Pregătirea pentru IA începe cu date de produs de încredere

Producătorii investesc masiv în IA, inițiative privind firul digital, automatizare și modernizarea întreprinderilor, pentru a îmbunătăți productivitatea și procesul decizional. O mare parte a discuțiilor se concentrează asupra modelelor de IA, infrastructurii și integrării. Însă multe organizații trec cu vederea o condiție fundamentală pentru aceste eforturi: încrederea în datele de produs și regulile de afaceri care stau la baza deciziilor operaționale.

Provocarea nu constă doar în conectarea sistemelor, ci și în asigurarea acurateței definițiilor produselor, a logicii de configurare și a regulilor de afaceri care circulă între acestea. Pregătirea pentru IA începe cu încrederea în datele despre produse ale întreprinderii. Transformarea digitală nu înseamnă doar conectarea sistemelor, ci și păstrarea sensului și acurateței informațiilor care circulă între ele.

Pe măsură ce companiile își modernizează sistemele întreprinderii și conectează platformele de gestionare a ciclului de viață al produselor (PLM), de planificare a resurselor întreprinderii (ERP), de configurare, stabilire a prețurilor și creare a ofertelor (CPQ), precum și platformele de service, inconsecvențele din logica de configurare pot submina pe nesimțite acuratețea proceselor din aval și eficiența recomandărilor bazate pe IA. Fără o logică de configurare de încredere, IA accelerează greșelile în loc să îmbunătățească deciziile.

De ce configurarea produselor este fundația ascunsă

Producătorii de astăzi se bazează tot mai mult pe un ecosistem interconectat, care cuprinde PLM, ERP, CPQ, producție și service. Configurarea produselor este țesătura de legătură care transpune intenția de proiectare în cerințe de producție, vânzări, stabilire a prețurilor și service.

Fiecare sistem are o perspectivă diferită asupra produsului: PLM are nevoie de informațiile tehnice și de proiectare, producția trebuie să știe ce poate fi fabricat, iar CPQ are nevoie de regulile de vânzare și de piață. Configurarea este cea care conectează aceste perspective. Când logica de bază se schimbă sau devine inconsecventă, firul digital se întrerupe, indiferent cât de bine sunt integrate sistemele.

Regulile vechi introduc riscuri invizibile

Modelele de configurare a produselor reunesc adesea cunoștințe acumulate de-a lungul mai multor decenii, adăugate treptat: cerințe de reglementare, constrângeri de producție, excepții specifice piețelor și logică de stabilire a prețurilor. Cei care au creat inițial aceste modele au părăsit adesea compania, lăsând organizațiile cu reguli pe care nimeni nu le mai înțelege pe deplin.

Proiectele de modernizare a întreprinderilor, precum migrările la SAP S/4HANA, pun de obicei accentul pe aplicații, infrastructură și cod personalizat, tratând logica de configurare ca pe un aspect secundar. Rezultatul este un risc trecut cu vederea: sistemele pot fi migrate cu succes, în timp ce comportamentul configurărilor se schimbă subtil, într-un mod greu de detectat prin testarea tradițională.

Migrările la S/4HANA ilustrează bine problema, deoarece un nou motor de configurare poate interpreta diferit reguli folosite de mult timp, chiar dacă sintaxa este identică. Diferențele în modul de aplicare a valorilor implicite, în ordinea evaluării constrângerilor și în felul în care sunt soluționate conflictele dintre reguli pot schimba combinațiile acceptate de un model, fără să fie rescrisă nicio linie a regulilor în sine.

Nu este vorba doar despre confuzie; logica de configurare defectuoasă devine o problemă de afaceri. Există două moduri în care pot apărea aceste eșecuri, iar ambele sunt costisitoare:

• O configurare permite unei companii să vândă ceva ce nu poate fabrica, ceea ce duce la refacerea muncii, nerespectarea angajamentelor și deteriorarea relațiilor cu clienții.
• O configurare împiedică în mod eronat o companie să vândă ceva ce ar putea fabrica, ceea ce duce la pierderi de venituri și, eventual, la pierderea avantajului competitiv.

Primul tip de eșec ajunge, în cele din urmă, să se manifeste în fabricație. Al doilea trece neobservat: nimic din registrul comenzilor nu consemnează o vânzare pe care configuratorul nu a permis-o.

Verificarea devine o capabilitate strategică

Validarea tradițională a migrărilor se bazează în mare măsură pe testare manuală și verificări punctuale, care nu pot evalua în mod realist numărul enorm de combinații posibile de produse. Verificarea configurărilor mută accentul de la întrebarea dacă datele au fost transferate cu succes la întrebarea dacă intenția de afaceri a rămas intactă.

Am văzut producători care au format echipe a căror unică responsabilitate este să confirme că un model migrat generează în continuare aceleași configurații valide și respinge aceleași configurații invalide, pur și simplu pentru că nu au altă modalitate de a afla. Este o muncă migăloasă, costisitoare și consumatoare de timp și, chiar și așa, acoperă doar un eșantion al problemei.

Merită să fim preciși în privința amplorii problemei. Un model cu 30 de variabile și cinci opțiuni pentru fiecare permite aproximativ 10²¹ de combinații, cu mult mai multe decât numărul estimat de grăunțe de nisip de pe Pământ, iar modelele industriale reale sunt considerabil mai mari. Oricât de mulți oameni ar parcurge interfața utilizatorului prin clicuri, nu ar putea acoperi toate aceste posibilități; aritmetica nu permite acest lucru.

De aceea sunt importante metodele formale. În loc să eșantioneze combinații, un model de configurare poate fi compilat într-o formă logică canonică: o reprezentare matematică compactă a tuturor combinațiilor valide permise de regulile sale. Două modele compilate astfel pot fi comparate direct. Fie descriu exact aceeași mulțime de produse valide, fie comparația indică precis unde diferă, oferind exemple concrete de combinații pe care unul le acceptă, iar celălalt le respinge. Aceeași reprezentare transformă comportamentul în timpul execuției într-o căutare directă, nu într-o căutare exploratorie, ceea ce îi permite configuratorului să afișeze doar opțiuni valide și să nu conducă niciodată utilizatorul într-un impas. Verificarea și corectitudinea în timpul execuției se dovedesc a fi aceeași capacitate, abordată din două direcții.

Organizațiile au tot mai multă nevoie de acest tip de comparație formală înainte de a adăuga IA sau automatizări peste regulile produselor lor. Obiectivul nu este doar reducerea riscului migrării, ci și menținerea continuității operaționale în inginerie, producție, vânzări și service, precum și dobândirea capacității de a testa, depana și verifica modelele de configurare înainte de lansare, nu după aceasta.

IA trebuie să se bazeze pe un motor determinist, nu să îl înlocuiască

Nimic din toate acestea nu presupune ca IA să înlocuiască motorul de configurare. Modelul mai durabil este chiar opusul: IA se interpune între utilizator și un motor de configurare riguros, oferind o experiență mai naturală de vânzare ghidată sau de recomandare, în timp ce regulile de la bază rămân deterministe. Modelul lingvistic interpretează ce solicită clientul, iar motorul decide ce se poate fabrica efectiv. Această împărțire a responsabilităților menține acea parte a procesului care trebuie să fie demonstrabil corectă în afara controlului unui sistem care, prin definiție, funcționează probabilistic.

Datele de încredere sunt esențiale pentru succesul programelor de IA

IA poate genera recomandări doar în măsura în care informațiile despre produse pe care le primește sunt fiabile. Datele de configurare neverificate determină IA să propage erori la scara întregii întreprinderi, subminând îndrumarea oferită în vânzări, deciziile de producție și angajamentele față de clienți.

Producătorii ar trebui să considere verificarea datelor o condiție prealabilă implementării IA, la fel cum testarea software-ului a devenit o condiție prealabilă dezvoltării aplicațiilor. Pe măsură ce transformarea digitală continuă, avantajul competitiv va proveni tot mai mult nu din adoptarea primilor a IA, ci din implementarea IA pe o bază solidă de informații fiabile despre produse.