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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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