Интересный факт: подписка на наш e-mail дайджест вдвое популярнее, чем подписка на RSS-ленту. Но и там, и там — сотни читателей. Присоединяйтесь, это удобно!

«
»

«Шум» KPI Комментарии (RSS)

Комментариев: 44 »
23.01.2012
Рубрики: Обо всём на свете

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




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

  • Измеряем Incident management
    Продолжаем публикацию находок по измерению процессов управления ИТ, начатую в заметке «Измеряем Problem management». Примеров метрик по процессу управления инцидентами...
  • Взаимодействие 1-й и 2-й линий поддержки в системе автоматизации
    В очередной раз с несколькими заказчиками обсуждали способы организации взаимодействия первой и второй линий поддержки в системе автоматизации процесса управления...
  • Измеряем Incident Management. Часть 2
    Продолжаем публикацию материалов по измерению процесса управления инцидентами. Чтобы предотвратить «футбол» (быстрое, бездумное перекидывание инцидентов в другие группы) плюс к...
  • Мастер-класс: автоматизация процессов управления ИТ-услугами
    Не могу не поделиться информацией о том, что 10 февраля в 10-00 мы собираемся проводить мастер-класс по вопросам автоматизации процессов...
  • Инциденты и проблемы
    В очередной раз в обсуждении с заказчиком я сталкиваюсь с серьёзным непониманием отличий процесса управления проблемами от управления инцидентами. Корневых...

  1. Дмитрий Исайченко:
    25.01.2012 в 00:39

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

    Ответить
    • Pavel Solopov:
      27.01.2012 в 10:50

      Меньше просрочек, меньше штрафов. Ваша же метрика она включается, только после просрочки.

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

      Если крайний срок можно взять и безболезненно увеличить, то о чём это говорит?

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

      Ответить
  2. Константин Нарыжный:
    25.01.2012 в 11:24

    Миш, а снижение норматива — это как? Был целевой срок час — сделали два или сделали полчаса? Если два то в принципе понятно, как убирается шум.

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

    Ответить
    • Pavel Solopov:
      27.01.2012 в 10:36

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

      Ответить
      • Вадим:
        29.01.2012 в 00:40

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

        Ответить
        • Pavel Solopov:
          30.01.2012 в 11:03

          Не уверен, что подход Голдратта подойдёт для ИТ.

          Во-первых, в ИТ, как правило, производственный центр — один человек. Значит надо отказаться от практики назначения на группу, а распределять все задания поимённо.

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

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

          Ответить
          • Дмитрий Исайченко:
            30.01.2012 в 11:33

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

            Ответить
            • Pavel Solopov:
              30.01.2012 в 11:46

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

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

              Ответить
              • Константин Нарыжный:
                30.01.2012 в 11:55

                напомнило:

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

                Ответить
              • Вадим:
                30.01.2012 в 22:47

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

                я вот видел в МО ребят, которые либо в отсутствие PowerPointа, либо в отсутствие умения с ним работать, либо в отсутствие умения делать презентации, делали их на Excel

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

                Ответить
                • Pavel Solopov:
                  31.01.2012 в 10:43

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

                  Ответить
                  • Вадим:
                    31.01.2012 в 12:51

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

                    но с таким же успехом его можно применить к чему угодно, например, к организации супермаркета.

                    аналогичное могу сказать и про ИТИЛ.

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

                    Ответить
            • Вадим:
              30.01.2012 в 22:43

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

              Ответить
          • Дмитрий Исайченко:
            30.01.2012 в 11:43

            Тут нам Роман очередной перл на днях притащил: img-fotki.yandex.ru/get/4...2_634a02b9_L.jpg

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

            Ответить
          • Константин Нарыжный:
            30.01.2012 в 11:53

            Кроме шуток, Миша, решение, предложенное Павлом? может помочь диагностике, если речь идёт об одной и той же группе сотрудников!

            Временно упраздните эту «группу», пусть назначение происходит на конкретный «производственный центр», поимённо. Так и продиагностируем, какого рода задачи отнимают много времени. То есть неизящно, зато эмпирично.

            А вот про штучное производство, Павел, не соглашусь. Это ж не наш метод! Это метод, «ранее известный как PRINCE2»! ))))))

            Ответить
            • Pavel Solopov:
              30.01.2012 в 12:17

              Это может быть наш метод или не наш, но это объективная реальность, не зависящая от наших мнений и представлений о ней.

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

              По принципу: «В ИТ всё так сложно и непредсказуемо, что ничего не предусмотришь. ИТ это как творчество.».

              Ответить
              • Вадим:
                30.01.2012 в 22:51

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

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

                Ответить
                • Pavel Solopov:
                  31.01.2012 в 10:56

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

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

                  Ответить
                  • Вадим:
                    31.01.2012 в 21:09

                    не надо передергивать, я этого не говорил.

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

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

                    Ответить
                    • Pavel Solopov:
                      01.02.2012 в 10:28

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

                    • Вадим:
                      02.02.2012 в 20:22

                      Инцидент и не «запчасть», это во-первых.

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

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

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

          • Вадим:
            30.01.2012 в 22:48

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

            Ответить
            • Pavel Solopov:
              31.01.2012 в 10:53

              По серости своей, читал только одно произведение, как понимаю, первое: «Цель».

              А что в других 4 книгах он излагает подходы применимые к иным способам производства нежеле в первой?

              Ответить
              • Вадим:
                31.01.2012 в 12:45

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

                Рекомендую.

                Единственно, прошу не делать так, как Вы написали раньше, и не валить все в кучу — кесарю кесарево

                Ответить
      • Константин Нарыжный:
        30.01.2012 в 11:45

        Павел, извините что долго не отвечал.

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

        Ответить
        • Pavel Solopov:
          30.01.2012 в 11:51

          А я разве против?

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

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

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

          Ответить
          • Константин Нарыжный:
            30.01.2012 в 11:59

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

            Вот если бы речь о регулярных регламентных задачах — тогда ок. И это работает много где.

            Как найти — так по метрике Дмитрия, например.

            Ответить
  3. Константин Нарыжный:
    25.01.2012 в 11:26

    И ещё: единственная информационная система, которая не в состоянии фиксировать момент переназначения, которую могу вообразить — это система бумажек-нарядов, которые передаются из рук в руки:))))

    В любой другой таймстемпы изменения полей БД должны записываться. Ну а дальше работают руки, которые эти таймстемпы смогут выцепить.

    Ответить
    • Вадим:
      29.01.2012 в 00:42

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

      Ответить
  4. Дмитрий Исайченко:
    25.01.2012 в 13:12

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

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

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

    Ответить
    • Дмитрий Исайченко:
      25.01.2012 в 13:13

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

      Ответить
      • Константин Нарыжный:
        25.01.2012 в 18:15

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

        Ответить
        • Дмитрий Исайченко:
          25.01.2012 в 23:01

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

          Ответить
          • Pavel Solopov:
            27.01.2012 в 10:41

            Дискуссия напомнила ситуацию с одним моим заказчиком.

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

            Ну я соответственно пытаюсь ему объяснить, что это не побыстренькому, это не так просто...

            На что он мне отвечает «Было бы у меня время, я бы сейчас сам за пару часов сделал...».

            И ведь не возразишь, обвинить голословно нельзя, а друг и правда сделает, а проверить не получится «занят сильно». :-)

            Ответить
            • Юсов Алексей:
              30.01.2012 в 12:38

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

              Ответить
    • Юсов Алексей:
      30.01.2012 в 12:52

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

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

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

      Ответить
      • Вадим:
        31.01.2012 в 21:03

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

        Ответить
  5. Михаил Тобурдановский:
    31.01.2012 в 21:21

    Так получилось, что я выпал из RealITSM и вообще из жизни :-) Просмотрел комментарии — есть над чем подумать :-) .

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

    Ответить

Оставить ответ

Connect with Facebook

Можете использовать эти теги: <b>, <i>, <strike>