Портал №1 по управлению цифровыми
и информационными технологиями

Борьба за своевременность решения

dangerous-growПравда, здорово, когда своевременность решения инцидентов в вашей организации составляет более 95%? Даже отраслевая статистика ниже – средний уровень своевременности решения находится на уровне 82%, и только 13% компаний добрались до лидерских 96-100% («IT Service Management Metrics Benchmarks», Pink Elephant, 2013). Так что больше 95% – это действительно круто. Или нет?

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

А вот с точки зрения процессного контроля все немного сложнее. Фактически, у руководителя есть две принципиально различные стратегии. Первая – выставить высокий показатель своевременности при относительно большом сроке решения и постепенно его сокращать. Например, своевременность 95%, время решения для начала 8 часов, потом постепенно снижаем. Вторая – установить более жесткое целевое время решения, постепенно поднимая планку по своевременности. Например, сразу установить срок решения 2 часа, но начать со своевременности на уровне 50%, постепенно приближая его к целевым 80-90%. И из этих двух вариантов я, пожалуй, голосую за второй.

Во-первых, при прочих равных он заставляет двигаться быстрее, а это именно то, что нужно от управления инцидентами. Во-вторых, о более коротких сроках восстановления легче договориться с заказчиками услуг. А в-третьих, установив целевое время решения далеко от текущих показателей, мы с большей вероятностью избежим ловушки локальной оптимизации. То есть начнем думать не только о том, как быстрее реагировать на поступающие инциденты, но и о том, как сократить их количество, какие заготовить обходные решения и как научиться использовать мониторинг. А поможет нам в этом очень полезный метод – Expanded incident lifecycle.

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Комментариев: 8

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

    • Сложно сказать, но скорее нет — там более-менее равномерное распределение в широком диапазоне значений, дисперсия большая.

  • Андрей, другой

    Мне кажется весьма странным сам принцип назначения сроков и процентов. Т.е. получается, что ИТ рукводитель сам, от балды, ставит значения(не важно срок исполнения или процент своевременности), а потом начинает закручивать гайки. А бизнес процессы и пользователи вообще не при делах. И что удивялться, что они не довольны? Лично я считаю, что и срок исполнения инцидента и процент своевременности должны определяться требованиями бизнес процессов, потребляющих ИТ услугу. И тут надо искать баланс между потерями от простоя и затратами на достижение показателей (длительность и процент своевременности). Какой смысл от 99% процентов своевременности, если затраты на обеспечение этого превысили возможные риски от простоя в разы?

    • получается, что ИТ рукводитель сам, от балды, ставит значения

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

      • Андрей, другой

        Не так важно кто именно случайным (от балды) образом выбирает значения показателей — ИТ директор или бизнес. Важно, что ни тот, ни другой не обосновывают свой выбор экономическими расчетами. В предлагаемом подходе 99% всегда лучше 98%(своевременность или что угодно еще). На самом же деле 98% за 100 рублей намного лучше, чем 99% за 10 000 рублей. "...бизнес далеко не всегда платит..." — бизнес платит всегда. Не всегда в явном виде через оплату услуг. Часто в виде бюджета на ИТ. И неспособность ИТ директора на цифрах обосновать себестоимость услуг и требуемые инвестиции на их развитие с привязкой к прибыли компании существенно снижает его конкурентноспособность в борьбе за бюджет.

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

          А во-вторых, снижение среднего времени решения абсолютно необязательно связано с увеличением затрат, верно? Поэтому, несмотря на то, что тезис о благе экономически обоснованного уровня услуги мной ни в коем случае не оспаривается, жизнь немного сложнее. В частности, думать о сокращении среднего времени решения можно не только в сторону увеличения ресурсов, но и в сторону сокращения потока инцидентов, и в сторону изменения технологии их выявления, диагностики, решения (я ведь не зря упоминал про Expanded incident lifecycle). Более того, нельзя забывать, что рост среднего времени решения, при прочих равных, означает рост операционных потерь, которые также влияют на общую экономику организации.

          Так что я продолжаю настаивать на том, что балда здесь абсолютно не причем.

          • Андрей - другой

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

            "А во-вторых, снижение среднего времени решения абсолютно необязательно связано с увеличением затрат, верно?" — не согласен. Считаю, что не верно. Такое может быть верно, если исходить из того, что для сотрудников созданы идеальные условия и показатели нарушаются исключительно из-за их нежелания работать. Следовательно для улучшения показателей надо мотивировать сотрудников. На самом деле в большинстве случаев есть обективнные причины и для их устранения нужны затраты — изменения в технолиях, внедрение инструментов, дополнительное обучение и т.д. Меня вот, на пример, сколько ни стимулируй, а выше головы не прыгну.

            • Что я могу утверждать — ни разу не были предложены показатели с обоснованным расчетом

              Такое бывает, не спорю. Однако я лично и наблюдал, и участвовал в постановке нормативов SLA с вполне конкретным бизнес-обоснованием, в том числе в привязке к бизнес-планам.

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

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


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT