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

“Шум” KPI

Опубликовано 23 января 2012
Рубрики: Измерение и оценка ИТ, Обо всём на свете
Комментарии

Немногим ранее Дима опубликовал свои мысли по поводу измерения Incident Management’а и придумал интересную метрику (https://realitsm.ru/2011/12/measuring-incident-management/). Как уже говорилось, выросла она не на пустом месте, а в результате реальной потребности заказчика – в организации задумались о системе оценки персонала ИТ. Показатель по нарушению сроков инцидентов должен был войти в эту систему, и заказчика очень не устраивало то, что фактически ответственность за нарушение срока падала на последнюю рабочую группу, которая участвовала в обработке инцидента. А так как показатели должны были влиять на зарплату сотрудников, то можете себе представить, с какой аккуратностью подходили к созданию метрик. Наличие в системе одного такого «несправедливого» KPI может и революцию породить в рядах трудящихся :). Метрика, предложенная Димой, хороша и проблему такого «шума» в KPI решает. Но вот незадача – чтобы такой метрикой пользоваться, надо откуда-то определенную информацию (о времени обработки каждой группой и переназначениях между группами) брать. Система автоматизации, которая используется у заказчика, такую информацию предоставить не может. Стали рассматривать варианты – можно, конечно попробовать в конфигурацию системы автоматизации определенные изменения внести, но это долго и дорого. Да и в скором времени ее планируют заменить другим продуктом. А информацию по нарушению сроков обработки инцидентов в систему измерений включать необходимо. Клинч :). Думали-думали, и с менеджером процесса пришли к следующему решению: чтобы компенсировать «шум», просто снизили норматив по обработке :). А вы как бы поступили? Может быть, мы прошли мимо какого-нибудь изящного решения? :)

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

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

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

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

    А что даёт снижение целевого значения? Как это помогает в управлении?

    • Pavel Solopov

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

  • Константин Нарыжный

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

    • Pavel Solopov

      Всё зависит от точки зрения. С точки зрения потребителя услуг, ему действительно достаточно того, что виноват поставщик. А внутри самого поставщика как быть? Как найти то слабое звено, из-за которого поставщик постоянно виноват?

      • Вадим

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

        • Pavel Solopov

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

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

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

            • Pavel Solopov

              Надо думать, и пытаться собрать воедино Голдратта, ITIL, CCMI, Agile и прочие, прочие, прочие… Ну и самое главное не забывать про здравый смысл. А не просто ограничиваться чтением отдельно взятых книг. Глядишь чего-то и получится.
              Я вот тут на днях читал про ребят, которые соединили ITIL и армейские наставления по организации полётов (не помню как дословно называется), говорят получился мощный инструмент.

              • Константин Нарыжный

                напомнило:

                – Идите к чертовой матери со своим «Студебеккером »! – заорал Остап. – Кто такой Студебеккер? Это ваш родственник Студебеккер? Папа ваш Студебеккер? Чего вы прилипли к человеку?! Русским языком ему говорят, что «Студебеккер » в последний момент заменен «Лорен-Дитрихом », а он морочит голову. «Студебеккер»! «Студебеккер»!                 (с)

              • Вадим

                скрестить можно что угодно с чем угодно – была бы польза.
                я вот видел в МО ребят, которые либо в отсутствие PowerPointа, либо в отсутствие умения с ним работать, либо в отсутствие умения делать презентации, делали их на Excel
                в военное время косинус достигает четырех, так что я бы не стал до наступления этого момента доверять непрофессионалам в специфических вопросах

                • Pavel Solopov

                  Не совсем понял кого вы непрофессионалом называете и о каких специфических вопросах идёт речь?

                  • Вадим

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

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

            • Вадим

              Опередили… Может ну его – ИТ, в смысле не заняться ли чем-то другим.

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

            Тут нам Роман очередной перл на днях притащил: http://img-fotki.yandex.ru/get/4602/1154545.8c/0_69a72_634a02b9_L.jpg

            По-моему, прямо к этой дискуссии 🙂

          • Константин Нарыжный

            Кроме шуток, Миша, решение, предложенное Павлом? может помочь диагностике, если речь идёт об одной и той же группе сотрудников!
            Временно упраздните эту “группу”, пусть назначение происходит на конкретный “производственный центр”, поимённо. Так и продиагностируем, какого рода задачи отнимают много времени. То есть неизящно, зато эмпирично.
            А вот про штучное производство, Павел, не соглашусь. Это ж не наш метод! Это метод, “ранее известный как PRINCE2”! ))))))

            • Pavel Solopov

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

              • Вадим

                Человек – царь природы! Мы не можем ждать милостей от природы, взять их у нее — наша задача!

                Так что с объективной реальностью (кстати, данной нам в ощущениях) надо находить в себе силы и бороться…

                • Pavel Solopov

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

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

                  • Вадим

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

                    • Pavel Solopov

                      Инцидент для сервисдеска “запчасть”, по скоплению которых Вы предлагаете выявлять слабое звено.

                    • Вадим

                      Инцидент и не “запчасть”, это во-первых.
                      Также, насколько я помню, насчет скопления инцидентов и выявления по нему слабого звена не я писал 31.01.2012 в 10:56. это во-вторых.

                      Для того, чтобы проводить параллели чего-то с чем-то наверное лучше знать/понимать оба предмета. По поводу знания Вами написанного Голдраттом у меня мнение не совпадающее с Вашим.

                      Nothing personal, как говорится.

          • Вадим

            Это Вы о каком Голдратте? Про какую из пяти книг (извините, у меня есть только пять)?

            • Pavel Solopov

              По серости своей, читал только одно произведение, как понимаю, первое: “Цель”.
              А что в других 4 книгах он излагает подходы применимые к иным способам производства нежеле в первой?

              • Вадим

                Точнее применение TOC к другим областям деятельности, в частности, к ИТ-разработкам и к проектной деятельности.
                Рекомендую.
                Единственно, прошу не делать так, как Вы написали раньше, и не валить все в кучу – кесарю кесарево

      • Константин Нарыжный

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

        • Pavel Solopov

          А я разве против?
          Я по поводу Михаила ничего не говорил. Я по поводу ваших слов: “одно из ключевых изменений — это полное упразднение персональной или командной ответственности за просрочку”.

          Вот я и вопрошаю: как найти слабое звено, если персональной ответственности у нас нет.

          Или я что-то неверно понял?

          • Константин Нарыжный

            Аааа, я про то, что искать слабое звено в обработке инцидентов, конечно, необходимо, но категорически против того, чтобы выстраивать систему мотивации на соблюдении нормативов устранения инцидентов!
            Вот если бы речь о регулярных регламентных задачах – тогда ок. И это работает много где.
            Как найти – так по метрике Дмитрия, например.

  • Константин Нарыжный

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

    • Вадим

      Кстати, бумажки-наряды вполне себе могут содержать информацию о переназначении и его времени. Здесь ведь вопрос в информационном наполнении, а не носителе. Не нужно подменять одно другим…

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

    “Ну а дальше работают руки, которые эти таймстемпы смогут выцепить”

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

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

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

      Поправка: “совсем НЕ пару часов”.

      • Константин Нарыжный

        помнится, мои добрые друзья из крупного системного интегратора аналогичную SQL+VB задачу (про календарь) решили за 15 человекочасов с тестированием и простенькой отчетностью в Crystal Reports. Так что дорого и долго – это нужно оценить относительно погрешности, на которую мы согласны, игнорируя “шум”.

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

          Уже не в первый раз убеждаюсь, что в жизни очень важно иметь правильных друзей 😀

          • Pavel Solopov

            Дискуссия напомнила ситуацию с одним моим заказчиком.
            Стал мне заказчик некие свои фантазии высказывать, типа вот это, да вот это сделайте… По быстренькому…
            Ну я соответственно пытаюсь ему объяснить, что это не побыстренькому, это не так просто…
            На что он мне отвечает “Было бы у меня время, я бы сейчас сам за пару часов сделал…”.
            И ведь не возразишь, обвинить голословно нельзя, а друг и правда сделает, а проверить не получится “занят сильно”. 🙂

            • Юсов Алексей

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

              • Pavel Solopov

                Статус говорящего человека не подразумевал возможность ему возражать (если я хотел сохранить отношения с заказчиком). 🙂

                • Юсов Алексей

                  Надеюсь, что проект оказался успешным ;-).

                  • Pavel Solopov

                    C точки зрения финансового результата для меня – Да. 🙂

                    • Юсов Алексей

                      А с точки зрения практических результатов (и “ценности” иже с ними) для заказчика?

    • Юсов Алексей

      Вообще задача, озвученная Михаилом, носит чисто технологический характер. А обходные “процессные” решения ввиде “понижения порога” свидетельствуют о том, что надо либо средство автоматизации менять было уже давно, как несоответствующее требованиям, либо метрики такие не выдумывать.
      И еще один момент из жизни. Я как-то общался с механиками из дилерского центра Audi. Так вот у них ВСЯ! зп зависит от выработки. Не штрафы и премии, а вся! Можете себе представить, с какой тщательностью они подходили к созданию метрик. Тем не менее у них часто встречаются ситуации, когда норматив на решение задачи 4 нормочаса, но реально только один супермеханик может ее решить. И уходит у него на это 8-10 часов, т.к. возникают непредвиденные обстоятельства ввиде, например, приросшей намертво гайки. И такие случаи просто разбираются отдельно начальником цеха и принимается каждый раз индивидуальное решение, т.к. несмотря на на просрочку норматива, это супермеханик решил сложную задачу и сохранил клиента для сервис-центра.
      Так же и решение инцидентов в ИТ нередко затыкается на поиск плавающих ошибок. Так что стремление полностью автоматизировать и формализовать оценку работы, и тем самым избавить руководителя от необходимости думать, анализировать, общаться с людьми и принимать решения, никогда не приведет к построению боевого коллектива, полностью нацеленного на создание “ИТ-ценности” для клиента.

      • Вадим

        маленькая поправка – в идеале ИТ, как учат классики ИТ и SMа, должно создавать для клиента “бизнес ценность”.

        • Юсов Алексей

          Принимается. Благодарю за поправку. Оговорочка по Фрейду :-).

  • Михаил Тобурдановский

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

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

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

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