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

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

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

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

Согласно ITIL 4, SLA (Service Level Agreement) — это документированное соглашение между поставщиком и заказчиком, которое определяет требования к услуге и ожидаемый уровень предоставления этой услуги. SLA фиксирует договоренности между двумя субъектами сервисных отношений, где заказчик должен определить свои требования и ожидания относительно потребляемой услуги, а также требования других стейкхолдеров, таких как регуляторы.

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

Принципиальный компромисс в ITSM заключается в исключении из области охвата управления уровнями ИТ-услуг вопросов разработки новой функциональности информационных систем. Этот подход предполагает разделение зон ответственности: Application lifecycle management (ALM) используется для разработки, а IT service management (ITSM) — для эксплуатации и сопровождения систем. Такой компромисс позволяет сосредоточиться на поддержании существующих услуг и их доступности, не беря на себя обязательства по гарантии сроков и качества новых разработок.

Output (выход) — это результат деятельности поставщика услуг, который сам по себе не представляет ценности для потребителя, но является необходимым промежуточном этапом. Outcome (результат) — это конечный эффект, который достигает потребитель услуг, выражаясь в реальной пользе или удовлетворении его потребностей. Например, торт от пекарни — это output, тогда как счастливые дети на дне рождения — outcome.

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

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