«Шум» KPI

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

CleverKPI Разработка сбалансированной системы KPI:
 

от метрик процессов до dashboard’а ИТ-руководителя.
 

Узнайте больше!

Комментарии и мнения

    1. Pavel Solopov

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

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

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

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

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

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

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

    1. Pavel Solopov

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

      1. Вадим

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

        1. Pavel Solopov

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

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

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

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

            1. Pavel Solopov

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

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

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

                напомнило:

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

              2. Вадим

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

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

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

                  1. Вадим

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

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

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

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

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

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

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

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

            1. Pavel Solopov

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

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

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

              1. Вадим

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

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

                  1. Вадим

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

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

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

                    1. Pavel Solopov

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

                    2. Вадим

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

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

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

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

              1. Вадим

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

                Рекомендую.

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

        1. Pavel Solopov

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

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

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

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

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

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

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

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

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

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

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

    1. Вадим

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

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

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

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

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

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

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

          1. Pavel Solopov

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

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

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

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

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

            1. Юсов Алексей

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

                    1. Юсов Алексей

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

    1. Юсов Алексей

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

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

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

  4. Михаил Тобурдановский Автор

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

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
19
Учебный курс:
Основы ITIL (очно)