Для предотвращения будущих недоразумений между бизнесом и IT необходимо обсудить несколько ключевых аспектов, которые часто остаются за рамками обычной рутинной работы. Согласно тексту, нужно выяснить: одну ли мотивацию имеют бизнес-сотрудники и технические специалисты (обычно ответ — «нет»), одинаково ли понимают ли они термины и концепции (часто нет), одинаково ли воспринимают и участвуют в командных процессах (обычно нет), достаточно ли коммуникаций между ними и подходящая ли у них форма (часто недостаточно). Также важно, чтобы ИТ-специалисты могли простыми словами объяснять бизнесу смысл своей работы, трудности и обоснование решений. Такие обсуждения помогают создать общее понимание целей и процессов, что уменьшает риск накопления технического долга и улучшает взаимодействие в долгосрочной перспективе.

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

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

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

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

У первой линии поддержки существуют следующие ограничения при оценке влияния инцидентов: 1) Доступны только субъективные оценки пользователя, без технической диагностики. 2) Объем диагностической информации минимален на начальном этапе обращения. 3) Пользователь может не знать о проблемах других сотрудников. 4) Сложности в объективной оценке степени недоступности функционала ('совсем не работает' против 'частично не работает'). 5) Необходимость быстро принять решение об уровне влияния, имея ограниченную информацию. Эти ограничения делают важным разработку четких вопросов для пользователя, которые позволяют максимально объективно определить влияние инцидента.

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

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

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

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