Automaatio2 min luettavaa

Kysyin järjestelmältä, miten se on aiemmin epäonnistunut

Automatisoitu tuonti läpäisi kaikki muototarkistukset ja kantoi silti tuhatkertaista kustannusta. Virhe, joka ei kaada ajoa, löytyy vain säännöllä, jonka kirjoitat itse.

Kysyin järjestelmältä, miten se on aiemmin epäonnistunut

Tuontitiedosto oli valmis ja näytti hyvältä. Ennen kuin ajoin sen sisään, tein jotain, mitä en ollut aiemmin tullut ajatelleeksi: Kysyin järjestelmältä itseltään, miten se on ennen epäonnistunut.

Massatuonti on niitä tehtäviä, jotka toistuvat joka kampanjassa ja joissa kukaan ei ehdi oppia mitään. Taulukosta ajetaan rivit verkkokauppaan, CRM:ään tai toiminnanohjaukseen. Tiedosto vilkaistaan läpi, ajo käynnistetään, ja virheet selviävät vasta jälkikäteen raportista. Seuraavalla kerralla sama tanssi alusta. Rakensin tiedoston tällä kertaa tekoälyn kanssa, mikä teki tuottamisesta nopeaa mutta ei yhtään sen turvallisempaa. Nopea väärä tiedosto on vain nopeammin väärässä.

Virheloki on tarkistuslista, jota kukaan ei lue

Tuontityökalussa oli tallessa yli kaksisataa aiemmin ajettua työtä, jokainen omine virheilmoituksineen. Luin ne läpi ja laskin, mitkä virheet ovat oikeasti toistuneet juuri tässä ympäristössä. Kolme toistui selvästi muita useammin.

  • Uutta tuotetta ei voi luoda ilman otsikkoa. Ylivoimaisesti yleisin. Yhdessä aiemmassa ajossa 25 riviä kaatui pelkästään tähän.
  • Hinta ei kelvannut luvuksi. Yksi ylimääräinen merkki solussa riittää.
  • Varianttisarakkeen nimi vaihteli riviltä toiselle. Yksi tuote hajoaa hiljaa moneksi.

Sen jälkeen tarkistuslista ei ollut enää yleinen ohje. Se oli tämän ympäristön lista: Otsikko jokaisella uudella rivillä, jokainen hinta kelvollinen luku, optiosarakkeet yhtenäiset koko tiedostossa. Kolme tarkistusta, jotka ajetaan ennen kuin mitään lähtee liikkeelle.

Sitten tuli virhe, joka ei kaada mitään

Tarkistukset menivät läpi. Ja silti tiedostossa oli virhe, jota yksikään niistä ei olisi napannut.

Kustannussarakkeessa luki yhdellä rivillä 460 + 391. Joku oli laskenut kahden osan hinnan yhteen ja jättänyt laskutoimituksen soluun näkyviin. Jäsennin siivosi plussan pois muun roskan mukana, ja luvut liimautuivat yhteen. Kustannukseksi tuli 460 391 euroa, kun oikea luku oli 851 euroa.

Se olisi mennyt läpi. Muoto oli moitteeton: Numero, ei kirjaimia, ei tyhjää solua. Tuonti ei olisi kaatunut, mikään ei olisi valittanut, ja luku olisi paljastunut vasta katelaskennassa, aivan liian myöhään.

Korjaus ei ollut parempi jäsennin. Korjaus oli sääntö, joka on ihmiselle itsestään selvä ja koneelle täysin näkymätön: Kustannus ei voi olla suurempi kuin myyntihinta. Se on ainoa tarkistus, joka paljastaa tämän, ilman että joku laskee rivit käsin.

Kaksi kysymystä ennen seuraavaa ajoa

Mitä lokit tietävät, mitä sinä et? Melkein jokainen järjestelmä, joka ajaa tuonteja tai integraatioita, tallettaa historian omista epäonnistumisistaan. Sitähän ei lue kukaan, koska yksittäinen virhe korjataan silloin, kun se sattuu, ja unohdetaan saman tien. Kun ne lukee kerralla ja laskee toistumat, syntyy lista, joka on arvokkaampi kuin mikään yleinen ohje, koska se kertoo, miten juuri sinun ympäristösi hajoaa. Sama pätee siihen, mitä kielimallille kannattaa antaa taustaksi. Virhehistoria on parasta kontekstia, mitä mallille voi ojentaa, koska se on mitattua eikä oletettua.

Mikä luku ei voi koskaan olla suurempi kuin toinen? Kirjoita kaksi tai kolme tällaista sääntöä ylös omasta datastasi. Kustannus ei ylitä hintaa. Alennus ei ylitä sataa prosenttia. Toimituspäivä ei ole ennen tilauspäivää. Nämä eivät ole muototarkistuksia vaan merkityksen tarkistuksia, ja juuri ne jäävät tekemättä, jos niitä ei sanota ääneen. Malli tarkistaa mielellään muodon, koska muoto on sääntö, jonka se näkee. Merkityksen se olettaa.

Muoto kertoo, kaatuuko ajo. Merkitys kertoo, oliko lopputulos oikein. Vain jälkimmäinen näkyy asiakkaalle.