Järjestelmäkartta luo yhteisen ymmärryksen

Liiketoiminta ja ICT-elävät usein ihan eri maailmoissa. He ovat kiinnostuneet eri asioista ja puhuvat eri kieltä. Toki tämä on kärjistys, mutta usein liian lähellä totuutta. Tämä on organisaatiolle iso haaste. Hyvin toimivilla organisaatiolle on jaettu käsitys siitä miten ICT-ratkaisut tukevat liiketoimintaa ja pystyvät käymään rakentavia keskusteluja siitä miten palveluita kehitetään.

Joskus tämä keskustelu voi olla toimintalähtöistä. Tarvitaan parempia ICT-palveluita tukemaan muuttunutta liiketoimintaa. Keskustelu voi olla myös ICT-lähtöistä. Järjestelmä pitää uusia tai on olemassa uusia kyvykkyyksiä jotka voisi olla hyödyksi toiminnalle.

Arkkitehtien työnkuvan ytimessä on tämän keskustelun fasilitointi ja yhteisen tilannekuvan rakentaminen keskustelun pohjaksi. Perinteiset arkkitehtuurityökalut eivät usein tue tätä parhaalla mahdollisella tavalla. Toiminnan edustajien silmät alkavat usein vaistomaisesti pyöriä kun arkkitehdit kaivavat esiin kaavion missä näkyy laatikoita ja paljon nuolia/viivoja niiden välillä.

Perinteisten arkkitehtuurityökalujen haasteita ovat:

Kuvausmallit ovat niin monimutkaisia, että ne eivät tue päätöksentekoa portfoliotasolla käytännössä
Kuvausmallit sisältävät niin paljon informaatiota, että kokonaisuuden hahmottaminen muodostuu haastavaksi
Niiden ylläpito vaatii niin paljon työtä, että ne eivät pysy ajan tasalla ja siten palvele käytännön kehitystyön ohjausta
Ne on suunniteltu vain arkkitehtien käyttöön ja vaativat usein erityisiä teknisiä sovelluksia.

Näiden haasteiden ratkaisemiseen olemme kehittäneet järjestelmäkartta -työkalun. Se yhdistää kolme eri näkökulmaa selkeäksi visuaaliseksi kartaksi:

Toiminnan kyvykkyydet: se kuvaa toiminnan prosessit/kyvykkyydet ja niiden tärkeimmät perustiedot: nykytilanteen toimivuuden, tavoitetilan ja trendin.
ICT-järjestelmien perustiedot: Kyvykkyyksien kannalta tärkeiden ICT-järjestelmät ja niiden tärkeimmät perustiedot kuten jäljellä olevan elinkaaren, kustannustason (kehitys ja ylläpito), kehityksen tehokkuuden ja riskitason.
Kyvykkyyksien ja järjestelmien leikkauspisteet: se miten järjestelmät tukevat tällä hetkellä kyvykkyyksiä: käyttökokemuksen, käytön laajuus, käyttämättömät mahdollisuudet, ja käytön trendi

Järjestelmäkartan perusajatus on, että se on työkalu, jonka äärellä voidaan käydä organisaation kannalta tärkeitä keskusteluja helpommin, tehokkaammin ja tuloksekkaammin kuin aikaisemmin:

Sidosryhmät ymmärtävät nykytilanteen samalla tavalla: ICT ymmärtää toiminnan näkökulman ja toiminta ymmärtää ICT:n näkökulman.
Kehitystarpeiden tunnistaminen mm. käyttökokemuksen parantamiseksi
Strategiset teknologiapäätökset - mitä järjestelmiä halutaan jatkossa kehittää; mihin liiketoimintakyvykkyyksiin investoidaan; mistä haetaan kasvua
Varautuminen elinkaaren loppumisesta tuleviin päivityksiin hyvissä ajoin
ICT-budjetin optimointi elinkaari- ja kehityskustannusten osalta
Pystytään tunnistamaan muutoksien vaikutukset molempiin suuntiin (toiminnan muutoksien ICT-vaikutukset ja ICT-muutoksien vaikutus toimintaan)
Liiketoiminnan kyvykkyyksien priorisointi ICT-kehityksen ohjaamiseksi oikeille osa-alueille

Kartta on abstraktiona yksi ihmiskunnan vanhimmista. Sen hyöty on päätöksenteon (mihin suuntaan mennä) tekeminen helpommaksi poistamalla niin paljon todellisuuden yksityiskohtia kuin mahdollista. Tämän periaatteen päälle järjestelmäkartta myös perustuu. Yrityksen teknologinen kyvykkyys suhteessa liiketoiminnan tarpeisiin tiivistetään yhdeksi kuvaksi - kartaksi, jonka avulla tehdään strategisen tason päätöksiä esimerkiksi siitä, mihin järjestelmiin investoidaan. Järjestelmäkartan avulla fasilitoidaan kokonaisuuden hallintaa ja tuodaan visuaalisen johtamisen keinoja myös teknologian käyttöön. Kaikissa eri käyttötarkoituksissa pyritään välttämään tyypillinen arkkitehtuurityöskentelyn informaatioähky ja keskitytään vain käsillä olevan päätöksenteon tukemiseen.

Artikkelin loppuosassa käydään tarkemmin läpi kaksi teemaa:

Järjestelmäkartan ymmärtäminen tarkemmalla tasolla
Miten järjestelmäkartta tehdään

Kuva tehty tekoälyllä

Järjestelmäkartan ymmärtäminen tarkemmalla tasolla

Järjestelmäkartan tarkempi käsittely on hyvä aloittaa sen keskeisistä periaatteista:

Järjestelmäkartta on taulukko, jossa on kaksi ulottuvuutta
- Kolumneina (x-akseli) toiminnot, jotka vaativat räätälöityjä ratkaisuja
- Riveinä (y-akseli) järjestelmät tai järjestelmäkokonaisuudet
Toimintojen/kyvykkyyksien suhde strategiaan visualisoidaan (kyvykkyyden tavoitetaso)
Järjestelmien kehityksen tila kuvataan ikoneilla
Toimintojen ja järjestelmien risteys (solu) on kartassa se kohta, josta luetaan miten ko. järjestelmä tällä hetkellä palvelee toimintoa
Solujen taustavärillä voidaan indikoida uutta kehitystä (vihreä), ongelmakohtia (punainen) tai lisäselvityksen tarvetta (keltainen)

Kyvykkyyksien/toiminnan kuvaaminen

Käydään ensiksi läpi kyvykkyyksien/toimintojen kuvaaminen. Ensimmäinen askel on tunnistaa x-akselilla käytettävät asiat. Tässä ei pidä jäädä sanoihin kiinni. Rakkaalla lapsella on monta nimeä. Joskus kyvykkyydet on oikea termi. Joskus se on prosessit tai toiminnot. Joskus jopa tiimit tai yksiköt. Tärkeintä on tunnistaa ne asiat joiden liittymä pintaa järjestelmiin halutaan kuvata.

Esimerkki auttaa usein ymmärtämään, joten esimerkiksi talouden ydinprosessit isolla organisaatiolla ovat:

Taloussuunnittelu ja budjetointi
Toiminnan ja talouden seuranta
Raportointi ja tilinpäätös
Maksuliikenne ja reskontrat
Investointien talousohjaus

Tämä olisi hyvä ensimmäinen arvaus jos tarkoituksena kuvat järjestelmäkartta taloudelle. Toki organisaation välillä on eroja. Tyypillinen määrä toimintoja järjestelmäkartassa on 5-15. Jos niitä on enemmän tällöin abstraktiotaso on valittu väärin: Kartta jossa on kymmeniä eri asioita muodostuu sekavaksi.

Käsiteltävä laajuus vaikuttaa paljon abstraktiotason valintaan. Jos järjestelmäkartta tehtäisiinkin koko hyvinvointialueen tukipalveluiden laajuudesta, niin x-akselilla voisi olla esimerkiksi

Henkilöstöpalvelut
Talouspalvelut
ICT-palvelut
Tilapalvelut
Ruokahuolto ja siivouspalvelut
Turvallisuuspalvelut
Hallinto ja päätöksenteon tuki
Viestintä
PMO

Järjestelmäkartan käyttötarkoituksesta riippuu oikea taso. Yksi yleinen tapa on tehdä järjestelmäkartat eri tasoilla: On laajempaa kokonaisuutta kuvaava järjestelmäkartta (esimerkiksi hyvinvointialueen tukipalvelut) ja yksityiskohtaisempi kartta, jossa pureudutaan esimerkiksi HR:n avainprosesseihin ja näiden järjestelmiin.

Kun olet tunnistanut x-akselille laitettavat asiat, on aika siirtymä kuvaamaan niiden attribuutteja:

Kyvykkyyden tavoitetaso
Tämänhetkinen kilpailu/suorituskyky
Trendi

Tavoitetaso toiminnalle tarkoittaa sitä mihin pyritään. Olemme käyttäneet kolmiportaista luokittelua: perusalue, erottuva, innovatiivinen.

Perusalue tarkoittaa: tavoitetasona on se että perusasiat sujuvat hyvin alan käytäntöjen mukaisesti. Tällöin ei pyritä erottumaan, vaan saavuttamaan perustaso kustannustehokkaasti. Esimerkkinä tästä voisi olla kirjanpito. Kunhan perusteet sujuvat hyvin, niin muuta ei tarvita.

Erottuva tarkoittaa sitä, että pyritään hakemaan kilpailukykyä järjestämällä tämä toiminta eri tavalla kuin avainperusprosessi olisi. Organisaatio voi hakea esimerkiksi kilpailukykyä kehittämällä kilpailijoihin verrattuna erilaisen tavan tehdä investointien talousohjausta toimialalla jossa takaisinmaksuajan ymmärtäminen on strategian kannalta erityisen tärkeää. Tällaiseen toimintoon käytetään yleensä valmisratkaisuja, mutta ne voidaan kustomoida tai konfiguroida soveltuvalla tavalla.

Innovatiivinen puolestaan tarkoittaa puolestaan, että luodaan aidosti uudenlainen tapa tehdä tätä toimintaa. Innovatiivisten kyvykkyyksien järjestelmät ovat yleensä organisaation omiin tarpeisiin tehtyjä. Tällaisia alueita organisaatiolla ei ole monia ja ne ovat strategian kannalta keskiössä ja kohdistuvat yleensä ydintoimintaan. Esimerkiksi uudenlainen tapa tehdä kotihoitoa, joka on kolme kertaa tehokkaampi kuin perinteiset lähestymistavat.

Tavoitetason määrittäminen on tärkeää, koska se ohjaa mm. sitä millaisia ICT-ratkaisuilla toimintoa pitää tukea. On tärkeää ymmärtää, että suurin osa organisaation toiminnosta on perustasoa, yleensä 10-30 % erottuvaa ja innovatiivisia toimintoja on vain yksi tai muutama per organisaatio.

Kilpailukyky kuvaa sitä mikä on toiminnon tai kyvykkyyden tämän hetken suoriutumistaso verrattuna samankaltaisiin organisaatioihin. Hyvä kuvaa sitä, että toiminta on selkeästi parempaa kuin keskimäärin verrokkiryhmässä sekä laadultaan että tehokkuudeltaan. “OK” kuvaa sitä, että ollaan aika samalla tasolla kuin verrokkiryhmä. Heikko puolestaan kuvaa sitä, että ollaan selkeästi jäljessä verrokkiryhmää laadussa ja tehokkuudessa.

Trendi puolestaan kuvaa sitä mihin toiminnan taso on kehittymässä viimeisen vuoden perusteella. Nouseva tarkoittaa, että kyvykkyyden taso (tehokkuus ja laatu) on parantunut selkeästi edellisellä tarkastelujaksolla. Vakaa tarkoittaa, että merkittäviä muutoksia ei ole tullut suuntaan tai toiseen ja laskeva sitä, että kyvykkyyden laatu ja/tai tehokkuus on laskenut viimeisen vuoden aikana.

Järjestelmien (tai järjestelmäkokonaisuuksien) kuvaaminen

Seuraavaksi vuorossa on valittuihin toimintoihin tai kyvykkyyksiin liittyvien järjestelmien tai järjestelmäkokonaisuuksien tunnistaminen. Tavoitteena taas suuruusluokka 5-15, mikä vaikuttaa siihen mikä abstraktiotaso valitaan: Mallinnetaanko esimerkiksi SAP yhtenä järjestelmänä, vai otetaanko sen pääkomponentit erikseen. Kokonaisuutena voisi sanoa, että järjestelmäkartta toimii parhaiten alle 10x10 ulottuvuuksissa, mutta 15x15 kokoiset voivat joskus olla toimivia.

Järjestelmien tunnistaminen on yleensä helppoa, kun vain käydään läpi mitä järjestelmiä toiminnoissa käytetään. Määrän kasvaessa valitaan ne joilla on suurin merkitys toiminnan kannalta.

Alla esimerkkilistaus julkisen organisaation talousjärjestelmistä:

SAP ERP
Cloudia
Kuntatieto
Power BI
KuntaHR
Tweb
Teams ja Power Apps

Järjestelmistä kirjataan ylös seuraavat perustiedot:

Odotettu elinkaari
Ylläpitokustannukset
Kehityksen tehokkuus
Riskitaso

Odotettu elinkaari kertoo vuosissa kuinka kauan järjestelmän uskotaan olevan vielä tuotantokäytössä. Vaihtoehtoja ovat: 1v, 5v, 10v, 15v, 25v. Tämä auttaa ymmärtämään miten järjestelmän kehittämiseen kannattaa panostaa ja koska on syytä alkaa suunnittelemaan korvaavaa järjestelmää. Vaikka se voi kuulostaa hassulta, yllättävän usein organisaatiot havahtuvat elinkaaren loppumiseen hyvin myöhäisessä vaiheessa.

Ylläpitokustannukset (jatkuvat kustannukset) kertovat kuinka kallista järjestelmän ylläpito on. Ylläpitokustannuksissa on käytetty suhteellista arviointimallia. Sen taustalla on toki tieto euroista, mutta esimerkiksi ERP-järjestelmän ja digipalvelun ylläpitokustannuksia ei voi suoraan verrata toisiinsa. Se olisi hieman kuin vertailisi auton ja lentokoneen ylläpitokustannuksia. Käytössä onkin viisi eri luokitusta (1-5). Näistä luokitus 3 tarkoittaa, että kustannukset vastaavat tyypillistä vastaavan järjestelmän jatkuvia kustannuksia. 4 tarkoittaa, että kustannukset on keskimääräistä kalliimpia ja 5 puolestaan sitä, että kyseessä on poikkeuksellisen kallis järjestelmä. Vastaavasti luokitus 2 tarkoittaa, että kyseessä on keskimääräistä edullisempi ratkaisu ja 1 sitä, että se on luokassaan halvimpia ratkaisuja. Luokittelu tehdään yleensä siten, että asetellaan janalle 1-5 erilaisten vaihtoehtoisen ratkaisujen sijainnit ja tunnistetaan mihin kohtaan ko. ratkaisu kuuluu.

Ohessa täysin keksitty esimerkki julkisen sektorin ERP-järjestelmien kustannustasojen luokittelusta (tekemiseen on hyödynnetty tekoälyä):

5: SAP, Oracle eBusiness Suite
4: Raindance, Oracle Netsuite
3: Sarastia365, Unit4 Business
2: Lemonsoft, Fennoa
1: Netvisor, Procountor

Kehityksen tehokkuus tarkoittaa kuinka paljon kehitystyön euroille saadaan vastiketta toimivina muutoksina. Tämäkin luokittelu on suhteellinen, mutta siinä vertaillaan järjestelmiä enemmänkin keskenään kokonaisvaltaisesti. Tämä johtuu siitä, että organisaatio voi ainakin osittain valita mihin järjestelmiin muutokset toteutetaan. Esimerkiksi toiminnan logiikan voi toteuttaa monesti digipalveluun tai taustalla olevaan ERP-järjestelmään ja kehitystyön kustannustaso usein ohjaa tätä valintaa. Kehitystyön tehokkuuteen vaikuttaa kaksi asiaa: kehitystyön hinta ja kuinka paljon asioita saadaan aikaiseksi per aikayksikkö tällä hinnalla. Luokittelu on myös viisiportainen. 3 tarkoittaa, että kehityksen kustannustehokkuus edustaa ICT-alan keskiarvoa. 4 on keskiarvoa tehokkaampi ja 5 edustaa alan parasta tuottavuutta. 2 puolestaan alan keskimääräistä tuottavuutta heikompaa ja kategoriassa 1 on alan vähiten kilpailukykyinen kehitys.

Alla muutamia esimerkkejä (keksittyjä tekoälyä hyödyntäen):

5 SAP HANA tai Apotti
4 Raindance, Lifecare
3 Oneforce, Dynamics 365
2 Intranet, hyvin tehty digipalvelu
1 PowerApps, Google Appsheet

Riskitaso kuvaa puolestaa muutoksiin liittyviä riskejä. Sekin arvioidaan suhteellisesti asteikolla 1-5. 3 kuvaa taas alan keskiarvoa. 4 ja 5 ovat keskiarvoa hauraampia. 1 ja 2 keskiarvoa vähemmän hauraita järjestelmiä. Muutoksen riskitasossa on kaksi osaa: todennäköisyys muutoksen epäonnistumiselle ja epäonnistumisen hinta/seuraukset. Eli jos epäonnistumisen vaikutuksia on vaikea/hidas korjata, niin järjestelmä on hauras, vaikka todennäköisyys epäonnistumiselle ei olisi erityisen suuri (4).

Ohessa keksittyjä AI-avusteisia esimerkkejä:

5 - Hauras potilastietojärjestelmä

4 - Hieman parempi potilastietojärjestelmä

3 - CRM

2 - Digipalvelu (hyvin tehty) 1 - Intranet, PowerBI raportti

Leikkauspisteet (toiminta ja järjestelmät)

Kun toimintojen ja järjestelmien perustiedot on mallinnettu, päästään mielenkiintoiseen keskusteluun. Miten järjestelmä palvelee toimintoa? Tässä keskustelussa katsotaan asiaa seuraavista näkökulmista:

Käytön laajuus
Käytön trendi
Soveltuvuus
Laajentamispotentiaali

Käytön laajuus kuvaa kuinka suuri osuus potentiaalisesta toiminnan potentiaalisista käyttäjistä hyödyntää järjestelmää. Jos kyseessä on esimerkiksi PowerBI talouden raportoinnissa kaikki controllerit ovat potentiaalisia käyttäjiä. Käytön laajuus kuvataan asteikolla 1-5. 1 Tarkoittaa, että vain pilottikäyttäjät hyödyntävät järjestelmää. 2 tarkoittaa, että järjestelmä on suhteellisen laajasti käytössä, mutta ei vielä enemmistöllä käyttäjistä. Kolme tarkoittaa, että puolet tai hieman yli käyttäjistä on ottanut järjestelmän käyttöön. 4 tarkoittaa, että valtaosa potentiaalisista käyttäjistä hyödyntää järjestelmää ja 5 järjestelmän täysimittaista käyttöä.

Käytön trendi kuvaa sitä onko järjestelmän käyttö kasvanut tai vähentynyt viimeisen kuuden kuukauden aikana. Vaihtoehtoja on kolme: nouseva, vakaa, laskeva.

Soveltuvuus kertoo sen miten hyvin järjestelmä soveltuu käyttötarkoitukseensa käsiteltävän toiminnon osalta. Se on yhdistelmä käyttökokemusta, tehokkuutta ja ominaisuuksia. Se arvioidaan suhteellisesti asteikolla 1-5. Vertailukohtana käytetään vaihtoehtoisia ratkaisuja mitä esimerkiksi muut käyttävät toimialalla. 3 vastaa toiminnon odotustasoa tämän tyyppiselle järjestelmälle. 4 ja 5 ylittävät odotustason. 1 ja 2 puolestaan alittavat sen.

Laajentamispotentiaali ei viittaa käyttäjien määrään, vaan siihen kuinka paljon hyödyllisiä optiota järjestelmässä on käytön sisällöllisessä laajentamisessa. Esimerkkinä PowerBI - käytön laajuus kuvasi osuutta ihmisistä, jotka käyttävät järjestelmää. Laajentamispotentiaali kuvaa sitä kuinka paljon hyödyntämättömiä toiminnallisuuksia järjestelmässä on, jota voitaisiin käyttää tässä toiminnossa. PowerBI:ssä esimerkkejä voisivat olla raporttivalikoiman laajentaminen ja dynaamisten raporttien hyödyntäminen. Laajentamispotentiaali kuvataan neliportaisella asteikolla. Jos potentiaalia ei ole, niin sitten ei laiteta ikonia ollenkaan. Muuten luokitellaan asteikolla:

Vähäistä laajentamispotentiaalia
Kohtuullista laajentamispotentiaalia
Merkittävästi laajentamispotentiaalia

Laatikoiden värikoodaus

Lisää informaatiota voidaan esittää laatikoiden värikoodauksella. Kaikkia laatikoita ei pidä missään nimessä “värittää”: ainoastaan ne mihin on perusteltu syy alla olevan kuvauksen perusteella.

Vihreä taustaväri laatikossa kertoo, että kyseisessä solussa on tällä hetkellä aktiivinen kehitystyö käynnissä. Jos vihreä väri on järjestelmän ja toiminnan leikkauspisteessä, niin se kertoo, että kehitystyö on sellaista, jossa järjestelmään tehdään toimintaan vaikuttavia (toivottavasti parantavia) muutoksia. Samassa yhteydessä usein - ei kuitenkaan aina - tehdään toimintatapa muutoksia. Jos vihreä väri on järjestelmäsolussa, se kertoo, että järjestelmään tehdään parannuksia (esim. infrastruktuuri), jotka eivät suoraan vaikuta toimintaan. Jos vihreä väri on toiminnassa, se kertoo, että toimintatapoihin tehdään muutoksia, mutta ne eivät vaikuta järjestelmiin.

Keltainen taustaväri kertoo puolestaan selvityksen tarvetta. Se tarkoittaa, että pitää tarkemmin tutkia mikä tilanne on. Tämä voi johtua esimerkiksi tilanteesta missä on ristiriitainen tilannekuva siitä miten järjestelmä palvelee jotain toimintoa. Tällöin keskustelua kannattaa jatkaa vasta kuin faktat on selvitetty. On tärkeää sopia kuka tekee selvitystyön ja millä aikataululla. Keltaista väriä voidaan käyttää järjestelmä-, toiminta ja leikkauspistesoluissa.

Punainen taustaväri visualisoi haastetta. Se toimii varoitusvärinä: tässä solussa on ongelma. Se varmistaa, että kaikki tiedostavat tilanteen. Tällaisissa tilanteissa on tärkeä sopia selkeät askeleet miten tilannetta lähdetään korjaamaan. Punainen taustaväri voi olla järjestelmä-, toiminta- tai leikkauspistesolussa riippuen siitä millainen haaste on kyseessä.

Nykytilanne ja tavoitetilanne

Järjestelmäkartta kuvaa aina jotain tiettyä ajanhetkeä. Se ei voi siis yhtä-aikaa kuvata nykytilannetta ja tulevaisuutta. Valitse siis näkökulma mistä lähdet tekemään järjestelmäkarttaa. Yleensä oikea valinta on nykytilanteen kuvaaminen. Kun osapuolilla on sama tilannekuva siitä missä ollaan nyt, tavoitetilanteesta voidaan käydä paljon parempia keskusteluja. Monessa tilanteessa pelkästään nykytilannetta kuvaava järjestelmäkartta on riittävä. Älä siis koe painetta kuvata välttämättä sekä nyky-, että tavoitetilaa.

Jos koet, että myös tavoitetilan kuvaaminen on hyödyllistä, se on usein helppo tehdä nykytilanteen kuvauksen pohjalta. Mietit vain mikä muuttuu ja näin saat tavoitetilan kuvauksen. Tämä voidaan tehdä esimerkiksi keskustelemalla nykytilanteen kartan äärellä, dokumentoimalla mahdollisia muutosehdotuksia post it-lapuille ja valitsemalla niistä ne jotka halutaan toteuttaa. Hyvä oletus tavoitetilanteen aikajänteestä on noin kaksi vuotta. Siinä ajassa ehtii tyypillisesti tapahtumaan riittävä määrä muutoksia jotta karttojen erot ovat selkeät. Toki tilanteet ovat yksilöllisiä.

Tiivistettynä:

Järjestelmäkartta kuvaa aina tiettyä ajanhetkeä
Aloita nykytilanteen järjestelmäkartasta
Usein tämä riittää
Jos tarvitset tavoitetilan kuvauksen, niin tee siitä erillinen kartta
Tavoitetilan voi luoda tunnistamalla muutoksia nykytilanteeseen
Noin 2 vuotta on hyvä aikajänne tavoitetilalle

Attribuuttien mukauttaminen

Esitellyt attribuutit järjestelmiin, toimintaan ja näiden leikkauspisteisiin on hyvä paikka aloittaa. Ja usein myös lopettaa. Ne sisältävät useimmissa tilanteissa tarvittavat tiedot. On inhimillistä miettiä heti, että olisi hyvä, jos siellä olisi myös tieto X, Y ja Z.

Kannattaa kuitenkin aloittaa valmiista attribuuteista ja kokeilla käytännön kautta onko tarve lisätiedoille todellinen.

Jos kuitenkin päätät laajentaa attribuutteja, niin valitse korkeintaan 1 tai 2. Näille riittää tilaa karttamallissa. Tee niille myös omat visuaaliset symbolit, jotta karttamainen käyttökokemus säilyy.

Järjestelmäkartan tekeminen ja hyödyntäminen

Järjestelmäkartta on suunniteltu kevyeksi työkaluksi. Et tarvitse pitkää ja raskasta projektia toisin kuten arkkitehtuurityössä monesti on tilanne. Ideana on, että voit aloittaa nopeasti ja kevyesti. Usein tämä riittää. mutta niihin tilanteisiin joissa tarvitset tarkempaa tietoa, niin voit täydentää sitä myöhemmin vaiheittain. Kannattaa aloittaa järjestelmäkartan tekeminen nykytilanteen kuvaamisesta.

Tärkein asia järjestelmäkartan onnistuneessa tekemisessä on fasilitaattori. Tarvitset henkilön, joka auttaa jäsentelemään järjestelmäkartan tiedot. Fasilitaattori juoksuttaa työpajoja tavalla, jolloin ihmisillä oleva hiljainen tietoa saadaan näkyväksi järjestelmäkartalle.

Lähes aina kannattaa aloittaa toimintojen/kyvykkyyksien tunnistamisesta. Keskustele toiminnan kanssa mikä heidän mielestään on järkevä tapa pilkkoa toiminta osa-alueisiin. Muista, että järjestelmäkartta on parhaimmillaan kun toimintoja on alle 10.

Kun toiminnot on tunnistettu, voit täydentää niihin perustietoja tavoitetasosta, nykytilanteesta ja trendistä. Joskus nämä saadaan kuvattua yhdessä keskustelussa, mutta usein on hyvä antaa toiminnan edustajille hieman aikaa miettiä asiaa kotitehtävänä ja kokoontua uudelleen parin päivän kuluttua. On myös hyvä haastaa toimintoa erityisesti tavoitetason suhteen. Muista, että monelle toiminnolle riittää perustaso.

Seuraavaksi vuorossa on toiminnoissa tarvittavien järjestelmien tunnistaminen ja niiden perustiedot. Tämä on hyvä tehdä ICT:n edustajien kanssa. Usein tiedot pystytään täydentämään yhdessä keskustelussa, mutta välillä on hyvä antaa heille hieman miettimisaikaa: kotitehtävä ja seuraava palaveri missä tiedot täydennetään. Sudenkuoppana on, että tietojen syöttämisestä tehdään liian eksaktia tiedettä. Attribuutit ovat suhteellisia arvioita. Yleensä ICT:n edustajilla on riittävä ymmärrys markkinatilanteesta, jolloin arviot voidaan tehdä suoraan. Joskus on hyvä tehdä kevyttä taustatyötä esim. kustannustasosta, mutta tästä ei pidä tehdä liian raskasta, koska sillä ei saada tarpeeksi hyötyä suhteessa panostukseen.

Leikkauspisteet on hyvä täydentää työpajassa missä on läsnä sekä IT:n että toiminnan edustajat. Joskus attribuuttien täydentäminen onnistuu keskustelemalla. Tällöin fasilitaattorin roolina on kirjata arvot keskustelun perusteella. Toisinaan tarvitaan määrätietoisempaa fasilitointia, missä voidaan käyttää erilaisia postit-lappuihin (fyysisiin tai virtuaalisiin) harjoituksia, että tiedot saadaan syötettyä riittävän nopeasti. Jos johonkin asiaan jäädään jumiin, niin se on hyvä laittaa hetkeksi parkkipaikalle ja siirtyä eteenpäin.

Järjestelmäkartan tekeminen on iteratiivista. Ensimmäisen version ei tarvitse olla täydellinen. Mitä nopeammin saadaan ensimmäinen versio aikaiseksi sen nopeammin päästään täydentämään sitä. Yleensä kun tällaisia kierroksia on tehty muutama, kartta on sellainen että se edustaa yhteistä tilannekuvaa. Tämä onkin tarkoitus.

Tekoälyä voi myös hyödyntää tarvittaessa joidenkin tietojen haarukointiin. Esimerkiksi kustannustaso voi olla yksi tällainen tieto. Kuitenkaan aina tämä ei ole tarpeen. Tekoälyä voi käyttää niissä tilanteissa, joissa jäädään arviointia tehtäessä jumiin. ChatGPT:n syvätutkimustoiminto on näissä tilanteissa oikein käytettyä hyödyllinen. Sitä voi pyytää esimerkiksi lähteiden perusteella arvioimaan järjestelmän perusattribuutit. Lisää tietoja syvähausta löytyy tästä artikkelista (LINKKI).

Kun järjestelmäkartta on saatu aikaiseksi, on tärkeää hyödyntää sitä. Tästä kannattaakin tehdä kevyt kaksiosainen suunnitelma:

Miten sitä hyödynnetään heti
Miten sitä hyödynnetään jatkossa osana toistuvia rutiineja

Heti - järjestelmäkartan hyödyntämisessä kannattaa ottaa heti pieni spurtti, jotta se tulee tutuksi kaikille ja jotta siitä saadaan hyötyjä irti. On hyvä aloittaa esimerkiksi tunnistamalla kartan avulla kehityskohteita ja priorisoimalla kehitystä valitsemalla yhdessä kehityksen painopisteitä. Tämän tyyppisiä keskusteluja järjestelmäkartta tukee hyvin. Järjestelmäkartta on myös hyvä apu budjetointiin, koska se auttaa tunnistamaan mahdollisesti tarvittavia uusia järjestelmiä tai muutoksia nykyisiin. Voi olla myös hyvä ajatus yrittää luoda tavoitetilalle esimerkiksi kahden vuoden päähän. Tämä voidaan kuvata tunnistamalla muutoksia ja valitsemalla niistä ne jotka halutaan toteuttaa (tiukka priorisointi). Muutokset voidaan kuvata tavoitetilaa edustavalla järjestelmäkartalla.

Toistuvat rutiinit - on myös tärkeää sopia miten järjestelmäkarttaa hyödynnetään jatkossa. Tämä hyödyntäminen on hyvä sitoa toistuviin rutiineihin. Esimerkiksi kerran kuukaudessa IT:n ja toiminnan välillä pidettävässä palaverissa voidaan luoda yhteinen tilannekuva käymällä kartta läpi aluksi. Kerran kvartaalissa toistuvassa suunnittelussa voidaan sen avulla priorisoida valittavia kehityskohteita. Budjetoinnin ja investointisuunnittelun yhteydessä hyödyntää sitä tarpeiden tunnistamiseen, perusteluun ja priorisointiin.

Artikkeli on kirjoitettu pohjautuen Henri Frilundin kirjoittamaan aikaisempaa artikkeliin, mutta sitä on laajennettu Teemu Toivosen toimesta.