Заявки отсутствия. Как они помогают бизнес-процессам и как мы создали свой мини-n8n

Одна из новых возможностей нашего HRM-модуля — заявки отсутствия. Заявки отсутствия — это формальный способ оповещения компании о временном отсутствии сотрудника.

Виды отсутствий, которые оформляются через заявки:

Как заявки помогают повысить эффективность процессов:

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

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

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

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

Третья итерация стала переломной. Мы отказались от карточной линейной модели отображения вех и перевели маршрутизацию в визуальный граф на базе React Flow. Это изменение было не косметическим, а архитектурным. Вехи стали полноценными узлами процесса, а действия — явными связями между ними. За счет этого конструктор начал поддерживать сложную логику естественным способом: теперь можно наглядно строить ветвления, возвраты назад, переходы не только на следующий или предыдущий этап, но и в конкретную точку маршрута, отдельные сценарии согласования, отказа, доработки и завершения. В результате выросла не только гибкость функциональности, но и качество самого продукта. Процесс стало легче читать глазами, проще объяснять, быстрее настраивать и безопаснее изменять. Для корпоративной системы это особенно важно: ценность не только в том, что сложный маршрут “можно собрать”, а в том, что его можно собрать без риска запутаться в собственной логике.

Отличия от типовых решений на рынке: мини n8n

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

Это и делает реализацию заметно отличающейся от многих типовых решений на рынке. Во многих системах “конструктор заявок” по сути остается конструктором формы со статусами: есть поля, есть несколько этапов, есть список ответственных, а реальная логика процесса либо жестко ограничена, либо прячется в сложных настройках, которые трудно читать и трудно сопровождать. Мы изначально пошли в другую сторону. Для нас заявка — это не просто карточка с данными, а маршрут движения действия внутри компании. В центре этой модели стоит не только ввод информации, но и сам процесс: кто принимает решение, какие действия у него есть, что происходит после каждого действия, кому уходят уведомления, где процесс заканчивается, а где продолжается. После перехода на графовую модель эта логика перестала быть скрытой. Ее видно сразу. Администратор работает не “вслепую” через выпадающие списки и таблицы, а буквально собирает схему движения заявки как живой процесс.

Отличия от типовых решений на рынке: фундамент для ЭДО

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

Три итерации — избыточно?

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

По сути, сегодня конструктор заявок в ZentrySpace — это уже больше, чем конструктор. Это зарождение собственного визуального движка бизнес-процессов внутри корпоративной платформы. И именно поэтому его следующая эволюция выглядит для нас особенно интересной: мы не просто добавляем новые поля или новые статусы, а шаг за шагом собираем внутренний механизм, на котором смогут строиться процессы согласования, HR-сценарии, уведомления, маршруты документов и ЭДО. В каком-то смысле это действительно движение в сторону нашей собственной “n8n” — только не общей, а глубоко встроенной в корпоративный контекст, оргструктуру и реальные ежедневные процессы компаний.

#корпоративныймессенджер #заявки #n8n #b2b