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

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

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

Важно, что предложенная метрика изменяется в диапазоне [0;1], потому что нормированность метрики позволяет легко интерпретировать её значения, сравнивать производительность в разные периоды времени и между различными группами или подразделениями. Нормированные метрики упрощают установление целевых значений, так как менеджеры заранее знают, к каким показателям стремиться (например, достичь 80-90%), а также позволяют выявить, когда значение метрики становится критически низким и требуется вмешательство для улучшения процесса.

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

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

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

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

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

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