Елена Монахова, Алексей Важнов, Сергей Бобровский
Еще весной мы, не прощаясь с читателями надолго, предрекали непременную встречу осенью. Осень наступила на нас ласковыми днями бабьего лета и разгулом всеобъемлющего “политэкономического” кризиса. Но это, естественно, не повод для прекращения исследований. Среди изрядного числа полученных нами писем по поводу публикации результатов начального этапа наших исследований (см. PC Week/RE, № 14/98, с. 59) попадались и такие, в которых встречались вполне конструктивные предложения о развитии и расширении таких работ (актуальность их не оспаривал никто). Мы постарались эти предложения учесть.
Заседание продолжается! Итоги очередных шагов первого этапа (касающегося оценки технологичности) и наметки будущих сражений - перед вами.
“Возможно, придется отстреливаться. Я дам вам парабеллум”
Одна из отправных точек нашего обзора - глубокая уверенность авторов в том, что “коробочной” КИС нет и быть не может. К тому же среднестатистический российский заказчик ни за что не поручит все работы по созданию и поддержке КИС сторонней компании, поскольку стоимость такого поручения, как правило, слишком высока, а контролировать работу чужих сотрудников гораздо труднее, чем своих. Собственных же сил (высокопрофессиональных команд) для создания качественной КИС “от нуля” давно ни у кого нет. А посему приходится вспомнить, что оптимальное решение чаще всего находится на равном удалении от крайностей: целесообразно взять типовой продукт, который успешно может быть использован в качестве основы для создания КИС, поручить отдельные виды работ внешним консультантам, а сопровождение созданной системы оставить в своих руках. Как раз в таком случае особое звучание приобретает разговор о технологичности программных решений, продолженный нами в этой статье.
Новые игроки
Вторая часть исследований позволила добавить в наши квадранты еще три новых продукта:
- “БОСС-Корпорация” (фирма “АйТи”);
- Oracle Applications (Oracle);
- ConcordeXAL (Columbus).
Между тем в действительности продуктов было просмотрено больше. Почему же они не попали в нашу систему координат?
При знакомстве с системами мы обнаружили несколько интересных отклонений от привычного подхода к построению КИС. Они проявились в системах, ориентированных на производство, особенно непрерывное (пример - SyteLine фирмы Symix), и в системах, функциональность которых ограничена только управленческим учетом. К последним относится весьма интересная разработка московской фирмы “ИнтерпрокомЛАН” - система комплексной автоматизации торговли (СКАТ). По оценкам разработчиков, с чьим мнением мы согласны, использование стандартной платформы Lotus Notes, оперирующей понятием “документ”, на 60 - 70% снижает трудоемкость разработки и, главное, полностью снимает такие проблемы, как переход на следующие версии ОС, обеспечение многоплатформности, переносимости и т. п.
Система SyteLine не попала на наш график, поскольку инструменты настройки в ней, по сути дела сознательно не даны в руки пользователей (подробности - ниже), а система СКАТ - из-за того, что ее область применения ограниченна (на сегодняшний день). При этом обе системы претендуют на роль лидеров в своем классе и полностью удовлетворят заказчиков, чьи задачи не выходят за обозначенные рамки.
Еще раз о технологичности и ее последствиях
Почему были выбраны именно такие оси - прикладная и инструментальная технологичность - для представления результатов первого этапа исследований, мы уже объяснили в первой публикации. К введенным ранее определениям хотелось бы добавить несколько поясняющих слов.
Отчасти мерой инструментальной технологичности можно считать степень легкости (быстроты), с которой специалисты заказчика могут освоить средства настройки системы. Ведь зачастую очень мощные средства настройки, имеющиеся в системах этого уровня, нелегко освоить кому-либо, кроме специалистов самой фирмы-разработчика и узкого круга ее партнеров по внедрению.
Мера прикладной технологичности определяется тем, насколько гибко система может реализовать особенности бизнес-процедур заказчика. При этом не следует забывать, что инсталляция системы, в свою очередь, может повысить уровень организации бизнеса заказчика. Так что положительное взаимовлияние и проявляющиеся взаимосвязи не следует сбрасывать со счетов.
Поскольку сегодня отсутствует устоявшаяся терминология, то многие разработчики, характеризуя свои продукты, употребляют одинаковые слова в совершенно разных смыслах (особенно это касается термина “настройка”). Еще раз подчеркнем, что модификация системы - это по сути дела описание бизнес-правил средствами программирования. Базовое отличие настройки от модификации - - в неизменности программного кода системы. Профессиональный программист знает, от чего зависит качество реализации системы и почему любое изменение кода крайне отрицательно на это качество влияет.
Правда, существуют и другие взгляды на проблему прикладной технологичности. До абсолюта доводит свое неприятие изменений системы силами заказчиков фирма Socap, продвигающая на российском рынке продукты компании Symix. При этом ее позиция показалась нам достаточно разумной, если принять во внимание, что продукт SyteLine ориентирован на применение в промышленном производстве и тесно интегрирован с АСУ ТП (получает информацию с датчиков). В нем концептуально заложена определенная жесткость - а как иначе обеспечишь бесперебойную работу автоматизированных аппаратных комплексов? В этом случае всякие “фантазии” и гибкость не только неуместны, но и опасны.
Нужно ли программирование при описании бизнес-правил
Бизнес-правила - это структурированное отражение политики предприятия и практики ведения бизнеса (хозяйственной деятельности). Поначалу бизнес-правила напрямую реализовывались в программном коде прикладной системы. Этим занимались программисты по заданиям постановщиков задач (причем и те и другие имели очень смутное представление о бизнес-правилах, если имели таковое вообще). Чтобы создать большую систему в ограниченные сроки, нужно было распараллелить работы, разбив систему на модули, выполняющие связанный набор функций. Система, построенная как совокупность подобных модулей, называется блочно-функциональной.
Мониторные системы (или бизнес-процессоры) отличаются тем, что в них описания бизнес-правил вынесены в отдельный слой. Подобные системы управляются информацией, находящейся вне программного кода. Это на порядки повышает их надежность, поскольку программный код написан и отлажен один раз и остается неизменным при внесении изменений в логику работы. В мониторных системах обязательно присутствует специальный язык настройки - набор взаимосвязанных таблиц, проблемно-ориентированный язык высокого уровня (например, язык XAL в системе Concorde) или языки логического программирования (типа Prolog).
“Параллельные прямые пересекаются в бесконечности”
Если язык настройки мониторной системы представляет собой упрощенную самодеятельную версию FoxPro, Бейсика или функциональное расширение XQL (к примеру), что встречается в большинстве КИС и даже во многих бухгалтерских программах, то обработку данных в системе с помощью этого встроенного языка приходится реализовать через так называемые “точки выхода”. Это небольшие фрагменты программного кода (в предельном случае - просто формулы), привязанные к полям документов, либо к операциям над записью БД (в момент сохранения, обновления, удаления), либо к экранным формам. То есть большая часть бизнес-логики все равно описывается средствами процедурного языка программирования. Такие системы мы отнесли бы к “псевдомониторным”.
В то же время в истинно мониторных системах большое внимание уделяется формированию языка описания бизнес-логики, выделяемого в специальный промежуточный слой. Язык этот по своей структуре стремится к языкам логического программирования (ЛП). Их основное отличие от традиционных языков программирования в том, что программа представляет собой описание (декларирование) структур данных, их ограничений и взаимосвязей, а также действий по преобразованию данных, которые называются правилами и формулируются в виде:
ЕСЛИ {условия}
ТО {выполнить действия над данными, соответствующими условиям}
В традиционных языках мы в основном сосредоточены на управлении порядком исполнения программных инструкций, а данные отодвинуты на второй план. А вот в языках ЛП достаточно сформулировать только одно правило - согласно его условиям монитор сам отберет все данные и выполнит заданный набор действий над каждым из них *.
Кроме того, декларативные языки позволяют организовывать очень сложные запросы к БД (не обязательно реляционным!), что недоступно языкам типа SQL/OQL.
В то же время мы наблюдаем, как иные блочно-функциональные системы приближаются по своим качествам к мониторным. Завершив первую часть исследований, мы полагали, что левый верхний квадрант нашей диаграммы окажется незанятым - уж очень много сил (и средств) нужно приложить разработчикам тиражируемых систем для реализации механизма динамических изменений при блочно-функциональном подходе. Но корпорация Oracle сделала это! Не исключено, что пакет Oracle Applications останется единственным обитателем этой территории, демонстрируя финансовую мощь стоящего за его спиной лидера индустрии.
Углубим и расширим
Осмыслив на досуге все поступившие комментарии, коллектив экспертов RC Group за лето доработал концепции недостающих блоков для широкомасштабного исследования продуктов, способных лечь в основу построения КИС предприятий, относящихся к категории средних и крупных.
Были определены цели и задачи еще трех этапов, в комплексе с первым, уже развернутым, дающих наиболее полное, на наш взгляд, представление об исследуемом объекте и его особенностях.
Каковы же эти этапы? Первый носит название “Оценка технологичности программных решений, которые могут быть использованы как основа (прототип) для построения корпоративных информационных систем”. В этой статье мы знакомим вас со второй частью этого этапа, проводимого в условиях фиксированной функциональности методом экспертных оценок.
Второй этап касается оценки (в баллах) жизнеспособности и качества работы фирм - поставщиков означенных решений. Он предусматривает исследование финансовой устойчивости, уровня управления и уровня работы с кадрами в этих компаниях, а также качества разработки и внедрения ПО, работ по обследованию, обучению, сопровождению клиентов.
На третьем этапе будет проведено исследование функциональности и области применения поставляемых продуктов.
Четвертый посвящен сравнительной оценке стоимости всех работ по вводу в эксплуатацию и последующему сопровождению подобных систем.
На сегодняшний день RC Group располагает развернутыми методиками для каждого из перечисленных этапов.
По замыслу инициаторов исследовательских работ, с завершением всех этапов можно будет, с одной стороны, получить некоторую довольно объективную интегральную оценку качества и стоимости поставляемого решения, а с другой - рельефные его отражения в разных проекциях, позволяющие сравнить определенные характеристики решений между собой.
Полный текст статьи можно прочитать на Web-узле www.pcweek.ru/kis, раздел RC Group.
* Чтобы не перегружать излишними подробностями эту статью, мы решили подготовить отдельный материал по использованию подходов искусственного интеллекта при построении КИС. Он будет опубликован в ближайших номерах PC Week/RE, а также доступен на сайте: www.pcweek.ru/kis.
К авторам - экспертам RC Group - можно обратиться по адресу: rcgroup@aha.ru.
