Пекарня: производственный учёт и списание муки — Excel против своей базы данных

MAATRIX

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

Как обычно ведут производственный учёт в пекарне

Типичная схема на бумаге выглядит просто. Есть рецептура: например, на партию багетов в 50 штук уходит 12 кг муки, 0,24 кг дрожжей, 0,9 кг соли, определённый объём воды. Технолог утром смотрит план выпечки, кладовщик по этому плану отпускает сырьё со склада, а в конце смены кто-то вбивает фактический расход в таблицу.

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

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

Где Excel ломается при росте

Рост производства обычно выглядит так: было 40 партий в день на одной точке, стало 150+ партий на две-три точки плюс склад. Именно на этом объёме таблица перестаёт справляться сразу по нескольким направлениям.

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

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

Нет истории изменений. Когда цифры по муке не сходятся со складским остатком, встаёт вопрос: кто и когда поменял норму расхода в рецептуре, кто исправил количество испечённых партий задним числом. В Excel это либо не восстановить, либо приходится копаться в истории версий Google Таблиц, где изменения показаны построчно по ячейкам, а не по смыслу операции — попробуйте понять оттуда, кто именно списал лишние 8 кг муки на партию №214 и почему.

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

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

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

Что даёт своя база данных вместо таблицы

Собственная база производственного учёта решает эти проблемы не за счёт того, что она «умнее» Excel, а за счёт того, что её архитектура изначально рассчитана на параллельную работу нескольких людей с одними данными.

В базе данных (например, PostgreSQL — почему именно её, а не MySQL, разобрано в статье PostgreSQL или MySQL: что выбрать для сервера) каждая операция — отдельная запись с временной меткой и автором, а не ячейка в общем листе. Кладовщик списывает муку на партию — это строка в write_offs с created_at и created_by. Технолог правит рецептуру — появляется новая версия, а не перезапись старой. Формул как таковых нет: себестоимость считается запросом к данным по требованию.

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

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

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

Модель данных: рецептуры, партии, списание сырья

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

CREATE TABLE ingredients (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    unit TEXT NOT NULL,
    stock_qty NUMERIC(10,3) NOT NULL DEFAULT 0 CHECK (stock_qty >= 0),
    unit_cost NUMERIC(10,2)
);

CREATE TABLE recipes (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    output_qty INTEGER NOT NULL,
    version INTEGER NOT NULL DEFAULT 1
);

CREATE TABLE recipe_items (
    recipe_id INTEGER REFERENCES recipes(id),
    ingredient_id INTEGER REFERENCES ingredients(id),
    qty_per_batch NUMERIC(10,3) NOT NULL CHECK (qty_per_batch > 0),
    PRIMARY KEY (recipe_id, ingredient_id)
);

CREATE TABLE batches (
    id SERIAL PRIMARY KEY,
    recipe_id INTEGER REFERENCES recipes(id),
    baked_qty INTEGER NOT NULL CHECK (baked_qty >= 0),
    scrap_qty INTEGER NOT NULL DEFAULT 0,
    shift TEXT,
    created_by TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE write_offs (
    id SERIAL PRIMARY KEY,
    batch_id INTEGER REFERENCES batches(id),
    ingredient_id INTEGER REFERENCES ingredients(id),
    qty NUMERIC(10,3) NOT NULL CHECK (qty > 0),
    created_by TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

(ingredients — сырьё и остаток на складе; recipes и recipe_items — рецептура и её состав; batches — фактические партии выпечки; write_offs — фактическое списание сырья по каждой партии.)

Разница с Excel здесь принципиальная: рецептура и факт списания — разные сущности. По норме на партию багетов положено 12 кг муки, но по факту кладовщик мог списать 12,4 кг — часть теста ушла в брак при формовке. В таблице это два разных числа, которые всегда можно сравнить, а не одна ячейка, где норма и факт путаются местами. Списание «сверх партии» — бой, порча при хранении, списание по сроку — стоит заводить с отдельной причиной (reason); в Excel это обычно тонет в общей цифре расхода за день.

Можно повесить на write_offs триггер, который автоматически уменьшает stock_qty в ingredients при каждой вставке — тогда остаток склада всегда синхронен с фактическими списаниями:

CREATE OR REPLACE FUNCTION deduct_stock() RETURNS TRIGGER AS $$
BEGIN
    UPDATE ingredients
    SET stock_qty = stock_qty - NEW.qty
    WHERE id = NEW.ingredient_id;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_deduct_stock
AFTER INSERT ON write_offs
FOR EACH ROW EXECUTE FUNCTION deduct_stock();

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

Многопользовательский доступ и история операций

Здесь раскрывается основное преимущество над Excel — не в красоте интерфейса, а в том, как система ведёт себя, когда с ней одновременно работают разные люди с разными правами.

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

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

История операций вместо истории версий файла. Каждая запись в write_offs и batches содержит created_by и created_at — это не техническая история изменений ячеек, а осмысленная история бизнес-операций: кто, когда и что списал. Вопрос «почему на прошлой неделе расход муки на 15% выше нормы» решается одним запросом:

SELECT b.created_at, b.created_by, w.qty, i.name
FROM write_offs w
JOIN batches b ON b.id = w.batch_id
JOIN ingredients i ON i.id = w.ingredient_id
WHERE i.name = 'Мука пшеничная в/с'
  AND b.created_at >= now() - interval '7 days'
ORDER BY b.created_at;

В Excel эквивалент — вручную листать историю версий по ячейкам или разводить руками, потому что данные за прошлые дни уже перезаписаны новыми цифрами в той же ячейке.

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

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

Как перейти с Excel на свою базу — практический план

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

Путь 1: готовый low-code инструмент. Если писать интерфейс с нуля некому, разумный компромисс — развернуть на своём сервере NocoDB или Baserow: Excel-подобные таблицы с формами ввода, ролями доступа и полноценной реляционной базой под капотом. Разница с облачными SaaS-таблицами в том, что база стоит на вашем сервере и не утекает по подписке. Что выбрать, разобрано в статье NocoDB или Baserow: что выгоднее и когда — там же готовые docker-compose файлы.

Путь 2: своя база плюс минимальный интерфейс. Если есть человек, способный написать простое веб-приложение на Python или PHP, это даёт больше контроля: точную модель данных под конкретные рецептуры, триггеры на списание, свои отчёты. Отправная точка — PostgreSQL на сервере, пошаговая установка описана в статье как установить и настроить PostgreSQL на VPS. Поверх базы можно временно работать через SQL-клиент или простую админку вроде pgAdmin, пока не готов интерфейс для цеха.

Практический порядок миграции, который хорошо работает на живых пекарнях:

1. Выгрузить справочники из Excel — сырьё, рецептуры с нормами расхода — в CSV и импортировать в ingredients и recipes/recipe_items. Разовая ручная сверка, но её всё равно придётся сделать при любом переходе.
2. Запустить обе системы параллельно на 2-3 недели. Кладовщик и технолог продолжают вести Excel, но параллельно вносят те же данные в новую систему — так находятся расхождения в логике и люди привыкают к новому вводу.
3. Сверить итоговую себестоимость за тот же период по обеим системам. Расхождения почти всегда объясняются округлением или скрытым ручным исправлением в Excel, которого нет в формуле.
4. Отключить Excel только после того, как сверка сошлась хотя бы за две недели подряд.
5. Настроить резервное копирование базы сразу, а не «когда-нибудь потом» — данные о списании сырья финансово значимы, и потерять полугодовую историю из-за упавшего диска обиднее, чем потерять файл Excel с копиями в почте.

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

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