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

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

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

Коэффициент доступности является ключевым KPI в SLA (Service Level Agreement). Например, обязательство «99,9% доступности» означает, что суммарное время простоя в год не должно превышать 8,76 часов. При невыполнении этого условия поставщик услуг может выплачивать штрафы или предоставлять компенсации. Для расчета учитываются как внезапные отказы, так и плановые работы, согласованные с клиентом. Четкость определения термина в SLA предотвращает спорные ситуации.

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

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

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

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

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

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