Е. Всяких - Практика и проблематика моделирования бизнес-процессов
Схожими по своей природе с «неучетом» существующего лингвистического обеспечения являются проблемы наличия ошибок в проектировании системы «модель бизнес-архитектуры предприятия». Данные ошибки можно условно разделить на две категории:
♦ неполнота и некорректная реализация заявляемого функционала;
♦ отсутствие возможности эффективного развития модели.
Часть оценок в отношении проектных ошибок может носить субъективный характер со стороны заказчика. Такого рода субъективные ошибки могут быть связаны с «личностной» интерпретацией представителями заказчика рамок технического задания (ТЗ) на разработку. Безусловно, может быть и объективная природа у проектных ошибок.
Одним из условий минимизации потенциальных претензий заказчика к качеству проектирования модели является изначальная ориентация исполнителя на потенциально высокую частоту изменений, которые должны будут вноситься в модель. Данные изменения могут быть связаны как с выявлением некорректности представления бизнес-процессов, так и с необходимостью учета изменений в деятельности организации.
Типичные проектные ошибки в отношении проектирования модели бизнес-архитектуры предприятия могут быть связаны с:
♦ неполнотой охвата состава бизнес-процессов;
♦ недостаточным уровнем детализации;
♦ недостаточным уровнем чувствительности моделей;
♦ неполнотой функциональных средств анализа и построения отчетов;
♦ неправильным отражением логики бизнес-процессов;
♦ неправильным (неоптимальным) отражением окружения бизнес-функций;
♦ «недружелюбностью» интерфейса и т. д.
Соответственно, в зависимости от выбранной архитектуры построения выявляемые ошибки могут классифицироваться как быстро устраняемые, равно как и долго устраняемые.
Одним из основных способов предупреждения подобного рода рисков является качественная разработка Соглашения по моделированию и технического задания с последующим утверждением данного Соглашения и заказчиком, и исполнителем.
Особую опасность вызывают проектные ошибки и корректность отображения логики бизнес-процессов. В первую очередь данная опасность связана с неопределенностью периода их выявления в условиях большого количества входных ситуаций, которые должны отрабатываться моделью. Для минимизации рисков применительно к созданию сложной модели с большим количеством пользователей необходимо в обязательном порядке создавать специализированные средства тестирования, которые обеспечивают:
♦ нагрузочное решение при работе в многопользовательском режиме;
♦ «прогон» модели по максимально возможному количеству входных ситуаций (желателен перебор всех ситуаций);
♦ различные сочетания использования разработанного прикладного функционала.
Постановка и контроль выполнения задачи по формированию специализированных средств тестирования должны исходить от заказчика либо «ответственного» исполнителя. При этом необходимо обязательное согласование между заказчиком и исполнителем объема и формы осуществления тестирования.
Отдельного упоминания заслуживают риски, связанные с таким феноменом, как «паралич» детализации. Желание сразу охватить все бизнес-процессы с максимально возможной подробностью может сыграть злую шутку как с исполнителем, так и с заказчиком. Слишком детальная и слишком чувствительная модель может оказаться очень дорогой и непрактичной. Дорогой – поскольку потребует значительных ресурсов не только на свою реализацию, но и на поддержку. Непрактичной – потому что будет реагировать на непринципиальные изменения, отвлекая внимание и создавая угрозу пропуска (неучета) действительно важных событий.
Задание избыточного уровня детализации, по сути дела, приводит к распылению ресурсов со стороны как заказчика, так и исполнителя. Происходит втягивание в нескончаемый процесс получения исходных данных, которые сложно добыть и оценить, согласования и уточнения многоаспектной и изменчивой картины моделируемых бизнес-процессов.
Подобные ошибки нельзя допускать как для всей модели бизнес-архитектуры, так и для отдельных моделируемых бизнес-процессов. В единой модели бизнес-архитектуры необходимо поддерживать единый уровень детализации, в противном случае могут возникнуть не только вопросы организационного плана – почему одни бизнес-процессы промоделированы более точно, но и вопросы последующей интеграции бизнес-процессов в общую модель.
В качестве первопричин «паралича» детальности моделирования может выступить попытка единовременного «глобального» охвата бизнес-процессов. Правильным решением является выбор на начальном этапе нескольких (далеко не всех) основных бизнес-процессов, с соответствующей локализацией заинтересованных подразделений заказчика. При этом обеспечивающие бизнес-процессы, с которыми осуществляется взаимодействие выбранных основных процессов, моделируются с таким уровнем детализации, который достаточен для отражения взаимодействия.
Другой крайностью, противоположной «параличу» детализации, является «завышенный» уровень абстракции бизнес-моделей. При неконтролируемом неучете (игнорировании) несущественных деталей появляется высокая вероятность получения такой «универсальной» модели, которая может давать только общие, а не конкретные ответы на практически значимые вопросы. Подобная ситуация может возникнуть, когда, двигаясь «сверху вниз» при построении модели, не хватает ресурса либо исходных данных перейти от высоких уровней детализации на более низкие.
Одним из противодействий таких рисков, связанных с некорректным определением точности описания, является фиксация потребительски значимого для заказчика уровня детализации, при котором модель бизнес-архитектуры действительно может стать действенным информационно-консультационным инструментом по мониторингу и анализу деятельности организации.
Определение значимого уровня детализации должно осуществляться в ходе формирования требований заказчика и требований на разработку (С– и D-требований), как это делается стандартным образом при создании программных продуктов [18]. Зафиксированный уровень детализации описания бизнес-процессов должен быть отражен в Соглашении о моделировании, типовая структура которого представлена в приложении.
Помимо ошибок в определении разумного и достижимого в рамках проекта уровня детализации, риски технологических решений могут быть обусловлены неэффективностью разработанных вариантов интеграции различных компонент модели в условиях, когда на предприятии уже существуют определенные наработки по моделированию по частным задачам.
По факту существует множество возможных моделей для описания деятельности предприятия как системы, и очень часто в организации происходит достаточно разрозненный процесс моделирования. В условиях отсутствия в организации корпоративных стандартов на использование инструментальных средств каждое из подразделений реализует свой выбор. При этом в рамках используемой среды формируются значимые информационные ресурсы, аккумулирующие знания по различным аспектам деятельности организации. Причем конвертация этих ресурсов в какую-либо новую среду далеко не всегда является простой задачей, а формирование данных ресурсов в новой среде моделирования, при условии что они формировались на протяжении длительного периода для ограниченного по срокам и бюджетам проекта, может быть неприемлемо.
По этой причине консолидация различных представлений и многочисленных моделей в рамках единой модели бизнес-архитектуры является весьма сложной задачей. Эта проблема может существенно снизить функциональные возможности создаваемой модели, равно как и сузить круг потенциальных пользователей. Минимизация такого риска лежит в плоскости тщательной проработки методических аспектов, касающихся логической организации различных моделей, используемых при построении единой модели бизнес-архитектуры.
Еще одной часто встречаемой ошибкой при реализации проектов по моделированию бизнес-процессов является неправильное распределение временных и исполнительных ресурсов по этапности создания модели. Это связано либо с незнанием, либо с игнорированием базовой последовательности мероприятий по разработке модели бизнес-архитектуры:
1) разработки модели «как есть»;
2) разработки модели «как должно быть» на ближнюю и дальнюю перспективу;
3) проведение сравнительного анализа (Gap-анализа) моделей «как есть» и «как должно быть» и выработка плана перехода (плана мероприятий) по организационно-технологическим изменениям организации.
В ряде случаев происходит «забывание» 2-го и 3-го пунктов либо неоправданно малое выделение на них ресурсов. Как правило, инициирование работ по созданию модели бизнес-архитектуры связано с желанием организации осуществить оптимизационные мероприятия в своей деятельности. Это уже предполагает, что существующая организация бизнес-процессов будет меняться. Если к этому добавляются обстоятельства, связанные с недостаточно управляемыми текущими активными изменениями, обусловленными высокой динамикой развития рынка, то значительные вложения в детальное описание текущей бизнес-архитектуры вряд ли можно считать оправданными.
