Фиксированная эскалация создает четкие границы ответственности между бизнес-аналитиками и разработчиками в процессе обработки инцидентов. Бизнес-аналитики, выступающие в роли третьей линии поддержки (L3), получают инцидент после предварительной диагностики на уровне L2 и определяют, связана ли проблема с ошибками программного обеспечения или с некорректными требованиями к алгоритмам от бизнес-подразделений. Если требования были сформулированы верно, инцидент передается на уровень L4 к разработчикам для внесения исправлений в код. Такая структура предотвращает ситуацию, когда разработчики тратят время на анализ требований, и наоборот, бизнес-аналитики не тратят время на отладку программного кода, что повышает эффективность работы обеих групп.

В некоторых организациях элементы Change proposal могут присутствовать в RFC, особенно в случаях, когда бизнес-заказчик первоначально обращается с запросом в свободной форме. Форма RFC часто включает разделы, касающиеся бизнес-выгод и обоснования срочности, что помогает быстрее определить необходимость создания полноценного Change proposal для крупных изменений.

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

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

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

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

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

До перехода в консалтинг, когда автор работал на стороне заказчика, рабочая загрузка составляла примерно 70-80% — времени хватало на выполнение всех задач, и даже оставалось время на изучение новых технологий и управленческих методик. После перехода в консалтинг уровень рабочей загрузки вырос до 120-130%, в пиковые периоды достигая 160%. Это привело к тому, что возник острый вопрос о том, как всё успеть, и потребовало поиска решений в области управления временем и повышения личной эффективности.

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

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