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

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

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

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

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

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

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

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

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

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