Проектирование и построение единой операционной системы бизнеса на базе Pyrus

Ситуация на старте
До начала проекта полноценной информационной системы у компании не было.
Основная работа велась в таблицах, отдельных файлах, переписках и вручную собранных отчётах. Там хранились данные о заказах и клиентах, закупках, остатках, расчётах и финансах.

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

Но по мере роста компании становилось всё сложнее быстро ответить на простые вопросы:

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

Проблема была не только в отсутствии автоматизации.
У компании не было единой спроектированной модели работы.

Поэтому проект начали не с настройки Pyrus, а с проектирования самой операционной модели бизнеса.

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

Для каждого процесса определили:

• где он начинается;
• какие подразделения в нём участвуют;
• какие данные нужны на каждом этапе;
• где требуется согласование;
• какие действия можно выполнять параллельно;
• от какого события зависит следующий шаг;
• какие процессы связаны между собой.

Особое внимание уделили сквозным цепочкам.

Например, закупка была спроектирована не как отдельная задача «купить товар», а как полноценный процесс: от появления потребности и расчёта себестоимости до размещения заказа, оплаты, доставки и поступления партии на склад.

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

Pyrus как ядро операционной модели
Центральной системой стал Pyrus.
В нём мы собрали внутреннюю логику компании и связали основные операционные процессы:

• коммерческие предложения;
• согласование договоров;
• закупки;
• платежи;
• складские заявки;
• упаковку;
• логистику;
• контроль исполнения заказов;
• внутренние согласования;
• финансовые процессы.

При этом Pyrus стал не просто местом, где сотрудникам ставят задачи.

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

Три системы — одна архитектура
При проектировании мы сразу отказались от идеи заставить одну систему выполнять все функции.
В итоге была построена связка из трёх систем:
Pyrus — процессное ядро и управление внутренней работой.
Битрикс24 — CRM, клиентская база, сделки и коммуникации.
МойСклад — товарный, складской и учётный контур.

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

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

Каждая система отвечает за свою часть работы, а Pyrus связывает их в единую операционную модель.

Сквозное управление заказом
После появления заказа Pyrus становится координатором дальнейшей работы.

В зависимости от ситуации могут запускаться связанные процессы:
заказ → проверка возможности исполнения → согласование условий → закупка → поставка → склад → отгрузка → контроль оплаты.
При этом это не жёсткая линейная воронка.

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

Именно поэтому обычной CRM-воронки здесь было недостаточно.

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

Управляемые закупки
Одним из наиболее значимых контуров стали закупки.

В рамках проектирования мы разобрали полный путь поставки:
Потребность → Расчёт себестоимости → Размещение заказа → Оплата → Готовность → Отправка → Движение поставки → Поступление на склад.

Теперь закупка существует в системе как отдельный управляемый процесс.

Руководителю не нужно отдельно спрашивать сотрудников, где находится товар. В Pyrus видно текущее состояние поставки, ответственного и следующий шаг.

При этом закупка связана с остальной системой. Потребность возникает не сама по себе, а в контексте конкретных заказов, остатков и планов компании.

То есть решение «нам нужен товар» сразу связано с дальнейшим его исполнением.

Коммерческие предложения и согласования
Отдельным сложным процессом стала подготовка коммерческих предложений.

Цена для крупного клиента может зависеть не только от стоимости самого товара. На итоговую экономику влияют условия поставки, логистика, объём, канал продаж, комиссии, отсрочка и другие параметры.

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

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

В результате цепочки писем и сообщений заменились понятными цифровыми маршрутами.

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

Особенно это важно для маркетплейсов, где складская работа тесно связана с требованиями конкретной площадки и форматом поставки.

В результате склад перестал быть отдельным участком, которому периодически передают задачи. Он стал полноценным участником общей цепочки исполнения заказа.

Финансовый контур
Через Pyrus связали и операционные процессы с финансовыми событиями.
Например, закупка может создавать необходимость в оплате, а отгрузка — запускать дальнейший контроль поступления денег.

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

Таким образом, Pyrus связывает не только сотрудников и задачи, но и финансовые события с причиной их возникновения.

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

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

Мы встроили ИИ непосредственно в процесс Pyrus.

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

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

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

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

Что получил бизнес
МОСТРЕЙДГРУПП прошла путь от процессов, собранных в таблицах, файлах и знаниях отдельных сотрудников, к единой спроектированной операционной системе.

Главным результатом стала не автоматизация какой-то одной функции.
Мы фактически описали цифровую модель работы компании и реализовали её на базе Pyrus.
Сотрудники получили понятные маршруты вместо ручной координации.

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

Закупки — с реальными потребностями.
Склад — с заказами.
Финансы — с операционными процессами.
А Битрикс24 и МойСклад благодаря глубокой кастомной интеграции стали частью общей архитектуры, а не отдельными информационными системами.

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

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

Центральным элементом стал Pyrus.
На его базе была создана процессная система, которая управляет внутренней жизнью заказа и связывает вокруг себя Битрикс24 и МойСклад.

Кейс проекта МОСТРЕЙДГРУПП наглядно показывает, как Pyrus может использоваться не просто для постановки задач и согласований, а как операционное ядро бизнеса, спроектированное под реальную модель работы компании.