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