Согласно ITIL 4, руководящий принцип определяется как рекомендация, которая направляет организацию в любых обстоятельствах, независимо от изменений в ее целях, стратегиях, типе работ или управленческой структуре. Руководящие принципы универсальны и устойчивы и призваны поддерживать принятие решений всех типов и на всех уровнях. Они отражают основные идеи ITIL и управления услугами в целом, а также согласуются с многими другими подходами, методологиями, стандартами и сводами знаний, такими как Lean, Agile, DevOps и COBIT. Принципы помогают организациям внедрять подход управления услугами и адаптировать рекомендации ITIL к своим конкретным потребностям и обстоятельствам, а также способствуют постоянному улучшению на всех уровнях.

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

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

Для оценки удовлетворенности заказчика ИТ-услугами можно использовать опрос, содержащий ключевые вопросы, задаваемые заказчикам на регулярной основе. Например, вопросы о степени удовлетворенности достигаемойutility услуг, степени удовлетворенности достигаемой warranty услуг, и степени соответствия показателей warranty реальным потребностям заказчика. Ответы даются по шкале 0-1 (0 – полное несоответствие, 1 – полное соответствие), а для определения итогового показателя можно использовать взвешенное арифметическое усреднение. Такой подход обеспечивает прямое получение обратной связи от заказчика.

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

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

Наличие дефектов негативно влияет как на бизнес, так и на процесс разработки. Со временем дефекты приводят к экспоненциальному росту потерь - в примере из деловой игры 'Проект Феникс' потери составили 2 000 долларов в первом раунде, 26 000 во втором и 39 000 в третьем. Наличие дефектов замедляет разработку новых функций, так как разработчики вынуждены тратить время на исправление ошибок, и создает технический долг, который становится все дороже в исправлении. Для бизнеса это трансформируется в прямые финансовые потери и ухудшение качества продукта, что отражается на удовлетворенности клиентов.

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

В управлении инцидентами tension-метриками являются: 1) своевременность — соблюдение сроков обработки инцидентов; 2) результативность — доля инцидентов, решенных с первого раза без перенаправлений. Эти метрики конфликтуют: стремление к скорости может привести к перенаправлению обращений (низкая результативность), а фокус на полном решении замедляет процесс (низкая своевременность). Общий KPI объединяет их через геометрическое среднее, чтобы стимулировать баланс.

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