Портал №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.

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

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

  • Рубрики

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

    • Новый взгляд на управление знаниями
      В конце 1990-х годов я увлёкся концепцией явного и неявного знания. Это был расцвет эры управления знаниями, и как отраслевому аналитику мне посчастливилось регулярно встречаться …
    • ITIL®4 Specialist CDS: внутренняя культура и коммуникации
      Внутренняя культура организации является одним из наиболее важных компонентов управления услугами, но в большинстве случаев разговоры о ней  ограничиваются словами о «мягких …
    • Технический долг: как не стать жертвой невидимого врага
      Зачастую о техническом долге говорят как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Что подготовить в компании, чтобы заработало управление ИТ-активами?
      Автор — Андрей Боганов, ITSM/ITAM эксперт, тренер курса «Управление ИТ-активами (ITAM)» Для организации управления ИТ-активами «навести порядок» только в ИТ …
    • Технический долг и беклог
      Не могу оторваться от темы беклога, ведь это именно то место, где принимаются решения. Продолжу о вопросах вокруг технического долга и способности команды инвестировать в его …
    • маленькие релизыТри визуализации, которыми я объясняю Agile
      Хорошая визуализация помогает объяснять достаточно сложные вещи. Вместо большого количества слов достаточно одной картинки. У большинства консультантов есть свои любимые …
    • Что дальше в DevOps: AIOps?
      Уже со времен появления гигантских хранилищ и анализа больших данных эксперты говорили о том, какими огромными становятся ИТ—инфраструктуры, и что скоро они станут настолько …
    • Как “продать” место в очереди
      Очередь — одна из раздражающих вещей и пережиток советской эпохи. Она повсюду: в магазине на кассу, у лифта в офисном здании, пробка на дороге – это ведь тоже очередь. …
    • Есть ли польза от оценок трудозатрат разработчиков для самих разработчиков?
      Мы знаем, что заказчикам и заинтересованным сторонам проекта нужны оценки по срокам реализации задач. На их основании они строят планы, расставляют приоритеты и планируют даты …
    • Кто тут крайний?
      Забудем на минуту про единорогов, бирюзовые компании, холакратию и прочие мифические концепции. Они, конечно, где-то есть, но не очень рядом. Представим себе традиционную …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT