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

Управление рисками не выделено в отдельную практику в ITIL 2011, поскольку оно присутствует как сквозной элемент в различных процессах и группах практик. Риск-менеджмент интегрирован в процессы проектирования услуг, управления проблемами, постоянного совершенствования услуг, управления изменениями и релизами, а также в управление портфелем услуг. Согласно тексту, ITIL в целом можно рассматривать как систему управления рисками, поскольку управление ИТ-услугами в широком смысле является инструментом снижения бизнес-рисков, связанных с ИТ-сферой. Вместо отдельного процесса управление рисками распределено между различными практиками, что отражает идею о том, что управление рисками является частью работы любого менеджера на любом уровне.

Чтобы избежать фокуса исключительно на процессах при внедрении управления ИТ-сервисами, необходимо следовать следующим принципам: 1) Начать с определения ключевых ИТ-сервисов и выявления показателей качества, важных для бизнеса, а не со внедрения процессов; 2) Установить четкую ответственность за каждый сервис и назначить менеджеров сервисов; 3) Связать метрики процессов напрямую с показателями качества сервиса, а не только с внутрипроцессными показателями; 4) Внедрить постоянную обратную связь от пользователей сервисов для корректировки приоритетов и целей; 5) Создать циклы непрерывного улучшения сервисов, включающие анализ отклонений, выявление причин проблем и внедрение улучшений; 6) Обеспечить, что система мотивации сотрудников направлена на достижение целевых показателей сервиса, а не только на следование процессным процедурам; 7) Проводить регулярные стратегические встречи по управлению сервисами с участием бизнеса для согласования приоритетов и ожиданий.

Адаптация ITIL-процессов под специфику компании основывается на принципах гибкости и ориентации на бизнес-ценность. Сначала определите ключевые бизнес-процессы компании и ИТ-услуги, которые их поддерживают. Выберите элементы ITIL, которые напрямую влияют на эти услуги и процессы. Проведите анализ текущих практик в компании и выявите, что уже работает хорошо и может быть сохранено. Сфокусируйтесь на результатах, а не на процессах - задавайте вопрос: 'Какой бизнес-результат должен быть достигнут этим процессом?' Упростите процессы до необходимого уровня сложности, исходя из размера компании, сложности ИТ-инфраструктуры и бизнес-требований. Для небольших организаций допустимо объединение ролей и упрощение документации. Для регулируемых отраслей увеличьте внимание к аудиту и отчетности. Создайте гибридные процессы, комбинируя элементы ITIL с существующими практиками компании. Проведите пилотное внедрение адаптированных процессов в одной области, оцените результаты и только потом масштабируйте. Обратите внимание, что ITIL - это не жесткий стандарт, а набор рекомендаций, которые должны быть интерпретированы в контексте конкретной организации. Основное правило - процесс должен создавать ценность для бизнеса, а не существовать ради формального соответствия.

Для создания системы стандартов оценки эффективности работы в гибкой команде необходимо сначала определить, что организация считает нормальной работой. Это включает установление допустимого уровня дефектов (например, не 15-50%, как часто ошибочно считают, а гораздо ниже), определение эффективного использования трудовых ресурсов (чтобы не было ситуации, когда до 80% ресурсов расходуется впустую), создание четких стандартов постановки запросов от бизнеса, чтобы все задачи в бэклоге несли бизнес-ценность. Также необходимы KPI для оценки производительности и качества работы. Эти стандарты должны быть согласованы со всеми заинтересованными сторонами и понятны всем сотрудникам. Важно регулярно пересматривать и обновлять стандарты по мере развития бизнеса и изменений в ИТ-ландшафте. Соблюдение этих стандартов должно стать частью корпоративной культуры и оцениваться в рамках системы мотивации.

"Сквозная" ответственность за релиз означает наличие единой роли или лица, отвечающего за управление и координацию деятельности в рамках релиза на всём протяжении его жизненного цикла — от планирования и подготовки до непосредственного развёртывания и закрытия. Эта концепция аналогична роли координатора изменений в процессе управления изменениями, где отдельный ответственный следит за всеми этапами изменения. В ITIL такая сквозная ответственность фактически возлагается на менеджера процесса, хотя прямого указания на роль "Координатор релизов" в стандарте не существует. Это создаёт некоторые неопределённости для организаций, внедряющих ITIL, особенно при необходимости четко распределить ответственность внутри команды.

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

В дополнение к основным компонентам чек-лист предлагает рассмотреть стандартизацию изменений с низким риском, автоматизацию процессов через конвейеры (CI/CD), порядок взаимодействия с внешними поставщиками при обработке изменений и требования к компетенциям сотрудников, участвующих в реализации изменений. Эти рекомендации необязательны для всех случаев, но могут значительно повысить эффективность управления, особенно для определённых типов изменений. Например, стандартизация ускоряет выполнение низкорисковых изменений, а автоматизация позволяет интегрировать модель изменений в существующие CI/CD конвейеры.

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

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