Ситуация на стартеPyrus в компании уже использовался, но изначально представлял собой скорее набор отдельных форм, чем единую операционную систему.
По мере развития проекта стало понятно, что для мебельного производства этого недостаточно. Нужно было связать CRM, работу с заказом, технологическую и конструкторскую подготовку, внутренние согласования, производство, рекламации, отчётность и обмен данными с 1С.
Особенно много ручной работы оставалось на этапе передачи заказа конструкторам.
Сотруднику приходилось самостоятельно разбираться:
- кто из конструкторов может работать с конкретным заказчиком;
- кому подходит данный тип заказа;
- кто уже работал с этим клиентом;
- насколько загружен каждый специалист;
- кому разумнее передать крупный проект, а кому — небольшой заказ.
Фактически правильное распределение зависело от опыта и памяти сотрудника. При большой загрузке это превращалось в отдельную операционную задачу и создавало риск неправильного назначения.
Вторая критичная точка находилась уже после проектирования.
Когда конструктор подготавливал документацию, её качество во многом зависело от ручной проверки. При большом количестве заказов возрастал риск пропустить ошибку в спецификации, отсутствие необходимой информации или несоответствие установленным требованиям.
Причём стоимость такой ошибки увеличивается по мере движения заказа. То, что можно быстро исправить на стадии документации, значительно сложнее исправлять после передачи в производство.
Поэтому задача проекта вышла далеко за рамки настройки отдельных форм.
Pyrus должен был стать полноценной ERP-системой, которая не только ведёт заказ по маршруту, но и помогает контролировать корректность принимаемых решений.
Архитектура решенияВ центре системы находится форма «Заказ клиента».
В ней собираются данные по заказчику, типу заказа, ответственным, проекту и дальнейшему движению заказа.
Вокруг неё выстроены связанные процессы: работа отдела продаж, технологическая подготовка, проектирование, согласования, подготовка счёта, рекламации и другие внутренние задачи.
Pyrus стал рабочим интерфейсом сотрудников, а 1С:ERP сохранила роль учётного и производственного контура.
Сотруднику не приходится постоянно переключаться между системами или вручную передавать информацию между отделами. Заказ движется по заданному маршруту, а на ключевых этапах подключаются автоматические проверки и боты.
При этом мы не стремились полностью убрать человека из процесса.
Там, где требуется управленческое решение, система подготавливает информацию, сокращает выбор и контролирует соблюдение правил, но финальное действие остаётся за сотрудником.
Особенно хорошо этот подход проявился в работе с конструкторами.
Умное распределение заказов между конструкторамиКогда заказ доходит до этапа передачи в конструкторский блок, автоматически запускается бот.
Его первая задача — определить, какие конструкторы вообще могут быть назначены на этот заказ.
Для этого система анализирует заданные компанией правила, в том числе:
- заказчика;
- тип заказа;
- допустимых для этого сценария специалистов.
В результате сотрудник получает уже отфильтрованный список конструкторов, которых можно назначить.
Раньше ему приходилось самостоятельно искать эту информацию и сопоставлять сразу несколько факторов. Теперь большую часть этой работы выполняет система.
При этом мы не стали полностью автоматизировать назначение.
Финальный выбор конструктора по-прежнему делает сотрудник. Это позволяет сохранить гибкость в ситуациях, где формальных правил недостаточно.
После назначения бот включается ещё раз и проверяет выбранного конструктора. Если назначение не соответствует правилам компании, система не пропускает ошибку дальше по процессу и возвращает заказ на корректировку.
Получилась двухступенчатая модель:
система определяет допустимых исполнителей → сотрудник принимает решение → система проверяет это решение.Таким образом, автоматизация не заменяет человека, а убирает из его работы большую часть рутинного поиска и одновременно страхует от ошибки.
ИИ-агент для анализа загрузкиФормальные правила отвечают на вопрос: кто может выполнить заказ?
Но этого недостаточно, чтобы понять, кому его лучше передать сейчас.
Для этой задачи в процесс добавили ИИ-агента, который анализирует текущую загрузку конструкторов и характеристики поступающего заказа.
Важно, что агент смотрит не только на количество задач.
Он способен различать заказы по масштабу и учитывать, что один крупный проект может создавать большую нагрузку, чем несколько небольших заказов.
Это позволяет оценивать загрузку команды значительно реалистичнее, чем простой подсчёт количества активных задач.
В итоге распределение работает в несколько уровней:
- автоматические правила определяют допустимых конструкторов;
- ИИ оценивает их текущую загрузку с учётом характера заказов;
- сотрудник получает более узкий и обоснованный выбор;
- после назначения бот проверяет соответствие правилам.
Таким образом, человеческое решение сохраняется там, где оно действительно необходимо, но объём ручной аналитики перед этим решением сводится к минимуму.
ИИ-контроль проектной документацииВторой AI-контур работает уже после того, как конструктор завершает подготовку проекта.
Раньше главным риском на этой стадии была человеческая ошибка. В документации могло не хватать необходимых данных, в спецификациях могли оставаться неточности или отдельные элементы проекта могли не соответствовать установленным требованиям.
Чем позже обнаруживается такая проблема, тем дороже она обходится бизнесу.
Если ошибка проходит дальше в производственный процесс, она может привести к дополнительным согласованиям, переделкам и рекламациям.
Поэтому после подготовки документации в Pyrus автоматически подключается отдельный ИИ-агент.
Он выполняет роль дополнительного уровня контроля качества перед дальнейшим движением заказа.
Агент проверяет:
- спецификации по проекту;
- комплектность необходимой документации;
- наличие требуемой информации;
- соответствие документации правилам проверки;
- возможные ошибки и несоответствия.
Если система обнаруживает проблему, конструктор получает информацию о том, что необходимо проверить или исправить.
Так контроль качества переносится на более ранний этап — до того, как ошибка уйдёт дальше по производственной цепочке.
RAG-база для проверки документацииДля такого сценария недостаточно использовать обычную языковую модель.
Проверка должна выполняться не на основании общих знаний нейросети, а с учётом внутренних требований и правил компании.
Поэтому для агента был реализован полноценный RAG-контур.
Перед проверкой ИИ получает из базы знаний релевантную информацию, необходимую именно для конкретной задачи, и уже после этого анализирует документацию.
Таким образом, агент работает не как универсальный чат-бот, который самостоятельно пытается определить, правильно ли собран проект, а как специализированный инструмент контроля, опирающийся на знания и требования компании.
Это делает проверку воспроизводимой и позволяет развивать систему дальше. По мере появления новых правил и сценариев база знаний дополняется, а сам бизнес-процесс при этом не приходится перестраивать.
ИИ не заменяет конструктора и не снимает с него ответственность за проект.
Его задача — выступать дополнительным автоматическим фильтром и находить потенциальные проблемы до передачи документации дальше.
Интеграция Pyrus с 1С : ERPПараллельно с процессной автоматизацией была выстроена интеграция с 1С:ERP.
Роли систем разделены следующим образом:
Pyrus — рабочий интерфейс сотрудников и центр управления процессами.
1С:ERP — учётный и производственный контур.
При наступлении определённых событий данные автоматически передаются между системами.
В 1С создаются и актуализируются необходимые сущности по заказу, а полученные данные возвращаются обратно в Pyrus.
Это позволяет менеджерам, технологам и конструкторам продолжать работать в привычном процессном интерфейсе, при этом производственный контур получает необходимую информацию автоматически.
Отдельно синхронизируются справочники контрагентов и связанные данные, которые затем используются внутри Pyrus для маршрутизации и определения ответственных.
В результате справочники становятся не просто хранилищем информации, а частью бизнес-логики системы.
Рекламации и контроль качестваОтдельным процессом внутри Pyrus ведутся рекламации.
Для мебельного производства это особенно важно: проблема может возникнуть на разных участках — в проектировании, материалах, производстве, замере, доставке или коммуникации с заказчиком.
Рекламация фиксируется как отдельный управляемый процесс с причиной, ответственными, историей обработки и итоговым решением.
При этом новый ИИ-контроль проектной документации добавляет ещё один уровень профилактики рекламаций.
Если потенциальную ошибку удаётся обнаружить ещё до производства, её можно вернуть конструктору и исправить в той точке, где стоимость исправления минимальна.
Таким образом, система работает не только с последствиями проблемы, но и помогает снижать вероятность её возникновения.
Отчётность и управленческий контрольPyrus позволяет руководству видеть не только текущий статус заказа, но и его фактическое движение по процессу.
Можно контролировать:
- на каком этапе находится заказ;
- кто отвечает за следующий шаг;
- где возникает задержка;
- сколько времени заказ находится у конкретного подразделения или сотрудника;
- какие задачи действительно просрочены;
- какие находятся в ожидании клиента;
- как распределена нагрузка между участниками процесса.
Разделение рабочих статусов и ожиданий позволяет корректнее оценивать загрузку команды.
А новый механизм распределения между конструкторами добавил ещё один уровень: данные о загрузке теперь используются не только для последующего анализа, но и непосредственно при принятии решения о назначении нового заказа.
Что получил бизнес«ПростоМебель» получила единую операционную систему, в которой Pyrus управляет заказом от входящего обращения до подготовки к производству и дальнейшего взаимодействия с 1С.
Для сотрудников система стала рабочим инструментом, который снимает значительную часть рутинных решений.
При передаче заказа конструкторам больше не нужно вручную собирать информацию о допустимых исполнителях и самостоятельно сопоставлять её с загрузкой команды. Автоматические правила формируют список возможных специалистов, ИИ помогает оценить их реальную загрузку, а бот после назначения контролирует правильность решения.
При этом финальный выбор остаётся за человеком.
Для конструкторов появился дополнительный уровень контроля качества. После подготовки проекта ИИ-агент на базе RAG проверяет документацию и спецификации и помогает обнаруживать потенциальные ошибки до передачи заказа дальше.
Для руководства система стала значительно прозрачнее: можно видеть движение заказа, ответственных, сроки, загрузку сотрудников и проблемные точки процесса.
Самое важное — Pyrus перестал просто фиксировать происходящее.
Система начала участвовать в принятии операционных решений и контролировать их качество: определять допустимых исполнителей, помогать балансировать загрузку, проверять назначения и анализировать проектную документацию до передачи в производство.
ИтогНа базе Pyrus для «ПростоМебель» была построена кастомная ERP-система, которая объединяет CRM, обработку заказов, технологическую и конструкторскую работу, согласования, рекламации, управленческую отчётность и интеграцию с 1С:ERP.
Следующим уровнем развития стала интеллектуальная автоматизация ключевых точек производства.
ИИ используется здесь не ради отдельной функции или чат-бота. Он встроен непосредственно в операционный процесс: помогает распределять заказы между конструкторами и выступает дополнительным уровнем контроля проектной документации.
В связке с обычной процессной автоматизацией это позволило построить гибридную модель, где система берёт на себя рутину, анализ и проверки, а сотрудники сохраняют контроль над решениями, которые требуют человеческого участия.
Кейс проекта «ПростоМебель» наглядно показывает, как Pyrus можно превратить из системы форм и задач в полноценный рабочий слой между клиентом, сотрудниками и производственным контуром — с автоматическими правилами, ИИ-агентами и контролем качества на ключевых этапах заказа.