Inhimillinen IT-projekti - lataa opas

Teknologian tehtävä on pitää yksinkertaiset asiat yksinkertaisina

Teknologian tehtävä on pitää yksinkertaiset asiat yksinkertaisina

Simplicity is the ultimate form of sophistication.  – Albert Einstein

Kunnianhimoisesti avaan kirjoituksen suhteellisuusteorian kehittäjän ajatuksilla. Kimmokkeen tähän sain kohtaamisesta potentiaalisen asiakkaan kanssa. Halusimme tarjota pk-sektorin pienemmän pään edustajalle asiakkaan Microsoft 365 -ympäristöön rakentuvaa toteutustamme yrityksen asiakkaiden -ja projektienhallintaan, täysin yksilöllisten tarpeiden mukaan nopeasti konfiguroitavan liiketoiminta-alustan päälle. Yritys oli kuitenkin päättänyt, että ratkaisua varten olisi rakennettava täysin räätälöity mikropalveluarkkitehtuuri, joka paketoitaisiin kauniiseen konttiin lähetettäväksi ajoon vaikkapa nyt Microsoftin tai Amazonin pilvipohjaiselle alustapalvelulle.

Hämmennyin. Miksi tehdä kovin kallis ja teknisesti raskas ratkaisu? Päädyin siihen johtopäätökseen, että asiakas halusi ymmärryksensä mukaan parasta, mitä markkinoilta löytyy. Uusinta uutta. Siksi pieni yritys tahtoi tilata pörssiyhtiötasoisen ratkaisun.

Jäin kuitenkin pohtimaan, miksi kevyempi ja yksinkertaisempi ratkaisu toteutus tarkoittaisi automaattisesti huonompaa, etenkin jos se vastaa kaikkiin asiakkaan tarpeisiin, sitä on mikropalveluitakin helpompi kehittää vaikka vauvanaskelin eteenpäin, tietokanta riittää datan massaan nähden monikertaisesti ja asiakkaan syöttämä tieto on asiakkaan omassa hallussa.

Kärsi, kärsi, kirkkaamman kruunun saat?

Väittävät, että IT-projekteista suurin osa epäonnistuu. Joko budjetti ylitettiin, aikataulu ylitettiin tai valmistunut järjestelmä ei vastannutkaan tarpeeseen. Katson toki asiaa omasta low code-kuplastani, mutta tämän tiedon valossa en tahdo jaksaa ymmärtää, miksi paras teknologiavalinta on se, joka on ehkä monimutkaisin ja raskain toteuttaa.

Nolostuttaako tietohallintopäättäjiä kertoa, että toimintoamme ohjaava järjestelmä toteutettiin konfiguroiden neljässä kuukaudessa ja se maksoi neljäsosan kovakoodatusta? Vaatiiko jonkinlainen it-uskottavuus sen, että kaksi vuotta rakennettiin monoliittia ja upotettiin siihen miljoona tai kaksi? Silloinko vasta on yrityksen tieto hyvässä hallussa?

Miten mutkat suoristetaan?

Pitkään mietimme, miten kiteyttää se,  miten me teknologian roolin organisaatioissa näemme ja mikä sen tehtävä on. Se kulminoitui vihdoin siihen tavoitetilaan, että pyrimme ratkaisemaan asiat aina yksinkertaisimmalla mahdollisella toteutuksella, joka kulloinkin asiakastarpeen parhaiten täyttää. Teknologian tehtävä kun on pitää yksinkertaiset asiat yksinkertaisina.

Meille se tarkoittaa lähtökohtaisesti toimintaa ohjaavaa järjestelmää, jota nuin vain muokataan istumaan arkeen, jos arki muuttuu. Se tarkoittaa järjestelmää. joka pyörii omassa, muutenkin asiakkaan käytössä olevassa Microsoft 365 -pilviympäristössä. Ei tarvitse miettiä palvelintiloja eikä tarvitse purkaa paketista mikrosovelluksia muokattavaksi, saati tehdä kylmän hien pintaan nostattavia roll outeja kokonaisesta ohjelmistojärkäleestä.

Jos haluat varmistaa, että yksinkertaiset asiat pysyvät yksinkertaisina, valitse siis oikeanlainen teknologia oikeaan asiaan. Et varmasti lähtisi rakentamaan miljardibisneksen ERP-järjestelmää low code -toteutukset mahdollistavalla alustalla, miksi siis lähtisit sovittamaan pienen tai keskisuurenkaan pk-yrityksen liiketoimintaa pörssiyhtiön kankeisiin ratkaisuihin, kun kaikki olisi tehtävissä valmiin liiketoiminta-alustan tarjoamilla mahdollisuuksilla moninkertaisesti yli tarpeen? Tuskin yrittäisit saada konsernitasoista toiminnanohjausjärjestelmää taipumaan yksittäisen tiimin erityistarpeisiin, miksi siis et hyödyntäisi yhtä ja samaa alustaa tällaisten yksilöllisten ”ERP-kolojen” paikkaamiseen?

Pelkkä teknologiavalinta ei kuitenkaan riitä. Jos tavoitetila on, että projektin lopputuotos eli asiakkaan järjestelmä yksinkertaistaa arkea, pitää se kokemus mielestämme mahdollistaa jo projektia tehdessä. Siksi me mieluiten teemme projekteja siten, että vaatimusmäärittelyyn normaalisti uppoavat tunnit sijoitetaan pikemminkin järjestelmän testaamiseen projektin kuluessa ja mieltä saa muuttaa milloin vain, mieluiten juuri siinä hetkessä, kun jokin ominaisuus tuntuu hiertävän.

Eiköhän se järjestelmän varsinaisessa käytössä valkene paperille kirjaamista paremmin, miten ne asiat oikeasti pysyvät yksinkertaisina.  Asiat kun ovat harvoin monimutkaisia, mutta väärä teknologia työkaluna voi niistä kyllä tehdä sellaisia.

Kai Halonen

kai.halonen@pilvilampi.fi
+358 44 3200 368

Ps. Vaihteeksi tällainen lopputarkennus. Kehittämäämme Sopivin 365 -liiketoiminta-alustaa ei siis ole kasattu kokoon low code -teknologioilla vaan sitä koodataan hikihatussa, jotta sen avulla voitaisiin tehdä mutkattomasti monimuotoisia low code -toteutuksia yksilöllisiin asiakastarpeisiin.