Рис. Границы и правила системы сильно упорядочивают процесс

Если бы у песочных часов не было бы стенок, песок бы хаотично рассыпался на нижней поверхности. И это был бы то же процесс, подверженный всего лишь двум, но сильным правилам: невозможно двигаться по направлению наверх, а также – нижнюю поверхность невозможно пересечь насквозь. Стеклянные стенки являются дополнительными ограничивающими правилами системы под названием «песочные часы». Вместе с узким горлышком они задают более тонкие упорядочивающие границы процесса. Какие бы цели ни ставились перед песчинкой, она все равно попадет в нижнюю часть системы и обязательно через узкое горлышко. Можно задаться более высокоточной целью и попытаться рассчитать в какой момент времени какая песчинка должна находиться в каком месте и рядом с какой другой – простроить точный выверенный процесс. Но зачем? Похоже, цель конечного результата будет достигнута в любом случае. Если искать примеры чуть ближе к деловому миру, то, например, бесполезно и бессмысленно пытаться описать процесс движения на автодороге. Для этого достаточно Правил дорожного движения.

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

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

Рис. Поле сервисных процессов. Области скоростей.

Довольно необычно смотреть на происходящие процессы как на непрерывное поле деятельности. Однако, нарезка процесса на модули и шаги, удобна только на локальном участке процесса, и не позволяет за отдельными деревьями увидеть весь лес.

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

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

Рис. Поле сервисных процессов: локализация основных процессов.

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

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

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

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

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

Рис. Процесс предоставления сервиса в предельном случае.

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

Ничего не напоминает? Необычно? Да. Но ведь и в физике, до появления квантовой теории все процессы считались плавными, а бесконечность – абстрактным математическим понятием.

В попытке ответить на вопрос, заданный Майклу Фарадею, в чем же может оказаться полезность взгляда на деятельность как на поле, придется ненадолго чуть глубже занырнуть в организацию информационных технологий. Поле бизнес-процессов напрямую показывает, как можно сочетать надежное управление крупными релизами бизнес-систем и скоростное внедрение удобных фич для электронных клиентов. Классические практики управления изменениями с длительными циклами разработки, точным выполнением заявленных на старте требований и доскональным тестированием, не работают или неэффективны в целом ряде областей. Попытка же полностью заменить их на подход быстрой итеративной разработки неэффективна, поскольку прямо приводит к рискам крупных сбоев критически важных систем. Чего стоит, например, программный сбой в аэропорту Хитроу.