Елена Монахова, Алексей Важнов
Последние два года все активнее идет заполнение пустующей ранее ниши российского компьютерного рынка, где обитают системы масштаба предприятия. Там еще по-прежнему просторно, игроков не так много, однако пользователю, сбитому с толку монументальностью упомянутых продуктов, легко заблудиться и в этих трех соснах. Дезориентируют и одинаковые слова, написанные в рекламных проспектах фирм-разработчиков: масштабируемость, открытость, простота настройки и модификации и т. д. и т. п. Мы неоднократно наблюдали, как ИТ-менеджеры с предприятий заполняют на выставках всевозможные собственные таблички, пытаясь на основе их анализа объять необъятное - разом оценить и финансовую, и функциональную, и инструментальную часть этих систем. Да еще и составить впечатление о команде, которая продукт (решение) поставляет.
Опыт нашего общения с клиентской аудиторией подтвердил страшный голод на сравнительные обзоры продуктов именно этого сегмента. Их отсутствие вполне понятно - российский рынок сильно отличается от западного по количеству и качеству представленных систем, а исследование таких продуктов - дело сложное, дорогое и трудно формализуемое. Представленный сегодня обзор (вернее, его первая часть), выполненный экспертами исследовательской группы RC Group, - попытка хоть в какой-то степени “размочить” этот вакуум. В нем рассматриваются тиражируемые решения, которые могут быть использованы как основа (прототип) для построения корпоративных информационных систем.
Кому это надо?
Наибольшую сложность вызвал выбор системы координат.
Почему именно в таких осях - прикладная технологичность и инструментальная технологичность (схема 1) - было принято рассматривать совокупность тиражируемых решений, способных вырасти до систем масштаба предприятия? Потому что, на наш взгляд, этот разрез сегодня наиболее информативен и понятен для тех, кто отвечает за выбор такого ПО, - ведь это, как правило, начальники служб АСУ, консультанты (бизнес-аналитики), аудиторы. Такая систематизация может пригодиться и системным интеграторам, зачастую выступающим в роли генподрядчиков в крупных проектах по автоматизации. Особенно тем из них, кто не привязан к какому-то одному продукту, а может предлагать своим клиентам некоторый выбор.
Схема 1. Оценка технологичности тиражируемых решений (в условиях фиксированной функциональности)
Мы хотим также привлечь к этому обзору внимание руководителей предприятий среднего (и, может быть, даже малого) уровня. Ведь неизбежный рост бизнеса, диктуемый понижающейся доходностью, через очень короткое время поставит их перед необходимостью масштабировать свои информационные системы. И тогда затраты на замену программной основы для построения ИС наверняка перекроют первоначальную экономию от использования технологий вчерашнего дня, реализованных в дешевых файл-серверных продуктах. Так что есть резон сразу сделать ставку на правильных “скакунов”.
Подчеркнем, что финансовый аспект мы на этом этапе исследований “вынесли за скобки”, - о нем еще пойдет речь в будущем, а до поры до времени пусть дилемму “по карману - не по карману” ИТ-менеджеры решают сами - они, как нам кажется, достаточно хорошо научились это делать.
Мерило соответствия ожиданиям
Что нужно иметь в виду, чтобы не сильно промахнуться при выборе того или иного программного решения?
Во-первых, быть уверенным, что с его помощью за расчетное время и определенные деньги можно решить хотя бы ограниченный круг “горящих” задач (судя по опросам клиентов, до сих пор задачи управленческого учета стоят на первом месте по актуальности на большинстве предприятий). При этом, вообще говоря, не так важно, какой набор задач взять в качестве базы для оценки, - главное, чтобы можно было продемонстрировать ряд основополагающих свойств рассматриваемого программного решения: гибкость (легкость в настройке и внесении изменений), масштабируемость (возможность при необходимости распространить решение на филиалы, преобразовать систему в территориально-распределенную), открытость (способность легко взаимодействовать с другими присутствующими в ИС предприятия программными продуктами - почтой, разнообразными БД, бухгалтерскими пакетами и т. п.). Эти качества могут быть весьма наглядно представлены в осях “прикладная технологичность” (реализация бизнес-логики, простота ее модернизации) и “инструментальная технологичность” (простота настройки ИС). А ограниченная функциональность (в нашем случае - рамками управленческого учета) играет свою положительную роль - не дает задаче “распухнуть”, помогает найти общий знаменатель. Ведь если сложный продукт построен на верных принципах, проблем с последующим наращиванием функциональности быть не должно. Значит, в первую очередь важно на качественном уровне оценить эти самые принципы.
Вторая непростая задача клиента при выборе решения - не промахнуться с командой, с которой его организация на длительное время свяжет свою жизнь. То есть существенно, чтобы разработчик имел достаточный потенциал (финансовый и человеческий) для поддержки и развития своего продукта на протяжении ближайших 7 - 10 лет (что соответствует циклу изменения технологий, обслуживающих бизнес) и был способен консультировать и обучать тех, кто будет работать с ним со стороны заказчика.
Предлагаемый обзор (результат завершения первого этапа исследований) преимущественно освещает первый, “технологический” блок критериев. Второму блоку, связанному с оценкой потенциала фирм-разработчиков, будет уделено соответствующее внимание по мере развития исследований на следующих этапах.
Ориентация на решения
Приступая к исследованиям, мы ориентировались на возможность создания законченных решений, построенных на базе рассматриваемых программных продуктов.
Что понимается нами под законченным решением? Это совокупность программных средств и услуг, позволяющих решить некоторый круг задач (как правило, наиболее “горячих” для конкретного бизнеса) за расчетное время с привлечением определенных (заранее просчитываемых) финансовых и человеческих ресурсов. Например, поставить на предприятии управленческий учет, минимизировать запасы на складах, обеспечить гибкое ценообразование, реализовать массовую сборку изделий на заказ и т. п.
Подразумевается, что фирма-разработчик предоставляет законченное решение, если она способна провести все работы по следующим этапам:
- обследование (с привлечением собственной или внешней команды бизнес-аналитиков);
- реинжиниринг бизнес-процессов;
- ввод в эксплуатацию (настройка);
- обучение персонала заказчика.
Решения принципиально отличаются от коробочных продуктов тем, что в их создании, внедрении и сопровождении участвует большое число специалистов разного профиля (бизнес-аналитиков, разработчиков, преподавателей обучающих центров и др.). Для успешного ввода ИС в эксплуатацию их взаимодействие должно быть организовано оптимальным образом, что предполагает наличие некоторой внутрифирменной технологии. Этот фактор тоже принимался во внимание в нашем исследовании.
Несомненно, заказные решения могут быть и более отточенными, чем тиражируемые, и более эффективными (для конкретного этапа развития бизнеса в некоторый фиксированный момент времени). Но их развитие и поддержка окажется однозначно более дорогостоящей и более зависимой от разработчиков. Так что унификация (создание тиражируемых решений) - способ удешевить и упростить процесс построения ИС.
Поскольку эксперты знакомились с системами не самостоятельно, а во время демонстрации их специалистами фирм-разработчиков, то объективно отсутствовала возможность точных сравнений. Можно было лишь качественно оценить рассматриваемые системы, а потому для повышения объективности оценки во втором раунде было организовано обсуждение результатов с бизнес-аналитиками, работающими в этом сегменте рынка. После жарких споров сформировалось общее мнение, что нецелесообразно проводить “соревнование” систем на каком-то специальном тестовом примере. Простой пример годится только для оценки функциональности (делает/не делает), мы же сравнивали системы в условиях ограниченной функциональности. А сложный пример разрабатывать слишком долго (и дорого), притом еще дороже оценивать результаты выполнения (ввиду многокритериальности). В то же время выполнять по заказу такие работы в рамках тестовой лаборатории RC Group вполне возможно.
Зачем нужны стандартные технологии
В качестве отправной точки при рассмотрении продуктов, пригодных для создания тиражируемых решений, обращалось внимание на использование стандартных технологий. Так, например, разработчик должен предусмотреть два вида программных интерфейсов:
- API - как средство доступа к внутренним объектам системы из внешних по отношению к ней программ;
- среда программирования для управления объектами внешних программ из системы. Сегодня такие инструменты стандартизованы де-факто. Достаточно, например, лицензировать среду Visual Basic for Applications.
Подчеркнем, что перечисленные средства ни в коем случае не предназначены для настройки ИС на бизнес! Они используются только для организации стыковки с другими элементами среды рабочего места. А описание бизнес-правил должно производиться принципиально иными средствами.
На первом этапе было рассмотрено пять программных продуктов:
- Platinum SQL (фирмы Platinum Software);
- “Галактика” (корпорации “Галактика”);
- “Эталон” (фирмы “Цефей”);
- “Ресурс” (фирмы “Эллай”);
- Baan IV (фирмы Baan).
Продукт R/3 фирмы SAP изображен на схеме условно, для некоторой ориентации, и соответствует пока лишь внутренним представлениям экспертов о его расположении в означенных осях. Более точно он будет позиционирован после знакомства с ним.
Врата великих возможностей
Исследование проводилось в условиях ограниченной функциональности, подразумевающей возможность немедленного (после установки системы) решения задач управленческого учета в контуре товародвижения, взаиморасчетов и расчета себестоимости.
Ознакомление с системами производилось по единому опросному листу без предварительного предоставления его фирмам-разработчикам. Ниже приведен агрегированный список критериев, каждый из пунктов которого в опросном листе был соответствующим образом детализирован. На данной фазе исследования назначать весовые коэффициенты оцениваемым параметрам было бы, на наш взгляд, некорректно.
Инструментальная технологичность
- Простота установки и настройки системы (развертывание системы, в том числе силами штатного администратора заказчика, массовый импорт данных на этапе загрузки).
- Способы описания бизнес-процессов в системе (правила, алгоритмы, необходимость программирования при реализации сложных процессов).
- Простота сопровождения системы администратором (работа с распределенными БД, синхронизация БД, способы формирования отчетности, модификация набора учетных реквизитов и т. д.).
- Простота стыковки с внешними программными модулями (интерфейсы к другим компонентам программной среды, возможность обмена данными с другими подсистемами ИС заказчика, хранение шаблонов импорта и экспорта данных).
Прикладная технологичность
- Заложенные в систему технологии и принципы подготовки и хранения документов (возможность хранить не до конца оформленный документ, возможность оперативного подключения других приложений при работе с документами и т. п.);
- Возможность гибко изменять бизнес-модель и одновременно применять несколько моделей на имеющемся массиве исходных данных;
- Система формирования отчетов (внутренний генератор отчетов, возможность использования внешнего генератора отчетов, возможность подключения серверов OLAP). “Динамичность” продукта при проведении анализа накопленных данных.
Не надо оваций
Перечисленные критерии нельзя рассматривать как результат фундаментальных методических разработок. Это скорее первый набросок, позволяющий представить качественную картину, характеризующую различия между тиражируемыми решениями с точки зрения инструментальной и прикладной технологичности или, иными словами, простоту настройки на начальной стадии (при вводе в эксплуатацию) и гибкость модификации системы при последующем ее развитии.
Как видится дальнейшее развитие этих исследований? RC Group намерена просмотреть и разместить в уже выбранных осях в общей сложности около 15 систем, претендующих (как нам сейчас кажется) на звание масштабируемых, открытых, гибких и проч. благодаря заложенным в них технологиям. А затем добавить срез, затрагивающий человеческий фактор, т. е. сравнить силы (интеллектуальный и финансовый потенциал) команд, поставляющих эти решения.
К представленным на схеме продуктам мы тоже еще вернемся - их развитие идет очень бурно, ожидаются новые, значительно отличающиеся версии, и, следовательно, положение в нашей системе координат может сильно измениться. На схеме это развитие обозначено стрелками.
Свои вопросы вы можете присылать по адресу: rcgroup@aha.ru.
Путеводитель по схеме 1, или К чему приводят различия во внутренней организации программных систем
Что может служить мерой качества при сравнении блочно-функциональных и мониторных систем? Как обычно, деньги. Схема 2 демонстрирует принципиально разную динамику затрат при внедрении и эксплуатации этих систем.
схема 2. Как изменяется функциональность ИС с дискретным
характером развития при изменении требований бизнеса
Блочно-функциональные - это системы с дискретным характером развития (наращивания). Их функциональность повышается скачкообразно при переходе к следующей версии либо при добавлении очередного блока. При подключении нового блока (приобретенного в связи с растущими потребностями бизнеса) необходимо вложить определенные средства для его запуска, складывающиеся из трудозатрат на детализацию (изменение) набора учетных признаков и на соответствующую организационную поддержку (добавление обязанностей какому-то сотруднику), связанную с регистрацией этих признаков в системе.
В начальный период (область A), как правило, имеется избыток функциональности, т. е. некоторые функции, присутствующие в системе, не используются.
По мере освоения системы пользователями эти возможности будут востребованы и в точке B будет наблюдаться идеальное соответствие возможностей системы запросам ее клиентов (на фиксированный момент времени).
Но бизнес развивается дальше, и вновь начинает ощущаться недостаток функциональности (область C), который менеджерам среднего звена приходится компенсировать дополнительными действиями. По некоторым оценкам, этот резерв мощности менеджерского звена должен составлять около 20%.
Иначе ведут себя мониторные системы, построенные на основе программного ядра. Фирма “Эллай” предложила для них удачное название - бизнес-процессоры, функциональность которых наращивается плавно при добавлении новых бизнес-правил. Их кардинальное отличие в том, что язык настройки этих систем оперирует терминами бизнеса, а не является вариацией традиционного языка программирования (пусть даже высокого уровня типа 4GL). В блочно-функциональных системах бизнес-логика реализуется программным кодом, в то время как бизнес-процессор позволяет не хранить в программе сведения об объектах бизнеса, изменения касаются лишь слоя бизнес-правил.
А вот статическая и динамическая модели, расположенные на вертикальной оси схемы 1, определяют поведение программной системы при обработке накопленных данных. Системы с динамической моделью в ходе своей работы создают новые знания о предметной области (например, выявленные взаимозависимости данных) и сразу же их используют. А применение статической модели подразумевает, что эти знания должны быть преобразованы в алгоритмическую форму и внесены в систему ее администратором.
Преимущества динамической модели (скорее - просто динамичность) проявляются, в частности, при онлайновой аналитической обработке (OLAP). Пусть на очередном шаге анализа возникает необходимость ввести дополнительный критерий для того, чтобы произвести разделение (split) данных. К этому моменту данные уже накоплены в БД и введение еще одного критерия (еще одного поля в БД) должно не только повлиять на сбор новых, но затронуть и старые данные. Причем система должна сделать это (полу)автоматически, при модификации бизнес-логики. В блочно-функциональных системах при работе с внешними источниками для обеспечения онлайновой динамичности должны быть предусмотрены специальные, достаточно дорогие в разработке процедуры, основной недостаток которых - необходимость детально прописывать обработку базы данных средствами СУБД и встроенного языка программирования СУБД.
Сила динамической модели в том, что она позволяет принимать решения на основе не полностью определенных исходных данных, достраивая недостающие фрагменты картины, используя методы искусственного интеллекта и нечеткой логики. (Решение таких задач алгоритмическими методами в принципе невозможно.)
В построенной подобным образом системе “Ресурс”, например, предусмотрено так называемое управление контекстом, позволяющее системному аналитику при проведении модификаций не опускаться на транзакционный уровень (детального прописывания всех взаимосвязей, потоков данных и т. п.). Система сама, по своим внутренним законам, которые работающий с ПО человек детально не специфицирует, преобразует массив имеющихся данных и в требуемом виде представляет результаты пользователю.
В отличие от “Ресурса” в продукте фирмы Baan для варьирования поведения системы используются сети Петри, являющиеся более жестким вариантом, чем системы искусственного интеллекта. Скорее всего, выбор сети Петри определялся эффективностью программной реализации.
Продолжение см. PC Week №(161)37/98
