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

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

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

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

Для объяснения используется пример заказа торта на день рождения: Output — сам торт, который готовит и предоставляет пекарня; Outcome — это восторг именинника и удовлетворённость гостей, которые съели торт. Также применяются другие примеры: Output таксиста — спортивный автомобиль, а Outcome — быстрая и комфортная доставка пассажира до места назначения.

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

Улучшение клиентского опыта достигается через идентификацию и оптимизацию точек взаимодействия с потребителем, которые находятся в полосе видимости. При синхронизации потоков и путешествия заказчика необходимо определить, на каких этапах путешествия происходит взаимодействие с клиентом и какие потоки при этом запускаются. Сфокусировавшись на этих точках, можно непрерывно улучшать CX/UX, делая взаимодействие более эффективным и приятным. Например, упрощая процессы сбора требований на этапе Offer или оптимизируя решение инцидентов на этапе Co-create. Это позволяет целенаправленно управлять клиентским опытом и повышать удовлетворенность потребителей.

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

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

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