Практика и проблематика моделирования бизнес-процессов - Е. Всяких

♦ отсутствие необходимости модернизации общесистемной программно-аппаратной платформы;

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

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

♦ требования к технической платформе;

♦ требования к общесистемному программному обеспечению;

♦ требования к телекоммуникационному обеспечению;

♦ возможности по обеспечению информационной безопасности;

♦ количество мест установки пользовательских приложений.

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

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

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

В частности, если заказчиком ставится задача «сквозного» моделирования с последующей автоматизацией тех или иных функций, то вполне очевидно, что при наличии двух объектов моделирования (бизнес-логики деятельности организации и функционирования информационной системы) целесообразно использовать как минимум два класса средств:

♦ программные средства моделирования (формализации), нацеленные на общее описание бизнес-процессов;

♦ программные средства моделирования (формализации), нацеленные на разработку автоматизированных информационных систем.

Аналогичная ситуация сложилась и при необходимости использования нескольких разнопрофильных средств моделирования при исследовании различных сторон одного и того же объекта. Например, при постановке задачи анализа структуры и поведенческой (динамической) составляющей моделируемого объекта должно быть предусмотрено использование как минимум двух классов программных средств (модулей):

♦ средств формализованного описания статической структуры бизнес-процесса;

♦ средств динамического анализа (имитационного моделирования).

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

Принципиальное значение для определения архитектуры среды моделирования бизнес-процессов имеет общая стратегия предприятия в части создания прикладных программных средств. В общем случае существуют две ключевые стратегии в части создания прикладного ПО:

♦ опора на заказные разработки;

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

Разумеется, возможен и промежуточный вариант, предусматривающий сочетание двух вышеуказанных стратегий.

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

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

Современные взгляды на построение АИС предусматривают приоритетную реализацию стратегии использования промышленно поддерживаемых технологий. Основные издержки и риски создания заказных разработок в области моделирования бизнес-процессов связаны с:

♦ низким уровнем прогнозирования сроков завершения работ по созданию самописных скриптов;

♦ вероятностью наличия скрытых ошибок в ПО;

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

♦ высокой зависимостью от разработчика;

♦ недостаточной полнотой документирования разработки;

♦ трудно прогнозируемыми затратами на документирование, тестирование, обеспечение качества и т. д.;

♦ возможностью срыва сроков построения модели;

♦ сложно прогнозируемым уровнем технической поддержки и т. д.

Риски и издержки, связанные с использованием промышленно поддерживаемых программных средств моделирования, могут заключаться в следующем:

♦ неполнота функционала для учета специфики постановки задач;

♦ необходимость проведения доработок для интеграции с существующими информационными системами;

♦ избыточность функционала, что усложняет работу пользователей;

♦ затраты на техническую поддержку;

♦ диктат производителя в части апгрейда версий ПО;

♦ недостаточная гибкость;

♦ возможность ухода с рынка производителя ПО и соответственно возможность потери технической поддержки и восстановление заказчиком утерянных дистрибутивов и т. д.

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

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

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

Общим принципом является обеспечение организационно-технологической готовности предприятия к «приему» специализированного программного обеспечения. Данная готовность определяется следующим перечнем условий:

♦ детальный уровень проработки постановок актуальных задач по созданию моделей и установленное соответствие со спецификацией закупок ПО;

♦ соответствие характеристик программно-технической платформы требованиям планируемых к покупке программных средств, поддержки процесса моделирования;

♦ достаточность компетенций технического персонала;

♦ достаточность уровня подготовки пользователей;

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

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