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

Им там на заводе попроще было.

Да, забыл. Сравнивать можно и себя с собой, и себя с другими.

2+2=4 — всё верно.

А вот чего 4? Яблока, апельсина, километра, килограмм?

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

Или просто используем её результат как некое число исключительно для сравнения с другими или самими собой в перспективе?

Да нет, Паша, дело не в этом. Просто в математике я уверен на 100%. Математика корректна.

В формуле конечно ошибки нет

Т.е. если её трактовать словами, то метрика выглядит так:

Чем дольше мы работали в просроченном инциденте, тем хуже наш показатель ^®, но если инцидент был сильно просрочен, то это улучшает наши показатели (умножаем на w), но если сумарная просрочка была высокой, то это ухудшит наши показатели пропорционально этой просрочке (делим на w).

Не сочтите за занудство, я просто думаю, вы может ошиблись, может на N надо делить всё же?

Для начала я не понял, зачем вы на весовой коэффициент W и умножаете и делите, в чём «физический» смысл, так сказать?

Дим, а что такое срок решения и чем он отличается от времени обработки? Я может что-то упустил из текста поста?

В тексте поста (не в комментариях, а в самом посте) слово «Дополнение», красным цветом, большими буквами. Ниже текст, в котором ответ на Вашу реплику «Чем дольше работают ваши смежники, тем лучше вы выглядите на их фоне».

В Оптимисты меня никто ещё не записывал, чаще наоборот.

1. Возврат есть.

2. При возврате время, которое инцидент находился в статусе «Решено» на проверке решения у пользователя, включается в расчёт времени решения инцидента.

3. Возврат осуществляется в ту же группу, которая перевела инцидент в статус «Решено».

Это оно?

По твоему тексту сама возможность (!) и правила возврата не описаны вообще )

Павел, Вы неисправимый оптимист

Смотрите лучше на дополнение в тексте поста, который я сделал по Вашей критике.

Где же мы были всё это время, если мы до сих пор воспринимаем процесс, как результат работы независимых групп, в которой есть победители и проигравшие, независимо от общего результата?

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

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

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

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

Среди прочего в контраргументах постоянно возникает «претензия» в том, что одна группа может в оценке своей работы зависеть от других групп. Я не понимаю, что в этом удивительного. Почему, например, инцидент-менеджер в оценке своей работы зависит от всех групп, и мы считаем это частью логики процессного подхода, а старшие групп, передающих друг другу инцидент по цепочке, друг от друга зависеть не должны? В процессе каждая следующая группа зависит от результатов работы предыдущих. Зависимость является следствием двух факторов: работы на общий результат и взаимодействия друг с другом. Почему и за счёт чего необходимо исключить при оценке деятельности групп это взаимодействие – мне не понятно. Разве от старших групп это взаимодействие не зависит? Разве не линейные менеджеры по своей должностной инструкции организуют взаимодействие подчинённой структурной единицы с другими? Так через обсуждение отдельной метрики мы неожиданно для меня вышли на обсуждение фундаментального вопроса – сути процессного подхода.

Есть такая замечательна игра. Несколько участников команды собирают из выданных им фрагментов (как паззл) квадраты. Результат достигнут когда ВСЕ члены группы сложили свои квадраты. Для этого надо не первым собрать свой квадрат, а обмениваться деталями со своими коллегами, чтобы ВСЕ квадраты собрались как можно быстрее. Это и есть суть процессной работы. Как бы ни был замечателен Адам Смит в 18 веке, в 20 уже появился Джон Нэш, и принцип «всякий экономический субъект для получения прибыли должен исходить из своих собственных интересов» был подвергнут пересмотру. Где же мы были всё это время, если мы до сих пор воспринимаем процесс, как результат работы независимых групп, в которой есть победители и проигравшие, независимо от общего результата?

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

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

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

Действительно метрику можно использовать как показатель улучшения. Типа, вот ребята молодцы, раньше у вас было 0,29, теперь стало 0,32 — растёте...

Вот только такой рост будет очень дорогим — силы, время, деньги, в то время, как у нас под боком есть запас в 15% (те полчаса, которые вторая группа теряет из-за разгильдяйства), но метрика нам на него не покажет.

И приходим мы к нерациональному использованию ресурсов. Те, кто и так работает эффективно (в имеющихся услвоиях) должен напрячься ещё больше — внедрить мониторинг, разработать базу знаний и т.д. А тем, кто курит, просто достаточно будет ходить не в дальнюю, а в ближнюю курилку, для них улучшение на 5 минут уже 12% рост.

Абсолютно согласен, структуру затрат такая метрика покажет. Правда структуру затрат не относительно SLA, а относительно общих затрат. В формуле (я сейчас не про P.S., P.P.S и т.д.) у вас SLA-то не присутствует.

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

Также такая метрика может показать совершенствование какого-либо исполнителя (или группы), но:

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

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

Паша, не сочтите за занудство, почитайте «Цель» Голдратта. Там тоже все работали на пределе своих возможностей

1. Адекватность расчёта. Нормативный срок – 3 часа. При нормативе в 3 часа мы 2.5 занимались диагностикой (опустим пока вопрос времени реакции). Это нормально? А если бы перезагрузка сервера не помогла, даже будучи сделанной за 0.5 часа? Поднимитесь выше уровня расчёта по одному инциденту, и Вы легко сделаете вывод: такая организация работ нормативу в 3 часа не соответствует. И несоответствие тем больше, чем больше времени тратится на каждом из участков. Если мы при нормативе в 3 часа 2.5 часа диагностировали, значит мы на этом участке недостаточно эффективны (недостаточно — для надёжного соответствия нормативу в 3 часа). Именно это и показывает значение метрики. Всё чётко.

2. Польза метрики. Если не связывать значение метрики с каждым участником обработки инцидента, то всем, кроме последнего участника, на просрочку будет наплевать: «Мы своё дело сделали, а они – просрочили». А у последнего участника всегда будет оправдание: «Если бы мне передали раньше, я бы всё успел». Это тупик. Старшие групп имеют самое непосредственное влияние на свои ресурсы, они же ближе всего к предметной части и могут предложить новые технические решения (по мониторингу, по диагностике), которые менеджеру процесса не видны. Польза заключается в том, чтобы заставить их думать как руководителей, как изменить организацию работ и технические решения так, чтобы надёжно соответствовать установленным нормативам. Вот тогда и совещание по процессу, о котором справедливо говорит Владимир, будет работой группы, а не метанием бисера силами инцидент-менеджера, который один отдувается за коллективную безответственность.

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

Ага, это я сам себя перехитрил... «Думаю два, три в уме...»

да ещё и у каждого известен свой нормативный срок

Я не про то, что он так уж прямо «нормирован» (это отдельная тема). Я имею в виду объективную трудоёмкость (например первым надо десяток логов перечитать, чтобы найти сбойный сервер, а вторым сервер этот перезагрузить). Получается, что одни работают на пределе своих возможностей, а метрика их всё равно хуже тех, кто «курит бамбук».

включается элемент стимулирования старших групп

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

Так что обсуждайте на здоровье где угодно — хоть здесь, хоть там.

Ну, во-первых, ошибка в расчёте. Первый получит 0.29, второй — 0.71.

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

В-третьих, включается элемент стимулирования старших групп. Они работают на конвейере. Ошибка каждого ставит под удар весь ИТ-департамент, потому что для потребителя услуг виноват всегда ИТ-департамент, а не Вася Пупкин. Я почему и вспомнил про Голдратта — стохастические отклонения и зависимость операций. Желание разобраться в ситуации, найти узкое место, исключить его должно волновать не только инцидент-менеджера, которого одарили соответствуюшей обязанностью, но и старших групп — линейных менеджеров. Тогда эффект будет гораздо сильнее, ведь линейные менеджеры — это «нервные окончания» системы управления. Инцидент-менеджер без них — как ясная голова у парализованного тела.

«По теме: не очень раскрыта возможность возврата в группу \ в работу инцидента пользователем»

Это как раз во второй метрике, о которой «P.S.P.S». Раскрою, если дело дойдёт. Что-то пока кажется это немногим интересно.

«Дима, а почему в старые записи нельзя написать комментарий?»

Это защита от ботов. Статьи старше 60 дней закрываются. Но мне страшно любопытно. Напиши здесь!

offtop: Дима, а почему в старые записи нельзя написать комментарий? я как раз хотел черкнуть о PrbM — сегодня первый раз прямо-таки впрямую воспользовался опытом realitsm )

Как её можно будет использовать, если она не показывает на проблему? Тут у руководителя получится методика: Наказать невиновных, нградить непричастных.

Вот ещё вариант: в инциденте работают два человека. Ограничение длительности по инциденту 3 часа. Задача одного более трудоёмкая и занимает 2,5 часа. Задача второго на 0,5 часа. Первый делает всё в срок, а второй в два раза длиннее положенного. В итоге первый получает 0,16, а второй 0,66. Как эти метрики сможет использовать руководитель? И какие выводы он из них сделает?

Может быть вот такой ход будет более эффективен:

Каждый последующий исполнитель может оценить предыдущего, напрмиер по 3-х бальной системе (3-претензий нет, 2-есть замечания, 1- абсолютно не удовлетворительно). Т.е. если вам передали инцидент за 5 минут до окончания срока, или ничего не сделали, или сделали так, что пришлось переделывать, то вы таким образом можете пожаловаться на смежника. Можно оценку снабдить комментарием ещё.

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

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

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

«Заставить же действовать по таким схемам большинство можно только путём угрозы, т.е. когда из метрики будет следовать наказание.»

Кнут и пряник. Только так.

P.S. Просто потрясающе. Насколько ИТ-шники любят поговорить о метриках, об их объективности, о том, как они сами будут считаться в супер-системе автоматизации, настолько же они опасаются применения этих метрик к себе. Процесс в целом измерять надо обязательно, но нас и наше участие в нём измерить невозможно! А если ещё и наказывать будут по результатам измерения, так вообще караул Детский сад.

Ага, я и сам вижу. Да и не буду. У Вас хорошая позиция, я сам такую много раз использовал, только без OLA. И то подозреваю, что то, что Вы называете OLA, это совсем не OLA Чего в этой позиции не хватает — ясности в отношении способов стимулирования старших групп поддержки. Если менеджер процесса могучий, он их построит и дело постепенно пойдёт. Но я обычно (почти во всех проектах) использую независимые дополнительные механизмы стимулирования старших групп, и эта метрика — один из способов. А то, что Вы в неё не поверили — не страшно, каждый выбирает для себя

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

И кстати, я не чего не полагаю, а лишь делюсь опытом нескольких компаний, которые принименяют этот подход в том или ином ввиде. О чем и написал в первом посте.

коллективную ответственность, присущую процессу

Очень спорное утверждение. Коллективная работа группы людей и коллективная ответственность это разные вещи.

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

Извините не убедили.

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

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

Павел, приведите, пжл, пример целостной системы таких метрик всего по одному (самому простому!) процессу — процессу управления инцидентами.

Что разбор полётов, что оперативный контроль, с точки зрения, управления это одно и то же:

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

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