Planificarea în Excel nu vede toate constrângerile deodată
Un planificator uman bun optimizează intuitiv, dar nu poate ține simultan în cap zeci de constrângeri (capacitate pe linie, termen de valabilitate pe SKU, secvențierea schimbărilor de alergen, disponibilitatea materiei prime, turele de personal) la fiecare recalculare.
Rezultatul frecvent: giveaway nemăsurat (produs dat cadou peste greutatea declarată) care poate ajunge la câteva procente din producție — de regulă cel mai mare cost ascuns dintr-o linie, pentru că nimeni nu-l urmărește explicit. Un soft de planificare a producției cu AI face mai mult decât o predicție de vânzări: propune planul care respectă toate aceste reguli deodată și îl recalculează când intră o comandă nouă.
Bucla închisă de planificare
Patru pași, apasă pe fiecare. Ultimul e mereu un om.
Combină un forecast pe istoricul din ERP cu simulări de scenarii, ca să estimeze cererea cu incertitudine explicită, nu un singur număr. Date necesare: vânzări istorice pe SKU, sezonalitate, promoții.
Caută cel mai bun plan ținând cont simultan de capacitate, termen de valabilitate, secvențierea schimbărilor de alergen, materie primă și ture. Date necesare: capacități pe linie, rețete, stocuri.
Planul propus e testat pe scenarii alternative: cerere mai mare sau mai mică, o linie oprită. Date necesare: scenariile pe care planificarea le întâlnește real.
Planul ajunge la un om din planificare, care îl aprobă, ajustează sau respinge. Abia apoi ajunge înapoi în ERP.
Forecast de vânzări: scenarii, nu un singur număr
Forecastul pornește de la un model statistic clasic pe istoricul din ERP: vânzări pe fiecare SKU, sezonalitate, promoții. Peste el rulăm scenarii, de exemplu o creștere bruscă de cerere sau o comandă neașteptat de mare. Rezultatul e un interval de cerere, nu un număr pe care să-l iei de bun.
Diferența contează pentru cum se folosește rezultatul: un plan bazat pe scenarii cere ca omul să aleagă între variante, nu doar să confirme un singur număr. Forecastul nu înlocuiește judecata planificatorului: îi pune variantele pe masă, iar decizia rămâne a lui. Datele de capacitate și stoc pe care le folosește optimizatorul vin direct din ERP — cum ajung datele din ERP până la un model AI e explicat separat, cu accent pe guvernanță.
Ai planul în Excel și nu știi cât pierzi la giveaway? În 30 de minute îți spunem dacă un pilot are sens.
Un caz real: FOX, producător de mezeluri, pe SAP
FOX a lucrat întâi cu noi la un training AI pentru 28 de angajați, apoi la o platformă de redeem. Al treilea proiect împreună e un discovery pentru digitalizarea producției: un sistem de planificare care lucrează alături de SAP, nu îl înlocuiește.
În arhitectura din discovery, planificarea și controlul giveaway-ului stau într-un strat construit lângă SAP S/4HANA, legat prin OData, IDoc și evenimente. Nucleul SAP nu se atinge și rămâne actualizabil normal de furnizor. Proiectul e în discovery, așa că nu îl prezentăm ca rezultat livrat.
Optimizarea producției: un plan care respectă toate regulile
Peste simularea de cerere, un optimizator matematic (de tip MILP/CP-SAT) caută planul care respectă simultan capacitatea liniei, termenele de valabilitate, secvențierea corectă a schimbărilor de alergen, materia primă disponibilă și giveaway-ul țintă — nu doar unul sau două criterii izolate.
Acest tip de optimizare depășește ce se poate face rezonabil într-un Excel, mai ales când constrângerile se schimbă des (o comandă nouă, o linie oprită pentru mentenanță). Unul dintre obiective e giveaway-ul: cantitatea dată în plus față de gramajul declarat, ca marjă de siguranță, care în timp costă real.
Soft de planificare a producției: standard sau construit pe regulile tale
Nu orice fabrică are nevoie de un optimizator construit la comandă. Dacă Excel-ul încă ține, îți spunem asta din prima discuție.
Merge cât regulile sunt puține
O linie, puține SKU-uri, reguli care se schimbă rar. La fiecare comandă nouă planul se reface de mână, iar giveaway-ul rămâne de obicei nemăsurat.
Un produs gata făcut, configurat pe fabrică
Are sens când procesele voastre încap în modelul produsului și aveți timp de configurare. Regulile care nu încap rămân tot la planificator, iar licența e a furnizorului.
Construit pe regulile voastre, lângă ERP
Regulile se scriu explicit, inclusiv ordinea alergenilor și giveaway-ul țintă. Sistemul citește din ERP, propune planul, planificatorul îl aprobă. Codul și infrastructura rămân ale voastre.
Datele rămân la voi, nucleul ERP rămâne neatins
Accesul la ERP se verifică explicit înainte să conectăm ceva, iar la predare primești documentația: ce date citește sistemul și ce scrie înapoi.
- 01Rulează la voi sau în UE: pe serverele companiei sau pe infrastructură dedicată în UE. Alegem împreună, în discovery.
- 02Aceleași drepturi ca în ERP: sistemul citește doar datele de care are nevoie planul și respectă regulile de acces existente.
- 03Nucleul ERP nu se modifică: citim prin interfețele standard (la SAP: OData, IDoc, evenimente) și scriem înapoi doar planul aprobat.
- 04Codul e al vostru: predăm codul și documentația, fără să depindeți de o platformă închisă.
O linie, câteva SKU, date curate
Recomandăm mereu un pilot pe o singură linie sau pe câteva SKU-uri, cu date istorice curate, înainte de a extinde la toată fabrica. Calitatea datelor istorice contează la fel de mult ca algoritmul — un forecast bun pe date proaste dă un plan prost, oricât de sofisticat e optimizatorul.
Pilotul validează atât acuratețea forecast-ului, cât și, la fel de important, dacă echipa de planificare are încredere să folosească planul propus în locul procesului actual. Criteriile de acceptare se scriu înainte de pilot, iar decizia de extindere se ia pe ele, nu pe entuziasm.
De la discovery la plan aprobat de om
Echipă mică: aceiași oameni fac discovery-ul, construiesc sistemul și îl predau. Poți opri după discovery, cu raportul livrat.
Ca agenție AI din București, facem forecast și optimizare doar când datele din ERP o permit; altfel începem cu automatizări mai simple.
- 01Discovery pe o linie: date istorice disponibile, constrângeri reale, ce se pierde azi nemăsurat
- 02Construim simulatorul de cerere + optimizatorul, calibrate pe datele tale
- 03Testăm planul pe scenarii what-if înainte de a-l propune echipei de planificare
- 04Predăm sistemul, codul și documentația, cu bucla de aprobare umană integrată, nu execuție automată în ERP
Preț fix, după un discovery scurt.
- audit date + constrângeri
- hartă de oportunități
- recomandare pilot
- simulator de cerere
- optimizator sub constrângeri
- plan aprobat de om, nu automat
- extindere multi-linie
- integrare cu ERP-ul existent
- retainer mentenanță
Fiecare proiect are alt context, alte fluxuri și altă infrastructură, așa că prețul se stabilește după un discovery scurt și plătit, iar apoi nu se schimbă pe parcurs.
Ai planul în Excel și nu știi cât pierzi la giveaway? În 30 de minute îți spunem dacă un pilot are sens.
Întrebări frecvente
Ce face un soft de planificare a producției?
Îți spune ce, cât, când și pe ce linie produci. Pornește de la comenzi sau de la forecast și ține cont de capacitate, materie primă, ture și termene de valabilitate. Noi îl construim pe datele din ERP-ul pe care îl ai deja: sistemul propune planul, planificatorul îl aprobă și abia apoi planul ajunge înapoi în ERP.
Se poate face planificarea producției în Excel?
Da, cât timp ai o linie, puține produse și reguli care se schimbă rar. Devine greu când trebuie ținute deodată capacitatea, ordinea schimbărilor de alergen, termenele de valabilitate și materia primă, iar planul se reface la fiecare comandă nouă. Atunci un optimizator matematic calculează variantele, iar planificatorul o alege pe cea bună.
Ce înseamnă forecast de vânzări?
E estimarea cererii viitoare pentru fiecare produs, făcută din istoricul de vânzări, sezonalitate și promoții. În planificarea producției îl folosim ca interval de scenarii, nu ca un singur număr, pentru că planul trebuie să țină și dacă cererea iese mai mare sau mai mică.
Ce este „giveaway” într-o linie de producție și de ce contează?
Giveaway înseamnă produsul dat în plus față de greutatea declarată pe etichetă, ca marjă de siguranță, ca să nu iasă pachete sub gramaj. Poate ajunge la câteva procente din producție și de regulă nu e măsurat explicit. E adesea cea mai mare economie ascunsă într-o linie fără control digital al greutății.
Cât costă un sistem de forecast și optimizare a producției?
Lucrăm cu preț fix, stabilit după un discovery scurt și plătit, care apoi nu se mai schimbă pe parcurs. Prețul depinde de câte linii și SKU-uri intră în plan, de cât de curate sunt datele istorice, de câte reguli are linia și de cum se leagă sistemul de ERP. Poți opri după discovery, cu raportul livrat. Nu publicăm cifre din proiectele clienților.
Sistemul de optimizare a producției ia decizii automat?
Nu. Propune un plan, testat pe scenarii what-if, dar decizia de a-l aplica rămâne a unui om din planificare. Sistemul e un instrument de decizie, nu un pilot automat care scrie direct în ERP fără verificare.
Ce date sunt necesare pentru a porni un pilot de optimizare a producției?
Istoricul de vânzări pe SKU, cât mai curat; constrângerile reale ale liniei (capacitate, termene de valabilitate, reguli de schimbare a alergenilor); disponibilitatea materiei prime și a turelor. Calitatea acestor date contează la fel de mult ca algoritmul.
Funcționează cu SAP sau cu alt ERP?
Da. La SAP construim lângă nucleu, pe SAP BTP, prin OData, IDoc sau evenimente, fără să modificăm nucleul. La SAGA, care nu are API pe desktop, citim direct baza de date, fără să scriem în ea. Pentru alt ERP, discovery-ul arată exact ce date ies din sistem și cum se conectează.
Ce se întâmplă după predare?
Cererea și rețetele se schimbă, așa că modelul se recalibrează periodic pe datele noi. Mentenanța și recalibrarea intră în programul complet, iar codul și documentația rămân la voi.
Hai să vedem ce se poate automatiza la tine.
O sesiune gratuită de 30 de minute: îți spunem ce se poate automatiza, cât durează și cât costă, cu preț fix după discovery.
Răspundem în aceeași zi lucrătoare.