Столярка на пять человек: учёт заказов и остатков массива без подписки на каждого

MAATRIX

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

Почему подписка «за голову» бьёт по маленькой мастерской сильнее

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

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

Третья сторона — вы платите за пользователя каждый месяц независимо от того, идёт заказ или нет. У столярки часто есть сезонность и paузы между крупными заказами (кухни на заказ, например, — это не конвейер), а подписка не умеет становиться дешевле в тихий месяц.

Что реально нужно от учёта в столярной мастерской

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

• Учёт заказов — клиент, спецификация (материал, размеры, фурнитура), статус (принят / в раскрое / в сборке / в отделке / готов), срок сдачи.
• Остатки материала — сколько массива каждой породы и сорта на складе, в каких единицах (доска, кубометр, погонный метр — у разных мастерских по-разному).
• Списание под заказ — когда доска ушла в раскрой, остаток должен уменьшиться автоматически или хотя бы одним действием, а не «вспомнить и вычесть в уме».
• Учёт фурнитуры и расходников — петли, направляющие, шканты, клей, лак — отдельная категория с другой логикой закупки (мелкий опт, а не по кубометрам).
• Простая история — кто и когда изменил остаток, чтобы через месяц можно было понять, откуда взялось расхождение.

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

Экономика: фиксированная стоимость сервера против платы за каждого

Возьмём пятерых как иллюстрацию — именно столько человек работает в мастерской из заголовка этой статьи. Логика подписки «за пользователя» означает, что стоимость учёта растёт линейно с числом людей, у которых есть доступ, — и не важно, менеджер это за компьютером восемь часов в день или мастер, который заходит в систему раз в час с телефона, чтобы отметить остаток.

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

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

Как это выглядит на практике: стек на собственном сервере

Технически задача решается без экзотики. На арендованном VPS или выделенном сервере разворачивается открытая система складского и проектного учёта (например, ERPNext или Odoo Community — обе доступны бесплатно как self-hosted и закрывают склад, заказы и базовую отчётность без доработки напильником) поверх обычной связки: контейнеризация, база данных, регулярный бэкап.

Минимальный набор в docker-compose выглядит примерно так (конкретные образы и версии подставляются под выбранную систему учёта):

version: "3.8"
services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: workshop
      POSTGRES_USER: workshop
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    secrets:
      - db_password

  erp:
    image: your-erp-image:latest
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - erp_files:/app/data

volumes:
  db_data:
  erp_files:

secrets:
  db_password:
    file: ./secrets/db_password.txt

Доступ снаружи закрывается через обратный прокси с TLS-сертификатом (Caddy или nginx с certbot — оба варианта отрабатывают эту задачу без лишней возни), а не выставляется порт наружу напрямую. Бэкап базы — банальный ежедневный дамп в cron, который вы храните хотя бы неделю:

# /etc/cron.d/workshop-backup
0 3 * * * root pg_dump -U workshop workshop | gzip > /backups/workshop-$(date +\%F).sql.gz

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

Остатки массива: единицы учёта и партии, которые ломают шаблонные системы

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

Практичный подход — заводить материал не одной позицией «дуб первый сорт», а карточкой на партию: порода, сорт, дата закупки, влажность на момент приёмки, поставщик, объём. При списании под заказ мастер выбирает конкретную партию, а не просто вычитает кубометры из общего остатка. Это чуть больше дисциплины при вводе данных, зато через полгода вы точно знаете, откуда взялась рекламация — из какой партии дерева был сделан спорный стол.

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

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

Доступ впятером: роли, права и работа из цеха

Пять человек — это не «пять одинаковых аккаунтов админа». Стоит развести роли сразу, иначе через месяц никто не вспомнит, кто и почему изменил остаток:

Мастеру в цеху удобнее заходить с телефона или дешёвого планшета, а не садиться за компьютер в опилках. Для этого систему на сервере не обязательно выставлять в открытый интернет целиком — рабочий вариант для мастерской: доступ только через VPN-подключение (WireGuard разворачивается на том же сервере отдельным контейнером за вечер), тогда с внешней стороны сервер вообще не виден, а телефон мастера просто становится частью внутренней сети мастерской, где веб-панель учёта открывается как локальный адрес.

Это же решает вопрос с уволившимся сотрудником: отключить один VPN-конфиг и один аккаунт в системе — секундное дело, в отличие от ситуации с общим логином на весь цех, где непонятно, что вообще нужно менять.

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

Частые вопросы