«Практика и проблематика моделирования бизнес-процессов»

А. Г. Зуева, Б. В. Носков, Е. В. Сидоренко, Е. И. Всяких, С. П. Киселев Практика и проблематика моделирования бизнес-процессов

Введение

В настоящее время государственные и негосударственные организации Российской Федерации начинают активно реализовывать проекты по созданию бизнес-моделей. Данная активность не является данью некой новой «технологической» моде – для нее существуют вполне объяснимые причины, связанные с действием совокупности объективных экономических и организационно-правовых факторов. Во-первых, наличие документированной бизнес-архитектуры предприятия является обязательным условием его сертификации как по международным стандартам ISO 9001:2000, так и по российским ГОСТ Р ИСО 9001–2001. Более того, в настоящее время в ряде развитых зарубежных стран приняты стандарты, определяющие требования к структуре и порядку построения бизнес-архитектуры. Во-вторых, в условиях все возрастающих инвестиций в информационно-технологическую инфраструктуру организации предварительное моделирование ожидаемых изменений в бизнес-процессах и оценки эффектов является одним из основных инструментов обоснования и оптимизации расходов на модернизацию.

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

♦ увеличение доли федеральных органов государственной власти, выполнивших описание и оптимизацию административно-управленческих процессов, с 7 % до 60 %;

♦ увеличение доли органов государственной власти субъектов Российской Федерации, выполнивших описание и оптимизацию административно-управленческих процессов, с 5 % до 50 %.

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

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

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

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

Архитектура предприятий по своей сути является некоторым механизмом, который обеспечивает прозрачность представления, «трансформацию» «стандарных» услуг (деятельности) правительства в электронные регламенты, основанные на использовании современных ИТ. В каждой из стран существует своя специфика в организации, наименовании и стандартизации проектов по созданию электронного правительства. Например, в США реализуется проект «Федеральная архитектура», в Германии – «Стандарты и архитектура прикладных систем электронного правительства» (SAGA – Standards and Architecture for e-Government Applications). Однако при всем многообразии специфик реализации основной лейтмотив заключается в процессном подходе организации деятельности государства по предоставлению на современной технологической основе услуг гражданам и бизнесу. Соответственно, проектирование национальной инфраструктуры государственных информационных систем осуществляется в контексте обеспечения эффективной реализации государственных функций.

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

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

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

В качестве примера можно привести один из результатов такой разобщенности, озвученный бывшим министром обороны США Дональдом Рамсфельдом: «Наличие 673 различных и нескоординированных систем финансового учета сделало невозможным найти следы транзакций на общую сумму в 2,3 млрд долларов» [2].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке.

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

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

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

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

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

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

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

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

Глава 1 Зачем нужна модель бизнес-архитектуры: стандартные постановки задач по моделированию бизнес-процессов

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

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

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

При самом общем подходе эффекты от создания модели бизнес-архитектуры нужно позиционировать с повышением уровня общей управляемости предприятия. Применительно к ИТ-компоненте архитектуры предприятия мировая практика свидетельствует о возможности снижения расходов на одного сотрудника до 30 %, в то же время отсутствие задокументированной ИТ-архитектуры влечет за собой дополнительные расходы до 12–18 % по ряду эксплуатационных направлений [4].

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

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

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

Зачастую стандартные ответы на эти вопросы связаны с упором на оптимизацию бизнес-процессов организации и, соответственно, перечислением «базового набора» параметров оптимизации:

♦ дублирование функций;

♦ узкие места;

♦ затратные центры;

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

♦ избыточные операции;

♦ возможности автоматизации;

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

♦ возможности сертификации по ISO 900х.

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

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

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

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

♦ формализация и документирование информации (знаний) об организации.

Очевидно, что вне зависимости от целей оптимизации качественное накопление, структурирование и формализация информации (знаний) очень важны с точки зрения:

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

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

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

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

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

♦ цели;

♦ задачи;

♦ показатели эффективности;

♦ регламенты (инструкции, приказы и т. п.) бизнес-процессов.

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

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

♦ систематизация и документирование (формализация) информации (знаний), значимой для деятельности, что обеспечивает:

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

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

Рис. 1. Проблематика управления знаниями в организации в части бизнес-процессов

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

Рис. 2. Перспективные решения по использованию знаний о бизнес-процессах при принятии управленческих решений

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

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

а) ISO 15704 – стандарт по формальному описанию архитектуры предприятия, который был предложен рабочей группой IFAC/IFIP (International Federation of Automatic Control/International Federation for Information Processing);

б) ISO 15288 – стандарт, определяющий жизненный цикл системы;

в) ISO 12207 – стандарт, определяющий жизненный цикл программного обеспечения.

Существует более 30 дополнительных «поддерживающих» стандартов системной и программной инженерии (например, ISO 14258, определяющий концепции и правила моделирования предприятия).

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

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

Постановки задач по моделированию бизнес-архитектуры в контексте поддержки SOA направлены на обеспечение следующих требований проектирования ИС:

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

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

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

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

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

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

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

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

В подтверждение данных тезисов в отношении роли и места бизнес-моделирования можно привести высказывание аналитика Gartner Джима Синура (Jim Sinur): «На самом деле большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время» [5]. В целом необходимо отметить, что по различным экспертным оценкам большинство предприятий будут вести проекты, которые так или иначе будут затрагивать различные аспекты проблемы совершенствования бизнес-процессов, несмотря на неоднозначные оценки практики реинжиниринга бизнес-процессов середины 1990-х годов.

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

В качестве примера используемой в развитых странах методологии оценки зрелости государственных организаций можно привести модель Финансово-контрольного управления США [6], которая определяет пять уровней зрелости.

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

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

Очевидно, что постановки задач по моделированию для производственной (коммерческой) организации существенно могут отличаться от задач государственного контрольного (надзорного) органа. По этой причине, безусловно, необходима специфическая настройка каждой из методик высокого уровня под область моделирования. На эту потребность вполне адекватно реагирует рынок консалтинговых услуг. Так, в настоящее время есть практически значимые модели для различных отраслей экономики и госструктур, которые реализованы на основе разных методологий и инструментальных средств моделирования, таких как методология ARIS и базирующееся на ней семейство программных продуктов компании IDS Sheer AG, язык моделирования UML и средство разработки объектно-ориентированных информационных систем Rational Rose компании IBM, методология IDEF, DFD и продукт AllFusion Modeling Suite (ранее BPwin и ERwin) компании Computer Associates и др.

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

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

Состояние формализации и на ее основе оптимизации административно– управленческих процессов ОГВ определено в документе «Стратегия развития и использования информационных и коммуникационных технологий в Российской Федерации» в качестве основных показателей планируемых мероприятий. Приведенная ниже таблица отражает текущее состояние, перспективы и государственную политику по внедрению бизнес-моделирования в деятельность ОГВ РФ [7] (табл. 1).

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

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

♦ внедряются электронные административные регламенты;

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

♦ оптимизируется организационная структура.

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

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

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

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

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

♦ разработчики информационных и технологических систем;

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

♦ бизнес-аналитики, которые ведут процесс проектирования организационной структуры;

♦ руководители, заинтересованные в систематическом, структурированном анализе проблем и возможностей, которые открываются перед бизнесом, и т. д.

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

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

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

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

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

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

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

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

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

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

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

1) систематизация и формализация – построение описательных моделей;

2) построение аналитических и оптимизационных моделей.

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

1) качественно-количественная оценка (оптимизация) реализуемых бизнес-процессов;

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

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

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

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

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

♦ Какие интегральные стоимостные и временные затраты требуются для реализации конкретного бизнес-процесса (подпроцесса)?

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

♦ Какая динамика использования организационных, технологических и информационных ресурсов необходима для выполнения конкретного бизнес-процесса?

♦ Какие ресурсы (организационные, технологические и информационные) или регламенты являются основными ограничивающими факторами для расширения возможностей организации по увеличению качественно-количественных характеристик решаемых бизнес-задач?

♦ Какие операции (должностные функции) закреплены за конкретной должностной единицей в рамках осуществления целевой деятельности организации?

♦ Какой перечень операций (технологическая карта) должен выполняться должностной единицей при наступлении конкретной стандартной или нестандартной ситуации, связанной с осуществлением целевой деятельности организации?

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

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

♦ определение этапности;

♦ определение ролей в проекте;

♦ формирование и управление в проектной команде и т. д.

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

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

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

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

Усилия по построению бизнес-архитектуры, которая представляется в виде бизнес-моделей, быстро окупают себя и имеют большое количество дополнительных преимуществ [8]. Преимущества от построения модели бизнес-архитектуры моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса могут дать до 10 % экономии. А при моделировании альтернативных вариантов бизнес-процессов организации могут сэкономить до 20 % [4].

Глава 2 Что такое модель бизнес-процессов. Типовая архитектура модели бизнес-процессов

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

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

В качестве примера можно привести несколько определений понятия «архитектура предприятия».

Вот как определяется данное понятие в документах Финансово-контрольного управления США [9]:

«Архитектура предприятия описывает деятельность организации с двух позиций:

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

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

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

Можно привести другое определение архитектуры предприятия, которое дано на сайте Всемирной организации корпоративной архитектуры» (GEAO – Global Enterprise Architecture Organization): «Архитектура предприятия описывает те способы, с помощью которых общее видение деятельности организации отражено в структуре и динамике предприятия. На различных уровнях абстракции она дает единый набор моделей, принципов, руководств и политик, которые используются для создания, развития и обеспечения соответствия систем в масштабе и контексте деятельности всего предприятия в целом».

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

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

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

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

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

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

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

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

а) оценку влияния компонента на процесс;

б) взаимосвязь с другими компонентами и интеграцию в целевой бизнес-процесс.

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

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

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

Контекст и основные элементы бизнес-архитектуры

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

Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры ИТ-приложений, которые обеспечивают автоматизированную поддержку этих процессов. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer Арр [11]: «Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты и где начинаются технологии».

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

♦ используемые данные (что?);

♦ процессы и функции (как?);

♦ места выполнения этих процессов (где?);

♦ организации, персоналии-участники, системы (кто?);

♦ управляющие события (когда?);

♦ цели и ограничения, определяющие работу системы (зачем?).

В рамках модели бизнес-архитектуры выделяются следующие основные компоненты:

1) бизнес-процессы / цели и стратегия построения бизнеса;

2) организационная компонента / организационное окружение;

3) информация / информационное окружение;

4) приложения / обеспечивающее окружение.

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

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

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

Можно привести следующие определения по целевым постановкам задач для бизнес-архитектуры: «Если архитектура ИТ-предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно так же бизнес-архитектура описывает, как элементы бизнеса соединены вместе» [12].

Бизнес-архитектура включает в себя, как правило, следующие аспекты:

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

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

♦ показатели результативности. Этот аспект состоит в определении ключевых показателей результативности (КПР) работы организации, их текущих и желаемых уровней. Модель КПР используется как средство мониторинга исполнения бизнес-процессов. Для определения показателей результативности работы организации применяются различные методики, например широкую популярность завоевала методика Роберта Каплана и Дейвида Нортона «Balanced Score Card (BSC)». BSC представляет собой систему, основанную на причинно-следственных связях между стратегическими целями, отражающими их параметрами и факторами получения планируемых результатов. Она рассматривает четыре проекции: финансовую, взаимоотношения с потребителями, операционной эффективности и человеческого потенциала организации, цели и задачи которых взаимосвязаны и отражены финансовыми и нефинансовыми показателями.

Структура организационной компоненты

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

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

Структура информационной компоненты

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

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

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

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

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

Организация компоненты «Приложения»

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

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

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

Базовые принципы, методы и определения моделирования бизнес-процессов

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

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

Определение моделирования

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

Определение по ISO-15704 Моделирование – абстрактное представление реальности в какой-либо форме (например, в математической, физической, символической, графической или дескриптивной), предназначенное для представления определенных аспектов этой реальности и позволяющее отвечать на рассматриваемые вопросы.

Типология моделей

В общем, модели можно классифицировать по различным критериям, например:

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

♦ количественные – позволяющие производить численные оценки и проверки, и качественные – предназначенные для понимания поведения и структуры системы;

♦ описательные – предназначенные только для восприятия человеком, или исполняемые – позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходном объекте.

Примерами качественных и описательных моделей являются:

♦ текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст;

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

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

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

Общие принципы моделирования

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

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

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

В данном случае закладываются условия для выполнения такого значимого требования, как адекватность модели, а именно достижение разумного баланса между детальностью и потребительскими качествами модели.

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

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

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

Этот прием используется при определении границ области моделирования и при расстановке приоритетов внутри нее, он позволяет сократить объем и продолжительность моделирования, однако может негативно сказаться на адекватности модели.

Базовые определения по архитектуре

В качестве общих элементов определений, связанных с архитектурой, можно использовать следующий перечень [7]:

♦ архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т. д.);

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

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

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

♦ каждая система имеет архитектуру, даже система, которая состоит из одной компоненты;

♦ архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;

♦ определения архитектуры не содержат описания самих компонент.

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

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

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

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

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

♦ архитектура должна быть расширяемой, масштабируемой и адаптивной;

♦ архитектура должна быть инструментом реализации изменений;

♦ архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов;

♦ тенденции рынка должны учитываться при проектировании технологической архитектуры.

Объектный анализ

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

В качестве объектов предметной области могут рассматриваться конкретные предметы или реальные сущности, например клиент, заказ, изделия, документ и т. п. (рис. 3).

При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются действия, и активные объекты (организационные единицы, конкретные исполнители, программное обеспечение), которые осуществляют действия.

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

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

♦ функций, уровень их типизации, уровень автоматизации;

♦ документооборота;

♦ организационных единиц, должностей, ролей;

♦ информационных и технических средств.

Процессный анализ

Понятие процесса

Процессный анализ предполагает исследование одного или множества бизнес-процессов организации в целом.

Варианты определения процесса следующие.

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

♦ Процесс – это поток работы, проходящий от одного специалиста к другому или от одного отдела к другому (в зависимости от уровня рассмотрения).

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

♦ Процесс – это взаимонезависимый компонент производственной системы, преобразующий вход в один или несколько выходов в соответствии с предварительно установленными правилами.

♦ Процесс – это связанный набор повторяемых действий (функций), которые преобразуют исходный материал и/или информацию в конечный продукт (услугу) в соответствии с определенными критериями.

Процессный подход к моделированию позволяет:

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

♦ выделить и использовать процессы в качестве объектов управления (раньше управляли функциями, выполняемыми тем или иным подразделением);

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

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

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

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

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

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

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

Компоненты процесса

Для задания процесса необходимо определить:

♦ название (определение) процесса;

♦ реализуемую функцию или их последовательность;

♦ участников процесса;

♦ ответственное лицо – владельца процесса;

♦ границы процесса;

♦ входные и выходные потоки, а также их поставщиков (или потребителей);

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

♦ определяющую цель (цели) процесса;

♦ метрики процесса, точки и процедуры мониторинга процесса;

♦ возможные риски и влияния процесса на субъекты процесса.

Входные потоки – материалы, услуги и/или информация, преобразуемые процессом для создания выходных потоков.

Выходные потоки – результат преобразования входных потоков.

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

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

Исходя из вышеизложенного, выделяются основные составляющие модели бизнес-процесса, участвующие в ее построении:

♦ функции (действия, выполняемые участниками процесса);

♦ ресурсы (производственные, технические, материальные, системные);

♦ документы и данные (как преобразуемые в процессе, то есть входной/ выходной поток, так и непреобразуемые, то есть как ресурс);

♦ участники процесса (трудовые ресурсы);

♦ материалы/продукты, услуги (как преобразуемые в процессе, то есть входной/выходной поток).

Анализ процесса

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

♦ анализ топологии процесса;

♦ анализ характеристик процесса;

♦ анализ ошибок процесса;

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

♦ анализ рисков процесса;

♦ анализ ресурсного окружения процесса;

♦ анализ возможностей стандартизации процесса (создание эталонных, референтных моделей).

Анализ топологии процесса

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

Анализ характеристик процесса

Этапы анализа характеристик:

1) определение основных характеристик (показателей) процесса;

2) определение метрик характеристик для их оценки;

3) мониторинг метрик характеристик процесса.

Основными характеристиками процесса являются следующие показатели:

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

♦ определенность – отражает степень, с которой реальный процесс соответствует описанию;

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

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

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

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

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

Примеры метрик характеристик процесса:

♦ отношение фактического времени выполнения процесса к плановому времени выполнения;

♦ степень автоматизации по количеству функций (количество функций с возможностью автоматизации / общее количество функций процесса);

♦ степень автоматизации по времени (суммарное время автоматизированных работ / суммарное время выполнения всех работ);

♦ отношение суммарного времени выполнения функций процесса к суммарному времени ожидания;

♦ отношение суммарного времени выполнения функций-интерфейсов взаимодействия с другими процессами к суммарному времени ожидания.

Анализ ошибок процесса

Этапы анализа ошибок процесса:

1) классификация возможных ошибок процесса;

2) описание ошибок процесса;

3) выявление ошибок в процессе.

Возможные ошибки, которые могут возникать при моделировании бизнес-процессов:

♦ незавершенность. Наличие пробелов в описании процесса, например отсутствие подпроцесса, процедуры или информационного ресурса;

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

♦ иерархическая несовместимость. Несовместимость процесса с подпроцессами, его составляющими;

♦ «наследственная» несовместимость. Наличие конфликта между основными и последующими процессами.

Анализ динамики процессов

Динамика процессов исследуется с помощью динамической (имитационной) модели.

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

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

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

Анализ рисков процесса

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

Операционный риск критичен для тех процессов, которые характеризуются:

♦ значимостью для деятельности организации в целом;

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

♦ сложной системой технической поддержки.

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

Этапы анализа рисков процесса:

1) структуризация рисков;

2) описание рисков и процессов, их предотвращающих;

3) определение рисков в бизнес-процессах.

Анализ ресурсного окружения процессов

Основу процесса составляют выполняемые функции. Для выполнения каждой из функций требуются ресурсы:

♦ людские – участники процесса (кто выполняет);

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

♦ материальные – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет);

♦ информационные – данные, документы, информация (на основании чего выполняет);

♦ интеллектуальные – знания и полномочия участников и владельца процесса.

Все эти ресурсы должны быть определены и описаны для каждой функции, выполняемой в процессе.

Например, операционное окружение таможенных процессов включает:

♦ организационное наполнение (перечень исполнителей на уровне должностных лиц и подразделений, участвующих в процессе);

♦ системное наполнение (перечень информационных и технических систем, используемых в процессе);

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

♦ информационное наполнение (перечень документов и данных разного типа, используемых в процессе).

Анализ возможностей стандартизации процесса (создание эталонных, референтных моделей)

Эталоны могут служить базовыми критериями для инжиниринга бизнес-процессов. Сопоставление собственного бизнес-процесса с аналогичным процессом, взятым за образец, позволяет получить целевые, или ориентировочные, показатели. Такая процедура называется эталонным сравнением. Расхождение между характеристиками эталонного процесса и собственными показателями может подсказать, как лучше организовать у себя бизнес-процессы. Целевыми критериями при эталонном сравнении могут выступать финансовые, временные или совокупные показатели, например стоимость процесса, пропускная способность или величина входа/выхода, хотя немаловажное значение имеют и более субъективные характеристики, связанные со степенью удовлетворенности клиентов. Концепция эталонного сравнения не нова, но она всегда позволяет по-новому подойти к совершенствованию бизнес-процесса и необходимому для него сокращению времени.

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

Основные методики моделирования

Необходимо отметить, что постановка задачи по построению модели объекта определяется фиксированием ряда таких составляющих, как:

♦ используемые методики проектирования моделей;

♦ формализация (нотация);

♦ лингвистическое обеспечение (система классификации и кодирования).

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

♦ методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, МЕТА Group и др.;

♦ модель Захмана;

♦ методика TOGAF;

♦ методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная архитектура госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве обороны США DoDAF (Department of Defence Architecture Framework).

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

♦ описание методов проектирования архитектуры в терминах использования определенных «строительных блоков»;

♦ описание того, как эти «строительные блоки» связаны между собой;

♦ набор инструментов для описания элементов архитектуры;

♦ общий словарь используемых терминов.

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

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

Разработка одних методик была инициирована государственными структурами, других – частным сектором и представителями индустрии.

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

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

Определение модели согласно Захману (Zachman Framework for Enterprise Architecture). Модель представляет собой общий словарь, набор перспектив или структур для описания современных сложных, корпоративных систем и преследует две основные цели: с одной стороны, логическое разбиение поставленной задачи на отдельные блоки для упрощения формирования и восприятия итогового решения, с другой – обеспечение возможности рассмотрения целостной архитектуры решения с выделенных точек зрения или соответствующих уровней абстракции.

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

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

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

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

На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.

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

Основные правила заполнения таблицы следующие:

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

♦ порядок следования колонок несуществен;

♦ каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);

♦ базовые модели для каждой из колонок являются уникальными;

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

♦ заполнение клеток должно проводиться последовательно «сверху вниз», попытка пропуска одного из рядов нежелательна, так как нельзя создать хорошо работающую систему, «перепрыгнув» определенные уровни ее описания на этапе проектирования.

Модель Gartner выделяет четыре связанных, взаимозависимых и усложняющихся уровня:

♦ Среда бизнес-взаимодействия (Business Relationship Grid);

♦ Бизнес-процессы и стили бизнес-процессов;

♦ Шаблоны;

♦ Технологические строительные блоки (кирпичики – bricks).

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

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

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

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

IDEF-технологии

Первые методы семейства стандартов IDEF (Integrated DEFinition) были разработаны в США в середине 70-х годов по программе Integrated Computer-Aided Manufacturing. В настоящее время данный комплекс стандартов включает в себя методы функционального, информационного, поведенческого моделирования и проектирования, приведенные ниже.

♦ IDEFO (Function Modeling Method) – стандарт функционального моделирования, позволяющий описать бизнес-процесс в виде иерархической системы взаимосвязанных функций (функциональных блоков – в терминах IDEF0).

♦ IDEF1 (Information and Data Modeling Method) – стандарт описания информационных потоков внутри системы, позволяющий отображать и анализировать их структуру и взаимосвязи.

♦ IDEF1X (IDEF1 Extended) – стандарт проектирования реляционных структур, основанный на концепции «сущность – связь» (ER – Entity-Relationship), предложенной в 1976 году сотрудником корпорации IBM Питером Ченом. Применяется для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы и обеспечивающий универсальное представление структуры данных в рамках организации, независимое от конечной реализации базы данных и аппаратной платформы.

♦ IDEF2 (Simulation Modeling Method) – стандарт динамического моделирования развития систем. В связи с весьма серьезными сложностями задачи построения модели динамической системы и ее последующего анализа от использования этого стандарта практически отказались, и его развитие приостановилось еще на начальном этапе. IDEF2 использует модели и методы имитационного моделирования систем массового обслуживания, сети Петри, модель конечного автомата, описывающую поведение системы как последовательность смен состояний.

♦ IDEF3 (Process Flow and Object Stale Description Capture Method) – стандарт документирования процессов, происходящих в системе. Применяется при исследовании, например, технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3.

♦ IDEF4 (Object-oriented Design Method) – стандарт проектирования объектно-ориентированных систем. IDEF4 позволяет наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым давая возможность анализировать и оптимизировать сложные объектно-ориентированные системы.

♦ IDEF5 (Ontology Description Capture Method) – стандарт наглядного и эффективного описания онтологии системы: словаря терминов и определений, используемых при описании характеристик объектов и процессов, имеющих отношение к рассматриваемой системе, и классификации логических взаимосвязей между ними.

♦ IDEF6 (Designed Rational Capture Method) – назначение стандарта состоит в структурировании «знаний о способе» моделирования, их представления и использования при разработке информационных систем. Под «знаниями о способе» понимаются причины, обстоятельства, другие мотивы, которые обусловливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель выглядит таким образом?». Стандарт IDEF6 акцентирует внимание именно на процессе создания модели.

♦ IDEF8 (Human-System Interaction Design) – стандарт описания интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем) и на деталях интерфейса (какие элементы управления предлагает интерфейс для выполнения операции).

♦ IDEF9 (Business Constraint Discovery) – стандарт описания бизнес-ограничений, используется при определении и анализе ограничений, в которых действует организация.

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

Глава 3 Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке

Общий подход к проектированию

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

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

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

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

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

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

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

1. Идентификация критически важных для предприятия процессов (обычно не более восьми). Чаще всего это те ключевые процессы, которые:

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

♦ открывают новые возможности;

♦ в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов, имеют возможности для оптимизации затрат.

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

3. Построение модели высокого уровня для ключевых бизнес-процессов.

4. Определение для каждого шага процесса ответственных за выполнение шага. Это могут быть как внешние организации, так и подразделения компании.

5. Идентифицирование и документирование основных категорий информационных объектов.

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

♦ декомпозиция функций/процессов;

♦ анализ бизнес-событий.

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

1) каковы основные функции организации?

2) какие функции не несут в себе ценности?

3) какие функции пересекаются с другими бизнес-функциями?

Посредством декомпозиции и анализа бизнес-процессов должны быть получены следующие результаты:

♦ основные подпроцессы выбранных ключевых процессов (критически важных для бизнеса);

♦ границы основных организационных единиц;

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

♦ пересечения и излишние функции/процессы;

♦ возможные требования к прикладным системам и информации.

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

1) кто является инициатором бизнес-события?

2) кто является основными участниками события?

3) как событие обрабатывается в рамках «расширенного» предприятия (партнеры и прочее)?

4) возможны ли инновации, которые связаны с событием и требуются бизнесом?

Посредством анализа бизнес-событий должны быть получены следующие результаты:

♦ основные инициаторы и участники бизнес-событий;

♦ партнеры;

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

♦ возможные новые формы ведения бизнеса.

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

♦ моделирование местоположений выполнения функций/процессов;

♦ модель интеграции функций/процессов.

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

1) где выполняются основные функции?

2) какие функции связаны между собой?

3) существуют ли возможности по консолидации и рационализации? В результате мы должны получить:

♦ распределение функций по местоположениям;

♦ связи между бизнес-функциями;

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

♦ возможные требования к организационным изменениям.

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

Результатами ее построения являются:

♦ ключевые внутренние и внешние точки интеграции;

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

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

♦ возможные требования к организационным изменениям.

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

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

1) на что реагирует модель?

2) как реагирует модель?

Определение параметров вариативности модели и ее реализации

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

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

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

♦ изменяется состав подпроцессов (функций, операций), входящих в модель;

♦ изменяется логическая последовательность исполнения подпроцессов (функций, операций), входящих в модель;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применительно к «переборному» и «структурному» подходу построения модели можно определить следующие общие характерные последовательности шагов (табл. 2).

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

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

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

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

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

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

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

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

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

Анализ и оптимизация моделей

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

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

♦ определение характеристик (требований) к основным компонентам модели (организационной, информационной), при которых обеспечивается оптимизация всего бизнес-процесса;

♦ в рамках заданных (зафиксированных) характеристик (требований) к компонентам модели определение вариантов ее оптимизации структуры (внутренних показателей).

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

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

«Глобальная» оптимизация решается на основе процессного подхода, а «локальная» – на основе объектного.

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

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

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

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

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

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

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

♦ механизмы учета состояния (доступности, расхода) ресурсов (организационных, информационных, технических) в ходе реализации соответствующих этапов бизнес-процесса;

♦ механизмы задания входных условий и инициализации бизнес-процесса.

Типичным примером практически значимого отчета, получаемого на основе динамической модели средствами процессного анализа, являются:

♦ временные и стоимостные затраты на реализацию бизнес-процесса под заданные входные условия;

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

♦ оценка предельной «пропускной» способности организационно-технологической структуры предприятия по обработке входного потока «бизнес-событий»;

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

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

Этапность создания модели

Общие рекомендации

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

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

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

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

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

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

Поэтапная детализация каждой из компонент модели имеет своей целью:

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

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

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

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

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

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

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

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

♦ описание информационных потоков на уровне используемых операционных документов (наименование документа) и нормативных правых актов (регистрационные номера приказа);

♦ описание информационных потоков на уровне используемых операционных сведений (данных);

♦ описание операционных документов в контексте источника информации для операционных сведений (данных);

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

Для описания организационной компоненты (персонала), задействуемой для участия в процессе, можно предложить следующую этапность детализации:

♦ указывается наименование подразделения/подразделений, задействуемого для выполнения подпроцесса/процедуры;

♦ указывается должностное лицо/лица, задействуемое для выполнения функции;

♦ указывается ролевая функция должностного лица/лиц, используемая для выполнения функции;

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

Детализация модели выходов может быть осуществлена в рамках такой последовательности шагов:

♦ описание результатов выходов процессов на уровне документов, продуктов, услуг;

♦ описание результатов выходов процессов на уровне данных/сведений, компонент продуктов/услуг.

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

♦ отражение в рамках процесса окружения функции на уровне наименования информационной системы, операционного (входного/выходного) и правового документа, подразделения-исполнителя;

♦ отражение в рамках процесса окружения функции на уровне наименования модуля информационной системы, операционных данных (входных/выходных сведений) и положений («выдержек») правового документа, должностного лица (ролевой функции).

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

♦ разработка общих возможных сценариев протекания процессов;

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

♦ повышение чувствительности модели бизнес-процесса за счет большей детализации входных ситуаций, связанных с бизнес-событиями.

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

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

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

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

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

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

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

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

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

♦ формирование перечня «вторичных» классификаторов, ориентированных на решение задач:

а) моделирования процессов;

б) специализированного анализа по задачам пользователей;

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

Построение информационной модели

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

♦ правовые документы – нормативная и правовая база;

♦ операционные документы;

♦ операционные сведения (данные).

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

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

1) актуализация и обеспечение непротиворечивости и полноты нормативной правовой базы;

2) устранение избыточности в операционных документах;

3) устранение избыточности в операционных данных и существенное сокращение операций по идентификации и проверке их достоверности.

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

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

♦ в рамках проектирования структуры для объекта «нормативный правовой» документ предусмотреть состав атрибутов и связей, которые позволяют:

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

– отразить связь документа с составом объектов, которые подпадают под его регламентацию (например, операционные документы, сведения, информационные системы и т. д.);

– отразить связь с другими правовыми документами.

Благодаря такой форме описания правовой базы появляется возможность точно ответить на вопросы:

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

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

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

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

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

♦ какие правовые акты устарели и в реальности не используются и т. д.

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

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

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

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

♦ инвентаризация всех операционных данных (сведений), задействуемых в операционном процессе;

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

♦ категорирование источников по каждому данному (сведению);

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

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

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

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

♦ наиболее часто используемые в бизнес-процессе операционные данные и документы;

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

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

♦ конфликтные ситуации, связанные с идентификацией точных значений данных (сведений) при их расхождении в разных источниках.

Построение организационной модели

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

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

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

♦ временное (по этапам реализации бизнес-процесса), географическое (по месту реализации бизнес-процесса), стоимостное (по стоимости ресурса для выполнения бизнес-процесса) распределение ресурса в рамках реализуемого бизнес-процесса;

♦ динамическое состояние ресурса – текущая доступность и текущий остаток.

В конечном итоге получаемая информация должна позволить сделать выводы и подготовить предложения по:

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

♦ изменению структуры и характеристик ресурсов;

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

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

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

♦ организационно-штатной структуры предприятия на уровне структуры подразделений;

♦ состава должностей;

♦ бизнес-роли;

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

♦ временных и стоимостных затрат на выполнение бизнес-функции в рамках бизнес-процесса;

♦ временных и стоимостных ограничений на порядок задействования персонала в бизнес-процессах.

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

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

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

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

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

♦ какие временные и стоимостные нагрузки (затраты) сопровождают участие конкретного должностного лица в бизнес-процессах.

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

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

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

По данным Министерства экономического развития и торговли России, опубликованным в августе 2004 года, объем всего рынка ИТ, включая государственный, корпоративный и частный секторы, в 2003 году составил $6–7 млрд и вырос по сравнению с предыдущим годом на 23 %, а к 2007 году объем рынка ИТ составит $11,5 млрд. Близкие оценки давали аналитики CNews и IDC. Наибольшие объемы затрат на ИТ в России сейчас сосредоточены в правительственном, транспортном и добывающем секторах.

А общемировой рост расходов на ИТ в 2004–2008 годах, по оценкам IDC, будет находиться в пределах от 5,2 % до 6,6 %, опережая рост валового национального продукта.

Достаточно репрезентативным является зависимость капитальных расходов на ИТ, отнесенных к общим капитальным расходам компании. Эта зависимость имеет явную тенденцию к увеличению, так что прогнозируемая доля расходов на ИТ достигнет к 2015 году почти половины совокупных капитальных затрат, как показано на рис. 5.

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

Наиболее часто встречаемая проблематика использования АИС, которая значима для последующей оптимизации бизнес-процесса и которая должна отображаться в рамках выбранных проектных решений по архитектуре организационной модели, связана со следующими обстоятельствами:

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

♦ одни и те же данные хранятся в разных информационных системах;

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

♦ при наличии избыточности в составе автоматизируемых функций существование большого количества «не покрываемых» автоматизацией значимых бизнес-функций;

♦ отсутствие достоверной информации о том, насколько активно и в каких бизнес-процессах используется АИС (либо отдельная ее подсистема);

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

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

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

♦ насколько экономически и организационно выгоднее использование новой системы по сравнению с существующими системами;

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

♦ временные и стоимостные показатели использования перспективной АИС (отдельных ее подсистем) в рамках бизнес-процесса предприятия.

С учетом вышеизложенного исходными данными для разработки процессно-ориентированной модели АИС может служить табл. 3.

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

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

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

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

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

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

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

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

♦ отражение взаимосвязи со всеми компонентами модели, являющимися чувствительными к обрабатываемым бизнес-событиям (например, изменения в составе входных/выходных документов, составе используемых АИС, составе должностных лиц и т. д.) в рамках формирования «окружения» функции;

♦ порядок учета основных компонент модели (люди, системы) на временные и стоимостные затраты реализации бизнес-функции;

♦ отражение временных и стоимостных затрат на выполнение бизнес-функции;

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

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

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

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

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

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

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

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

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

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

Построение модели выходов (результатов)

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

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

♦ тактическую, определяющую результаты операционной деятельности;

♦ стратегическую, определяющую обобщенные цели и показатели.

В рамках проектирования общей модели результатов необходимо обеспечить взаимосвязь всех ее составляющих:

♦ целевых установок различного уровня;

♦ выходных результатов процессов;

♦ критериев оценки качества бизнес-процесса.

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

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

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

♦ какие ресурсы (организационные, информационные и технологические) необходимы для их получения;

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

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

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

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

♦ шаблон;

♦ новый документ;

♦ изменен (вариант: в разработке);

♦ согласован (вариант: завизирован);

♦ утвержден;

♦ зарегистрирован;

♦ передан в архив.

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

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

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

♦ отношения вхождения (включения) между объектами целеполагания;

♦ процедуры (алгоритмы) оценки их достижения;

♦ качественно-количественные показатели;

♦ основные параметры, влияющие на значение качественно-количественных показателей;

♦ связи с бизнес-процессами на согласованном уровне.

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

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

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

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

Построение модели управления

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

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

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

♦ определения интерфейсов для взаимосвязи;

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

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

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

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

♦ наглядном отображении на общей модели соответствующих самостоятельных фрагментов и «точек» входа в основные модели;

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

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

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

Разумным дополнением базового классификатора бизнес-процессов могут быть следующие поддерживаемые моделью управления (и соответствующими классификаторами) группировки бизнес-процессов:

♦ по основным сценариям;

♦ по основным этапам прохождения «стержневых» бизнес-процессов;

♦ по основным типам входных условий (бизнес-событий).

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

Разработка прикладных приложений для работы с моделями

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

Пример:

6. Получение отчета по загрузке (доступности) ресурсов.

7. Анализ пропускной способности организационно-технологической архитектуры предприятия.

Общим концептуальным требованием к проектированию общесистемных сервисов («общесистемной» функциональности) является минимизация обязанности пользователя:

♦ по «прониканию» внутрь общесистемной платформы модели и тем более ее корректировке;

♦ по вниканию в общесистемные настройки;

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

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

♦ задание входных условий – бизнес-событий, которые должны инициализировать анализируемый бизнес-процесс, в рамках предварительно сформированного набора (меню) возможных параметров;

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

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

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

♦ возможность многопользовательской работы;

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

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

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

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

♦ входные события для модели (внешняя среда);

♦ выборы по принимаемым решениям в точках ветвления бизнес-процесса (внутренняя среда).

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

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

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

Разработка Соглашения о моделировании

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

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

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

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

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

♦ Определение чувствительности моделей. В данном разделе уточняется, на что и каким образом будет реагировать создаваемая модель, то есть определяется набор входных параметров (параметров различий) модели и предлагаемый вариант реализации учета этих различий (чувствительности) моделей.

♦ Структура хранения моделей в базе данных. Элементы проекта, такие как модели и объекты (активности), желательно структурировать в определенные папки проекта в инструментальной среде.

При создании иерархии папок возможно использование нескольких критериев:

♦ согласно этапам проведения проекта;

♦ согласно процессно-ориентированной структуре;

♦ согласно функциональной структуре компании;

♦ согласно описываемым предметным областям;

♦ комбинации указанных выше критериев.

В данном разделе указываются выбранные критерии построения и непосредственно общая структура папок.

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

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

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

– каждый тип объекта может использоваться в одном или нескольких типах моделей;

– каждый тип объекта может быть представлен одним или несколькими символами.

Также необходимо указать, на какие типы моделей могут быть детализированы те или иные типы объектов.

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

Данный выбор типов связей осуществляется на основе поставленных целей моделирования и знаний таких основ, как:

– один и тот же тип связей между типами объектов может присутствовать в нескольких типах моделей;

– между двумя объектами может быть проведено несколько связей различного типа.

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

Выбор типов атрибутов основывается на знании того, что:

– каждый тип модели, объекта или связи обладает специфичным набором атрибутов;

– есть набор атрибутов, существующий у каждого типа модели, объекта или связи, например: Имя, Полное имя, Описание, Автор и др.;

– другие атрибуты могут существовать только для определенных типов модели, объекта или связи, например «Количество сотрудников» для объекта Подразделение.

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

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

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

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

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

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

– оргединицы и роли отображаются справа от функции.

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

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

Кроме того, определяется ориентировочное количество объектов, которые должна содержать диаграмма, для того чтобы она легко читалась при ее распечатке на листе формата А4 или A3. Также определяется внешний вид элементов используемой нотации (цвет, форма, толщина линий, размеры объекта, формат и наклон текста).

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

1) адекватность модели – соответствие модели моделируемому объекту или процессу. Модель адекватна, если все ее элементы (объекты и связи) имеют прообраз в моделируемой предметной области. Если в модели отображены не все нужные объекты, а «лишних» элементов нет, то считаем, что модель адекватна, но не полна;

2) корректность модели – соответствие исполнения модели бизнес-процесса установленным для конкретной методологии или нотации семантическим и синтаксическим правилам. Модель корректна, если создана в соответствии с правилами оформления, установленными методологией моделирования и другими требованиями;

3) полнота модели – присутствие в модели всех необходимых объектов и связей предметной области (выделенного бизнес-процесса). Модель полна, если она содержит все допустимые заданной методологией элементы предметной области, которые должны быть отображены для достижения целей моделирования и т. д.

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

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

Основные этапы по проектированию

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

1. Систематизация и нормализация входных параметров для формирования областей допустимых значений.

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

а) классификация и кодирование;

б) детализация;

в) взаимосвязь с входными условиями.

3. Проектирование описательной процессной модели (модели управления).

4. Проектирование форм отчетов.

5. Проектирование интерактивной модели.

6. Проектирование имитационной модели.

7. Тестирование разработанной модели

Проектирование моделей «как должно быть» и GAP-анализ

Общая методология построения бизнес-моделей требует рассмотрения трех промежутков времени:

♦ текущего (модели «как есть»);

♦ ближайшего будущего на среднесрочную перспективу (модели «как должно быть» – вариант 1);

♦ отдаленного будущего на долгосрочную перспективу (модели «как должно быть» – вариант 2).

Под среднесрочной перспективой компания Gartner рекомендует рассматривать временной горизонт от 9 до 18 месяцев, а под долгосрочной перспективой – в 30 месяцев. Такие сроки обусловлены влиянием глобального ускорения бизнес-процессов и постоянного развития информационных технологий.

Gartner рекомендует 15 % усилий и внимания уделять существующей сегодня в организации бизнес-архитектуре, 70 % – бизнес-архитектуре, которую предполагается реализовать в ближайшем будущем, и еще 15 % усилий – бизнес-архитектуре, как она видится в отдаленной перспективе.

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

Если говорить про распределение усилий на различных фазах построения бизнес-архитектуры, то 40 % всей усилий должны занимать управление и надзор над процессом создания, порядка 30 % усилий – собственно разработка моделей, решений и их документирование. И примерно по 15 % усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений и на проведении оценки и сравнительного анализа с лучшими мировыми практиками или доступными аналогами.

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

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

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

2. Анализ движущих сил, которые влияют на организационно-технологическую структуру организации с точки зрения основных функций и бизнеса организации.

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

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

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

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

На этапе Gap-анализа осуществляются:

♦ идентификация и категорирование несоответствий между текущим и целевым состояниями;

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

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

Выявляемые в рамках Gap-анализа несоответствия могут быть связаны с вопросами культуры организации, структурными проблемами, функциональными или же процедурными вопросами [14].

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

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

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

В обобщенном виде процесс Gap-анализа предусматривает выполнение следующих шагов [4].

1. Идентификация различий между существующей и целевой бизнес-архитектурами.

2. Формирование перечня идентифицированных несоответствий с разбивкой по категориям (в том числе компонентам бизнес-архитектуры) и определение состава требуемых изменений.

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

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

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

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

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

Результаты Gap-анализа ложатся в основу Плана миграции (модернизация) организационно-технологической архитектуры предприятия по всем ключевым компонентам:

♦ информационным потокам;

♦ функциям;

♦ организационной структуре;

♦ ИТ и производственным технологиям и т. д.

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

Плюсы и минусы различных подходов к разработке бизнес-архитектуры

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

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

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

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

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

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

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

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

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

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

Глава 4 Современные инструментальные средства моделирования бизнес-процессов. Как выбирать инструментальную среду для бизнес-моделирования

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

Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architect, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. И в данной книге мы не будем останавливаться на сравнительном анализе этих и других средств и отсылаем читателя к специализированным публикациям.

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

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

♦ «внутренние» – потребности и возможности предприятия, связанные с созданием моделей бизнес-архитектуры;

♦ «внешние» – возможности современных инструментальных средств.

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

К числу основных «внутренних» факторов, влияющих на выбор заказчиком инструментальной среды моделирования, следует отнести:

♦ производственную необходимость;

♦ бюджетные ограничения;

♦ уровень текущей проработки задач по моделированию и оптимизации;

♦ уровень подготовки персонала;

♦ предыдущие вложения;

♦ характеристики программно-аппаратной платформы и т. д.

По каждому из вышеперечисленных факторов можно дать следующие комментарии.

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

Для качественного обоснования производственной необходимости выбираемой конфигурации средств моделирования необходимо:

1) четко сформулировать все «производственные» постановки задач по моделированию;

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

3) сопоставить функционал по моделированию возможных к использованию инструментальных средств (модулей инструментальных средств).

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

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

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

♦ разработанными подходами, включая алгоритмические решения, по оценке состояния бизнес-процессов и их оптимизации.

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

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

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

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

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

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

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

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

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

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

♦ уровень «похожести» интерфейса с заменяемой платформой;

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

♦ отсутствие необходимости модернизации общесистемной программно-аппаратной платформы;

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

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

♦ требования к технической платформе;

♦ требования к общесистемному программному обеспечению;

♦ требования к телекоммуникационному обеспечению;

♦ возможности по обеспечению информационной безопасности;

♦ количество мест установки пользовательских приложений.

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

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

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

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

♦ программные средства моделирования (формализации), нацеленные на общее описание бизнес-процессов;

♦ программные средства моделирования (формализации), нацеленные на разработку автоматизированных информационных систем.

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

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

♦ средств динамического анализа (имитационного моделирования).

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

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

♦ опора на заказные разработки;

♦ опора на промышленно поддерживаемые инструментальные средства, предусматривающие возможность настройки на прикладные задачи.

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

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

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

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

♦ низким уровнем прогнозирования сроков завершения работ по созданию самописных скриптов;

♦ вероятностью наличия скрытых ошибок в ПО;

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

♦ высокой зависимостью от разработчика;

♦ недостаточной полнотой документирования разработки;

♦ трудно прогнозируемыми затратами на документирование, тестирование, обеспечение качества и т. д.;

♦ возможностью срыва сроков построения модели;

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

Риски и издержки, связанные с использованием промышленно поддерживаемых программных средств моделирования, могут заключаться в следующем:

♦ неполнота функционала для учета специфики постановки задач;

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

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

♦ затраты на техническую поддержку;

♦ диктат производителя в части апгрейда версий ПО;

♦ недостаточная гибкость;

♦ возможность ухода с рынка производителя ПО и соответственно возможность потери технической поддержки и восстановление заказчиком утерянных дистрибутивов и т. д.

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

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

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

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

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

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

♦ достаточность компетенций технического персонала;

♦ достаточность уровня подготовки пользователей;

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

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

Основой для выбора наиболее подходящего для предприятия инструментального средства (профиля средств) является знание рынка современных технологий, относящихся к области моделирования. Не претендуя на полноту и детальность, проведем краткий анализ современных средств моделирования.

Выбор инструментальных средств моделирования и методов

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

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

В целом выделяют два подхода к моделированию.

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

К этому блоку относится методология IDEF; инструментом, реализующим данную методологию, является BPWin.

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

Методологии, поддерживающие объектно-ориентированный принцип: методология Aris (группа продуктов IDS Sheer «Aris») и методология UML (продукт Rational Rose). Методология UML в основном ориентирована на разработку программного обеспечения, Aris используется для описания бизнес-процессов предприятия.

Aris в том числе предоставляет возможность оценки процессов по заданным параметрам, например с точки зрения времени и стоимости их выполнения.

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

В России для моделирования и анализа бизнес-процессов достаточно широко используются следующие средства моделирования: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer. За рубежом, помимо упомянутых, активно используются такие средства, как System Architect, Ithink Analyst, ReThink и др. В табл. 5 представлен перечень инструментальных средств, участвующих в рассмотрении. Приведенная информация включает:

♦ наименование инструментального средства;

♦ данные о поставщике и представителе в России;

♦ краткую характеристику инструментального средства.

Выделим основные критерии, позволяющие из представленных средств моделирования выбрать те, применение которых в России могло бы с большей вероятностью себя оправдать. Такими критериями являются:

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

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

♦ доступность поддержки поставщика. Такие услуги могут включать телефонную «горячую линию», техническую и консультационную поддержку через представителя поставщика в России;

♦ доступность обучения. Обучение может проводиться на территории представителя поставщика в России, пользователя или где-либо в другом месте;

♦ доступность материалов по продукту. Они могут включать компьютерные учебные материалы, учебные пособия, книги, статьи, информацию в Интернете, демоверсии.

Из приведенного в таблице списка инструментальных средств для более подробного анализа выделим те программные продукты, которые удовлетворяют указанным критериям. В этом случае в рамки нашего дальнейшего рассмотрения попадают BPWIn/ERWin, Oracle Designer, Rational Rose, Power Designer, ARIS, по которым ниже представлено более подробное описание.

BPWin и ERWin компании СотрШвгAssociates. Computer Associates International, Inc. (CA) входит в пятерку ведущих производителей программного обеспечения, предлагая средства моделирования, резервного копирования, управления инфраструктурой предприятия (сетями, серверами и т. д.), информационной безопасности, business intelligence и т. д. Пакет BPWin основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями.

Возможности BPwin:

♦ поддерживает сразу три стандартные нотации – IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область наиболее комплексно;

♦ позволяет оптимизировать процедуры в компании;

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

♦ позволяет облегчить сертификацию на соответствие стандартам качества ISO9000;

♦ интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.;

♦ интегрирован со средством имитационного моделирования Arena;

♦ содержит собственный генератор отчетов;

♦ позволяет эффективно манипулировать моделями – сливать и расщеплять их;

♦ имеет широкий набор средств документирования моделей, проектов.

Пакет ERWin – это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность – связь». В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов. Возможности ERWin:

♦ поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEFlx для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных – Dimensional;

♦ поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;

♦ интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.;

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

♦ возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager);

♦ позволяет переносить структуру БД (не сами данные!) из СУБД одного типа в СУБД другого;

♦ позволяет документировать структуру БД.

Oracle Designer компании Oracle. Набор инструментальных средств Oracle Designer предлагает интегрированное решение для разработки прикладных систем корпоративного уровня для Web– и клиент/серверных приложений. Oracle Designer участвует в каждой фазе жизненного цикла разработки программного обеспечения – от моделирования бизнес-процессов до внедрения. Применение единого репозитория делает возможным использование любых его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений. Задачей Oracle Designer являются сбор данных о потребностях пользователей и автоматизация построения гибких графических приложений. Oracle Designer используется не только для создания приложений, но и для ведения учета изменений, которые неизбежно происходят при эксплуатации системы. Графические модели определений проекта, интегрированные с многопользовательским репозиторием, существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки и позволяющих пользователям осуществлять построение моделей привычным для их организации способом. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода и др. Пользуясь этими принципами, можно добиться успешного баланса организационных потребностей и технологических возможностей и даже эффективно управлять риском, связанным с частыми неизбежными и важными изменениями как в одной, так и в другой области. Средства концептуального моделирования Oracle Designer включают в себя:

♦ ER-диаграммы (диаграммы информационной структуры предметной области, представляемой в виде объектов и их взаимосвязей);

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

♦ диаграммы потоков данных, циркулирующих на предприятии.

Такие модели представляют информационные потребности в удобном и наглядном для восприятия виде, что делает их хорошим средством коммуникации между проектировщиками и пользователями в процессе уточнения постановки задач. Любой разработчик заинтересован, чтобы описание концептуальной модели было использовано для создания спецификаций, описывающих структуру и основные компоненты будущей системы. В Oracle Designer все спецификации проекта системы разрабатываются на основе моделей концептуального уровня и обеспечивают выполнение всех содержащихся в них требований и ограничений. Полученные компоненты системы могут быть преобразованы в реальные объекты базы данных, экранные формы и отчеты. Финальная часть разработки проекта – автоматическая генерация серверных компонентов – возможна не только для сервера БД Oracle, но и для СУБД Microsoft SQL Server, DB/2, Sybase и ряда других. Любые изменения бизнес-процессов могут быть внесены в модели, и тут же будет сгенерировано модифицированное приложение, основывающееся уже на новых схемах ведения бизнеса. При этом все разработанное ранее будет сохранено и войдет в новый проект. Огаск Designer автоматически создает отчеты, которые содержат всю информацию о проекте и могут быть использованы как набор документов, отражающих текущее состояние проекта.

Rational Rose компании IBM. IBM Rational Rose входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Rational Rose является одним из ведущих инструментов визуального моделирования в программной индустрии благодаря полноценной поддержке языка UML и многоязыковой поддержке командной разработки. Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС. Любые участники проекта – аналитики, специалисты по моделированию, разработчики и др. – могут использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта. Для бизнес-аналитиков средство Rational Rose дает возможность детально описать и проанализировать бизнес-процессы данной предметной области. Системные аналитики, используя указанные описания, смогут разработать необходимый функционал ИС, который максимально удовлетворит запросы заказчика. Для архитекторов средство Rational Rose будет полезно при создании мощной и гибкой архитектуры системы. Для аналитиков, специализирующихся в области разработки баз данных, Rational Rose даст возможность визуально проектировать и генерировать базы данных любого размера. Таким образом, можно создавать базы данных Microsoft SQL Server, Oracle, Sybase, SQL Anywhere, IBM DB2 и любые другие, которые поддерживают возможность запуска скриптов стандарта ANSI SQL. Любые модели, создаваемые с помощью данного средства, являются взаимосвязанными: бизнес-модель, функциональная модель, модель анализа, модель проектирования, модель базы данных, модель компонентов и модель физического развертывания системы. Есть возможность по созданию шаблонов архитектурных решений, позволяющих использовать опыт, накопленный в предыдущих проектах. Существуют расширения Rational Rose, которые позволяют выполнять скелетную (round-trip) разработку ИС, создаваемых на базе языков C/C+ +, Java, Smalltalk, Ada, Object Pascal (Borland Delphi) и др. Таким образом, можно сгенерировать каркас программного кода на любом из указанных языков или выполнить процедуру обратного проектирования, что позволяет сформировать модель на базе существующего кода. Есть возможность публикации модели в Интернете, которая служит основой для объединения работы удаленных команд разработчиков. Интеграция Rational Rose с Rational RequisitePro позволяет на базе визуальной модели разработать полный набор требований, которые необходимо реализовать при создании конечного продукта. Интеграция Rational Rose с Rational TestManager дает возможность создавать сценарии тестирования на базе визуальной модели. Интеграция Rational Rose с Rational ClearCase позволяет поставить на версионный контроль модель целиком или по частям. Интеграция Rational Rose с Rational SoDA позволяет автоматизировать процесс создания документов и отчетов по визуальной модели.

PowerDesigner компании Sybase. Компания Sybase со дня своего основания традиционно является ведущим поставщиком информационных технологий на мировой рынок финансовых институтов: технологии Sybase используют 90 % компаний мирового рынка ценных бумаг, 60 % мировых банков и 68 % компаний Wall Street. С 1996 года, когда открылся офис в Москве, Sybase активно работает в России и других странах СНГ. В апреле 2002 года открылись офисы компании в Санкт-Петербурге и Киеве. Офисы Sybase в Москве, Санкт-Петербурге и Киеве обеспечивают всестороннюю работу с клиентами, включая поставки технологий, оборудования, разработку законченных решений, обучение пользователей, полнофункциональную техническую поддержку и услуги консалтинга. PowerDesigner является комплексным решением для моделирования и разработки приложений и бизнес-процессов для организаций, которые нуждаются в быстром, последовательном и эффективном с точки зрения затрат создании или реинжиниринге бизнес-приложений. PowerDesigner позволяет устранить следующие препятствия, мешающие эффективной разработке проектов: различия в профессиональной подготовке участников проекта, разнородные платформы и изобилие языков разработки – то, что характерно для большинства современных компаний. Это позволяет фокусироваться на бизнес-потребностях создания приложений на протяжении всего процесса разработки – от системного анализа и дизайна вплоть до непосредственной генерации кода для приложения. Последняя версия продукта, PowerDesigner, обладает новыми возможностями по моделированию бизнес-процессов, объектному моделированию, базирующемуся на UML, и поддерживает как традиционные, так и вновь появляющиеся технологии моделирования в рамках одной развитой графической среды. Это позволяет значительно сократить затраты и время реализации проекта, который должен функционировать на различных платформах и инструментальных средах. Одним из основных преимуществ PowerDesigner является также использование репозитория масштаба предприятия для хранения и управления всей информацией, касающейся моделирования и дизайна приложений на всех уровнях ведения бизнеса в компании. Это дает возможность правильно организовать рабочий процесс и кардинальным образом повысить эффективность работы разработчика. Ключевые характеристики PowerDesigner:

♦ моделирование бизнес-процессов: PowerDesigner позволяет нетехническим специалистам компании разрабатывать и моделировать бизнес-процессы, ориентируясь на бизнес-задачи и опираясь на известные им термины, используя простую и интуитивно понятную графическую нетехническую модель;

♦ моделирование данных: PowerDesigner позволяет разрабатывать и генерировать схему БД посредством двухуровневого (концептуального и физического) моделирования реляционной БД, поддерживающего классические методики проектирования баз данных. Имеет также встроенные средства моделирования хранилища данных;

♦ объектное моделирование: PowerDesigner предлагает законченную технологию анализа и проектирования систем с использованием стандарта UML (диаграммы бизнес-процессов, последовательности выполнения, классов и компонентов). На основе диаграммы классов PowerDesigner автоматически осуществляет генерацию и реинжиниринг кода для популярных инструментальных сред, таких как JavaTM (включая EJB 2.0), XML, Web Servicies, C+ +, PowerBuilder, Visual Basic и др., посредством настраиваемого генератора;

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

ARIS компании IDS Scheer AG. В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS, разработанный германской фирмой IDS Scheer. Компания IDS Sheer AG основана в 1984 г. Основное направление – программное обеспечение и консалтинг. В настоящее время компания обслуживает 4000 клиентов в 50 странах мира через сеть своих представительств и партнеров. Качество решений IDS Scheer было подтверждено в июне 2005 года золотой медалью Международной познаньской ярмарки, на которой награждаются только лучшие продукты. А также в июле 2005 года, когда на мировом рынке была представлены программные продукты ARIS 7 с абсолютно новыми Web-продуктами; все они имеют общую черту – интуитивно понятный и выразительный интерфейс. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что дает возможность использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику. Методика моделирования ARIS основывается на разработанной профессором Августом Шером теории построения интегрированных ИС, определяющей принципы визуального отображения всех аспектов функционирования анализируемых компаний. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

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

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

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности ER и UML. В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами. ARIS не накладывает ограничений на последовательность построения указанных выше типов моделей. Процесс моделирования можно начинать с любого из них, в зависимости от конкретных условий и целей, преследуемых разработчиками. Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – «функция», «событие», «структурное подразделение», «документ» и т. п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа. Таким образом, по результатам выполнения этого этапа возникает набор взаимосвязанных моделей, представляющих собой исходный материал для дальнейшего анализа. Стоит отметить несколько особенностей системы ARIS. Первая – семейство программных продуктов ARIS ориентировано на процессное описание. Основная бизнес-модель ARIS – eEPC (extended Event-driven Process Chain – расширенная модель цепочки процессов, управляемых событиями). По существу, модель eEPC расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Вторая особенность – в системе ARIS есть внутренняя база данных, которая позволяет проверять модель на непротиворечивость, целостность, проводить верификацию модели. В других продуктах это отсутствует. Третья особенность: ARIS – единственная система, ориентированная на описание бизнеса, где присутствуют различные взгляды на бизнес-систему, которую мы можем оценить и рассмотреть с разных сторон, чего нет в других программных продуктах. В течение последних пяти лет ARIS уверенно лидирует среди средств моделирования.

Укажем основное предназначение каждого рассматриваемого продукта из множества его применений:

♦ для моделирования баз данных больше подходят инструменты Erwin, Power Designer и Rational Rose;

♦ для моделирования компонентов разрабатываемых приложений больше подходят Oracle Designer, Power Designer и Rational Rose;

♦ для моделирования бизнес-процессов больше подходят BPwin, ARIS и Rational Rose.

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

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

1) появлением новых внутренних регламентов взаимодействия, изменений внешней среды – требований клиентов к предоставляемым продуктам и услугам, активности конкурентов и др.;

2) модернизацией и появлением новых автоматизированных процедур вследствие развития ИС;

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

4) оптимизацией моделей, в том числе в рамках состава рассчитываемых показателей и критериев их оценки.

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

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

♦ наличие и удобство реализации иерархического подхода;

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

♦ формальный язык и система обозначений;

♦ интеграционные возможности;

♦ средства анализа;

♦ методологическая база;

♦ наличие прототипов формализованных бизнес-процессов применительно к различным предметным областям.

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

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

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

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

К категории «мечтатели» относятся компании с продуманной стратегией развития своих решений, но ограничениями в части их технологической реализации.

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

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

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

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

Исходя из этого, выбор инструментальной среды предусматривает в общем следующие работы (включая соответствующее документирование результатов):

1) обоснование состава методов моделирования с учетом состава и особенностей системообразующих элементов бизнес-процессов;

2) определение общих требований к средствам разработки моделей процессов;

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

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

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

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

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

♦ формирование команды проекта разработки бизнес-архитектуры;

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

♦ формирование структур и процессов управления и контроля (governance) модели бизнес-архитектуры.

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

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

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

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

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

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

1. Описание (документирование) деятельности организации (процессы, производственные и информационные ресурсы, документы и данные, персонал и т. д.).

2. Анализ и совершенствование бизнес-процессов и деятельности организации в целом.

3. Описание деятельности организации при построении систем менеджмента качества.

4. Подготовка к внедрению систем управления предприятием.

5. Подготовка к внедрению систем класса Workflow.

6. Построение системы стратегического управления на основе сбалансированных показателей.

7. Проведение организационных изменений.

8. Управление операционными рисками и др.

Вне зависимости от типа проект по моделированию бизнес-архитектуры состоит из следующих основных этапов.

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

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

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

4. Подготовка к переходу к оптимизированной модели. На этом этапе разрабатывается план перехода от текущего состояния к целевому:

– создание новых должностных инструкций;

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

– описание временных решений и т. п.

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

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

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

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

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

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

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

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

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

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

г) мониторинг методической и нормативной базы по оценке бизнес-процессов в организации.

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

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

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

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

Реализация минималистского подхода и подхода по «достаточно хорошей архитектуре» осуществляется в соответствии со следующими ключевыми принципами:

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

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

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

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

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

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

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

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

♦ тактическое окно – 9 месяцев;

♦ скользящее окно оперативных возможностей – 18 месяцев;

♦ стратегическое окно – 30 месяцев.

Архитектура должна приносить пользу прежде всего с точки зрения достаточно короткого, 9-месячного промежутка времени. Окно оперативных возможностей должно постоянно перемещаться и соответствовать интервалу примерно в 18 месяцев. Это тот период времени, который связан с понятием «архитектура завтрашнего дня». Стратегическое окно должно быть не более 30 месяцев и соответствовать принятому в компании горизонту стратегического планирования [4] (рис. 8).

Управление процессом создания модели бизнес-архитектуры должно осуществляться в рамках ряда общих руководящих принципов:

♦ архитектура бизнес-процессов для состояния «как должно быть» должна проходить обязательные экспертные и расчетные процедуры контроля на эффективность;

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

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

♦ будут разработаны и поддерживаться стандарты и правила (политики) построения бизнес-моделей. В частности, должно быть разработано соглашение о моделировании. Соответствие стандартам и правилам будет контролироваться. Бизнес-архитектура будет неотъемлемой частью всего процесса управления развитием предприятия;

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

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

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

С организационной точки зрения работа над проектом по построению модели бизнес-архитектуры ведется на трех основных уровнях:

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

♦ уровне внесения существенных изменений в бизнес-архитектуру;

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

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

♦ общих принципов, определенных для регионального уровня;

♦ специфики деятельности подразделения.

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

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

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

В табл. 7 приведены характерные качества, которыми должны в идеале обладать члены команды по формированию модели бизнес-архитектуры [4].

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

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

♦ специалистами-предметниками (бизнес-консультантами);

♦ специалистами технологического профиля (моделировщиками).

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

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

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

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

Ролевую функцию бизнес-консультантов можно определить в рамках решения следующего комплекса задач:

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

♦ восполнение «белых» пятен в существующей системе регламентов предприятия с последующим представлением соответствующих исходных данных по недостающим частям модели;

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

Необходимо дать следующие краткие ремарки в отношении перечисленного комплекса задач.

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

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

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

♦ новой рабочей среды;

♦ подозрения, что на них перекладывают чужую часть работы.

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

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

Как правило, состав исходных данных включает в себя:

♦ неформализованное описание бизнес-процессов;

♦ состав операционных данных;

♦ состав операционных документов;

♦ состав правовой базы;

♦ состав технических ресурсов;

♦ состав организационных ресурсов.

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

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

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

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

Бизнес-консультанты полностью несут ответственность за:

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

♦ обоснование методов и критериев оценки бизнес-процессов;

♦ обоснование методов и критериев оптимизации процессов.

Технологические консультанты полностью несут ответственность за:

♦ полноту и удобство функционала, необходимого для реализации постановок задач бизнес-консультантов в части оценки и оптимизации бизнес-процессов;

♦ дружелюбность интерфейса;

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

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

♦ качество реализации общесистемных функций – администрирование, управление доступом, обеспечение информационной безопасности и т. д.

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

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

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

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

Группа бизнес-консультантов:

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

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

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

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

Группа специалистов по моделированию (технологические консультанты со стороны исполнителя):

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

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

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

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

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

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

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

Можно сформулировать следующие общие требования к квалификации (знаниям) специалистов по описанию бизнес-процессов:

♦ знание принципов и методов организации управления на основе процессного подхода;

♦ знакомство с основами структурного и системного анализа;

♦ знание основ теории эффективности;

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

♦ знание требований действующих корпоративных, государственных и международных стандартов по формализации бизнес-процессов предприятия, в том числе стандартов системы менеджмента качества (ISO 9000).

К личным качествам специалистов по описанию бизнес-процессов предъявляются следующие требования:

♦ коммуникабельность, тактичность и умение при проведении интервью выслушивать собеседника;

♦ умение аналитически и гибко мыслить;

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

♦ умение отделять существенное от несущественного;

♦ способность структурировать собранную информацию.

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

♦ предоставления исходных данных;

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

♦ организационного обеспечения.

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

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

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

Реализуемые в проекте функции управления и контроля включают два аспекта:

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

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

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

По мнению отдельных авторов, управление, руководство и надзор над процессом создания архитектуры предприятия должны занимать примерно 40 % всех усилий по созданию архитектуры [4]. По утверждению этих же авторов, вторым по «значимости» аспектом проекта – порядка 30 % усилий – является собственно разработка моделей, стратегий, решений и их документирование, то, что обычно понимается под понятием «построение, разработка архитектуры». Примерно по 15 % усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений, то есть «продаже» идеи внутри организации, а также на проведении оценки и сравнительного анализа с лучшими практиками или доступными аналогами. В значительной степени эти «пропорции» по распределению ресурсов справедливы и для проекта по созданию модели бизнес-архитектуры. Практика показывает, что большинство проблем при создании архитектуры являются следствием плохого управления и контроля, а не ошибок в отдельных проектных решениях.

Ключевыми вопросами, которые требуют особого внимания при управлении архитектурным процессом, являются следующие [4]:

♦ изучение, осознание и коммуницирование бизнес-стратегии;

♦ определение и анализ уровня зрелости архитектуры;

♦ решение вопросов комплектования и организации работы команды архитекторов;

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

♦ реализация философии «постоянных изменений»;

♦ поиск архитекторов с нужным уровнем знаний.

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

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

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

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

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

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

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

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

Глава 6 Модель построена, что дальше? Масштабное внедрение и поддержка бизнес-модели

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

1) формирование механизма отображения, монитиронига и поддержки процесса управления состоянием бизнес-процессов организации;

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

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

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

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

Соответственно, после создания модели бизнес-архитектуры начинается работа по:

♦ поэтапному масштабному внедрению;

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

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

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

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

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

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

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

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

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

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

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

Как предложено в [4], этих сотрудников организации можно условно разделить на три группы:

♦ руководство организации и руководители бизнес-направлений;

♦ среднее звено управления бизнесом;

♦ различный технический персонал, а также «продвинутые и влиятельные» пользователи.

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

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

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

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

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

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

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

♦ как выявить «пробелы» и «избыточные» элементы в организационной и технологической структурах организации;

♦ соотнесение затрат с активностями (Activity-based costing) (как по бизнес-процессам, каналам продаж и заказчикам распределяется прибыль?);

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

♦ общая стоимость владения (сколько стоит этот процесс?);

♦ возврат инвестиций (R0I) (будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?) и т. д.

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

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

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

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

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

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

♦ изменениями внешней среды (в первую очередь рынка) и соответственно взаимодействующих с предприятием объектов;

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

♦ необходимостью детализации бизнес-модели.

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

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

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

♦ высокие темпы снижения срока жизни программных продуктов: за 2–3 года наблюдается изменение рынка информационных технологий в среднем на 80 %.

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

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

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

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

♦ формирование внутри компании необходимых компетенций;

♦ привлечение сторонней компании (вполне возможно, компании – разработчика комплекса моделей).

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

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

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

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

♦ управление контентом модели бизнес-архитектуры;

♦ управление программно-аппаратной платформой.

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

В состав задач по управлению контентом модели бизнес-архитектуры входят:

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

♦ поддержка актуальности компонент окружения бизнес-моделей;

♦ дополнение модели бизнес-архитектуры новыми бизнес-процессами;

♦ изменение уровней детализации бизнес-процессов;

♦ изменение структуры представления модели;

♦ совершенствование методологии анализа бизнес-процессов и т. д.

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

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

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

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

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

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

Помимо процессов администрирования модели, централизованные механизмы должны использоваться для:

♦ разработки корпоративных стандартов в проектировании бизнес-процессов;

♦ экспертизы предлагаемых изменений в модели бизнес-архитектуры на соответствия их принятым корпоративным стандартам.

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

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

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

♦ обеспечение поддержки бизнес-архитектуры со стороны внешних бизнес-консультантов;

♦ обеспечение поддержки архитектуры со стороны сотрудников ИТ-службы;

♦ создание, документирование и публикация информации об архитектуре;

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

♦ обучение персонала;

♦ мониторинг эффективности использования модели в деятельности предприятия;

♦ подготовка планов технологического развития, связанных с новыми проектными решениями.

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

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

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

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

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

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

♦ качественно-количественные процедуры анализа эффективности по отдельным бизнес-процессам;

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

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

В общем виде «маршрут» движения из старого в новое состояние может быть представлен на рис. 9.

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

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

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

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

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

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

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

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

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

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

1. Решение вопроса об аутсорсинге.

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

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

4. Определение дальнейших этапов развития модели:

♦ детализация компонент модели;

♦ расширение сферы моделирования.

5. Разработка нормативно-методической базы, определяющей порядок использования моделей, внесения в них изменений, администрирования и т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подобные ошибки нельзя допускать как для всей модели бизнес-архитектуры, так и для отдельных моделируемых бизнес-процессов. В единой модели бизнес-архитектуры необходимо поддерживать единый уровень детализации, в противном случае могут возникнуть не только вопросы организационного плана – почему одни бизнес-процессы промоделированы более точно, но и вопросы последующей интеграции бизнес-процессов в общую модель.

В качестве первопричин «паралича» детальности моделирования может выступить попытка единовременного «глобального» охвата бизнес-процессов. Правильным решением является выбор на начальном этапе нескольких (далеко не всех) основных бизнес-процессов, с соответствующей локализацией заинтересованных подразделений заказчика. При этом обеспечивающие бизнес-процессы, с которыми осуществляется взаимодействие выбранных основных процессов, моделируются с таким уровнем детализации, который достаточен для отражения взаимодействия.

Другой крайностью, противоположной «параличу» детализации, является «завышенный» уровень абстракции бизнес-моделей. При неконтролируемом неучете (игнорировании) несущественных деталей появляется высокая вероятность получения такой «универсальной» модели, которая может давать только общие, а не конкретные ответы на практически значимые вопросы. Подобная ситуация может возникнуть, когда, двигаясь «сверху вниз» при построении модели, не хватает ресурса либо исходных данных перейти от высоких уровней детализации на более низкие.

Одним из противодействий таких рисков, связанных с некорректным определением точности описания, является фиксация потребительски значимого для заказчика уровня детализации, при котором модель бизнес-архитектуры действительно может стать действенным информационно-консультационным инструментом по мониторингу и анализу деятельности организации.

Определение значимого уровня детализации должно осуществляться в ходе формирования требований заказчика и требований на разработку (С– и D-требований), как это делается стандартным образом при создании программных продуктов [18]. Зафиксированный уровень детализации описания бизнес-процессов должен быть отражен в Соглашении о моделировании, типовая структура которого представлена в приложении.

Помимо ошибок в определении разумного и достижимого в рамках проекта уровня детализации, риски технологических решений могут быть обусловлены неэффективностью разработанных вариантов интеграции различных компонент модели в условиях, когда на предприятии уже существуют определенные наработки по моделированию по частным задачам.

По факту существует множество возможных моделей для описания деятельности предприятия как системы, и очень часто в организации происходит достаточно разрозненный процесс моделирования. В условиях отсутствия в организации корпоративных стандартов на использование инструментальных средств каждое из подразделений реализует свой выбор. При этом в рамках используемой среды формируются значимые информационные ресурсы, аккумулирующие знания по различным аспектам деятельности организации. Причем конвертация этих ресурсов в какую-либо новую среду далеко не всегда является простой задачей, а формирование данных ресурсов в новой среде моделирования, при условии что они формировались на протяжении длительного периода для ограниченного по срокам и бюджетам проекта, может быть неприемлемо.

По этой причине консолидация различных представлений и многочисленных моделей в рамках единой модели бизнес-архитектуры является весьма сложной задачей. Эта проблема может существенно снизить функциональные возможности создаваемой модели, равно как и сузить круг потенциальных пользователей. Минимизация такого риска лежит в плоскости тщательной проработки методических аспектов, касающихся логической организации различных моделей, используемых при построении единой модели бизнес-архитектуры.

Еще одной часто встречаемой ошибкой при реализации проектов по моделированию бизнес-процессов является неправильное распределение временных и исполнительных ресурсов по этапности создания модели. Это связано либо с незнанием, либо с игнорированием базовой последовательности мероприятий по разработке модели бизнес-архитектуры:

1) разработки модели «как есть»;

2) разработки модели «как должно быть» на ближнюю и дальнюю перспективу;

3) проведение сравнительного анализа (Gap-анализа) моделей «как есть» и «как должно быть» и выработка плана перехода (плана мероприятий) по организационно-технологическим изменениям организации.

В ряде случаев происходит «забывание» 2-го и 3-го пунктов либо неоправданно малое выделение на них ресурсов. Как правило, инициирование работ по созданию модели бизнес-архитектуры связано с желанием организации осуществить оптимизационные мероприятия в своей деятельности. Это уже предполагает, что существующая организация бизнес-процессов будет меняться. Если к этому добавляются обстоятельства, связанные с недостаточно управляемыми текущими активными изменениями, обусловленными высокой динамикой развития рынка, то значительные вложения в детальное описание текущей бизнес-архитектуры вряд ли можно считать оправданными.

В проектах, ориентированных на реализацию трех вышеуказанных фаз, главная цель работ по модели «как есть» состоит в:

♦ сборе и интерпретации исходных данных в объеме, позволяющем понять специфику предметной области и деятельности организации;

♦ разработке проектных решений для построения модели бизнес-архитектуры;

♦ частичном наполнении контента бизнес-архитектуры информацией по состоянию «как есть» для демонстрации потенциальных функциональных возможностей создаваемой информационной системы «модель бизнес-архитектуры предприятия».

При такой роли модели «как есть» основные экспертные и временные ресурсы, связанные с формированием контента модели бизнес-архитектуры, будут приходиться на модель «как должно быть».

Отсутствие понимания либо игнорирование такой логики исполнения приводит к тому, что в условиях отсутствия модели «как должно быть» исполнитель вместе с заказчиком втягивается в процесс постоянной корректировки текущих бизнес-процессов применительно к изменениям, которые, скорее всего, не вписываются в концепцию реинжиниринга бизнес-архитектуры компании. В какой-то мере это напоминает преследование постоянно меняющейся цели.

Особенно чревата подобная ситуация, когда временные сроки изменений в деятельности компании (либо взглядах на организацию деятельности) короче длительности работ по построению бизнес-модели. В результате представляемые результаты работ по модели «как есть» не соответствуют реальности. Это создает достаточно серьезные формальные поводы для отказа приема работ. Подобные случаи особенно характерны для государственных заказчиков, у которых процедуры рассмотрения и согласования результатов носят настолько «затяжной» характер, что за время рассмотрения появляются новые существенные изменения в правовой базе, организационной структуре и т. д.

Разумеется, вероятна и такая ситуация, когда организация обладает устоявшейся (стабильной) организационно-технологической структурой и для нее самостоятельной целевой задачей являются систематизация и формализация знаний о своем устройстве. Тогда модель «как есть» будет предусматривать полное наполнение контента и соответственно требовать выделения основной части ресурса по проекту.

Несомненно, что для исключения неправильного распределения ресурса между фазами проекта важно изначально правильно сформулировать и зафиксировать метацели моделирования модели бизнес-архитектуры: что это – систематизация (инвентаризация) организационно-технологической структуры, или прототип новой организационно-технологической структуры, или механизм документирования и управления изменения в организационно-технологической структуре предприятия?

Нечеткая или неправильная постановка задач по проекту бизнес-архитектуры приводит не только к неправильному распределению ресурсов между различными фазами (этапами) исполнения, но и к ошибкам в формировании самих исполнительных ресурсов. Если работы на этапе построения модели «как есть» ИТ-специалистов и «не ИТ-специалистов приблизительно сопоставимы, то на этапе построения модели «как есть», где основная нагрузка ложится на оптимизацию предметной бизнес-области, потребности в «не ИТ» – компетенциях существенно возрастают. По этой причине по ходу проекта необходимо очень внимательно отслеживать и прогнозировать изменение потребностей в профилях и объемах необходимых компетенций и адекватно на них реагировать.

Риски, связанные с моделью бизнес-архитектуры, существуют не только на этапе разработки (исполнения проекта внешним исполнителем), но и на этапе внедрения, использования и развития модели. Действительно, используемая модель бизнес-архитектуры будет находиться в состоянии изменения, настолько активного, насколько динамичны объективные изменения во внешней и внутренней среде деятельности организации. Рассматривая модель бизнес-архитектуры как состоящую из двух основных компонент – проектных решений и контента, наиболее эффективным видится такое распределение ответственности за их развитие (поддержку) после завершения проекта.

За проектные решения должен отвечать исполнитель (в рамках аутсорсинга) либо специально подготовленная группа поддержки от заказчика. За развитие контента – представители заказчика, в соответствии с закрепленными бизнес-направлениями (зонами ответственности по компонентам модели). То есть проектные решения модели бизнес-архитектуры нужно рассматривать как некоторый механизм, с которым должен уметь работать заказчик и который должен им самостоятельно использоваться для накопления, систематизации, документирования знаний о ключевых аспектах деятельности организации, мониторинга состояния и принятия обоснованных управленческих решений.

Прямое, а не опосредованное через исполнителя, управление заказчиком контентом модели бизнес-архитектуры является необходимым условием оперативного внесения изменений и таким образом постоянной поддержки актуальности модели. Отдача исполнителю на аутсорсинг контента модели порождает повышенные риски в задержках внесения изменений, обеспечении информационной безопасности и коммерческой тайны вследствие доступа сторонних сотрудников к конфиденциальным сведениям, выхода за бюджеты на поддержку модели.

Учитывая необходимость переноса основной нагрузки по сопровождению модели на заказчика, должны своевременно создаваться соответствующие условия для реализации этой задачи. В первую очередь это касается формирования специализированных структур внутри предприятия для поддержки и развития модели бизнес-архитектуры и обучения персонала данных подразделений.

Задержки в подготовке подобных организационных структур несут угрозу появления периода «бесхозности» модели бизнес-архитектуры, во время которого может быть утеряна актуальность модели либо сформироваться условия для «затяжного» периода сопровождения системы исполнителем, что, следовательно, приведет к дополнительным финансовым расходам.

Выше отмечалось, что масштабное внедрение модели бизнес-архитектуры сопряжено с переориентацией организации на «новую» культуру (например, внедрения процессного подхода). В данный процесс вовлекаются практически все основные бизнес-направления и сотрудники компании. По охвату и глубине изменений в сознании персонала подобного рода проекты не сопоставимы с проблемами внедрения частных прикладных информационных систем. В таких условиях вполне оправдано ожидать повышенной сопротивляемости среды внедрения к новым процессам, равно как удлинения сроков обеспечения организационной и психологической готовности к использованию новаций.

Данные риски несвоевременной готовности заказчика к самостоятельной эксплуатации модели бизнес-архитектуры могут быть снижены за счет либо заблаговременной подготовки страховочного варианта по привлечению исполнителя, либо более раннего начала мероприятий по подготовке собственного персона.

Особенно важным аспектом при самостоятельной эксплуатации модели бизнес-архитектуры является обеспечение ее актуальности. Данная проблема распадается на несколько ключевых составляющих:

♦ кто будет следить за всеми изменениями (существенными для модели) в деятельности организации;

♦ кто будет вносить изменения в модель в соответствии с изменениями в деятельности организации;

♦ как будут осуществляться подготовка и переподготовка (обучение) персонала – пользователей и технического персонала.

Риски в данной области могут быть связаны с:

♦ неучетом задач по технической поддержке системы и подготовке персонала;

♦ неправильной оценкой собственных финансовых и технических возможностей заказчика по самостоятельному сопровождению системы;

♦ переоценкой заказчиком уровня профессиональной подготовки своего персонала.

Отличительной особенностью рисков сопровождения для системы «модель бизнес-архитектуры предприятия», в отличие от обычных информационных систем, является в первую очередь многоаспектность природы изменений в деятельности организации.

При максимально оптимистичной постановке задачи модель бизнес-процессов должна отражать и увязывать «все и вся» на предприятии: изменения в технологических процессах, штатном расписании, информационных системах, документообороте, обеспечивающих процессах и т. д. Ответственность за отслеживание данных изменений и последующую передачу в «точку» централизованного учета должна ложиться на «владельцев» процессов (либо их компонент). Очевидно, что организовать данный регламент на предприятии, при том что для функциональных подразделений подобное информирование является не основной функцией, является довольно непростой организационной задачей.

Существует вполне определенный риск игнорирования данных обязанностей функциональными подразделениями и, соответственно, постепенная потеря актуальности модели. Данный риск может нивелироваться только путем полномасштабного принятия на предприятии «новой» культуры управления. Соответственно, период «постпроектной» жизни модели должен сопровождаться активной «пропагандисткой» работой и стимулирующими мероприятиями по ее практическому использованию.

По аналогии с обозначением и решением вопроса поддержки «жизнедеятельности» модели необходимо ставить и решать проблему широкомасштабного внедрения. Риски для заказчика и исполнителя здесь имеют такую же природу – наличие финансовых и технологических ресурсов, уровень компетенции, «благожелательность» среды внедрения, своевременное обеспечение организационно-технологической готовности. Соответственно, подходы по их минимизации являются такими же, как и в случае с решением вопроса по поддержке «жизнедеятельности» модели.

Подводя итог, необходимо отметить, что «человеческий» фактор играет ключевую роль в появлении и нейтрализации рисков. В издании [4] приводится следующая категоризация «социума» по отношению к проектам по созданию архитектуры предприятия и решениям по ответной реакции (табл. 8). В значительной степени такие оценки могут быть распространены и на проекты по созданию модели бизнес-архитектуры.

Глава 8 Моделирование бизнес-процессов в среде ARIS – иллюстрация частных решений и подходов

В настоящее время существует достаточно большое количество печатных и электронных изданий, в которых с различным уровнем детализации описаны возможности среды ARIS.

В данной главе не предполагается повторение либо какая-то «авторская» систематизация ранее опубликованных материалов по инструментальной среде моделирования ARIS. Главной целью будет освещение отдельных решений и подходов, которые были наработаны в ряде консалтинговых проектов по моделированию, и по мнению авторов, потенциально могут быть полезны для решения аналогичных задач.

В значительной степени изложение материалов по решениям и подходам в среде ARIS по своей структуре будет привязано к общей логике и последовательности изложения материалов главы 3.

В первую очередь предполагается осветить, как в среде ARIS могут быть реализованы полезные постановки задач прикладного и специального функционала для создаваемой модели бизнес-архитектуры предприятия.

Прикладной функционал

В ряде случаев стандартных возможностей ARIS для последующего анализа и оптимизации модели протекания бизнес-процессов не хватает и требуются дополнительные доработки функционала.

Существуют практически значимые постановки задач по моделированию, когда необходимо создать комплексную модель, которая должна реагировать на большое количество различных ситуаций, которые, в свою очередь, определяются «внешними» входными данными и принимаемыми внутрикорпоративными решениями в ходе исполнения бизнес-процесса.

Как было отмечено в главе 3, эффективно реализовать реакцию модели на большее количество ситуаций возможно при условии такого ее проектирования, при котором:

♦ в рамках каждой вышестоящей модели выделяются точки «ветвления» бизнес-процесса, с учетом входных условий и принимаемых бизнес-решений;

♦ происходит «навешивание» на каждый из маршрутов ветвления «уникальной» бизнес-модели нижнего уровня, соответствующей параметрам входных условий и принимаемых бизнес-решений.

Соответственно, каждой уникальной ситуации, определяемой значением параметров входных условий и принятыми бизнес-решениями, будет соответствовать уникальный «маршрут» в разветвленной модели бизнес-архитекутры предприятия. Стандартный набор постановок задач для анализа маршрута может выглядеть так:

♦ «позиционирование» маршрута в рамках общей модели путем его выделения каким-либо образом, например цветом;

♦ выделение всего маршрута в отдельную подмодель, поддерживающую связь с общей базой;

♦ проведение финансового, стоимостного, временного и других видов анализа «маршрута»;

♦ отслеживание последовательности этапов прохождения маршрута и т. д.

К сожалению, инструментальная среда ARIS не позволяет только своими стандартными средствами в полном объеме реализовать такую постановку задач и предлагаемое проектное решение. Средства ARIS покрывают решение следующей части задачи:

♦ формирование описательной части общей бизнес-модели и ее составных частей, в том числе включаемые через точки ветвления уникальные процессы, подпроцессы, процедуры, функции;

♦ стандартные процедуры финансового, стоимостного, временного и других видов анализа «маршрута».

По этой причине исполнителю необходимо самостоятельно разрабатывать ряд программных модулей – скриптов, которые позволяют:

♦ «выделить» из среды ARIS уникальный маршрут;

♦ «вернуть» в среду ARIS уникальный маршрут в качестве модели бизнес-процесса, связанного с общей базой модели бизнес-архитектуры.

Применительно к этим целевым задачам ниже представляются следующие описания прикладного функционала, требующего «ручных» доработок. Группа прикладных функций выделения «маршрута»:

♦ интерактивный режим задания параметров входных условий;

♦ интерактивный режим прохождения в реальном масштабе времени бизнес-процесса с учетом заданных параметров входных условий и принятия бизнес-решений;

♦ цветовое выделение «маршрута» на фоне общей модели;

♦ сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры;

♦ интерактивный режим навигации по сохраненной (измененной) модели маршрута.

Группа прикладных функций аналитической обработки «маршрута»:

♦ технологическая карта;

♦ специализированные алгоритмы анализа (временного, стоимостного) бизнес-процесса с учетом влияния человеческих и технических ресурсов.

Группа прикладных функций выделения «маршрута»:

♦ интерактивный режим задания параметров входных условий.

В соответствии с положениями главы 3 чувствительность многокомпонентной модели к набору входных параметров реализуется через создание в режиме ручного моделирования подмоделей, реализующих особенности функционала, зависящие от входного параметра.

На модели верхнего уровня формируется функция, с ней ассоциируется набор подмоделей, реализующих специфический функционал (рис. 10).

Рис. 10

Каждая подмодель должна быть озаглавлена так, чтобы пользователь смог понять, какой специфический функционал эта подмодель реализует. Для автоматизации выбора подмодели из списка подмоделей, ассоциированных с функцией высокого уровня, одному из атрибутов подмодели (в нашем случае это атрибут модели Identifier) присваивается определенное значение (числовое или строковое – по желанию разработчика).

Например: на модели (рис. 11) с функцией высокого уровня, выделенной черными квадратами, связан список подмоделей типа eEPC, каждая из которых реализует специфический функционал, определенный типом транспорта. Атрибут Identifier каждой подмодели имеет свое значение, разное в зависимости от, например, типа транспорта. Перед началом обхода модели высокого уровня при помощи скрипта последний формирует диалоговое окно, из которого пользователь может выбрать нужное значение, например вида транспорта, в зависимости от анализируемой версии бизнес-процесса. Выбранное значение запоминается в переменной. Значение переменной используется при выборе из списка ассоциированных с функцией подмоделей.

Рис. 11

В приложении 1 приведен пример кода функции seltrans (выбор вида транспорта).

Если в процессе обхода модели встречается функция, имеющая ассоциации с eEPC-моделями, то автоматически будет выбираться для дальнейшей обработки подмодель с нужным видом транспорта.

В приложении 1 приведен пример кода функции getassmodpar (получить ассоциированную с текущей функцией подмодель с нужным видом транспорта).

Подобным образом реализуется чувствительность модели к другим входным параметрам.

При написании и отладке скриптов применялся встроенный в среду ARIS интерпретатор языка программирования Sax Basic, окно экранного редактора которого приведено на рис. 12.

Рис. 12

Для доступа к специфическим средствам языка – компонентам объектовой среды ARIS – применялись стандартные библиотеки ATARep.dll и ATDRepDb.dll среды ARIS (рис. 13).

Рис. 13

При помощи диалогового окна «ActiveX Automation Members» можно получить доступ как к средствам языка Sax Basic, так и к типам данных – объектам среды ARIS, информацию обо всех их свойствах (Properties) и методах, реализованных через процедуры (Sub) и функции (Function), о типе возвращаемого значения, количестве и типах параметров методов (рис. 14).

Рис. 14

При необходимости можно подключить другие библиотеки из опубликованного в системном реестре набора dll-ресурсов. Доступ к этой возможности предоставляется через опцию Tools/Referenses… окна экранного редактора среды ARIS (рис. 15).

Рис. 15

Интерактивный режим прохождения в реальном масштабе времени бизнес-процесса с учетом заданных параметров входных условий и принятия бизнес-решений

В штатном режиме среда ARIS предоставляет стандартные возможности навигации, состоящие в ручном прохождении по моделям путем или выбора имени модели из окна Explorer, или – на модели – выделения функции, имеющей ассоциации с другими подмоделями, выбора ассоциированной подмодели из списка закладки Assignments окна просмотра модели. В этих случаях можно увидеть модель и ее объекты, просмотреть свойства модели и ее объектов, можно изменить модель и любое из ее свойств, изменить любой объект и любое из его свойств. Формирование статистики обхода или любое документирование воздействий невозможно. При помощи специально написанного скрипта можно:

♦ произвести фиксацию «следа», «тропы», по которой происходил обход моделей;

♦ получить возможность интерактивного режима принятия бизнес-решений;

♦ получить подробный протокол обхода;

♦ получить новые модели, на которых отражены только те объекты, которые были использованы при обходе исходных моделей.

Список сервисного функционала может быть значительно расширен в зависимости от бизнес-потребностей заказчика и возможностей разработчика.

Навигация по модели производится в автоматическом режиме, в реальном масштабе времени. По соглашениям о моделировании модель может начинаться и завершаться любой совокупностью функций, интерфейсных функций, событий. Для облегчения программирования возможны следующие соглашения:

♦ модель верхнего уровня может начинаться событием или интерфейсным процессом с детализацией и заканчиваться событием или интерфейсным процессом с детализацией или интерфейсным процессом без детализации;

♦ модель, являющаяся детализацией, начинается и заканчивается событием;

♦ интерфейсный процесс с детализацией вначале ссылается на модель-предшественник;

♦ интерфейсный процесс с детализацией в конце ссылается на модель-последователь;

♦ если модели связаны через интерфейсные процессы, то должна выполняться дисциплина: на модели-источнике – событие 1, интерфейсный процесс 1, ссылающийся на модель-приемник, на модели-приемнике – интерфейсный процесс 1, но ссылающийся на модель-источник, затем событие 1;

♦ интерфейсный процесс без детализации в конце завершает процесс и обход.

Последовательное применение таких соглашений облегчит навигацию и понимание связей между моделями.

При моделировании часто возникает необходимость выбора пути, по которому будет развиваться бизнес-процесс в зависимости от принятого бизнес-решения.

Точки принятия бизнес-решений реализованы путем введения в модель совокупностей объектов – правил, за которыми следуют совокупности многочисленных событий, объясняющих альтернативы дальнейшего прохождения бизнес-процесса в зависимости от сделанного пользователем бизнес-решения (рис. 16).

Рис. 16

Если в процессе обхода модели встречается правило, то сначала анализируется его тип.

Если правило AND, то начала альтернативных ветвей заносятся в стек, затем в автоматическом режиме продолжается обход ветвей одна за другой, диалоговый режим не возникает. Извлечение из стека начала очередной ветви происходит по достижении конца текущей ветви. Для организации такого режима необходимо, чтобы при ручном создании модели каждому открывающему правилу соответствовало аналогичное закрывающее правило.

Если правило OR, то формируется список альтернативных ветвей процесса, который в диалоговом режиме предлагается пользователю. Пользователь выбирает любую комбинацию ветвей, начала этих ветвей заносятся в стек, затем в автоматическом режиме продолжается обход ветвей одна за другой.

Если правило XOR, то также формируется список альтернативных ветвей, который предъявляется пользователю в диалоговом режиме. Пользователь сможет в этом случае выбрать только одну ветвь. Начало ветви в стек не заносится, затем в автоматическом режиме продолжается обход текущей ветви.

Дисциплина доступа к стеку: последним вошел – первым вышел (LIFO).

Стек может быть организован несколькими способами.

Если надо хранить несколько параметров для одного объекта, применяется или многомерный массив вариантного типа, в каждом измерении которого хранится один параметр объекта, или одномерный массив структур, в котором отдельная структура хранит параметры отдельного объекта.

Если надо хранить один параметр для каждого объекта, может подойти или одномерный массив вариантного типа, или список. Список в этом случае более предпочтителен.

Так как операции с объектами требуют много ресурсов, то обязательна практика возврата ресурсов системе перед завершением работы всех процедур и функций скрипта. Для списка это делается путем присвоения значения Nothing, для массива придется писать код, который обнулит ссылки каждого задействованного объекта в ячейке массива.

На рис. 17 приведен пример выбора альтернативной ветви процесса для правила XOR.

Рис. 17

В приложении 1 приведен пример кода, реализующего этот функционал. Это процедура XOROpen. Строки диалогового окна формируются при помощи функции Getname(), код которой также приведен в приложении 1.

Цветовое выделение «маршрута» на фоне общей модели

В стандартном режиме ARIS позволяет просматривать модели любой группы, свойства модели и любого из ее объектов, менять свойства модели и любого из ее объектов. Журнал посещений моделей не ведется, поэтому запомнить путь, повторить просмотр, пометить как-то просмотренные модели и т. п. невозможно.

Для реализации подобного функционала создан скрипт, позволяющий в интерактивном режиме пройти по любой модели или группе моделей, сделать осознанный выбор альтернативного пути развития бизнес-процесса, пометить уже пройденный путь (выделить отличным от стандартного цветом пройденные объекты), получить журнал – список пройденных моделей. В процессе прохода по модели формируется подробный журнал, типа Технологической карты, в котором отмечаются все точки принятия решений, все пройденные функции, фиксируется окружение каждой пройденной функции.

Создан также скрипт, при помощи которого можно повторить обход модели, так как пройденные объекты на модели помечаются не только цветом, но и последовательным номером. Кроме того, этот скрипт использует навигационную информацию из журнала, созданного при первом проходе.

Создан также скрипт, который производит восстановление всех моделей из списка просмотренных до первоначального состояния – восстановление цветов, сброс номеров объектов, сброс других сервисных атрибутов моделей и объектов на них.

На рис. 18 приведен пример использования описанного скрипта, под ним – список моделей, пройденных скриптом за последний сеанс работы.

Рис. 18

Изменение цвета объекта и присвоение ему последовательного номера производятся путем назначения некоторым атрибутам объектов специальных значений.

Пример кода, реализующего этот функционал, приведен в приложении 2.

Это функции setfunnomer() и setcolor(). Список пройденных моделей:

1. Оформление запрещения выпуска товаров.

2. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи и ЛНП.

3. Проставление штампа «Выпуск разрешен» и соответствующей записи и ЛНП.

4. Проставление штампа «Выпуск запрещен» и соответствующей записи, ЛНП в правом верхнем углу заявления.

5. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи, ЛНП в правом верхнем углу контрольного экземпляра документа.

6. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи и ЛНП.

Сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры

Для того чтобы применить некоторые стандартные средства ARIS (например, стоимостной, временной анализ, симуляцию и т. п.) к моделям, их нужно предварительно готовить, как правило, долго и вручную. Такая подготовка обычно состоит в создании новой Group, копировании в нее моделей – всех или некоторых, модификации моделей – добавлении или удалении объектов, изменении некоторых атрибутов объектов и т. п.

Подобное копирование можно производить или вручную, или при помощи механизма Variants. Однако если модели копируются как Copies occunrence, то любые изменения объектов этих новых моделей автоматически приводят к изменениям occurences этих объектов на моделях-источниках, что далеко не всегда то, что нужно пользователю.

Как правило, модели копируются пользователями как Copies definitions, но в этом случае пропадают все связи объектов этих моделей и на новых моделях все связи приходится восстанавливать вручную, что очень затратно по времени и чревато ошибками.

Был создан скрипт, который, реализуя весь ранее уже описанный функционал, позволял вдобавок создавать в автоматическом режиме новую тестовую Group, копии моделей, по которым «проходил».

На этих новых моделях отражались только те объекты и ветви, которые анализировались скриптом, и помечались цветом и уникальным последовательным номером. Объекты, которые не анализировались, не копировались на новую модель.

В итоге получалось нечто, похожее на приведенное на рис. 19.

Рис. 19

В процессе формирования новой модели проводился соответствующий анализ, состоявший в том, что:

♦ если атрибуты объекта, число и тип связей, число и тип ассоциаций не изменялись, то на новой модели создавался новый occurence уже существующего объекта, при этом, естественно, сохранялись все уже существовавшие связи этого объекта, затем создавались новые occurences связей уже существующего объекта, аналогичные связям объекта – оригинала с модели-источника;

♦ если же менялись атрибуты объекта, или число и тип связей, или число и тип ассоциаций, то:

– в новой группе создавался новый объект, аналогичный оригинальному, но уже со своим, специфицированным набором атрибутов;

– на новой модели создавался новый occurence объекта;

– затем создавались новые occurences связей нового объекта, аналогичные связям объекта – оригинала с модели-источника.

Полученная модель сохраняла все «старые» связи модели – своего оригинала, но в то же время была функционально от нее независимой.

Такая модель практически без ручной доработки, или с минимальными доработками, могла быть подана на вход стандартных средств ARIS для дополнительного анализа.

Группа прикладных функций аналитической обработки «маршрута»

Технологическая карта

Скрипты из стандартной поставки ARIS многочисленны и позволяют производить довольно подробный анализ объектового состава моделей. При грамотном подходе эти скрипты – мощное подспорье для анализа моделей в руках умелого пользователя. Но они практически не позволяют пользователю делать произвольную группировку объектов нужной модели.

Для расширения функциональных возможностей системы аналитической обработки моделей был создан ряд скриптов, позволяющих формировать отчеты, содержащие подробную информацию по пройденным событиям, правилам, функциям «маршрута» и окружению (документы и информационные системы) каждой обработанной функции.

Одна из версий скрипта может формировать документ приведенной ниже структуры (табл. 9).

Это пример типового функционала формирования технологической карты.

В процессе формирования этого документа в интерактивном режиме выбираются из меню параметры, определяющие «чувствительность» модели. После этого начинается «обход» модели. В точках принятия решения пользователю предоставляется возможность принять бизнес-решение, от которого зависит выбор дальнейшего пути прохождения по модели.

Событие, связанное с появлением точки принятия решения, фиксируется в отчете строкой, содержащей текст сделанного выбора. Для каждой функции на помеченном пути поизводится анализ ее (функции) «окружения». Итогом этого анализа является помещение в отчет отсортированной информации по группам, указанным в примере заголовка отчета.

Также в отчет включается список моделей, пройденных при обходе. Этот же список сохраняется отдельно в текстовом файле. Информация из этого файла может быть использована другими – сервисными – скриптами, например для повторного обхода помеченного маршрута, сброса объектов пройденных моделей в исходное состояние – восстановление цветов объектов, сброс номеров пройденных функций, сброс сервисных атрибутов помеченного маршрута.

Должностная инструкция

Другой скрипт может формировать документ приведенной ниже структуры (табл. 10). Это также достаточно типичный функционал, связываемый с работой с моделями бизнес-процессов, – должностная инструкция.

При формировании этого документа создается список должностей – объектов типа Position, присутствующих в базе. Этот список можно сформировать как скриптом, так и вручную, создав специальную модель (Должности) типа Organization Chat. Также создается список ролей – объектов типа Person Type, присутствующих в базе. Этот список тоже можно сформировать как скриптом, так и вручную, создав специальную модель (Роли) типа Organization Chat. Далее пользователю предлагается в интерактивном режиме выбрать одну должность и произвести назначение этой должности ролей из списка ролей. Это вполне логично, так как должность, в принципе, может выполнять несколько ролей. После этого производится анализ базы. Для каждой выбранной роли в цикле ищется функция-хозяин, строится список таких функций. После поиска список функций делается уникальным, чтобы исключить повторные вхождения одной функции, сортируется и выводится в отчет. Надо заметить, что рассмотренный скрипт формирует обобщенный список функций, выполняемых ролями данной должности, то есть без учета конкретного бизнес-процесса.

Еще одна из версий скрипта может формировать документ типа должностная инструкция, но уже с учетом конкретного бизнес-процесса. То есть формируются должность, список ролей данной должности, обобщенный список функций данной должности, затем, после запроса входных параметров, определяющих режимы чувствительности модели, производится проход по модели и формируется часть (раздел) выходного документа следующей структуры (табл. 11).

В выходной документ попадают только те функции, хозяевами которых являются роли из списка, выбранные на первом этапе формирования документа ролей.

Он (скрипт) объединяет возможности как скрипта «должностная инструкция», так и скрипта «технологическая карта». Алгоритм формирования, вид и структура выходного документа практически аналогичны уже ранее рассмотренным.

Специализированные алгоритмы анализа (временного, стоимостного) бизнес-процесса с учетом влияния человеческих и технических ресурсов

Стандартная конфигурация ARIS предоставляет в распоряжение пользователя очень богатый и функционально полный набор специализированных опций экономического анализа. Это ABC – Activity Based Cost Calculation, Balanced Scoreboard и Simulation. Правда, надо признать, что ожидаемый эффект достигается лишь при условии, что исследуемые модели соответствующим образом подготовлены к анализу. Имеются в виду такие действия, как:

♦ приведение семантики модели в полное соответствие с требованиями методологии ARIS;

♦ удовлетворение условиям по количеству уровней вложенности моделей;

♦ удовлетворение требованиям по числу и типу ассоциаций для функций, присутствующих в моделях;

♦ создание дополнительных сервисных моделей, таких как, например, диаграммы событий, календари смен.

Почти все эти требования могут быть удовлетворены только при помощи «ручных» доводок. При наличии многокомпонентной, многоуровневой модели для, например, симуляции надо, чтобы число ассоциаций функции с другими моделями было единственным. Как правило, неединственная ассоциация является следствием «чувствительности» модели к нескольким условиям, например тип транспорта, тип товара и т. п. Для того чтобы запустить симуляцию на такой модели корректно, необходимо разделить многокомпонентную, многомерную модель на ряд плоских. Каждая их этих плоских моделей реализует «чувствительность» только по одному из параметру или одной группе аналогичных параметров.

Был создан скрипт, при помощи которого на базе многоуровневой модели создавались наборы «плоских» моделей.

Сначала выбирается параметр или группа параметров, определяющая «чувствительность» целевой модели. Затем создается новая целевая группа, куда копируются в автоматическом режиме все модели группы источника.

Далее для всех моделей из целевой группы производится анализ, состоящий в том, что в модели ищутся функции, имеющие более чем одну ассоциацию с моделями типа eEPC. При наличии на модели таких функций из списка ассоциированных моделей исключаются модели, реализующие функционал, отличный от заказанного, например другой транспорт. В списке остается единственная модель, реализующая нужный функционал.

Общесистемный функционал

Равно как и для прикладного функционала, в ряде случаев общесистемный функционал среды ARIS требует дополнительных настроек и доработок, исходя из выбранных постановок целевых задач моделирования и проектных решений по модели. Для удобства последующего изложения материала предлагается следующая систематизация рекомендуемых решений по общесистемному функционалу:

♦ решения по визуализации и настройкам;

♦ проектные решения;

♦ тестирование.

В рамках каждого из выделенных направлений рассмотрим следующие основные решения.

Решения по визуализации и настройкам

ARIS предлагает пользователю свой проводник (ARIS Explorer), дающий возможность доступа ко всем своим возможностям. Если баз в системе много и базы сложны по структуре, то только или разработчик, или высококвалифицированный эксперт сможет быстро сориентироваться в том объеме информации, который представлен на экране. Конечному пользователю, работающему с ограниченным, узко специализированным набором средств, такой объем информации не нужен (рис. 20, 21).

Рис. 20

Рис. 21

Оптимальным можно признать вариант, когда на экране компьютера конечного пользователя находится некая структура, прямо и однозначно связанная с тем функционалом, который этот пользователь выполняет или использует. Эта структура представляет для многих категорий пользователей общую точку доступа к специализированному функционалу, реализованному в моделях специальной базы (рис. 22).

Рис. 22

Разработчики применили для этого концептуально понятный графический образ «домика ARIS», нагрузив его узнаваемые разделы специальным функционалом. Функционал связан с названием раздела – «комнаты» «домика ARIS». Способ доступа прост и применяем в любой модели ARIS – клик мышкой на пирамидке справа внизу от объекта или выбор в окне «Object Windows» на закладке «Assignments».

Задание ролей и определение связи «должность – роль», исходя из штатной структуры подразделения, реализующего бизнес-процесс

Разработчики проекта исходили из того соображения, что конкретная бизнес-функция реализуется не конкретным исполнителем Иванов – Петров – Сидоров, находящимся на конкретной должности, а некоторой организационной единицей, которая в одной организации – техник, в другой – инженер, в третьей – менеджер или еще кто-то. По мнению разработчиков, модель на этапе разработки не должна быть привязана к конкретной штатно-должностной структуре. По этой причине функционал, реализованный в модели, выполняет некую РОЛЬ, с которой может быть связана в последующем любая совокупность исполнителей и штатных структур. Связывание РОЛЬ – ДОЛЖНОСТЬ – ИСПОЛНИТЕЛЬ должно происходить отдельно от модели и никак не влиять на ее (модели) структуру и состав.

Проектные решения

Подключение библиотек настроек организационно-технологической структуры

В соответствии с соглашениями о моделировании в модели используется парадигма (система понятий) – роль. Именно роль выполняет бизнес-функцию, является ее хозяином. Именно роль является элементом окружения практически любой функции (рис. 23).

Рис. 23

Для связывания ролей с должностями и конкретными исполнителями применяется механизм создания организационной модели. Создается модель типа Organization Charts. Элементами ее становятся объекты типа Person Type (роли). Далее создается еще одна модель типа Organization Charts, на ней располагаются иерархически организованные объекты типа Organization Unit (подразделение) и Position (должность) (рис. 24).

Рис. 24

И наконец, последний этап – формируется модель типа Organization Charts, на которой располагаются объект Position (должность) и связанный с ним набор объектов типа Person Type (роль). Мы получаем модель, определяющую зависимость подразделение – его должностной состав, а для каждой должности – ее исполнителя и список обязанностей (ролей), которые исполнитель по решению или кадровых органов, или менеджера по прикладному функционалу должен выполнять.

Еще одним элементом окружения практически любой функции являются информационные системы, средства которых используются для целей автоматизации учета, контроля, информационного взаимодействия и т. п.

Для представления структуры информационных систем применяются модели типа Application System Type, элементами которых являются выстроенные в иерархическом порядке объекты типа Application System Class (класс прикладной системы), Application System Type (прикладная система), классы информационных сервисов, информационные сервисы, ИТ-функции, классы модулей и модули. Пример модели типа Application System Type приведен на рис. 25. Объекты этой модели имеют многоуровневую детализацию – ассоциации, позволяющие в конечном итоге получить подробное представление об информационной среде функции на модели.

Рис. 25

Создание и подключение библиотек специализированных расчетных алгоритмов (модулей) затрат

Стандартная конфигурация ARIS позволяет производить многие виды стоимостных и прочих затратных (время, ресурсы) расчетов. Опции ABC и Simulation рассчитывают минимальные, максимальные и средние значения затрат многих видов ресурсов. Как уже упоминалось, для того чтобы получить коррелированные данные, надо долго и тщательно готовить модели. Получаемые отчеты очень подробны, содержат много ценной информации, но чтобы из нее выделить нужное, требуется дополнительная обработка отчетов при помощи дополнительных инструментов – как правило, статистического анализа. Однако далеко не всегда пользователь располагает знанием, временем, навыками, необходимыми для выполнения всего комплекса подготовительных и прочих мероприятий. Часто пользователей или интересуют очень специальные данные, которые нерационально долго извлекать, пользуясь стандартным вычислительным аппаратом, или данные выдаются не в том разрезе, который нужен. Для решения узких, специальных задач более рациональным может оказаться создание специализированных расчетных модулей, дающих результат много быстрее и с меньшими издержками. Например, создан скрипт, который выполняет:

♦ присвоение значений некоторым атрибутам функций типа Times и Cost (максимальные, минимальные или средние значения соответствующих затрат);

♦ присвоение значений некоторым атрибутам типа Free attributes (специальные расчетные параметры, отсутствующие в стандартной поставке, но интересные для прикладного применения);

♦ присвоение значений некоторым атрибутам связей между функциями, оргединицами и информационными системами (число работников, процент использования – загрузка различных ресурсов).

Запуск прохождения по модели с указанными атрибутами и расчет с выдачей протокола затрат времени, средств по пройденному «маршруту»

Пример кода, реализующего некоторые из этих действий, приведен в приложении 2. Это функции Function secs(ss As Variant) As Long, Function time_count(sss As Double) As String и процедура Sub Count.

Также создан скрипт, выполняющий расчет зависимости затрат времени и денежных средств от загрузки средств информационной системы при прохождении по специфицированному «маршруту». Будучи выведенным в формате Excel, отчет позволяет получить диаграммы, наглядно показывающие тенденции в использовании тех и или иных информационных систем в бизне^процессах.

Связь между моделью «как есть» и «как должно быть» (независимая база, варианты)

Цели модернизации, актуализации базы, оптимизации процессов предполагают действия по изменению структуры базы, составляющих ее моделей, связанных с моделями объектов и т. п. Базу моделей из состояния «как есть» стремятся перевести в состояние «как будет», «как должно быть» – путем оптимизации процессов по структуре, времени выполнения, порядку распределения ресурсов и т. д. Этого эффекта достигают путем введения дополнительных типов ресурсов, информационных систем и т. п. Оптимизации осуществляются путем применения модуля Simulation. Изменения моделей проводятся, как правило, путем создания копий моделей и последующих их (моделей) модификаций. Копирование моделей производится или вручную, или через механизм «вариантов». Для сохранения унаследованных от моделей-источников связей применяют копирование или «варианты» через использование occurrences моделей и объектов на них. Это сохраняет унаследованные связи. Правда, сразу возникает проблема – изменение объектов модели-приемника сразу же изменяет и модель-источник, что далеко не всегда устраивает разработчика. Приходится копировать модели как Copy

Definitions, это позволяет вносить изменения, не затрагивая модель-источник, но в этом случае – новая проблема – теряются связи объектов. Приходится их восстанавливать вручную, что требует много времени, внимания и чревато ошибками. Были разработаны скрипты, в автоматическом режиме выполняющие функционал копирования моделей с сохранением, где надо, связей.

Один из скриптов уже описан в разделе «Сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры».

Как известно, Simulation при выполнении может проанализировать только те функции, которые имеют одну и только одну ассоциацию с моделью типа eEpc. Если ассоциаций больше, то процесс Simulation «зависает». Был разработан скрипт, который так корректирует структуру модели, что она (модель) удаляет лишние не нужные для бизнес-процесса связи, сохраняет связи с нужными для бизнес-процесса моделями и источниками данных. Этот скрипт применяется к группе, копируя в целевую группу все модели группы-источника, и дополнительно выполняет следующий функционал:

♦ в диалоговом режиме запрашивает параметр, определяющий «чувствительность» целевых моделей, например тип транспорта;

♦ в автоматическом режиме копирует модели группы как Copy Occurrences;

♦ в цикле для каждой модели проверяет наличие на ней функций, имеющих ассоциации с eEPC-моделями, чувствительными по выбранному параметру, например по типу транспорта;

♦ при наличии таких функций:

– создается новое definition (определение) функции;

– атрибуты новой функции делаются такими же, как у функции-источника;

– из списка ассоциаций новой функции удаляются ссылки на модели, не удовлетворяющие выбранному параметру (остается только ссылка на модель, имеющая атрибут чувствительности по транспорту, равный выбранному);

– создается новое occurrence (представление) новой функции;

– создаются новые occurrences (представления) связей между occurrence (представлением) новой функции и occurrences (представлениями) объектов, составляющих окружение функции-источника;

– удаляется «старое» occurrence функции на модели.

В итоге автоматически, быстро, очень корректно и безошибочно получаем группу моделей, сохранивших связи с моделями, независимыми от, например, транспорта.

Такие группы моделей после соответствующей подготовки (назначения вероятностей событиям или формирования диаграмм событий, формирования дополнительных моделей, например графиков смен) можно оптимизировать Simulation или анализировать другими стандартными средствами ARIS (ABC или Balanced Scoreboard).

Формирование чувствительности документов

Документы в любом виде – печатном или электронном – представляют собой или элементы нормативной системы, придающей бизнес-процессам легитимность, или элементы оперативной среды, обеспечивающие процедурную, смысловую поддержку бизнес-процессов. Группирование документов на нормативные и оперативные – логичная и повсеместно применяемая практика моделирования бизнес-процессов. Часто бывает оправданной или даже необходимой дальнейшая, более подробная группировка. Например, нормативные документы делятся на законы, приказы, кодексы, распоряжения и т. д., а оперативные – на коммерческие, государственные, ведомственные и т. д. Кроме того, в зависимости от особенностей протекания бизнес-процессов документы должны группироваться по многим другим признакам. Таким образом, становится актуальной проблема – сделать документы «чувствительными» к режимам функционирования, к особенностям протекания бизнес-процессов.

Чтобы сделать документы «чувствительными» к режимам функционирования бизнес-процессов, применяется механизм назначения определенным атрибутам документов специальных значений, закрепленных в Соглашении о моделировании.

Например, значение атрибута документа Identifier= «DOC_NP_*» «делает» документ нормативным, а «DOC_OP_*» – оперативным. Добавление постфикса вместо символа «*» позволяет ввести дополнительную градацию. Например, «PSM» – это письма, а «LAW» – законы и т. д. На рис. 26, 27 приведены примеры применения такой практики к документам.

Рис. 26

Рис. 27

Для задания чувствительности документов к, например, типу товара, некоему режиму и типу транспорта происходит присвоение атрибутам документа «User attribute Text 1», «User attribute Text 2» и «User attribute Text 3» специальных значений, определенных в «Соглашении о моделировании» в соответствующей, также согласованной нотации. Пример применения этих соглашений приведен на рис. 28.

Рис. 28

В процессе работы специально разработанных скриптов происходит анализ атрибутов документов из окружения функции, и, если совокупность атрибутов документа соответствует совокупности атрибутов, определяемых при выборе входных параметров скрипта (тип товара, таможенный режим, тип транспорта), документ помечается цветом при проходе по модели и его название помещается в выходной отчет.

Тестирование

Создаваемые в процессе моделирования диаграммы должны удовлетворять спецификациям ARIS по структуре, синтаксису, другим согласованным требованиям. Соответствие этим требованиям проверяется при помощи скриптов семантического анализа среды ARIS. Нужно признать, что разработчики часто отходят от соглашений ARIS, создавая диаграммы в соответствии со своими «Соглашениями о моделировании». В этом случае семантическая проверка ARIS применяется в ограниченном режиме. Проблемы же корректности моделей решаются путем написания и запуска на моделях тестирующих скриптов, учитывающих особенности «своих» «Соглашений о моделировании».

Например, при потоковом тестировании моделей при формировании помеченного «маршрута» применялись генераторы случайных чисел, с помощью которых формировались случайные условия на входе и случайные условия в процессе формирования «маршрута».

Формирование случайных сочетаний параметров входных условий

При формировании входных параметров использовались случайным образом выбранные тип товара, некий режим, тип транспорта. В приложении 2 приведен пример кода, формирующего случайным образом тип транспорта. Это Function seltransrand() As String.

Формирование случайных сочетаний принимаемых бизнес-решений

Описание механизма формирования на модели точек принятия бизнес-решений подробно дано в разделе «Интерактивный режим прохождения в реальном масштабе времени бизнес-процесса с учетом заданных параметров входных условий и принятия бизнес-решений». Механизм формирования случайных наборов бизнес-решений использует точки принятия решений, описанные выше. Но в отличие от интерактивного режима, заменяет интерактив применением случайного сгенерированного числа, как индекса в массиве альтернатив выбора бизнес-решения.

Потоковое тестирование и анализ модели на основе случайно заданных параметров входных условий и чисел

Потоковое тестирование применено для практически безынтерактивного циклического обхода моделей с пометкой пройденного маршрута и генерацией отчета о сделанных выборах – входных параметрах в начале каждого цикла и выбранных бизнес-решениях – в промежуточных точках принятия решений. Скрипт, реализующий данный функционал, в цикле производил случайные выборы и использовал их при формировании случайного «маршрута».

Специализированные проверки составных элементов модели

Иногда нет необходимости проводить анализ всей модели. Часто нужно проанализировать свойства одного или нескольких объектов разного типа на модели или его связи (входящие и исходящие). Для этого применялась система небольших скриптов, запускаемых на объектах и выполняющих только очень узкий специализированный функционал.

Интеграционные решения

Специфика постановок задач и реализующих их проектных решений в ряде случаев не может быть эффективно учтена в рамках использования стандартных возможностей ARIS либо «авторских» доработок исполнителя. Принципиально среда ARIS позволяет обеспечить соответствующую интеграцию с другими средствами моделирования и широко распространенными технологиями в части:

♦ форматов загрузки, выгрузки информации;

♦ использования специализированного функционала.

Стандартно ARIS предоставляет средства взаимодействия с другими CASE-средствами разработки и поддержки моделирования бизнес-процессов. Назначение этих средств – обмен отдельными моделями с другими программными CASE-системами посредством файлов, записанных в XML-кодах. Этот обмен осуществляется при помощи специальных программ-интерфейсов сторонних производителей, например компании Reischmann Informatik GmbH (RI) (). В настоящее время интерфейсы TOOLBUS компании RI поддерживают больше чем 30 инструментальных CASE-средств. Посредством этих интерфейсов можно произвести обмен данными между ARIS и такими CASE-си-стемами, как ErWin от СА, PowerDesigner от Sybase и OracleDesigner. Обмен может быть произведен в обоих направлениях.

На взгляд авторов, одним из перспективных направлений по интеграции возможностей ARIS с «внешними» технологиями может быть наработка постановок задач и поддерживающих их проектных решений применительно к MSProject.

Одной из имеющих «право на жизнь» постановок задач в рамках моделирования бизнес-процессов предприятия является анализ загрузки кадровых ресурсов. MSProject в силу приоритетности данной задачи для управления проектами имеет очень развитую функциональность в части контроля и отображения всех процессов, связанных с использованием ресурсов.

В частности, данным средством поддерживаются такие полезные функции, как расчет оптимальной загрузки персонала при выполнении проектов, диалоговый режим формирования условий оптимизации загрузки персонала, быстрое формирование стандартных отчетов и некоторые другие.

Поэтому целесообразной видится реализация следующей технологической схемы совместного использования ARIS и MSProject:

♦ из ARIS «выгрузить» в формате Excel информацию по ресурсам для MSProject;

♦ загрузить в MSProject информацию по ресурсам в формате Excel;

♦ в MSProject в рамках использования стандартного функционала получить требуемую информацию (результаты) по контролю и анализу загрузки ресурсов;

♦ преобразовать результаты, полученные в MSProject, в форматы, совместимые с ARIS (как правило, это формат Excel);

♦ загрузить результаты в формат Excel в разработанную модель ARIS с последующим подключением к соответствующему функционалу, предоставляемому комплексной моделью.

Специально разработанные модули, которые могут поддержать данную технологическую схему, могут быть следующего вида:

♦ скрипт выполняет формирования в формате Excel четырех рабочих листов специальной структуры, «понятной» программе-приемнику. Для формирования 1-го листа скрипт «проходит» по модели, формируя для каждой посещенной функции данные в следующем формате – «ID», «Функция», «Длительность», «Предшественник», «Уровень структуры». На 2-м листе должны формироваться данные по исполнителям. На 3-м листе должны формироваться данные по загрузке исполнителей. На 4-листе должна присутствовать идентификационная информация MSProject. Она формируется предварительно и добавляется в выходной файл, созданный скриптом «вручную»;

♦ ассоциированные модели преобразуются в «вехи» MSProject (веха не имеет длительности и ресурсов).

В рамках аналогичного подхода (предложенной технологической схемы) могут быть реализованы задачи по временной и стоимостной оценке бизнес-процессов с использованием функциональных возможностей MSProject, а именно:

♦ определение критического пути;

♦ выработка рекомендаций по оптимизации загрузки персонала.

Достаточно интересным может быть интеграционное решение, которое, в отличие от вышерассмотренного случая, направлено не на дополнение функциональных возможностей ARIS за счет MSProject, а наоборот – на использование ARIS для решения целевых задач MSProject.

Заключение

Общая задача, которая ставилась авторским коллективом перед написанием книги, – аргументированно показать, с одной стороны, актуальность и эффективность внедрения механизмов описания бизнес-процессов в деятельность организации в современных условиях, а с другой – сложность процесса построения действительно полезных для практики бизнес-моделей.

Достаточно затруднительно дать собственную оценку того, насколько убедительна была аргументация необходимости и неизбежности вхождения моделирования бизнес-архитектуры в «культуру управления» предприятий, стремящихся максимально соответствовать современным международным стандартам. Вместе с тем хотелось бы отметить тот факт, что за период работы над книгой члены авторского коллектива неоднократно привлекались к исполнению нескольких проектов по бизнес-моделированию со стороны различных государственных и коммерческих структур. Кроме того, состоялось большое количество контактов с заинтересованными заказчиками, которые в силу текущих организационных и финансовых ограничений не смогли обеспечить старт проекта в текущем периоде.

Особо следует отметить, что данные события были не только «спровоцированы» активностями потенциальных исполнителей по ознакомлению с возможностями и ожидаемыми результатами по разработке бизнес-моделей по внедрению в деятельность организации, но и имели независимые причины, обусловленные повышенным интересом рынка к данному виду услуг.

В той же мере авторскому коллективу затруднительно оценить, насколько полно нашла отражение в книге сложность процесса построения реально востребованных бизнес-моделей. Так или иначе, в заключение хотелось бы еще раз подчеркнуть организационную и технологическую проблематику создания моделей.

Можно взять на себя смелость утверждать, что из всех консалтинговых проектов, в том числе ИТ-направления, бизнес-моделирование является лидером по таким параметрам, как:

♦ значительное количество разнородных специалистов, роль каждого из которых имеет критичное значение для успеха проекта: юристы, производственные технологи, кадровые сотрудники, ИТ-специалисты и т. д.;

♦ обширный состав заинтересованных подразделений заказчика, которые являются потенциальными пользователями системы;

♦ необходимость поддержки в актуальном состоянии разработанной бизнес-архитектуры.

По этой причине организационные проблемы, включающие подбор компетенций, распределений ролей по проекту, планирование активностей, то есть управление проектом, во многих случаях могут стать основной причиной неудач и снивелировать высокие технологические возможности недостаточно подготовленного в организационном аспекте исполнителя.

В этой же плоскости организационных проблем лежит и четкая постановка задач, увязанная с готовностью заинтересованных подразделений заказчика обеспечить синхронную работу по проекту.

Технологическая проблематика связана с тем, что далеко не всегда декларируемые производителями возможности инструментальных средств могут быть реализованы на практике. Как правило, работы по каждому конкретному проекту требуют учета специфических условий и требований заказчика: постановок задач, реализации функционала, интеграции (взаимодействия) с информационными системами и т. д. По совокупности воздействия этих факторов исполнитель сталкивается с необходимостью «ручной» доработки используемой инструментальной базы, задействования и интеграции в общее решение других инструментальных средств, в которых тот или иной функционал реализуется более эффективно.

По этой причине предложенные в книге в виде организационно-технологических решений (рекомендаций) варианты обхода препятствий и «подводных камней», обусловленных объективно существующими ограничениями у используемой инструментальной среды, могут использоваться для сдвига с «мертвой» точки технологических проблем по проектам.

Следует отметить, что многие из представленных рекомендательных положений были выработаны авторским коллективом в результате практического исполнения масштабных работ по моделированию бизнес-процессов, и в этом смысле можно говорить о реальной их апробации.

На текущий момент «многопрофильность» проблематики построения формализованных бизнес-моделей не встречает адекватной готовности среды исполнения и внедрения.

Заказчики не знают в полной мере всех возможностей современных инструментальных средств моделирования, методологии использования моделей в практике управления развитием, потенциальных эффектов от внедрения бизнес-моделей в практику деятельности организации, условий для полномасштабного внедрения, особенностей поддержки процесса использования и т. д.

Исполнители зачастую по разным причинам позиционируются на использовании ограниченного функционала инструментальных средств моделирования, избегают решений, связанных с комплексированием различных взаимодополняющих по функционалу инструментальных средств, не в полной мере укомплектовывают исполнителей специалистами с разными компетенциями.

Дистрибьюторы инструментальных средств, позиционируясь на текущую недостаточно высокую эффективность их использования, не обеспечивают качественного уровня технической поддержки, не создают углубленных курсов обучения для опытных специалистов.

Отсутствие должного уровня консолидации основных участников, обеспечивающих формирование культуры и практики использования бизнес-моделирования в различных областях, является одной из главных причин, тормозящих процесс широкого распространения технологий управления на основе моделирования.

В этом смысле книга, ориентируясь на общий целевой результат, рассматривала проблематику разработки бизнес-моделей с разных позиций и участников процесса. Очевидно, что в такой постановке уже можно ожидать взаимопротиворечащих оценок относительно изложенных решений, поскольку существует определенная конфликтность интересов исполнителя, заказчика, дистрибьютора инструментальных средств.

Хочется отметить позицию авторского коллектива в отношении оценки перспектив развития инструментальных и методологических средств бизнес-моделирования.

В ближайшем времени следует ожидать существенного изменения роли и места инструментальных средств моделирования в общей системе организационно-технологического управления предприятием. Современный уровень функциональных возможностей инструментальных средств моделирования позволяет перейти от «пассивной» – описательной роли к «активной» – прикладной роли в качестве составного элемента систем автоматизированного управления.

Можно выделить в качестве основных следующие направления прикладного использования инструментальных средств моделирования:

♦ управление логикой взаимодействия автоматизированных информационных систем (АИС) в рамках информационно-технологической поддержки управления бизнес-процессом;

♦ организация экспертно-консультационной поддержки персонала в рамках непосредственного участия в бизнес-процессе;

♦ обеспечение протоколирования (в том числе юридически значимого) действия участников бизнес-процессов в ходе его исполнения.

Перечисленные направления реализуются на основе «комплексирования» ключевых возможностей современных инструментальных средств:

♦ обеспечение практически неограниченного уровня детализации формализованного описания бизнес-процессов (с охватом всем основных компонент – информационной, технологической, организационной);

♦ обеспечение интерактивных режимов взаимодействия с пользователями и «внешними» информационными системами.

Несомненно, что только за счет своих собственных технологических возможностей вышеперечисленные перспективные направления использования навряд ли могут быть реализованы. Очевидно, что потребуется разработка специализированных интегральных решений, в рамках которых будет осуществлено «дополнение» недостающих возможностей инструментальной среды моделирования.

Весьма интересной видится перспектива поиска интеграционных решений совместного использования современных систем управления информационными системами и инструментальных средств моделирования. На этом направлении можно ожидать появления новых проектов и изданий, касающихся новых сфер применения инструментария и методологии бизнес-моделирования.

Вполне вероятен и такой вариант развития событий, когда будет происходить совершенствование инструментальных средств моделирования в интересах обеспечения более высокой готовности к реализации вышеописанной «активной» деятельности предприятия.

В завершение хотелось бы выразить надежду, что даже при возможной неоднозначной оценке тех или иных положений книги общая реакция аудитории будет направлена на положительное понимание значимости, а главное, реализуемости в обозримой перспективе широких возможностей современных инструментальных и методологических средств для построения и использования формализованных бизнес-моделей в управлении деятельностью организации.

Приложения

Приложение 1

Основные термины и определения

Приложение 2

Примеры прикладного кода на Sax Basic

Приложение 3

Типовое техническое задание на разработку модели бизнес-архитектуры

1. Введение

Реализация проекта по оптимизации бизнес-процессов позволит полностью проанализировать все ключевые бизнес-процессы организации, выявить процессы, негативно влияющие на функционирование организации, и обеспечить их соответствующую модернизацию. Переработанные в результате выполнения проекта бизнес-процессы обеспечат сохранение и повышение качественных и количественных показателей функционирования организации с учетом растущей конкуренции и развивающихся технологий.

2. Название и назначение

2.1. Название

Полное название проекта: «Оптимизация и разработка бизнес-процессов организации».

2.2. Назначение

Назначением настоящей работы являются формализация и описание процедур, действий, документооборота и информационного взаимодействия, происходящего в организации при выполнении ее бизнес-задач. Результаты данной работы будут являться основой для стандартизации выполнения процедур и действий сотрудниками организации в процессе ее функционирования.

3. Цель и задачи

Целью настоящего технического задания является обеспечение условий для развития бизнеса организации, а также минимизации временных и материальных затрат, связанных с ее функционированием.

Для достижения поставленной цели должны быть решены следующие задачи.

1. Построение полнофункциональных моделей процедур функционирования организации с использованием инструментальных средств описания моделей бизнес-процессов как есть и как должно быть в случае их оптимизации.

2. Внедрение основанного на применении инструментальных средств описания моделей бизнес-процессов механизма разработки технологических схем, инструкций для сотрудников организации, а также описания проектов (экспериментов), направленных на оптимизацию выполнения процедур функционирования организации.

3. Обеспечение условий для разработки методологического и информационного обеспечения бизнес-процессов организации, в том числе в целях создания и внедрения информационной составляющей в бизнес-процессы.

4. Ожидаемый эффект

В результате выполнения работ ожидается обеспечить:

♦ систематизацию знаний об организации выполнения бизнес-процессов;

♦ систематизацию знаний о принципах автоматизации бизнес-процессов, с учетом в том числе мировой практики;

♦ системный и аргументированный подход к формализации бизнес-процессов организации;

♦ механизм оптимизации и разработки бизнес-технологий;

♦ условия для оптимизации бизнес-процессов организации, а также их автоматизации;

♦ механизм разработки технологических схем, инструкций для сотрудников организации, а также описания проектов (экспериментов), направленных на оптимизацию выполнения процедур функционирования организации;

♦ условия для оптимального распределения имеющихся ресурсов организации на наиболее важных и приоритетных направлениях бизнеса.

5. Требования к разработке

5.1. Общие требования

В настоящей работе должны быть учтены опыт разработки моделей бизнес-процессов в государственных органах и иных организациях, а также передовой опыт зарубежных стран в данной области.

5.2. Функциональные требования

Работа по реализации задания должна затронуть функции, связанные с деятельностью организации.

При моделировании процессов должны быть описаны функции и действия сотрудников, осуществляемые в процессе функционирования организации, взаимодействие структурных подразделений, документооборот, информационный оборот, а также контрольные и учетные меры. Модели выполнения операций должны быть описаны на уровне детализации действий сотрудников организации.

Модель процессов организации как есть (as is) должна отражать применяемые процедуры, операции, функции и действия сотрудников организации в соответствии с действующими в организации нормативными правовыми документами.

Модель процессов организации как будет (as to be) должна отражать применение основных операций, функции и действия сотрудников организации в случае их максимального взаимного согласования между собой, а также их оптимизации по временным, материальным, контрольным показателям. Данная модель может предполагать внесение соответствующих изменений в нормативные правовые акты, действующие в организации. При этом не должны быть пересмотрены основные функции организации, а также основные принципы ее функционирования.

5.3. Общие требования к разработке модели и формализованному описанию процессов

Под моделью понимается представление существующих процессов организации с целью описания их ключевых характеристик. Объектом моделирования (предметной областью) являются организационная структура, цели и функции, материальные и информационные потоки, технология бизнес-процессов организации, данные и знания сотрудников организации, необходимые для их выполнения, а также существующие в организации интегрированная телекоммуникационная сеть и программное обеспечение.

Построение полнофункциональной модели описания процессов организации предназначено для:

а) отражения текущего состояния процессов организации (как есть) в целях:

– выявления и локализации существующих проблем;

– оценки организационных, функциональных, информационных и экономических параметров;

– автоматизации процессов;

– структурирования и формализации знаний организации;

– создания условий для оптимизации выполнения основных процедур;

б) моделирования изменений состояния процессов организации в целях:

– оценки организационных, функциональных, информационных и экономических параметров планируемых изменений;

– поддержки принятия решений руководством организации;

в) создания системы оценки процессов организации в целях:

– формирования методического и нормативного документационного обеспечения деятельности организации;

– контроля соответствия документации и реального состояния процессов организации.

Для однозначной интерпретации модели должны применяться единые принципы структурирования и хранения информации, а также размещения и именования моделируемых объектов.

Основными принципами моделирования должны являться следующие:

♦ процессы организации должны быть смоделированы в модели «как есть» и проанализированы;

♦ критические изменения в процессах или структуре организации должны быть предварительно промоделированы и оценены;

♦ версии моделей должны храниться в архиве моделей для анализа истории и выявления тенденций внутреннего развития организации;

♦ моделирование выполняется на основе процессного подхода;

♦ основными источниками информации для построения модели являются внутренние нормативные правовые документы организации;

♦ построение критических по значимости моделей оформляется в форме отдельного проекта.

При этом под процессом должен пониматься набор связанных по входу функций, производящих законченный продукт (результат).

Приоритеты моделирования расставляются в соответствии с типами процессов:

♦ основные процессы;

♦ вспомогательные (автоматизация, контроль, правовое обеспечение и т. д.) процессы, обеспечивающие нормальное выполнение основных процедур и изменять в зависимости от изменения состава и технологии основных процессов;

♦ обеспечивающие процессы, процессы внешнего взаимодействия и процессы развития (см. главу 2).

В модели должны быть выделены пять представлений:

♦ представление организационной структуры исполнителей процессов;

♦ представление действий, участвующих в процессах;

♦ представление функций процессов;

♦ представление информационного взаимодействия;

♦ представление информационных данных процессов.

Каждое представление должно содержать диаграммы для моделирования деятельности организации (модель деятельности) и диаграммы для моделирования автоматизации деятельности (модель автоматизации деятельности).

Под комплексной моделью должна пониматься совокупность согласованных диаграмм, отражающих ключевые характеристики процессов организации. Все диаграммы хранятся в единой базе, обеспечивая целостность модели. По базе модели возможно построение производных моделей и различных настраиваемых отчетов, в том числе и в формате официальных документов.

Авторские соглашения должны определять:

♦ правила именования объектов модели;

♦ представления и диаграммы комплексной модели;

♦ структуру представления процессов;

♦ использование атрибутов диаграммы;

♦ использование атрибутов функций;

♦ использование атрибутов событий;

♦ использование атрибутов документов;

♦ использование атрибутов организационных единиц.

Под метамоделью структуры должна пониматься карта комплексной модели, обеспечивающая независимость от структуры физических папок базы модели. Метамодель должна определять необходимое число уровней вертикальной детализации комплексной модели в соответствии со структурой организации: уровень целей и задач, уровень технологических процессов, уровень бизнес-процедур, уровень технологических операций. На уровне должностей должны выделяться подуровни должностных (что?) и рабочих (как?) инструкций с указанием элементарных операций.

Формализованное описание процессов организации должно отражать:

♦ условия, порождающие выполнение процесса в целом и отдельных его шагов (подпроцессов);

♦ результаты выполнения процесса и критерии оценки качества процесса;

♦ структуру процесса (от четырех до восьми подпроцессов на один процесс верхнего уровня);

♦ состав участников процесса (привязка шагов процесса к звеньям организационной структуры / должностным лицам);

♦ используемые ресурсы;

♦ информационные и материальные потоки;

♦ используемые хранилища данных, в том числе нормативно-справочной информации (содержательное наименование, без детализации структуры);

♦ точки контроля и принятия решений.

Модель и ее оценки должны являться формализованной основой для принятия своевременных и адекватных решений на любом уровне ответственности. Должны оцениватьтся как модель текущей деятельности, так и планируемые изменения. Изменения могут быть вызваны как внутренними причинами, так и внешними.

При оформлении документ модели должен состоять из диаграмм, расположенных в одной папке дерева комплексной модели, отчетов по модели и листа утверждения.

В ходе разработки модели важным моментом является определение в работе организации недостатков, которые могут привести к коррупционным явлениям. Исполнитель должен указать возможные пути уменьшения или устранения влияния выявленных недостатков, а также наиболее приемлемые индикаторы состояния системы, позволяющие определить в дальнейшем, является ли процесс достаточным и эффективным.

5.4. Требования к информационному обеспечению процессов

Описание информационных объектов формализованной модели процессов организации должно содержать, как минимум, следующие элементы:

♦ наименование объекта;

♦ назначение;

♦ направление деятельности, в рамках которого происходит использование;

♦ атрибутный состав объекта;

♦ исполнителя каждого атрибута;

♦ на основании какой информации заполняется каждый атрибут.

5.5. Требования к организационному обеспечению

В рамках создания формализованного описания процессов необходимо подготовить материалы для разработки создания автоматизированной системы – организационного обеспечения этих процессов. Такие материалы должны включать:

♦ перечень подразделений, участвующих в процессах;

♦ таблицу распределения функций подразделений в рамках этих процессов;

♦ таблицу входящих и исходящих информационных объектов (документов) по подразделениям.

5.6. Требования к нормативно-законодательному обеспечению

В рамках оптимизации процессов может быть выявлена необходимость внесения изменений и дополнений во внутренние нормативные правовые документы организации. Отчет об аналитическом обследовании должен включать предложения по внесению таких изменений.

5.7. Требования к интеграции

Результаты настоящей работы станут основой для организации иных работ, связанных с совершенствованием бизнес-процессов организации. Для интеграции проводимых работ необходимо обеспечить тесное взаимодействие заказчика и исполнителя. Для этого будет создана координационная группа, возглавляемая представителем заказчика. Исполнитель по настоящему заданию обязан принимать участие в работе координационной группы, в том числе:

♦ участвовать в планировании совместных/взаимосвязанных работ;

♦ своевременно предоставлять промежуточные материалы и информировать о ходе выполнения работ.

5.8. Требования по обеспечению непрерывности рабочих процессов

При разработке процедур необходимо составить перечень внештатных ситуаций, которые могут привести к невозможности выполнения этих процедур по стандартному сценарию. Для этих ситуаций должны быть разработаны резервные сценарии, обеспечивающие непрерывность выполнения функций, связанных с функционированием организации.

6. Требования к составу работ

Состав работ в рамках настоящего задания включает следующие работы.

1. Анализ внутренних нормативных правовых документов организации.

2. Разработка моделей процессов организации в разрезе «как есть».

3. Разработка моделей процессов организации в разрезе «как будет».

4. Консультационные услуги при внедрении инструментальных средств для описания моделей процессов организации.

5. Разработка предложений по новым внутренним нормативным правовым документам организации.

6. Разработка методики (инструкций) по новому порядку осуществления процедур организации.

7. Разработка программы и проведение обучения сотрудников организации новым процедурам.

8. Обучение сотрудников в рамках внедрения инструментальных средств для описания моделей процессов организации.

7. Требования к отчетным материалам

В результате проведенной работы должны быть подготовлены следующие отчетные материалы:

♦ формализованные модели, отражающие функциональный, информационный, организационный и нормативно-законодательный аспекты процессов организации;

♦ предложения по сокращению количества документов организации и предотвращению дублирования содержащейся в них информации;

♦ материалы и программа, обеспечивающие механизм разработки модели выполнения процедур, основанный на применении инструментальных средств описываемых моделей;

♦ предложения, в том числе проекты внутренних нормативных правовых документов и иных документов для обеспечения модернизированных процессов, совершенствования и оптимизации, в том числе за счет автоматизации процессов, перехода на электронный документооборот в практической деятельности организации;

♦ после завершения выполнения каждой из работ, поименованной в параграфе 6 этого раздела, консультант должен подготовить соответствующий промежуточный отчет и акт приема-передачи работ, одобренный заказчиком. Указанные документы будут использоваться в процессе осуществления платежей;

♦ подготовка презентационных материалов по моделям процессов организации в разрезе «как есть» и «как должно быть».

Все программное обеспечение, оборудование и обучающие программы, используемые исполнителем для подготовки бизнес-моделей, передаются заказчику по окончании работ.

Приложение 4

Структура типового Соглашения о моделировании

Список рисунков Список таблиц

Перечень сокращений, условных обозначений, терминов

1. Введение (о назначении документа)

2. Общие положения

Цели, задачи и область моделирования

Используемые инструментальные средства моделирования

Общие принципы и подходы к моделированию

Ограничения и допущения

Уровни моделирования

Классификаторы

3. Организация хранения моделей в базе ARIS

4. Синтаксические и семантические правила создания моделей

5. Визуализация моделей в инструментальной среде ARIS Стартовая модель

Модели бизнес-процессов Модели данных и документов Модели знаний и полномочий Организационные модели Программные системы Технические ресурсы Функциональные модели Модели продуктов и услуг

6. Настройки среды моделирования Настройка языка базы данных Настройка фильтра моделей

Настройка внешнего вида модели (стрелок, сетки, используемого шаблона, размещения текста в объекте)

Настройка объектов (размера, цвета)

Настройка шрифтов текстовых атрибутов объектов

Настройка пользовательских наименований атрибутов

Приложение 5

Базовые определения уровня зрелости предприятия на основе процессного подхода

В соответствии с методикой оценки уровня зрелости управления процессами на предприятии выделяют два измерения эталонной модели: измерение «процесс» и измерение «зрелость».

В модели имеется шесть уровней зрелости, включающих девять атрибутов процессов.

Уровень 0: Неполный (Incomplete). В целом процесс не соответствует своему назначению. Рабочие продукты и итог процесса отсутствуют, или их невозможно выявить.

Уровень 1: Выполняемый (Performed). Процесс в целом соответствует своему назначению. Его выполнение не может быть строго запланировано и отслежено. Сотрудники организации знают, что мероприятие должно быть осуществлено, и существует общее соглашение, что это мероприятие осуществляется как и когда следует. Существуют выявляемые рабочие продукты процесса, и это свидетельствует о достижении результата.

Уровень 2: Управляемый (Managed). Процесс дает рабочие продукты в соответствии с определенными процедурами, а также планируется и отслеживается. Рабочие продукты соответствуют определенным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что теперь процесс дает рабочие продукты, которые соответствуют явным требованиям к качеству, при заданных ограничениях по времени и ресурсам.

Уровень 3: Устоявшийся (Established). Процесс осуществляется и управляется с использованием определенного процесса на основе надлежащих принципов разработки программных средств. Индивидуальные реализации процесса используют для получения заданного результата процесса принятые и адаптированные к конкретной ситуации версии стандартного, полностью документированного процесса. Также наличествуют ресурсы, необходимые для определения процессов. Основное отличие от уровня 2 состоит в том, что процесс уровня 3 использует заданный процесс, способный достичь определенных для него результатов.

Уровень 4: Предсказуемый (Predictable). Заданный процесс на практике осуществляется в предписанных рамках для достижения определенных целей процесса. Собираются и анализируются детализированные результаты измерений производительности. Это ведет к количественному пониманию возможностей процесса и повышенной способности к предсказанию производительности и управлению ею. Количественно известно качество продукта. Основное отличие от уровня 3 состоит в том, что заданный процесс осуществляется в предписанных рамках для достижения результатов процесса.

Уровень 5: Оптимизируемый (Optimizing). Производительность процесса оптимизируется для соответствия текущим и будущим бизнес-потребностям, и процесс регулярно достигает определенных для него бизнес-целей. Устанавливаются количественные ориентиры (цели) по эффективности выполнения процесса в соответствии с бизнес-целями организации. Постоянный мониторинг продвижения процесса к этим целям основывается на количественной обратной связи, а его усовершенствование основывается на анализе его результатов. Оптимизация процесса включает апробирование инновационных идей и технологий и изменение неэффективных процессов для приведения в соответствие с заданными целями и ориентирами. Основное отличие от уровня 4 состоит в том, что процесс определенный и стандартный, претерпевает постоянные уточнения и улучшения для соответствия текущим и будущим бизнес-целям.

Литература

1. Appel W. Enterprise Architecture: An In-Depth Study. 2003 // .

2. Stack С. Managing Enterprise Architecture Artifacts and Assets, презентация на Enterprise Architect Summit, June, 2004. /

3. Материалы 4-й Международной практической конференции «Эффективный документооборот в управлении бизнесом», 11–12 декабря 2006 г., Москва.

4. Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «ян» информационных технологий предприятия. Серия «Архитектор информационных систем» // Интернет-университет информационных технологий, . М., 2005.

5. Агсhitecting Bisness Process From Models To Real Flows. – Gartner, 2003.

6. A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1), GA0-03-584G.

7. Стратегия развития и использования информационных и коммуникационных технологий в Российской Федерации.

8. Business Models: The Architecture That Pays for Itself. – Gartner, 2002.

9. GAO. Information technology. Enterprise Architecture Use across the Federal Government Can Be Improved. 2002, February.

10. The Pillars of Enterprise Architecture Terminology, Giga, 2002.

11. Downes L., Mui C. Unleashing the Killer App: Digital Strategies for Market Dominance – Harvard Business School Press.

12. Enterprise Architecture: The Business Issues and Drivers. – Gartner, 2002.

13. Ахо А., Ульман Дж. Теория синтаксического анализа, перевода и компиляции. Синтаксический анализ. – М.: Мир, 1986. Т. 1.

14. МЕТА Group. Enterprise Architecture Desk Reference, 2002.

15. Schulman J. Defining «Good Enough» Architecture // Gartner Research Note COM-20-2743.

16. Malan, Ruth and Bredemeyer Dana. Less is More with Minimalist Architecture. IEEE Computer Society. IT Professional.

17. Obtaining management Buy-In for Enterprise Architecture. – Gartner, 2002.

18. Брауде Дж. Э. Технология разработки программного обеспечения. – СПб.: Питер, 2004.

19. Манифест (Чемен).

20. Книга по проектному офису (взять у Зуевой). УТОЧНИТЬ!!!!!!

21. ISO 15704.

22. ISO 15288.

23. ISO 12207.

24. ISO 14258.

25. ИСО 9000:2000.

26. Материалы 4-й Международной практической конференции «Эффективный документооборот в управлении бизнесом», 11–12 декабря 2006 г., Москва.

27. Абутидзе З. С. и др. Управление качеством и реинжиниринг организаций. – М.: Логос, 2003.

28. Ален Пол Х. Реинжиниринг банка. Программа выживания и успеха. – М.: Альпина Паблишер, 2002.

29. Балабанов И. Т. Инновационный менеджмент. Прогнозирование. Реинжиниринг. Бенчмаркинг. – СПб.: Питер, 2001.

30. Гританс Я. М. Организационное проектирование и реструктуризация (реинжиниринг) предприятий и холдингов: экономические, управленческие и правовые аспекты: практическое пособие по управленческому и финансовому консультированию. – М.: Волтерс Клувер, 2005.

31. Кутелев П. В., Мишурова И. В. Технология реинжиниринга бизнеса. – М.: МарТ, 2003.

32. Медынский В. Г., Ильдеменов С. В. Реинжиниринг инновационного предпринимательства. – М.: Юнити, 1999.

33. Николенко Н. П. Реинжиниринг во имя клиента. – М.: Страховое Ревю, 2003.

34. Оболенски Н. Практический реинжиниринг бизнеса. – М.: Лори, 2004.

35. Оголева Л. Н., Чернецова Е. В., Радиковский В. М. Реинжиниринг производства. – М.: КноРус, 2005.

36. Ойхман Е. Г., Попов Э. В. Реинжиниринг бизнеса. – М.: Финансы и статистика, 1997.

37. Робсон М. Реинжиниринг бизнес-процессов: практическое руководство. – М.: Юнити, 2003.

38. Сгибнев А. В. Информационные технологии и реинжиниринг бизнес-процессов в российских условиях. – М.: КомКнига, 2005.

39. Сусуму С., Хиромицу К. Реинжиниринг окружающей среды. – М.: Бизнес-пресса, 2002.

40. Тельнов Ю. Ф. Реинжиниринг бизнес-процессов. – М.: Финансы и статистика, 2005.

41. Тютюнник А. В. Реинжиниринг кредитных организаций. Управленческая аналитическая разработка. – М.: БДЦ-пресс, 2003.

42. Уткин Э. А. Бизнес-реинжиниринг. – М.: Экмос, 1998.

43. Хаммер М., Чампи Д. Реинжиниринг корпорации: Манифест революции в бизнесе. – Издательство «Манн, Иванов и Фербер», 2006.

44. Черемных О. С., Черемных С. В. Стратегический корпоративный реинжиниринг: процессно-стоимостной подход к управлению бизнесом. – М.: Финансы и статистика, 2005.

45. Щенников С. Ю. Реинжиниринг бизнес-процессов. Экспертное моделирование, управление, планирование и оценка. – М.: Ось-89, 2004.

46. Шеер А. В. Бизнес-процессы. Основные понятия. Теория. Методы. – Весть – Метатехнология, 1999.

47. Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS: практическое руководство. – М., 2001.

48. Ивлев В., Попова Т. Оценка эффективности автоматизации // КомпьютерПресс. 1996. № 8.

49. Галактионов В. Сага о проектах построения архитектуры предприятия // Директор ИС. 2002. № 7–8.

50. Цисарь И. Ф., Нейман В. Г. Компьютерное моделирование экономики. – М.: Диалог – Мифи, 2002.

51. Чередниченко А. С. Управление операционными рисками в ARIS.

52. Тягунов Д. М. Применение ARIS BSC 6.2 при построении карт стратегии компании.

53. Скворцов В. И. Технологические основы использования системы ARIS Toolset 7.0. – М.: Диалог-МИФИ, 2006.

54. Ильин В. П. Моделирование бизнес-процессов. Практическое использование ARIS // -scheer.com/

55. /

56. /

57. /

58. /

59. /

60. -portal.ru/

Сокращения

АИС Автоматизированные информационные системы

БП Бизнес-процесс

ИС Информационные системы

ИТ Информационные технологии

КПР Ключевые показатели результативности

ОГВ Органы государственной власти

ПО Программное обеспечение

РФ Российская Федерация

Оглавление

Введение

Глава 1 Зачем нужна модель бизнес-архитектуры: стандартные постановки задач по моделированию бизнес-процессов

Глава 2 Что такое модель бизнес-процессов. Типовая архитектура модели бизнес-процессов

  Контекст и основные элементы бизнес-архитектуры

    Структура организационной компоненты

    Структура информационной компоненты

    Организация компоненты «Приложения»

  Базовые принципы, методы и определения моделирования бизнес-процессов

    Определение моделирования

    Типология моделей

  Общие принципы моделирования

    Базовые определения по архитектуре

  Объектный анализ

  Процессный анализ

    Понятие процесса

    Компоненты процесса

  Анализ процесса

    Анализ топологии процесса

    Анализ характеристик процесса

    Анализ ошибок процесса

    Анализ динамики процессов

    Анализ рисков процесса

    Анализ ресурсного окружения процессов

    Анализ возможностей стандартизации процесса (создание эталонных, референтных моделей)

  Основные методики моделирования

  IDEF-технологии

Глава 3 Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке

  Общий подход к проектированию

  Определение параметров вариативности модели и ее реализации

  Анализ и оптимизация моделей

  Этапность создания модели

    Общие рекомендации

    Построение информационной модели

    Построение организационной модели

    Построение функциональной модели

    Построение модели выходов (результатов)

    Построение модели управления

    Разработка прикладных приложений для работы с моделями

    Разработка Соглашения о моделировании

    Основные этапы по проектированию

    Проектирование моделей «как должно быть» и GAP-анализ

    Плюсы и минусы различных подходов к разработке бизнес-архитектуры

Глава 4 Современные инструментальные средства моделирования бизнес-процессов. Как выбирать инструментальную среду для бизнес-моделирования

  Выбор инструментальных средств моделирования и методов

Глава 5 Организация проекта по моделированию бизнес-архитектуры организации: этапность, участники, роли, взаимодействия

Глава 6 Модель построена, что дальше? Масштабное внедрение и поддержка бизнес-модели

Глава 7 Чего нужно опасаться при моделировании бизнес-процессов. Проектные риски моделирования бизнеспроцессов

Глава 8 Моделирование бизнес-процессов в среде ARIS – иллюстрация частных решений и подходов

  Прикладной функционал

    Цветовое выделение «маршрута» на фоне общей модели

    Сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры

    Группа прикладных функций аналитической обработки «маршрута»

      Технологическая карта

      Должностная инструкция

    Специализированные алгоритмы анализа (временного, стоимостного) бизнес-процесса с учетом влияния человеческих и технических ресурсов

  Общесистемный функционал

    Решения по визуализации и настройкам

    Проектные решения

    Тестирование

    Интеграционные решения

Заключение

Приложения

  Приложение 1

  Приложение 2

  Приложение 3

  Приложение 4

  Приложение 5

  Литература

  Сокращения X Имя пользователя * Пароль * Запомнить меня

Регистрация

Забыли пароль?