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

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

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

;l

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

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

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

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

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

А что же находится между полюсами клиента и инфраструктуры? Здесь предлагаю проанализировать перехода через одну из самых интересных границ – из мира людей в искусственный электронный мир. Именно на этом стыке, понятия, привычные для людей, превращаются в своих искусственных двойников:

– Люди становятся пользователями;

– Ресурсы превращаются в HardWare, SoftWare, NetWare, DataWare;

– Услуги переходят в форму электронных сервисов.

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

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

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

Поставщик и Клиент одновременно могут находиться в интерфейсе как персонально с глазу на глаз, так и в электронной форме. В контексте интерфейса между людьми, мы имеем дело с так называемым слоем «Customer facing services» – процедурами, сценариями и правилами, описывающими действия людей. Примеры таких сервисов: заключение контракта, изменение параметров сервиса, получение сервиса, оплата счетов. В контексте же интерфейса между элементами технической инфраструктуры, мы имеем дело со слоем «Resource facing services», реализующими сервис электронным способом. Примеры таких сервисов: передача данных по сети, формирование очередного экрана по запросу пользователя, запрос информации в базе данных и т.д.

Так что, архитектурно, субъектами операций могут выступать, как люди (C-Customes) или корпорации (B-Business), так и элементы инфраструктуры (M-Machines). А сочетания их вариантов взаимодействия дают общеизвестные бизнес термины:

С2С – если сервис направлен от человека к человеку,

B2С – если взаимодействует корпорация с клиентом физическим лицом,

B2B– если корпорации взаимодействуют между собой,

M2M– если одно техническое устройство взаимодействует с другим устройством.

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

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

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

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

Ресурсно-сервисную парадигму можно интерпретировать как главную ось координат, полюса которой направлены на Север и Юг «сервисного компаса», ориентированного на клиента. Такая модель хорошо иллюстрирует статическую архитектуру предоставления сервиса. Однако в ней отсутствует динамика происходящих процессов. Физически, ели можно было бы предположить, что отсутствует привычное нам трехмерное пространство 3D, то и Земле не было бы вокруг чего вращаться. Есть лишь одна поляризованная ось. Для того, чтобы отражать причинно-следственные связи процессов, модель должна стать, как минимум, двумерной 2D. Но какие две полярности лежат на второй оси координат?

D

emand

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

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

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

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

Рис. Вторая ось «сервисного компаса» – от возможности к реализации

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

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

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

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

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

Рис. Труба Активностей. Половинки 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». Недостатки обоих подходов хорошо известны.

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