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

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

Люди по своей природе склонны находиться преимущественно либо в реактивной аналитической, либо в проактивной созидательной области работ. Именно поэтому, на рисунке 1 область Demand отмечена синим цветом и ассоциируется с фазой Check, а область Supply отмечена красным цветом и ассоциируется с фазой Plan классического цикла PDCA (Plan, Do, Check, Act).

Однако здесь кроется подвох. Грубейшей ошибкой было бы поставить знак равенства между Demand и реактивным состоянием Check, а также между Supply и проактивным состоянием Plan. Люди, работающие преимущественно слева или справа, занимаются разным, но самодостаточным делом и движутся в своем полном цикле деятельности PDCA. Похоже, что в рисунок 1 закралась неточность – цвет областей. Труба потоков работ не делится жестко на синюю и красную половины. Красный и синий цвета должны плавно проникать друг в друга. И именно в этом проникновении и кроется наибольшая сложность и секрет эффективности бизнеса.

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

А что же внутри трубы? Препарируем чуть подробнее ее продольный срез, задавшись вопросом, а нет ли еще одной базовой полярности в любом потоке процессе?

Извечный вопрос «Где заканчивается операционная рутина и начинается область развития и изменений» имеет извечный ответ: «Вы сами хозяин того, что считать изменением в архитектуре вашей системы». Нет точной границы, а есть плавный переход между стандартной, основанной на опыте деятельности Run, и направленной на изменения в системе деятельности Change. В своих крайних состояниях, Run представляет собой мгновенные автоматические системные операции, а Change – долгие проекты с большой неопределенностью. Подобно геному человека, Run несет ответственность за наследственность и повторяемость в бизнесе, а Change за изменчивость и появление новых свойств.

Современный менеджмент давно уже рекомендует разделять области Run и Change, как по способам управления, так и по составу участвующих в них людей. Так что мы имеем дело не с одной, а с двумя парами противоположностей, образующих квадрант базовых активностей любого бизнеса (рис.).

Рис. . Квадрант базовых активностей любого бизнеса

В направлениях Demand и Supply собираются люди, по своим психотипам, нацеленные на внешнюю среду и на внутреннюю реализацию, а в направлениях Run и Change собираются люди, либо нацеленные на сохранение сложившегося порядка, либо стремящиеся этот порядок изменить. Так что, модель трубы активностей можно уточнить. Предлагаю разместить скоротечную и зачастую автоматизированную деятельность Run вблизи оси, а медленную и нестандартную деятельность Change по краям трубы активностей (рис.)

Рис. . Труба Активностей. Разделение областей Run & Change

Выглядит немного необычно, но очень похоже на реальные физические явления, например, на движение песка в песочных часах или движение вязкого газа в ракетном двигателе. Максимальная скорость потока достигается по оси, а минимальная вблизи стенок трубы. Необычность состоит в том, что Run на картинке представлен как цельный неделимый процесс, а Change искусственно разрезан на верхнюю и нижнюю полоски. Прежде чем объяснить почему так, предлагаю посмотреть на модель еще чуть подробнее глазами Информационных технологий (рис.).

Рис. . Как устроена Труба Активностей. Глазами ИТ технологий.

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

Каждая из областей Demand и Supply, вдоль линии течения процесса, делится на Front Office, контактирующий слева и справа с внешней средой, и Back Office, расположенный ближе к центру и выполняющий внутрисистемные операции. В качестве примера такого разделения могу привести, например, пару сервисных процессов – управление инцидентами и управление проблемами или пару процессов управление изменениями и управление работами.

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

На левой границе трубы во Front Office Demand, поток структурируется по точкам контактов с внешней средой. Сверху – по клиентам и сервисам, а снизу по сложившимся инфраструктурным технологиям.

Ближе к центру, в области Back Office Demand поток переструктурируется в архитектуру предметной области компании, по технологиям уже работающих продуктов. В каждой отрасли: телекоме, медицине, банках, у энергетиков, на транспоррте архитектура предметной области своя. Именно поэтому подавляющее большинство сотрудников Demand – это бизнес аналитики, архитекторы, менеджеры проектов и технические писатели, ведь основной продукт, создаваемый Demand – это проеткные требования, а вовсе не сам конечный продукт.

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