Уже давно бродит эта тема. А последней каплей стало то, что за последние 2-3 недели я обсуждал её 3 (!) раза с разными людьми. И так, вопрос: «Насколько осмысленно (или в каких случаях) выделять обработку сервисных запросов и управление инцидентами в отдельные процессы»?
За:
- Соответствие ITIL v3. Строго говоря, тут надо учесть, что понятие «процесс» в ITIL v3 используется довольно неоднозначно. Но средства автоматизации ITSM-процессов «меряются» количеством процессов, а значит для вендоров – это плюс.
- И раз уж заговорили про вендоров ITSM-продуктов, надо упомянуть, что такое деление (на инциденты и сервисные запросы) стимулируется рядом программных продуктов, в которых сервисные запросы и инциденты – это не просто разные категории одного объекта, а просто-таки разные объекты (с весьма различными возможностями по обработке).
Видимо, отсюда песня и пошла в народ. Но рассмотрим также и …
Против:
- Рациональность организации управления. О чём, кстати, говорится в ITIL v2: «A request for new or additional service (i.e. software or hardware) is often not regarded as an Incident but as a Request for change (RFC). However, practice shows that handling of both failures in the infrastructure and of service requests are similar, and both are therefore included in the definition and scope of the process of Incident Management.». И в самом деле, зачем выделять отдельный процесс, который будет заниматься практически тем же, чем уже занимается управление инцидентами?
- Устранение вероятных конфликтов. На практике (в проектах) граница между инцидентом и сервисным запросом вызывает массу вопросов. Обычно они выливаются в дискуссии типа «А замена картриджа принтера? А сброс забытого пароля?» и так далее. Логично предположить, что путаются не только «идеологи», но и специалисты при исполнении процесса. А значит должна быть возможность переклассификации. Но если сервисный запрос и инцидент теперь принадлежат к разным процессам управления (и не дай Бог, эти процессы управляются разными менеджерами), вопрос «что это – инцидент или сервисный запрос» превращается в вопрос «кто за это отвечает». И это не на пользу.
- Рациональность автоматизации. В моей практике разница в обработке инцидента, поданного пользователем, и запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя (тут и разная классификация, и разные процедуры выявления / регистрации, и разные процедуры закрытия). То есть деление, выполненное в HP OpenView Service Desk, мне кажется гораздо более разумным, чем деление, например, в HP SM или в BMC Remedy ITSM Suite. Это конечно тема смежная, поскольку декомпозиция объектов в модели данных ITSM-продукта может не иметь никакого отношения к декомпозиции процессов управления. … но всё же 🙂
Выводы делаем сами. Ну и спорим, естественно.
P.S. Хотя меня конечно так и подмывает закончить известным «Никто не сказал ни слова, выводы были ясны». (с) БГ.
Прошлой осенью на эту тему отлично высказался Неугомонный Наш Ян ван Бон в своей колонке c оригинальным названием What the %$#$& is a Service Request?(http://www.itsmportal.com/columns/what-service-request). Я тогда тоже постарался сформулировать свое отношение к вопросу, тем более что три раза за три недели – это как раз средняя частота, с которой ITSM-тренеру приходится обсуждать эту тему.
Я уверен, что главный вопрос – не в количестве потоков работ (“процессов”). Основная проблема объединения запросов и инцидентов в v2 была в том, что это делало процесс внутренне противоречивым: деятельность не соответствовала цели (обработка запросов не ведет к скорейшему восстановлению нормальной работы, ибо эта работа не нарушена). “Коня налево повернул, а сам направо поскакал”.
Отсюда главный вывод: либо это один процесс, цель которого включает в себя и устранение инцидентов, и своевременную качественную обработку запросов на обслуживание, либо процессов несколько, но у каждого цель, виды деятельности, метрики и проч. – целостны и друг другу не противоречат.
Приведенные Димой “плюсы” кажутся мне неубедительными. Тем не менее, я считаю, что разделение процессов может быть оправдано и полезно. У кого-нибудь есть более практические аргументы “за”?