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

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

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

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

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

В состав Nj при расчёте FTR должны входить только те обращения, обработанные j-той группой, по которым процедура проверки решения полностью завершена. К ним относятся: закрытые без рекламаций инциденты (Cj) и возвраты на доработку (Sj). Не включаются в Nj обращения, которые всё ещё находятся в процессе обработки или где проверка решения не завершена, так как они не могут быть учтены при определении качества работы группы.

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

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

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

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