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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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