Измерение результатов критично для ITSM, потому что оно обеспечивает фокус на реальной ценности, а не на процессах. ITSM не должен быть просто набором процессов - он должен быть драйвером бизнес-успеха. Когда ИТ-службы измеряют результаты, а не только выходы, они могут доказать свою ценность для бизнеса, избежать 'разрыва' между ИТ и бизнесом, оптимизировать ресурсы для достижения реальных целей и построить услуги, которые создают конкурентные преимущества. Без измерения результатов ITSM рискует стать бюрократической структурой, генерирующей отчёты, но не приносящей реальной пользы.

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

Для организации регулярной диагностики множества продуктовых команд необходима хорошо проработанная методическая база, включающая: стандартизированную методику диагностики, четкие критерии оценки, систему приоритизации команд, процесс регулирования количества одновременных диагностик (WIP limit), шаблоны отчетов и рекомендаций, инструменты визуализации процесса, обученные внутренние эксперты. Кроме того, необходима система накопления и распространения знаний, чтобы каждый последующий цикл диагностики был более эффективен предыдущего. Важно также наличие гибкости в методике, позволяющей адаптировать диагностику под специфику разных команд и этапов их развития.

Рефакторинг кода может не привести к ожидаемому результату из-за недостаточного понимания задачи исполнителем и эффекта Даннинга-Крюгера. В тексте приводится пример, когда команда обсудила план рефакторинга, но через месяц выяснилось, что исполнитель просто переносил проблему в другой слой системы, вместо того чтобы решать её. Это произошло потому, что человек не осознавал своей недостаточной компетентности в вопросе рефакторинга, считая, что его действия приведут к улучшению кода. Автор отмечает, что такой случай не уникален: «каждый человек понимает «в меру своей испорченности», переоценивает свои умения, не понимая истинной глубины своей некомпетентности». Поэтому важно не только обсудить план, но и обеспечить постоянный контроль и коммуникацию в процессе выполнения задачи.

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

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

При отсутствии полноценного процесса управления конфигурациями возникают проблемы, связанные с отслеживанием зависимостей между инфраструктурой и услугами. Альтернативные методы требуют постоянной ручной актуализации информации, что занимает много времени и повышает вероятность ошибок. Кроме того, такие решения не позволяют в полной мере решать как задачу определения влияния инфраструктурных изменений на услуги, так и задачу определения затрагиваемых элементов при изменениях требований. В итоге, сложность и неэффективность временных решений делают необходимым внедрение CMDB и процесса управления конфигурациями.

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

Оптимальная структура классификатора изменений должна быть матрично-иерархической. Это позволяет эффективно управлять разнообразием изменений без избыточного создания множества моделей. Структура классификатора включает следующие элементы: - Группировку по категориям: изменения могут быть сгруппированы по категориям в зависимости от типа (стандартные, нестандартные), уровня риска, специфики объекта изменения (ИТ-инфраструктура, сетевые компоненты, информационные системы). - Типовые порядки обработки: для каждой группы определены типовые порядки прохождения этапов, включая определение необходимых согласований, этапов выполнения, условий включения в релиз. - Параметризация по объектам: к каждой группе систем или направлений привязаны специфические параметры, такие как назначение координатора, список уполномоченных на согласование, обязательные результаты этапов. - Иерархия детализации: стандартные изменения могут иметь высокую степень детализации, включающую чёткие указания по этапам и исполнителям, тогда как для нестандартных изменений детализация фокусируется на ключевых этапах анализа и оценки. Пример такой структуры: - Для ИТ-инфраструктуры: общий типовой порядок обработки с опциональными этапами для работ, выполняемых в рабочей среде. - Для информационных систем: общий мастер-порядок с обязательным этапом приёмочного тестирования. - Дополнительная параметризация под конкретные системы или типы изменения (например, для критически важных систем – дополнительные этапы оценки влияния). Такой подход позволяет сократить количество полностью уникальных моделей, упростив процесс поддержки и адаптации классификатора к изменениям в ИТ-ландшафте.

В работе сервис-деска следует отслеживать несколько ключевых параметров соотношения инцидентов и запросов: общий объем обращений, разделенных на инциденты и запросы; соотношение количества инцидентов к запросам на обслуживание в процентах; динамику изменения количества инцидентов во времени (тренд); показатель первичного решения (FLR) для каждой категории; среднее время решения инцидентов и запросов; частоту определенных типов инцидентов (анализ для работы с корневыми причинами). Регулярный мониторинг этих параметров позволяет получить объективную картину работы сервис-деска, выявить проблемные зоны и обоснованно планировать улучшения процессов.