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

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

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

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

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

Некоторые компании используют отдельные инструменты для учёта активов и экономических расчётов, потому что их программное обеспечение изначально разрабатывалось как разделённое — например, HP имеет отдельные продукты для ITSM (HPSM с CMDB) и для управления активами (HP Asset Manager с AMDB). Также некоторые разработчики продуктов не хотят, чтобы их инструменты зависели от наличия развитых ITSM-решений у заказчиков, поэтому они делают свои системы независимыми. Однако это обусловлено программно-архитектурными ограничениями конкретных решений, а не общими рекомендациями или лучшими практиками. Такие решения не всегда отражают наиболее эффективный подход к совмещению функциональности.

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

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

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

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