Uimaradoista kohti todellista toimintamallia

Laadunhallinnan yksi kantava periaate on prosessimainen toimintamalli. ISO 9001:2015 standardissa sanotaan, että ”Organisaation on luotava ja otettava käyttöön laadunhallintajärjestelmä, johon sisältyvät tarvittavat prosessit ja niiden keskinäiset vuorovaikutukset… ”. Suomennettuna tämä tarkoittaa organisaation toimintamallin luomista. Toimintamallista käytetään myös nimiä prosessien välinen vuorovaikutus, process integration model (PIM).

Asiakaskoulutuksissa törmään silloin tällöin kysymykseen, että ”mistä tiedän mitä prosesseja meidän kannattaa tai pitäisi mallintaa?”. Lähestyn tässä blogissa asiaa organisaation asiakas- ja palvelulähtöisen prosessiarkkitehtuurin laadinnan näkökulmasta.

Organisaation ylimmän tason prosessiarkkitehtuurin laatiminen lähtee strategiasta. Strategia antaa liiketoimintamallille syötteitä siitä, mitä konkreettisia palveluita ja tuotteita organisaatio haluaa tarjota asiakkaillensa. Kun ylimmän tason toimintamallia lähtee suunnittelemaan liiketoimintamallin tietojen (asiakkaat, palvelut, tuotteet, arvoverkko- ja arvolupaus) pohjalta, niin ei voi mennä kovin pahasti pieleen. Liiketoimintamallin toteuttamiseen tarvittavien kyvykkyyksien kautta etenemme kohti organisaatio-, osaamis-, prosessi-, tietojärjestelmä- ja teknologianäkökulmia. Toimintamallia laadittaessa hyvä ohjenuora on miettiä asiakkaan virtausta eli millä meidän organisaatiomme prosesseilla vastaamme asiakkaan kokemaan palvelupolkuun (ennen, alussa, aikana, jälkeen). Silloin itse tehdyt organisaatiosiilot unohtuvat taustalle ja pystymme ajattelemaan paremmin tekemistä asiakkaan näkökulmasta.

Jostain syystä organisaatioiden verkkolevyt kuitenkin pullistelevat irrallisia sisäisestä näkökulmasta tehtyjä prosessien kulkukaavioita (eli ns. uimaratakaavioita).  Ylimmällä tasolla on kuvattu vain prosessikartta, joka on kuin kirjan sisällysluettelo: näet mitä prosesseja on, mutta voit tehdä asiat ihan missä järjestyksessä tahansa. Toimintamallilla puolestaan pystyt määrittelemään prosessiarkkitehtuurin rakenteen ja rajapinnat siten, että voit varmistua yksittäisten prosessien johdonmukaisuudesta, eheydestä ja yhteyksistä muihin prosesseihin.  Operatiivisessa toiminnassa olevien prosessikehittäjien työ vaikeutuu, jos toimintamallin ylin taso puuttuu. Silloin yksi suunnittelee prosessinsa sisäisestä näkökulmasta, toinen asiakkaan näkökulmasta ja kolmas ekosysteemin näkökulmasta. Myöskään prosessien väliset rajapinnat eivät muodostu eheiksi ja yksiselitteiseksi, vaan muodostuu päällekkäisiä prosesseja. Prosessiarkkitehtuuria siis tarvitaan, jotta organisaation toimintamalli rakennetaan ylhäältä alas asti eheästi.

Toinen usein kysytty kysymys on, että montako toimintamallitasoa tarvitaan ennen uimaratoja. Tähän vastaus on yksiselitteinen: niin monta tasoa kuin prosessin johtamiseen tarvitaan. Tarkempia uimaratatasoisia kuvauksia tarvitset yleensä vasta toiminnan kehittämisvaiheessa. Toiminnan kehittämisen puolestaan pitäisi pohjautua strategisista painopistealueista johdettuihin kriittisten menestystekijöiden toteutumisen varmistamiseen. Mutta tämä onkin sitten jo toisen blogin arvoinen asia.

Kirjoittaja
Author imageexpand

Nina Ritonummi

Senior Process Consultant / Quality Director QPR Software Oyj. Nina on kokenut palveluliiketoiminnan kehittäjä, joka auttaa asiakkaita strategian toteuttamista parhaiten tukevan palvelu- ja prosessiarkkitehtuurin rakentamisessa. Hän vastaa myös QPR:n sertifioidusta ISO 9001 -laatujärjestelmästä.

Jaa