Kun yritys muuttuu, ontologian on muututtava mukana

Aina tuotteita myynyt yritys alkaa myydä niiden rinnalla huoltosopimuksia. Huoltosopimus ei sovi tilauksen käsitteeseen: toimitettavaa ei ole, se laskutetaan kuukausittain, ja siihen liittyy vasteaikoja, jotka yrityksen on täytettävä. Nopein korjaus on tilaus, jolla on erityinen tyyppikoodi ja muutama vapaatekstikenttä sopimusehdoille.

Vuotta myöhemmin raportit laskevat huoltosopimukset tilauksiksi ja paisuttavat tilauskantaa. Varasto näkee tilauksia ilman nimikkeitä ja kysyy, mitä pitäisi kerätä. Agentti, jota pyydetään valmistelemaan viikon lähetteet, tekee sellaisen myös huoltosopimukselle. Jokainen ongelma saa oman pienen paikkansa, ja jokainen paikka vaikeuttaa seuraavaa muutosta.

Syy on se, että liiketoiminnan mallia käsiteltiin kiinteänä infrastruktuurina, joka suunniteltiin kerran ja jota sen jälkeen puolustettiin. Ontologia on kuitenkin kuvaus siitä, miten yritys toimii, ja yritys muuttuu jatkuvasti: uudelleenjärjestelyt, uudet tuotteet, yritysostot, uudet säännökset ja uudet myyntitavat. Jos mallia ei voi muuttaa turvallisesti, ihmiset muuttavat sitä turvattomasti tyyppikoodi kerrallaan.

Miten liiketoiminnan malli vanhenee

Ylikuormitus. Olemassa olevaa kohdetta käytetään uudelleen johonkin uuteen, ja ne erotetaan lipulla. Se on nopeaa, ja se tarkoittaa, että jokaisen kohdetta lukevan raportin, säännön ja agentin on nyt tiedettävä lipusta.

Vapaatekstin varaovet. Rakenne siirtyy muistiinpanokenttiin. ”Sopimus nro … voimassa …” näppäillään käsin kiinteän kaavan mukaan, koska mallissa ei ole paikkaa sille.

Hiljaiset uudelleenmäärittelyt. Alue jaetaan kahtia, ja vanha nimi kattaa nyt pienemmän alueen kuin ennen. Vuosivertailut vertaavat huomaamatta eri asioita.

Kaikki kerralla -uudistus. Muutokset säästetään suureen ”ensi vuoden” hankkeeseen. Sillä välin kiertotiet kasautuvat, ja hankkeen on purettava ne kaikki.

Ei kirjausta syistä. Kukaan ei muista, miksi asiakastyyppi 7 on olemassa tai käyttääkö mikään sitä enää, joten kukaan ei uskalla poistaa sitä.

Agentit oppivat kiertotien. Nykyisen mallin varassa työskentelevä agentti toistaa sen kiertotiet uskollisesti ja laajassa mittakaavassa. Ihminen oppi lopulta ohittamaan haamutilaukset. Agentti ei opi, ellei malli kerro sille.

Muuta mallia niin kuin muutat koodia

Jokainen muutos versioidaan. Jokaisella kohteisiin, suhteisiin tai sääntöihin tehdyllä muutoksella on tekijä, syy, katselmointi ja versionumero – samalla kurilla kuin lähdekoodissa. Historian voi myöhemmin lukea joku, joka ei ollut paikalla.

Lisää ensin, siirrä sitten, poista lopuksi. Tuo uusi kohde, huoltosopimus, omine suhteineen ja sääntöineen. Siirrä olemassa olevat tiedot sen alle. Merkitse vanha polku poistuvaksi ja poista se vasta, kun mikään ei enää riipu siitä. Älä koskaan määrittele olemassa olevaa merkitystä uudelleen paikallaan.

Käytä voimaantulopäiviä. Alueen jako tulee voimaan tiettynä päivänä. Historia säilyttää vanhan rakenteen, raportit tietävät, kumpi oli voimassa milloinkin, ja rajan yli tehtävät vertailut tehdään harkiten.

Näytä vaikutukset ennen hyväksyntää. Ennen kuin muutos hyväksytään, listaa kaikki, mikä riippuu muutettavasta: raportit, säännöt, agentit, integraatiot ja dokumentit. Hyväksyjä näkee vaikutusalueen eikä pelkkää eroa.

Anna agenttien ehdottaa ja ihmisten hyväksyä. Agentti voi huomata kiertotien – esimerkiksi sen, että yhden tyypin tilauksilla ei koskaan ole nimikkeitä – ja ehdottaa sen tilalle uutta kohdetta näyttöineen. Päätöksen tekee ihminen, joka vastaa kyseisestä liiketoiminnan osasta.

Näin Hurukanin Ontologia-kerros on suunniteltu: kohteet, suhteet ja säännöt kuvattuina ja versioituina sekä laajennettuina sitä mukaa kuin agentit laajentavat järjestelmää. Ehdotukset kulkevat Agenttinen logiikka -kerroksen hyväksyntäsääntöjen kautta, ja jokainen muutos auditoidaan ihmisen, agentin tai järjestelmän tekemäksi, kuten kohdassa Tietoturva ja suvereniteetti kuvataan. Se on rakenteilla. Mistä tällaisen mallin ensimmäinen versio tulee, kerrotaan kirjoituksessa yritykselläsi on jo ontologia.

Testi, jonka voi tehdä jo tänään

Etsi pääjärjestelmästä kolme eniten käytettyä ”tyyppi”-, ”luokka”- tai ”tila”-kenttää. Kustakin:

1. Listaa kaikki arvot, jotka se voi saada.
2. Selvitä jokaisesta arvosta, milloin, kenen toimesta ja miksi se lisättiin.
3. Merkitse arvot, joita käytetään johonkin muuhun kuin mitä niiden nimi sanoo.

Etsi sitten tiedoista vapaatekstikenttiä, joita ihmiset täyttävät kiinteän kaavan mukaan, kuten ”OT: …”, ”sopimus nro …” tai ”voimassa …”. Jokainen löytämäsi kaava on kohde tai suhde, jota mallissa ei vielä ole.

Nämä kaksi listaa yhdessä ovat jono muutoksista, jotka yritys on jo tehnyt todellisuudessa mutta ei vielä mallissaan. Niiden läpikäyminen versioitu muutos kerrallaan on halvempaa kuin suuri uudistushanke, joksi ne muuten kasvaisivat. Hurukan on suunniteltu pitämään tuo jono lyhyenä.