Как повысить эффективность бизнеса?

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

Эволюция управления бизнес-системами проделала путь от единых иерархий через проектные и процессные матрицы к плоским мобильным структурам управления. Цифровая трансформация условно разделила бизнес-систему на часть, контактирующую с клиентом, например через мобильные устройства, и на инфраструктуру, обеспечивающую обработку событий, генерируемых клиентом. Это и есть «левая» и «правая» руки бизнес-систем. Попробуем разобраться в природе их синхронизации.

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

Рис. 1. Модель современного бизнеса

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

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

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

А что же внутри трубы?

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

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

Рис. 2. Разделение областей Run и Change

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

Рис. 3. Труба активностей с точки зрения ИТ

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

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

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

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

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

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

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

Разрыв в модели — не ошибка. Дело в том, что до сих пор речь шла о трубе событий, но в модели указывался лишь ее продольный плоский срез, хотя реальная труба объемна и требуется понять, как она устроена в поперечном срезе.

Взглянув сквозь всю модель слева, можно обнаружить калейдоскоп событий — например, вращение Demand и Supply с периодической сменой полюсов (рис. 4).

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

Круговое движение двух полярных активностей Demand и Supply поддается тем же законам, что и суточное вращение Земли вокруг своей оси. Это своего рода 24-тактовый циферблат, в который органично вписался цикл PDCA. Термины Plan, Do, Check, Act — это точки, разделяющие фазы цикла. Фазы между точками имеют почти такой же смысл: «Планирую», «Делаю», «Проверяю» и «Отдыхаю» — три четверти активных и одна пассивная.

Demand и Supply, продвигаясь вперед вдоль оси времени, вращаются вокруг нее, находясь в полной противофазе. Время на рис. 4 направлено вперед. В точности вдоль вашего взгляда на эту картинку, перпендикулярно плоскости рисунка. Именно так, не растворяясь друг в друге, а закручиваясь в две спирали по оси времени, Demand и Supply взаимодействуют друг с другом. Действительно, все сотрудники компании не могут одновременно бегать по клиентам, а вернувшись, все вместе наваливаться на решение одной-единственной задачи. Каждый должен заниматься параллельно своим делом в своей фазе.

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

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

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

Результатом Demand не должен быть конечный продукт, а могут быть только архитектура и проект, разработанные в терминах бизнеса. На этой фазе можно оторвать Supply от отдыха и привлечь его к разработке Demand-продукта, но ответственным за разработку документа, который часто называют БФТ («Бизнес- и функциональные требования»), является только Demand — другого результата его деятельности нет. Именно поэтому в методологиях разработки программного обеспечения отдельно прорастают Business Use Cases и Software Use Cases, а в бизнесе — два отдельных документа: БФТ и «Технический анализ и дизайн». Их просто делают разные группы людей, и это естественно.

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

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

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

***

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

Литература

1. Михаил Потоцкий. Будущее ITSM в России // Открытые системы.СУБД. — 2010. — № 5. — С. 24–26. URL: http://www.osp.ru/os/2010/05/13003046 (дата обращения: 18.07.2016).

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