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

Сервисное мышление тесно связано с 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) служат направляющими для принятия решений, отражающих сервисное мышление.

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

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

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

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

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

Среднее время поставки (Lead time) — это временной интервал, необходимый для выполнения запроса пользователя или внедрения изменения в систему, начиная с момента его поступления и до завершения обработки. Это ключевая метрика, так как она определяет скорость реакции системы на запросы клиентов и сотрудников, влияет на удовлетворённость пользователей и эффективность бизнес-процессов. Слишком длительное время приводит к потерям: клиенты уходят, сделки срываются, снижается конверсия. Эталонные команды разработки стремятся уложиться в часы, а хорошие — в дни, что подчеркивает важность минимизации Lead time.

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

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