Всевозможные конструкторы, помнится, страшно занимали меня в детстве. Благодаря им я, наверное, научилась делать уроки быстро - хотелось выкроить побольше времени, чтобы поколдовать над разными металлическими детальками, из которых получался то причудливый торшер, то коляска, то подъемный кран. А если к этому великолепию добавлялись еще электрические проводки, миниатюрные лампочки и возможности непопулярных ныне 4,5-вольтных батареек, то оторваться от такого занятия было просто невозможно.

Сегодня технологии шагнули далеко вперед, осчастливив нынешнее поколение детей невероятным разнообразием моделей “Лего” и подобных ему наборов, однако ключевая идея в них осталась прежней - дать простор детской фантазии, предоставить инструмент, позволяющий создать что-то свое, потом это перестроить, добавив новые элементы, и так до бесконечности.

Мнится мне, что пользователи и создатели сегодняшних программ-конструкторов в глубине души испытывают что-то подобное моим детским восторгам, когда мастерят причудливые конструкции из своих “Лего”-подобных элементов. Как и зачем они это делают?

Так сложилось, что на отечественном и мировом рынке выделилось три типа программных продуктов, используемых для создания корпоративных информационных систем (КИС) - заказные, полузаказные (конструкторы) и тиражные. Мы не раз обсуждали их различия (см. например, PC Week/RE, № 35/2000 с. 33 или PC Week/RE, № 30/2000, с. 20). Вкратце они сводятся к следующему. Заказные продукты идеально подходят предприятию в некоторый момент времени Х (созданы по его “мерке”, отражают его особенности), но слишком долго разрабатываются и дорого стоят, если проект сложный. В противоположность им тиражные - гораздо дешевле, быстрее внедряются, но заложенные в них бизнес-модели могут существенно отличаться от имеющихся на конкретном предприятии процессов (причем с выходом новых версий эти различия могут лишь усугубляться).

Поскольку природа не терпит пустоты, то программы-конструкторы удачно внедрились между заказными разработками и тиражными продуктами, претендуя на золотую середину по всем трем параметрам - гибкости решения, его стоимости и срокам внедрения. Таких продуктов на российском рынке немного, поскольку их создание требует от разработчиков особого уровня программистской культуры: надо уметь проектировать и развивать не только ядро (прототип), но и собственные высокоуровневые инструментальные средства.

На прошедшей выставке “Бухучет и аудит - 2001” мне удалось побеседовать с представителями трех отечественных фирм-разработчиков, представляющих продукты рассматриваемой категории: “Алеф Консалтинг энд Софт”, “Цефей”, “ИнтелГрупп”.

Общий знаменатель

По традиции сначала пришлось сформулировать определение, чтобы привести все рассуждения к общему знаменателю, для чего всем разработчикам было предложено продолжить фразу: “Программный конструктор - это+”. Нельзя сказать, что участники акции были единодушны и отвечали без запинки. Выделение характерных, а точнее - базовых черт этого ПО оказалось делом не простым даже для его разработчиков. Недаром к этой категории разные специалисты причисляли разные продукты (скажем, “1С:Предприятие” кто-то причислял к конструкторам, а кто-то категорически возражал, называя его “всего лишь технологической платформой”). В первом приближении у нас получилось следующее.

Определение. Конструктор - это программный продукт, включающий:

- ядро (изменяемое или неизменяемое в зависимости от желания или нежелания фирмы-разработчика разрешить клиентам доступ к нему);

- модель предметной области (достаточно абстрактную);

- среду разработки высокого уровня (CASE-средства, дизайнеры, визарды и т. п.), которая не требует от пользователя программистских навыков, а позволяет оперировать понятиями предметной области.

Следствия:

1. Конструктор должен обеспечивать совместимость снизу вверх готовых программных решений и ядра.

2. Конструктор не должен работать с физической базой данных напрямую.

Зачем и кому они нужны

Евгений Аксенов, генеральный директор фирмы “Алеф Консалтинг”:

- Конструкторы прежде всего привлекательны для компаний с четко выраженной спецификой бизнеса и компаний, изменения хозяйственной модели которых имеет высокую динамику, ввиду диверсификации бизнеса, изменения системы управления, организационной структуры, внешней среды и т. п.

Подобное ПО позволяет создавать специфические решения от уровня ядра конструктора, что значительно ускоряет разработку приложений и обеспечивает надежную архитектуру решения в целом.

Совсем не обязательно, чтобы заказчик или поставщик конструктора своими силами разрабатывал решение. Это могут делать независимые партнеры (консультанты).

В связи с этим конструктор обязан обеспечить возможность управления внутренними стандартами и эффективного ведения многоуровневого бизнеса, в котором между разработчиком и клиентом занимают должное положение поставщики решений, которые разрабатывают, внедряют и сопровождают отдельные модули или комплексные решения.

Они должны доверять конструктору, который должен помочь им быстро создавать надежно работающие решения и предоставлять возможность выбора того уровня абстракции для внесения изменений, который уместен в каждом отдельном случае.

Кроме того, каждая новая версия конструктора, наряду с предоставлением новых возможностей, должна поддерживать наработки, выполненные на более ранних версиях. Для этого “разъемы” между ядром конструктора и настройками, из которых состоит конечное решение, должны быть четко документированы и поддерживаться разработчиком конструктора от версии к версии. Иначе инвестиции в решения, создаваемые на конструкторе, не будут надежно защищены и потребуют от клиента финансирования не только поддержки решений, но и “ядерного” функционала конструктора. Тогда зачем конструктор?

Дмитрий Глямшин, зам. генерального директора “ИнтелГрупп”:

- Конструктор - это технологическая база, позволяющая не только удовлетворять текущие потребности предприятия, но и обеспечивать оптимизацию его деятельности в дальнейшем. Первичны - управленческие методики (например, организация учета затрат с разделением их на постоянные и переменные и расчета маржинальной прибыли), но без адекватной технологической основы их сегодня реализовать практически невозможно. А программы-конструкторы позволяют быстро справиться с такими задачами.

Они полезны предприятиям, которым нужно быстро создать макет, прототип для решения остро стоящей экономической задачи. Пусть он не будет оптимальным, но качественную картину получить позволит.

Характерный пример: скажем, предприятие хочет внедрить систему класса MRP II, но это возможно, если на нем существуют и выполняются все необходимые нормы и нормативы до уровня операций. А если их нет или они безнадежно устарели? В этом случае “в лоб” внедрение MRP II не проходит. Значит, надо сначала заняться нормированием, а это, как известно, процесс небыстрый. При таком движении “от печки” результат можно увидеть только через 1,5-2 года. Отсюда проблема неудовлетворенности клиентов ERP/MRP-системами.

Конструкторы позволяют идти по другому пути. Если на предприятии есть особенности, переделка которых займет продолжительное время, то мы в качестве первого шага предлагаем моделирование базовых элементов производственной цепочки (тогда отнормировать процессы достаточно не до уровня операций, а до уровня подразделений). Это через 2-3 месяца позволяет грубо прикинуть себестоимость, посчитать затраты по подразделениям - пусть с точностью 3-5%, а не 0,1%, как в MRP-системах. А параллельно технологический отдел предприятия занимается разработкой норм и нормативов, в том темпе, который возможен. Как только они будут готовы, мы внесем изменения в систему.

Елена Дворникова, руководитель службы информации фирмы “Цефей”:

- Наша “Эталон”-CASE-технология (мы никогда не считали КСУ “Эталон” “конструктором, это полнофункциональная корпоративная система управления со встроенным CASE) отдельно от информационной поставки, безусловно, имеет некоторый смысл, так как позволяет проектировать и создавать отдельные приложения и системы в различных сферах, о которых разработчики могут и не подозревать, а также произвордить (в том числе и нашим партнерам, и самим заказчикам) “тонкую настройку” КСУ. Но покупать конструктор вместо КСУ для предприятия, на наш взгляд, нецелесообразно. Создание “своей” КСУ требует слишком больших затрат (под конструктором, как становится ясно из дальнейших рассуждений, Елена Дворникова подразумевает только средства настройки. - Прим. ред.).

Применительно к КСУ имеет смысл говорить о формировании и накоплении систем прототипов (или библиотек решений) и средств их использования и доработки Скажем, прототип - это базовый “костюм”(для металургического предприятия или нефтегазового холдинга), а средство настройки - это “швейная машинка”, позволяющая подогнать его по фигуре заказчика). Чем шире возможности конструктора, передаваемого пользователю, и больше библиотека исходных моделей, тем лучше. Пользователь получает все возможности по настройке системы за исключением работы с базовыми классами (мы не разрешаем пользователю влезать в наш программный код). Все остальные функции по настройкам клиенту доступны: установить и переопределить связи, копировать и наследовать какие-то классы, объекты или методы, настраивать формы ввода и представления информации и др. Это позволяет пользователю чувствовать полную самостоятельность - он не ощущает себя привязанным к разработчику, но, в то же время, всегда может обратиться к нему за помощью, используя имеющуюся технологию сопровождения B2B. Этот факт является торговым преимуществом для систем такого класса, обладающих развитым инструментарием настройки.

(Окончание следует)