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

ITIL® пишет о том, что эти два процесса могут быть одним (как, например, в ISO 20000:2011), но лучше их разделять, потому что:

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

(С) ITIL Service Operation, TSO, 2011

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

Решение должно отталкиваться от объёма и структуры этого спроса. Зачем люди приезжают в автосервис? Мне кажется, в трёх случаях:

1. Если с автомобилем что-то «не так» (последствия аварии, нештатные шумы и т.п.).
2. Если автомобиль надо улучшить, чтобы повысить удовлетворенность им (тюнинг).
3. Если пора делать ТО (по рекомендациям завода-изготовителя).

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

Тогда получается, что 1 – это инциденты, а 2 и 3, конечно же, запросы на обслуживание. Спрос на ваши услуги будет складываться, таким образом, из нормированных (тюнинг и ТО)  и ненормированных (вот они, инциденты) работ.

Ура! Приступаем к планированию ресурсов. 

• Ведь вы знаете точно, сколько автомобилей эксплуатируется в вашем городе и как часто их надо обслуживать? Более того, работы по ТО уже нормированы по времени и снабжены чёткими инструкциями того же завода производителя. Значит, можно посчитать требуемое количество "рук" для этих работ и даже количество механиков в смене (например, многие клиенты считают удобным сдать машину на ТО утром, перед работой).
• Кроме этого, вы знаете (и об этом пишет ITIL) статистику инцидентов, и на ее основе можете спрогнозировать объем работ по пункту «1». А учитывая пиковые значения, взять в каждую смену «резервного» механика, на случай большого количества аварий (гололёд, 1 сентября и т.п.).
• «Туманной» областью здесь является «тюнинг», ведь на эти услуги нет устойчивого спроса, напротив – сами услуги меняются со временем (сейчас вот мода на шторки на дверях иномарок E-класса и на ДХО). Механизмы предсказания здесь уже не в статистике прошлых периодов, а в сфере управления спросом.

Резюмирую: отделять обработку инцидентов от запросов на обслуживание нужно, прежде всего, если вы планируете ИТ-персонал на основе статистики. А в противном случае, какая разница? Всё равно в обоих процессах работают одни и те же механики.

Ну как?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую