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

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

Путаница с ролями, начинающимися со слова 'service', возникает из-за обилия вариаций названий и исторических изменений в ITIL. В частности, в некоторых компаниях до сих пор используется термин 'Service Manager', который в ITIL уже давно не применяется. Дополнительную сложность создает то, что ITIL4 Foundation не содержит детального описания ролей, участвующих в практиках, в отличие от ITIL V3. Эта путаница особенно заметна в контексте процесса управления уровнем услуг (Service Level Management), где требуется чёткое понимание обязанностей различных ролей, таких как Service level manager и Service owner.

Запрос на получение информации о текущем статусе инцидента должен обрабатываться в процессе Управление инцидентами (Incident Management, INC). Этот процесс несёт ответственность за обеспечение прозрачности работы с инцидентами, включая коммуникацию информации о статусе инцидента. В ITIL Service Operation явно указано, что обеспечение прозрачности является частью задач процесса INC. В примере критических факторов успеха упомянут KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов», что подразумевает необходимость минимизации таких запросов за счёт качественной коммуникации в рамках INC. Хотя процесс Управления запросами на обслуживание (Request Fulfillment Management, RFF) может использоваться как канал передачи информации, основная ответственность за организацию коммуникации и прозрачность лежит на INC, поэтому именно этот процесс должен отрабатывать запросы о статусе инцидента.

Восемь шагов модели Джона Коттера для успешных изменений: 1) Создание ощущения срочности; 2) Создание коалиции; 3) Разработка видения и стратегии; 4) Коммуницирование видения; 5) Старт преобразований на всех фронтах; 6) Создание быстрых побед; 7) Консолидация и усиление изменений; 8) Закрепление изменений. Каждый этап играет важную роль в процессе трансформации организации.

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

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

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

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

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