--- title: "Agentti kirjoittaa ERP:hen: lukemisen ja kirjoittamisen raja" url: "https://hurukan.com/fi/blog/agentti-joka-kirjoittaa-erp-jarjestelmaan" description: "Kirjausjärjestelmästä lukeminen on turvallista. Kirjoittaminen on kohta, jossa integraatiot pettävät. Mitä agentin kirjoittaminen vaatii, ja mihin Hurukan vetää rajansa." --- # Agentti kirjoittaa ERP:hen: lukemisen ja kirjoittamisen raja 20\. lokakuuta 2026·4 min lukuaika·Toimitus Talousosaston työntekijä sivulta kuvattuna työpöydän ääressä kahden näytön edessä, toisella abstrakti sinisenharmaa pääkirja, käsi lepää hiirellä ja tulostettua asiakirjaa pidetään näyttöä vasten vertailua varten, viileä toimistovalo Hankintatiimi ajaa pilottia. Agentti lukee avoimen tarpeen, varastosaldot ja toimittajien toimitusajat, ja kolmen viikon ajan se tekee juuri sen, mitä kaikki toivoivat: se ehdottaa tilauksia, ostajat tarkistavat ne, ostajat näppäilevät ne ERP:hen. Sitten joku esittää ilmeisen kysymyksen. Miksi kirjoitamme uudelleen sen, minkä agentti on jo valmistellut? Annetaan sille kirjoitusoikeus. Maanantaiaamuna ERP näyttää kaksi ostotilausta samalle toimittajalle, samat rivit, kahden minuutin välein. Toisessa on toimittajan vahvistus liitteenä. Toinen on otsikon alapuolelta tyhjä. Liitin oli saanut aikakatkaisun ensimmäisellä yrityksellä ja yrittänyt uudelleen; ERP hyväksyi tarinan molemmat puolikkaat. Toimittaja on jo alkanut keräillä toisen tilauksen mukaan, eikä kukaan huoneessa osaa sanoa kumman. Agentin päättelyssä ei ollut mitään vikaa. Pettänyt osa oli kirjoitus, ja kirjoitus on se kohta, jossa jokainen integraatio on pettänyt kahdenkymmenen vuoden ajan. Kirjausjärjestelmästä lukeminen on ratkaistu ja lähes riskitön ongelma: lukemisen voi toistaa, tallentaa välimuistiin, vertailla ja heittää pois. Kirjoitus muuttaa tietuetta, jota muu yritys pitää totuutena, eikä tietueella ole mitään keinoa tietää, oliko muutos tarkoitettu kerran vai kahdesti. ## Miksi takaisin kirjoittaminen on eri ongelma **Lukemisen voi toistaa, kirjoitusta ei.** Jos lukeminen epäonnistuu puolivälissä, luetaan uudelleen. Jos kirjoitus epäonnistuu puolivälissä, jäljellä on asiakirja, joka on olemassa osittain, ja seuraava yritys joko monistaa perille päässeen osan tai ohittaa sen, joka ei päässyt. Jokainen kuukauden lopussa ajettava täsmäytys on olemassa tämän epäsymmetrian takia. **Osittainen kirjoitus on pahempi kuin ei kirjoitusta.** Ostotilaus, jossa on otsikko mutta ei rivejä, läpäisee ERP:n oman tarkistuksen. Se myös varaa numeron toimittajalla, näkyy avoimissa sitoumuksissa ja päätyy seuraavaan raporttiin. Virhe on näkymätön juuri siellä, missä sillä on merkitystä. **Kirjausjärjestelmässä ei ole kumoa-toimintoa.** Kirjanpito-ohjelmistot on suunniteltu niin, ettei mitään poisteta. Väärä kirjaus korjataan vastakirjauksella, väärä lasku hyvityslaskulla. Jokainen korjaus on uusi asiakirja omalla numerollaan ja omalla kirjausketjullaan, joten konevauhdilla tehty virhe jättää konevauhdilla syntyneen sotkun, jonka ihminen siivoaa käsin. **Aikakatkaisu tekee yhdestä aikomuksesta kaksi toimea.** Liitin ei tiedä, vastaanottiko järjestelmä pyynnön ja vastasi hitaasti vai eikö se saanut sitä koskaan. Ilman keinoa sanoa “tämä on sama pyyntö kuin äsken” turvallinen valinta ja oikea valinta osoittavat vastakkaisiin suuntiin. **Kirjoitus ohittaa merkityksen.** ERP tarkistaa, että kentät on täytetty ja koodit ovat olemassa. Se ei tiedä, että tällä asiakkaalla on kokouksessa sovittu luottokielto tai että tätä toimittajaa saa käyttää vain yhdessä tehtaassa. Ne säännöt elävät ihmisissä, ja suora kirjoitus kävelee suoraan niiden ohi. **Kukaan ei osaa sanoa, kuka sen kirjoitti.** Tilauksen luonut integraatiokäyttäjä on tekninen tili, jonka jakaa jokainen sen kautta ajettava työ. Kysymykseen “kuka tämän päätti” ei ole vastausta tietueessa, ja siitä kertoo [yksi identiteetti ihmisille ja agenteille](https://hurukan.com/fi/blog/yksi-identiteetti-ihmisille-ja-agenteille). ## Mitä pitää olla olemassa ennen kuin agentti kirjoittaa **Idempotentit ehdotukset.** Jokainen aiottu muutos kantaa yhtä tunnistetta, joka luodaan ennen ensimmäistä yritystä. Kahdesti lähetettynä sen on tuotettava yksi tulos, ja vastaanottavan puolen on pystyttävä sanomaan “jo tehty” sen sijaan, että se tekisi sen uudelleen. Jos kohdejärjestelmä ei pysty siihen, sen edessä olevan kerroksen on hoidettava se: tarkistettava ennen lähettämistä ja kirjattava, mitä se lähetti. **Hyväksyntävaihe, jonka ihminen omistaa.** Ei ilmoitus vaan päätös: ehdotus, sen taustalla oleva näyttö ja sen kantama riski, hyväksytty, muutettu tai hylätty jonkun toimesta, jonka nimi menee tietueeseen. Mitkä kirjoitukset tätä vaativat, ei ole makuasia; se on kirjattu toimi kerrallaan, ja talosta lähtevä raha tai tehty sitoumus on aina listalla. **Uudelleen ajettava loki.** Mitä agentti näki, mitä se päätteli, mitä ehdotettiin, kuka hyväksyi, mitä lähetettiin, mitä tuli takaisin. Kirjoitettu niin, että ihminen voi kuukausia myöhemmin seurata ketjua, ja jäsennelty niin, että ketjun voi ajaa uudelleen järjestelmän kopiota vasten, kun jotain pitää rekonstruoida. **Raja, jonka ontologia tekee näkyväksi.** Toimet, jotka ovat olemassa kullakin liiketoiminnan kohteella, tilat, joissa kukin kohde voi olla, säännöt, jotka muutoksen on täytettävä, ja se, mitkä toimet lasketaan kriittisiksi. Agentti, joka toimii vain näillä käsitteillä, ei voi kirjoittaa mitään, mitä malli ei salli, ja mallia lukeva ihminen näkee tarkalleen, mitä agentti saa tehdä. **Täsmäytys kirjoituksen jälkeen.** Luetaan takaisin, mitä meni perille, ja verrataan siihen, mitä lähetettiin. Useimmat tuplakirjaukset löytää toimittaja tai tilintarkastaja; ne pitäisi löytää ne tehneen järjestelmän, minuuteissa. ## Testi, jonka voit tehdä tänään Ota uusin integraatio, joka kirjoittaa ERP:hen tai kirjanpito-ohjelmaan. Siinä ei tarvitse olla agenttia; verkkokaupan liitin tai taulukkolaskennan lataus riittää. Esitä sen rakentajille kolme kysymystä ja kirjoita vastaukset ylös. Mitä tapahtuu, jos sama viesti saapuu kahdesti? Mitä tapahtuu, jos siirto epäonnistuu seitsemän rivin kolmannen rivin jälkeen? Mihin on kirjattu, kuka hyväksyi kirjoitetun asiakirjan ja millä näytöllä? Jos teillä on testiympäristö, kokeilkaa sitten kahta ensimmäistä ja laskekaa korjaukset, jotka tarvitaan tietueen palauttamiseksi totuuteen. Jos jokin vastauksista on “saisimme kuulla siitä toimittajalta” tai “näkisimme sen kuukauden lopussa”, integraatio ei ole valmis agentille, lukipa agentti mitä tahansa. Aukko ei ole mallissa; se on kirjoituspolussa, ja se on sama aukko ihmiselle ja ohjelmistolle. Hurukan vetää oman rajansa tähän. Agentit valmistelevat, luonnostelevat ja ehdottavat kirjattujen rajojen sisällä, ja ne toimivat vain ontologian määrittelemillä käsitteillä. Se, mikä lähtee kirjanpito-ohjelmaan tai rinnalla käynnissä pidettävään olemassa olevaan järjestelmään, lähtee sen jälkeen, kun ihminen on sen hyväksynyt, liittimen kautta, ja ehdotus, päätös ja lopputulos ovat yhdessä lokissa. Kriittiset toimet odottavat ihmistä jokaisessa kokoonpanossa. Miksi kirjausjärjestelmän ei voi luottaa toimivan itsenäisesti, perustellaan kirjoituksessa [kirjausjärjestelmä ei osaa toimia](https://hurukan.com/fi/blog/kirjausjarjestelma-ei-osaa-toimia); kirjoituspolku on se kohta, josta [Hurukan](https://hurukan.com/fi) alkaa. - kirjausjärjestelmä - ERP - agentit - idempotenssi - hyväksynnät ## Lue lisää - [Yksi identiteetti ihmisille ja agenteille: kuka saa tehdä mitä](https://hurukan.com/fi/blog/yksi-identiteetti-ihmisille-ja-agenteille) - [Nykytila ja rekisteri: yrityksen käyttöjärjestelmän kaksi muistia](https://hurukan.com/fi/blog/nykytila-ja-rekisteri-kaksi-muistia)