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

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

Розабет Кантер, профессор Гарвардской школы бизнеса, определила три ключевых класса инструментов влияния: 1) Информация — данные, технические знания, экспертиза, знание политической ситуации; 2) Ресурсы — финансовые средства, материальные активы, человеческие ресурсы, время; 3) Поддержка — подтверждение, легитимность, одобрение, защита. Эффективное использование всех трех классов инструментов позволяет сформировать коалицию поддержки изменений и построить процесс внедрения так, чтобы сотрудники воспринимали изменения как свои собственные.

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

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

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

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

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

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

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