Сбалансированная система показателей для ключевых показателей IT +5


AliExpress RU&CIS

Я ранее написал несколько статей о метриках и ключевых показателях (KPIs) для некоторых процессов Управления ИТ услугами. Вот ссылки на них в случае, если хотите с ними ознакомиться.

Очень круто иметь продуманные ключевые показатели (KPIs) индивидуально под конкретные ITSM процессы, но даже в этом случае можно получить огромный неудобный отчет, из которого не каждый сможет извлечь пользу.

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

Что такое сбалансированная система показателей?

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

  • Финансы - метрики, позволяющие понять, как используются ресурсы вашей компании

  • Клиенты - метрики, позволяющие понять, насколько удовлетворены потребности заказчиков и на сколько заказчики этим удовлетворены

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

  • Обучение и развитие - метрики, позволяющие понять, как вы готовы к будущему и позволит ли ваша процедура непрерывного улучшение оставаться вам конкурентоспособными

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

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

Например, можно в обобщающем ИТ-отчете встретить такие показатели:

  • Финансы: процент расходования годового бюджета ИТ, возврат инвестиций в ИТ проектах.

  • Клиенты: удовлетворенность ИТ-заказчиков, достижение целевых сервисных метрик сквозных процессов.

  • Внутренние бизнес-процессы: количество ITSM процессов с достигнутыми целями, количество IT-проектов, по которым были достигнуты согласованные цели.

  • Обучение и развитие: количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения (CSI), среднегодовое время обучение IT-персонала.

Далее показатели могут быть разбиты для отдельных ITSM процессов или рабочих групп. Например, деятельность технической поддержки (service desk) можно измерить и оценить:

  • Финансы: общегодовая затрат на работу техподдержки, средняя стоимость одного инцидента.

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

  • Внутренние бизнес-процессы: количество проблем созданных техподдержкой.

  • Обучение и развитие: число предложений на улучшение, поданных в реестр процесса непрерывного улучшения сотрудниками техподдержки и принятыми для реализации; число сотрудников техподдержки, которые потратили не менее 4 часов на обучение сотрудников бизнес подразделений.

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

В заключении автор предлагает каждому ответить для себя на несколько вопросов:

На сколько текущие метрики ваших процессов управления ИТ-услугами покрывают все 4 проекции сбалансированной системы показателей?

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

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




Комментарии (17):

  1. badmilkman
    /#22338082

    Без привязки к целям, что Стюард предлагает измерять?

    • GreyBear
      /#22338096

      Уточните, пожалуйста, вопрос. Для чего такие измерения проиводятся?

      • badmilkman
        /#22339134

        Для чего используются показатели? Любые, не только KPI.

        • GreyBear
          /#22339248

          Cпасибо, в такой формулировке смогу ответить.

          Попробуйте почитать еще одну статью Рейнса «Осторожно. Как использовать метрики процессов без вреда для здоровья процессов» habr.com/ru/post/359206, если она не ответит на Ваш вопрос, посмотрю, что еще можно найти.

          PS Рейнс, как и многие, кто связан с любыми best practics, очень не любят давать рекомендации, что именно делать и измерять, предпочитая описывать подходы и в качестве примеров давать кусочки свой удачной практики.

  2. badmilkman
    /#22339358

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

    • GreyBear
      /#22341334

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

    • GreyBear
      /#22343442

      Если нужны подробные примеры по показателям ITSM процеесом, можно посмотреть на COBIT.
      Его позиционируют, как reference (образцовая, примерная) модель процессов, в отличие от ITIL, которую выпускают в мир, как best practics (только best трактуют, как хорошие, а не лучшие :) ).
      Кстати, в COBIT для показателей используется сбалансиованная система…

      • badmilkman
        /#22343676

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

        Если уж совсем примитивно — Заказчик всегда прав.
        и именно он выставляет нам (IT) цели и критерии оценки их достижения.

        • GreyBear
          /#22345926

          Это же ничем не противречит статьям… В них идет рассказ об одном из вариантов (а именно вараинте рекомендуемом в ITIL) как имея цель, cформулированную в понятных для бизнеса категориях (сбалансированная система показателей), плучить ключевые показатели для оценки, которые также можно показывать заказчику, т.к. они сформулированы в его терминах.

          • badmilkman
            /#22347880

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

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

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

            • GreyBear
              /#22347958

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

              «процент расходования годового бюджета ИТ» — о чем может сказать?

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

              рейтинг удовлетворенности по закрытым инцидентам» — где использовать,?

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

              «количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения» — как быть с неприемлемыми или отозванными предложениями?

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

              вообще-то это заказчик выставляет вам цели и критерии оценки их достижения.

              В случаях низкого доверия, да, жестко выставляет. Если доверия побольше, то идет обсуждение. Бывают случаи, когда заказчику все равно, единственное его требование: «чтобы все работало», и тогда приходится выпытывать его процессы и операции, которые поддерживаются ИТ-системами, и из этого получать требования к ИТ.

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

              Каждый решает для себя сам, чем ему пользоваться. Считаете, что для Вас более приемлем lean и готовы сделать его адаптацию под не производство, делайте. Другие выберут ITIL, а третьи поймут что им нужен только COBIT, т.к. внешние аудиты, четвертые выберут IT4IT, а пятые придумают свой уникальный фреймфорк, а еще кто-то скажет, что процессы — это бюрократия и они им не подходят.

              • badmilkman
                /#22348650

                «риски или что денег не хватит» — для чего нужны?
                «работа ИТ не соотвествует ожиданиям заказчиков» — для чего? В SLA это не прописано?
                «процесс непрерывного улучшения» — зачем нужен? Если на него нет спроса.

                ITIL, COBIT, IT4IT — предполагают что IT это нечто обособленное. Если компания и ее продукты чистый IT — их вполне достаточно.
                В большинстве крупных компаний IT это одна из составляющих, тесно с переплетенная с остальными. IT-шные методологии плохо ложатся на весь бизнес, а бизнесовые (тот же lean) в большей части покрывают IT.
                Про «Цифровую трансформацию» каждый утюг вещает. А она предполагает еще более тесное переплетение, и самое главное — единое управление.

  3. GreyBear
    /#22350512

    «риски или что денег не хватит» — для чего нужны?
    «работа ИТ не соотвествует ожиданиям заказчиков» — для чего? В SLA это не прописано?
    «процесс непрерывного улучшения» — зачем нужен? Если на него нет спрос

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

    ITIL, COBIT, IT4IT — предполагают что IT это нечто обособленное.

    Вы не правы, но обсуждение этих вопросов к статье не относится.

    • badmilkman
      /#22352546

      В игру «зачем?» можно до бесконечности играть.

      Что возвращает нас к изначальному комментарию. А должно было вывести на «цель» всей компании.

      • GreyBear
        /#22352574

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

        • badmilkman
          /#22352600

          Нет, я планировал дать читателям дискуссии видение процесса формирования целей. Без понимания которого, на практике, невозможно создать «Сбалансированную систему показателей». Которая, на мой взгляд, подменяет стратегию «Карго-культом» (судя по статьям).
          По нормальному «система показателей» должна быть включена в стратегию, как один из механизмов управления ей.

          UPD: У любой коммерческой компании всего одна цель — Добывать деньги акционерам.

          • GreyBear
            /#22362082

            Здорово, классная цель для дискуссии. А какие на Ваш взгляд могут быть цели на входе в ИТ? Для экономии времени ИТ упростим до отдела техподдержки и процесса решения обращений.