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

Разложим все три по полочкам и определим, что зависит от выбора системы, а что — только от процессов и организационной подготовки.

Задача 1: сделать одну точку входа

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

Но что происходит  после отправки заявки? Единое окно решает вопрос входа, но ничего не гарантирует на выходе, если за формой нет логики маршрутизации. Возьмём заявку на командировку: 

  • сотрудник указывает даты и город, 

  • форма уходит в общую очередь, 

  • а дальше кто-то должен вручную определить, что запрос касается сразу трёх отделов — бухгалтерии для аванса, АХО для брони билетов и HR для отметки в графике отпусков и командировок. 

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

Дальше нагрузка не исчезает, а просто меняет форму. Диспетчер переключает статус заявки на «в работе», когда бухгалтерия начала считать аванс, и возвращает её в очередь, если из АХО пришёл вопрос про даты рейса. Сотрудник, который отправил запрос, не видит прогресса по каждому из трёх кусков своей командировки — он видит одну заявку и звонит уточнить, что там с билетами, потому что статус в системе не менялся уже два дня. Тот же диспетчер эскалирует просроченные заявки, если вообще замечает просрочку, и отвечает за то, чтобы ни один из трёх отделов не забыл про свою часть работы. Снаружи это выглядит как единая точка входа, изнутри — как прежний объем ручной маршрутизации, просто собранный в одной очереди. 

Мы уже разбирали, как разные классы систем — трекеры, документооборот, service desk и ESM — справляются с маршрутизацией и распределением заявок между отделами.

Задача 2: заменить разные системы одной

Второй сценарий спускается сверху: компания объявляет мегапроект по переходу на единую систему для всех обращений и ставит жёсткий дедлайн. Цель — покончить с зоопарком инструментов, где ИТ работает в трекере, HR — в почте, а бухгалтерия — в общей папке на диске. Проблема в том, что подготовка почти никогда не успевает за амбициями проекта, и первый удар принимают не те, кто его придумал, а те, кто должен работать в новой системе завтра.

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

Здесь легко допустить и обратную ошибку. Если ИТ-отдел успешно работал в ITSM-системе, есть соблазн выдать её же HR, юристам и бухгалтерии — система уже куплена, команда её знает, зачем искать что-то ещё. Проблема в объектной модели, под которую настроена система: в ИТ-контуре базовый объект — инцидент и конфигурационная единица, вокруг них строятся поля, статусы и связи. HR не оформляет инциденты, у него заявления на отпуск, поиск кандидатов и адаптация новых сотрудников. Бухгалтерии не нужны конфигурационные единицы, ей нужны согласования счетов и авансовых отчетов. Обоим отделам нужен свой базовый объект — услуга со сроками и условиями для конкретного заказчика. Заставить эти отделы работать в структуре, построенной вокруг ИТ-объектов, означает либо ломать её логику до неузнаваемости, либо мириться с тем, что часть полей и процессов остаётся балластом.

Работающий вариант — забрать у ITSM не саму систему, а практики: описание услуги, каталог с понятными сроками, единую логику эскалации и отчётности. Эти практики родом из ITIL, но ITIL не привязан к ИТ-отделу — он описывает принципы сервисного управления в целом. Так HR, АХО и бухгалтерия становятся отдельными поставщиками услуг со своими каталогами и SLA, но работают в рамках одной платформы, а не отдельного клона ИТ-системы. Тогда ИТ сохраняет свою специфику, HR получает процессы под свои задачи, а данные всех отделов остаются в одном источнике вместо трех несовместимых баз.

Задача 3: описать услуги и назначить ответственных

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

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

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

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

Так какую задачу решать?

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

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

Как это сделать по шагам, включая расчёт эффекта для своей компании, мы разобрали в гайде «ESM для CIO»: пять шагов внедрения, новая роль ИТ-директора и три реальных кейса — Альфа-Лизинг, МТС Банк, Systeme Electric — с цифрами: рост скорости обработки заявок на 20–25% и экономия до 10% FTE при переходе HR, финансов и АХО на сервисную модель. 

Прочитайте гайд на нашем сайте, чтобы понять, с чего начать переход у себя в компании.  

Если вы уже используете систему заявок и не уверены, что она справляется с ростом компании, признаки того, что пора её менять, мы разобрали в нашей статье на Хабре.