В редакцию портала поступил вопрос:
Добрый день.
Как следует поступать со «старыми» инцидентами?
Пример 1.
Инцидент не закрывается уже длительное время, например, месяц. Причина — отсутствие ресурсов/времени у специалистов. Следует ли открывать проблему и закрывать после этого инцидент?
Пример 2.
Внешний инцидент не закрывается уже длительное время, например, месяц. Причина — вендор не предоставляет исправление. Следует ли открывать проблему и закрывать после этого инцидент?
Коллеги, комментируйте свои оценки, иначе это теряет их ценность.
Я бы рекомендовал регулярно обсуждать с бизнесом “висяки”. Нехватка времени = всегда есть более приоритетные задачи, и бизнес должен это понимать. Возможно “инцидент уже не инцидент”.
То же и с представителем вендора, менеджер по взаимодействию с вами должен понимать, когда есть “висяки” с их стороны, и давать прогноз, когда это будет решено.
Инцидент? Т.е. прерывание предоставления Услуги длится месяц? Значит услуга никому особо и не нужна и ее стоит вывести из эксплуатации, либо это явно не “инцидент”, а запрос на обслуживание.
Многие компании (и их ИТ-департаменты) не мыслят категорией услуг и любая проблема необходимость попадает в раздел инцилента. Да и не обязательно, чтобы инцидент вызывал прерывание. Пример, “У меня периодически вылезает алерт в браузере”. Да неприятно, но не критично. Пользователь работать может, руки до системного анализа данной проблемы не доходят.
Согласен, дело в терминологии. Просто люди называют “инцидентом” что-то другое, не то, что подразумевается в “лучших практиках”. Алерт в браузере не мешающий работе – явно проблема, но не инцидент.
Зависит от того, какие условия прописаны в КЕ сервиса.
Инцидентом так же считается деградация сервиса те без прерывания, простой пример – задержка доставки почты на 5-10 мин, причина для заведения тикета (а еще и проблемы, если это массовая история) – да, несомненно, при этом сервис почты работает.
Инциденты висеть могут по разным причинам, навскидку:
1. применено обходное решение, но для постоянного нужны согласования или еще какие заморочки
2. инцидент решен, но последствия не устранены. тоже нужно время, иногда длительное
3. инцидент решен, но проверить, сработало ли решение, сможем позже, потому что ошибка плавающая
4. инцидент с заменой з/ч через сервисный центр, там сроки вообще бывают сумасшедшие. понятно, что из ЗИП быстро поменяем и все восстановим, но до конца всю заявку провести займет уйму времени
Так что не стала бы категорично критиковать описанную ситуацию, нужно больше информации, чтобы обсуждать и находить решение )
Все беды от терминологии. Инцидент – прерывание услуги. Как только прерывание устранено (любым способом – пусть даже обходным решением) – инцидент устранен и должен быть закрыт. Все остальное – применение постоянного решения, проверка “сработало ли решение” и т.д. и т.п. – это уже часть процесса управления проблемами.
Пример. 1. Отсутствие ресурсов – инцидент не закрывать до получения, как я понимаю, запчасти, потому что может забыться. Отсутствие времени – ждать пока появится, если конечно инцидент не имеет большей важности чем остальные имеющиеся, в противном случае поднимать приоритет. Если у вас хроническая задержка поступления запчастей и\или отсутствие времени у специалистов, то надо делать проблему не в системе управления заявками, а решать организационно-административные вопросы. Идти к высшему начальству, и оперируя фактами, показать что повышается неудовлетворенность сотрудников и бизнеса в целом.
Пример. 2. Опять же, на мой взгляд, оставить инцидент и почаще пинать внешнюю сторону, добиваясь решения и актуализируя состояние запроса. Так же можно повышать уровень пинания, как на своей стороне, так и на другой, в зависимости от критичности инцидента.
Прежде всего необходимо определиться “по понятиям” :))). Инцидент – это:
– ситуация, когда состояние ИТ услуги не позволяет её потребителям выполнять свои бизнес функции
– проявление проблемы. Т.е. проблемы проявляются в виде инцидентов.
В приведенных примерах явная ошибка в классификации обращений. Если есть возможность целый месяц продолжать работать без решения обращения, то это не инцидент, а проблема или запрос на улучшение (работать могу, но не удобно). Еще может быть ситуация – реально инцидент, но приделали временный “костыль “, пользователь может продолжать работать, но причина не решена. В такой ситуации инцидент закрывается с пометкой про workaround. При этом проблема может сразу регистрироваться либо позднее, в процессе Problem Management. Ну или еще упомянутая ситуация – сервис никому реально не нужен и может висеть годами. Но это уже в область CSI.
Очевидный и самый правильный ответ.
Сразу возникает вопрос, что делают менеджеры для решения этой задачи. Почему кастомер не повышает приоритет, так называемый эскалейшен. По хорошему, должен работать процесс эскплирования инцидентов, который мониторится slm. Если по инциденту нет обновлений в течение 30 дней, звонок кастомеру с вопросом можно ли закрыть. Если закрыть нельзя, перебрасывать заявку в группу менеджеров, пусть решают.
– Для руководителей отделов добавить дополнительный показатель в виде старых не закрытых заявок (можно процентное соотношение от всех закрытых заявок) и если этот процент превышает определённый порог, то руководитель подразделения ответственный за сервис страдает.
Это мотивирует руководителей отделов отслеживать старые заявки, мониторить и поддерживать их в актуальном состоянии.
– Для сервис деска – после прошествии месяца, раз в неделю-две пушить ответственных за заявку/сервис и выяснять, в чём задержка и добавлять в примечание полученную информацию. Возможно заявка по прошествии времени, стала не актуальной.
– В общем отчете о состоянии ИТ внести отдельно показатели старых не закрытых заявок и сравнивать это количество с предыдущим отчётным периодом, что бы видеть зависимость роста или уменьшения числа старых не закрытых заявок.
И по каждой заявки желательно отдельно расписывать в из-за чего задержка, возможно податель заявки в отпуске/на больничном, или возможно оборудование находится в сервис центре и ожидает поставку деталей, или до банального ожидается принятия бюджета для покупки…
Отвечая на вопросы автора:
1. Значит, это не инцидент. Инцидент при устранении нештатного функционирования сервиса даже с обходным решением должен быть закрыт.
Таким образом вы можете подсчитать кол-во сбоев, вне зависиомсти от какой-либо системы мониторинга, это своего рода другой уровень оценки работы сервиса.
Далее создаёте и “связываете” (в разных системах устроено по-своему) “запрос на обслуживание”, определив его тип (например, ошибка в ПО), и там уже “как пойдёт”: ошибка поставщика ПО/оборудования и т.д., требуется ли изменение и т.д.
Если инциденты повторяются, у вас может быть применено решение (то самое, что было обходным и записано в вашей базе знаний), и если вновь и вновь – тогда создаёте проблему (критерий “переноса” инцидента в проблему определяете внутренним регламентом).
Вновь поступающие инциденты связываете с проблемой, для которой может быть повышен приоритет, срок устранения, сами инциденты фиксируете, закрываете, предварительно связав их с другими запросами.
При решении проблемы (возможно, проведя ИЗМЕНЕНИЕ) закрываете её и все связанные с ней инциденты.
2. Увы, не хватает данных о вашей ситуации, но тут также, как и писал выше. Нет решения месяц, значит, “как-то да живёте с этим”? Значит, для вас это и не проблема, а единичный сбой, провлёкший к временной приостановке сервиса.
Вендор может и годами не предоставлять исправления, т.к. у него собственные приоритеты, проекты, вплоть до того, что он вообще он может перестать существовать.
Целесообразность создания ещё одной записи об одном и том же не вижу, итак ясно, что нужно-что делать.
Из всего того, что указал выше, можно “нагородить” систему оценки работы подразделения, руководителя этого подразделения, передавая показатели выделенному аудитору или вышестоящему по иерархии в компании (ИТ-директор, например).
Пример 2. Вендор не предоставляет решения. Интересный случай.
вероятно уже есть задача, запрос, тикет на вендора, в рамках которого решается проблема.
Не предоставляет решение – вероятно речь про затягивание сроков, по сути вендор признал ошибку.
Нужно ли отдельно регистрировать проблему в этом случае? Ведь все решение сводится к решению вендора. Новые инциденты можно привязывать к запросу на вендора, в нем и информация по срокам, и временному решению (если оно применимо), по нему же возможно собрать все обращения по проблеме.
как быть? что говорят лучшие практики по этому вопросу? Заранее благодарен за помощь и содействие
Мнение,
Пример 1: таких ситуаций не должно быть в принципе.
Влияет на сервис? материально демотивировать руководство, пока не найдутся ресурсы.
Если KPI это не предусмотрено, поставить вопрос о профпригодности.
Не влияет? инцидент ли это? ждите высвобождения ресурсов.
Инцидент не закрывать.
Пример 2: проблему открывать, инцидент не закрывать.