Tankeledere
AI-beredskap starter med pålitelige produktdata

Produsenter investerer tungt i AI, initiativer for digitale tråder, automatisering og modernisering av virksomheten for å øke produktiviteten og forbedre beslutningstakingen. Mye av diskusjonen dreier seg om AI-modeller, infrastruktur og integrering. Men mange organisasjoner overser en grunnleggende forutsetning for dette arbeidet: tillit til de underliggende produktdataene og forretningsreglene som styrer operative beslutninger.
Utfordringen handler ikke bare om å koble sammen systemer, men også om å sikre at produktdefinisjonene, konfigurasjonslogikken og forretningsreglene som flyter mellom dem, forblir nøyaktige. AI-beredskap starter med tillit til virksomhetens produktdata. Digital transformasjon handler ikke bare om å koble sammen systemer, men om å bevare meningsinnholdet og nøyaktigheten i informasjonen som flyttes mellom dem.
Når virksomheter moderniserer systemene sine og kobler sammen produktlivssyklusstyring (PLM), virksomhetsressursplanlegging (ERP), konfigurering, prissetting og tilbud (CPQ) samt serviceplattformer, kan uoverensstemmelser i konfigurasjonslogikken ubemerket svekke nøyaktigheten i etterfølgende prosesser og effektiviteten til AI-drevne anbefalinger. Uten pålitelig konfigurasjonslogikk fremskynder AI feil i stedet for å forbedre beslutningene.
Hvorfor produktkonfigurering er det skjulte fundamentet
Dagens produsenter er i stadig større grad avhengige av et sammenkoblet økosystem som omfatter PLM, ERP, CPQ, produksjon og service. Produktkonfigurering fungerer som bindeleddet som omsetter ingeniørenes intensjoner til krav for produksjon, salg, prissetting og service.
Hvert system har sitt eget syn på produktet: PLM trenger teknisk informasjon og designinformasjon, produksjonen må vite hva som kan produseres, og CPQ trenger regler for salg og markeder. Konfigureringen knytter disse perspektivene sammen. Når den underliggende logikken endres eller blir inkonsistent, brytes den digitale tråden, uansett hvor godt systemene er integrert.
Eldre regler skaper usynlig risiko
Produktkonfigurasjonsmodeller gjenspeiler ofte flere tiår med opparbeidet kunnskap som er lagt til over tid: regulatoriske krav, produksjonsbegrensninger, markedsspesifikke unntak og prislogikk. De som opprinnelig bygde disse modellene, har ofte sluttet i selskapet, og organisasjonene sitter igjen med regler som ingen lenger forstår fullt ut.
Prosjekter for modernisering av virksomheten, for eksempel migreringer til SAP S/4HANA, legger vanligvis vekt på applikasjoner, infrastruktur og tilpasset kode, mens konfigurasjonslogikken behandles som et underordnet spørsmål. Resultatet er en oversett risiko: Systemer kan migreres uten problemer, samtidig som konfigurasjonsatferden endres på subtile måter som er vanskelige å oppdage med tradisjonell testing.
Migreringer til S/4HANA illustrerer problemet godt, fordi en ny konfigurasjonsmotor kan tolke veletablerte regler annerledes selv om syntaksen er identisk. Forskjeller i hvordan standardverdier brukes, rekkefølgen begrensninger vurderes i, og hvordan konflikter mellom regler løses, kan alle endre hvilke kombinasjoner en modell godtar, uten at en eneste linje i selve reglene er skrevet om.
Dette er ikke bare forvirrende; dårlig konfigurasjonslogikk blir et forretningsproblem. Det finnes to typer feil, og begge er kostbare:
- En konfigurasjon gjør det mulig for et selskap å selge noe det faktisk ikke kan produsere, noe som fører til omarbeid, brudd på forpliktelser og svekkede kunderelasjoner.
- En konfigurasjon hindrer feilaktig et selskap i å selge noe det kunne ha produsert, noe som fører til tapte inntekter og potensielt tap av konkurransefortrinn.
Den første typen feil blir før eller siden synlig på fabrikkgulvet. Den andre forblir skjult; ingenting i ordreboken registrerer et salg som konfiguratoren aldri tillot.
Verifisering blir en strategisk kapasitet
Tradisjonell validering av migreringer bygger i stor grad på manuell testing og stikkprøver, som ikke med rimelighet kan vurdere det enorme antallet mulige produktkombinasjoner. Verifisering av konfigurasjoner flytter oppmerksomheten fra om dataene ble overført uten feil, til om forretningsintensjonen fortsatt er ivaretatt.
Jeg har sett produsenter sette sammen team som utelukkende skal bekrefte at en migrert modell fortsatt gir de samme gyldige konfigurasjonene og avviser de samme ugyldige, rett og slett fordi de ikke har noen annen måte å vite det på. Det er detaljert, kostbart og tidkrevende arbeid, og selv da undersøkes bare et utvalg av problemet.
Det er verdt å være presis om størrelsesordenen. En modell med 30 variabler og fem valg for hver av dem åpner for omtrent 10²¹ kombinasjoner, langt flere enn det anslåtte antallet sandkorn på jorden, og virkelige industrimodeller er betydelig større. Uansett hvor mange som klikker seg gjennom et brukergrensesnitt, kan de ikke dekke hele dette mulighetsrommet; det tillater rett og slett ikke regnestykket.
Det er derfor formelle metoder er viktige. I stedet for å prøve ut kombinasjoner kan en konfigurasjonsmodell kompileres til en kanonisk logisk form: en kompakt matematisk representasjon av alle gyldige kombinasjoner som reglene tillater. To modeller som er kompilert på denne måten, kan sammenlignes direkte. Enten beskriver de nøyaktig det samme settet med gyldige produkter, eller så viser sammenligningen presist hvor modellene avviker, med konkrete eksempler på kombinasjoner den ene godtar og den andre avviser. Den samme representasjonen gjør kjøretidsatferd til et oppslag i stedet for et søk. Dermed kan en konfigurator vise bare gyldige alternativer og aldri føre brukeren inn i en blindvei. Det viser seg at verifisering og korrekthet ved kjøring er den samme funksjonen, sett fra to ulike vinkler.
Organisasjoner trenger i stadig større grad denne typen formell sammenligning før de legger AI eller automatisering oppå produktreglene sine. Målet er ikke bare å redusere risikoen ved migrering, men også å sikre kontinuitet i driften innen konstruksjon, produksjon, salg og service, og å kunne teste, feilsøke og verifisere konfigurasjonsmodeller før lansering, ikke etterpå.
AI hører hjemme oppå en deterministisk motor, ikke i stedet for den
Ingenting av dette krever at AI erstatter konfigurasjonsmotoren. Den mer bærekraftige tilnærmingen er det motsatte: AI fungerer som et mellomledd mellom brukeren og en grundig konfigurasjonsmotor og gir en mer naturlig opplevelse med veiledet salg eller anbefalinger, samtidig som de underliggende reglene forblir deterministiske. Språkmodellen tolker hva kunden ber om, mens motoren avgjør hva som faktisk kan bygges. Denne arbeidsdelingen sørger for at den delen av prosessen som må være beviselig korrekt, ikke overlates til et system som av natur er probabilistisk.
Pålitelig data er det som får AI-programmer til å lykkes
AI kan bare gi anbefalinger så pålitelig som produktkunnskapen den får tilgang til. Uverifiserte konfigurasjonsdata får AI til å spre feil i stor skala i virksomheten, noe som svekker salgsveiledningen, produksjonsbeslutningene og forpliktelsene overfor kundene.
Produsenter bør se på dataverifisering som en forutsetning for å ta i bruk AI, på samme måte som programvaretesting ble en forutsetning for applikasjonsutvikling. Etter hvert som den digitale omstillingen fortsetter, vil konkurransefortrinn i økende grad komme av å ta i bruk AI på et grunnlag av pålitelig produktinnsikt, ikke av å være først ute med AI.












