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

Сервисно-ресурсная модель помогает при мониторинге и управлении событиями, показывая, как услуга устроена и из каких компонентов состоит. Понимая структуру услуги и взаимосвязи между компонентами, можно более точно определить, какие параметры и компоненты должны подлежать мониторингу, что позволяет сократить объем собираемых данных, избежать информационной перегрузки и сосредоточиться на самом важном для обеспечения качества ИТ-услуг.

Для встраивания понимания бизнес-ценности необходимо создать процессы и метрики, которые напрямую связывают ИТ-услуги с бизнес-результатами. Следует проводить обучение сотрудников на примерах конкретных бизнес-сценариев, как их работа влияет на конечных пользователей и бизнес-процессы. Регулярные совместные встречи с бизнес-заказчиками, разработка совместных KPI, которые измеряют не только технические показатели, но и бизнес-результаты, а также внедрение механизма сбора и анализа обратной связи от конечных пользователей помогут закрепить понимание бизнес-ценности в организации.

Customer Lead Time - это время ожидания, которое считается от момента принятия решения о реализации задачи (зеленый флажок) до момента поставки результата заказчику. Этот период зависит от количества задач, которые находятся в системе перед рассматриваемой задачей, а также от скорости обработки этих задач. Особенно комично выглядит попытка определить срок поставки задачи именно в момент принятия решения, так как зачастую очередь задач меняется, и точную дату завершения предсказать невозможно.

Process Owner в контексте управления ИТ-процессами — это роль, ответственная за общее управление и развитие процесса. Process Owner определяет стратегическое направление процесса, утверждает его документацию, контролирует соблюдение регламентов и обеспечивает соответствие бизнес-целям. Эта роль не предполагает непосредственного руководства исполнителями, но включает согласование изменений, мониторинг метрик и внедрение улучшений. Process Owner должен быть независим от операционных процессов, чтобы избежать конфликта интересов и обеспечить объективность при принятии решений. Назначение Process Owner является одной из рекомендаций стандартов управления ИТ-сервисами, таких как ITIL.

Для объединения двух tension-метрик в один общий KPI необходимо использовать геометрическое среднее (а не арифметическое). Если K1 — метрика своевременности, а K2 — метрика результативности, то итоговый K = √(K1 × K2). Это обеспечивает чувствительность к игнорированию одной из метрик (при значении одной из них в 0% общий KPI также будет равен 0%), в то время как при равных значениях обеих метрик итоговый KPI соответствует уровню их значений. Геометрическое среднее лучше отражает баланс между метриками, чем арифметическое, поскольку низкое значение одной метрики сильно влияет на общий результат.

Автоматизация играет ключевую роль в определении завершения работы по концепции DevOps, так как она обеспечивает: 1) надежность и воспроизводимость процессов; 2) минимизацию человеческого фактора; 3) быстрое выявление и исправление ошибок; 4) непрерывную доставку изменений; 5) возможность частых и безопасных обновлений продукта. В финальной ступени Definition of Done автоматизация сборки, тестирования и развертывания является обязательным условием для признания работы завершенной, что позволяет командам сосредоточиться на улучшении продукта, а не на рутинных операциях.

Обходное решение — это решение, которое уменьшает или устраняет влияние инцидента или проблемы, для которого полное разрешение еще не доступно. Его особенность заключается в том, что оно быстро восстанавливает услугу до приемлемого качества, что позволяет пользователю временно продолжать работу. Однако обходные решения не решают проблему полностью, а вместо этого могут увеличить технический долг, создавая риск возникновения новых инцидентов в будущем. Практика управления проблемами помогает сократить этот технический долг, который накапливается в результате применения обходных решений.

Для измерения удовлетворенности сотрудников сервис деска можно применять несколько методов: регулярные анонимные опросы с частотой не реже двух раз в год, использование методики NPS с вопросом о вероятности рекомендации компании как места работы, неформальные коммуникации и случайные встречи, анализ больничных листов и отчетов об отсутствии на работе, проведение опросов через третьих лиц для обеспечения конфиденциальности, а также изучение мнений сотрудников на совещаниях и в рабочих группах. Важно учитывать атрибуты, такие как лидерство в команде, корпоративная культура, моральный дух, организационный климат и особенности трудовой деятельности.

Известная ошибка в ITIL — это проблема, которая уже была проанализирована и для которой найдено временное (обходное) решение, но при этом не устранена окончательно. Например, если инцидент с невозможностью печати документов вызван конфликтом драйвера, и в качестве временного решения используется перезагрузка компьютера или диспетчера печати, тогда эта ситуация классифицируется как известная ошибка. Системное решение, например, обновление драйвера принтера, может потребовать дополнительного времени.