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

Термин "мастерская информационных технологий" определяется в [1] как общий набор методов и технологий, применяемый для проектирования специализированной информационной системы или адаптации универсальной информационной системы к требованиям и нуждам конкретного заказчика, в совокупности с поддерживающим этот набор методов и технологий программным обеспечением. ARIS - один из таких инструментов, обязательный в арсенале профессионального консультанта, технолога, проектировщика, разработчика информационной системы. Строго говоря, ARIS не относится непосредственно ни к CASE-средствам, ни к методологиям и средствам разработки информационных систем как, например, семейство продуктов Rational. Более того, оба они, одновременно наличествуя в мастерской ИТ, предназначены в целом для решения разных задач. Если продукты Rational ориентированы в основном на поддержку всего жизненного цикла программного продукта начиная со стадии сбора и формулирования требований к системе и ее проектирования и заканчивая стадиями сопровождения и конфигурационного управления, то методология ARIS нацелена на предшествующие стадии. К ним относятся: документирование знаний о бизнесе, т. е. определение миссии организации, формулирование стратегических целей и задач, построение реестра продуктов и услуг (стратегический слой); разработка организационной структуры предприятия с детальным многоуровневым описанием бизнес-процессов (слой бизнес-архитектуры); документирование архитектуры приложений, данных, оборудования (слой системной архитектуры); определение связей между всеми сущностями трех этих слоев. (На практике перечисленные стадии часто даже не предшествуют, а лежат в параллельных плоскостях со стадиями жизненного цикла информационной системы. - В.Г.) Функциональность методологии и инструментария ARIS имеет незначительные пересечения со средствами проектирования и разработки информационных систем, но исключительно в части построения той самой достаточно зыбкой связи между бизнес-архитектурой и системной архитектурой.

При построении архитектуры предприятия, в частности, системной архитектуры, возникает немало традиционных вопросов (см. [2]). Все они имеют ответ, но любой ответ становится знанием предприятия только в том случае, если он задокументирован. Практически все известные методологии и стандарты (от отечественных ГОСТов и SADT до RUP) и инструменты (начиная с IDEF Designer, System Architect и BPwin/Erwin и заканчивая продуктами семейства Rational) предоставляют возможности для документирования только части из перечисленных знаний, поскольку ориентируются в значительной степени на разработку программных систем. Многие же из перечисленных выше вопросов лежат в слое бизнес-архитектуры. Задаче документирования знаний о бизнесе наиболее соответствует методология и инструментарий ARIS.

Здесь уместно упомянуть о новом мифе информационных технологий, "архитектурном мифе". Давно известное [3] понятие архитектуры предприятия (и составляющие ее бизнес-архитектура и системная архитектура), отвечающее потребности отображения в более емкой и "плоской" форме сложных для второй сигнальной системы (т. е. речи) вещей, в конце прошлого века удачно упало на одну из многих граней процесса информатизации бизнеса, став, однако, объектом торговли и спекуляций. Поэтому, несмотря на значительное число уже опубликованных работ, посвященных внедрению и использованию различных инструментов из мастерской ИТ [4-7], автор считает своей основной задачей оградить читателя от необоснованных надежд при выборе той или иной методологии и возможных проблем организации проекта, связанного с построением архитектуры предприятия. Приведенные в статье рекомендации и советы, рассматриваемые на примере использования методологии ARIS, являются достаточно общими и с успехом могут быть применимы при выборе любых других инструментов для вашей личной "мастерской ИТ".

Методология ARIS основана на теории Августа-Вильгельма Шеера "Архитектура интегрированных информационных систем" (ARchitecture of Integrated Information System) и определяет принципы моделирования практически всех аспектов деятельности организации, что составляет ее коренное отличие от других методологий. ARIS основывается на концепции интеграции, предлагающей целостный взгляд на бизнес-процессы, и представляет собой множество различных методологий, интегрированных в рамках единого системного подхода.

Данная статья не рассматривает ни самой методологии, ни инструментария ARIS. За информацией по этим вопросам автор отсылает к сайту компании "Логика бизнеса" (http://www.blogic.ru/aris), а также к книгам [8-10].

Цели проекта

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

  • Какие цели преследует организация? Какие задачи она ставит при внедрении методологии?
  • Какие результаты организация планирует получить? В каком виде?

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

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

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

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

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

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

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

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

Внедрение ARIS требует определенной ломки стереотипов. Так, регламент, должностная инструкция, положение о структурном подразделении, традиционно разрабатываемые в виде текстовых документов в формате MS Word, после перевода на формализованный язык меняют форму, становятся более структурированными. Их изучение в традиционной бумажной форме зачастую становится затруднительным; предпочтительнее работа с документами в электронной форме с использованием гиперссылок. ARIS Web Publisher поддерживает возможность оперативной публикации любых документированных знаний в корпоративной сети, что облегчает их изучение. Вместе с тем, использование подобного инструментария предполагает определенный уровень корпоративной культуры. Корпоративную культуру не ввести авторитарным решением, она не может возникнуть в результате разработки и принятия в качестве стандарта необходимых нормативных документов, не появится она и после недельного пребывания всех сотрудников на соответствующих учебных курсах. Корпоративную культуру воспитывают достаточно долго. Ряд корпоративных знаний с большим трудом и определенным риском удается передать посредством формализованной нотации.

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

Организация проекта

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

Необходимость разработки такого соглашения обусловлена также большим количеством моделей и объектов, потенциально пригодных для использования. Одно и то же знание может быть зачастую документировано с помощью десятка различных моделей. Иногда это полезно, поскольку позволяет отразить специфичные аспекты бизнеса. Однако особенности использования тех или иных типов моделей, типов объектов для отражения той или иной специфики также следует зафиксировать в соглашении о моделировании. Использование каких бы то ни было иных моделей и объектов помимо перечисленных в соглашении является недопустимым. Здесь также действует принцип Паретто: 80% знаний о бизнесе могут документировать 20% моделей. Умышленное ограничение на начальных этапах спектра доступных инструментов методологически обосновано.

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

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

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

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

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

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

Из практики известно, что документирование одного банковского продукта занимает в среднем от 3 до 6 человеко-месяцев. При среднем размере реестра банковских продуктов в 500 позиций его документирование потребует ресурсов в 1500-3000 человеко-месяцев. Элементарный расчет показывает, что силами 20 человек эта задача может быть решена в течение 6-12 лет. Полученное за этот срок знание успеет к моменту завершения работ полностью устареть.

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

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

Последний вариант позволяет сохранить на какое-то время монополизацию использования методологии ARIS, но одновременно создает ряд дополнительных проблем. Монопольное использование ARIS и выборочное документирование знаний о бизнесе не позволяют ответить на целый ряд вопросов. Каков уровень документированности бизнеса в данный момент времени (объемы знания, которое осталось "за бортом", не известны)? Каковы риски, какова эффективность, какова степень автоматизации в "неучтенной" части бизнеса? И как следствие, каковы риски, какова эффективность бизнеса в целом?

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

Проблемы локального внедрения

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

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

В [6] автор жестко формулирует свою позицию: "Моделирование ни в коем случае не должно стать внутренним процессом отдела ИТ". Проект документирования архитектуры предприятия должен быть инициирован со стороны бизнес-подразделений, а не со стороны ИТ-подразделений. К проекту проявляют интерес и оказывают ему поддержку функциональные (обеспечивающие) подразделения - служба внутреннего контроля, служба безопасности и др. ИТ-подразделения предприятия также будут играть не последнюю роль в проекте, но эта роль однозначно не должна быть первой.

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

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

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

Сложность методологии

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

В действительности методология ARIS достаточно понятна и хорошо документирована, а инструментарий ARIS обладает интуитивно понятным интерфейсом и позволяет начать работать с ним буквально сразу после установки. Однако мнимая тривиальность часто подсказывает ошибочное решение, что персонал обучать методологии ARIS не нужно: "Ведь мы не обучаем персонал использованию MS Word или MS Excel. Тогда почему мы должны учить ARIS?" При этом часто забывают, что Word и Excel всего лишь инструменты, ставшие при том стандартом де-факто, которым должен владеть каждый сотрудник компании, начиная с президента (или, как минимум, вице-президента) и заканчивая секретарями, бухгалтерами и кладовщиками.

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

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

Заключение

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

Виктор Галактионов - вице-президент, главный системный архитектор ОАО "Альфа-банк". С ним можно связаться по электронной почте по адресу: VGalax@alfabank.ru.
Литература
  1. Е.З. Зиндер. Новое системное проектирование: информационные технологии и бизнес-реинжиниринг. - "Системы управления базами данных", № 4, 1995
  2. В.И. Галактионов. Системная архитектура и ее место в архитектуре предприятия. - "Директор информационной службы", № 5, 2002
  3. В.П. Меллинг. Корпоративные информационные архитектуры. - "Системы управления базами данных", № 2, 1995
  4. Е.З. Зиндер. CASE-факторы риска. - "Директор информационной службы"" № 13, 1999
  5. А. Вендров. Ниша и внедрение CASE-средств. - "Директор информационной службы", № 11, 2000
  6. Д. Слиньков. Бизнес-моделирование для внедрения ИСУ предприятия. - "Директор информационной службы", № 03, 2001
  7. С. Рубцов. Какой CASE-инструмент нанесет наименьший вред организации? - "Директор информационной службы", № 01, 2002
  8. Август-Вильгельм Шеер. "Моделирование бизнес-процессов". Пер с англ., 2000
  9. Август-Вильгельм Шеер. "Бизнес-процессы. Основные понятия. Теория. Методы". Пер с англ., 2000
  10. М. Каменнова, А. Громов, М. Ферапонтов, А. Шматалюк. "Mоделирование бизнеса. Методология ARIS. Практическое руководство". Москва, 2001