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

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

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

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

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

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

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

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

Продуктовым командам помогают принципы Site Reliability Engineering (SRE), методики разработки, повышающие надёжность, такие как Test-Driven Development (TDD), сквозное автоматизированное тестирование на всех этапах разработки, интеграции и доставки, а также своевременный контроль и устранение технического долга. Эти подходы позволяют минимизировать риски сбоев при внесении изменений, поддерживать эксплуатационные характеристики приложений и сокращать время поставки за счёт автоматизации и строгого контроля качества на каждом этапе.

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