Löysin virheen ja jätin sen paikalleen

Kumpi näistä kirjoitetaan tuotteelle: Numero, jonka tiedän olevan väärä, vai numero, jota kukaan ei ole vahvistanut?

Olin viimeistelemässä yhtä tuotekorttia myyntikuntoon. Tavallista tuotetietotyötä: Tarkistetaan hinta, kustannus, saldo ja julkaisutila, täydennetään puuttuvat kohdat ja siirrytään seuraavaan. Juuri sellaista toistuvaa työtä, joka kannattaa antaa koneen hoidettavaksi.

Sitten tuli viivakoodi.

Numero, joka todistaa itse olevansa väärä

Viivakoodin viimeinen numero on tarkiste. Se lasketaan koodin muista numeroista, eikä laskuun tarvita mitään ulkopuolista lähdettä. Jos tarkiste ei täsmää, koodi ei voi olla kelvollinen viivakoodi. Sen voi todeta yhtä varmasti kuin sen, että kaksi plus kaksi ei ole viisi.

Verkkokaupassa oleva koodi ei läpäissyt tätä laskua. Tavarantoimittajan omassa kirjastossa samalle tuotteelle oli toinen koodi, ja se läpäisi laskun moitteetta. Tässä kohdassa automaatio tekee mielellään sen ilmeisen asian: Korvaa rikkinäinen arvo kelvollisella ja merkitsee rivin korjatuksi.

Jätin kentän koskematta.

Kelvollinen ei tarkoita oikeaa

Tarkisteen täsmääminen todistaa, että numero on oikein muodostettu viivakoodi. Se ei todista, että se on tämän tuotteen viivakoodi. Nämä ovat kaksi eri väitettä, ja vain ensimmäinen ratkeaa laskemalla. Toinen vaatii jonkun, joka vahvistaa että juuri tämä tuotekoodi ja juuri tämä viivakoodi kuuluvat yhteen. Sitä vahvistusta ei ollut missään.

Viivakoodi ei myöskään jää tuotekortille lepäämään. Se lähtee eteenpäin kanaviin, hintakyltteihin, varastojärjestelmiin ja kauppapaikkojen syötteisiin. Väärä koodi, joka on korvattu toisella väärällä koodilla, on huonompi tilanne kuin väärä koodi, joka on merkitty epäselväksi: Jälkimmäisen jäljet löytyvät myöhemmin, ensimmäisen eivät.

Kaksi eri lupaa, ei yksi

Tästä jäi käteen sääntö, jonka kirjoitan nykyään ohjeisiin auki. Automaatiolla on kaksi eri lupaa, eivätkä ne tarkoita samaa asiaa:

• Lupa havaita. Kone saa tarkistaa, laskea ja huomata, että arvo on rikki. Tämän luvan voi antaa laajasti, koska havainto ei muuta mitään.
• Lupa korjata. Kone saa kirjoittaa uuden arvon vanhan tilalle. Tämä lupa on kenttäkohtainen, ja se riippuu siitä, onko olemassa lähde, joka päättää kyseisen kentän sisällön.

Malli yhdistää nämä kaksi yhdeksi luvaksi, jos et erota niitä itse. Virheen löytyminen tuntuu luvalta korjata se, koska korjaaminen näyttää siltä hetkeltä katsottuna avuliaalta.

Mikä muuttui

Tunteja tämä ei säästänyt. Kyse on yhdestä kentästä yhdessä tuotteessa. Se mikä muuttui, on ettei avoin kysymys jäänyt kenenkään päähän: Tuotteen tarkistuslistalle tuli yksi kohta odottavaksi ja sen viereen syy, eli että koodin ja tuotteen yhteenkuuluvuutta ei ole vahvistettu. Kaikki muu tuotteessa meni läpi normaalisti ja lähti myyntiin.

Se on koko homman pointti. Yksi epävarma kenttä ei saa pysäyttää kokonaista ajoa, mutta se ei myöskään saa hävitä ajon mukana.

Mitä tästä kannattaa ottaa omaan työhön

Ota yksi automaatio, joka kirjoittaa johonkin oikeaan järjestelmään. Käy sen kentät läpi ja jaa ne kahteen listaan: Niihin, joita kone saa korjata itse, ja niihin, joita se saa vain merkitä tarkistettavaksi.

Useimmiten ensimmäiselle listalle päätyvät muotoasiat, kuten ylimääräiset välilyönnit, isot alkukirjaimet ja yksiköt. Niissä oikea muoto on pääteltävissä itse arvosta. Toiselle listalle päätyvät lähes aina tunnisteet, eli koodit, numerosarjat ja viittaukset toisiin järjestelmiin. Niissä kone voi kyllä tietää, että arvo on rikki, mutta ei sitä, mikä kuuluisi tilalle.

Tämä kannattaa päättää ennen ensimmäistä ajoa eikä sen jälkeen. Kirjoitin tekoälyn käyttöönotosta tarkemmin siitä, missä järjestyksessä liikkeelle kannattaa lähteä.