ELMA: портал поставщиков на ELMA365

Закупочная команда перенесла заявки из почты и таблиц в исполняемый процесс с ответственными, сроками и обязательными данными. Поставщик получил понятный статус, каждое решение стало частью аудита, а временная недоступность ERP перестала означать потерю операции: запрос оставался в контролируемой очереди и безопасно повторялся.

Паспорт процесса

• Направление: B2B, low-code, документооборот, интеграции.
• Задача: Создать портал, где поставщик подает предложение, прикладывает документы и видит статус проверки.
• Продолжительность: 4 месяца на портал, процессы и ERP-интеграцию.
• Команда: PM, process analyst, ELMA365-архитектор, 2 low-code-разработчика, integration-разработчик, QA и UX. Всего 8 человек.
• Роль AIFlowPoint: Разработка кабинета поставщика, маршрутов согласования, защищенного документооборота и интеграций с ERP и электронной подписью на ELMA365.

Исходная ситуация и бизнес-риск

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

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

Границей проекта стал портал поставщика вместе с маршрутами согласования и необходимыми интеграциями. Портал собирал заявку, проверял обязательность, исполнял процесс, сохранял версии и передавал утвержденные данные в ERP через контролируемый интеграционный контур. Формальная модель владения данными за пределами этого обмена в кейсе не заявляется.

Сначала процесс, затем формы

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

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

Путь поставщика и закупочной команды

Реализация охватила полный согласованный цикл:

1. Разработали кабинет поставщика с регистрацией компании, пользователями и ролями.
2. Добавили анкету, загрузку документов и контроль обязательных полей и сроков действия.
3. Настроили маршруты согласования по сумме, категории закупки и уровню риска.
4. Создали запрос коммерческого предложения с защищенной подачей цены и файлов.
5. Реализовали сравнение версий, комментарии, уточнения и возврат на доработку.
6. Подключили электронное подписание и передачу утвержденных данных в ERP.
7. Добавили очередь интеграционных ошибок и безопасный повтор операции.
8. Подготовили дашборд сроков, просрочек и загрузки без раскрытия предложений другим поставщикам.

Поставщик регистрировал организацию, заполнял анкету, прикладывал действующие документы и видел статус проверки. Если комплект был неполным или требовал уточнения, заявка возвращалась на доработку без уничтожения предыдущей версии. Закупочная команда видела сроки, ответственных и исключения, сравнивала версии и передавала утвержденные данные в ERP после подписания.

Технический и защитный контур

ELMA365 дает исполняемые процессы, формы и роли, которые бизнес может развивать без переписывания всего приложения. TypeScript используется для сложных проверок и интерфейсной логики. REST API связывает портал с ERP и сервисом подписи. PostgreSQL хранит структурированные данные, объектное хранилище отделяет документы от публичной части, а OpenAPI и contract tests защищают обмен от незаметного изменения форматов.

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

Технологический контур проекта: ELMA365, TypeScript, JavaScript, HTML, CSS, BPMN 2.0, REST API, OpenAPI, PostgreSQL, S3-совместимое хранилище, OAuth 2.0, Электронная подпись, Docker, CI/CD, Playwright и API contract tests. Этот перечень связывает исполняемый процесс, интерфейсы, документы, интеграции и проверки в границах проекта.

Временная недоступность ERP обрабатывалась как ожидаемая отказная ветка. Операция оставалась в очереди, ошибка была видна, а повтор не приводил к потере операции или неконтролируемому дублю. Защита документов строилась на серверной проверке прав для каждого объекта, а не только на том, что пользователь не видел ссылку в интерфейсе.

Результат и метрики

Главным изменением стала управляемость исключений: неполный комплект возвращался по маршруту, просрочка становилась видимой, а сбой ERP больше не превращал заявку в потерянное письмо.

Измеримый результат: Длительность согласования сокращается на 30-50%; не менее 75% заявок поступают с полным комплектом документов; временная недоступность ERP не приводит к потере операций.

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

Критерии приемки и подтверждающие материалы

• Поставщик видит только свою организацию, заявки и документы.
• Система не пропускает заявку без обязательных и действующих документов.
• Новая версия предложения не уничтожает ранее согласованный вариант.
• Временная недоступность ERP не приводит к потере заявки.
• Каждое решение и изменение остаются в аудите.
• Бизнес меняет согласованный справочник или шаблон без выпуска новой версии backend.

Проверку результата фиксируют BPMN до и после, dashboard process analytics, матрица ролей, журнал интеграционной очереди и отчет проверки доступов. Метрики рассчитаны по одинаковым границам процесса и сопоставимым периодам до и после внедрения.

Переданные материалы

• Настроенный портал и исходники расширений.
• BPMN-схемы процессов.
• Матрица ролей и доступов.
• Контракты интеграций.
• Инструкции администратора.
• Тестовые сценарии.
• План переноса между dev, test и production.

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

Когда этот опыт релевантен

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

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