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

Зуева А. Г.

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

Определение значимого уровня детализации должно осуществляться в ходе формирования требований заказчика и требований на разработку (С– и D-требований), как это делается стандартным образом при создании программных продуктов [18]. Зафиксированный уровень детализации описания бизнес-процессов должен

быть отражен в Соглашении о моделировании, типовая структура которого представлена в приложении.

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

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

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

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

1) разработки модели «как есть»;

2) разработки модели «как должно быть» на ближнюю и дальнюю перспективу;

3) проведение сравнительного анализа (Gap-анализа) моделей «как есть» и «как должно быть» и выработка плана перехода (плана мероприятий) по организационно-технологическим изменениям организации.

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

В проектах, ориентированных на реализацию трех вышеуказанных

фаз, главная цель работ по модели «как есть» состоит в:

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

разработке проектных решений для построения модели бизнес-архитектуры;

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

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

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

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

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

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

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