Когато лотът носи дизайна: архитектура за параметрично производство в Odoo

Представете си един типичен производител. Продуктът е един — наречете го "артикул X" — но всяка поръчка е различна. Различен размер. Различен опаковъчен материал. Различен етикет в зависимост от канала за продажба. Различен набор от опции в зависимост от изискванията на клиента. Една седмица поръчката е от голяма търговска верига под тяхната собствена марка. Следващата седмица е от друг дистрибутор — същият артикул, но с различни етикети за различни региони.

Може да е продукт от хранително-вкусовата промишленост. Може да е строителен елемент, конфигуриран по размер и клас. Може да е защитен продукт с класфикационен рейтинг. Може да е индустриална опаковка. Може да е автоматизирана компонента, която се монтира в по-голяма система. Индустрията е различна всеки път. Но проблемът е един и същ.

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

Стандартните ERP системи се спъват в това по предсказуеми начини.

Как обикновено се развива

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

Резултатите, които виждам при клиентите:

експлозия на SKU.Продукт с няколко опционални пакета, няколко класификации, няколко покрития и непрекъснати размерни диапазони генерира десетки хиляди SKU. Каталогът на продуктите става неизползваем. Складовият персонал губи доверие в системата. Търговците търсят продукти само по имена, които те знаят.

Разпространение на рецепти.Всеки вариант изисква собствена спецификация на материалите (BoM). Поддръжката става работа на пълен работен ден. Една промяна на материала изисква редактиране на стотици BoM. В действителност това никога не се прави напълно — някои BoM остават остарели, други се актуализират, никой не знае кои са актуални.

Проследимостта се нарушава.Номерът на партидата на готовия продукт ви казвакогае произведен, но некоя конфигурацияпредставлява. Искате да отзовете конкретен вариант? Успех.

Планирането лъже.MRP вижда 50 поръчки за даден продукт и планира съответно — но тези 50 поръчки може да изискват 50 напълно различни комплекта компоненти. Изискванията, които MRP изчислява, са фикция.

Индустрията работи около това от десетилетия: персонализирани конфигуратори, прикрепени към ERP, правила, написани на ексцентрични собствени езици, Excel таблици, които никога не съвпадат с действителното производство, и дълги технически спецификации, прикрепени като PDF файлове към всяка поръчка.

Нито едно от тези решения не решава архитектурния проблем. Те само го маскират.

Различна архитектура

През последните две години, работейки по реални производствени случаи в различни производствени архетипи — процесно производство, масово производство, инженерно производство по поръчка и конфигуриране по поръчка — съм изградил това, което вярвам, че е по-чиста основа. Проектът е набор от модули на Odoo под лиценз AGPL-3.

Има три основни идеи, всяка от които се различава от начина, по който повечето ERP системи обработват конфигурируеми продукти.

Идея 1: Партидата носи дизайна

В повечето ERP системи номерът на партидата е просто идентификатор — печат на завършеното изделие, който казва "Бях произведен в тази партида на тази дата." Това е метаданнизапродукта.

В архитектурата, която описвам, номерът на партидатаеконфигурацията. Записът на партидата носи всеки параметър, който определя този конкретен физически обект: размери, избор на материали, избрани опции, класifikционни оценки, списък с правила, които са били приложени при създаването му. Когато извикате партида, не извиквате партида — извиквате конкретна спецификация на конфигуриран продукт.

Това може да звучи като малка разлика. Но не е. То означава следното:

• Спирате да създавате вариант на продукта за всяка възможна конфигурация.Един шаблон на продукт, много партиди, всяка с уникален отпечатък.
• Проследимостта става значима. Искането за дефект на конкретна партида ви казва точно кои размери, материали и правила са произвели това изделие. Не просто "някакъв артикул, произведен през април."
• Контролът на качеството има нещо конкретно за валидиране. Не проверявате "дали сме изградили артикула правилно" — проверявате "дали сме изградилитази конкретна конфигурацияправилно."
• Услугата и гаранцията стават изпълними. Клиент съобщава за проблем години по-късно. Вие разглеждате партидата, виждате точната спецификация, купувате съвместими резервни части.

Технически, реализацията живее в модул, който разширява стандарта.stock.lotмодел с поле за дефиниция на параметри и обект Properties, който съхранява всички параметри като JSON. Формулярът на партидата получава раздел "Дизайнерски параметри" и параметрите стават видими, търсими и достъпни за всяко изчисление по-надолу по веригата.

Идея 2: Списъкът на материалите е планова гледна точка, а не производствена рецепта

Стандартните ERP системи третират списъка на материалите (BoM) като източник на истина за това, от какво е направен продуктът. Всяка производствена поръчка или използва BoM директно, или създава специфичен за варианта BoM за тази поръчка.

В новата архитектура BoM еобщ планов шаблон. Той отговаря на въпроси като "приблизително колко суровини ни трябват за един артикул от този клас?" — достатъчно добре за снабдяване, грубо планиране на капацитета и изчисление на цената при офериране.

Действителната производствена рецепта — точният списък на компонентите, точната последователност на операциите, точните количества — се генерира в момента, в който се създава производствената поръчка, произтичайки от конфигурацията на партидата чрез верига от решения.MO е гледната точка за изпълнение. BoM е плановата гледна точка.Не е необходимо да съвпадат перфектно, а настояването те да съвпадат е това, което произвежда разширяването на BoM.

Тази разделение отразява директно как функционира реалното производство:

• Снабдяването планира месеци напред спрямо приблизителни изисквания.
• Производственият етаж изпълнява спрямо точни спецификации, известни само когато поръчката влезе в графика.
• Опитите да се направят тези две гледни точки идентични са борба с физиката.

Техническото наименование за това в кода еO-variant pattern(плейсхолдър с нулев коефициент). Всеки ред на BoM имаcoeff_default=0.0— означава "това е планирано място, а не изпълнима количествена стойност" — плюс правило, което, по време на изпълнение, извлича реалния коефициент от матричния двигател.

Идея 3: Правилата за вземане на решения живеят в реален двигател

Всеки производител, с когото съм работил, има някаква версия на същия документ: голям Excel файл, тетрадка с пръстен или уеб страница, озаглавена нещо като "правила за конфигурация" или "инженерни стандарти." Той описва логиката, която определя как се конфигурира продукт, какви материали влизат в кои варианти, какви операции са необходими за кои опции.

В повечето реализации на ERP този документ става персонализиран Python код, разпръснат из изчислени полета, ограничения и обработчици на промени. Работи — докато не работи. Когато правилата се променят (а те винаги се променят), разходите за модификация са високи, рискът от счупване на нещо е реален и никой, освен оригиналния разработчик, не разбира какво се случва.

Архитектурата, която описвам, екстернализира тези правила в единреален двигател за вземане на решения— по-специално, DMN (Модел за вземане на решения и Нотация), отворен стандарт за бизнес правила, изпълняван от отворен код двигател. Правилата са написани като таблици за вземане на решения, които мениджър по производството или инженер може да прочете, разбере и модифицира. Те са версирани, тестируеми и преносими.

Верига за вземане на решения имачетири нива:

T0 — Валидност.Тази комбинация от параметри физически възможна ли е? Правилата T0 казват "да" или "не" преди някой да се ангажира с оферта. Политика на удар:събиране. Изходът е списък с съобщения с нива на сериозност (грешка/предупреждение/информация) — грешките блокират, предупрежденията информират.

T1 — Произход.При зададени валидни параметри, какви производни стойности следват? Ако клиентът е избрал конкретна класификация, следва, че има конкретна минимална дебелина, конкретен брой точки за закрепване, конкретни структурни изисквания. Политика на действие:първо. Изходът е речник на производни стойности, добавени към контекста.

T2 — Избор на компоненти.При зададени параметри и производни стойности, какви конкретни компоненти и подасембли са необходими за този продукт? Политика на действие:първо. Изходът е речник на коефициенти за всяка линия от спецификацията на материалите.

T3 — Последователност на операциите.При зададения списък с компоненти, кои операции, в какъв ред, в кои работни центрове, с какви времена за настройка, произвеждат този продукт? Политика на действие:събиране. Изходът е списък на работни поръчки.

Всяко ниво е таблица за решения. Всяка таблица за решения е четима за хора. Всяко ниво може да бъде модифицирано без да се засяга изходният код на ERP. Изходът на едно ниво става вход за следващото.

Как това всъщност работи в производството

Концепциите са евтини. Ето конкретния работен процес:

Офертата пристига.Конфигураторът за продажби показва на клиента (или на търговеца) форма: размери, класификация, опционални пакети, покрития. Докато формата се попълва, правилата T0 се изпълняват в реално време, предотвратявайки невалидни комбинации. Правилата T1 се изпълняват, показвайки производни стойности. Общата цена на офертата се изчислява от списъка с компоненти T2 спрямо текущите цени.

За интерфейса за продажби има отделен модул, който реализира 3D преглед на OWL с Three.js. Това е визуализация в реално време, използваща GLB модели или SVG профили, екструдирани динамично. Клиентът вижда какво поръчва, преди да го поръча.

Офертата става поръчка.Редът на поръчката се отнася до общ продукт и носи конфигурацията като структурирани атрибути. Не се създава нов SKU. Не се създава нов BoM.

Планове за доставки.MRP работи с общия BoM плюс атрибути, за да оцени търсенето на суровини. Артикулите с дълго време за доставка се поръчват на базата на типичното потребление, а не на точното потребление.

Производствената поръчка е създадена.В този момент — когато MO е генерирана — цялата верига T0-T3 се изпълнява спрямо конфигурацията и създава:

• Номер на партида, носещ пълния отпечатък на конфигурацията.
• Списък на компонентите, специфичен за производството (изходът на T2).
• Последователност на операциите, специфична за производството (изходът на T3).
• Резервиране на точни компоненти за тази партида.

Компонентите преминават през фабриката.Всеки изразходван компонент е резервиран за конкретната завършена партида. Това е ролята на механизма за принудително резервиране на партиди — той разпространява етикетирани партиди компоненти през цялата верига за доставки, така че конкретният продукт получава точно своите компоненти, а не "съвместими" от наличност. Това е отделна техническа статия, но за производствения мениджър наблюдаваното поведение е просто: "системата избира правилните компоненти за тази поръчка, точка."

Продуктът е произведен.MO изпълнява по своята специфична рецепта. Контролите за качество се отнасят до спецификацията на партидата. Отклоненията се записват срещу партидата.

Партидата е изпратена.Записът за проследимост сега съдържа всичко: какво е поръчано, кои параметри са избрани, кои правила са задействани, кои компоненти са консумирани, кой е работил по него, какви са били резултатите от качеството. Години по-късно този запис все още отговаря на всеки въпрос, който някой задава за този конкретен физически продукт.

Архитектурата в практика

Системата вече е валидирана на реални производствени случаи в различни производствени архетипи:

Производство по процес.Типично за индустрии, където основният продукт е резултат от рецепта, но опаковките, етикетите и регулаторните изисквания варират в зависимост от пазара и канала. Верига T0-T3 обработва регулаторни ограничения, преобразувания на единици за измерване и правила за съвместно опаковане в същата партида.

Масово производство.Типично за индустриални продукти с непрекъсната параметризация (геометрия, материали, смеси). Нивото T2 изчислява консумацията на суровини от геометрични свойства — пример за правила, които работят в непрекъснато параметрично пространство, а не срещу дискретни списъци с опции.

Проектиране по поръчка.Типично за индустрии, където всяка поръчка е индивидуална и определена от класова оценка, персонализирани размери и пакети с опции. Нивото T0 налага регулаторни ограничения. Нивото T1 извежда структурни изисквания от класификацията. Нивото T2 избира компоненти, подсилвания и механизми.

Конфигуриране по поръчка.Типично за индустрии, където изборът на един компонент определя изискванията на другите. Пример: товарната характеристика определя структурния профил; профилът плюс размерите определят конкретна маса; масата определя избора на задвижващ компонент. Това е най-физически интензивният архетип и стрес-тества способността на двигателя за вземане на решения да се справя с чисто многостепенни производни.

Различни индустрии. Различни конфигурационни модели. Една архитектура.

Под капака

Това, което описах досега, е функционалността. Под него има техническа структура — модули на Odoo, организирани в четири слоя:

Фондация.Универсални определения на параметри, профили (със SVG рендер и JSON схеми), прикачване на параметри към партиди, групиране на дизайнерски активи (3D модели, SVG профили, изображения) по тип.

Формули.Повторно използваеми шаблони на формули за BoM-ред с валидация на синтаксиса. Изскачащ редактор с кодов виджет и панел с променливи за производствения инженер. Интеграция с AI асистент, който генерира формули от описание на домейн — тема за отделна статия.

Двигател.Ядрото — T0/T1/T2/T3 DMN правила, O-вариантен шаблон, автоматичен избор на правилния продукт от много възможности в един шаблон, дадени стойности на атрибутите, детски партиди (параметрите се предават на всяка полуготова партида), логика на MTO-стоп (ако партида с съвпадаща конфигурация вече съществува на склад, MO не се създава отново).

UI за продажби.3D предварителен преглед в реално време, интегриран в формуляра за оферта.

Индустриални модули.Специализации за всеки производствен архетип — всеки с неговите собствени T0/T1/T2/T3 JSON дефиниции, специфични за домейна параметри и конкретни продуктови шаблони.

Всички модули са AGPL-3 и работят на Odoo 18 и 19.

Какво е това и какво не е

Това не е пренаписване на ERP. Това е набор от Odoo модули — разширения на съществуващите приложения за производство, инвентар и доставки — които въвеждат модела на партида-като-превозвач, DMN веригата за решения и поддържащата инфраструктура за принудителна резервация на компоненти.

Не е магия. Ако логиката на вашата конфигурация не е добре разбрана, изнасянето ѝ в DMN правила няма да я поправи. Това, което ще направи, е да наложи яснота: не можете да напишете таблица за решения, която не разбирате. Това звучи строго. Всъщност е основната полза. Няколко производители вече са забелязали, че процесът на моделиране на техните правила в DMN е разкрил неясноти и противоречия в собствените им вътрешни стандарти — неясноти, които причиняваха проблеми с качеството в продължение на години.

Не е за всеки производител. Ако произвеждате един продукт в една конфигурация, не ви е нужно това. Ако вашата конфигурируемост е ограничена до малко на брой дискретни опции и не се разпространява през BoM, стандартните варианти на Odoo вероятно са достатъчни. Тази архитектура се изплаща, когато конфигурируемостта ецентралното предизвикателствона вашата работа — когато отговорът на "как изглежда вашият продукт" е наистина различен за всеки клиент.

Какво следва

Репозиториумът ще бъде отворен публично в следващите седмици, след като първата вълна от реални внедрения се стабилизира. Ако сте производител, чиято логика на конфигурация разяжда вашия ERP, или производствен мениджър, който наблюдава разходите за поддръжка на BoM, които нямат смисъл, бих искал да говоря с вас.

Също така предстоят: няколко технически статии за отделни аспекти на архитектурата — механизма за принудително резервиране на партиди в цялата верига на доставки, генериране на формули за BoM с помощта на ИИ чрез терминала MCP и инженерните спецификации около избраните технологии.