Как ERP выросла из Google Таблиц и реального производства

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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