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

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

Участники игры Grab@Pizza выносят несколько ключевых уроков: понимание важности эффективного взаимодействия между бизнесом и ИТ; осознание того, что ИТ-инициативы требуют серьёзного обоснования бизнес-ценностью; необходимость активного позиционирования технической поддержки в процессах коммуникации; использование финансов как общей системы координат для бизнеса и ИТ; понимание того, что успех компании зависит от правильной выстроенности связки Business-SLM-Change. Также участники получают представление о процессах ITSM и учатся на практике применять эти знания в реальных условиях.

Service Desk может быть не нужен организации в двух основных случаях: когда недостаточно ресурсов для его организации, так как потребность в них легко оценивается с использованием специальных формул (например, формулы Эрланга), или когда существуют отдельные узкоспециализированные группы пользователей, поддерживающих свои собственные ИТ-решения. В таких условиях каждая специализированная группа может выступать в роли SPOC (единой точки контакта) для своих пользователей, что делает централизованную точку контакта избыточной. Это особенно характерно для крупных организаций с разнообразными ИТ-услугами.

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

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

Ресурсный характер традиционных ИТ-услуг приводит к нескольким важным последствиям для ИТ-менеджмента: 1) сложность в обосновании инвестиций в процессные улучшения и инфраструктурные проекты, так как их ценность для бизнеса неочевидна; 2) проблемы в коммуникации с бизнес-заказчиками, которые фокусируются только на конечных ресурсах, а не на процессах их предоставления; 3) слабое понимание бизнесом скрытых аспектов ИТ-сервисов, обеспечивающих надежность и безопасность; 4) трудности в формировании актуального каталога услуг, если он составлен на языке ИТ, а не бизнеса; 5) необходимость постоянного усилия по трансляции ценности ИТ-процессов в понятные бизнесу термины, что требует от ИТ-менеджеров развития навыков бизнес-коммуникации и аргументации.

Повторная обработка инцидента отрицательно сказывается на результате метрики результативности. Чем больше количество инцидентов (M), которые потребовали повторной обработки конкретной группой, тем ниже значение KPI результативности, так как метрика рассчитывается как 1 — (M / N), где N — общее количество инцидентов с участием группы. Таким образом, повторные обработки напрямую снижают показатель результативности и показывают, что группа не смогла завершить задачу полностью и корректно с первого раза.

Управление доступностью ИТ-услуг (AVA) фокусируется на рисках с высокой вероятностью возникновения, в то время как управление непрерывностью ИТ-услуг (CONT) сосредоточено на рисках, связанных с высоким ущербом, таких как чрезвычайные ситуации и катастрофы. AVA рассматривает незначительные и короткие сбои, не имеющие серьезного влияния на бизнес, включая отказы отдельных компонентов, тогда как CONT учитывает только события, которые потенциально приводят к значительному ущербу независимо от их вероятности. Это включает такие ситуации, как пожары, затопления, длительные отключения электроэнергии или недоступность целых дата-центров.

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