Käsite ”digitalisaatio” ei ole mitenkään vakiintunut. Petri Tuominen viittaa blogissaan Gartnerin jäsennykseen IT-kehityksen vaiheista: IT-käsityöläisyyden aikakausi, IT-teollisuuden aikakausi ja digitalisaation aikakausi. IT käsityöläisyyden aikakaudella keskityttiin teknologiaan, järjestelmien ohjelmointiin ja hallintaan. Työtä tehtiin eristäytyneenä – varsinkin ulkomaailmasta. IT-teollisuuden aikakaudelle oli ja on edelleen tyypillistä keskittyminen tuotantoon, prosesseihin, tuottavuuteen ja tehokkuuteen. Digitalisaation aikakaudelle on tunnusomaista uudet liiketoimintamallit, verkostoituminen ja tuotteiden kehittäminen yhdessä asiakkaiden kanssa. Kuva siitä kuka ostaa ja myy, ja kuka tuottaa ja kuluttaa, alkaa hämärtyä.
Tässä kirjoituksessa keskitymme ensisijaisesti vaiheeseen kaksi eli IT-teollisuuden aikakauteen ja liitämme käsitteen digitalisaatio siihen. Tarkoitamme digitalisaatiolla sitä, kuinka yritykset ja julkisyhteisöt voivat automatisoida, nopeuttaa ja tehostaa omia prosessejaan informaatioteknologian avulla ja kuinka heidän tarjoamansa palvelut ja tavarat saadaan paremmin asiakkaiden käyttöön. Kysymys ei ole suinkaan välttämättä jo vakiintuneiden prosessien tehostamisesta, vaan digitaalitekniikka voi tehdä mahdolliseksi täysin uudenlaisia toimintatapoja. Näissäkin tapauksissa arkkitehtuurin jäsentäminen on tarpeellista. On syytä huomata, että digitalisointi usein siirtää painotusta yksittäisten transaktioden hoitamisesta edellytysten luomiseen sille, että yksittäiset esimerkiksi tilaus-toimitus transaktiot voidaan automatisoida. Käsittelemme tätä aihetta myöhemmin tässä artikkelissa.
Asiakas haluaa palvelua
Palvelu on keskeinen käsite digitalisaatiossa. Sen vuoksi on syytä avata, mitä tämä käsite tarkoittaa.
Tutkijatohtori Jari Paranko on määritellyt, että ”Palvelu on tekemistä toiselle”. Tämä naseva määritelmä tarkoittaa, että täytyy olla palvelija, joka tekee jotakin palveltavalle. Kun parturi leikkaa asiakkaan hiukset tai siivooja siivoaa asunnon, kysymys on palvelusta. Jos leikkaat itse omat hiuksesi, kysymys ei ole palvelusta. Palvelu voi olla tuote, jota yritys myy ja markkinoi. Tuotteita on kahden tyyppisiä: tavaroita ja palveluita. Molemmat voivat olla fyysisiä tai digitaalisia. Reittivaihtoehtojen opastus julkisia kulkuvälineitä käyttämällä on hyvä esimerkki digitaalisesta palvelusta. Valittuasi lähtöpaikan, määränpään ja halutun lähtö- tai saapumisajan, tietokone laskee ja valitsee sinulle reittivaihtoehtoja. Juuri tämä reittivaihtoehtojen laskeminen on määritelmän mukaista palvelua eli tekemistä, jonka palvelija eli tietokone tekee sinulle. Sovellus, jonka mahdollisesti olet ostanut verkkokaupasta reittivaihtoehtojen laskentaan on digitaalinen tavara. Digitaalisuus sinänsä ei tarkoita palvelua.
Palvelulla on merkittäviä eroja tavaroihin verrattuna. Palvelua esimerkiksi ei voi palauttaa. Jos olet tyytymätön siivouksen lopputulokseen, voit reklamoida asiasta, mutta et voi palauttaa tätä siivousta. Palvelua ei voi myöskään tehdä varastoon. Siivouspalvelujen tarjoaja ei voi tehdä joulusiivouksia varastoon tasapainoittaakseen kysyntävaihteluita. Tämä on hyvin merkittävä tekijä palveluiden digitalisoimiseksi. Digitaaliset palvelut ovat aina saatavilla ja niiden skaalautuvuus kuormitusmuutoksiin on nykytekniikalla lähes rajaton – ainakin moninmoninkertainen verrattuna ihmisvoimin toteutettuihin palveluihin.
Palveluun liittyy myös se ominaisuus, että palvelija voi kontrolloida ketä hän palvelee. Parturi voi koska tahansa päättää syystä tai toisesta, että hän ei vastedes leikkaa herra X:n hiuksia. Hän voi soveltaa tätä sääntöä kunhan vain tunnistaa, että asiakas on herra X. Samaa ideaa voidaan soveltaa ja sovelletaan myös digitaalisiin palveluihin. Palvelun tarjoavalle palvelimille voidaan määritellä keskitetysti laitteet tai asiakastilit, joille palvelua annetaan. Kontrolli perustuu palveltavan kohteen tunnistamiseen heikommilla tai vahvemmilla autentikointimenetelmillä. Digitaalisia tavaroita ei voi samalla tavalla kontrolloida. Kun digitaalinen musiikkitiedosto on kerran laskettu irti, sitä voidaan kopioida rajattomasti. Kopioitujen tiedostojen käyttämistä voidaan yrittää estää digital rights management tekniikoilla. Nämä tekniikat aiheuttavat ongelmia varsinkin rehellisille kuluttajille, koska käyttöoikeuksia ei voida myöntää henkilölle, vaan ne täytyy sitoa laitteeseen. Digitaalisten oikeuksien hallinnasta ei siis varsinaisesti ole kysymys, vaan digitaalisten tavaroiden käytön rajoittamisesta tiettyihin laiteyksilöihin.
Asiakas on kiinnostunut yrityksen tai julkishallinnon toimijan tarjoamista palveluista. Se millaisilla sisäisillä prosesseilla ja rakenteilla palvelut ja tavarat tuotetaan ei ole asiakkaan kiiinnostuksen kohteena, mutta näiden prosessien ja rakenteiden eli arkkitehtuurin hahmottaminen on palvelun tarjoajan kannalta äärimmäisen tärkeää, koska niiden avulla palvelut määritetään ja toteutetaan. Tästä enemmän seuraavassa kappaleessa.
Arkkitehtuurimalli
Kuva 1 esittää arkkitehtuurimallin palveluiden tuottamiseksi. Palvelu tarkoittaa tässä yhteydessä mitä tahansa asiakkaan tarvitsemaa palvelua, joka voi olla digitaalista, fyysistä tai näiden yhdistelmiä. Termi liiketoimintaprosessi on hieman harhaanjohtava, koska kysymys ei tarvitse olla varsinaisesta liiketoiminnasta vaan esimerkiksi julkisista terveyspalveluista tai vanhusten kotihoidosta. Digitaalitekniikan rooli tässä mallissa on tehostaa näitä prosesseja paremman palvelun tarjoamiseksi asiakkaille. Mallin yksi perusviesteistä on, että tietotekniikan syövereihin ei pidä rynnätä suinpäin, vaan ensiksi on tarpeen jäsentää millä prosesseilla palvelut saadaan aikaiseksi, mitä käsitteitä ja sääntöjä näissä prosesseissa käytetään, minkälaisia sovelluspalveluita tietotekniikalta odotetaan ja mitä käyttötapauksia sovelluspalvelut tukevat prosessin eri vaiheissa. Sovelluspalveluiden määrittelyn jälkeen voidaan erikseen päättää hankitaanko sovellukset omaan omistukseen vai ulkoistetaanko sovellukset esimerkiksi pilvipalveluun. Luonnollisesti mitä paremmin sovelluspalveluiden määrittelyssä osataan jo ottaa huomioon kaupalliset ratkaisut, sen vähemmällä räätälöinnillä selvitään.
Kuva 1: Arkkitehtuurimalli palvelun tuottamiseksi
Määritelmät arkitehtuurimallissa esiintyville käsitteille:
| Palvelu | Palvelu on tekemistä toiselle (Jari Paranko) |
| Liiketoimintaprosessi | Tehtäväsarja, joka koostuu toisiinsa loogisesti liittyvistä tehtävistä ja joka käynnistyy määritellystä tapahtumasta ja tuottaa asiakkaalle ja muille prosessin sidosryhmille yhden tai useamman mitattavan lopputuloksen. |
| Käsitemalli | On tietomalli, joka kuvaa liike- tai muussa toiminnassa käytettävät käsitteet, käsitteiden väliset suhteet ja oleellisimmat attribuutit. |
| Sovelluspalvelu | Sovelluksen tarjoama selvästi määritelty ja rajattu toiminnallisuus kuten ”näytä avoimet tilaukset” tai ”avaa nimike”. Sovelluspalvelu määrittelee, mitä järjestelmä tekee. Sovelluspalvelua voi hyödyntää useista käyttötapauksista tai muista sovelluksista. |
| Käyttötapaus | Yksityiskohtainen ja askelmainen kuvaus käyttäjän kommunikoinnista järjestelmän kanssa jonkin prosessivaiheen suorittamiseksi. |
| Sovellus | Tietokoneohjelma tai ohjelmisto, joka toteuttaa sovelluspalvelun. |
Joitakin huomioita:
- Oleellista on lähteä liikkeelle yrityksen tai julkisyhteisön strategioista ja päättää, mitä palveluja on tarpeen tuottaa ja mitä nämä palvelut tarkkaan ottaen ovat.
- Liiketoimintaprosessit operoivat liiketoiminnassa käytettävillä käsitteillä ja käsitteisiin liittyvillä säännöillä. Tästä syystä prosessimallinnus ja käsitemallinnus kannattaa tehdä käsikädessä.
- Prosessille pitää olla olemassa tunnistettu käynnistävä tapahtuma ja selvä tulos (Kuva 2). Prosessi kannattaa nimetä muodossa verbi+substantiivi, josta voi johtaa prosessin lopputuloksen. Esimerkiksi: Toimita tilaus (tilaus on toimitettu), hanki asiakas (asiakas on hankittu). Vältä prosessin nimissä termejä ”hallinta”, ”monitorointi”, ”seuranta”. Mitä tarkoittaisi prosessin tuloksena, että asiakassuhde on hallittu?
Kuva 2: Prosessi
- Sovelluspalvelu on itsenäinen kokonaisuus, joka hoitaa yhden primitiivisen, mutta liiketoiminnan kannalta merkityksellisen tehtävän alusta loppuun kuten ”avaa nimike”. Sovelluspalvelu pitää sisällään tehtävään liittyvän sovelluslogiikan ja laadun varmistukset myös poikkeustilanteissa ja riippumatta siitä, mistä sovelluspalvelua kutsutaan.
- Sovelluspalveluita voi tunnistaa eri tavoin. Voi esimerkiksi poimia käsitteen käsitemallista ja kysyä, mitä tapahtumia kohdistuu tähän käsitteeseen. Esimerkiksi käsitteeseen ”tilaus” voisi kohdistua tapahtumia ”tilaus on vastaanotettu”, ” tilaus on ajoitettu”, tilaus on vahvistettu”, ”tilaus on valmistettu”, ”tilaus on pakattu”, ”tilaus on toimitettu”. Näiden perusteella on mahdollista nimetä vastaavat sovelluspalvelut ”vastaanota tilaus” jne sekä kuvata sen jälkeen kuhunkin sovelluspalveluun kuuluvat loogiset toiminnot.
Liiketoimintaprosessien ja liiketoiminnassa käytettävien käsitteiden ja niihin liittyvien sääntöjen jäsentäminen ovat välttämättömiä edellytyksiä onnistuneille muutos- ja digitalisointihankkeille. Usein nämä mallinnusvaiheet jäävät liian vähälle huomiolle ja siitä syystä tätä aihepiiriä on tarpeen käsitellä hieman tarkemmin seuraavissa kappaleissa. Lisäksi suosittelemme tutustumaan referensseihin [1] ja [2].
Liiketoimintaprosessin mallintaminen
Prosessien mallintamisessa on kysymys tekemisen rakenteista eli työn organisoimisesta siten, että jokin yritykselle tai muulle yhteisölle tärkeä tehtävä sujuu jouhevasti ja kukin toimija tässä tehtäväketjussa tuottaa lisärvoa halutun lopputuloksen saavuttamiseksi. On hieman vaikeaa ja tarpeetontakin määritellä, milloin prosessi muuttuu liiketoimintaprosessiksi varsinkin, koska – kuten aiemmin olemme todenneet – termi liiketoiminta ei oikein istu julkishallinnon prosesseihin. Oleellista on kuitenkin tuoda esille, että liiketoimintaprosessille on tunnusomaista, että se ylittää organisaatiorajapinnat. Toisin sanoen prosessiin osallistuu toimijoita monista organisaatioyksiköistä tai funktioista. Tämä on itse asiassa yksi tärkeimmistä syistä liiketoimintaprosesseille.
Kuva 3 esittää tämän perusidean.
Kuva 3. liiketoimintaprosessi
Liiketoimintaprosessia ei siis pidä lähteä jäsentämään siten, että organisaation funktioita aletaan kutsua prosesseiksi niin, että myyntitoiminnosta tulee myyntiprosessi, valmistuksesta valmistusprosessi ja asennuksesta asennusprosessi, jonka jälkeen kukin toiminto optimoi omaa prosessiaan omien mittareidensa mukaisesti. Tuloksena on helposti niin osaoptimoitu kokonaisprosessi, että lopputulos voi olla huonompi kuin lähtötilanne. Kustannusten minimointi ”asennusprosessissa” voi johtaa siihen, että asennustehtäviä tämän mittarin mukaan kannattaa puskuroida asentajien pitämiseksi kaiken aikaa tasaisesti kuormitettuina. Tällainen toimintatapa on helposti ristiriidassa kokonaistavoitteen kanssa esimerkiksi, jos pyrkimyksenä on toimittaa jokainen tilaus mahdollisimman nopeasti tilauksen vastaanottamisesta asennuksen hyväksyntään. Mittarit pitää siis asettaa liiketoimintaprosessille ja funktiokohtaisten mittareiden pitää tukea liiketoimintaprosessin mittareita.
Kuinka tunnistaa liiketoimintaprosessit? Tämä on oleellinen kysymys, johon ei ole yhtä ja oikeata vastausta. Voi esimerkiksi lähteä liikkeelle terminologiasta. Haastattelemalla eri funktioiden edustajia, saa melko nopeasti selville liiketoiminnassa käytettävät käsitteet. Sen jälkeen voi kysyä, mitä tapahtumia tai toimenpiteitä liittyy näihin käsitteisiin. Samalla olemme tekemässä myös käsitemallinnusta, mikä korostaa jo aiemmin mainitsemaamme periaatetta, että prosessimallinnusta ja käsitemallinnusta kannattaa tehdä käsi kädessä. Kun käsitteisiin liittyvät tekemiset kirjataan verbi-substantiivimuodossa (vastaanota tilaus), meillä alkaa olla aihioita osaprosesseista ja yksittäisistä tehtävistä. Seuraavaksi tunnistetut tekemiset kannattaa järjestellä loogiseen tapahtumajärjestykseen ja analysoida tekemisten (osaprosessien) väliset liitynnät (1:1, 1:M, M:1, M:M). Kuva 4 esittää lopputuloksen tällaisesta prosessijäsennyksestä. Ne osaprosessit joiden suhde toisiinsa on 1:1, on usein järkevää ryhmitellä samaan liiketoimintaprosessiin. Näissä prosesseissa sama viestikapula (esimerkiksi asiakas) kulkee läpi kaikkien osaprosessien. Hyvä kandidaatti uudelle liiketoimintaprosessille on niissä kohdissa, joissa kytkennät ovat joko 1:M tai M:1. Samalle asiakkaalle voidaan käynnistää useita lainan myöntämisprosesseja ja jokaiselle lainalle monta lainan lyhennystapahtumaa. Ryhmittelyn jälkeen liiketoimintaprosessit nimetään havainnollisesti verbi-substantiivimuodossa siten, että prosessin nimi jo kertoo mikä on prosessin mitattava lopputulos. Sen jälkeen loogisesti yhteenkuuluvat liiketoimintaprosessit voidaan koota prosessialueeksi kuten esimerkkikuvassamme.
Kuva 4: Prosessialue, liiketoimintaprosessi, osaprosessi (Alec Sharp: Workflow Modeling)
Kuvan 4 mukaiseen rakenteeseen voi päätyä myös top-down menetelmällä sen sijaan, että tunnistetaan ensiksi yksittäisiä käsitteisiin kohdistuvia toimenpiteitä. Vaarana vain on, että mallintaja saattaa vaistomaisesti soveltaa organisaatiorakennetta pilkkoessaan prosessialuetta liiketoimintaprosesseiksi, jolloin ajaudutaan huomaamatta funktiokohtaisiin prosesseihin todellisten liiketoimintaprosessien sijaan. Tekemisen rakenteiden hahmottaminen ei ole mitenkään helppoa, vaikka lopputulos voi näyttää (ja toivottavasti näyttääkin) yksinkertaiselta sitten kun se valmis.
Mitattavien lopputulosten lisäksi liiketoimintaprosessin rajaamisen ja määrittelyn kannalta on oleellista tunnistaa liiketoimintaprosessin käynnistävä tapahtuma. Näitä tapahtumia on kolmenlaisia: Toimenpide tai päätös, aika, ja ehdon täyttyminen.
Liiketoimintaprosessien tunnistus ja määrittelyvaiheessa kuvataan siis yrityksen tai julkisyhteisön kannalta oleelliset prosessit ja niiden perusrakenteet. Malli kuvaa, mitä yrityksessä tehdään, mitä tuloksia prosessit tuottavat ja miten prosessit käynnistyvät. Usein ei tarvitse ottaa kantaa siihen edustaako malli nykytilaa vai tavoitetilaa. Hyvin todennäköisesti se edustaa molempia. Nykytila ja tavoitetila tulevat kuvaan mukaan, kun analysoidaan uimaratadiagrammien (swimlane diagram) avulla kuka tekee ja mitä ja suunnitellaan vastaavat tekemiset ja roolitukset tavoitetilan mukaisesti.
Emme käy tässä esityksessä tarkemmin läpi, kuinka uimaratakuvia tehdään. Oleellista kuitenkin on pitää mielessä, että prosessin analysoimiseksi ja uuden suunnittelemiseksi uimaratakuvissa pitää näyttää kaikki toimijat, jotka tavalla tai toisella ovat tehtäväketjussa mukana riippumatta siitä tekevätkö he vähän tai paljon töitä prosessissa tai onko tekeminen enemmän tai vähemmän tärkeää. Kaikki ”kapulan vaihdot” on tarpeen tunnistaa, koska ne voivat aiheuttaa tarpeettomia viivästyksiä kokonaisprosessissa. Uimaratakuvan tarkoitus on toimia kommunikointivälineenä, jolla nykytilaa analysoidaan tai tavoitetilaa kuvataan. Tätä tarkoitusta varten kuvaustavan pitää olla selkeä ja yksinkertainen eli monimutkaista notaatiota pitää välttää.
Käsitemallin tekeminen
Tietoa tulvii reaaliajassa erilaisten laitteiden ja palveluiden kautta jokapäiväiseen elämäämme. Tietojen tulkitseminen ja jakaminen on osana arkea. Kavereille pitää kertoa mitä teki milloinkin ei ainoastaan sanoin vaan myös kuvin ja äänin tehostettuna. Onko tämä tietojen tulva vaikuttanut ihmisen kykyyn ymmärtää ja prosessoida tietoja? Onko aivomme kapasiteetti ja kyky abstrahoida asioita parantunut viimeisten sadan vuoden aikana? Osaammeko yhdistää monimutkaisia riippuvuuksia ja nähdä metsän puilta, porautua tietomassojen ytimeen ja ymmärtää mitä kaikkea ne meille kertovat erilaisissa asiayhteyksissä? Aivomme eivät ole virittyneet tietojen ja käsitteiden suhteiden ja sääntöjen tiukkaan tulkitsemiseen, koska se ei ole tarpeellista päivittäisten rutiinien hoitamisen kannalta. Selviämme varsin hyvin ilman tietomalleja, kun käymme ruokakaupassa ostoksilla tai kuntosalilla jumppaamassa. Mutta onko tilanne sama myös yritysmaailmassa? Voidaanko liiketoimintaa hoitaa menestyksellä ilman asianmukaisia asiakas- ja tuotetietoja? Voidaanko tuotanto- ja jakeluketjuja hallita ilman täsmällistä tietoa tilauksista ja toimituksista? Maalaisjärki sanoo, että tietojen tehokas käsittely tuo tehokkuutta liiketoimintaan. Mutta mitkä tiedot ovat sitten tarpeelisia ja mitkä voidaan unohtaa? Vastaus tähän saadaan käsitemallinnuksen avulla. Käsitemallinnuksella tarkoitetaan tässä analyysia, joka selventää liiketoiminnassa käytettyjen käsitteiden merkityksen, miten käsitteet liittyvät toisiinsa ja mitä tietoja käsitteistä on syytä kerätä ja hallita.
Käsitemalli on kuvaus todellisuudesta, tässä tapauksessa yrityksen liiketoiminnasta sellaisena kun se on tai halutaan olla. Käsitemallilla voi kuvata nykytilaa tai tulevia liiketoiminnan sääntöjä. Koska jokainen kokee todellisuuden erilaisena, yhtenäistää käsitemalli näkemykset, varmistaa käsitteiden yhdenmukaisen ymmärtämisen ja tietojen käsittelyn. Käsitemalli on tietomalli, joka kuvaa liiketoiminnan käsitteet (konseptit), käsitteiden suhteet (relaatiot) ja ominaisuudet (attribuutit). Kuvassa 5 on esitetty tässä artikkelissä käytettyä tietomallien luokittelua, joka noudattaa varsin usein alan kirjallisuudessa esiintyvää jaoittelua.
Kuva 5: Tietomallit: Käsitemalli, looginen malli ja fyysinen tietomalli
Haluamme painottaa, että käsitemalli ei määrittele IT järjestelmän tietorakennetta vaan liiketoiminnan sääntöjä. Käsitemalli kulkee käsi kädessä liiketoiminnan prosessimallien kanssa. Käsitemallinnuksella ei tarkoiteta tietokannan suunnittelua eikä sen tarvitse johtaa siihen. Käsitemalli on täysin riippumaton teknologiasta, sen toteuttaminen voi tapahtua tietojärjestelmän tuella tai ilman.
Tietomallinnuksesta löytyy varsin paljon kirjallisuutta, käsitemallinnuksesta tuntuu olevan vähemmän tarjolla. Yhtenä erinomaisena referenssinä pidämme kirjaa “Data Modeling for the Business” (referenssi [3]).
Joskus ajatellaan, että liiketoiminnan käsitemalli on ylimalkainen ja epätarkka, nopeasti luotu luonnos maailmasta, jota ei ole olemassa. Tämä ei ole oikea ajatus. Käsitemalli on teknisesti erilainen kuin looginen tai fyysinen tietomalli. Se on varsin yksityskohtainen ja täsmällinen, missä piileekin sen tekemisen haaste; kuka voi kertoa liiketoiminnasta täsmällisesti ja riittävän yksityskohtaisesti? Useimmiten liiketoimintasääntöjen selvittäminen on salapoliisin kaltaista työtä, missä mallintaja haastattelee joukon ihmisiä ja yhdessä heidän kanssaan luo käsitemallin. Tässä on hyvä muistuttaa, että liiketoiminnan säännöt ohjaavat mallia ja mallintajan rooli on kuvata sääntöjä mallin avulla eikä päinvastoin.
Kuinka sitten luodaan hyvä käsitemalli ja tunnistetaan liiketoiminnan kannalta tärkeät tiedot? Menestyksen avaimena on yhdessä tekeminen. Käsitemallia ei voi luoda irrallaan varsinaisesta toiminnasta ja sitten pakottaa liiketoimintaa noudattamaan sitä, oli malli kuinka elegantti tahansa. Ensiksi on hyvä määritellä, mihin liiketoiminnan tarpeeseen mallia tehdään, mihin pyritään ja mitä prosessiin tai tietoihin liittyvää ongelmaa ollaan ratkaisemassa. Tämä luo sidoksen reaalimaailmaan ja perustelut mallinnustyön tekemiselle. Sitten on syytä rajata mallinnettavan alueen laajuus. Hyvin määritelty tarve edesauttaa rajauksen tekemisessä ja se voi syntyä hyvinkin luontevasti. Rajauksena voi olla yksittäinen funktio, kuten taloushallinto tai myynti, liiketoimintaprosessi tai sen osa, useamman prosessin muodostama prosessialue, tai jopa kokonainen liiketoiminta-alue. Jos mallinnettava alue on laaja, suosittelemme sen palastelua pienempiin osiin. Palastelussa on hyvä noudattaa selkeitä, liiketoiminnalle luonnollisia rajoja vaikkapa funktioiden tai prosessien mukaan. On hyvä muistaa, että käsitemalli tehdään liiketoiminnalle liiketoiminnan ehdoilla.
Liiketoiminnan käsitteiden tunnistaminen tapahtuu analysoimalla liiketoimintaprosessia ja kirjaamalla, mistä asioista puhutaan ja mitä asioita käsitellään kuten tavarat, henkilöt, paikat, organisaatiot ja erilaiset tapahtumat. Kun käsite on tunnistettu, on syytä kirjata, mitä sillä tarkoitetaan. Käsitteen määritelmä kertoo yhdellä tai kahdella lauseella, mitä käsite tarkoittaa, ei kuka sitä käyttää tai mihin sitä käytetään. Käsitteen merkityksen kiteyttäminen voi joskus tuntua mahdottomalta. Lähtökohtana voi hyödyntää Internetistä löytyvän sanaston tarjoamaa määritelmää ja muokata siitä kyseiselle käsitteelle sopiva kuvaus (Kuva 6).
Kuva 6: Esimerkki käsitteestä
Käsitettä kuvaavat tiedot lisätään attribuutteina ja attribuuttien merkitys määritellään. Lisäämällä attribuutin määritelmään muutama attribuutin esimerkkiarvo voidaan merkitystä edelleen tarkentaa. Esimerkiksi asiakkaan tunniste, etunimi ja sukunimi voivat olla tärkeitä tietoja kyseisen prosessin kannalta, joten ne on syytä dokumentoida mallissa. Toisessa prosessissa voikin olla, että pelkästään asiakkaan tunniste on tärkeä, jolloin sen prosessin mallissa vain tunniste näytetään asiakkaan attribuuttina (Kuva 7). Attribuuttien tietotyypit eivät kuulu käsitemalliin, vaan ovat loogisen tietomallin tietoa. Poikkeuksia voi toki tehdä, jos tietotyyppi on prosessin kannalta kriittinen tieto.
Kuva 7: Attribuutit kuvataan tarpeen mukaan
Joskus käsite voi liiketoimintaprosessin edetessä saada erilaisia tiloja, joita halutaan seurata. Esimerkiksi lasku voi eri ajanhetkinä olla tilassa Lähetetty, Maksettu tai Arkistoitu. Käsitteen tilasiirtymä tapahtuu, kun tietty ehto täyttyy (esimerkiksi lasku arkistoidaan kaksi päivää maksutapahtuman jälkeen). Käsitteen tilatieto voidaan ilmaista esimerkiksi “Tila” attribuutilla ja määritelmässä mainita attribuutin sallitut arvot (käsitteen tilat).
Joskus käsitteen versiointia voi olla tarpeellista mallintaa. Ajatellaan tilannetta, missä esimerkiksi yhdestä asiakkaan tilauksesta voi olla monta versioita, ja ne kaikki ovat liiketoiminnan kannalta tärkeitä. Koska tarkoitus on kuvata liiketoimintaa, myös nämä tapaukset täytyy käsitellä. Mallin rakenne riippuu siitä, miten monimutkainen versiointihallinta on. Versiotieto voidaan yksinkertaisesti lisätä käsitteen attribuutiksi tai toisena ääripäänä on, että versiohallinta kuvataan omalla käsitemallilla.
Käsitteiden väliset relaatiot kuvaavat miten prosessissa käsiteltävät asiat liittyvät toisiinsa. Relaatiot tuovat näkyviin liiketoiminnan logiikan ja näyttävät täsmällisesti miten prosessissa toimitaan. Oletetaan esimerkiksi, että tuotteen tilausprosessin sääntöä kuvataan hieman ylimalkaisesti näin: “Kun asiakas luo tilauksen, hänen täytyy aina kertoa mitä tuotetta hän tilaa”. Tästä lauseesta voi päätellä, että asiakkaan ja tilauksen välillä on suhde, mutta mikä on asiakkaan ja tuotteen välinen suhde? Mallintamalla kyseiset suhteet käsitemallissa sääntö tarkentuu ja todetaan, että asiakas luo tilauksen ja tilaus on aina tietylle tuotteelle. Voidaan todeta, että asiakkaalla on relaatio tilaukseen ja tilauksella on relaatio tuotteeseen. Tästä voidaan jatkaa mallin tarkentamista ja lopulta päätyä seuraaviin sääntöihin: Asiakas voi luoda ei yhtään tai monta tilausta, tilauksen luo aina yksi asiakas, tilaus tehdään aina yhdelle tuotteelle, ja tuotteelle voi tehdä ei yhtään tai monta tilausta. Nämä säännöt kuvataan lisäämällä kardinaliteetit (1, 0..*, 0..*, 1) relaatioiden molempiin päihin (Kuva 8).
Kuva 8: Esimerkki käsitteiden välisistä relaatioista eli liiketoimintasäännöistä
Relaation esittäminen käsitemallissa ei tarkoita, että siitä tallentuu automaattisesti tietoa jonnekin. Liiketoimintaprosessin ongelma voi yksinkertaisesti ratketa sillä, että aloitetaan keräämään jostakin relaatiosta tietoa.
Käsitemallinnuksen avulla voidaan tarkastella toimitaanko järkevästi. Edellisessä esimerkissä voi kysyä, että eikö olisi helpompaa jos asiakas voi tilata monta erilaista tuotetta samalla tilauksella? Sääntöjen esittäminen kuvan avulla helpottaa niiden tarkastelua ja kokonaisuuden hahmottamista. Vanha sananlasku “yksi kuva kertoo enemmän kuin tuhat sanaa” pitää varsin hyvin paikkansa.
Joskus käsitemallista tulee monimutkainen ja vaikeasti ymmärrettävä. Mallin piirtämisessä tuleekin pyrkiä selkeyteen, välttää turhia relaatioiden päällekkäisyyksiä ja sijoittaa käsitteet niin, että mallin lukeminen on mahdollisimman helppoa ja luontevaa. Mutta jos liiketoiminnan säännöt ovat monimutkaiset, myös mallista tulee monimutkainen. Monimutkaisten tai epämääräisten sääntöjen mallintaminen ja esittäminen antaa herätteen liiketoimintaprosessin yksinkertaistamiseen ja uudelleen suunnitteluun.
Käsitemallinnuksessa voidaan käyttää monta erilaista kuvauskieltä (Chen, Crow’s Foot, UML, jne.) ja näitä tukevia mallinnustyökaluja on monenlaisia tarjolla. Käytännössä mallin piirtäminen ja hallinta on helpointa työkalun avulla, mutta myös paperilla ja kynällä pääsee alkuun. Kuvauskieli ei saa näytellä pääroolia käsitemallinnuksessa. Tärkeintä on liiketoiminnan sääntöjen tunnistaminen, niistä muodostettu yhtenäinen täsmällinen kuva ja jaettu ymmärrys. Mallinnuksen alkuvaiheessa on kuitenkin hyvä selventää kuvauskielen symbolit ja miten mallia luetaan. Olemme huomanneet, että panostamalla selkeään järjestykseen ja ryhmittelemällä loogisesti samat asiat yhteen, mallin lukeminen ei yleensä aiheuta ongelmia.
Kun liiketoiminnan prosessia pyritään yksinkertaistamaan ja/tai tukemaan IT järjestelmällä, on ilmeistä, että liiketoiminnan logiikka täytyy ensin yksiselitteisesti ymmärtää ja määritellä täsmällisesti. Käsitemallinnus on siihen hyvä ja halpa työkalu, jota hyödyntämällä varmistetaan yhtenäinen ja tarkoitukseen sopiva tietoarkkitehtuuri.
Digitaalisten tuotteiden liiketoiminta
Digitaaliset tuotteet – olivatpa ne digitaalisia tavaroita tai palveluita – poikkevat oleellisesti fyysisistä tuotteista. Digitaalisilla tavaroilla ei ole valmistukseen tai logistiikkaan liittyviä rajoitteita kuten materiaalien suunnittelu, varastointi tai yksittäisten tuotteiden kokoonpano. Digitaalisilla palveluilla ei ole ihmistyöstä aiheutuvia skaalautumisrajoitteita. Digitaalisille tuotteille on tyypillistä suuret transaktiomäärät, mutta yksittäisen transaktion arvo on usein pieni. Tästä seuraa, että transaktiot on tarpeen automatisoida skaalautuvuuden ja kustannustehokkuuden vuoksi.
Monet digitaaliset palvelut toimivat jo nyt täysin automaattisesti. Kuluttaja voi tehdä tilisiirtoja pankin verkkopalvelussa, voi määritellä laskunsa automaattisesti maksettaviksi, voi täydentää veroilmoitustaan ilman verovirkailijan apua, voi etsiä parhaat matkustusvaihtoehdot lomakohteeseen ja hankkia liput saman tien, ohjelmistot päivittyvät tuoreimpaan versioon automaattisesti jne. Tällaisissa palveluissa on onnistuneesti pystytty automatisoimaan asiakasrajapinnassa tapahtuva kanssakäyminen. Tuloksena on aina saatavilla oleva ja lähes rajattomasti skaalautuva palvelu. Se, että asiakasrajapinnassa tapahtuva transaktio voidaan automatisoida täysin, vaatii, että palvelu tai digitaalisen tavaran ostotapahtuma on hyvin mallinnettu ja sitä tukevat prossessit, informaatio ja taustajärjestelmät ovat kunnossa. Kehitystyön painotus siirtyy silloin yksittäisten transaktioiden hallinnasta edellytysten luomiseen sille, että nämä yksittäiset transaktiot voidaan automatisoida.
Seuraavassa tätä ajatusta on kuvattu 3-tasoisella rakenteella (Kuva 9).
- Valmistelu ja ylläpito, taso 1: Liiketoiminnan perusrakenteen asettaminen
- Valmistelu ja ylläpito, taso 2: Tuotteen asettaminen
- Online transaktiot: Asiakaspalvelu ja myynti
Kuva 9: 3-tasoinen rakenne digitaaliselle tuoteliiketoiminnalle
Kullakin tasolla prosessit käsittelevät tai voivat käsitellä sekä tuote-, asiakas, liiketoiminnan ohjaus- ja jakelunäkökulmia, mutta käsiteltävät asiat ja tarkasteltavat ajanjaksot ovat erilaisia. Esimerkiksi käytettävät tuloutusmallit määritellään, päätetään ja syötetään järjestelmään valmistelutasolla 1. Tietty tuloutusmalli kiinnitetään tuotteeseen valmistelutasolla 2. Myyntitransaktion yhteydessä käytetään tätä mallia, jotta liikevaihdon tuloutus saadaan automatisoiduksi sääntöjen mukaisesti.
Kuvan 1 arkkitehtuurimallia voi sellaisenaan soveltaa kullekin tasolle. Kuva 10 havainnollistaa, kuinka valmisteluvaiheen prosessilla ja sitä tukevilla sovelluspalveluilla tehdään mahdolliseksi online palvelu asiakkaalle. Asiakas saa palvelun käyttöliittymän kautta. Prosessi on automatisoitu ja kätkeytyy sovelluspalvelun logiikkaan, jonka sovellus toteuttaa. Käyttöliittymässä esiintyvät käsitteet ovat käsitemallin mukaiset.
Kysymyksessä voi olla vaikkapa asiakkaan käynnistämä ohjelmistopäivitys laitteeseensa tai reittiopastus julkisilla kulkuneuvoilla pisteestä A pisteeseen B. Jotta ohjelmistopäivitys tai reitin opastus toimisivat luotettavasti ja virheittä, täytyy monen asian olla paikoillaan. Täytyy olla mietittynä, miten uutta ohjelmistoa tuotetaan, versioidaan, hyväksytään ja julkaistaan. Täytyy olla varmuus siitä, että ohjelmistopäivitys on juuri oikea kyseiseen kohteeseen. Reittiopastuksessa aikataulujen, reittivaihtoehtojen, karttojen ja matka-aikojen pitää olla koko ajan ajantasalla jne. Tietokoneet toimivat niinkuin ne on määritelty toimimaan. Myös virheet skaalautuvat nopeasti. Koska ihminen ei ole tulkitsemassa palvelupyyntöjä, tiedon oikeellisuuden tarve korostuu entisestään. Online palvelun laatu on hyvin riippuvainen valmisteluprosessin tuottamasta laadusta. Käsitteet, prosessit ja ICT-ratkaisut täytyy mallintaa huolellisesti niinkuin olemme tässä kirjoituksessa esittäneet. Digitalisaatio korostaa arkkitehtuurin merkitystä.
Kuva 10: Valmisteluprosessi tukee ja ylläpitää online palvelua
Lähteitä:
- Blogi: Hyvää Arkkitehtuuria Tarvitaan, Heikki Melama, 2014
https://www.itewiki.fi/blog/2014/01/hyvaa-arkkitehtuuria-tarvitaan/ - Workflow Modeling – Tools for Process Improvement and Application Development, Alec Sharp, 2009
- Data Modeling for the Business, Steve Hoberman, Donna Burbank, Chris Bradley, 2009
Kirjoittajat:
Heikki Melama
Kirjoittajalla on monipuolista kokemusta yrityselämän eri osa-alueilta myynnin ja markkinoinnin, tuotekehityksen, tuotannon ja ICT:n parissa. Hänen kiinnostuksensa on viime vuosina kohdistunut erityisesti arkkitehtuurityöhön ja arkkitehtuurin merkitykseen yrityksen johtamisessa ja muutoshankkeissa.
Jan-Erik Österberg
Kirjoittajalla on pitkä kokemus ICT:n suunnittelu- ja mallinnustehtävistä. Hän on vuodesta 2003 lähtien työskennellyt tietoarkkitehtuurin ja tietomallinnuksen parissa.Työssään hän on tehnyt tietoarkkitehtuurin suunnittelua, yritystietomallin kehitystä, prosessimallinnusta, ja tietovaraston tietomallinnusta. Viime vuosina hän on keskittynyt käsitemallinnukseen kattaen yrityksen eri toimintoja kuten henkilöstö, taloushallinto, tuotekehitys, valmistus, toimitus, huolto ja tuotetuki.
