Типичные ошибки внедрения service desk и как их избежать

6 октября 20266 мин чтения

Короткий ответ: большинство неудачных внедрений ITSM-системы спотыкаются не на самой системе, а на четырёх повторяющихся ошибках: берут сразу все практики ITIL 4, не проверив, что реально нужно; назначают SLA «на глаз», без расчёта от реальной критичности; заставляют заявителей менять привычный канал обращения; и запускаются с пустой базой знаний, которая так и остаётся пустой.

Ошибка 1: внедрять всё сразу

ITIL 4 описывает 34 практики, и методология прямо говорит: применять их нужно выборочно и прагматично, а не все одновременно. Попытка сразу настроить CMDB, управление изменениями, проблемами и мощностями затягивает запуск на месяцы, пока простой приём заявок с SLA решил бы основную боль уже за несколько дней. Подробный план поэтапного запуска — в статье «Как запустить службу поддержки с нуля за одну неделю».

Ошибка 2: назначать SLA без расчёта

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

Ошибка 3: заставлять всех писать только в новую систему

Если единственный способ подать заявку — зайти в незнакомый веб-интерфейс, часть сотрудников просто продолжит писать в личку коллеге из ИТ-отдела в обход системы. Разумнее подключить каналы, которыми уже пользуются — Telegram, почту — и дать системе собирать заявки оттуда автоматически, не меняя привычек заявителей.

Ошибка 4: запуск с пустой базой знаний

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

Как проверить, что ваш план внедрения не повторяет эти ошибки

Перед запуском стоит честно ответить на четыре вопроса: с каких практик вы реально начинаете (не все 34 сразу); откуда взялись цифры в нормативах SLA; из каких каналов заявители продолжают писать после запуска; и кто и когда будет пополнять базу знаний в рабочем режиме.

По теме в КРОМ: план внедрения КРОМ

Короткие ответы на частые вопросы

С каких практик лучше начинать внедрение?

С приёма заявок, приоритетов, SLA и каталога услуг — это закрывает основную боль ручного учёта. CMDB, управление изменениями и проблемами добавляют уже на втором этапе, когда появляется конкретная задача под них.

Как понять, что SLA назначен нереалистично?

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

Обязательно ли сразу писать много статей в базу знаний?

Нет, 5–10 статей по самым частым вопросам на старте — нормальный объём. База знаний растёт по мере работы: каждая новая повторяющаяся заявка — повод завести статью.

Что делать, если сотрудники саботируют новую систему?

Чаще всего причина — система заставляет менять привычный способ обращения. Если заявки принимаются из тех же каналов, которыми уже пользуются (Telegram, почта), сопротивление обычно меньше, чем при переходе исключительно на новый веб-интерфейс.

Разберём план вашего внедрения на демо — укажем на риски заранее, а не после запуска.

Демо по заявке →