Как известно передовой ITSM-общественности, в общем случае нормативы обработки проблем установить нельзя. Это, в частности, связано с тем, что в большинстве случаев для решения проблемы необходимо реализовать изменение, причем вряд ли стандартное, а срок реализации изменений есть результат индивидуального планирования. Более того, в случае управления проблемами дело, как правило, осложняется тем, что у проблемы может быть несколько решений, отличных по степени надежности, стоимости, срокам реализации – оптимальный вариант придется выбирать. Время, в течение которого выполняется тестирование результативности решения, также не поддается нормировке. Например, если проблема проявляется ежедневно, то тестирование можно выполнить за 2-3 дня. А если проблема связана с недопустимым торможением при формировании квартальной отчетности, нужно ждать начала следующего квартала (и если решение применено в начале квартала, это 3 месяца, а если в конце – может быть 1 неделя). Еще сложнее с проблемами, которые проявляются время от времени и не имеют явной регулярности.
Эти рассуждения, впрочем, все еще не известны многим производителям ПО, которые в своих продуктах умудряются вводить нормативы на решение проблем, в том числе через SLA. Но … «не будемте об этом» 🙂
Опыт руководящей работы показывает, что наличие «дедлайна» – один из самых действенных стимуляторов для исполнителей. Нет срока – нет прогресса в работе. Причем срок этот должен быть установлен исполнителю, а не определяться им самим с возможностью неограниченных переносов. Как же быть? Открываем ITIL, читаем, удивляемся – внимания этому вопросу не уделено. Опять придется думать самим.
И вот, что мы (в Cleverics) думаем. Еще со времен ITIL v2 общий цикл обработки проблемы делился на две части – problem control (PC) и error control (EC). От PC к EC мы переходим по завершению диагностики – определению корневой причины и, как следствие, определению вариантов решения. Мы считаем разумным и вполне реалистичным нормировать фазу диагностики проблемы (PC) на основании её уровня влияния на бизнес-процессы. Сроки здесь, конечно не «инцидентские», но фиксированные. Например, если уровень влияния «Высокий», срок диагностики может составлять 1 неделю, средний – 2 недели и так далее. На EC срок не нормируется, но в каждой реперной точке устанавливается менеджером по отношению к исполнителю. Например, отдельно определяется срок реализации решения (в идеале он приходит из управления изменениями), срок проверки результативности решения, срок контроля известной ошибки (когда реалистичных решений по итогам диагностики не обнаружено). Принципиально важно, чтобы срок аналитик проблемы устанавливал не сам себе, а получал сверху – в зависимости от масштаба процесса и организации от менеджера процесса или от координатора проблем.
Вроде бы все просто и вполне логично. Интересно, почему в ITIL не так? Почему во многих программных продуктах это не так? И как это в вашей практике? Неужели применяемое нами решение настолько спорно?
Дмитрий, добрый день.
Помню еще по прошлой работе: стоклнулись с проблемой медленной работы именно 1С и именно на терминальном сервере. Для диагностики требовалось привлечение производителя "железа", поддержки 1С, провайдера канала связи и т.д. При этом все эти действия проводились для вывления причины проблемы. И заняло это больше любого планируемого срока. Мы эмулировали ситуацию в офисе, в ДЦ, на рабочих местах 1Сников; меняли прошивки на SAN'е, включали/выключали те или иные настройки.
В общем, мне кажется, что нормировать для всех проблем сроки диагностики – тоже малореально.