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

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

Согласно исследованию, проведенному в 2006 году среди 440 организаций, 33% компаний использовали собственный внутренний подход к организации управления ИТ-процессами (internally developed framework), в то время как только 13% применяли ITIL. Это свидетельствует о том, что значительное количество организаций предпочитает разрабатывать свои собственные методологии управления, адаптированные под их конкретные нужды, вместо использования общепринятых стандартов.

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

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

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

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

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

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

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