На протяжении последних месяцев я с увлечением следил за дискуссией о системах-трансформерах (раньше их называли «конструкторами», но не все участники дискуссии любят это слово. Познакомиться с дискуссией можно в номерах 11, 12, 14 и 23 еженедельника PCWeek/RE за 2002 год.)
Напомню определение предмета дискуссии. Определение это можно уточнять и расширять до бесконечности, но, на мой взгляд, достаточно ограничиться краткой версией. Речь идет о пакетах деловых программ (Корпоративные информационные системы, Автоматизированные системы управления предприятием - как вам будет угодно), снабженных мощными инструментальными средствами (в том числе встроенными языками программирования) для создания индивидуальных конфигураций без участия разработчика.
Несколько из обсуждавшихся вопросов меня «зацепило». Вот один из них: «Кому нужны системы-конструкторы бизнес-приложений?»
В ходе дискуссии под словом «кому» имелись в виду потребители систем. Думается, это отдельный вопрос, а начинать стоит с авторов программного обеспечения.
Конечный пользователь системы (бухгалтер, менеджер, диспетчер производства, руководитель предприятия и так далее) всегда использует «жесткую» программу. Бухгалтер, настраивающий «под себя» базовую конфигурацию «1С» или «Турбо-бухгалтера», не является исключением. Он просто выступает в обеих ипостасях - сначала как программист, а потом как конечный пользователь. Замечу еще, что чем крупнее предприятие, чем больше пользователей входит одновременно в систему, тем выше требования к этой самой «жесткости». В больших фирмах зачастую одна из основных функций программы - «хватать за руку отступника», пытающегося сделать хотя бы шаг в сторону от утвержденных бизнес-процедур.
Если рассматривать «жесткое» приложение в качестве конечного продукта программистской деятельности, то становится очевидным, что создатели систем-конструкторов просто расчленяют процесс разработки на большее число этапов, чем разработчики «жестких» систем. Между тем, это разделение ничем принципиально не отличается от распределения обязанностей среди программистов производящей компании: вряд ли кто-то из них будет отрицать наличие «инструментальщиков», «прикладников», разработчиков визуальных форм и т. д. Впрочем, одно отличие есть: создатели конструкторов заранее планируют, что часть программистов, создающих конечный продукт, не будет входить в штат их родной фирмы.
Осмелюсь утверждать, что конечному пользователю абсолютно безразлично, каким образом программа, с которой он работает, появилась на свет. Зато это очень даже небезразлично для компании-разработчика.
Если разработчик делового программного обеспечения заранее ориентирован на плотную работу с конечным пользователем, в том числе и на извлечение прибыли за счет обслуживания своего ПО в течение всего жизненного цикла, он не станет «выдавать на-гора» открытую систему. Он ограничится включением в пакет средств параметрической настройки (о них чуть позже). Более того, если разработчик запланировал распространение продукта и обновление версий без участия сотрудников своего отдела внедрения, то требования к «жесткости» будут усилены. В результате пользователь таких систем будет ограничен заранее заложенными моделями бизнес-процессов. Покупая их, он приобретает не только (и даже не столько) программное обеспечение, но и опыт бизнес-консультантов производителя. Как представляется, такая идеология заложена, например, в систему «ЛокОфис» компании «ЛокИС».
Если же компания настроена на работу через дилерскую сеть, то рано или поздно она придет к идее конструктора. Это наглядно доказывает деятельность самого известного в России разработчика деловых программ, компании «1С», полностью ориентированной на организацию франчайзинговой сети. Аналогичные примеры - «ИнфоБухгалтер», «Турбо-Бухгалтер», да и вся история моего родного «Компаса» - это история увеличения открытости программного обеспечения.
Такой подход абсолютно логичен, ибо, чтобы привлечь партнеров, надо дать им возможность заработать, а основные доходы толковые дилеры извлекают вовсе не из продажи тиражных копий, а из внедрения системы, моделирования индивидуальных бизнес-процессов пользователя, создания новых отраслевых решений. Это очень четко начинаешь понимать, когда проанализируешь прайс-листы хотя бы нескольких франчайзи «1С». Да и то, что дилеры «Компаса» являются авторами таких отраслевых решений, как «Сельское хозяйство», «Зарплата для банков» или «Издательский дом», говорит о том же.
Но какие пользователи предпочтут «жесткую» систему, а какие систему-конструктор? Собственно говоря, ответ вытекает из сказанного ранее. Предприятию, не имеющему развитую службу ИТ, конструктор не нужен. Он ему противопоказан. Это не значит, что такой пользователь не приобретет ПО марки «1С», «ИнфоБухгалтер» или «Компас». Просто он не будет его покупать непосредственно у разработчика, а обратится к дилеру, поставляющему нужную ему конфигурацию. При этом в тендере на поставку программного обеспечения такой пользователь не будет делать различия между конструкторами и «жесткими» системами.
А вот большие предприятия, имеющие собственный штат программистов, склонны приобретать именно открытые системы. Но вот что интересно: в известной мне практике «на полную катушку» возможности конструкторов используются такими заказчиками редко. Чаще всего представители ИТ-департаментов занимаются созданием шлюзов между использующимися на предприятии программами разных марок, а все индивидуальные доработки и даже целые подсистемы заказываются у разработчика или его представителя. Исключения, как водится, подтверждают правило.
Зачем же таким пользователям нужны именно конструкторы? На мой взгляд, это, в первую очередь, вопрос уверенности в завтрашнем дне. Вложения во внедрение корпоративной информационной системы на больших предприятиях огромны. Жизненный цикл конечного продукта достаточно велик. А что если разработчик разорится, изменит профиль или иным образом уйдет с рынка? Приобретение конструктора - своего рода страховка от такой ситуации.
Второй вопрос, на котором хочется остановиться, - это инструментальные средства, включаемые в системы-конструкторы. Выделяют три уровня инструментов: классическая параметризация, визуальные средства и встроенные языки программирования. Если название третьего уровня говорит само за себя, то первые два хочется пояснить.
Под параметризацией понимают возможность выбора между различными бизнес-моделями, разными учетными политиками, для реализации которой пользователю достаточно установить позиционный переключатель, ответить на вопрос типа «да - нет» или ввести значение числового параметра (например, величину налоговой ставки). Такая настройка, как уже говорилось, присутствует не только в конструкторах, но и в «жестких системах».
Под инструментами визуальной настройки понимаются CASE-средства, мастера, дизайнеры и т. п., которые не требуют от пользователя программистских навыков, а позволяют оперировать понятиями предметной области.
На мой взгляд, качество системы-конструктора бизнес-приложений определяется, в первую очередь, соотношением возможностей настроечных средств второго и третьего уровней. Если нельзя решить хотя бы 60% всех проблем, связанных с изменением старых и появлением новых бизнес-процессов, не прибегая к помощи алгоритмического инструментария, то эксплуатация такого конструктора становится экономически невыгодной, а сам он сравним с классическими средствами разработки, такими как СУБД, RAD или даже компиляторы с алгоритмических языков.
Я совершенно не согласен с бытующим мнением, что большинству пользователей нельзя позволять корректировать структуры данных. Количество реальных проблем, которые можно было бы решить с помощью такого ограниченного инструментария, стремилось бы к нулю. Более того, я считаю, что проблемы изменения структур должны быть вынесены в слой визуальной настройки, чтобы поддержать высокую скорость создания новых конфигураций. И если введение нового поля в 90% случаев требует параллельной корректировки текстов в алгоритмическом слое, то разработчикам стоит подумать о перепроектировании инструмента.
Другое дело, что конструктор должен обладать развитыми средствами контроля корректности вносимых изменений. Главная задача таких средств - не позволить нарушить функционирование встроенных в тиражные программы алгоритмов. Что, например, будет делать складская часть системы-конструктора, если из таблицы складских карточек удалить поле остатков по конкретной номенклатуре? Вопрос риторический.
Третий пункт - проблема обновления программного обеспечения у конечного пользователя. Конструкторы бизнес-приложений - не просто средства разработки (иначе бы и смысла в них не было), это еще и программы, включающие конкретные модели бизнес-процессов, отвечающие текущим требованиям законодательства. Когда законы меняются (а в России это происходит очень часто), разработчик выпускает новую версию пакета. Вполне естественно, что в большинстве случаев пользователи предпочитают «не заморачиваться» с самостоятельной адаптацией своей информационной системы к новым законам, а получать новые версии пакета от разработчика в порядке абонементного обслуживания. Но стандартная поставка естественным образом не содержит всего того, что программисты ИТ-департамента сотворили собственными руками. Как все это совместить в режиме автоматического обновления?
Решение, к которому пришли разработчики системы «Компас», - это встроенная в утилиту обновления система распознавания «свой - чужой». Все таблицы, отдельные поля, формы представления информации и т. д., введенные самими разработчиками, должны помечаться специальными признаками. В результате все метаданные из старой версии системы, обладающие такими признаками, автоматически заменяются метаданными из новой версии. А вот с непомеченной частью приходится разбираться в диалоговом режиме. В результате для малоактивных пользователей, совершенно не дорабатывавших стандартную версию, обновления происходят очень быстро и «на автомате». Более квалифицированные пользователи также имеют приличную скорость обновления, если авторы изменений находятся под рукой. А вот если автор уволился, то процесс затягивается. В среднем же цифры получаются вполне приемлемые.
Такая система распознавания не очень проста, поэтому по мере накопления опыта она постепенно совершенствуется. В новом проекте серии «Компас» (он находится сейчас на стадии разработки) предусмотрено большее число уровней принадлежности, что позволит осуществлять поэтапное обновление. Например, сначала создается новая версия программы, полученная на основе стандартной версии, разработанной компанией «Компас», и изменений, внесенных дилером. А уже на следующем этапе этот вторичный вариант сливается с конфигурацией конкретного пользователя.
Несмотря на все трудности в разработке и сопровождении систем-конструкторов, они имеют, на мой взгляд, большое будущее. В конце концов, любые проблемы разрешаются.
Игорь Якобсон - главный эксперт компании «Компас»; с ним можно связаться по электронной почте по адресу sensr@kompac.spb.su