антон саввинВ природе заложено единство дискретного и непрерывного, единство вещества и поля. «В чем же полезность ваших исследований?» — спросил как-то посетитель, зашедший в лабораторию первооткрывателя полей Майкла Фарадея. «А в чем полезность ребенка? — ответил ученый, — Он вырастает и становится взрослым».

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

 

Между двумя полюсами

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

Подобно тому, как человек мечется между инстинктом и интуицией, компания, как в торнадо, располагается между двумя сходными полюсами (рис.1b).

главные полюса

Рисунок 1. Главные полюса (человек, бизнес, ИТ)

Нижний полюс – область готовых к использованию ресурсов и инфраструктуры компании. Верхний полюс – область смысла существования компании: клиенты с их потребностями, отношением к продуктам бизнеса, желанием или нежеланием пользоваться услугами или вести бизнес вместе с компанией.

По краям такого торнадо – на уровне клиентского фронт-офиса и на самом дне инфраструктуры – расположена область операционной деятельности, где аккумулируется весь накопленный и доведенный до автоматизма опыт компании. К этому опыту можно прикоснуться, ознакомившись с нормативными документами, правилами, процедурами, базами знаний и программным обеспечением. Пополняя свой опыт и выходя в зону стабильного роста, компания начинает «жить инстинктами», обрастает процедурами и становится относительно независимой от отдельных сотрудников и лидеров. Замечу, что рост масштаба бизнеса, как и рост мышечной массы человека, нельзя считать развитием. Чистый рост несет в себе только количественные накопления (увеличение мощности, наращивание потенциала). Он не затрагивает архитектуру и не изменяет суть системы.

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

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

 

От полюсов к экватору

Для современного бизнеса все более критичным фактором успеха становятся информационные технологии (ИТ), для которых справедливы все те же принципы (рис.1с). ИТ-служба внутри компании расположена между полюсами клиентов ИТ и ИТ-инфраструктурой. В методологиях сервисного управления ИТ (ITSM) эту ось принято называть ресурсно-сервисной моделью. Подобная парадигма присутствует в любом бизнесе как набор систем и сервисов, обращенных интерфейсами на клиента, и набор систем и сервисов, обращенных интерфейсами в техническую инфраструктуру.

Идею легко проиллюстрировать на примере действий стюардесс и пилотов во время авиарейса (рис. 2).

ресурсно-сервисная модель полета на авиалайнере

Рисунок 2. Ресурсно-сервисная модель полета на авиалайнере

Несколько лет назад на одной из конференций по управлению ИТ-сервисами западный консультант обратился в зал с вопросом: «Я прилетел в Москву на самолете. И несмотря на длинный путь и разницу во времени, чувствую себя отлично! Скажите, что можно считать сервисом, который мне оказала авиакомпания?». Я предложил свой вариант: «Они доставили вас из точки A (Нью-Йорк) в точку Б (Москва)». «А вот и нет, — услышал я в ответ. — Я чувствую себя отлично, потому что мой полет хорошо поддерживался сотрудниками авиакомпании».

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

Непосредственно во время рейса точкой контакта для получения сервиса выступает стюардесса, но взаимоотношения пассажира с авиакомпанией не ограничиваются процессом полета. Пассажиры заранее купили билеты (продукт авиакомпании), заключив тем самым контракт о будущем получении ценности (быстрое и безопасное перемещение из точки А в точку Б). Для оказания этого сервиса используется высокотехнологичный ресурс (самолет) и высококвалифицированные сотрудники, отвечающие за его управление и эксплуатацию. Так кто же приносит ценность пассажиру – пилот, плавно ведущий самолет на посадку, или стюардесса, приветливо улыбающаяся ему? И где в цепочке оказания ценности место менеджеров, организовавших сложный процесс перелета, и диспетчеров, от которых напрямую зависит жизнь пассажира?

Разобраться помогают понятия «фронт-офис» и «бэк-офис». И стюардесса, и пилот находятся во фронт-офисе – на полюсах ресурсно-сервисной модели. Место стюардессы – на верхнем полюсе: ее деятельность предельно понятна клиенту и не требует специальных технических средств. Пилот в этот же момент времени находится на нижнем полюсе и взаимодействует с инфраструктурой бизнеса авиаперевозчика – сложным техническим устройством под названием самолет.

А что же находится между полюсами клиента и инфраструктуры? Для понимания можно обратиться к архитектуре современного бизнеса (рис. 3), поскольку он практически уже стал цифровым и высокотехнологичным, а ИТ-департамент перестал быть обслуживающим подразделением и превратился в прямого участника цепочки формирования ценности для клиента компании.

архитектура современного бизнеса

Рисунок 3. Архитектура современного бизнеса между верхним и нижним полюсами ресурсно-сервисной модели

На первый взгляд может показаться, что переход от контактов между людьми к чистой инфраструктуре и к взаимодействию электронных битов на информационных носителях носит резкий характер. Однако это не совсем так. Во-первых, в большом облаке сервисов существуют два слоя: сервисы, обращенные к клиенту (customer facing services) – аналог стюардессы, и сервисы, обращенные к ресурсам (resource facing services) – аналог пилота. Во-вторых, между двумя полюсами – двумя фронт-офисами, обращенными наружу, существует слой бэк-офиса. Переход между сервисами и между фронт- и бэк-офисами носит плавный и постепенный характер (рис.4).

плавность перехода между чистыми сервисами  и чистыми ресурсами

Рисунок 4. Плавность перехода между чистыми сервисами и чистыми ресурсами

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

 

Восток и Запад

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

В бизнесе и в реальной жизни, как в шахматах, можно одновременно находиться только в одном из двух состояний: в проактивной фазе, планируя и активно реализуя действия, либо в реактивной фазе, наблюдая и анализируя обстановку в поиске возможностей (рис.5).

вторая ось сервисного компаса

Рисунок 5. Вторая ось «сервисного компаса» — от возможности к реализации (человек, бизнес/ИТ)

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

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

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

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

Теперь самое время совместить обе оси в виде плоской ортогональной системы координат (рис. 6).

сервисный компас

Рисунок 6. Сервисный компас, ориентированный на клиента

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

В таком компасе просматриваются все четыре фазы PDCA (Plan, Do, Check, Act) любого бизнес-цикла. Обычная деятельность Do, исходящая от противоположных полюсов вертикальной оси, является своего рода раздражителем, требующим реакции с противоположной стороны. Клиенты своей деятельностью влияют на инфраструктуру и наоборот, изменения инфраструктуры тут же, как в зеркале, сказываются на деятельности клиентов. Между раздражителем и реакцией всегда должна быть пауза, во время которой проходит процесс в горизонтальной оси: Check – понимание ситуации, сбор, обработка и анализ информации, рефлексия и накопление опыта, Plan – подготовка и исполнение ответной реакции. А между ними – область Act – принятия управленческого решения. Ее можно, как делает международный стандарт ISO 9001, назвать процессом непрерывного улучшения качества системы. Но по сути Act – это лишь небольшой, но очень важный отрезок времени пребывания системы в состоянии неопределенности и принятия осознанного управленческого решения с пониманием рисков и последствий.

 

Поле бизнес-процессов

Если есть компас, то должно быть поле, в котором он показывает направление. Таким полем являются процессы компании. Полученный «сервисный компас», по сути, представляет собой оси координат в поле сервисно-ориентированных процессов (рис.7).

поле сервисных процессов, области скоростей

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

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

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

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

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

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

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

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

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

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

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

 

Так в чем же полезность исследований?

В качестве примера полезности взгляда на бизнес-процессы как на поле можно привести проблему сочетания процесса управления релизами и Agile-разработки. Скорость внешних по отношению к компании изменений и индивидуальный подход к клиентам вынуждает ИТ быть адаптивными, то есть сочетать разные манеры поведения в отношениях с бизнесом. Классические практики управления изменениями (Release Management) с их длительными циклами разработки, точным выполнением заявленных на старте требований и доскональным тестированием не работают или неэффективны в целом ряде областей. Попытка же полностью заменить их на подход быстрой итеративной разработки (Agile) неэффективна, поскольку прямо приводит к рискам крупных сбоев в критически важных системах. Гибкое сочетание подходов от классического управления релизами через Agile до прямого управления настройками, осуществляемого самим клиентом, – своего рода искусство.

Мы привыкли смотреть на Agile как на инструмент быстрой разработки новых продуктов, для которых важны высокая скорость вывода на рынок и итеративная постановка новых требований. Однако для предприятия гораздо важнее применять Agile для уже сложившейся архитектуры. Сервисные оси помогают выделить несколько типов изменений и областей их применения внутри архитектуры предприятия (рис. 10).

медленные и быстрые области управления изменениями

Рисунок 10. Медленные и быстрые области управления изменениями

В быстрых областях проведения изменений (Fast) на полюсах фронт-офиса лежит настройка параметров самим клиентом через веб-приложения (экранные формы, формат и логика отчетов, конфигурирование услуг и т.д.). В областях медленных и тяжелых изменений (Slow) лежат крупные релизы приложений, составляющих базис бизнеса (ERP, Биллинг, Операционный день, CRM). Между областями быстрых и медленных изменений находится Agile. Это уже не классический релиз, но еще не прямая настройка сервиса. Вот почему при помощи Agile в первую очередь дорабатываются интерфейсы клиентских приложений, а также выполняется тюнинг инфраструктуры для качественного предоставления сервиса.

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

местоположение основных бизнес-ролей

Рисунок 11. Местоположение основных бизнес-ролей в сервисном поле процессов ИТ

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

Антон Саввин — руководитель департамента развития систем поддержки операций, «Вымпелком»