Хроника объявленной аварии
Давайте честно: сколько раз ваше производство останавливалось не из-за поломки сложного станка с ЧПУ, а из-за того, что на складе внезапно кончились болты М6 или специфическая смазка?
Обычно это выглядит так. Начальник цеха бежит к снабженцам с криком "Где?!", снабженцы тычут в Excel-таблицу со словами "Мы заказали месяц назад!", а на складе разводят руками — "Привезли, но не то". В итоге инженер срочно ищет аналог, логист везет это на такси по тройной цене, а директор считает убытки от простоя линии.
Корневая причина:
Мы привыкли винить людей ("Иванов забыл", "Петров не внес"). Но проблема не в людях. Проблема в разрыве информационных потоков. В классической схеме "лоскутной автоматизации" отдел продаж работает в CRM, склад — в WMS (или в тетрадке), производство — в голове мастера, а бухгалтерия — в своей учетной системе.
Между этими островами нет мостов. Данные передаются через электронную почту, звонки и стикеры на мониторах. Как только цепочка усложняется (появляются аналоги, частичные поставки, возвраты), "ручной привод" отказывает. Вы не можете управлять тем, что не видите в реальном времени.
Чем модуль закупки отличается от Excel
Я часто слышу от ИТ-директоров: "Зачем нам модуль закупки? У нас есть бухгалтерия, там всё видно". Это опасное заблуждение. Бухгалтерия фиксирует факт (деньги ушли, накладная пришла). Инженеру и снабженцу нужен план и процесс.
Давайте включим EXPERT MODE и разберем, как работает правильная архитектура снабжения изнутри. Современный модуль закупки — это не просто журнал заявок. Это машина состояний , жестко связанная с MRP (планирование потребностей в материалах).
Как это работает "под капотом":
Во-первых, система должна обеспечивать Единый источник истины В правильной архитектуре нет дублирования справочников. Если конструктор в PLM-системе заменил материал "Сталь 45" на "Сталь 40Х", модуль закупки узнает об этом мгновенно через общую базу данных (обычно это PostgreSQL). В Excel-таблице снабженец продолжит заказывать "Сталь 45", пока ему не позвонят.
Во-вторых, автоматизация должна строиться на триггерах Система мониторит уровень запасов не раз в месяц ("инвентаризация"), а в момент каждой транзакции. Сработал триггер min_qty — автоматически сформировался черновик для поставщика. Это работает на уровне SQL-запросов и триггеров базы данных, исключая человеческий фактор "забыл посмотреть".
В-третьих, необходима интеграция через API (XML-RPC/JSON-RPC). Если у вас крупный холдинг, и вы обязаны работать через внешние тендерные площадки, модуль не должен быть замкнутой вещью в себе. Он должен уметь "выплюнуть" спецификацию через API во внешнюю систему и забрать оттуда результаты торгов.
Важно: Правильный софт не верит поставщику на слово. Он реализует логику Тройная сверка: Заказ ↔ Приемка на склад ↔ Счет поставщика. Если склад принял 90 штук, а счет пришел на 100 — система заблокирует оплату автоматически, без участия человека.
Сравнение подходов
Разница между старым подходом и инженерно верным решением колоссальна, и она кроется в деталях процесса.
В устаревшей модели (Excel + Почта + Телефон) инициация закупки всегда реактивна. Это звонок мастера: "У нас кончается!". В современном интегрированном модуле процесс проактивен: закупка формируется авторасчетом MRP на основе плана производства, еще до того, как деталь физически исчезла с полки.
Синхронизация данных в старой схеме требует ручного переноса из Excel в учетную систему, что гарантирует ошибки ввода. Правильный подход — это единая запись в БД, где данные вводятся один раз и используются всеми департаментами.
Работа с поставщиками также меняется. Вместо десятков писем, потери истории переговоров и PDF-прайсов, вы получаете портал поставщика с историей цен в карточке товара и авто-рассылкой запросов. А контроль остатков превращается из гадания "примерно пол-ящика" в точный учет с резервированием под конкретные заказы.
Архитектура решения
Если бы я строил систему снабжения для своего завода с нуля, я бы отказался от идеи "монолита", где всё в одной куче. Но и "зоопарк" разрозненного софта — это тупик. Архитектура должна быть модульной, но с единым ядром.
В основе лежит Ядро (Core) — база данных (PostgreSQL) и движок ORM. Здесь живут справочники контрагентов и товаров. Далее идет Слой данных, где модуль склада и модуль производства пишут данные в одни и те же таблицы. Закупка просто читает потребности производства и "закрывает" их.
Над данными работает Слой логики — скрипты (например, на Python), которые просчитывают правила пополнения. Например: "Если это дорогой импортный компонент, заказываем только под подтвержденный заказ клиента . Если дешевый расходник — держим буфер на складе . И, наконец, Интерфейс — веб-клиент. Никаких "толстых клиентов", требующих установки на каждый компьютер. Снабженец должен иметь возможность утвердить закупку с планшета, находясь в командировке.
Выводы
Чудес не бывает. Установка модуля закупки не избавит вас от недобросовестных поставщиков или глобальных логистических кризисов. Но она уберет внутренний хаос.
Сухой остаток:
· Перестаньте использовать снабженцев как "секретарей по набивке накладных". Пусть они занимаются переговорами и поиском лучших цен.
· Уйдите от "реактивного" снабжения (тушим пожары) к плановому (MRP).
· Данные должны быть едиными. Если склад не видит, что заказал снабженец, а снабженец не видит, что реально лежит на полке — вы будете терять деньги.
Если вы устали от того, что производство стоит из-за мелочей, а в Excel-таблицах "черт ногу сломит" — возможно, пора пересмотреть свой подход к ИТ-архитектуре.
Есть вопросы по архитектуре? Заходите обсудить: https://fincom.tech
Или смотрите наши разборы на Rutube: https://rutube.ru/channel/32683271/