Структура операционной модели ИТ

image004Публикация на Facebook ссылки на IT4IT Reference Architecture вызвало большую, но неоднозначную реакцию. Кто-то проявил живой интерес, а кто-то отметился репликами в стиле: «Да кому это нужно! И что это за кружочки с квадратиками?». Выскажу свое мнение. Эталонная архитектура операционной модели деятельности ИТ-подразделения, изложенная в документе, получилась очень неплохой.  Визуализация этой архитектуры (см. рисунок ниже) сделана существенно хуже. Чтоб закрыть вопрос с картинками сразу скажу, что синии прямоугольники на картинках обозначают основные функции, а черные круги – объекты данных. Серые и фиолетовые круги – это частные случаи объектов данных (подклассы), обозначающие вспомогательные объекты и воспринимаемые пользователями ИТ-услуг сервисы. Теперь о содержании. 

Кратко повторю структуру операционной модели. Деятельность ИТ состоит из 4-х потоков создания ценности и 5-ти вспомогательных видов деятельности. Потоки ценности следующие:

  1. Strategy to Portfolio. От стратегии к портфелю(проектов, приложений, …)
  2. От требований к развертыванию (Requirement to Deploy)
  3. От заявок к предоставлению сервиса (Request to Fulfill)
  4. и от обнаружения до исправления (Detect to Correct)

Вспомогательные виды деятельности:

  1. Управление рисками (Governance Risk & Compliance)
  2. Управление поставщиками (Sourcing & Vendor)
  3. Аналитика и отчетность (Intelligence & Reporting)
  4. Финансы и активы (Finance & Assets)
  5. Ресурсы и проекты (Resource & Project)

image029

Первый вопрос, который возникает при взгляде на эту конструкцию: а зачем нужна еще одна процессная модель деятельности ИТ отдела. Ответ в том, что IT4IT не процессная модель. Перечисленные выше потоки создания ценности – это не процессы, а именно потоки создания ценности. Они поддерживаются процессами, но сами процессами не являются. Например, для реализации потока создания ценности  Requirement to Deploy, нужен и процесс управления релизами и процесс управления изменениями. Но оценивать работу ИТ (подсчитывать KPIs) мы будем не по показателям этих процессов, а по потоку создания ценности R2D. Здесь есть один очень важный момент. То, что в рамках потока создания ценности присутствуют несколько процессов, не означает, что они следуют друг за другом, как это принято в «водопадной» модели разработки информационных систем. Наоборот объединение, например, сбора требований и разработки релизов в одном процессе, на мой взгляд, является, чуть ли не основной проблемой современных корпоративных ИТ.

Позволю себе аналогию с использованием синхронных взаимодействий в распределенных информационных системах. Добрая половина сообщений в этом блоге рассказывает о том, почему синхронные RPC-style взаимодействия это плохо. Если у нас одна программа синхронно обращается к другой, которая в свою очередь вызывает третью, то это приводит к проблемам. И дело не только в том, что нефункциональные характеристики общей системы снижаются (время отклика системы складывается из времени отклика каждой из подсистем, а доступность перемножается: 90%x90%=81%). Такие системы очень чувствительны к сбоям и отказам отдельных компонент. Пока один из сервисов заблокирован, не работают все вызвавшие его сервисы и все сервисы, которые вызвали эти сервисы и т.д. В общем, сеть не загружена, сервера не загружены, а система не работает. Ситуация напоминает каскадные отключения электричества (подробнее см. заметку Cloud-Native Application Architectures). Примерно то же самое происходит в бизнес-процессах. Если несколько экземпляров бизнес-процесса доходят до «заблокированной» активности (ресурсов архитекторов не хватает на согласование ТЗ, например), то все они останавливаются. А вслед за ними останавливаются процессы более высокого уровня. Из-за нехватки архитекторов не согласуется ТЗ, из-за этого стоит процедура закупки (услуг по разработке ПО), а из-за этого своевременно не осваивается бюджет и значит деньги не лежат в банке на депозите, а болтаются на счете. Одним словом, во всем виноваты ИТ-архитекторы. Об этих вещах, собственно, и рассказывает Теория ограничений.

К счастью, люди, которые занимаются реальной операционной деятельностью, а не рисованием бизнес-процессов в красивой BPMN нотации все это понимают и так не работают. Если бы они этого не делали, а следовали бы моделям и процедурам из методологий ведения ИТ-проектов, то цикл производства автомобилей выглядел бы так:

Приходит человек в магазин покупать новый автомобиль. Бизнес-аналитик выясняет у него требования. Продавец уточняет марку, модель, цвет, тип двигателя, отделку салона и отправляет заявку в производство. Главный по производству арендует землю, строит на ней завод, закупает станки, нанимает рабочих и производит нужный автомобиль – одну штуку и отправляет его в салон. Затем разбирает конвейер, увольняет рабочих, отказывается от арендованной земли. Выглядит смешно, но многие айтишники так и работают. Впрочем, нет! Они знают, что автомобиль покупателю обязательно не понравится.  Через пару недель он пригонит свою новую машину и  попросит заменить двери, оторвать бампер и форсировать двигатель. Кроме того, в первой версии автомобиля не хватало половины колес, так что колеса он тоже попросит прикрутить. В общем, завод никто разбирать не спешит и потому команда программистов сидит месяцами и бездельничает, надеясь, что заказчик созреет до нового релиза. Нормально организованная деятельность ИТ больше похода на следующую картинку.

ITcircle

Но мы отвлеклись. Чем же хороша предложенная модель. Обычно, из четырех поток создания ценности ИТ осознает только два – разработка и эксплуатация. R2F присутствует где-то на задворках сознания. Это как если бы оператор сотовой связи строил и эксплуатировал сеть, но не продавал контракты(сим-карты). Ну, хочет кто-то подключиться к нашей сети, напишите e-mail или позвоните администратору, он пропишет Вас на коммутаторе и пользуйтесь на здоровье. А поток S2P, вообще,  находится за пределами понимания. Но ведь на самом деле, это главный вид деятельности бизнес-аналитиков и корпоративных архитекторов. Зато вспомогательные активности, обычно, занимают времени не меньше потоков создания ценности. Чем занимаются ИТ руководители? Бюджетом они занимаются. Рисками занимаются…  А аналитика и отчетность построена не на потоках создания ценности, а на вспомогательных процессах. Вещи все важные и нужные, конечно, но IT4IT предлагает изменить подход.

ИТ-подразделение это брокер услуг (внешних поставщиков). Его главный справочник это продуктовый каталог, а процесс – офер менеджмент. ITIL v.3 пытался озвучить эту тему, но получилось довольно сложно. В COBIT все тоже не очень понятно. В IT4IT получилось довольно просто. Картинки, конечно, нуждаются в переработке. Archimate в описании потоков создания ценности, вообще, не к месту. Но содержательная часть, на мой взгляд, интересная. Надо пробовать!

Структура операционной модели ИТ: 5 комментариев

  1. так в арчимейте как раз и можно реализовать модель S2P , равзе нет?

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *