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

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

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

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

Сервисное мышление тесно связано с 7 руководящими принципами ITIL 4, которые помогают реализовать это мышление на практике. ITIL 4 предлагает структурированный подход, превращающий абстрактное понятие 'сервисного мышления' в конкретные действия и решения. Семь принципов ITIL (Focus on value, Start where you are, Progress iteratively with feedback, Collaborate and promote visibility, Think and work holistically, Keep it simple and practical, Optimize and automate) служат направляющими для принятия решений, отражающих сервисное мышление.

Команда на уровне «Зрелость» представляет собой агента изменений на уровне всей компании. Она полностью контролирует свой рабочий процесс и несет ответственность за продукт на уровне P&L (прибыль и убытки), что означает управление финансовой стороной продукта. Инициативы направляются не только внутрь команды, но и наружу, команда стремится расширять зону влияния и инициирует изменения, затрагивающие множество служб и подразделений компании. Для такой команды лидер-слуга уже не нужен, как и лидер-наставник. Здесь требуется лидер-партнер с достаточными полномочиями для поддержки командных инициатив на высшем уровне, обладающий широкой осведомленностью о направлении развития компании и достаточным авторитетом для интеграции целей команды с целями компании. Это высшая ступень развития, где команда становится драйвером изменений в организации.

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

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

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

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