пересмотр качества и полноты результатов работ, либо проведение дополнительных экспертиз и презентаций по реализованным этапам проекта;

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

изменение порядка исполнения, включая корректировку приоритетов;

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

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

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

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

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

усложнится процесс развития модели вследствие наличия «барьеров» потенциально заинтересованных пользователей, работающих в «стандартной» среде;

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

инициируется процесс дополнительной идентификации компонент модели и т. д.

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

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

неполнота и некорректная реализация заявляемого функционала;

отсутствие возможности эффективного развития модели.

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

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

Типичные проектные ошибки в отношении проектирования модели бизнес-архитектуры предприятия могут быть связаны с:

неполнотой охвата состава бизнес-процессов;

недостаточным уровнем детализации;

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

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

неправильным отражением логики бизнес-процессов;

неправильным (неоптимальным) отражением окружения бизнес-функций;

«недружелюбностью» интерфейса и т. д.

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

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

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

нагрузочное решение при работе в многопользовательском режиме;

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

различные сочетания использования разработанного прикладного функционала.

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