В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик | К списку авторов | К списку публикаций
Как удачно заметил в своей песне Андрей Макаревич: "Если цель одна и в радости, и в горе, то тот, кто не струсил и весел не бросил, тот землю свою найдет".
Рискну поднять вопрос: а бывают ли в принципе единые цели у сотрудников, работающих по воле рынка в бизнес-компании и выполняющих сервисную поддержку? Думаю, каждый из нас переживает легкое волнение, звоня по телефону в очередной сервис-центр: "Хоть бы трубку снял вменяемый сотрудник!"
Бизнес-процесс хорошо работает, когда:
А если отклонения от сценария происходят? А если они приводят к потере качества? Замечу, что отклонения происходят в случае внешнего вмешательства в работу системы либо в результате внесения в систему изменений. Такие события называются инцидентами. Их решают люди, работающие по сервисным процедурам, но всегда имеющие свободу выбора, чем и как заниматься в следующий момент времени. Но возникает другой вопрос: всегда ли действия людей совпадают с тем, что действительно требуется для бизнеса компании? Ведь когда корабль тонет, можно бежать помогать заделывать пробоину, а можно принять меры по уплотнению дверей своей каюты. Такая ситуация является свойством любой компании.
Что же на эту тему гласят сервисные методологии? Методологии отвечают на вопрос: куда и как быстро бежать, если мы знаем приоритет инцидента, однако не знаем ответа на вопрос: почему событие имеет именно такой приоритет?
Безусловно, каждый руководитель пытается навести порядок и выстроить внутренние приоритеты. Такие локальные правила всегда сопровождаются лозунгом: "Все для клиента", однако сильно ограничены предметной областью подразделения, интерпретацией и личными целями самого руководителя, поэтому созданные несколько сводов правил все равно будут противоречить друг другу. Похоже, что единственный рецепт - это внедрение единой шкалы приоритетов во всей компании. Создавая такую шкалу приоритетов, с одной стороны, надо очень хорошо понимать цели бизнеса, с другой стороны, не менее важно понимать субъективность природы приоритета и попытаться взглянуть на него не со стороны бизнеса, а со стороны человека.
Итак, в центре любого процесса, даже электронного, находится человек. В сознании человека можно условно выделить два полюса: нижний полюс - инстинкт, область накопленного тысячелетиями опыта, где любое внешнее событие вызывает запрограммированную заранее цепочку реакции. Время этой реакции тем быстрее, чем опаснее последствия события для человека. Верхний полюс - интуиция, область нового и неизведанного. Между ними находится логическое мышление, которое мечется между инстинктом и интуицией, пытаясь понять, что же правильно делать, бросаясь то в одну, то в другую крайность.
Для бизнес-системы эти два полюса можно определить бизнес-терминами. Нижний полюс - операции, область накопленного компанией опыта, где любое внешнее событие должно вызывать описанную процедурами и регламентами цепочку действий. Время этих действий тем быстрее, чем опаснее последствия события для компании. Верхний полюс - развитие, область проектов и изменений, направленных на достижение новых целей. Между ними находится тонкая область, отделяющая стандартные действия от изменений. Ни одно изменение не делается при помощи уже существующей логики, процедура может описывать только накопленные опытом стандартные действия. В любом же изменении присутствует момент интуиции и принятия решения двигаться пусть в небольшом, но неизведанном направлении. Находиться одновременно в процессах развития и операций практически невозможно.
Любой процесс - это не просто событие и реакция. Процесс состоит из множества событий и вложенных циклов, каждое из которых имеет свою важность. Визуально это можно представить в виде воронки важности событий (рис. 1).
Набираясь опыта и выходя в зону стабильного роста, компания начинает жить инстинктами, обрастает процедурами и становится относительно независимой от лидерства. Замечу, что рост масштаба бизнеса не является развитием. Чистый рост (Capacity) несет в себе только количественные накопления, не меняя архитектуры, не меняя сути. Поставив новые цели, выходящие за пределы зоны комфорта, компания возвращается в зону развития, где очень слаба роль даже хорошо отлаженных процедур и очень сильна роль лидера. При помощи готовых процедур можно повторить только старые результаты. Для получения новых результатов нужны интуиция и вдохновение.
Рискну высказать спорное, но для меня очевидное суждение. Пара "срочность" и "важность" - это скорее два полюса, а не квадрант, как это принято трактовать на современных бизнес-тренингах. Срочность (внешний фактор) определяет инстинктивную реакцию человека и любой системы на воздействие извне. Важность (внутренний фактор) определяет интуитивный внутренний свободный выбор человека двигаться с определенной целью к пока неопределенному результату. "Скорая помощь" потому и называется "скорой" или "неотложной", что она работает в области операционных инстинктов. Можно, конечно, называть ее важной помощью, но правильно обеспеченное время реакции - самый главный критерий ее работы. Так же смешно будет выглядеть человек, заявляющий о своей цели быстро измениться и достигнуть состояния счастья. Развитие, как правило, результат ежедневных мелких, но правильно направленных действий, которые со временем дают урожай. Ценности порождают мысли, мысли порождают действия, действия порождают привычку, привычка порождает характер.
На практике в бизнес-процессах это имеет очень простое следствие. Для операционных процессов определяющим является понимание критериев качества глазами клиента и поддержка этого качества на уровне, о котором договорились с клиентом или чуть выше, чем у конкурентов. Если же качество упало, необходимо срочно вернуть его в приемлемое состояние. Для процессов развития определяющими являются нахождение целей, действительно важных для бизнеса, и организация оптимального движения к ним.
Наличие нескольких методологий, вера в эти методологии большого количества людей, усилия, которые люди тратят на попытки составить карты соответствия между детальными методологиями, приводят к парадоксальной мысли. Удивительно, но чем более детальной является модель, тем больше она удаляется от происходящего в действительности. Лично я больше верю в здравый смысл и интуицию. Гораздо важнее интуитивно понимать происходящее целиком, чем строить детальную модель и работать с ней вместо реальной действительности. Если уж модели, то максимально простые. Продемонстрирую это на примере. Наиболее удачными, на мой взгляд, являются модель PDCA, держащая в фокусе циклическую суть любого процесса, и модель
BSS/OSS, которая фокусируется на статической архитектуре взаимоотношений бизнеса и клиента (рис. 2).
Совместить эти две модели можно в два шага. На первом шаге зафиксируем 5 базовых процессов, происходящих в любой системе: Fulfilment (Do) - процесс проистекает сам по себе, без вмешательств; Fault Mgt. (Check) - управление ошибками (авариями, инцидентами и проблемами), чтобы восстановить случайно нарушенное качество.
Performance Mgt. (Act) - мониторинг состояния, осознание своих целей и принятие решений по будущим проактивным действиям, Change Mgt. (Plan) - управление изменениями, планирование и подготовка будущих проактивных действий. На рис. 3 приведены развертка четырех базовых процессов и основные понятия, возникающие в них.
Пятым ключевым процессом является Inventory - учет ресурсов предметной области и предоставление информации всем процессам.
Растягивая четыре ключевых процесса к полюсам BSS/OSS (клиент и инфраструктура), мы получаем двенадцать базовых процессов и очень четкое понимание местоположения сервисного процесса управления инцидентами в общей архитектуре (рис. 4).
В классическом Service Mgt. основным источником информации о бизнесе компании является сам клиент, звонящий или пишущий письмо в Service Desk. Приведенный рисунок крайне важен для понимания, поскольку при решении инцидента требуют согласования два разнородных потока информации: от клиента и от технических средств мониторинга. Как же, имея такую разнородную картину, договориться о приоритетах?
Главный приоритет любого бизнеса - прибыль, а главный приоритет поддержки - минимизация возможных финансовых потерь. Но как их измерить on-line? Шкала приоритетов должна быть единой, но потенциальные потери невозможно рассчитать на лету. Представьте себе ситуацию. В вашем серверном помещении вышел из строя один кондиционер, температура постепенно начала повышаться. Если не принимать меры, то с течением времени серверы начнут выходить из строя. Если первым выйдет из строя сервер, принадлежащий команде разработки и используемый для сборки очередного релиза, клиенты этого не заметят. А если выйдет из строя сервер, хранящий последние клиентские транзакции, без которого невозможны текущие on-line-действия клиента? Попробуйте теперь договориться с бизнесом, каков приоритет решения данного инцидента и как потенциальные возможные потери посчитать на лету? А даже если вы договоритесь присвоить этому кондиционеру денежный эквивалент возможных потерь, то кто и в каком процессе будет поддерживать актуальными параметры по всей инфраструктуре? Давайте честно ответим самим себе. Не у всех есть CMDB. А если есть, то не у всех есть достаточный набор учетных объектов. А если есть набор объектов, то далеко не у всех они содержатся в актуальном состоянии. А если процент актуальности большой, то они не содержат никакой информации о бизнес-потерях. А если содержат, то где гарантия, что информация достоверная, ведь ее вносит технический специалист. А если инфраструктура содержит тысячи конфигурационных единиц?
Как видно из рис. 5, влияние на шкалу приоритетов со стороны BSS оказывают параметры важности для бизнеса клиентов и прибыльности сервисов, а со стороны OSS - параметры критичности элементов инфраструктуры и степень деградации сервиса. Основная особенность взгляда со стороны инфраструктуры - это экспертное мнение по поводу критичности элемента инфраструктуры для бизнеса, даже если CMDB ведется на пять с плюсом и в ней есть все связи всех элементов между собой. Это мнение все равно в конечном счете будет экспертным, и бизнесу надо с этим согласиться.
Единственный способ соединить эти два взгляда и два потока - договориться. Не просто спустить вниз приказом, а именно договориться разным бизнес-единицам на разных уровнях. Договориться о количестве уровней в шкале, о временах реакции на инциденты, о соответствии приоритетов бизнеса уровням критичности элементов инфраструктуры. Единый приоритет - это требуемое время восстановления сервиса глазами руководства, интерпретированное взглядами со стороны клиента и технического мониторинга. Это то, как должно быть. Градусник должен быть единым, даже если он иногда не учитывает все факторы. Один раз договорившись, достаточно реализовать это в системе Trouble Ticketing и включить в штатный процесс.
Однако здесь поджидает еще одна проблема. Проблема ресурсов, а точнее, отношение к проблеме ресурсов.
Главной типовой ошибкой является попытка при помощи единой шкалы приоритетов и времени реакции оценивать людей, занимающихся поддержкой. Нельзя заставлять школьника прыгать с шестом на 5 метров - он это не сможет сделать. Нельзя заставлять одного человека сдержать вагон, начавший движение под откос, - ему потребуется помощь или специальные средства. Единая шкала нужна для оценки качества работы бизнес-системы, но не для оценки людей!
Люди, осознав, что при помощи единой шкалы приоритетов их пытаются оценивать, награждать и депримировать, начинают "борьбу с KPI". Приведу лишь несколько примеров такой борьбы.
1 способ - "Понижение приоритета". Как любое правило, правило определения приоритета имеет множество обходных путей - как системных, так и процедурных. Хорошо разобравшись с такими правилами, люди начинают любым способом понижать приоритет решаемого инцидента.
2 способ - "Футбол инцидентами". Поведение похоже на игру шахматиста в партии блиц, где время партии - это время решения инцидента, а персональный KPI - это время, которое инцидент решался не мной. Манера поведения - перевести инцидент на любого другого исполнителя, лишь бы был выключен мой счетчик времени KPI.
3 способ - "Остановись, мгновение". Иногда объективно решатель инцидента может не иметь возможности заниматься решением, например в силу отсутствия доступа на сайт клиента. Это является поводом заказать в системе кнопку "останов времени". Имея такую кнопку, уже никто не проконтролирует, насколько корректно ею пользовались. По сути, это прямое средство манипуляции KPI.
4 способ - "А была ли проблема?". В основном звонки в Service Desk бывают двух видов - жалобы и консультации. Право классифицировать звонок имеют сами сотрудники. Поскольку консультация не требует расчета KPI решения инцидента, сотруднику выгодно любой звонок интерпретировать как консультацию.
И только в случае невозможности решить инцидент самостоятельно возникает необходимость открыть руководству правду. Эта же проблема существует в центрах технического мониторинга.
Вместо попытки загнать всех в одинаковые, но некорректно рассчитанные KPI, есть гораздо более изящный, но требующий управленческого ресурса способ - Service Level Agreement. Однако это предмет отдельной большой статьи. Главное - это понимание, что нельзя манипулировать ни KPI, ни приоритетом и нельзя изменять отношение к приоритету. Он показывает, насколько событие было опасным для компании и как компания с ним справилась. Но можно изменить отношение к результату конкретного сотрудника или подразделения. Поскольку бесконечное качество требует бесконечных ресурсов, мы можем сознательно идти на разный уровень SLA для подразделений, имеющих разные ресурсные возможности.
Приступая к строительству сквозных процессов поддержки и единых приоритетов, надо четко понимать несколько важных моментов.
Единый приоритет - это цель корпорации и предмет договоренности, а время реакции на инциденты - это возможности и желание людей. Единая шкала - лишь способ зафиксировать общие ценности. Единая шкала - это способ оценки качества процесса и бизнес-системы, а не качества людей. Поэтому единый приоритет - не значит единый SLA. Нельзя манипулировать приоритетом, надо договориться о времени реакции, иначе люди начинают бороться с KPI, забывая об инциденте. Нельзя манипулировать в системах астрономическим временем, надо правильно интерпретировать отчеты о ходе решения инцидентов.
Вопросы, которые могут потребовать решения: "Все ли клиенты одинаково важны для бизнеса?", "Все ли согласны со шкалой приоритетов?", "Изменить ресурс или изменить SLA?".
Опубликовано: -2011
Посещений: 24117
Статьи по теме
Автор
| |||
В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик | К списку авторов | К списку публикаций
