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

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

Для объяснения пользователей задержек, связанных с разными часовыми поясами, рекомендуется использовать прозрачный подход. Создать стандартные шаблоны сообщений, которые автоматически информируют пользователя о статусе обращения и причинах возможных задержек. Например, сообщение может содержать информацию: «Ваше обращение было направлено в группу поддержки в [часовой пояс], которая начнет работу в [время] по вашему местному времени». Также можно разработать простой калькулятор на сайте, где пользователь может ввести время обращения и получить примерные сроки решения с учетом часовых поясов. Важно не перегружать пользователя техническими деталями, а объяснять ситуацию на понятном языке с акцентом на то, что работа над обращением будет продолжена в ближайшее рабочее время.

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

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

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

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

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

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

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