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

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

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

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

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

В тексте упоминаются четыре классические функции менеджмента: планирование, организация, мотивация и контроль. Текст намекает на эти функции, когда говорит о том, что некоторые руководители объясняют команде, как выполнять работу ('планирование' и 'организация'), определяют приоритеты, дают обратную связь ('мотивация') и следят за результатами ('контроль'). Хотя название этих функций прямо не перечислено, их суть раскрывается через описания правильного и неправильного поведения менеджеров в игровых ситуациях.

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

С помощью CLD в контексте DevOps можно определить следующие ключевые практики для процесса изменений: обеспечение полноты регистрации изменений (Changes Logged), реализация изменений с первого раза (First-Time Implementation Rate), применение PIR для оценки процесса (PIR), минимизация аварийных изменений (Emergency changes rate), стандартизация изменений для сокращения рисков (Standardization/Automation), контроль хода изменений (Change Control Level), обеспечение частых и небольших внедрений (Release Rate), управление бэклогом (Backlog size / Queue Time).

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

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