Типы архитектур КИС

На сегодняшний день во всем мире существуют три основных типа архитектур КИС [2]. Gartner Group выделяет их больше, но доминирующими являются только три: «лоскутное одеяло», «сильная интеграция» и «слабая интеграция». Данные типы представляют собой точки зрения прежде всего бизнес-пользователей, а уж потом ИТ-специалиста.

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

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

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

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

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

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

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

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

Уже появились целые направления, которые описывают происходящее в компании не в терминах бизнес-процессов, а в виде системы бизнес-правил, отличающихся от процессов тем, что описывают жизнь предприятия не по принципу «делать так и только так», а по принципу ограничения «разрешено всё, что не запрещено». Это совершенно другой подход к организации бизнеса. В качестве типичного примера бизнес-правил можно привести законодательство государства или учетную политику предприятия. В области ИТ и управления начали появляться языки описания бизнес-правил. World Wide Web Consortium (W3C) уже содержит стандарты таких языков [3]. Язык Business Process Executive Language (BPEL) как раз позволяет на очень глубоком уровне детализации описывать бизнес-правила и бизнес-процессы. При слабой интеграции реальные траектории процессов в большей степени зависят не от заранее заданных маршрутов, а от происходящих в бизнесе событий, которые отражены в данных. Типичным примером бизнес-приложений, основанных на этой архитектуре, являются системы класса Enterprise Content Management (ECM). Они ориентированы на управление, например, документами, которое отталкивается не столько от бизнес-процессов их движения, сколько от содержания самих документов.

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

Реальные архитектуры

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

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

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

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

Применение ИТ-сервисов в рамках разных архитектур

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

Сценарии отношений между ИТ-службой и бизнесом

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

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

Сценарий 3: ИТ-служба — «центр компетенции». К такому сценарию ИТ-служба часто приходит с масштабным внедрением ERP-системы в компании, в которой бизнес сознательно регламентирует свою основную деятельность зафиксированными бизнес-процессами. В этом случае бизнес получает высокоэффективную КИС, но в то же время и сильную зависимость от высококвалифицированной команды. В сильной интеграции эффективность оплачивается высокой сложностью КИС. Ценой высокой сложности всегда является высокая квалификация тех, кто с этой сложностью умеет работать. Такую команду надо неплохо оплачивать, да еще и удержать. Они на ИТ-рынке нарасхват. Это одна из «скользких» сторон крупных и даже успешных проектов по созданию сильно интегрированных КИС. «Центр компетенции» всегда балансирует на грани с «серым кардиналом». Для того чтобы не сорваться в сценарий №2, бизнес должен отчетливо понимать те выгоды, которые он получает от внедрения архитектуры сильной интеграции, и те границы, из которых она не должна выйти.

Сценарий 4: ИТ-служба — «сервисный центр». Именно этот сценарий идеально ложится на ITIL. Он имеет свои небольшие модификации. В архитектуре слабой интеграции каталог сервисов может четко соответствовать прикладным сервисам (почта, групповая работа, поиск, регистрация документов, согласование, хранение). В «лоскутном одеяле» каталог сервисов выстраивается вокруг бизнес-приложений («лоскутов»). В любом каталоге сервисы должны быть независимы друг от друга. Это принципиально отличает данный сценарий от сценария №3, где попытка построения каталога сервиса, например, по модулям сильно интегрированной системы приводит к тому, что весь каталог сворачивается в один сервис — доступ к интегрированному приложению. В третьем сценарии 80% инцидентов, связанных с КИС, являются уникальными, такими, которые может понять только небольшая группа специалистов. В то время как ITIL предполагает, что 60 — 70% инцидентов должно разрешаться на уровне Service Desk. Это также цена сложности. Именно в сценарии 4 — сервисного центра — ИТ-сервисы хорошо выносятся на аутсорсинг.

Заключение

Представленный анализ показывает, что возможность построения ИТ-сервисов сильно зависит, во-первых, от желания бизнеса выстраивать партнерские отношения со своими подразделениями, в том числе и с ИТ-службой, а во-вторых, от тех архитектурных решений КИС, к которым стремится сама ИТ-служба. В каждом бизнесе реальная архитектура КИС представляет собой уникальный симбиоз различных типов архитектур, который оказывается чрезвычайно чувствительным к изменениям самого бизнеса и статуса его ИТ-службы. В этом случае построение отношений между ИТ-службой и бизнесом также будет синтезом различных сценариев. Поэтому превращение функций ИТ-службы в ИТ-сервисы — процесс не быстрый, а иногда и обратимый. Видимо, с этим связаны и масштабы использования ИТ-сервисов, приведенные Gartner Group [1]. Ограничения в применении — это свойство любой практически значимой методологии. Если мы не понимаем ее ограничений, значит, мы не понимаем, как эффективно ее использовать. Универсальны только неработающие методологии.

Задачу разработки каталога ИТ-сервисов следует рассматривать в контексте всей ИТ-стратегии бизнеса, которая должна анализировать долгосрочные тенденции изменения самого бизнеса. Особенно остро проблема ИТ-сервисов возникает с появлением у бизнеса планов аутсорсинга. На аутсорсинг можно вынести только сервисы. Многочисленные попытки «вытолкнуть» на аутсорсинг свою ИТ-службу, назвав их функциональные обязанности ИТ-сервисами, всегда заканчивались серьезными проблемами для бизнеса [3]. Представленный анализ показывает также, что вывод на аутсорсинг — процесс постепенный и, возможно, обратимый. Не исключено, что существует и большее разнообразие сценариев развития отношений между ИТ-службой и бизнесом, которое даст новые ниши для ИТ-сервисов. В данной статье автором проведен анализ только тех сценариев, с которыми ему пришлось сталкиваться в реальной практике.

Литература

1. Holmstrom Eija. IT Service Manage­ment — best practices / Presenta­tion in Moscow. itSMF Russia, 25.04.2007.
2. Ананьин В. И. Формирование архитектуры корпоративной информационной системы путем естественного отбора // Intelligent Enterprise, 2006, №17.
3. Хейвуд Д. Б. Аутсорсинг. В поисках конкурентных преимуществ. Москва — Санкт-Петербург — Киев, ИД «Вильямс», 2004.

Об авторе:

Владимир Игоревич Ананьин, независимый консультант.На рынке IT с 1987 г. Занимается разработкой корпоративной IT-стратегии, управлением программами создания корпоративных информационных систем. Руководил проектами внедрения ERP систем Oracle Applications, SAP R/3. Занимался созданием и внедрением системы электронного документооборота, внедрением CAD систем. Сфера профессиональных интересов — IT-консалтинг в следующих областях: стратегическое управление корпоративными IT, управление проектами, сервисная организация корпоративных IT-служб и IT-аутсорсинг, контракты в IT. Преподавательская деятельность: курс “Бизнес и IT-стратегия”, Школа IT-менеджмента при Академии Народного Хозяйства при Правительстве РФ, MBA образование для руководителей. Автор ряда статей по тематике IT и управлению проектами.E-mail автора: v.ananiin@gmail.com