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

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

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

Конфигурационная единица (CI) — это любой компонент, который необходимо управлять для предоставления услуги. Определение того, что является конфигурационной единицей в рамках предоставляемой услуги, помогает установить границы ответственности. Если CI, например, стиральная машина, включена в соглашение, то её поломка будет считаться инцидентом. Если же она не включена, то это не является нарушением уровня услуги. Таким образом, понятия CI и границы ответственности тесно связаны между собой

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

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

ITIL рекомендует, чтобы служба service desk закрывала инциденты после того, как будет удостоверена полная ликвидация инцидента, удовлетворенность пользователей и их согласие на закрытие. Согласно документу Service Operation 4.2.5.9, service desk должен выполнить несколько процедур перед закрытием: указать код закрытия, провести опрос удовлетворенности пользователя, документировать закрытие инцидента, определить наличие связи с проблемой для предотвращения повторения, и формально закрыть инцидент (изменить статус на «закрыто»).

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

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

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