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

Измеряем Incident management

Продолжаем публикацию находок по измерению процессов управления ИТ, начатую в заметке «Измеряем Problem management».

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

Пришло решение использовать в качестве одного из KPI групп поддержки метрику, значение которой рассчитывается по формуле:

где Кгруппы – KPI группы по своевременности обработки инцидентов;

N – общее число инцидентов, в обработке которых участвовала данная группа, за период;

v– 0 или 1. 0, если i-тый инцидент решён в срок. 1, если инцидент просрочен;

ti – время обработки i-того инцидента силами данной группы, включая время реакции на назначение (время с момента назначения инцидента до переназначения в другую группу или окончания работы);

Ti – общее время обработки i-того инцидента (от регистрации до решения).

Поясню смысл формулы. За каждый инцидент, в обработке которого поучаствовала какая-то группа, она получает балл от 0 до 1. 1 – идеальный вариант, инцидент решён в срок. 0 – наихудший вариант, срок нарушен и ответственность за это целиком лежит на данной группе. Промежуточные значения соответствуют нарушению срока в результате работы нескольких групп. Причём штраф распределяется по группам пропорционально их доле в общем времени обработки просроченного инцидента. Значение метрики формируется усреднением баллов по всем инцидентам, прошедшим через данную группу. Оно также изменяется строго в пределах [0; 1]: 1 – отлично, 0 – наихудший результат. Поэтому для него легко установить целевое значение и использовать полученный KPI для контроля, а также стимулирования работы старших групп поддержки.

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

В литературе не встречал, поэтому решил опубликовать. Критикуйте, пожалуйста. Пользуйтесь на здоровье.

P.S. Примечательно, что эта метрика естественным образом «масштабируется» с уровня отдельной группы до уровня всего процесса. В самом деле, будем укрупнять группы поддержки до предельного состояния, когда единственная группа поддержки – это весь персонал поставщика услуги. В этом случае ti становится равным Ti и формула принимает привычный вид метрики «доля инцидентов, решённых в срок»:

P.P.S. Предложенная метрика также легко может быть модифицирована для учёта того, как сильно просрочены инциденты (если нам не всё равно, был ли срок превышен на одну минуту или в несколько раз). Для этого каждому инциденту можно присвоить вес wi. Вес равен 1, если инцидент решён в срок. Если же срок превышен, то вес может определяться, например, как отношение фактического времени решения инцидента Ti к установленному сроку. Тогда формула для расчёта метрики примет вид:

Чтобы лучше её осознать, введём обозначение:

Тогда метрика принимает привычный вид взвешенного арифметического среднего:

Где вес wi определяет, на сколько (как сильно) был превышен срок обработки i-того инцидента, а рейтинг ri – в какой степени ответственность за просрочку лежит на данной группе.

P.S.P.S. Чтобы предотвратить "футбол" (быстрое, бездумное перекидывание инцидентов в другие группы) плюс к предложенной здесь метрике своевременности нужна вторая метрика – результативности. Она также считается несложно, о ней напишу в отдельном топике. Вместе метрики своевременности и результативности образуют сбалансированную пару KPI для оценки деятельности групп поддержки.

ДОПОЛНЕНИЕ

По итогам обсуждения с Павлом Солоповым (за что ему спасибо) предлагаю альтернативный алгоритм расчёта метрики в P.P.S. Основное отличие – сокращение влияния действий других групп на значение метрики для заданной группы (за счёт нормировки не на общее время обработки Ti, а на срок решения инцидента Ti0).

Формула сохраняет вид взвешенного среднего в P.P.S, меняется только определение операндов. Вес wi равен 1, если инцидент решён в срок. Если срок превышен, то вес равен отношению времени обработки инцидента силами данной группы ti к сроку решения инцидента Ti0 (таким образом, вес может быть и больше, и меньше единицы), но не меньше 1.

Рейтинг ri определяется выражением:

Нормировка [0; 1] сохранена.

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

  • У себя в блоге я разместил перевод статьи “Показатели работы служб поддержки”, автор -Даниэл Вуд (Daniel Wood)
    Руководитель исследования
    SDI (Service Desk Institute)

  • Коллективная ответсвенность получается.
    Как бы хорошо не работала одни, они всё равно несут ответственность за ошибки других. Есть риск внутренних конфликтов между группами.

    Мне кажется более разумным решением заключение формальных соглашений с функциональными группами (OLA). Их исполнение можно контролировать фиксированными метриками.

    При этом отдельно анализируются инциденты в которых SLA нарушен, хотя формально все свои OLA выдержали.

    На основании резултатов анализа принимаются управляющие решения. (Персмотр OLA, Работа с первой линией, чтобы футбол исключить и другой).

    Подобный подход работает. Есть примеры.

    • Про OLA я как-нибудь обязательно отдельно напишу. Это большая и гораздо менее однозначная тема, чем кажется.

      “При этом отдельно анализируются инциденты в которых SLA нарушен, хотя формально все свои OLA выдержали.”

      Можно попросить Вас немного раскрыть тему “отдельно анализируются”? Каким образом? Какой результат такого анализа Вы предполагаете?

    • Pavel Solopov

      OLA хороши в том случае, когда у вас продуманы хотя бы 80% технологических цепочек, т.е. вы предусмотрели как будут решаться 80 из ста инцидентов, в какой последовательности.
      В современном ИТ это не модно – думать. Сейчас принято отдавать всё на “самоорганизацию”.

      • “В современном ИТ это не модно — думать”

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

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

  • Дмитрий, ну разве что совсем не много 🙂

    1) Каким образом анализируются?

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

    Список спорных инцидентов готовится и рассылается предварительно.

    2) Какой результат анализа?

    На основании индивидуального анализа каждого инцидента на той же летучке принимаются управляющие решения (дополнительное обучение, пересмотр соглашений с пользователем и т.д.)

    В общих чертах как то, так получается 🙂

    • Pavel Solopov

      Если инцидентов регестрируется где-то 1000 в месяц, то еженедельные планёрки станут недельными (по длительности).

  • “Каждый инцидент обсуждается индивидуально”

    В небольшой компании с избытком ресурсов почему бы и нет. Теперь представим поток инцидентов 10^3 в день (а это конечно не предел). Допустим, просрочка находится на хорошем уровне – около 5% (не так уж и много). Получаем 50 инцидентов в день, а раз встречи Вы предлагаете еженедельные, порядка 250-300 инцидентов каждую неделю. Многовато для индивидуального разбора.

    “На основании индивидуального анализа каждого инцидента на той же летучке принимаются управляющие решения”

    Ещё сложнее. Во-первых, в основе лежит индивидуальный анализ, а про него см. выше. А во-вторых, не всё просто и с управляющими решениями. Ведь пример, который мы разбираем, предполагает, что OLA выполнены (а это ещё отдельная песня с их согласованием, с контролем исполнения, с реализацией функциональной эскалации, с переназначением и так далее), а SLA нарушен. А какие решения, если все свои OLA выполнили? Постоянно ужесточать OLA? Назначать кого-то крайним?

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

    • Pavel Solopov

      Беда такой метрики в том, что она не показывает конкретное больное место.
      Т.е. одни решают свою часть за два часа, и действительно им именно столько и нужно.
      И другие решают за два часа, хотя могли бы и за час управиться. А в итоге и один и другой выглядят одинаково.
      Получается, что некто отвечающий за оба подразделения не участвует в оптимизации деятельности, он как бы говорит “ну вы там разберитесь ребятки сами, а я посмотрю”.

      • Это очень интересная мысль. Павел, спасибо, я подумаю.

        Первая реакция такова. Больное место вообще может не иметь прямой связи со сроками исполнения. Из того, что кто-то может за час, не обязательно следует, что за час и надо. Это может приводить к “провисанию” других задач. Ведь ИТ-подразделение занимается далеко не только устранением инцидентов. А поэтому сомневаюсь, что есть метрики, которые показывают такие “больные” места. Тут скорее нужен анализ поглубже, чем базовые индикаторы производительности. А Вы знаете такие метрики?

        P.S. Раньше мы для выявления таких узких мест использовали сопоставление просрочки с количеством инцидентов на одного сотрудника группы. Но это, конечно, условность из-за того, что, как и сказано выше, люди заняты не только инцидентами. Да и инциденты весьма отличаются друг от друга, их просто в штуках не сравнить.

        • Pavel Solopov

          Но если метрика не показывает больного места, то зачем она нужна? Как в изестном анекдоте?
          -Штурман приборы!
          -45!
          -Что сорок пять?!
          -А что приборы?

          Если ИТ занимается не только инцидентами, то надо строить сбалансированные метрики, охватывающие все сферы деятельности.

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

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

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

          • “Но если метрика не показывает больного места, то зачем она нужна?”

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

            Кроме того, для меня эта задачка – исключительно практическая. Поэтому строить исчерпывающую систему метрик, достаточных для глубокой аналитики всех аспектов деятельности, я не буду – это слишком долго и непродуктивно. Вы “Цель” Голдратта не читали?

            • Pavel Solopov

              Голдрата не читал.

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

              • “…метрика должна показывать на какой элемент системы оказывать управляющее воздействие…”

                Павел, приведите, пжл, пример целостной системы таких метрик всего по одному (самому простому!) процессу – процессу управления инцидентами.

                • Pavel Solopov

                  У меня нет его, Дмитрий, я же критик. А критики они, вы же понимаете, такие, сами ни ноты спеть не могут, а Шаляпина критикуют. 🙂

    • Получаем 50 инцидентов в день, а раз встречи Вы предлагаете еженедельные, порядка 250-300 инцидентов каждую неделю. Многовато для индивидуального разбора.

      Дмитрий, 5% это процент всех просроченных инцидентов. Спорных из них будет гораздо меньше. Из практики действительно на разбор полётов с момента запуска может уходить по несколько часов. Однако в дальнейшем эта цифра будет уменьшаться, что в целом укладывается в концепцию PDCA.

      А какие решения, если все свои OLA выполнили? Постоянно ужесточать OLA? Назначать кого-то крайним?

      Не обязательно, довольно часто в результате подобных обсуждений приходят к выводу, что заключили соглашения с бизнесом, которые не в состоянии выполнять. Сразу всплывают вопросы, и про людей занятых не только инцидентами, и про завышенные ожидания бизнеса. На моей практике именно такое обсуждение в своё время привело к созданию службы заказчика на одном из телеканалов. И именно подобные встречи помогают лучше понять “где болит”.

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

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

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

      Это актуально не только для IM, хорошая работа ИТ департамента требует слаженной работы разных групп людей, в рамках разных процессов.

      Но для меня это не озночает необходимость коллективной ответственности.

      ИМХО Коллективная ответственность приводит к её размыванию , а это ни к чему хророшему не приводило никогда.

      • Давайте пару примеров. Вот одна группа переназначает в другую, и время бежит. И можно, например, позвонить коллегам, передать собранную информацию, подсказать, что сроки бегут. А можно этого не делать. Зачем? Я инцидент не просрочил, теперь это не мой вопрос.
        Или, например, группа А считает, что косяк у группы В, а группа В уверена в обратном. И можно вместе быстро посмотреть, проверить с двух сторон, чтобы быстрее решить. А можно этого не делать. Зачем? Переназначил и больше это не мой вопрос.
        Так вот, я думаю, Вы меня неправильно поняли. Мне не нужна метрика, определяющая виновного. Я вообще не очень согласен с Вами в том, что стоит тратить массу времени на поиск виноватого, как Вы сами понимаете, его может не быть. Это конвейер и в общий результат вносит вклад каждый. Вместо наказания виновного мне нужна метрика, которая стимулирует правильное поведение (см. примеры выше). Поэтому я её и придумывал. Что касается OLA, они могут порождать конфликты “в полный рост”, и гораздо сильнее какой-либо метрики.
        Впрочем, убеждать Вас не буду. Не используйте 🙂

        • Дмитрий, я не в коей мере не ищу виноватого.

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

          Предложенные вами примеры вполне укладываются в эту концепцию.

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

          Что касается OLA, они могут порождать конфликты «в полный рост», и гораздо сильнее какой-либо метрики.

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

          • “Я всего лишь предположил, что описанный мной подход сильнее отражает концепцию постоянного улучшения (PDCA), чем указанная метрика.”

            Наверно, если бы я предлагал ввести метрику вместо регулярного контроля, в том числе в виде оперативных совещаний, вместо плана управления процессом, Вы были бы правы 🙂

          • “Получается, что формализированные отношения между людьми пораждают конфликты «в полный рост», я с этим не согласен.”

            Я тоже не согласен, если удаётся их формализовать так, что установленные правила а) всех устраивают и б) соблюдаются на практике. Вот, например, конституция в том числе формализует отношения между властью и обществом. Послезавтра мы узнаем, сколько десятков тысяч человек в Москве выразят “радость” такой формализации. В жизни ИТ-подразделений всё точно также.

            • Всех устраивать формализация не будет никогда. Нужно чтобы она устраивала большинство.

              24.12 митинг будет потому, что формализация не “соблюдается на практике”.

              Уверен, что в рамках управления ИТ факты “несоблюдения” можно и нужно пресекать.

              Возвращаясь к теме топика.

              Выскажусь по другому:

              При формализации отношений которые устраивают большинство и соблюдаются на практике. Любые формы коллективной ответственности носят деструктивный характер.

              • Ну вот видите, какие два важных уточнения мы с Вами ввели. Это раз.
                А вот и два: скажите, пжл, Вы полагаете, что в нарушении сроков каждого инцидента можно найти а) одного виноватого и б) найти за приемлемое время (т.е. на приемлемом уровне управленческих затрат)? Или лучше заменить, как Вы это называете, коллективную ответственность, присущую процессу, ответственностью одного крайнего (инцидент менеджера, а ещё лучше “других процессов”)?

                • Почему или? И почему мы ищем виноватого?

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

                  И кстати, я не чего не полагаю, а лишь делюсь опытом нескольких компаний, которые принименяют этот подход в том или ином ввиде. О чем и написал в первом посте.

                  коллективную ответственность, присущую процессу

                  Очень спорное утверждение. Коллективная работа группы людей и коллективная ответственность это разные вещи.

                  Работает коллектив, но отвечает за эту работу всегда конкретные персоналии отраженные в матрице ответственности.

                  Извините не убедили. 🙂

                  • “Извините не убедили”

                    Ага, я и сам вижу. Да и не буду. У Вас хорошая позиция, я сам такую много раз использовал, только без OLA. И то подозреваю, что то, что Вы называете OLA, это совсем не OLA 🙂 Чего в этой позиции не хватает – ясности в отношении способов стимулирования старших групп поддержки. Если менеджер процесса могучий, он их построит и дело постепенно пойдёт. Но я обычно (почти во всех проектах) использую независимые дополнительные механизмы стимулирования старших групп, и эта метрика – один из способов. А то, что Вы в неё не поверили – не страшно, каждый выбирает для себя 🙂

        • Pavel Solopov

          Всё о чём вы говорите в примерах, Дмитрий, больше связано с личной сознательностью конкретных исполнителей. И мало как связано с наличием метрики. Само по себе метрика никак не заставит человека радеть о коллегах или общем деле, если у него нет соответствующего уровня само-мотивации.

          Заставить же действовать по таким схемам большинство можно только путём угрозы, т.е. когда из метрики будет следовать наказание.

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

          • “Всё о чём вы говорите в примерах, Дмитрий, больше связано с личной сознательностью конкретных исполнителей. И мало как связано с наличием метрики.”

            С наличием метрики самой по себе – конечно никак не связано. Но на личную сознательность, как и на личную позицию в целом, руководитель должен иметь возможность влиять. Эта метрика может быть использована руководителем, как один из инструментов.

            “Заставить же действовать по таким схемам большинство можно только путём угрозы, т.е. когда из метрики будет следовать наказание.”

            Кнут и пряник. Только так.

            P.S. Просто потрясающе. Насколько ИТ-шники любят поговорить о метриках, об их объективности, о том, как они сами будут считаться в супер-системе автоматизации, настолько же они опасаются применения этих метрик к себе. Процесс в целом измерять надо обязательно, но нас и наше участие в нём измерить невозможно! А если ещё и наказывать будут по результатам измерения, так вообще караул 🙂 Детский сад.

  • Pavel Solopov

    Эта метрика может быть использована руководителем, как один из инструментов.

    Как её можно будет использовать, если она не показывает на проблему? Тут у руководителя получится методика: Наказать невиновных, нградить непричастных.

    Вот ещё вариант: в инциденте работают два человека. Ограничение длительности по инциденту 3 часа. Задача одного более трудоёмкая и занимает 2,5 часа. Задача второго на 0,5 часа. Первый делает всё в срок, а второй в два раза длиннее положенного. В итоге первый получает 0,16, а второй 0,66. Как эти метрики сможет использовать руководитель? И какие выводы он из них сделает?

    Может быть вот такой ход будет более эффективен:
    Каждый последующий исполнитель может оценить предыдущего, напрмиер по 3-х бальной системе (3-претензий нет, 2-есть замечания, 1- абсолютно не удовлетворительно). Т.е. если вам передали инцидент за 5 минут до окончания срока, или ничего не сделали, или сделали так, что пришлось переделывать, то вы таким образом можете пожаловаться на смежника. Можно оценку снабдить комментарием ещё.
    Потом считаем набранные балы и и если они сильно далеко от количества инцидентов помноженных на 3, то углубляемся в анализ.

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

    • “Вот ещё вариант…”

      Ну, во-первых, ошибка в расчёте. Первый получит 0.29, второй – 0.71.

      Во-вторых, я пишу о метрике для инцидентов. Для инцидента описанная здесь ситуация крайне нетипична (два последовательных шага, да ещё и у каждого известен свой нормативный срок). Для сервисного запроса – возможно, но это обычно реализуется не переназначением инцидента, а разбивкой инцидента на задания. Если бы таких запросов было большинство, такая метрика вообще была бы не нужна, можно было бы просто каждого считать по своим нормативам. Но в жизни таких ситуаций – крайне мало. Как правило, идёт последовательная обработка инцидента группами, каждая из которых по определению должна стремиться решить инцидент быстрее. Это как эстафета. Можно быстрее брать в работу, можно выигрывать время на диагностику за счёт реализации мониторинга, можно снабжать первую линию диагностическими скриптами, можно наполнять базу типовых решений, можно учить персонал, можно пытаться делать так, чтобы реже ломалось (а значит работать в PRB) и так далее. Кто хочет, тот ищет способ. Кто не хочет, тот ищет причину.

      В-третьих, включается элемент стимулирования старших групп. Они работают на конвейере. Ошибка каждого ставит под удар весь ИТ-департамент, потому что для потребителя услуг виноват всегда ИТ-департамент, а не Вася Пупкин. Я почему и вспомнил про Голдратта – стохастические отклонения и зависимость операций. Желание разобраться в ситуации, найти узкое место, исключить его должно волновать не только инцидент-менеджера, которого одарили соответствуюшей обязанностью, но и старших групп – линейных менеджеров. Тогда эффект будет гораздо сильнее, ведь линейные менеджеры – это “нервные окончания” системы управления. Инцидент-менеджер без них – как ясная голова у парализованного тела.

      • Pavel Solopov

        ошибка в расчёте
        Ага, это я сам себя перехитрил… “Думаю два, три в уме…”

        да ещё и у каждого известен свой нормативный срок
        Я не про то, что он так уж прямо “нормирован” (это отдельная тема). Я имею в виду объективную трудоёмкость (например первым надо десяток логов перечитать, чтобы найти сбойный сервер, а вторым сервер этот перезагрузить). Получается, что одни работают на пределе своих возможностей, а метрика их всё равно хуже тех, кто “курит бамбук”.

        включается элемент стимулирования старших групп
        Так я вам про то и говорю, что метрика эта не включит такой механизм (точнее не факт, что включит ). Вот наши первый и второй, опять же. Какой у второго будет стимул улучшаться? Он и так лучше чем первый, а второй может даже если напряжётся, лучше второго не станет – ну объективно у него работы больше.

        • А, так это всё-таки инцидент. ОК, разберёмся. Для этого давайте отделим два смешанных в предыдущем обсуждении аспекта: адекватность расчёта и польза метрики.
          1. Адекватность расчёта. Нормативный срок – 3 часа. При нормативе в 3 часа мы 2.5 занимались диагностикой (опустим пока вопрос времени реакции). Это нормально? А если бы перезагрузка сервера не помогла, даже будучи сделанной за 0.5 часа? Поднимитесь выше уровня расчёта по одному инциденту, и Вы легко сделаете вывод: такая организация работ нормативу в 3 часа не соответствует. И несоответствие тем больше, чем больше времени тратится на каждом из участков. Если мы при нормативе в 3 часа 2.5 часа диагностировали, значит мы на этом участке недостаточно эффективны (недостаточно – для надёжного соответствия нормативу в 3 часа). Именно это и показывает значение метрики. Всё чётко.
          2. Польза метрики. Если не связывать значение метрики с каждым участником обработки инцидента, то всем, кроме последнего участника, на просрочку будет наплевать: «Мы своё дело сделали, а они – просрочили». А у последнего участника всегда будет оправдание: “Если бы мне передали раньше, я бы всё успел”. Это тупик. Старшие групп имеют самое непосредственное влияние на свои ресурсы, они же ближе всего к предметной части и могут предложить новые технические решения (по мониторингу, по диагностике), которые менеджеру процесса не видны. Польза заключается в том, чтобы заставить их думать как руководителей, как изменить организацию работ и технические решения так, чтобы надёжно соответствовать установленным нормативам. Вот тогда и совещание по процессу, о котором справедливо говорит Владимир, будет работой группы, а не метанием бисера силами инцидент-менеджера, который один отдувается за коллективную безответственность.
          Ведь для этого и нужен процесс управления инцидентами (а не процесс обработки инцидентов), включая все его метрики, процедуры, роли и прочее – чтобы влиять на организацию работ так, чтобы минимизировать негативное влияние инцидентов. Неужели не убедил?

          • Pavel Solopov

            К п.1.
            Абсолютно согласен, структуру затрат такая метрика покажет. Правда структуру затрат не относительно SLA, а относительно общих затрат. В формуле (я сейчас не про P.S., P.P.S и т.д.) у вас SLA-то не присутствует.
            Однако, работает это только на еденичном инциденте, при большом количестве инцидентов значения у групп могут уравновеситься, тем более когда мы говорим о абсолютно нестандартных инцидентах, которые не подлежат нормированию.
            Также такая метрика может показать совершенствование какого-либо исполнителя (или группы), но:
            во-первых, этот показатель будет относительным. Чем дольше работают ваши смежники, тем лучше вы выглядите на их фоне. Соответственно если у вас в одном месяце было больше инцидентов в которых вы работали с раздолбаями, а в предыдущем больше инцидентов в которых смежники тоже хорошо себя показали, то у вас будет позитивная динамика, а если наоборот, то негативная…
            во-вторых, метрика вообще поощряет перекидывание провальных инцидентов на кого-то ещё. Т.е. если вы понимаете, что инцидент будет однозначно просрочен, то вам его лучше скинуть кому-то ещё, чтобы получить хоть какие-то балы, а не ноль.

          • Pavel Solopov

            К п.2.
            Действительно метрику можно использовать как показатель улучшения. Типа, вот ребята молодцы, раньше у вас было 0,29, теперь стало 0,32 – растёте…
            Вот только такой рост будет очень дорогим – силы, время, деньги, в то время, как у нас под боком есть запас в 15% (те полчаса, которые вторая группа теряет из-за разгильдяйства), но метрика нам на него не покажет.
            И приходим мы к нерациональному использованию ресурсов. Те, кто и так работает эффективно (в имеющихся услвоиях) должен напрячься ещё больше – внедрить мониторинг, разработать базу знаний и т.д. А тем, кто курит, просто достаточно будет ходить не в дальнюю, а в ближнюю курилку, для них улучшение на 5 минут уже 12% рост.

        • “Получается, что одни работают на пределе своих возможностей”

          Паша, не сочтите за занудство, почитайте “Цель” Голдратта. Там тоже все работали на пределе своих возможностей 🙂

          • Pavel Solopov

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

      • Pavel Solopov

        Вопрос несколько не в тему.
        Для инцидента описанная здесь ситуация крайне нетипична (два последовательных шага, да ещё и у каждого известен свой нормативный срок).

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

  • По теме: не очень раскрыта возможность возврата в группу \ в работу инцидента пользователем, что эээ некоторым образом сильно влияет на методики “обхода” данной метрики 8 )

    offtop: Дима, а почему в старые записи нельзя написать комментарий? я как раз хотел черкнуть о PrbM – сегодня первый раз прямо-таки впрямую воспользовался опытом realitsm )

    • Саша, какие люди!!

      “По теме: не очень раскрыта возможность возврата в группу \ в работу инцидента пользователем”

      Это как раз во второй метрике, о которой “P.S.P.S”. Раскрою, если дело дойдёт. Что-то пока кажется это немногим интересно.

      “Дима, а почему в старые записи нельзя написать комментарий?”

      Это защита от ботов. Статьи старше 60 дней закрываются. Но мне страшно любопытно. Напиши здесь!

      • Про комментарии к старым записям: в качестве эксперимента изменил 60 дней на 500. Посмотрим, может проблема спама преувеличена, да и наш прекрасный фильтр насчитал уже больше 26000 автоматически распознанных и удалённых ненужных комментариев.

        Так что обсуждайте на здоровье где угодно – хоть здесь, хоть там.

      • Просто невозможность возврата (а если возврат есть – то, как этот возврат работает) сильно влияет на работу с данной метрикой. Без возврата всегда будет возможность ее “скинуть” пользователю (статус = выполнено), с незавершенным, или вообще неверным решением.

        • Да нет, тут всё нормально. Во-первых, при возврате продолжится считаться время, повысится вероятность просрочки. Во-вторых, сам возврат снизит метрику результативности. Нет, это не пройдёт.

          • Дим, “ты не понял” (с)

            По твоему тексту сама возможность (!) и правила возврата не описаны вообще )

            • Правда не понял. И похоже продолжаю. Обычно правила такие:
              1. Возврат есть.
              2. При возврате время, которое инцидент находился в статусе “Решено” на проверке решения у пользователя, включается в расчёт времени решения инцидента.
              3. Возврат осуществляется в ту же группу, которая перевела инцидент в статус “Решено”.
              Это оно?

              • Ну что значит “обычно”? Просто мы с тобой привыкли, что это уже хорошая практика. А в общем, для стороннего читателя это далеко не так. В тексте же у тебя не оговорено ничего )

  • Уф. Неплохо поговорили. С одной стороны Владимир, который предлагает для выявления узких мест в процессе вместо метрики использовать индивидуальный анализ всех «спорных» инцидентов на оперативных совещаниях. С другой – Павел, который считает, что эта метрика плоха именно потому что не в состоянии выявить и обозначить узкое место.

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

    Среди прочего в контраргументах постоянно возникает «претензия» в том, что одна группа может в оценке своей работы зависеть от других групп. Я не понимаю, что в этом удивительного. Почему, например, инцидент-менеджер в оценке своей работы зависит от всех групп, и мы считаем это частью логики процессного подхода, а старшие групп, передающих друг другу инцидент по цепочке, друг от друга зависеть не должны? В процессе каждая следующая группа зависит от результатов работы предыдущих. Зависимость является следствием двух факторов: работы на общий результат и взаимодействия друг с другом. Почему и за счёт чего необходимо исключить при оценке деятельности групп это взаимодействие – мне не понятно. Разве от старших групп это взаимодействие не зависит? Разве не линейные менеджеры по своей должностной инструкции организуют взаимодействие подчинённой структурной единицы с другими? Так через обсуждение отдельной метрики мы неожиданно для меня вышли на обсуждение фундаментального вопроса – сути процессного подхода.

    Есть такая замечательна игра. Несколько участников команды собирают из выданных им фрагментов (как паззл) квадраты. Результат достигнут когда ВСЕ члены группы сложили свои квадраты. Для этого надо не первым собрать свой квадрат, а обмениваться деталями со своими коллегами, чтобы ВСЕ квадраты собрались как можно быстрее. Это и есть суть процессной работы. Как бы ни был замечателен Адам Смит в 18 веке, в 20 уже появился Джон Нэш, и принцип «всякий экономический субъект для получения прибыли должен исходить из своих собственных интересов» был подвергнут пересмотру. Где же мы были всё это время, если мы до сих пор воспринимаем процесс, как результат работы независимых групп, в которой есть победители и проигравшие, независимо от общего результата?

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

    • Pavel Solopov

      Не удержусь от комментария. 🙂
      Где же мы были всё это время, если мы до сих пор воспринимаем процесс, как результат работы независимых групп, в которой есть победители и проигравшие, независимо от общего результата?

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

      • “Если рассматривать процесс, как единое целое, то надо делать общую метрику по процессу и предлагать участникам самоорганизоваться, подтянуть отстающих и т.д.”

        Павел, Вы неисправимый оптимист 🙂

        Смотрите лучше на дополнение в тексте поста, который я сделал по Вашей критике.

        • Pavel Solopov

          Не понял, куда смотреть, в какой текст?

          В Оптимисты меня никто ещё не записывал, чаще наоборот. 🙂

          • “Не понял, куда смотреть, в какой текст?”

            В тексте поста (не в комментариях, а в самом посте) слово “Дополнение”, красным цветом, большими буквами. Ниже текст, в котором ответ на Вашу реплику “Чем дольше работают ваши смежники, тем лучше вы выглядите на их фоне”.

  • Pavel Solopov

    К ДОПОЛНЕНИЮ

    Дим, а что такое срок решения и чем он отличается от времени обработки? Я может что-то упустил из текста поста?

    • Срок – норматив (Ti0), время обработки – факт (Ti).

      • Pavel Solopov

        Дмитрий, по поводу формулы P.P.S. (лучше бы было им, конечно, номера присвоить как в учебнике).
        Для начала я не понял, зачем вы на весовой коэффициент W и умножаете и делите, в чём “физический” смысл, так сказать?

        • Павел, смысл очень прост – “утежяление” инцидентов тем более, чем больше они просрочены. Чтобы просрочка в 1 час и в 100 часов отражалась на результатах по-разному. Об этом же сказано в описании.

          • Pavel Solopov

            Это понятно. Я не пойму зачем мы сначала умножаем на W, а потом делим? Смысл метрики какой у нас? Чем меньше, тем хуже, правильно?
            Т.е. если её трактовать словами, то метрика выглядит так:
            Чем дольше мы работали в просроченном инциденте, тем хуже наш показатель (r), но если инцидент был сильно просрочен, то это улучшает наши показатели (умножаем на w), но если сумарная просрочка была высокой, то это ухудшит наши показатели пропорционально этой просрочке (делим на w).
            Не сочтите за занудство, я просто думаю, вы может ошиблись, может на N надо делить всё же?

            • Павел, Вы с понятием взвешенного среднего арифметического знакомы? Быстро об этом можно узнать здесь http://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5_%D0%B0%D1%80%D0%B8%D1%84%D0%BC%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%B2%D0%B7%D0%B2%D0%B5%D1%88%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5.
              В формуле конечно ошибки нет 🙂

              • Pavel Solopov

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

                • “а то, я чувствую, вы и сами уже не рады”

                  Да нет, Паша, дело не в этом. Просто в математике я уверен на 100%. Математика корректна.

                  • Pavel Solopov

                    Да в математике-то наверняка всё верно.
                    2+2=4 – всё верно.
                    А вот чего 4? Яблока, апельсина, километра, килограмм?
                    Вот и в этой метрике, я хотел бы понять на что она указывает, получается некий средний коэффициент участия взвешенный по коэффициенту просрочки…
                    Или просто используем её результат как некое число исключительно для сравнения с другими или самими собой в перспективе?

                    • Метрика показывает степень участия данной группы в обработке инцидентов с учётом нарушения сроков их обработки. Более того, она отражает вклад данной группы в просрочку.
                      Да, забыл. Сравнивать можно и себя с собой, и себя с другими.


Добавить комментарий для Pavel SolopovОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM