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

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

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

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

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

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

Сравнение показывает, что предполагаемые затраты времени на ведение учета (5-10% рабочего времени) значительно завышены по сравнению с реальными (0,32% за 2014 год). Это доказывает, что распространенные опасения относительно трудоемкости учета времени необоснованны и что введение системы учета не приведет к значительным потерям рабочего времени, как часто предполагают сотрудники и менеджеры.

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

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

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