Текст книги "Сервисный компас"
Автор книги: Антон Саввин
сообщить о нарушении
Текущая страница: 12 (всего у книги 14 страниц)
Взгляд через подзорную трубу
Попытавшись взглянуть на всю модель слева, как в подзорную трубу, мы обнаружим целый калейдоскоп событий. Мы увидим вращение Demand и Supply с периодической сменой полюсов. Это вихреобразное движение хорошо описывается одним небезизвестным символом (рис.).
Рис. . Поперечный срез трубы активностей (область RUN)
Не стоит ничего изобретать! Природа сама об этом давно позаботилась! Круговое движение двух полярных активностей Demand и Supply поддается тем же законам, что и суточное вращение Земли вокруг своей оси. Это своего рода 24-тактовый циферблат, проходящий 4 фазы движения: Утро, День, Вечер и Ночь. Обратите внимание, насколько органично вписался сюда цикл PDCA!
От себя добавлю лишь небольшую интерпретацию. Термины Plan-Do-Check-Act – это точки разделяющие фазы цикла. Фазы между точками имеют почти такой же смысл – «Планирую», «Делаю», «Проверяю» и…, как не странно, «Отдыхаю». Так уж распорядилась природа – три четверти активных и одна четверть пассивная.
Demand и Supply, продвигаясь вперед, вдоль оси времени, вращаются вокруг этой оси времени, находясь в полной противофазе. Время на рисунке 5 направлено вперед. В точности вдоль вашего взгляда на эту картинку. Перпендикулярно этому рисунку. Так что труба активностей напоминает скрученную двухцветную карамель из детства. Именно так, не растворяясь друг в друге, а закручиваясь в две спирали по оси времени, Demand и Supply взаимодействуют друг с другом.
Вы не можете одновременно все бегать по клиентам, а вернувшись от них, все вместе наваливаться на решение одной единственной задачи, поскольку каждый должен заниматься своим делом. Хотя, в свежих организациях, на стартапах, все поступают именно так, оправдываясь и называя себя гордым словом «команда».
Чтобы увидеть суть периодичности фаз Demand & Supply, предлагаю, подобно тому, как конфетная обертка разворачивается в фантик, развернуть круговое вращение потока работ в одну ось координат (рис).
Рис. . Развертка Трубы активностей
Такое представление позволяет сделать один интересный вывод о том, с чего стартуют и чем заканчиваются циклы PDCASupply и Demand. Сначала посмотрим на одновременную работу циклов.
Цикл Supplyнацелен навыполнениепланов и выглядит как Plan–Do–Check–Act. Цикл начинается с планирования и заканчивается анализом и принятием решения, что надо бы делать дальше. Однако, в действительности, после этого происходит не новое планирование, как в классическом цикле PDCA, а передача управления в смысловую область бизнеса, где фокус уже лежит на целях и взаимоотношениях с клиентами.
В области Demand, цикл нацелен на исследование складывающейся в бизнесе ситуации. Цикл выполняется в последовательности Check–Act–Plan–Do, то есть начинается с проверки. Проверки, что делается на рынке, что делается внутри системы, каковы возможности и что за решения по поводу дальнейших действий напринимала инфраструктура. Заканчивается же верхний цикл фазой Do. Но для смысловой области бизнеса Demand, фаза Do – это не столько действие физическое, сколько действие информационное. Именно в этой области работают маркетинг, реклама, продажи.
Теперь посмотрим на весь цикл глазами Demand. Все очень даже похоже на происходящее в реальном бизнесе. На первой фазе, пока вы изучаете рынок и планируете будущие проекты, технари-исполнители уже выполнили очередную прошлую задачу и проверяют результаты ее внедрения. Более сложный для реализации и понимания следующий второй этап. Технический персонал перешел в режим отдыха, расслабившись в поисках новой следующей задачи. А у вас наступила фаза 2 основной активности. Что же это за активность?
Результатом Demand не должен быть конечный продукт. Результатом Demand может быть только разработанные архитектура и проект в терминах бизнеса. На этой фазе, вы можете оторвать Supply от заслуженного отдыха и привлечь его к разработке вашего собственного Demand продукта, но ответственными за разработку документа, который часто называют БФТ (Бизнес и функциональные требования), являетесь вы и только вы. Другого результата у Demand нет!
Именно поэтому, в методологиях разработки программного обеспечения, отдельно прорастают Business Use Cases и Software Use Cases, а в бизнесе отдельные два документа – БФТ и Технический анализ и дизайн. Их просто делают разные группы людей и это правильно.
На третьей фазе происходит своего рода квантовый переход и передача эстафетной палочки от Demand к Supply. В соответствии с технологией, Supply приступает к планированию изготовления продукта. В это же время Demand релаксирует, проверяя наcколько качественно отработаны БФТ и корректируя, пока еще не поздно планы Supply.
На четвертой фазе, Supply реализует план реализации продукта. Вмешаться в это исполнение со стороны Demand практически нет возможности. Это своего рода фаза отдыха Demand в ожидании реализации задуманного.
И еще немного глазами Supply. Технические же службы, уходя в точке Act в ожидание, что же скажет бизнес, находятся в полной уверенности, что лучше всех проанализировали свои возможности и свежие бизнес-планы. Но затем они с легкостью получают обратно принятые бизнесом решения, которые могут кардинально отличаться от их предыдущего плана. И это нормально! Пауза и передача управления от черных к белым и обратно – лучше, чем попытка делать одновременные, но иногда противоречивые ходы.
И так повторяется из цикла в цикл, от почти мгновенных автоматических операций Run с высокой тактовой частотой, до медленных проектов Change, длящихся месяцами и кварталами.
Хочу поделиться парой личных наблюдений из собственного опыта. Бизнес-планерки, как правило, проводятся в утренние часы. Технические же, планерки, как правило, проводятся во второй половине дня. Понедельник начинается с операционного анализа за прошедшую неделю, вторник – лучшее время для планерок генеральских, среда – день проектных статусных митингов. Сравните со своими компаниями. Думаете все это случайные совпадения?
Подобно тому, как природа развела по фазе и сделала асинхронными периоды управления телом и управления смыслом, так и бизнес-процессы по своей природе асинхронны. Любые попытки их синхронизировать в режиме On-Line важны, но все равно останутся ограниченными. Заниматься одновременно управлением клиентами и инфраструктурой, управлением ожиданиями и разработкой – невозможно, как невозможно одновременно думать левой и правой половинами мозга, как невозможно одновременно писать картину и решать математическую задачу, как невозможно одновременно спать и бодрствовать. Можно к этому стремиться, но невозможно достичь. Таксист, разговорившийся с пассажиром сильно рискует угодить в аварию.
Здесь хотелось бы точных научных или конкретных практических выводов. Думаю, что они лежат в самой модели и у каждого свои. Предлагаю лучше посмотреть и насладиться насколько это гениально уже придумано до нас! А насладившись, стоит вернуться и вспомнить, что, увлекшись горизонтальной осью течения процессов, мы забыли про ось вертикальную.
Четыре направления любой системы
Совмещая вертикальную и горизонтальную оси в виде плоской ортогональной системы координат, совмещая две пары полярностей, мы получим своего рода «сервисный компас», ориентированный своим севером на клиента.
Рис Сервисный компас, ориентированный на клиента.
В таком компасе просматриваются все четыре фазы PDCA (Plan, Do, Check, Act) любого бизнес-цикла. Обычная деятельность Do, исходящая от обоих полюсов вертикальной оси, является своего рода раздражителем, требующим реакции с противоположной стороны. Клиенты своей деятельностью влияют на инфраструктуру и наоборот, изменения инфраструктуры тут же, как в зеркале, сказываются на деятельности клиентов. Между раздражителем и реакцией, всегда должна быть пауза, во время которой проходит процесс в горизонтальном направлении оси: Check – понимание ситуации, сбор, обработка и анализ информации, рефлексия и накопление опыта, Plan– подготовка и исполнение ответной реакции.
Между ними – область Act– принятия управленческого решения. По сути Act– это короткий, но очень важный отрезок времени пребывания системы в состоянии неопределенности и принятия осознанного, часто довольно быстрого, управленческого решения с пониманием и принятием на себя рисков и последствий.
Обнаруженный интуитивно Сервисный Компас, по своей природе, практически совпадает с обычным физическим компасом, но имеет пару странностей. Первая странность такой системы координат в том, что привычное нам направление событий во времени слева направо приводит к размещению в компасе Востока справа, а Запада слева. Думаю, что причина проста. Ведь обычный компас накладывают сверху на карту и смотрят на Землю снаружи вертолетным взглядом. Мы же с вами находимся и смотрим на компас изнутри бизнес-системы, из центра принятия управленческих решений.
Вторая странность – в несбалансированном на первый взгляд движении. По вертикали, от инфраструктуры и от клиентов, поступают взаимовлияющие сбалансированные события. По горизонтали же такого баланса нет, и вся система как будто плавно движется слева направо. Но ведь наша Земля тоже не совершает движений в вертикальной оси. Она вращается и ее физическое движение как раз и происходит поперек меридианов и вдоль параллелей от Востока к Западу. Чего не скажешь о магнитном поле Земли. Там трехмерное движение намного интереснее и сложнее.
В общем, предлагаю зафиксировать статические оси координат бизнеса, и попытаться, по аналогии с магнитным полем, посмотреть подробнее, как в этой системе координат происходят процессы. Для этого вернемся к двойному циклу PDCA.
Ранее мы обнаружили, что цикл PDCA всегда работает как парный. Теперь же проверим как это проявляется в любом бизнесе. Парность цикла PDCA можно увидеть на примере действий водителя такси. На первый взгляд, может показаться, что он «практически одновременно» смотрит на дорогу, приборы и разговаривает с вами, как с клиентом. И все дело как раз в этом слове «практически». Если разобрать более детально, то таксист все время мечется между двумя полюсами, будучи не в состоянии одновременно держать фокус и на разговоре, и на дороге. Можно лишь пытаться это делать, но такие попытки могут плохо закончиться. В действительности, он делает попеременные короткие циклы, уделяя внимание то вам, то управлению, надевая попеременно то шляпу стюардессы, то шляпу пилота. Как мы помним, в более сложном технически самолете эти роли разделены.
Чтобы понять последовательность работы парного цикла PDCA, сначала обратимся к вертикальной оси Сервисного компаса. В нормальном состоянии, когда бизнес-система работает без возмущающих воздействий, внешние события поступают в нее только от двух противоположных источников: сверху – от клиентов, использующих сервисы системы, и снизу – от инфраструктуры, которая предоставляет эти сервисы. Именно для этих полюсов просматривается аналогия с разделением суточного цикла на два оборота AM и PM.
Рис. Ресурсный и смысловой циклы PDCA.
Любая бизнес-деятельность циклична и выполняется в два последовательных цикла: верхний (смысловой цикл) AM, направленный на клиентов, цели, ценности и смысл бизнеса, и нижний (ресурсный цикл) PM, направленный на обеспечение соответствия возможностей инфраструктуры целям бизнеса.
Два таких последовательных цикла присутствуют как в сервисной, тка и в производственной деятельности. Верхний цикл в сервисной компании направлен на качество предоставления услуг. В производственной же компании, основной акцент – это сбыт, произведенных товаров. Нижний цикл сервисной компании направлен на обеспечение достаточной для качественного сервиса инфраструктуры. В производственной же компании, основной акцент нижнего цикла на производстве необходимого количества товаров. Балансировка этих двух циклов и есть предмет логистических задач, повышающих эффективность бизнеса.
Однако современный бизнес, с его короткими циклами и стремлением к режиму On-Line, как ни странно, все больше требует одновременности. Одновременно коррелировать разнородные события, разово принимать единственно верные решения, одновременно развертывать инфраструктуру и клиентские сервисы.
В естественных науках, описывающих физические потоки, существует один красивый прием, позволяющий существенно упростить модель. Еще раз повторюсь, что упрощение касается не физических явлений, а модели нашего понимания. Суть этого приема – переход от нестационарной системы координат к стационарной. Надо перестать бегать в динамике за текущим состоянием системы и посмотреть на нее как на систему, в которой все элементы неподвижны, а между ними происходят потоки. В случае бизнес-системы – это потоки ресурсов и информации. Предлагаю выполнить такой же прием для двойного цикла PDCA в бизнесе. Как легко заметить, для синхронизации управленческих действий, достаточно искусственно сдвинуть фазы циклов так, чтобы точка принятия решения (Act) обоих циклов оказалась совмещенной в центре координат – в центре принятия решений.
Рис. Синхронизация двух циклов PDCA в сервисных осях координат.
Удивительным образом, система координат совпала с Сервисным компасом. По сути, это еще одно доказательство удачно найденной модели.
Теперь легко увидеть еще одну особенность. В обоих циклах фаза Check оказалась слева, а фаза Plan – справа. Здесь просто напрашивается объединение верхней и нижней фазы Check – в единую корреляционную аналитическую машину, а областей Plan – в единую машину планирования и развертывания с единой «дорожной картой».
Рис. Единая корреляционная машина и единая дорожная карта в Сервисных осях
В этих единых процессах уже одновременно и симметрично учитываются события, происходящие на обоих полюсах – во фронт-офисе клиентов и в инфраструктуре. Наличие такой симметричной области – именно то, что крайне важно, и чего так не достает современному высокотехнологическому бизнесу, ориентированному на On-Line предоставление сервисов.
Такая конструкция выглядит немного необычно, но она хорошо отражает ситуацию в реальном бизнесе, где существует большой разрыв между тем, как маркетинг, продажи и колцентры взаимодействуют с клиентами, и тем, как живет технический мир и мир информационных технологий.
Эскалация между разными уровнями принятия решения в направлении к центру – вот главный элемент, на котором, похоже, должен строиться бизнес в левой половине модели, отвечающей за поддержку сервисов. Здесь важно не столько описывать входы и выходы и передачу информации из процесса в процесс, сколько улавливать связи, на основе которых работает корреляционная машина на разных ее уровнях эскалации событий – от мониторинга событий, через уровень инцидентов к уровню проблем. Также важно понимать связи, на основе которых работает общий процесс единого планирования справа, от уровня дорожных карт больших проектов до уровня исполнения мелких работ.
В такой эскалационной иерархии событий и планов знакомые по разным методологиям процессы прорастут в двух частях: слева – как часть мониторинга и аналитики («а что же происходит?»), и справа – как часть действий, направленных как на поддержание, так и на совершенствование качества («что же надо делать?»). С позиций русского менталитета, это те самые два риторических вопроса: «Кто виноват?» и «Что делать?” Кстати, человеку, исполняющему наряд на работы желательно, но не обязательно знать, в каком процессе он исполняет свою задачу. Главное делать это вовремя и качественно. Цель и результат, в конечном счете выше, чем правильность регламента.
Вот мы собственно и получили модель двумерную 2D модель процессов внутри системы, находящуюся на один шаг ближе к реальным процессам, чем простой 1D цикл PDCA
Безусловно можно снова начать смотреть на систему как на черный ящик, нарезая ее на элементы. Однако, мы сфокусировались на взгляде изнутри своей системы наружу, чтобы видеть ее как часть более общей системы. Первичным и главным системным вопросом теперь становится не «Из чего состоит система?», а «Что вы в данный момент считаете границей своей системы?». Например, где провести эти границы для человека в социуме: система, это я сам, семья, команда проекта, дирекция или компания, в которой я работаю? От границ системы зависят ответы на вопросы: кого мы можем считать своими клиентами, что мы можем считать их ценностями, и какими ресурсами мы обладаем?
Вообще говоря, клиентом системы может выступать любой субъект, на которого фокусируется сервис (клиент, поставщик, внутренний сотрудник компании). При изменении роли, меняется только внутреннее наполнение сервисов, но не принцип построения отношений. Однако, наша модель четко говорит о клиенте, расположенyном за границами системы. В эпоху цифровых сервисов, услуга всегда нацелена на внешнего по отношению к компании клиента, на настоящий бизнес-процесс, приносящий добавленную стоимость, а внутренний сотрудник является лишь частным случаем клиента ИТ, работающий по общим правилам.
Есть одно очень интересное свойство такой модели. Где бы вы ни очертили границу системы, граница не повлияет на наличие точки центра управления, на расположение осей и принцип работы двойного цикла PDCA. Это – своего рода компас системы, компас бизнеса.
Как оказалось, природа устроена по принципу голографичности. Часть целого устроена так же, как и все целое. Часть системы устроена также, как и вся система. У человека это проявляется через схожие фрагменты строения частей тела и взаимосвязь точек акупунктуры. В бизнесе через одинаковость принципов, объективно работающих в любой команде, будь то отдел, проектная команда, процесс или компания в целом.
Так что, всегда есть центр принятия решений внутри системы, есть оси, ориентированные на смысл деятельности системы и есть мысленно проведенные границы системы, которые можно защищать или открывать. Есть и понимание направления, в котором направлены процессы. Осталось немного разобраться как же процессы устроены внутри.
Поле бизнес-процессов
~~~
Не горы, не овраги и не лес,
не океан без дна и берегов,
а поле, поле, поле, поле чудес!
(Из к-ф Приключения Буратино)
~~~
В самой природе заложено единство дискретного и непрерывного, единство пустоты и наполненности, единство вещества и поля. «В чем же полезность ваших исследований?» – спросил как-то посетитель, зашедший в лабораторию первооткрывателя полей Майкла Фарадея. «А в чем полезность ребенка? – ответил ученый, – Он вырастает и становится взрослым».
В моделировании бизнес-процессов мы приучены мыслить четко ограниченными дискретными сущностями – модулями и этапами, которые обмениваются друг с другом информацией и ресурсами. Подобно тому, как песчинки толкаются друг с другом, просыпаясь через узкое горлышко песочных часов, процессы передают события на вход другим процессам, а шаги процессов – шагам параллельных процессов. Но вот только заполняет ли этот набор кубиков сплошным образом все то, что происходит внутри компании? Похоже, что нет.
Рис. Границы и правила системы сильно упорядочивают процесс
Если бы у песочных часов не было бы стенок, песок бы хаотично рассыпался на нижней поверхности. И это был бы то же процесс, подверженный всего лишь двум, но сильным правилам: невозможно двигаться по направлению наверх, а также – нижнюю поверхность невозможно пересечь насквозь. Стеклянные стенки являются дополнительными ограничивающими правилами системы под названием «песочные часы». Вместе с узким горлышком они задают более тонкие упорядочивающие границы процесса. Какие бы цели ни ставились перед песчинкой, она все равно попадет в нижнюю часть системы и обязательно через узкое горлышко. Можно задаться более высокоточной целью и попытаться рассчитать в какой момент времени какая песчинка должна находиться в каком месте и рядом с какой другой – простроить точный выверенный процесс. Но зачем? Похоже, цель конечного результата будет достигнута в любом случае. Если искать примеры чуть ближе к деловому миру, то, например, бесполезно и бессмысленно пытаться описать процесс движения на автодороге. Для этого достаточно Правил дорожного движения.
А как насчет пространства между песчинками? На что больше похож реальный бизнес-процесс? Может быть в своих бизнес-процессах, мы имеем дело не с песочными, а с водными или воздушными часами, сплошным образом заполняющими пространство системы? А что если представить, что все действительно происходит в некоем сплошном поле, в котором мы искусственно создаем границы, называя все, что оказалось внутри, – системами? А внутри систем искусственно нарезаем процессы и их шаги?
Мы уже нащупали, что есть компас, указывающий своим Севером на клиента. Но если есть компас, то просто обязано быть и поле, в котором он показывает свое главное направление. И таким полем является полный набор всех активностей компании. «Сервисный компас», по сути, представляет собой оси координат в сплошном поле сервисно-ориентированных процессов. На рисунке я постарался отобразить как может выглядеть поле скоростей происходящих в системе процессов.
Рис. Поле сервисных процессов. Области скоростей.
Довольно необычно смотреть на происходящие процессы как на непрерывное поле деятельности. Однако, нарезка процесса на модули и шаги, удобна только на локальном участке процесса, и не позволяет за отдельными деревьями увидеть весь лес.
Из этой картинки не видна динамика процессов, но видна неоднородность скорости происходящих процессов. Все поле, условно делится на симметричные области. На обоих осях расположены мгновенно работающие процессы. Ранее мы их назвали процессами Run. В крайних случаях Run действие клиента по вертикали мгновенно достигает дна инфраструктуры, а Run реакции на события по горизонтали быстрые и доведены до полного автоматизма. Но чем дальше мы удаляемся от осей к диагонали и чем ближе приближаемся к центру координат, тем медленнее проходят процессы. Происходит тот самый плавный переход от Run к Change.
Чтобы не быть обвиненным в голой абстрактной теории, хочу привести практический пример, как в таком поле проявляется картина основных процессов поддержки и развития современного технологичного электронно-цифрового бизнеса.
Рис. Поле сервисных процессов: локализация основных процессов.
В левой половине поля проявились процессы мониторинга и анализа ситуации. Самые скоротечные процессы собственно предоставления сервиса и автоматические реакции на незначительные отклонения в сценариях, расположены непосредственно на осях. Чуть более медленные, такие как мониторинг технических событий и управление обращениями клиентов – симметричны друг другу и расположены на диагоналях, далеко от центра. Управление инцидентами – чуть более медленный процесс, расположен на горизонтальной оси. Он коррелирует события, поступающие в колцентр от клиентов и от мониторинга технической инфраструктуры.
Гораздо более медленные процессы – процессы управления производительностью инфраструктуры и управления клиентским опытом – симметричны друг другу и располагаются на диагоналях, поскольку каждая из них сфокусирована на свой полюс. Однако и между ними на горизонтальной оси располагается процесс управления проблемами и качеством, который коррелирует взгляды на клиента и на инфраструктуру, подготавливая, тем самым, гораздо более крупные, чем при одиночных событиях или инцидентах, управленческие решения.
В правой половине поля сформировались процессы планирования и развертывания действий. Крупные управленческие решения влекут за собой инициацию крупных проектов. Мелкие управленческие решения приводят к необходимости управлять изменениями – от крупных до довольно мелких. Любое же управленческое решение влияет на оба полюса. Вверху – на необходимость конфигурировать клиентские сервисы, внизу – на необходимость выполнять работы на технической инфраструктуре, которая обеспечивает эти сервисы.
При взгляде на процессы, как на сплошное поле, вопросов, чем отличается управление проектами от управления изменениями или как одно событие порождает инцидент или проблему, даже не возникнет, поскольку один процесс плавно перетекает в другой.
Необычность и неприятие, на мой взгляд, может вызвать лишь резкий, скачкообразный, я бы сказал – квантовый переход в быстрых областях процессного поля на самих осях координат. Это ситуация, когда происходит обычный процесс предоставления сервиса, все идет нормально и не требуется никакого вмешательства.
Рис. Процесс предоставления сервиса в предельном случае.
По сути, это разрыв функции, где в пределе происходит крестообразное движение. Сначала сверху вниз, а затем, резко переместив фокус, направо. Повторюсь. Сначала – сверху вниз, а затем – по горизонтали. Это и есть предельный случай, к которому надо стремиться! Случай, и направление движения, когда в процессе все происходит гармонично, как и задумано создателем системы.
Ничего не напоминает? Необычно? Да. Но ведь и в физике, до появления квантовой теории все процессы считались плавными, а бесконечность – абстрактным математическим понятием.
В попытке ответить на вопрос, заданный Майклу Фарадею, в чем же может оказаться полезность взгляда на деятельность как на поле, придется ненадолго чуть глубже занырнуть в организацию информационных технологий. Поле бизнес-процессов напрямую показывает, как можно сочетать надежное управление крупными релизами бизнес-систем и скоростное внедрение удобных фич для электронных клиентов. Классические практики управления изменениями с длительными циклами разработки, точным выполнением заявленных на старте требований и доскональным тестированием, не работают или неэффективны в целом ряде областей. Попытка же полностью заменить их на подход быстрой итеративной разработки неэффективна, поскольку прямо приводит к рискам крупных сбоев критически важных систем. Чего стоит, например, программный сбой в аэропорту Хитроу.
Гибкое сочетание управления тяжелыми релизами, короткими разработками и настройками, выполняемыми самим клиентом являются своего рода искусством. Сервисные оси помогают выделить эти области внутри архитектуры предприятия.
Рис. Медленные и быстрые области управления изменениями.
В верхней быстрой области изменений Fast, на полюсе клиента лежит настройка параметров сервисов самими клиентами через мобильные и веб-приложения. Если такой возможности нет, вы проваливаетесь в зону Medium с заявкой на выполнение сервисных работ. В нижней быстрой области изменений Fast, на полюсе инфраструктуры лежит настройка качества технического сервиса техническими специалистами. Конфигурирование технических параметров с целью улучшения качества сервиса не требует никаких крупных изменений в бизнес системах.
В областях медленных и тяжелых изменений (Slow) лежат крупные релизы систем, составляющих базис бизнеса (ERP, Billing, CRM). Между областями быстрых и медленных изменений (Medium) находится область быстрой разработки. При правильном построении ИТ архитектуры, можно разнести процессы серьезных изменений ключевых систем и процессы быстрой реакции на возможные потребности групп клиентов. Представляете цену случившегося риска, если бы банк с многомиллионной аудиторией клиентов, каждый день выпусках измененную версию своей системы, выполняющей расчеты? А вот видеть полезные изменения в банковском мобильном приложении мы с удовольствием готовы видеть, хоть каждую неделю.
Практично? Еще как, поскольку вы можете осознанно стыковать процессы, не задаваясь лишними вопросами, а фокусируясь на правилах, например, что и когда считать проектом, изменением и простым действием, а не выстраивая три отдельных процесса с последующим вопросом, а как же это все может согласованно работать.
Но вернемся к непрерывному полю. Смотреть на изолинии удобно, если вы имеете дело со скалярными величинами, такими как температура на карте прогноза погоды. Процесс же всегда имеет направление и скорость. Так и хочется увидеть такую общую картину, подобно тому, как на географических картах изображают холодные и теплые океанические течения. Не претендуя на точность, я попытался изобразить такие холодные и теплые течения на карте системы в сервисных осях координат.
Рис. Главные направления потоков внутри системы
Здесь нанесены не все и только крупные течения. Детализация потребует гораздо большей художественной сноровки, но ее лучше делать не на полях книги, а на практике дальнейшего упорядочения вашего бизнеса или вашей системы, а возможно и мировоззрения.
Можно было бы привести еще ряд полезных применений найденного подхода. Однако, прежде чем это делать, хорошо бы, для начала, попытаться перестать смотреть на свой бизнес и на свои системы глазами консультантов, препарирующих систему как черную коробку на части со входами и выходами либо помещающего вашу систему, как песчинку в большую иерархию. Думаю, что полезно, хотя бы иногда ставить себя в центр осей координат и сверять свои цели, процессы, проблемы и действия с сервисным компасом.
Можно было бы на этом остановиться в изложении идеи поля бизнес-процессов. Но чего-то в общей картине явно недостает. Мы опять увлеклись процессами, забыв об их участниках. О людях, со своими психотипами, со своими мотивами, со своими знаниями. О людях, которые могут все выполнить по инструкции и не принести результат, а могут, отойдя от сценария, превысить ожидания. Давайте заглянем в поле сервисного компаса, удерживая фокус на создании полноценной эффективной команды
