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

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

Автор упоминает, что некоторые ИТ-специалисты воспринимают себя как "гуру и чуть ли не божества", чтобы подчеркнуть проблему излишней самоуверенности и ограниченности знаний у некоторых представителей ИТ-сферы. Он отмечает, что часто эти специалисты считают себя экспертами во всех вопросах только потому, что могут составлять простые программные конструкции из английских слов (for, while, if, loop), при этом их знание второго языка и технических аспектов обычно ограничено. Это создает барьеры в коммуникации с бизнесом и усугубляет проблему разобщенности между ИТ и бизнес-подразделениями.

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

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

Для определения достаточного уровня полномочий владельца конкретного процесса нужно провести анализ каждой обязанности владельца процесса и оценить степень критичности выполнения этой обязанности для успешного функционирования процесса в конкретной организации. Можно использовать десятибалльную шкалу, где 10 соответствует самой критичной обязанности, без выполнения которой процесс не сможет работать. По результатам оценки выделяют обязанности с высоким баллом (8-10), которые определят минимально необходимый уровень полномочий. Например, если обеспечению ресурсов процесса присвоено 9 баллов, значит владелец должен иметь возможность влиять на все подразделения, участвующие в процессе. Если организации только начинает внедрять процессный подход, высокие оценки получат больше обязанностей, что потребует более высокого уровня полномочий владельца. В зрелых процессных организациях достаточно будет сконцентрироваться на нескольких ключевых обязанностях.

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

Менеджер по взаимоотношениям с бизнесом (Business relationship manager) играет важную роль в процессе управления уровнем услуг, хотя в данной статье он не рассматривается подробно. Его основная задача - обеспечивать связь между бизнесом и ИТ, передавая требования бизнеса в понятном для ИТ виде. Он занимается трансляцией требований бизнеса, полученных от заказчиков, в понятные ИТ-задачи, которые затем передаются владельцу услуги и другим процессам ИТ. BRM участвует в формировании требований к уровням услуг, которые ложатся в основу SLA.

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

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