Demand & Supply. Единство противоположностей

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

А и Б сидели на трубе

Бизнес очень похож на классическую школьную задачу о бассейне, в который через трубу А вливается и через трубу Б выливается поток процессов. Но еще больше бизнес похож на открытую с двух сторон трубу переменного сечения, в которую внешний мир пытается «задуть» множество событий (рис.1). Сам же бизнес, являясь системой разумной, пытается уловить, привлечь к себе, отфильтровать и втянуть вовнутрь только важные и полезные события, преобразовав их на выходе в желаемые целевые результаты. Так что левую и правую части трубы я бы с легкостью назвал модными сегодня терминами Demand и Supply.

Рис. 1. Труба активностей. Половинки Demand и Supply.

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

Чтобы тратить ресурсы эффективно, возникает жесткая необходимость регистрации, корреляции и ранжирования событий, поступающих на вход, для принятия качественных решений и пропуска в область 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 как по способам управления, так и по составу участвующих в них людей. Так что мы имеем дело не с одной, а с двумя парами противоположностей, образующими квадрант базовых активностей любого бизнеса (рис. 2).

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

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

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

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

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

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

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

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

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

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

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

Далее, справа, в области Back Office Supply, поток переструктурируется в архитектуру изготовления и предоставления продуктов. Эта архитектура зависит не столько от предметной области, сколько от инструментария изготовления. Так, например, для создания современных ИТ-решений требуется собирать людей не по знанию банковского или страхового бизнеса, а по владению технологиями (разработчики Java, разработчики интеграционных сред, тестировщики и т. д.). Только в этом случае «фабрика Supply» становится «мобильной», не зависящей ни от состава временно привлекаемых ресурсов, ни и от конкретных заказчиков из Demand. Она может работать на Demand как внутри, так и вне компании, превращаясь из подразделения тратящего в подразделение, зарабатывающее деньги.

И наконец, крайняя область справа Front Office Supply полностью повторяет Front Office Demand, поскольку мы циклично возвращаемся к точкам контакта с клиентами и всем внешним миром.

Здесь можно было бы остановиться, если бы не одно но… Мне лично в такой модели долгое время не давал покоя разрыв потоков Change на верхний и нижний слои. Этот разрыв на практике соответствует разделенности людей и подразделений, называющих себя бизнесом, и теми, кто работает с ИТ-инфраструктурой. Эти люди изредка встречаются на совещаниях и часто не слышат и не понимают друг друга. В один прекрасный момент я понял, насколько детская ошибка лежит в невидении очевидного. Мы говорим о трубе событий, а в модели рисуем лишь ее продольный плоский срез. Но реальная труба ведь не плоская, а круглая! И стоит лишь понять, как она устроена в поперечном срезе.

Взгляд через подзорную трубу

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

Рис. 5. Поперечный срез трубы активностей (область RUN)

Не стоит ничего изобретать! Природа сама об этом давно позаботилась! Круговое движение двух полярных активностей Demand и Supply поддается тем же законам, что и суточное вращение Земли вокруг своей оси. Это своего рода 24-тактовый циферблат, проходящий четыре фазы движения: утро, день, вечер и ночь. Обратите внимание, насколько органично вписался сюда цикл PDCA!

От себя добавлю лишь небольшую интерпретацию. Термины Plan, Do, Check, Act – это точки, разделяющие фазы цикла. Фазы между точками имеют почти такой же смысл – «Планирую», «Делаю», «Проверяю» и… как ни странно, «Отдыхаю». Так уж распорядилась природа – три четверти активных и одна четверть пассивная.

Demand и Supply, продвигаясь вперед вдоль оси времени, вращаются вокруг нее, находясь в полной противофазе. Время на рис. 5 направлено вперед. В точности вдоль вашего взгляда на эту картинку. Перпендикулярно этому рисунку. Так что труба активностей напоминает скрученную двухцветную карамель из детства. Именно так, не растворяясь друг в друге, а закручиваясь в две спирали по оси времени, Demand и Supply взаимодействуют друг с другом.

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

Чтобы увидеть суть периодичности фаз Demand & Supply, предлагаю, подобно тому как конфетная обертка разворачивается в фантик, развернуть круговое вращение потока работ в одну ось координат (рис.6).

Рис. 6. Развертка трубы активностей

Посмотрим на медленный цикл глазами Demand. Все очень похоже на происходящее в реальном бизнесе. На первой фазе, пока вы изучаете рынок и планируете будущие проекты, технари-исполнители уже выполнили очередную прошлую задачу и проверяют результаты ее внедрения. Более сложен для реализации и понимания следующий второй этап. Технический персонал перешел в режим отдыха, расслабившись в поисках новой следующей задачи. А у вас наступила фаза 2 основной активности. Что же это за активность?

Результатом Demand не должен быть конечный продукт. Результатом Demand может быть только разработанные в терминах бизнеса архитектура и проект. На этой фазе вы можете оторвать Supply от заслуженного отдыха и привлечь его к разработке вашего собственного Demand-продукта, но ответственными за разработку документа, который часто называют БФТ (бизнес и функциональные требования), являетесь вы и только вы. Другого результата у Demand нет!

Именно поэтому в методологиях разработки программного обеспечения отдельно прорастают Business Use Cases и Software Use Cases, а в бизнесе отдельные два документа – БФТ и «Технический анализ и дизайн». Их просто делают разные группы людей, и это правильно.

На третьей фазе происходит своего рода квантовый переход и передача эстафетной палочки от Demand к Supply. В соответствии с технологией, Supply приступает к планированию изготовления продукта. В это же время Demand релаксирует, проверяя, наcколько качественно отработаны БФТ, и корректируя, пока еще не поздно, планы Supply.

На четвертой фазе Supply реализует план реализации продукта. Вмешаться в это исполнение со стороны Demand практически нет возможности. Это своего рода фаза отдыха Demand в ожидании реализации задуманного.

И так повторяется из цикла в цикл, от почти мгновенных автоматических операций Run с высокой тактовой частотой до медленных проектов Change, длящихся месяцами и кварталами.

Здесь хотелось бы точных научных или конкретных практических выводов. Думаю, что они лежат в самой модели и у каждого свои. Предлагаю лучше посмотреть и насладиться, насколько это гениально уже придумано до нас!

Антон Саввин (ASavvin@trans-ts.ru) — генеральный директор компании «ТрансТехСвязь»