Извечный вопрос «Где заканчивается операционная рутина и начинается область развития и изменений» имеет извечный ответ: «Вы сами хозяин того, что считать изменением в архитектуре вашей системы». Нет точной границы, а есть плавный переход между стандартной, основанной на опыте деятельности Run, и направленной на изменения в системе деятельности Change. В своих крайних состояниях, Run представляет собой мгновенные автоматические системные операции, а Change – долгие проекты с большой неопределенностью. Подобно геному человека, Run несет ответственность за наследственность и повторяемость в бизнесе, а Change за изменчивость и появление новых свойств.
Современный менеджмент давно уже рекомендует разделять области Run и Change, как по способам управления, так и по составу участвующих в них людей. Так что мы имеем дело не с одной, а с двумя парами противоположностей, образующих квадрант базовых активностей любого бизнеса (рис.).
В направлениях Demand и Supply собираются люди, по своим психотипам, нацеленные на внешнюю среду и на внутреннюю реализацию, а в направлениях Run и Change собираются люди, либо нацеленные на сохранение сложившегося порядка, либо стремящиеся этот порядок изменить. Так что, модель трубы активностей можно уточнить. Предлагаю разместить скоротечную и зачастую автоматизированную деятельность Run вблизи оси, а медленную и нестандартную деятельность Change по краям трубы активностей (рис.)
Выглядит немного необычно, но очень похоже на реальные физические явления, например, на движение песка в песочных часах или движение вязкого газа в ракетном двигателе. Максимальная скорость потока достигается по оси, а минимальная вблизи стенок трубы. Необычность состоит в том, что Run на картинке представлен как цельный неделимый процесс, а Change искусственно разрезан на верхнюю и нижнюю полоски. Прежде чем объяснить почему так, предлагаю посмотреть на модель еще чуть подробнее глазами Информационных технологий (рис.).
Верхняя половина такого среза, подобно ресурсно-сервисной модели ITSM, ассоциируется с клиентскими сервисами. Нижняя половина смотрит на техническую инфраструктуру. Очевидно, что в близкой к оси области RUN многие процессы выполняются, взаимосвязано, зачастую автоматически, очень быстро пролетая сквозь трубу. В области Change, на периферии трубы приходится отдельно прорабатывать изменения в сервисах для клиентов и отдельно связанные с ними изменения в инфраструктуре.
Каждая из областей Demand и Supply, вдоль линии течения процесса, делится на Front Office, контактирующий слева и справа с внешней средой, и Back Office, расположенный ближе к центру и выполняющий внутрисистемные операции. В качестве примера такого разделения могу привести, например, пару сервисных процессов – управление инцидентами и управление проблемами или пару процессов управление изменениями и управление работами.
Внимательное рисунка 4 дает также полезную информацию о том, как можно наиболее эффективно выстроить организационную структуру сложного современного ИТ подразделения. Все просто! Подразделения ИТ естественным образом должны стараться повторять структуру потока работ в отдельных его частях.
На левой границе трубы во Front Office Demand, поток структурируется по точкам контактов с внешней средой. Сверху – по клиентам и сервисам, а снизу по сложившимся инфраструктурным технологиям.
Ближе к центру, в области Back Office Demand поток переструктурируется в архитектуру предметной области компании, по технологиям уже работающих продуктов. В каждой отрасли: телекоме, медицине, банках, у энергетиков, на транспоррте архитектура предметной области своя. Именно поэтому подавляющее большинство сотрудников Demand – это бизнес аналитики, архитекторы, менеджеры проектов и технические писатели, ведь основной продукт, создаваемый Demand – это проеткные требования, а вовсе не сам конечный продукт.
В самом центре трубы находится сердцевина принятия управленческих решений. Структура и правила управления этой частью больше определяются искусством, чем наукой управления. Они уникальны для каждой компании. Это и есть бизнес. В самом центре лежит искусственный интеллект компании в виде автоматически выстроенных процессов принятия решений, в форме алгоритмов ИТ и действующих процедур. Чуть шире, эта область окружена областью принятия решений людьми-менеджерами в формах от набора управленческих комитетов, до единоличного принятия всех решений одним начальником.