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

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

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

Предлагается использовать три ключевых показателя, отражающих разные аспекты влияния простоев на бизнес: 1) Суммарное время простоев за период, отражающее общий объем недоступности; 2) Максимальный разовый простой, учитывающий критичность длительных прерываний, которые могут вызвать значительные убытки и репутационный ущерб; 3) Количество нарушений, важное для бизнес-процессов, чувствительных к частым кратковременным простоям (например, длительные вычисления, требующие перезапуска). Также упоминается альтернативный показатель - минимальная или средняя продолжительность работы без нарушений.

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

Для внедрения SMART-подхода в управление ITSM-процессами необходимо для каждого процесса сформулировать цели, соответствующие критериям Specific (конкретность), Measurable (измеримость), Achievable (достижимость), Relevant (релевантность), Time-bound (ограниченность сроками). Например, цель для процесса управления инцидентами: 'Сократить среднее время устранения инцидентов с критическим приоритетом до 2 часов к концу квартала'. Эти цели должны быть привязаны к назначению процесса и измеряться через влияние на качество ИТ-услуг.

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

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

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

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