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

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

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

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

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

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

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

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

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

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

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

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

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

♦кто будет следить за всеми изменениями (существенными для модели) в деятельности организации;

♦кто будет вносить изменения в модель в соответствии с изменениями в деятельности организации;

♦как будут осуществляться подготовка и переподготовка (обучение) персонала – пользователей и технического персонала.

Риски в данной области могут быть связаны с:

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

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