В октябрьском номере журнала «Форум IT» была опубликована статья, рассказывавшая о системе менеджмента качества ARIS. Этот материал продолжает тему. Автор совершенно не претендует на исчерпывающую полноту изложения проблемы, а лишь пытается обобщить наиболее типичные ошибки, встречающиеся при практическом применении ARIS.

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

Отсутствие четких целей, задач, объемов

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

На практике это означает потерю механизмов контроля и управления эффективностью бизнеса. Построение ключевых индикаторов результативности (KPI) часто основывается исключительно на финансовых показателях компании. Вместо полной картины мы получаем частную оценку в финансовом аспекте.

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

Отсутствие ответственных лиц

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

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

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

Отсутствие единого понимания (соглашения)

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

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

При этом всегда нужно помнить о принципе Паретто: 80 процентов знаний о бизнесе могут быть отражены в 20 процентах моделей.

Монополизация использования методологии

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

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

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

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

Из практики известно, что ресурс для документирования одного банковского продукта с достаточным уровнем детализации составляет в среднем 3—6 человеко-месяцев. Когда в реестре банковских продуктов, скажем, 500 позиций, его документирование займет уже 1500—3000 человеко-месяцев.

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

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

• временное привлечение внешних ресурсов (консультантов);

• отказ от документирования существующей корпоративной архитектуры и упор только на новые продукты и процессы.

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

Внедрение в рамках отдельного проекта

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

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

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

Ограниченный объем решаемых задач

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

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

Несвязанные направления документирования

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

Документирование в различных базах данных

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

ARIS всем понятен и не требует обучения персонала

Мнимая «простота» методологии иногда создает мнение о том, что для работы с ARIS нет нужды в дополнительном обучении персонала

Действительно, методология ARIS достаточно понятна и хорошо документирована. Более того, продукты ARIS имеют отличный интерфейс и позволяют начать работу сразу же после установки. Мнимая «простота» методологии иногда создает мнение о том, что для работы с ARIS нет нужды в дополнительном обучении персонала. В качестве аргумента часто можно слышать такую фразу: «Мы ведь обучаем людей использованию MS Word или MS Excel. А чем ARIS лучше?».

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

Документирование есть конечный процесс

Документирование знаний о бизнесе не является конечным процессом. Нельзя ожидать того, что когда-нибудь все знания будут задокументированы, регламенты — разработаны, а логические структуры баз данных и архитектура приложений -спроектированы. Рано или поздно у вас возникнет вопрос: «А что делать дальше?» Жизнь не стоит на месте. За время, пока проводится документирование текущей ситуации, бизнес уходит вперед, происходят изменения в организационной структуре предприятия, а программное обеспечение продолжает разрабатываться и модернизироваться.

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

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

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

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

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

Выбирать вам!!!