Rusty bicycle | Siili Solutions

Lopetetaanko prosessien mallintaminen?

Pitäisikö organisaation toiminnan ymmärtäminen lähteä käsitteistä, tavanomaisen prosessien kuvaamisen sijaan? Viime syksynä minulla oli tilaisuus osallistua Enterprise Architecture Conference Europe 2017 -tilaisuuteen Lontoossa. Sen ehdottomasti antoisin anti oli työpaja, jonka kanadalainen Alec Sharp piti käsitemallinnuksesta otsikolla: Kuinka käsitemallinnus tukee prosessi- ja arkkitehtuurityötä – kuinka saada loistavia tuloksia väärinymmärretyllä tekniikalla? 

Yleisesti työpaja oli loistava paketti tietoa käsitemallinnuksesta ja sen merkityksestä, ja Alec veti työpajan mukaansatempaavalla tyylillä. Minulle työpajasta jäi kytemään ajatus, joka esitettiin siellä lähinnä sivulauseessa: Pitäisikö yrityksen/ organisaation toiminnan ymmärtäminen lähteäkin käsitteistä, tavanomaisen prosessien kuvaamisen sijaan? Tämän ajatus jäi mietityttämään ja mitä enemmän olen ajatusta työstänyt, sitä enemmän olen alkanut siitä pitää. Olkoonkin että olen tottunut konsulttina kertomaan asiakkaalle, että prosessien ymmärtäminen on onnistuneen kehityshankkeen avain.

Toiminnan ymmärtämisen tarve ei katoa

Miksi toiminnan ymmärtäminen (ja kuvaaminen) on kehittämisessä tärkeää? Toiminnan kuvaamisesta ei tulisi tehdä itsetarkoitusta vaan sen tulisi lähteä tarpeesta kehittää toimintaa, etsiä ratkaisu olemassa olevaan ongelmaan tai tarpeesta ymmärtää uusien teknologioiden tuomia mahdollisuuksia.

Kaikissa näissä tilanteissa toiminnan ymmärtämisellä, kuvaamisella ja muotoilulla on merkittävä tehtävä ennen kuin syöksytään suunnittelemaan palvelua, tietojärjestelmästä puhumattakaan. Ilman toiminnan tai ongelman riittävän hyvää ymmärtämistä päädytään helposti tekemään ratkaisu ongelmaan, jota ei ole olemassa ja oikeat toiminnan kipukohdat ja potentiaaliset kehityskohdat jäävät ratkaisematta. Toiminnan ja toimintaa tukevan tietojärjestelmän kehittämisessä on tärkeää vastata ennen kaikkea kysymyksiin ’Miksi?’ ja ’Mitä?’, vasta tämän jälkeen ’Miten?’. Kysymykset ovat samat, riippumatta siitä ollaanko esimerkiksi rakentamassa kokonaan uutta järjestelmää vai sovittamassa kaupallista sovellusta organisaation toimintaan.

Perinteinen vaatimus toiminnan ymmärtämisestä ei ole häviämässä mihinkään teknologian kehittyessä. Pyrkimykset automatisoida prosesseja ja hyödyntää esim. keinoälyn tuomia mahdollisuuksia toiminnan tehokkuuden tai laadun parantamisessa asettava toiminnan ymmärtämiselle suuria vaatimuksia. Koneälyn ratkaistaviksi tulisi antaa vain prosesseja, joiden toiminnan pystymme ymmärtämään.

Toisaalta joudumme jatkuvasti kehittämään monimutkaisessa ja alati muuttuvassa toimintaympäristössä. Tällaisessa ympäristössä ei ole mahdollista pysähtyä pitkiksi ajoiksi tutkimaan ja kuvaamaan toimintaa yksityiskohtaisesti vaan tarvitaan ketteriä tapoja yhteisen ymmärryksen ja kokonaiskuvan hahmottamiseksi. Voisimmeko vastata tähän ketteryyden vaatimukseen lähtemällä liikkeelle toiminnan tarvitseman ja tuottaman tiedon (=käsitteiden) ymmärtämisestä ja kuvaamisesta?

Käsitteet toiminnan ymmärtämisessä

Meillä on usein käytettävissä varsin rajallinen aika ja resurssit toiminnan ymmärtämiseen ja kuvaamiseen. Uskon, että voisimme päästä hyödyllisempiin tuloksiin, jos aloitamme työn toiminnan käsittelemän ja tuottaman tiedon ymmärtämisellä ja kuvaamisella. Syntynyt käsitemalli antaa suuremman hyödyn, kuin saman ajan käyttäminen yksityiskohtaiseen prosessimallinnukseen. Tälle työskentelytavalle voi tunnistaa ainakin seuraavia perusteita:

  1. Käsitteet antavat kehittämiselle kielen – Käsitteiden, tunnistaminen, läpikäynti ja yhteisen ymmärryksen muodostaminen antaa kehittämiselle jatkossa yhteisen kielen ja käsityksen. Käsitemallin avulla voidaan kirkastaa käytettyjä termejä, sillä voidaan selkeyttää toiminnan sääntöjä ja tunnistaa toimintoja ja tapahtumia.
     
  2. Tieto säilyy kauemmin kuin prosessit – Toiminnan tarvitsema ja tuottama tieto on karkealla tasolla (käsitemalli) ajallisesti pysyvämpää kuin prosessit. Tällä perusteella se voi kuvata yrityksen tai organisaation toiminnan ydintä prosesseja luotettavammin
     
  3. Nopeat voitot - Rajoitetulle käytettävissä olevalla ajalla saat tiedoista nopeammin käsityksen. Käsitemallinnuksen avulla voidaan suhteellisen lyhyessä ajassa muodostaa yleiskuvaa toimintaympäristöstä. Kohtuullisen pienellä työmäärällä voimme saada apua esim. toiminnanohjausjärjestelmän sopivuuden tarkasteluun, ilman uppoutumista usein työlääseen prosessimallinnukseen.
     
  4. Käsitteet (tieto) läpäisevät arkkitehtuurin eri tasoja – Kokonaisarkkitehtuurin näkökulmasta käsittet ovat punainen lanka arkkitehtuurin eri näkulmien välillä: Strategia, tavoitteet ja mittarit luovat, määrittelevät ja mittaavat käsitteitä (tietoa). Prosessit käsittelevät tietoa. Käsitemalli muodostaa pohjan tietoarkkitehtuurille. Tietojärjestelmissä tukevat prosesseja tiedon käsittelyssä.
     
  5. Prosessit eivät aina kerro toiminnasta oleellisinta – Monissa tapauksissa prosessi voi sinällään olla yksinkertainen, mutta käsiteltävä tieto monimutkaista. Usein toiminnan tarvitsemat tiedot asettavat tarkemmat vaatimuksen esim. tarvittavalle järjestelmälle kuin prosessit. Tällaisissa tapauksissa kuvaamalla vain prosessit ymmärretään toimintaa puutteellisesti.

Kokeillaan!

Kuinka voimme työstää käsitemallin, joka kertoo olennaisen toiminnasta ja kuinka voisimme sen avulla tunnistaa toimintaa liittyviä tapahtumia. Esimerkkiprosessissa voimme tunnistaa seuraavia vaiheita:

  1. Tutustaan kohdealueen toimintaan esimerkiksi haastattelemalla toiminnan asiantuntijoita. Käsitemallintaja poimii näistä keskusteluista substantiivejä (käsitteitä) -Esim. tilaus, toimitus, asiakas, tilauspäivä
     
  2. Erotellaan asiat ja niitä kuvaavat käsitteet toisistaan, toisin sanoen erotetaan käsitteet ja attribuutit
     
  3. Käydään läpi käsite ehdokkaita ja tunnistetaan keskeiset, joiden perusteella käsitemallia lähdetään rakentamaan. Pohditaan kuinka käsitteet liittyvät toisiinsa, kuvataan käsitteiden väliset suhteet
     
  4. Käydään läpi käsitemallia ja tunnistetaan mitä tapahtumia/ aktiviteetteja kuhunkiin käsitteeseen liittyy, esim. ’Tilaus’ ’luodaan’, vahvistetaan, toimitetaan jne.

Vaiheet 2-4 kannattaa tehdä yhdessä (liike)toiminnan asiantuntijoiden kanssa, mieluiten yhdessä tai useammassa työpajassa.

Jokainen tällainen tunnistettu käsite-toiminto -pari voi olla:

  • rakennuspalikka tunnistettaessa kohdealueen prosesseja
  • palvelu, jonka tietojärjestelmä tarjoaa
  • käyttötapaus tai käyttäjätarina, jonka järjestelmä tarjoaa

Kas näin! Olemme suhteellisen nopealla tekniikalla luoneet käsitemallia, tunnistaneet tieto- ja sovellusvaatimuksia sekä luoneet alustavaa käsitystä ja pohjaa prosesseista, joilla tietoa käsitellään

Tapahtumat asioiden ympärillä

Lukuisissa projekteissa olen aloittanut toiminnan ymmärtämisen kuvaamalla prosesseja melko tarkallakin tasolla. Onko tämä enää paras toimintatapa? Oma kokemukseni on, että yksityiskohtaisessa prosessien läpikäynnissä löytyy harvoin jotain merkityksellistä ja uutta. Useammin on uusia näkökulmia löytynyt, kun on mietitty, kuinka prosessit liittyvät toisiinsa ja millaisia käsitteitä toiminta pitää sisällään.

Toiminta tapahtuu prosesseissa. Prosessit käsittelevät tietoa. Mitä jos useammin lähtisimme liikkeelle käsitteistä (tiedosta) ja suunnittelisimme ja rakentaisimme prosessit ja tietojärjestelmät niiden ympärille, kietoisimme tapahtumat asioiden ympärille?


---

Lue seuraavaksi: 

6 + 1 tilannetta, jossa Serverless pesee perinteisen palvelininfrastruktuurin

Business design – ihmislähtöistä liiketoiminnan muotoilua