В примерах политик процесса Управления инцидентами (INC) прямо указано: «Информация об инцидентах и их статусах должна своевременно и эффективно передаваться. Это предполагает наличие хорошего service desk для координации коммуникации информации об инцидентах тем, кто работает над инцидентами». Это означает, что процесс должен быть организован так, чтобы обеспечивать непрерывную и понятную коммуникацию между всеми участниками процесса: пользователем, Service Desk и группами, работающими над устранением инцидента. Service Desk выступает центральным звеном в координации этой коммуникации и несёт ответственность за передачу информации пользователю.

Универсальный характер имеют деловые игры, такие как "Египет - управление проектами" и "2020 - организационные изменения", полезные не только для ИТ-руководителей, но и для специалистов из других сфер. Они ориентированы на развитие общих навыков управления, которые применимы в различных профессиональных контекстах.

Основная разница заключается в том, что товар - это физический объект, который передается покупателю, и после покупки покупатель несет все затраты и риски, связанные с его использованием. Услуга же предполагает, что клиент не только получает некую ценность, но и перекладывает определенные затраты и риски на поставщика. При покупке услуги клиент получает доступ к ресурсу или сервисной операции, а не просто физический продукт. Например, при покупке шоколадки как товара клиент несет все риски и затраты по ее хранению, транспортировке и использованию, а при покупке шоколадки как услуги (Choco-as-a-Service) клиент перекладывает риски и затраты по доставке или обеспечению постоянного наличия шоколадки на поставщика.

Для управления рисками в области IT существуют различные методы и стандарты, такие как CRAMM, COSO ERM, ISO 27005, OCTAVE и MEHARI. Все эти методики описывают известный цикл управления рисками, состоящий из этапов: определение охвата, идентификация, анализ, оценка, реагирование и контроль. Этот цикл официально закреплен в стандарте ISO 31000 с 2009 года. Каждая методика предлагает свой подход к формулированию рисков. Например, ITSM-специалисты часто используют модель «актив-угроза-уязвимость», в то время как PMBOK рекомендует структуру «причина-событие-последствие». ISACA в своих публикациях, начиная с RiskIT и в частности в COBIT 5 for Risk, предлагает концепцию сценария риска, включающего источник угрозы, тип угрозы, событие, связанные активы и временной аспект.

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

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

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

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

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

Основная идея заключается в разделении функции общего контроля исполнения и организации работ по проведению изменений (это ответственность менеджера изменений) и функции организации обработки отдельных запросов на изменения (это задача координаторов изменений). Такое разделение позволяет создать более структурированную систему управления изменениями, где менеджер обеспечивает общее руководство процессом, а координаторы работают с конкретными запросами на изменения. Эта концепция, хотя и не упомянута в официальной документации ITIL, широко применяется в различных вендорских процессных моделях таких как BMC, HP и IBM