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

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

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

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

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

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

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

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

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

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