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

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

Релевантность метрики означает её соответствие и полезность для достижения поставленных целей. Это проверка, действительно ли нужно измерять данный показатель, чтобы принимать управленческие решения. Если данные не используются для конкретных решений или действий, метрика теряет смысл и не соответствует критерию R из SMART. Например, отчётность без последующих действий — нерелевантна.

Для определения компонентов, влияющих на снижение производительности, следует сравнить текущие метрики с ранее зафиксированными baseline-данными. Если известно, как система вела себя раньше при аналогичной нагрузке, можно выявить те элементы, чьи характеристики изменились. Например, если ранее при 1000 операциях загрузка диска составляла 40%, а сейчас — 90%, это указывает на проблему в дисковой подсистеме. Важно учитывать влияние всех уровней: прикладного ПО, баз данных, серверного оборудования и сети.

Чтобы система измерения процессов ИТ действительно помогала в управлении, следует придерживаться следующего подхода: 1. Начните с четкого определения назначения процесса (зачем он существует, какие цели решает). 2. Определите ключевые практики, которые необходимо выполнять для достижения этого назначения. 3. На основании ключевых практик сформулируйте метрики, которые будут отслеживать выполнение этих практик. 4. Установите целевые и граничные значения для каждой метрики, соответствующие вашим целям. 5. Сформируйте KPI, объединяющие эти метрики и показывающие степень достижения целей. 6. Убедитесь, что KPI взаимосвязаны между собой и создают целостную картину работы ИТ, а не представляют собой набор несвязанных показателей. 7. Включите в систему измерений не только технические данные, но и субъективные мнения пользователей (удовлетворенность), так как для ИТ важно качество предоставляемых услуг конечным пользователям. 8. Постоянно пересматривайте и корректируйте систему измерений, проверяя, действительно ли собранные данные помогают в принятии управленческих решений и достижении бизнес-целей.

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

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

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

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

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