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

Создание модели бизнес-архитектуры является непростым процессом не только с технологической, но и с организационной точки зрения. Модель бизнес-архитектуры – это примерно 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