Структура IT4IT первого уровня (Level 1) представлена через призму потоков создания ценности (Value Streams), где все элементы модели выстроены вокруг сервисной модели (Service Backbone) как основы. Это создает более явную и структурированную картину того, как различный ИТ-активы взаимодействуют для создания ценности. В ITIL v3 структура основана на жизненном цикле услуги (Service Lifecycle), представленном как последовательность фаз: стратегия, дизайн, переход к эксплуатации, эксплуатация и непрерывное улучшение. В то время как ITIL v3 фокусируется на том, что происходит с услугей на разных этапах ее жизни, IT4IT Level 1 делает акцент на том, как потоки работы проходят через организацию для создания этой услуги. IT4IT Level 1 предоставляет более явные связи между бизнес-потребностями и ИТ-реализацией через Value Streams, тогда как ITIL v3 предоставляет более детализированный взгляд на управление самой услугой на разных этапах ее жизненного цикла.

ITIL 4 расширил применение четырех аспектов управления на всю систему создания ценности потому, что услуги не ограничиваются только этапом проектирования, а создают ценность на протяжении всего своего жизненного цикла через взаимодействие всех компонентов организации. В ITIL v3 2011 концепция, похожая на четыре аспекта (4P: Продукты, Процессы, Персонал, Партнеры), применялась преимущественно к этапу проектирования услуг. Однако в современных условиях, с развитием гибких методологий и усложнением ИТ-экосистем, стало очевидно, что эти компоненты влияют на все этапы создания и предоставления услуг. Расширение применения четырех аспектов на всю систему создания ценности отражает более глубокое понимание того, что организация должна интегрированно управлять услугами на всех стадиях их жизненного цикла. Это позволяет более гибко реагировать на изменения, обеспечивать согласованность между стратегией и операционной деятельностью и лучше удовлетворять потребности пользователей через согласованные потоки создания ценности.

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

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

Чтобы преобразовать продажу товара в продажу услуги, необходимо определить, какие риски и затраты клиент может переложить на поставщика. Например, простая продажа шоколадки - это товарная модель, где клиент сам решает вопросы ее приобретения и хранения. Чтобы превратить это в услугу, можно добавить компоненты: 1) Регулярная доставка (покупатель получает шоколадку к утреннему кофе без необходимости самому ее покупать); 2) Обеспечение доступности через автомат (ресурс - сам автомат, операции - его загрузка и обслуживание). Таким образом, клиент не просто получает товар, но и перекладывает на поставщика ответственность за обеспечение доступности и своевременности получения товара, что и составляет суть услуги.

Выбор стандарта зависит от цели расчетов. Для внутренней технической оценки надежности компонентов сети (например, оборудования) рекомендуется использовать ГОСТ Р 53480-2009, так как он фокусируется на физических характеристиках систем. Для управления ИТ-услугами и взаимодействия с заказчиками предпочтительнее ITIL и ISO/IEC 20000, где акцент сделан на доступность услуги в контексте бизнес-процессов. На практике часто применяются оба подхода: ГОСТ для технических отчетов, ITIL — для коммуникации с клиентами.

Практические упражнения для распознавания Action Bias включают в себя анализ реальных кейсов и ситуаций, таких как рассмотренное в тексте упражнение «Найдите среди предлагаемых утверждений ложные, обоснуйте своё мнение». Полезно регулярно проводить рефлексию принятых решений, задавая вопросы: было ли это действие действительно необходимо? Что бы произошло, если бы мы этого не сделали? Также можно внедрить практику «остановки перед действием» - обязательную паузу перед запуском новых задач для обоснования их необходимости. Деловые игры и симуляции процессов, такие как «Проект Феникс - DevOps на практике», позволяют в безопасной обстановке увидеть, как скрытые убеждения влияют на принятие решений. Важно создавать среду, где вопросы о целесообразности действий поощряются, а не рассматриваются как проявление нерешительности.

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

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

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