Глава 7

Чего нужно опасаться при моделировании бизнес-процессов. Проектные риски моделирования бизнеспроцессов

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

¦ длительность и сложность согласования постановок задач;

¦ обеспечение совместной работы большой группы разнородных участников;

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

¦ обеспечение высоких требований по актуализации модели и т. д.

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

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

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

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

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

а) не в полной мере удовлетворяются требования модели к объему исходных данных;

б) отдельные положения имеют неоднозначную трактовку;

в) существует логическая конфликтность между различными документами;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¦ практического опыта;

¦ методических наработок и т. д.

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

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

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

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

Такие факторы характерны для крупных территориально распределенных организаций. Очевидно, что исполнителю обеспечить одновременный учет этих особенностей крайне сложно. Тем более что получение оценок по функциональным и стоимостным характеристикам людских и технологических ресурсов может потребовать не только выхода за рамки проекта (ресурсные и временные), но и наличия компетенций у исполнителей, изначально подобранных под задачи проекта. Так, оценка временных и стоимостных АИС, задействуемых в бизнес-процессах, может потребовать использования методик ТСО и соответствующих для них специалистов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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