Фармацевтическая компания Fox-Meyer Drugs, стоившая порядка 40 миллиардов долларов, из-за неверного внедрения ERP системы обанкротилась и была продана конкурентам за 80 миллионов долларов. Банкротство произошло потому, что складская логистика компании не измерялась, не мониторилась, не была охвачена ни метриками, ни показателями, ни KPI. При внедрении ERP не заметили разрушение ключевых бизнес-процессов: склады оказались переполнены, клиенты не получали продукцию. В компании отслеживалась прибыль, но не были формализованы логистические бизнес-процессы, которые разрушились за несколько дней. Отсутствие управления—неприятный нюанс, присутствующий на всех предприятиях. Это нужно принять, как данность, вопрос критичности, в том, какие зоны предприятия неуправляемы.

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

В Англии Министерство здравоохранения в целях сокращения времени ожидания в отделениях неотложной помощи решило наказывать больницы, где ждать приходилось больше четырех часов. Программа оказалась внешне успешной, но. На самом деле некоторые больницы стали держать поступающих пациентов за пределами своих стен в машинах скорой помощи, чтобы уложится в отведенные четыре часа(“Bevan and Hood, ‘What’s Measured Is What Matters”).

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

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

Начнем с моделирования.

Менеджмент процессов организует управление с учётом организационных противоречий, существующих в организации. Моделирование процессов—это часть процессного менеджмента. Разработаем упрощённую модель управления с учётом вышесказанного, чтобы приоткрыть завесу и показать как. Чтобы ответить на вопрос: "Может ли обычный руководитель управлять процессами?"

Система, которая сбоит похожа на больного человека. Сбой—это инцидент. Инцидент —это  внеплановое прекращение предоставления сервиса или снижение его качества. Поговорим об инцидентах, заметим, что в ИТ, как и везде нужно заботиться о качестве данных.

В ИТ есть показатель MTTA(Mean Time To Acknowledge), среднее время подтверждения и взятия инцидента в работу после возникновения первых симптомов сбоя. Очевидны параллели между MTTA и «временем ожидания лечения» из «английского» примера. Есть масса способов манипуляций с MTTA (знаю не менее десяти). Искажение информации здесь базируется на сокрытии первых симптомов неработоспособности путём искажения классификации: обращения пользователя о неработоспособности могут оформляться, как просьба о консультации. Предупреждения системы мониторинга о медленной загрузке страницы могут закрываться, как ложные. Информация о симптомах может «теряться» из отчётности...

В ИТ есть ещё один показатель: MTTR(Mean Time To Repair). Здесь под R может скрываться четыре слова с разными смыслами и способами измерения: решение(repair),реагирование(respond), устранение(resolve) или восстановление(recovery). Не спрашивайте почему так—сам «в шоке». Нам подойдёт repair. Напишу несколько строк о манипуляциях с этим показателем.

Пусть целевое значение показателя MTTR—58 минут, а фактическое значение 65минут после пяти сбоев. Встанем на место руководителя отдела администраторов, отвечающего за эксплуатацию ИТ-ресурсов. В его арсенале есть целый набор «нюансов», позволяющих «дезавуировать» нарушение целевого значения. Приведу несколько незамысловатых приёмов:

  • Фальшивые сбои. Если у вас плохие показатели устранения инцидентов, вам достаточно быстренько перегрузить какой‑нибудь маловажный сервер. К примеру за 10 минут. После быстрого рестарта вы поправите себе показатель и получите премию вместо нагоняя. Проверим: (65+10)/6=12,5 минут. Вы‑действительно молодец!

  • Деление длинного сбоя на несколько коротких. Пусть система А поставляет информацию системе Б. Сбой в функционале системы А вызывает сбой в системе Б. Восстановление работоспособности Б требует последовательного восстановления системы А(42 минуты) и системы Б(47 минут).Суммарное время такого восстановления 89 минут. Целевой показатель MTTR в 58 минут нарушен(89/1=89). Однако, если считать MTTR, как время восстановления двух систем по отдельности, то получится хорошо (89/2=44,5). Вы снова молодец, с точки зрения показателей в этом случае.

  • «Досрочное» устранения инцидента. В погоне за KPI, можно рискнуть и сказать, что инцидент устранён, не проверив работоспособности и даже не дождавшись полного восстановления ИТ‑услуги. Пусть сервер перегрузили, он восстановил работоспособность, а система на сервере ещё не развернулась или не обработаны накопившиеся очереди сообщений. В этом случае, вы не соврёте, если скажете, что работоспособность восстановлена, несмотря на недоступность сервиса у пользователей.

Итак, мы имеем два показателя, регулирующие оперативность устранения инцидентов, которые могут оказаться недостоверными. «Висящие в воздухе», без процесса, они кажутся нелепыми и бесполезными. Как управлять, если процент не качественного программного обеспечения вырос по экспоненте в рамках импортозамещения?

Победим описанные неприятные нюансы в отдельно взятом процессе. Разработаем первичную модель процесса с учётом недостатков.

Первичная модель строится на основании опыта разработчика, с учётом мнения экспертов. Это набросок и эскиз будущей картины.

Рассмотрим процесс «Управление инцидентами», описывающий технологию устранения сбоев в ИТ. Цель процесса: минимизация негативного влияния инцидентов на бизнес заказчика. Чаше всего минимизация негативного влияния сводится к минимизации времени устранения. Схематично и очень укрупнено процесс выглядит примерно так:

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

Рекомендую рисовать для себя, можно на листочке, карандашом и криво—помогает в управлении и объяснении. Детализировав до того уровня, на котором управление возможно и оправданно. После этого можно расставлять KPI, показатели и метрики. Здесь мы видим, что минимизировать время устранения инцидента(MTTR) возможно следующими способами:

  1. Сокращение времени взятия инцидента в работу

  2. Сокращение времени поиска способа решения инцидента

  3. Применения оптимального, заранее проработанного «обходного решения»

Эти три момента кто-то должен контролировать. Так, как инциденты—это операционный уровень, то и управлять процессом должен операционный директор ИТ или сотрудник с его ролью. Введём метрики MTTA, метрику «оперативность поиска решения» и показатель MTTR. Мы прекрасно помним, что показатели могут быть искажены, мы понимаем, что аномальные отклонения показателей требуют расследования и анализа, поиска решений. Отдадим эту роль аналитику, которыми обзавелись почти все предприятия подряд. Рекомендую закреплять за аналитиком контроль качества данных. С учётом сказанного, процесс «Управление инцидентами» схематично будет выглядеть так:

Обходное решение (workaround) – уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение.

Применение обходных решений — это наиважнейший инструмент повышения надёжности ИТ-инфраструктуры. Но он же и наисложнейший.

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

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

Модель разработана.

Что даёт нам данный процесс и зачем тратить деньги? Процесс даёт следующее:

  • Возможность управлять планированием решения инцидентов с помощью обходных решений.

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

  • Возможность контролировать время реакции на инциденты.

  • Возможность точнее регулировать SLA устранения сбоев

  • Возможность управления качеством данных, в том числе фактических значений метрик и показателей

  • Можно доминировать над ИТ‑шникамии раз в неделю орать на них, к примеру о том, что не стоит часами перегружать сервера, когда сеть не работает.

Мы разработали модель управления инцидентами—ура! Следующий этап управления процессом—организовать исполнение этого процесса.

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

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

P.S. Менеджмент процессов — это нехитрая наука, которой может овладеть любой хороший руководитель. Можно даже полюбить это дело. Если влюбитесь и на месяц погрузитесь в интернет по этой теме, то вы вы сможете дать фору любому консультанту с самым звонким и даже зарубежным сертификатом.

Комментарии (14)


  1. rinace
    26.10.2024 03:27

    Спасибо за статью. Взял в закладки . Год назад , почитал бы углубленно и более вдумчиво .

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

    С заключением не согласен

    Менеджмент процессов — это нехитрая наука, которой может овладеть любой хороший руководитель. 

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

    Я этим накушался с запасом .....


  1. Johan_Palych
    26.10.2024 03:27

    Интерпретация методологий ITIL/ITSM своими словами?


    1. ingvarotto Автор
      26.10.2024 03:27

      Ну... Если вы увидели эту статью таким образом, то пусть так. :)


  1. maXon777
    26.10.2024 03:27

    Очень понравилась статья и отдельное спасибо за схему процесса. А про управление проблемами продолжение будет? И очень круто почитать про эскалацию инцидента, на схеме как будто только эскалация проблемы есть. Например, инцидент не решается разработанными инструкциями, обходных решений поддержка не нашла, считается ли что они на своем уровне показатель выдержали?


    1. ingvarotto Автор
      26.10.2024 03:27

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


  1. Lord_Koteika
    26.10.2024 03:27

    Крайне занимательная статья, хотелось бы чтобы больше крупных компаний применяла что-то хотя бы близкое к этому (имелся печальный опыт работы в структуре с не отлаженной системой устранения интцидентов)


  1. Irreversib1e
    26.10.2024 03:27

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


    1. ingvarotto Автор
      26.10.2024 03:27

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

      По ходу придется пилить пост про проблемы. Если в минусы не загонят:)


      1. Irreversib1e
        26.10.2024 03:27

        тут есть операционный директор, аналитик - логично им это передать. Или отдельную роль выделить - инцидент менеджер.

        Да, много чего еще можно описать, к примеру "Управление измнениями".


        1. ingvarotto Автор
          26.10.2024 03:27

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

          Но, безусловно, очень много зависит от оргструктуры эксплуатации ИТ.


          1. Irreversib1e
            26.10.2024 03:27

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


            1. ingvarotto Автор
              26.10.2024 03:27

              Всё. Понял: у нас разночтения определений. Ок. Эскалация инцидента или обращение к разработчику или мегаэксперту за помощью, прописывается в процессе управления инцидентами и контрактом с разработчиком/ поставщиком. Это алгоритмизируемая операция, которая на схеме не выделена и требует отдельного разговора. Может быть решена с помощью SLA/OLA, но здесь есть риск манипуляций. С моей точки зрения, лучше проактивно прорабатывать сценарии устранение инцидентов для особо критичных моментов эксплуатации. Хых. У меня в голове аналитик третьей линии поддержки — это эксперт, поэтому некоторая путаница. Аналитик же в моей парадигме — это мозг, оперирующий технологиями управления.


  1. SaX_KT
    26.10.2024 03:27

    "Пусть целевое значение показателя MTTR—58 минут, а фактическое значение 65минут после пяти сбоев."

    "достаточно быстренько перегрузить какой‑нибудь маловажный сервер. К примеру за 10 минут. После быстрого рестарта вы поправите себе показатель и получите премию вместо нагоняя. Проверим: (65+10)/6=12,5 минут. Вы‑действительно молодец!"

    У меня арифметика не сходится. Либо 65 минут в среднем после 5 сбоев, тогда после перезагрузки сервера будет (65*5 + 10)/6=55,8. Да, молодец, но не 12,5.

    Либо 65 минут за 5 сбоев, и тогда 65/5=13, и так молодец.


  1. andrewzaitsev
    26.10.2024 03:27

    Столкнулся с ситуацией: телекоммуникационная компания решила послушать курс ВВедение в ITIL. Во время курса выяснилось, что бедную девочку послали не этот курс, чтобы она выстроила процесс управления инцидентами и внедрила KPI. Поэтому после курса Введение в ITIL была паника. Что делали: сели и описали процесс. Проблема 1: управление инцидентами не изолировано, а взаимодействует с другими процессами, например, управление запросами на обслуживание, управление проблемами. На первом этапе ограничились только инцидентами. Проблема 2: руководство хотело KPI. Я задал вопрос - а вы можете измерить ваш процесс с разбивкой по шагам. Ответ был - нет. Поэтому я и сказал: не можете измерять и не понимаете базовые метрики, значит KPI не может быть