Собери сам... и отвечай сам

Окончание. Начало см. PC Week/RE, № / 2001, с. 30; № /2001, с. 30.

Завершает разговор о “ядерной” части систем-конструкторов начатый в 4-м и 5-м номерах PC Week/RE рассказ Елены Дворниковой о структуре системы “Эталон”, которую разработчики настойчиво причисляют к категории комплексных систем управления, а не конструкторов, хотя об этом, наверное, можно и поспорить.

Елена Дворникова:

- Ядро системы для нас - это программный код. На него возложены функции обработки базовых классов и обеспечение работы CASE. Ядро едино для всех проектов, один и тот же программный код работает на всех предприятиях наших заказчиков. Ежемесячно выпускается новый релиз, зарегистрированные пользователи могут получить его на нашем Web-сайте.

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

В качестве прототипа для настройки новой системы управления мы можем использовать как базовую модель предприятия (в ней собраны наиболее эффективные, на наш взгляд, решения по отдельным задачам управления), так и наиболее близкую по отношению к рассматриваемому предприятию по составу ресурсов и параметров управления информационную модель из библиотеки уже готовых проектов. Базовую модель мы иногда называем базовой поставкой, потому что даже без дополнительных настроек она удовлетворяет потребности в управлении широкого круга промышленных предприятий. На эту модель существует комплект инструкций (с описанием бизнес-процессов) по всем участкам управленческого учета. Это не только учет по балансовым счетам (вообще “бухгалтерская” часть занимает не более 5% в перечне функциональных возможностей), но и управление договорной деятельностью, персоналом, проектами, производством, оперативное планирование, бюджетирование, мониторинг, финансово-экономический анализ и другие задачи управления. Базовая поставка может продаваться без дополнительной адаптации, в виде коробочного продукта. Такие случаи у нас были (более 50 продаж).

Соломоново решение

Второй компонент успеха конструкторов - развитость технологической основы, условно названной в первой части статьи средой разработки. Думается, конкурентная борьба между поставщиками конструкторов разгорается в основном на этом поле. Здесь берется в расчет много всего разного: и удобство встроенных дизайнеров, и простота прилагаемых CASE-средств, и проработанность “разъемов” между базовой частью и настройками, и полнота “объектной ориентированности”. Оно и понятно - в конечном счете от этой технологической части существенно зависит привлекательная гибкость конструктора, определяемая тем, насколько он при необходимости может “разложиться” на элементарные “кирпичики”, а потом вновь воплотиться в “конструкции”, собранной по другим “чертежам”. А также, что не менее важно, насколько сложным будет перевод решений на базе таких систем на новые версии.

В рамках беглого выставочного обзора бессмысленно как-либо сравнивать эти причудливые инструменты (их богатый перечень был представлен в таблице, приведенной в 5-м номере нашего еженедельника). Но поскольку тема эта очень интересная, мы, посовещавшись на редакционной оперативке, пришли к соломонову решению - провести в марте круглый стол, посвященный именно этому остро конкурентному компоненту систем-конструкторов. О его результатах мы, несомненно, сообщим на страницах PC Week/RE.

А напоследок я скажу+

Откровенно говоря, к мысли о написании статьи про конструкторы меня подтолкнули довольно частые обращения ИТ-менеджеров малых и средних предприятий. Из писем следует, что этим специалистам в целом симпатична идея построения комплексных ИС на базе ERP-систем и им подобных, но в то же время они абсолютно уверены, что их предприятию это сегодня не по карману. Резонен вопрос: есть ли на рынке достойные альтернативы (пусть уступающие по функциональным возможностям), которые лежат в другой ценовой нише и внедряются быстрее? Мой гипотетический ответ: хорошо проработанные конструкторы как раз могли бы претендовать на эту роль.

Две из трех рассмотренных в данном обзоре систем - “Тектон” и “Алеф” - похоже, именно так себя и позиционируют. Совокупная стоимость их проектов в основном лежит в диапазоне нескольких десятков тысяч долларов (при количестве рабочих мест около 30).

А напоследок - о главном. От того, насколько профессионально сконструирован и собран самолет, зависят не только его летные качества, но и жизнь пассажиров. Конечно, КИС - не самолет, и сравнение, прямо скажем, несколько натянутое. Но все же от правильности заложенных в этих системах бизнес-моделей серьезно зависит управленческое благополучие компаний (и чем крупнее предприятие, тем сильнее эта зависимость). А посему, несмотря на большие достижения разработчиков в области создания суперфантазийных сред разработки, главным фактором все равно останется идеологический (смысловой) стержень - бизнес-модель.

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

После сказанного

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

Ну и конечно же, я приглашаю всех, кто имел опыт разработки или использования систем-конструкторов, присоединиться к начатому нами обсуждению. Какие вопросы вы хотите задать разработчикам (или другим экспертам) на предстоящем круглом столе? Жду ваших предложений по адресу: monah@pcweek.ru.

Здравствуйте, Елена.

Часто попадаются Ваши статьи, которые для меня интересны и полезны в силу совпадения предметной области. Но статья “Собери сам+ и отвечай сам” в этом смысле особенная.

Некоторые комментарии к Вашей статье.

1. Практически полностью согласен с определением конструктора.

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

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

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

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

4. Теперь об одном из основных недостатков конструкторов, ускользнувшем из поля Вашего внимания в первой части статьи.

В конечном ПО, работающем у клиента на базе конструктора, явно выделяются три пласта:

- то, что создавали основные архитекторы ядра системы;

- то, что добавил и развил поставщик решения;

- то, что добавил клиент.

Естественно, чем ниже квалификация вносящего свой вклад специалиста, тем хуже результат. В итоге конечное ПО, работающее у клиента, оказывается “рыхлым” и далеко не оптимальным.

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

С уважением, директор представительства московской фирмы “СервоКомп” в Санкт-Петербурге Кисин Михаил Вениаминович