Prosesseja olionäkökulmasta

Prosesseista

Prosessilähentymisen pyrkimyksenä on yksinkertaistaa kokonaisuuden monimutkaisuutta erottamalla jossain määrin riippumattomia osia toisistaan. On selvää, että tällä on kustannus, joka tarkoittaa sitä, että jotakin osaprosessien välisestä vuorovaikutuksesta häviää.

Tarkastelkaamme yksinkertaista ravintolaesimerkkiä, joka avulla on helppo avata tätä kokonaisuutta.

Tarkastellaan siis ravintolayritystä Lautanen Oy, jolla on ruokaravintola, jossa on sanokaamme 30 pöytää ja näissä 2 – 10 paikka kussakin. Tarkastelkaamme nyt ravintolan prosessimallia:

Tässä liiketoiminnan kannalta näkyvin osaprosessi on asiakaan vierailu. Tämän prosessin elinkaari alkaa toiminnasta: ”paikan varaus” ja päätyy ravintolasta poistumiseen.

                        Ravintolasali

                                                                                                                  Keittiö

Tästä prosessikaaviosta näkyy, että linkki vierailunprosessin ja valmistusprosessin välillä on tilaus tapahtuma. Kun prosessimallin painottaa aktiviteettien virtaa, se jättää toimijat lähes huomiotta. Tämän seurauksena syntyy toiminnallinen – siis lähinnä aikaan sidottu- ositus. Tämä ositus jättää lähes kokonaan huomiotta tekemiseen osallistujat.

Kun tarkastellaan liiketoimintaprosesseja ja etenkin ydinprosesseja ja tavoitteena on tukea niitä tavalla tai toisella tietojärjestelmin. Tietojärjestelmiä voidaan rakentaa huomattavasti helpommin kuin lähtökohtana on todellisuuden mallintaminen toimijoihin perustuen. Tämä abstraktion tuottaa lähes välittömän tietojärjestelmätotutuksen liiketoimintalogiikan osalta. Tämä ei toki tarkoita vielä koko järjestelmää. Näin oliomallipohjainen abstrakti leikkaa todellisuutta eri suuntaan kuin prosessimalli. Prosessimallissa ei tyypillisesti eroteta liiketoimintalogiikka ja organisaation toteuttavaa toimintaa. Kun nämä jäävät osaksi saamaa kuvausta, kokonaisuus monimutkaistuu huomattavasti. Oliomalli taas erottaa liiketoiminnan perusteista tulevan toiminnon osaset varsinaisesta organisaation toiminnasta abstraktion avulla ja näin tämä näkökulma yksinkertaistuu. Kun se vielä on kuvattu oliotermein, sen ohjelmointi on hyvin suoraviivaista.

Toinen näkökulma prosessiin on hyvin paljon jakamattomampi kokonaisuus. Tässä prosessi näkyy enemmän kolmiulotteisena punoksena:

Tämä viittaa kokonaisuuden jakamattomuuteen jo hyvin paljon enemmän. Tässä siis valmistuksen ja vierailun vuorovaikutus on todellisuudessa pidempää ja monimutkaisempaa kuin alun perin on näytetty. Painotukset muuttuvat ja viimekädessä malli yksinkertaistuu liiketoiminnan logiikan kannalta. Toisaalta voidaan myös sanoa, että malli monimutkaistuu. Taustalla on kauhun tasapaino. Maailman monimutkaisuuteen voi ani harvoin vaikuttaa. Kun tähtäimessä on aina kokonaisvaltaisemmat ja kattavammat tietojärjestelmät, joutuvat tietojärjestelmien rakentajat aina mutkikkaampiin toteutuksiin. Monimutkaisuutta me voimme hallitta abstrahoimalla ja rakenteistamalla. Rakenteet ja abstraktio ovat itse asiassa meidän ainoat instrumentit monimutkaisuuden edessä. Näin siis rakenteet tuovat kaaokseen järjestyksen. Tämäkin on kaksiteräinen miekka. Liikaa rakenteita kääntyy itseään vastaan ja nopeasti nollakohdan ohitettuaan alkaakin luoda omaa monimutkaisuuttaan ja näin päädytään ojasta allikkoon.

Kun siirrymme oliomalliin (seuraavassa ensi luokkamalli ja sen jälkeen yksi yhteistoimintakaavio), tavoittelemme siis abstraktia simulaatiomallia, jonka abstraktiotaso ja näkökulma irrottavat liiketoiminnan toiminnan keskeisen ytimen prosessin kokonaisuuden mutkikkuudesta.

Tähän liittyvä yhteistoimintakaavio tilauksesta aterian tarjoiluun on seuraava:

Tässä yhteistoimintakaaviossa on kuvattu ydinliiketoiminta ruokalajin valinnasta aina valmiin annoksen tarjoiluun. Tässä on siis voitu nostaa kuvauksen abstraktiotasoa. Näin toimijoiksi voi tulla mikä olio tahansa esimerkiksi tapahtumat kuten valmistaa tai vierailu.

Ravintolatoiminnan laadun kannalta on keskeistä, että valmistus ja ruokailu ovat läheisessä vuorovaikutuksessa keskenään. Varmaankin on olemassa monia oikeitakin ravintoloita, jossa valmistus ja kulutusprosessi ovat hyvin etäällä toisistaan ja heikosti kytkettyjä, mutta tällaiset ravintolat eivät välttämättä toimi pitkään.

Oliomallissa prosessikaaviota vastaavat yhteistoimintakaaviot. Teknisesti yhteistoimintakaavio vastaa yhtä use case skenaariota. Näin toimintokaavio on teknisesti esimerkkitapaus joka kuvaa toiminnon. Nämä kuvaustavat ovat päällekkäisiä. Ne siis kuvaat saman asian eri tavoin. Näin on selvää, että kuvaus tulee tehdä toisella näistä tavoista. Molemmat kuvaukset ainoastaan sotkevat näkökulmia ja estävät kirkasta ajattelua.

Kun tavoitteena on tehdä tietojärjestelmä, on lähestymistavoilla valtava ero! Prosessimalli kertoo hyvin vähän siitä, miten tietojärjestelmä toteutetaan. Sitä vastoin luokkamalli ja yhteistoimintakaavio ovat lähes valmiit suoraan koodattavaksi. Itse asiassa yleensä yli 80 % liiketoimintalogiikasta voidaan näistä kaavioista automaattisesti generoida. Lähestymistavan edut tulevat kuitenkin suurimmaksi osaksi rakenteista ja luokkien määritellyistä vastuista ja yhteistyökehikosta. Tämä kaikki antaa toteuttajan maailmalle rakenteen, joka poistaa kaaoksen. Lähestymistapa edellyttää 3-tasoista sovellusarkkitehtuuria, joka erottaa sovelluslogiikan – siis käyttötilanteen ja siihen liittyvät toiminnot – ja liiketoimintalogiikan, joka taas on riippumaton käyttötilanteesta ja näin ollen kaikille käyttötilanteille yhteinen.

Tietojärjestelmän asema liiketoiminnassa

Ohjauksen tietojärjestelmien olemassa ole on välttämätön mutta ei riittävä edellytys liiketoiminnan menestykselle. Kun edellytyksen ovat kunnossa, on mahdollista saavuttaa toiminnassa sille asetetut tavoitteet. Lähes aina tässä on kyseessä liiketoiminnan henkilöstön ammattitaito, osaaminen, ryhmätoiminta ja sitoutuminen – siis ihan tavilliset johtamisen perusasiat. Operatiiviset ohjausjärjestelmät ovat näin yrityksissä parhaimmillaan mahdollistajan roolissa. Tästä olkoon esimerkki, kun yllä olevalle ravintolalle rakennetaan seuraavat tietojärjestelmät, jotka ovat integroitu yhden yhtenäisen liiketoimintaytimen ympärille:

· Menu-järjestelmä aterioiden tilausta ja tarjoilua varten

· Pöydänvaraus ravintolatilan kapasiteetin hallintaan

· Varastonhallinta raaka-aineiden hankintaa ja kulutuksen hallintaan

· Työvuorojen hallinta henkilöiden työajan hallinta

Ajatellaan vielä, että nämä järjestelmät toimivat ihanteellisesti ja antavat kaikille osapuolille täydellisen palvelun. Tässä vaiheessa itse liiketoiminnan keskeistä menestymistekijöistä on vasta hyvin vähän käsitelty.

Nämä vasta mahdollistavat ravintolaliiketoiminnan todelliset menestystekijät, joita tietenkin ovat:

· Menun valinta (minkälaisia aterioita tässä ravintolassa tarjotaan)

· Raaka-aineiden tuottajien valinta ja laadunvalvonta

· Annosten laatu ( mikä on kokkien ammattitaito)

· Miten palvelu ravintolasalissa toimii

o Paikan varaustoiminta

o Tarjoilutoiminta

o Vierailun päätös

Liiketoiminnan oikea osaaminen on siis oikeaa kyseisen toiminnan ammatillista osaamista. Tämä on tietenkin keskeistä eikä mikään mahdollistava tietojärjestelmä voi koskaan korvata tämän puutetta.

Sama tilanne on lähes kaikessa liiketoiminnassa esimerkiksi:

· Logistiikassa (kuljetusyritys, huolintaliike tai lentoyhtiö )

· Terveydenhuollossa (sairaala terveyskeskus lääkäriasema yms.)

· Kappaletavaratuotannossa

· Kaupassa

· Pankkitoiminnassa

Itse asiassa on vaikeata löytää liiketoimintaa, jossa asia olisi oleellisesti toisin.

Toisaalta on selvää, että toimintaympäristö –siis nämä mahdollistajat – voivat toki muuttaa itse liiketoiminnan ammatintaitovaatimuksia, kuten on nähty esimerkiksi kun ”oikea” kauppa muuttuu nettikaupaksi.