Для предотвращения путаницы необходимо четко определить в договорах и технической документации используемую терминологию. Рекомендуется сопровождать термины пояснениями вида: «Доступность (в смысле ITIL, включая плановые простои)». При работе с российскими стандартами можно указывать: «Готовность (в соответствии с ГОСТ Р 53480-2009)». Также полезно использовать англоязычные оригиналы (availability) с расшифровкой методологии расчета в приложениях.

Контроль известной ошибки (known error) в ситуации, когда после диагностики не обнаружено реалистичных решений, имеет свои особенности. В этом случае процесс фокусируется не на устранении проблемы, а на управлении ее последствиями и минимизации влияния на бизнес. В рамках error control (EC) устанавливается срок контроля известной ошибки, который позволяет отслеживать проявления проблемы и оценивать, как она влияет на работу бизнес-процессов в режиме ожидания. Такой подход необходим, когда решение проблемы технически невозможно или экономически нецелесообразно в данный момент, но требуется поддерживать сервис на приемлемом уровне.

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

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

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

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

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

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

В тексте упоминаются следующие рекомендуемые источники литературы по коммуникациям в управлении проектами: «Основы менеджмента» Мексон М., Альберт М., Хедоури Ф.; «Переломный момент: Как незначительные изменения приводят к глобальным переменам» (англ. The Tipping Point: How Little Things Can Make a Big Difference) Малкольм Гладуэлл; «Using Communications As An Agent Of Organizational Change» Джек Пробст, IT Management Consultant; «Communication Breakdown and Conflict within Teams» Стив Леммекс, PMP; PMBOK® Guide раздел «Communications management»; ITIL Practitioner Guidance. Эти источники охватывают различные аспекты коммуникаций — от фундаментальных управлений до специфических методик управления коммуникациями в ИТ-проектах и проектной документации. ITIL Practitioner, в частности, предлагает структурированный подход к планированию коммуникаций, задавая ключевые вопросы, которые необходимо решить для эффективного управления информационными потоками.

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