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

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

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

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

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

уровень ее совместимости со старой средой моделирования;

уровень «похожести» интерфейса с заменяемой платформой;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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