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

Определяем сроки обработки проблем

Как известно передовой ITSM-общественности, в общем случае нормативы обработки проблем установить нельзя. Это, в частности, связано с тем, что в большинстве случаев для решения проблемы необходимо реализовать изменение, причем вряд ли стандартное, а срок реализации изменений есть результат индивидуального планирования. Более того, в случае управления проблемами дело, как правило, осложняется тем, что у проблемы может быть несколько решений, отличных по степени надежности, стоимости, срокам реализации – оптимальный вариант придется выбирать. Время, в течение которого выполняется тестирование результативности решения, также не поддается нормировке. Например, если проблема проявляется ежедневно, то тестирование можно выполнить за 2-3 дня. А если проблема связана с недопустимым торможением при формировании квартальной отчетности, нужно ждать начала следующего квартала (и если решение применено в начале квартала, это 3 месяца, а если в конце – может быть 1 неделя). Еще сложнее с проблемами, которые проявляются время от времени и не имеют явной регулярности.

Эти рассуждения, впрочем, все еще не известны многим производителям ПО, которые в своих продуктах умудряются вводить нормативы на решение проблем, в том числе через SLA. Но … «не будемте об этом» 🙂

Опыт руководящей работы показывает, что наличие «дедлайна» – один из самых действенных стимуляторов для исполнителей. Нет срока – нет прогресса в работе. Причем срок этот должен быть установлен исполнителю, а не определяться им самим с возможностью неограниченных переносов. Как же быть? Открываем ITIL, читаем, удивляемся – внимания этому вопросу не уделено. Опять придется думать самим.

И вот, что мы (в Cleverics) думаем. Еще со времен ITIL v2 общий цикл обработки проблемы делился на две части – problem control (PC) и error control (EC). От PC к EC мы переходим по завершению диагностики – определению корневой причины и, как следствие, определению вариантов решения. Мы считаем разумным и вполне реалистичным нормировать фазу диагностики проблемы (PC) на основании её уровня влияния на бизнес-процессы. Сроки здесь, конечно не «инцидентские», но фиксированные. Например, если уровень влияния «Высокий», срок диагностики может составлять 1 неделю, средний – 2 недели и так далее. На EC срок не нормируется, но в каждой реперной точке устанавливается менеджером по отношению к исполнителю. Например, отдельно определяется срок реализации решения (в идеале он приходит из управления изменениями), срок проверки результативности решения, срок контроля известной ошибки (когда реалистичных решений по итогам диагностики не обнаружено). Принципиально важно, чтобы срок аналитик проблемы устанавливал не сам себе, а получал сверху – в зависимости от масштаба процесса и организации от менеджера процесса или от координатора проблем.

Вроде бы все просто и вполне логично. Интересно, почему в ITIL не так? Почему во многих программных продуктах это не так? И как это в вашей практике? Неужели применяемое нами решение настолько спорно?

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Кротов Алексей

    Дмитрий, добрый день.

    Помню еще по прошлой работе: стоклнулись с проблемой медленной работы именно 1С и именно на терминальном сервере. Для диагностики требовалось привлечение производителя "железа", поддержки 1С, провайдера канала связи и т.д. При этом все эти действия проводились для вывления причины проблемы. И заняло это больше любого планируемого срока. Мы эмулировали ситуацию в офисе, в ДЦ, на рабочих местах 1Сников; меняли прошивки на SAN'е, включали/выключали те или иные настройки.

    В общем, мне кажется, что нормировать для всех проблем сроки диагностики – тоже малореально.

    • Алексей, такие засады, конечно, бывают. И у меня были не раз. Но ведь аналогичные истории можно рассказать и про инциденты. Однако если мы нормируем % проблем, диагностированных в срок, такие флуктуации не перечеркнут всех усилий по своевременной диагностике. Зато само наличие срока будет дополнительным стимулом для команды.

      • Кротов Алексей

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

  • Pavel Solopov

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

  • Vyacheslav Potov

    Ставим сроки не на конечное решение, а на "обновление статуса". 

    Фактически смещаем фокус с "стараемся решить проблему в определённый долгий срок" на "стараемся чтобы в течении определённого короткого срока по проблеме проводились действия приближающие нас к решению", и контролируем эти короткие сроки.

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

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

      • Vyacheslav Potov

        И да и нет. 

        Я бы выделил 3 этапа. 

        1. Пока есть импакт и мы боремся за восстановление сервиса. Обычно на этом этапе записи о проблеме ещё нет, и мы работаем с инцидентом. и в этом случае мы однозначно должны быть жестки со сроками. Бывает, если мы уж говорим о качестве разрешения, есть случаи когда появляется соблазн открывать проблему, закрыть инцидент, и сказать что "а теперь мы долго искать root cause", при этом не восстановив сервис. Особенно если impact невелик. Но это отдельная тема )

        2. От этапа восстановления сервиса до нахождения root cause начинается то что можно обозвать Pure Problem Control 🙂 в том плане что особо никакие другие процессы на данном этапе не примешиваются. Согласен, что без должного контроля, при предложенном подходе он может скатиться в симуляцию бурной деятельности. Что правда так же справедливо и для Error control.

        Контролировать на этом этапе возможно и нужно проводя sense check активностей. У нас обычно этим занимаются супервайзеры на обоих этапах работы по проблеме. И это в том числе покрывает возможность, что сам поиск root cause может быть настольо кресурсоёмким, что это перекроет сам impact от проблемы. В таком случае рационально (хоть и не по процессу 🙂 ) Это дело бросать, и жить с workaround до лучщих времён.

        3. Error control. ну, тут как и по классике, и как вы сказали – делаем, следим что делаем, так же контролируем как мини-проект. Но мы при этом всё равно не забываем про sense check, и оценку соотносимости effort'a

         

        Много букв, но оч хотелось )

  • Alexander Popov

    Идея здравая. Дедлайн действительно сильный мотиватор.

     

  • Nargiza Suleymanova

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

    • Наргиза, скажите, пжл, потратив "уйму сил и времени" на то, чтобы заставить problem management работать, получили ли Вы ощущение сопоставимой отдачи? И если да, в чем она проявлялась – в сокращении потока инцидентов, в радости от решения застаревших болячек, с которыми уже никто не боролся?

      • Nargiza Suleymanova

        Дмитрий, ответ однозначно "да" 🙂 Выгоды от существенного сокращения потока инцидентов – снижение трудозатрат, улучшение имиджа компании (у них редко что-то ломается, а если ломается, то быстро чинится). А уж про радость от решения застаревших болячек…это безусловно здорово, разгребла проблемы, которые висели по году и более без временного решения.

        Насчет уймы сил и времени: 1. еженедельный обязательный разбор полетов с участием всех заинтересованных лиц (ВКС были мягко говоря бурные), 2. жесткий ежедневный контроль по заявкам с двух сторон, соответственно необходимость пинать ответственных лиц, 3. обязательная аналитика по текущим инцидентам, отслеживание тенденций, 4. приходилось тщательно выверять отчеты, чтобы было на основании чего выставлять штрафные санкции.

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

        • Жму руку. Делать всегда сложнее, чем рассуждать.

        • Dimitriy

          Проходили данный момент с " еженедельный обязательный разбор полетов с участием всех заинтересованных лиц"

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

  • Dimitriy

    Доброго времени суток.

    Вопрос о мотивации (пряниках) и "санкциях" (кнутах) за непробитые и пробитые сроки по стадии жижни проблем.

    Как и чем "пряниковать" молодцов и "карать" нерадивцев?

    У нас,  например, (на текущей работе) есть "инструмент" "оценка работы" сотрудника, которая действительно работает.

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

    Какие механизмы на практике используете Вы?


Добавить комментарий для DimitriyОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM