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

Бывают ли правильные градусники?

Опубликовано 9 ноября 2010
Рубрики: ITIL, ITSM, SLA, SLM, BRM, Аудит, Измерение и оценка ИТ, Управление инцидентами
Комментарии

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

Показатель качества Метрика Способ измерения
Корректность регистрации Доля обращений, потребовавших повторного документирования Расчет по данным системы автоматизации
Доля обращений, потребовавших переклассификации Расчет по данным системы автоматизации
Доля обращений, потребовавших уточнения у пользователя  Опрос специалистов второй линии

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

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

"Есть возможность смотреть журналы", – скажете вы. Теперь представьте, что в нашем примере обращений сотни, смотреть журналы вы замучаетесь.

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

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

Если вы ответили: "конечно да, без них никак", то скажите мне, как вы обеспечите корректность таких данных? Можно ли принимать решение на основании таких данных?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Построение системы KPI для ИТ
Как обеспечить управление процессами, проектами, услугами, персоналом

Также по теме:

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

  • old fuddy-duddy

    Думаю, что метрики процессов должны служить индикатором «точной настройки» по более общим целям управления ИТ в целом для конкретной организации. Соответственно, и метрики и способы измерения могут быть любые, лишь бы они действительно помогали «держаться на курсе». А если общих ориентиров нет, то, что ни выдумывай, все равно в раздел Метрики никто и заглядывать не будет.

    • Евгений Шилов

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

      • old fuddy-duddy

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

  • Роман Журавлёв

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

    Если субъективная оценка потребителей и наши измерения совпадают и измеряемые показатели оценены как “хорошие”, то полнота и точность метрик не так уж важны. Если не совпадают и/или “плохие”, это повод проверить и исправить качество объекта и/или систему метрик.

    Осталось только верно идентифицировать потребителей в каждом конкретном случае 🙂

  • Дмитрий Исайченко

    1. При любой технологии измерения значений метрик важно, чтобы потребители не только доверяли цифрам, но и просто понимали что они значат. Сейчас конечно все “местные” скажут, что это очевидно. Практика показывает – нет, не очевидно (увы).
    2. “Субъективные” метрики можно сделать чуть менее субъективными, если хотя бы немного проработать технологию измерения. Например, если способ измерения “чья-то экспертная оценка” или “опрос кого-нибудь”, можно зафиксировать короткий список вопросов, ответы на которые определяют результат оценки. А то один будет оценивать информативность регистрации по наличию скриншотов, а второй – по размеру текста.
    3. Для “субъективных” метрик важно определить в какой мере субъект, выдающий оценку, заинтересован в ее значениях. А также определить не мешает ли эта заинтересованность реализовать цели оценки.

  • Дмитрий Исайченко

    Еще один способ повысить доверие к “субъективным” метрикам – аудит. В ряде компаний регулярный внутренний аудит специалистами, понимающими суть и специфику объекта контроля, это реальность. Надо использовать.

  • Максим Зубаха

    “Не важно, что что-то идет не так. Возможно, это хорошо выглядит.” Первый закон Скотта.

    На мой взгляд у всех потребителей метрик ИТ-процессов есть одна общая черта – мы являемся аЙТишниками. А специфика работы ИТ-специалиста такова, что объективным источником информации о мире являются средства мониторинга, логии и прочее, те самые системы автоматизации. (Хрестоматийный тому пример – “объективный” ответ специалиста: ”У меня все работает”, на “субъективную” жалобу пользователя. Т.е данные системы мониторинга дают более правдивую оценку, чем мнение человека.) Отсюда и повышенное доверие к метрикам, посчитанным программой.
    Если бы потребителем метрик был кассир в гипермаркете, то оценка покупателей и контролеров казались бы более объективными, по сравнению с данным из системы о количестве обслуженных клиентов или скорости сканирования.

    • Евгений Шилов

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

      • Максим Зубаха

        Похоже ваше влияние сказывается сильнее, чем я мог предположить. Следующие строчки были написаны до прочтения поста 11.11.2010 в 14:53.

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

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

        Но профилактику ни кто не отменял;-)

  • Виталий Фролов

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

    • Олег Скрынник

      Не обязательно.

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

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

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

      А метрика-то – чисто субъективная, “нравится – не нравится”.

    • Олег Скрынник

      Вот ещё что. Воспоминания о былом (гы) навели меня на следующую мысль: важно не только значение метрики за период, но и наличие метрики, и способ её получения.

      В том, что мы тогда семь лет назад в своём ИТ ввели эти две оценки пользователя по всем нарядам, пользы было много. Сами оценки работали как индикатор – “Иванов, а почему у тебя по итогам месяца средняя оценка качества работ 4,5? Ты что, забыл как улыбаться надо?”.

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

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

      • Евгений Шилов

        Олег, а путь “сейчас я тебе поставлю тройку, потому что ты мне не понравился” не конфликтный?
        Я бы на месте инженеров переживал об адекватности оценок.

        • Олег Скрынник

          Не-а, опыт показал, что не конфликтный. Бывали и двойки, и единицы. Трудно объяснить почему, но думаю вот что: оценка ставится сразу после завершения работы, при её сдаче. Если она низкая, то всегда понятно почему (варианты “пользователь дебил, никого не любит” бывали, но ОЧЕНЬ редко, из 10 000 пользователей таких были единицы, и они были известны).

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

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

          Наверное так.

        • Олег Скрынник

          Кстати, была ситуация из разряда “ты мне не понравился”.
          Она не попала в оценки за конкретную работу, она была высказана на встрече с директором департамента – очень деловой и адекватной женщиной.

          Директор сказала примерно следующее: “Олег, ваши инженеры не очень воспитанные. С ноги дверь открывают, не здороваются. Поработайте с ними, пожалуйста”.

          Пришлось поработать. Исправились 🙂

          • Евгений Шилов

            Мораль сей басни такова “Не верьте только метрикам – включайте мозг при их анализе” 🙂

            • Олег Скрынник

              Не, ну эта ситуация вообще не про метрики.

              • Роман Журавлёв

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

                Вот у нас сейчас слушатели после курса в анкете ставят курсу оценки, и лишь одна из них – тренеру. Вспоминая былое (гы), несложно вспомнить анкеты, в которых тренер оценивался по 6-7 параметрам. Почему мы ограничились одной шкалой? Ее достаточно, чтобы держать работу тренеров на контроле. Пока оценки не опускаются ниже некого порога, нас не интересуют детали. Если, не дай бог, опустятся, одной из первых реакций станет детализация метрики.

                То есть уровень и число метрик должны соответствовать целям измерений. См. свежий пост Олега про GPS и Арнольда ван Мамерена.

                • Олег Скрынник

                  Классный пример про оценку тренера. Как раз в тему моего поста про виды измерений и “зачем измерять”.

  • Дмитрий Исайченко

    Виталий, плюсы “автоматизированных” метрик понятны. Но и минусы тоже. Предложите, пжл, “объективную” (рассчитываемую системой автоматизации) метрику, которая дает оценку _полезности_ CMDB (т.е. насколько действующая CMDB полезна специалистам в работе). И?

    Максим, +1.

    P.S. Максим, Виталий, рад вас “видеть” здесь 🙂

    • Виталий Фролов

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

      • Дмитрий Исайченко

        “Полезность CMDB возрастает с ростом отношения актуальных данных к неактуальным”

        Актуальность – да, не спорю. А причем здесь полезность? Например, 100% актуальны 59 атрибутов рабочих станций, которые реплицируются из SMS. И какова полезность этой информации?

        “и еще конечно возрастает с увеличением покрываемых категорий, которые реально существуют в инфраструктуре”

        С увеличением степени покрытия категория прежде всего возрастает нагрузка по актуализации этих данных. Сопоставим ли рост нагрузки с added value – опять же большой вопрос. Например, представьте, что в вашу CMDB сейчас будут включены все статические ip-адреса. Вы думаете, что это “неминуемо” приведет к росту полезности CMDB?

        • Виталий Фролов

          Если данные неактуальны, то какая от них польза? 🙂
          Точно также, если категория еще не покрыта CMDB, т.е. не используется в процессе, то пользы от нее ровно ноль, вернее столько же, сколько было до запуска CFG+CHG.
          Опросы и обследования, конечно же вещи полезные, кто б спорил :), хотя и намного более затратные, поэтому и применяют их реже.

          • Дмитрий Исайченко

            “Если данные неактуальны, то какая от них польза?
            Точно также, если категория еще не покрыта CMDB, т.е. не используется в процессе, то пользы от нее ровно ноль, вернее столько же, сколько было до запуска CFG+CHG.”

            Так вывод-то прост. Актуальность – необходимое, но не достаточное условие полезности. Аналогично с покрытием. Т.е. на основании данных об актуальности и покрытии выводы о полезности сделать нельзя. О “неполезности” наверно можно 😉

            “Опросы и обследования, конечно же вещи полезные, кто б спорил, хотя и намного более затратные, поэтому и применяют их реже.”

            +1. Только “реже” не значит “никогда”. Полезность CMDB наверно имеет смысл оценивать в преддверии планового пересмотра правил учета. Это не чаще 1-го раза в квартал (а то и реже, учитывая сроки идентификации CI). Опросить 10 ключевых потребителей раз в квартал – посильно и намного полезнее, чем пытаться заменить их ответы синтетическими расчетами.

      • Евгений Шилов

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

    • Олег Скрынник

      Дим, полезность CMDB – вообще спорная штука. В этом вопросе не до метрик, разобраться бы с самой базой. Некоторые, вроде Скептика, считают что CMDB – это утопия, фантазия, недостижимый идеал.

      Ещё некоторые, которые читали ITIL v3 и видели в нём монстрообразную картинку SKMS, уверены в утопичности этой штуки ещё побольше Скептика.

      Так что нужен другой пример, а не полезность CMDB.

      • Дмитрий Исайченко

        Странный вывод: раз многие сомневаются, пример не подходит 🙂

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

        Ведь одну и ту же задачу можно решить разными способами. Например, можно для сокращения трудозатрат на ежегодную инвентаризацию вести учет перемещения оборудования в течение года и отражать текущее расположение в CMDB. А можно – просто провести раз в год выборочную инвентаризацию. Что трудозатратнее? Сопоставима ли актуальность данных CMDB, всегда “знающей” где находится каждя CI, ценности от ее применения? Ответить на этот вопрос “в общем” нельзя, а для каждой конкретной организации (с конкретными руководителями и задачами) – можно и нужно. Разве нет?

        • Олег Скрынник

          Да нет, я согласен что вопрос интересный, просто не хочется смешивать две большие темы – метрики и CMDB.
          Потому и предлагаю развести их в стороны, а метриках продолжить на другом примере, чтобы не запутаться в чём мы пытаемся разобраться. Излишне не усложнять.

          • Дмитрий Исайченко

            А-а-а-а, в этом смысле. Вэлкам: полнота и своевременность информирования пользоваталей о проводимых изменениях (из проекта). Или: полнота и своевременность оповещений руководства компании о нарушениях в предоставлении ИКТ-услуг (из проекта). Ну и так далее.

            Процесс (по определению) направлен на достижение определенных целей. Цели ставят люди. И не все можно посчитать системой автоматизации. Это ж как в анекдоте про новогодние игрушки: “Не радуют!”.

            • Олег Скрынник

              Та-а-а-а-а-к…

              Простите мне мою безграмотность, но отчего же нельзя посчитать своевременность? Если оповещения отправляет система, то время отправки фиксировать можно. Согласованное (целевое) время можно задать. Далее – сравнить.

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

              Не так?

              (понимаю, что оповещение может и не дойти, но сейчас, надеюсь, не об этом).

              • Дмитрий Исайченко

                Своевременность посчитать пожалуй можно, соглашусь. Но это оценка инструмента (например, оповещений по e-mail), а не результата решения задачи – информированности заданного круга лиц. Эти две вещи моут прилично расходиться. Возможные причины:

                1. выбран не лучший канал коммуникаций (например, оповещение о сбоях компания, о которй я говорю отправляет по sms, а не по e-mail, т.к. слать срочные e-mail топам компании почти бессмысленно);
                2. оповещения отправляются не информативными или не целевой аудитории (т.е. да, понятно, ахтунг, будут менять, но что и на кого это повилияет неясно).

                … и так далее. Мы что меряем – результат или инструмент? Давайте определяться 🙂

                • Олег Скрынник

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

                  Вот если цель – удвоение ВВП, то тут ещё есть шансы. А если “скорейшее восстановление работы” – то всё, вариантов нет.

                  Так?

                  • Дмитрий Исайченко

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

                    Вообще “механическое” представление о деятельности людей, как об объекте управления, который может полностью контролироваться объективно мне кажется сильно упрощенным. Задача – найти правильную “смесь” из механизмов контроля, которая дает возможность управлять без необходимости постоянно погружаться в детали, но при этом знать о том, что происходит за рамками ответа “42”. Разумеется, на практике эта задача вполне решаема, да ты и так это знаешь 🙂

                    • Олег Скрынник

                      Ну с этим-то я согласен 🙂

                      Это мы ещё про аудит не поговорили, про свидетельства там всякие, записи, объективные суждения, наблюдения при проведении и т.д.

                      Это ведь так легко – внешнему человеку оценить работу ИТ-подразделения! Особенно если они сами себя оценивают, и нужно лишь “верифицировать”.

    • Павел Солопов

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

      хотя возможны и другие трактовки. 🙂

      • Дмитрий Исайченко

        “хотя возможны и другие трактовки”

        Вот и я говорю. Зачем выдумывать синтетические метрики, которые предположительно могут косвенно говорить о полезности CMDB (и которые, опираясь на предложенные примеры, таки практически невозможно посчитать, по кайней мере в известных мне системах), если можно 1 раз в квартал опросить 10 человек и получить картину из первых рук?

        Была раньше такая книжка забавная “Физики шутят”. Там была замечательная шутка: “Предложите самый дорогой метод определения постоянной планка”. По-моему аналогии очевидны 🙂 Буйство фантазии при практически нулевом выхлопе.

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

        • Павел Солопов

          Дмитрий, как вопрос поставили, так на него и ответ был дан.
          Вы спросили “Предложите, пжл, «объективную» (рассчитываемую системой автоматизации) метрику, которая дает оценку _полезности_ CMDB”
          Вы же не перечислили состав программного обеспечения, которое я должен был учитывать.
          Да и собственно приведённые мной метрики запросто собираются на любой системе с web интерфейсом, а на данный момент этой дорогой идут практически все.
          тут извините вопрос из разряда: “Как точнее измерить расстояние. Используя весы или попросив прохожиш прикинуть на глаз?”

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

          Хоть это был и не опрос, но всёже ситуация похожая.

          Признаюсь честно, метрики я эти никогда не использовал. Вообще я, если честно, теоретик всё больше. 🙂

  • Дмитрий Исайченко

    Вообще, тут есть еще один важный момент: мне кажется метрики переоценены. Это только один из способов оценки объекта управления, не единственный. Примеры? Извольте.

    1. Разве опрос удовлетворенности пользователей не является важным инструментом для оценки уровня услуг? Разве в ответах пользователей нас интересует только оценка по 5-бальной шкале? А основные “узкие места”, выделяемые пользователями?

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

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

    Все это примеры способов контроля / оценки, которые выходят за рамки метрик. Мне кажется, уповать только на метрики – лишать себя части важной информации об объекте управления. А уповать только на “автоматизированные” метрики – вдвойне. Не убедил?

    • Виталий Фролов

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

    • Лялеко Владимир

      Считаю, что все три ситуации можно считать метриками:

      Поясню на примерах

      1) У одного из заказчиков отлажен процесс, при котором по завершению обработки каждого обращения пользователю отправляется анкета (survey), результаты анкетирования складываются в аналитическую базу данных на основании которых строятся соответствующий KPI, которые влияют на коэффициент премии (наряду со объективными метриками в соотношении 50% на 50%).

      2) В условиях тендера на автоматизацию процессов ITSM у одного из заказчиков были озвучена метрика «Количество предотвращенных инцидентов, за счет своевременного выявления и устранения проблемы». Странное требование, но таковые реалии «хотелок» наших заказчиков 

      3) Внутренний аудит, как правило, вырабатывает собственные метрики, по которым оценивает качество работы IT. Это актуально и для внешнего аудита, например компания Cisco присылает вполне конкретные объективные показатели работы ИТ, необходимые для подтверждение партнерского статуса.

      • Дмитрий Исайченко

        “Назови хоть горшком, только в печь не ставь”.
        (из народной пословицы)

        P.S. А Вы и способ знаете чтобы метрику “2” посчитать? 😉

        • Лялеко Владимир

          К сожалению нет 🙂 В рамках ТКП было предложено, анализировать колличество поступающих инцидентов до внедрения проблем и после. Анализ происходил на основе сравнение трендов до и после.

          • Евгений Шилов

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

          • Павел Солопов

            “Внедрение проблем” хорошо звучит. 🙂
            Действительно зачем прикрываться какими-то ширмами система, ERP, CRM, аналитическая отчётность…
            Честно и откровенно “Предлагаем вам внедрить новую проблему…” 🙂

  • Роман Журавлёв

    меня убедил 🙂

    Между прочим, мне кажется уместным вспомнить, что ITILv3 довольно много и правильно говорит об этом же в контексте оценки ценности услуг для заказчиков: Ценность субъективна, и не может оцениваться только на основании объективно собранных свидетельств качества. На нее оказывают существенное влияние восприятие заказчика, внешние факторы и проч. (Воспроизвожу по памяти, но за общий смысл ручаюсь).

    Просто ITIL говорит об этом только применительно к сервисам, а в жизни эта же логика применима к чему угодно – продуктам, сервисам, процессам, знакомым, женам-мужьям…

  • Олег Скрынник

    Более общий взгляд на поднятую проблему – http://www.realitsm.ru/2010/11/gradusnik-spidometr-ili-gps-sistema/

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.