скрипт выполняет формирования в формате Excel четырех рабочих листов специальной структуры, «понятной» программе-приемнику. Для формирования 1-го листа скрипт «проходит» по модели, формируя для каждой посещенной функции данные в следующем формате – «ID», «Функция», «Длительность», «Предшественник», «Уровень структуры». На 2-м листе должны формироваться данные по исполнителям. На 3-м листе должны формироваться данные по загрузке исполнителей. На 4-листе должна присутствовать идентификационная информация MSProject. Она формируется предварительно и добавляется в выходной файл, созданный скриптом «вручную»;
ассоциированные модели преобразуются в «вехи» MSProject (веха не имеет длительности и ресурсов).
В рамках аналогичного подхода (предложенной технологической схемы) могут быть реализованы задачи по временной и стоимостной оценке бизнес-процессов с использованием функциональных возможностей MSProject, а именно:
определение критического пути;
выработка рекомендаций по оптимизации загрузки персонала.
Достаточно интересным может быть интеграционное решение, которое, в отличие от вышерассмотренного случая, направлено не на дополнение функциональных возможностей ARIS за счет MSProject, а наоборот – на использование ARIS для решения целевых задач MSProject.
Заключение
Общая задача, которая ставилась авторским коллективом перед написанием книги, – аргументированно показать, с одной стороны, актуальность и эффективность внедрения механизмов описания бизнес-процессов в деятельность организации в современных условиях, а с другой – сложность процесса построения действительно полезных для практики бизнес-моделей.
Достаточно затруднительно дать собственную оценку того, насколько убедительна была аргументация необходимости и неизбежности вхождения моделирования бизнес-архитектуры в «культуру управления» предприятий, стремящихся максимально соответствовать современным международным стандартам. Вместе с тем хотелось бы отметить тот факт, что за период работы над книгой члены авторского коллектива неоднократно привлекались к исполнению нескольких проектов по бизнес-моделированию со стороны различных государственных и коммерческих структур. Кроме того, состоялось большое количество контактов с заинтересованными заказчиками, которые в силу текущих организационных и финансовых ограничений не смогли обеспечить старт проекта в текущем периоде.
Особо следует отметить, что данные события были не только «спровоцированы» активностями потенциальных исполнителей по ознакомлению с возможностями и ожидаемыми результатами по разработке бизнес-моделей по внедрению в деятельность организации, но и имели независимые причины, обусловленные повышенным интересом рынка к данному виду услуг.
В той же мере авторскому коллективу затруднительно оценить, насколько полно нашла отражение в книге сложность процесса построения реально востребованных бизнес-моделей. Так или иначе, в заключение хотелось бы еще раз подчеркнуть организационную и технологическую проблематику создания моделей.
Можно взять на себя смелость утверждать, что из всех консалтинговых проектов, в том числе ИТ-направления, бизнес-моделирование является лидером по таким параметрам, как:
значительное количество разнородных специалистов, роль каждого из которых имеет критичное значение для успеха проекта: юристы, производственные технологи, кадровые сотрудники, ИТ-специалисты и т. д.;
обширный состав заинтересованных подразделений заказчика, которые являются потенциальными пользователями системы;
необходимость поддержки в актуальном состоянии разработанной бизнес-архитектуры.
По этой причине организационные проблемы, включающие подбор компетенций, распределений ролей по проекту, планирование активностей, то есть управление проектом, во многих случаях могут стать основной причиной неудач и снивелировать высокие технологические возможности недостаточно подготовленного в организационном аспекте исполнителя.
В этой же плоскости организационных проблем лежит и четкая постановка задач, увязанная с готовностью заинтересованных подразделений заказчика обеспечить синхронную работу по проекту.
Технологическая проблематика связана с тем, что далеко не всегда декларируемые производителями возможности инструментальных средств могут быть реализованы на практике. Как правило, работы по каждому конкретному проекту требуют учета специфических условий и требований заказчика: постановок задач, реализации функционала, интеграции (взаимодействия) с информационными системами и т. д. По совокупности воздействия этих факторов исполнитель сталкивается с необходимостью «ручной» доработки используемой инструментальной базы, задействования и интеграции в общее решение других инструментальных средств, в которых тот или иной функционал реализуется более эффективно.