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

И вот вы начинаете искать систему для заявок — и упираетесь в трекеры, документооборот, service desk, ESM. Каждый описывает себя одинаковыми словами: каталог услуг, автоматизация, единое окно. Разница почти не видна, пока заявок мало и они остается в одном отделе. Она проявляется в первую неделю после того, как заявка уходит из ИТ в кадры или в закупки, и там выясняется, кто ее видит и кто отвечает за срок.

Это не только наше наблюдение. Свежее исследование НИУ ВШЭ и консалтинговой компании Beyond Taylor (опрос 202 российских компаний, 2026 год) показывает то же самое на уровне рынка: 85% компаний признают, что сбои на стыках между подразделениями — реальная управленческая проблема, а около трети респондентов называют кросс-функциональные процессы главным узким местом в управлении, наравне с проблемами в самой команде топ-менеджмента (26%). При этом менее четверти компаний способны назвать конкретного человека, отвечающего за результат на стыке отделов. Заявка, застрявшая между HR и ИТ, — частный случай именно этой более широкой болезни.

Меня зовут Евгений Котухов, я эксперт по внедрению и оптимизации ITSM/ITAM-решений, официальный технологический партнёр SimpleOne, соавтор ГОСТа по управлению ИТ-активами. В этой статье разбираем, как выбирать между разными решениями.  

Почему нельзя сравнивать только по функциональности

Заявка, статус, уведомление, вложение встречаются в описании любой системы: трекера, СЭД, service desk, ESM. 

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

— Слушай, а где заявка на ноутбук для нового разработчика?
— В моем проекте, я ее HR-у в чат отправил.
— А в ИТ-очереди ее видно?
— Не знаю, надо у ИТ спросить, взяли ли они в работу.
— А срок с какого момента считается?
— С момента, как я завел задачу, наверное.

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

Возьмем два полюса спектра — привычный трекер и зрелый ESM, — чтобы увидеть амплитуду разницы. Ниже разберем, что происходит на той же развилке в собственной разработке, СЭД и service desk.

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

Уведомления есть в обоих случаях. Разница — в том, что происходит на переходе: сохраняется ли контекст, пересчитывается ли срок, кто получает доступ к деталям. Дальше эти три наблюдения разложим в пять критериев, по которым и сравним классы систем.

Как будем сравнивать

Чтобы сравнение было честным, мы выбрали пять критериев, которые проявляются именно на границе между отделами, а не внутри одного процесса.

1. Добавление новой услуги без разработки.

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

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

2. Маршрутизация между подразделениями. Передача заявки из отдела в отдел с сохранением истории и срока; групповые очереди, замещение.

3. Согласования. Многошаговые, условные, параллельные маршруты; делегирование.

4. Сроки с рабочим календарем. График подразделения, паузы на уточнении, пересчет при переназначении.

5. Разграничение видимости. Заявки одних подразделений закрыты от других; права на вложения настраиваются отдельно от прав на заявку.

Пять способов организации заявок

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

1. Таск-трекер

Трекер почти всегда уже стоит в компании — его завела команда разработки, а потом остальные отделы решили пользоваться тем же инструментом для своих задач. Дешевое и быстрое решение, пока задач немного и они однотипны.

Услуги как понятия здесь нет — есть тип задачи и форма полей. Согласование собирают вручную через автоматизации и статусы. Статус «отправлено на согласование» ничего не говорит о том, кто согласовал и когда.

— Опять пять разных полей заполнять для заявки на доступ. У нас что, шаблона нет?

— Не завели пока, каждый раз копируем из старой задачи.

— А кто согласовал — где посмотреть?

— В комментах где-то, я обычно скроллю всю ветку.

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

Кому подходит: малому и среднему бизнесу с двумя-тремя типами заявок без ветвящихся согласований.
Кому не подходит: компаниям с несколькими отделами, которым нужно передавать заявки между отделами и одновременно скрывать их друг от друга.

2. Документооборот и BPM

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

Маршруты согласования — многошаговые, параллельные, с делегированием — здесь сильнее, чем в любом другом классе, включая ESM. Версионирование документов и подпись работают из коробки.

Каталога услуг как отдельной сущности нет: есть виды документов и связанные с ними маршруты. Каждая новая услуга требует отдельного проекта настройки маршрута документа. Срок описан в логике самого документа.

Портал для сотрудника, который хочет отправить заявку и посмотреть статус, слабее, чем в service desk или ESM: интерфейс заточен под работу с документом, а не с обращением.

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

3. Классический service desk

Service desk решал одну задачу — навести порядок в заявках на ИТ-поддержку: инцидент, запрос на обслуживание, каталог ИТ-услуг. Внутри этой задачи он работает почти идеально, и большинство компаний, которые внедряли ITSM-практики, начинали именно с него.

Каталог, сроки по SLA, база знаний и портал работают из коробки для ИТ-домена. Маршрутизация и видимость покрывают процессы внутри ИТ без доработок.

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

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

4. ESM

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

То же ядро, что у service desk, только мультидоменное: каталог организован по подразделениям. Услуга оформлена как данные, которые настраивает администратор процесса без релиза. Разграничение видимости между отделами встроено в ролевую модель.

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

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

5. Разработка с нуля

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

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

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

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

Как выбрать

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

Но прежде нужно понять для себя главное. Какую задачу и для кого вы решаете? Вам нужна система для ИТ или для одной команды разработки? Может, для десяти команд? Для бухгалтерии? Вы хотите решить клиентский вопрос? Вы хотите, чтобы ваши коллеги бизнес-пользователи могли подавать свои обращения? 

Ответы дадут вам правильный вектор здесь и сейчас, что поможет определится с типом системы. Далее уже можно переходить к тем самым трем вопросам. Они вам дадут понимание, какая система вам нужна в перспективе. Может сейчас вам нужен таск-трекер, а через два года вы поймете, что все-таки нужен ESM, и лучше заложить это сразу. 

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

Сколько подразделений будет в системе через два года?

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

Кто должен менять правила маршрутизации и формы — администратор процесса или разработчик?

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

Нужно ли скрывать заявки одних подразделений от других?

Для начала нужно ответить на вопрос: а какую задачу вы решаете? Таск-трекер и документооборот по сути решают одну задачу, ITSM и ESM — другую. Заказчики иногда пытаются закрыть вторую задачу первым инструментом, и это не срабатывает: в трекере нет ни услуг, ни гибких процессов, ни того, из чего складывается сервисное управление.

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

Три ответа редко указывают на один и тот же класс поодиночке — окончательное решение складывается из их пересечения. Компания с двумя отделами, без требований к видимости и с администратором, готовым ждать релиз, может остаться на трекере. Как только хотя бы один ответ смещается в сторону роста подразделений, самостоятельной настройки правил или разграничения доступа, стоит присматриваться к service desk или ESM.

Резюме

Класс системы зависит от числа подразделений, которые заведут в нее заявки, и от того, кто владеет изменением правил. Собственная разработка и BPM отвечают на второй вопрос иначе, чем service desk и ESM. Таск-трекер и текущее решение остаются рабочим выбором, пока подразделений одно-два.

Сигнал для пересмотра — первое требование скрыть заявки одного отдела от другого. Рост компании сам по себе таким сигналом не служит: можно оставаться на трекере при пятидесяти сотрудниках и перейти на ESM при двадцати, если структура заявок этого требует.

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