TIEDOLLA JOHTAMISEN KÄSIKIRJA

Transkriptio

1 TIEDOLLA JOHTAMISEN KÄSIKIRJA Julkisrahoitteiset palvelut

2 Sote-tietojohtaminen 2 (112) SISÄLLYSLUETTELO 1 Käsikirjan tarkoitus ja tausta Käsikirjan käyttöohje Käsikirjan tausta Käsikirjan tarkoitus Kuntien Tiedolla johtamisen erityispiirteet ja haasteet 7 2 Tiedolla johtamisen tavoitteet ja hyödyt Paikallishallinnon ydinpalvelujen haasteet, vastaaminen niihin ja toiminnan kehittämisen keinot Julkisrahoitteisten palvelujen tiedolla johtamisen erityispiirteet Kuntien tiedolla johtamisen päätehtävät Julkisrahoitteisten palvelujen tiedolla johtamisen nykytila ja puutteet 13 3 Tiedolla johtamisen hyödyt JA MAHDOLLISUUDET julkisrahoitteisissa palveluissa 14 4 Tiedolla johtamisjärjestelmien toteutuksen ja käyttöönoton kriittiset menestystekijät 16 5 Paikallihallinnon organisaatioiden Tiedolla johtamisen viitekehys Julkisrahoitteisten palvelujen pääprosessit ja vaiheet Tiedolla johtamisen toiminnalliset moduulit Strateginen ja operatiivinen johtaminen Muuttuva ja organisaatiokohtainen sekä pysyvä tietotarve Ydinpalvelujen Tiedolla johtaminen verrattuna talouden ja resurssien johtamiseen Ulkoinen tietohuolto osana Tiedolla johtamista 26 6 Kuntien palvelutoiminnan onnistumisen tuloksellinen mittaaminen 28

3 Sote-tietojohtaminen 3 (112) 6.1 Mittareiden luokittelu Hyvien strategisten ja operatiivisten mittareiden määrityksestä 36 7 Tietojen kohdentuminen 39 8 Esimerkkejä hyvistä mittareista 41 9 Mittareiden lähtötiedot Tuottavuusmittauksen lähtötietojen suurimmat ongelmat ja haasteet Vaikuttavuusmittauksen lähtötietojen suurimmat ongelmat ja haasteet Kustannusten kohdistamismalli asiakas ja asiakassegmenttitasolle Julkisten organisaatioiden Tiedolla johtamisen mittausympäristö Julkisrahoitteisten ydinpalvelujen mittausympäristö Toimintaympäristön erot Toimintaympäristön erojen vaikutukset ja huomioiminen mittauksessa Henkilöresurssit ja niiden käytön erot selittävinä tekijöinä Miten vakioinnin avulla saadaan parempaa ja vertailukelpoisempaa tietoa? Vakioidun tiedon rajoitteista Miten ulkoisten ja rakennetekijöiden sekä oman toiminnan kehittämisen reaalinen vaikutus tulisi erottaa mittarilaskennassa? Mittaritiedon viitearvot ja niiden sisältö sekä esitysmuodot Tiedolla johtamisjärjestelmän vaiheittaisen toteutuksen ja käyttöönoton konsepti ja perus road map Tiedolla johtamisen kehittäminen tulee pohjautua lisäarvomalliin Tiedolla johtamisen kehittämishankkeen päävaiheistus BI-Strategia vaihe Oman palvelutoiminnan analysointi, kypsyystasoanalyysi BI-strategian luonti ja tiedottaminen Toteutettavuuden arviointi BI-Määrittely vaihe 67

4 Sote-tietojohtaminen 4 (112) Tavoitetilan ja 1.toteutusvaiheen vaatimusmäärittely Arkkitehtuurin määrittely ja suunnittelu PoC-toteutus ja testaus BI-Toteutus vaihe Tietovaraston toteuttaminen BI-sovellusmodulien toteuttaminen Järjestelmän käyttöönotto BI-Hyödyntämisvaihe Tiedolla johtamisen kehittäminen ja kokonaisarkkitehtuurinäkökulma Tiedolla johtamisen kehittäminen KA-mallin mukaisesti Tiedolla johtamissa tarvittavat tiedot ja ydintietojen [MD] hallinto [Data Governance] ja hallinta [Mater Data Management MDM] Vaiheittainen eteneminen, road map Tiedolla johtamisjärjestelmien tietotekniset arkkitehtuurivaihtoehdot Tietovarasto-pohjainen raportointiratkaisu Periaateratkaisu Käyttäjä- ja prosessien tukemisen näkökulma Arkkitehtuuri näkökulma Keskitetyn tietovaraston tietomallinnus Normaalimuotoinen tietovarasto Erilliset data mart-tiedostot ns. Kimballin malli Data Vault -mallinnus ETL-prosessi Yleiskuvaus Poiminta / Extract Yleistä tietojen poiminnasta SoTe tietojen poiminnat Muokkaus / Transform Yleistä tietojen muokkauksesta SoTe-tietojen muokkaus Lataus / Load Yleistä tietojen latauksesta SoTe-tietojen lataus Tietojen jalostaminen Yleistä 94

5 Sote-tietojohtaminen 5 (112) Data mart -tiedostot OLAP-kuutiot ja -järjestelmät Metatiedot Tiedolla johtamishankkeiden projektointimallit Scrum-malli Scrum-prosessimalli Scrum-roolit kehityksessä Scrum-kokoukset Scrum-seuranta Johdon käyttäjänäkymä tietoon eri Tiedolla johtamisen pääalueilla SoTe esimerkein Mittaritiedon käytettävyysvaatimukset johtamisessa Mittaritiedon tyypilliset esitystavat toiminnanohjauksen eri rooleissa LIITTEET 112

6 Sote-tietojohtaminen 6 (112) 1 KÄSIKIRJAN TARKOITUS JA TAUSTA 1.1 Käsikirjan käyttöohje Käsikirja jakautuu kolmeen pääosioon Osio 1, jossa on kuvattu julkisten palvelujen Tiedolla johtamisen ympäristöä ja annettu ohjeita Tiedolla johtamisen kehittämiseen, sivut Osio 2, jossa on kuvattu Tiedolla johtamisjärjestelmien arkkitehtuurivaihtoehdot, vaiheittaisen kehittämisen malli ja projektityömalli, sivut Osio 3 Liite, jossa on kuvattu SoTe-pilotin kautta esimerkein minkälaisella tiedolla tulisi julkisia palveluja johtaa, miten tiedon avulla voi kehittää palveluja ja mitä erityyppisten mittareiden käytössä tulisi huomioida Osio 1 ja 3 ovat tarkoitettu erityisesti palveluista vastaavalle ylimmälle johdolle. Osio 2 on tarkoitettu enemmän tietohallinnon ja tietotekniikan johdolle. Vaikka tämä käsikirja on tehty SoTe-alueen kehittämishankkeen yhteydessä, soveltuvat esitetyt mallit kaikille julkisille palveluille. Tässä on palvelun kohde = asiakas kuvattu henkilönä tai henkilöryhmänä, mutta malli soveltuu myös palveluihin joissa palvelun kohde on myös esinekohde tai toimija organisaatiokohde. 1.2 Käsikirjan tausta Tämä käsikirja pohjautuu valtiovarainministeriön SoTe-tietojohtamishankkeen yhteydessä tehtyyn määrittely- ja suunnittelutyöhön sekä Oulun, Tampereen ja Turun kaupunkien todellisessa tietoteknisessä ympäristössä toteutettujen pilottiympäristöjen toteuttamis- ja käyttökokemuksiin. Lisäksi on sovellettu muiden Tiedolla johtamishankkeiden ja ympäristöjen kautta saatua kokemusperäistä tietoa. Tässä käsikirjassa tarkastellaan Tiedolla johtamista toiminnallis-taloudelliselta kannalta. Siksi emme ole kuvanneet selkeitä perinteisiä talous- ja henkilöstösuunnittelun ja ohjauksen tietotarpeita eikä toiminnallisuutta. SoTe-tietojohtamishankkeessa kehitettiin yhdessä hankkeeseen osallistuvien kuntien kanssa kuntien sosiaali- ja terveystoimen johtamista ja päätöksentekoa tukevia työvälineitä sekä testattiin työvälineitä todellisessa asiakasympäristössä. Pääpaino on kuntien ydinpalvelujen Tiedolla johtamisessa tarvittavien tuottavuus-, vaikuttavuus- ja laatutietojen tuottamisessa. Hankkeessa luotuja menetelmiä testattiin ja pilotoitiin yli 65-vuotiaille annettavien säännöllisen kotihoidon palvelujen osalta todellisessa ICTtuotantoympäristössä Oulussa, Tampereella ja Turussa. 1.3 Käsikirjan tarkoitus Käsikirjan avulla ydinpalveluista ja niiden kehittämisestä ja toiminnan ohjauksesta vastaava johto luo yleiskäsityksen mitä Tiedolla johtaminen julkisissa palveluissa on ja miten Tiedolla johtamisjärjestelmän käyttöönotto mahdollistaa palvelutoiminnan entistä paremman kehittämisen. Käsikirjassa esitetty Tiedolla johtamisen malli pohjautuu palvelutoiminnan asiakaslähtöisyyden, tuottavuuden ja vaikuttavuuden olennaiseen kehittämiseen.

7 Sote-tietojohtaminen 7 (112) Kuntien Tiedolla johtamisen erityispiirteet ja haasteet Kuntien Tiedolla johtaminen kohdistuu lähinnä palveluihin. Palvelujen [kunnallisten ydinpalvelujen] erityspiirteet [mittaamisen kannalta] vaikuttavat olennaisesti Tiedolla johtamishankkeiden sisältöön ja työskentelytapaan ja tuloksena saataviin tietomäärittelyihin. Palvelujen [kunnallisten ydinpalvelujen] erityspiirteitä [mittaamisen kannalta] ovat mm Palvelun tuottaminen ja palvelun käyttö [kuluttaminen] tapahtuu usein samanaikaisesti [ei voida tehdä varastoon eikä itse kohdetta [palvelua] voi mitata kuin välillisesti jälkikäteen, vrt tavaratuotanto] Palvelutuote [hyödyke] on usein aineeton, joten sen saaminen kiinni mitattavaksi on vaikeaa Asiakas [palvelun kohde] osallistuu usein hyvinkin merkittävästi palvelun tuottamiseen [siis asiakas panostaa merkittävästi itse] Tuotosten [suoritteiden] ja vaikuttavuuden välinen suhde voi vaihdella hyvinkin merkittävästi, siis tarkoittaa että näiden välinen korrelaatio vaihtelee ja voi olla hyvinkin pieni Laadun merkitys on erilainen kuin fyysisissä tuotteissa [vaihtelut, merkitys ] Edellä kuvatut erityispiirteet vaikuttavat olennaisesti palvelujen mittaamiseen. Se, että palvelun käyttäjä osallistuu merkittävästi palvelun tuottamisvaiheeseen tarkoittaa sitä, että hänen toimintansa vaikuttaa olennaisesti myös palvelun vaikuttavuuteen. Palvelujen osalta hyvä esimerkki on sivistyspalvelut, joissa oppimisen tuloksiin vaikuttaa olennaisesti se miten oppilas itse toimii, pelkästään hyvä opetus ei takaa hyviä tuloksia ja oppimista [oppilas ei ole tunneilla / luennoilla, opetuksen seuraaminen ja aktiivinen toiminta, oppimisen motivaatio, omaehtoinen opiskelu jne]. Myös suuressa osassa hyvinvointipalveluja palvelun käyttäjän oma toiminta vaikuttaa olennaisesti palvelun tuloksiin. Hyvinvointipalveluissa kokonaisuuden kannalta [kokonaisvaikuttavuus, kustannusvaikuttavuus] ihmisten omalla palvelujen käyttöä edeltävällä [ja käytön aikaisella] toiminnalla on erittäin suuri vaikutus myös palvelutarpeeseen ja vaikuttavuuteen. Siksi hyvinvointipalvelujen mittaamisessa tulisi ottaa huomioon [mitata] myös asiakkaan oma toiminta ja pyrkiä toiminnan kehittämisessä vaikuttamaan myös asiakkaan omaan toimintaan. [Aineettomissa] Palveluissa mittaaminen on vaikeampaa kuin tavaratunnossa. Tavaratuotannossa toiminta jakautuu selkeästi tuotteen valmistukseen ja sen käyttöön. Valmistuksen aikana ja sen jälkeen tuotetta on helppo mitata. Samoin tuotteen ominaisuudet ovat tyypillisesti määritettyjä ja usein myös standardoituja. Palveluissa toiminnan vaikutusta on usein vaikea erottaa muun toiminnan vaikutuksista, koska mitataan asioita joihin vaikuttaa hyvin suuri joukko ulkoisia tekijöitä ja niiden väliset riippuvuudet ja yksittäiset vaikutukset on vaikea määrittää eikä niitä tunneta. Samoin palvelujen käyttö on pitkäaikaista ja niiden vaikutukset ovat usein hyvinkin pitkävaikutteisia [samoin hidasvaikutteisia ja vaikutusten muutosherkkyys pienehkö]. Aineettomien palvelujen laadun määrittäminen on usein vaikeata, joudutaan tyytymään välillisiin tekijöihin. Kunnallisten palvelujen erityispiirteet mittaamisen kannalta, Kunnallisiin palveluihin liittyen päätöksiä tekee moni taho Merkittävien osapuolien moninaisuus [asiakas, asiakkaan lähipiiri, kunta, valtio, palvelun tuottajat, kuntalaiset] Kunkin osapuolen roolit ja tavoitteet poikkeavat voimakkaasti toisistaan Ohjaus ei tapahdu juuri [kysynnän ja tarjonnan normaalilla lainalaisuudella] markkinoiden kautta, vaan yhteiskunnallisissa palveluissa merkittävä ohjaava tekijä on yhdenvertaisuus ja tasapuolisuus. Resurssirajoitteet muodostaa pääasiassa verotulot ja budjeteissa palveluille ohjatut resurssit [ei liiketaloudellinen tulokanta]

8 Sote-tietojohtaminen 8 (112) Päätöksenteko tapahtuu osittain demokraattisesti [poliittinen] päätöksenteon ylätasolla Julkinen ohjaus tarvitsee enemmän [ja toisenlaista] tietoa kuin markkinaehtoisessa toimintaympäristössä Päätöksenteon tuessa [johtamisessa] tarvittavien tietojen määritys tulisi tapahtua avaamalla kaikkien osapuolien päätöksentekoprosessit [roolit ja tavoitteet] [mallintamalla päätöksentekoprosessi eri tasoilla ja funktioissa].

9 Sote-tietojohtaminen 9 (112) 2 TIEDOLLA JOHTAMISEN TAVOITTEET JA HYÖDYT 2.1 Paikallishallinnon ydinpalvelujen haasteet, vastaaminen niihin ja toiminnan kehittämisen keinot Paikallishallinnolla on ja tulee olemaan suuria haasteita, mm kiristyvien rahoitusmahdollisuuksien, väestön ikääntymisen ja palvelutarpeen lisääntymisen sekä asiakkaiden kasvavien odotusten suhteen. Kunnat voivat vastata ko. haasteisiin vain kehittämällä voimakkaasti omaa toimintaansa palvelujen tuottavuuden vaikuttavuuden ja asiakaslähtöisyyden osalta Toiminnan tehokas kehittäminen on mahdollista vain, jos päätöksenteossa on käytettävissä oikea, luotettava, riittävän laadukas ja ajantasainen tieto omasta toiminnasta ja toimintaympäristöstä. Kuva 1 : Julkishallinnon palveluiden kehittämisessä on käytettävä erilaisia työkaluja Tuottavuutta, vaikuttavuutta ja asiakaslähtöisyyttä voidaan kehittää mm kehittämällä ja ottamalla käyttöön uusia tapoja järjestää ja tuottaa ydinpalveluja sisäisen toiminnan kehittämisellä johtamalla ja ohjaamalla toimintaa tiedon avulla

10 Sote-tietojohtaminen 10 (112) Tiedolla johtaminen tukee sekä palvelujen järjestämisen että tuotannon sekä sisäisen toiminnan kehittämistä. Näiden sisällä on käytettävissä monia työkaluja, joiden valinnan ja painotukset kunnan tulee tehdä oman lähtötilanteensa ja tavoitteidensa pohjalta. 2.2 Julkisrahoitteisten palvelujen tiedolla johtamisen erityispiirteet Julkisrahoitteisten palvelujen kehittämisessä tarvittava tieto poikkeaa joltain osin oleellisestikin markkinaehtoisen palvelu- ja tavaratuotannon tietovaatimuksista. Erot johtuvat ytimeltään siitä, että julkisten palvelujen rahoituksesta vastaavat merkittäviltä osin kunnat ja valtio. Asiakas ei maksa osalta palvelujen käytöstä suoraan mitään tai maksimissaan palvelun tuottamisen verran [poikkeus tietyt vapaasti kilpailtavat hyödykkeet kuten sähkö]. Näin palvelutoimintaa ei ohjaa kysyntä ja tarjonta, eikä kilpailutilanne vapailla markkinoilla eivätkä muut toimijat voi käytännössä tuottaa kyseisiä palveluja tuottavasti. Siten kilpailua ei ole joko lainsäädännöstä tai taloudellisuudesta johten. Julkisrahoitteiset palvelut jakautuvat käytännössä, pakollisiin (kunnan on järjestettävä ne kuntalaisille) vapaaehtoisiin (kunta voi järjestää niitä halutessaan) Vapaaehtoisissa palveluissa saattaa olla myös muita palvelutarjoajia. Rahoitusrajoitteiden takia valtiovalta tai kunnat itse määrittävät ketkä ovat oikeutettuja käyttämään (saamaan) palveluja. Näin rajoitetaan osaltaan kysyntää / käyttöä -> kustannuksia, koska hinta ei ohjaa kysyntää. Siten julkisissa palveluissa on useimmiten rajoitettu kysyntä ja myös tarjonta. Toisaalta lainsäätäjä ja valtiovalta määrittää kuntien tehtävät ja sitä kautta mitä palvelua on kuntien järjestettävä, kenelle palvelua on annettava ja muita palvelun saatavuuteen ja sisältöön liittyviä seikkoja. Siten julkisissa palveluissa ei käytännössä tarvita esim tuote- ja asiakaskannattavuustietoja eikä tietoja kilpailutilanteesta, samoin vaikuttavuustieto kohdistuu pääasiassa palvelun asiakasvaikutukseen [usein hyvin pitkäkestoinen vaikutus] eikä toiminnan vaikutuksesta myyntiin tai kysyntään kuten vapailla markkinoilla. Julkisissa palvelujen yksi erityispiirre on se, että siinä on monta merkittävää osapuolta, joilla on kullakin erilainen rooli toiminnassa. Samoin itse palvelutapahtumassa asiakasosapuolella on suuri ja erilainen rooli kuin markkinaehtoisissa palveluissa. Merkittävimmät osapuolet ovat Palvelun järjestäjä (kunta, myös osarahoitus) Palvelun tuottaja Asiakas (usein kuntalainen) Kuntalainen (veronmaksaja rahoittaa vaikkei itse käyttäisikään palvelua) Valtiovalta (osarahoittaja, omistajaohjaus, lainsäädäntö määrittää tehtävät) Elinkeinoelämä (sekä palvelutuottaja, palvelujen käyttäjä että välillinen rahoittaja) Merkittävimmät julkisia palveluja ohjaavat trendit asiakaslähtöisyyden korostuminen, tarkoittaa käytännössä sitä, että asiakastarve ohjaa toimintaa ja asiakas saa yhä enemmän valinnanmahdollisuuksia kenen, miten ja missä palveluja käyttää, siis asiakasohjaus lisääntyy asiakkaan oman osallistumisroolin lisäys myös itse palvelunkäyttötilanteessa ja tuotannossa

11 Sote-tietojohtaminen 11 (112) pyritään tehostamaan toimintaa siirtymällä reagoivasta palokuntatoiminnasta (reaktiivinen) ennakoivaan toimintaan (proaktiivinen) pyritään löytämään uusia kevyempiä ja edullisempi palvelumuotoja (avo-, neuvonta-, itsepalvelu ) ja näin vähentämään raskaampien ja kalliimpien palvelujen käyttöä pyritään ottamaan hyöty verkostomaisesta toimintamallista, johon kuuluu mm monituottajaympäristö, kolmas sektori ja asiakkaan lähipiiri. Tässä on tosin eri suuntiin menevää kehitystä, osa pyrkii vahvistamaan oman tuotannon osuutta ja toisessa ääripäässä pyritään ottamaan kaikki irti monituottajamallista. tarve suunnata niukat resurssit yhä vaikuttavammin Kehittämistoiminnassa on huomioitava, että palvelut ovat erilaisia pakollisuuden ja järjestämistavan suhteen esim perusopetus perusterveydenhoito sosiaalipalvelut kulttuuripalvelut liikuntapalvelut liikennepalvelut infra (sähkö, vesi, kaukolämpö) Ohjauksen ja johtamisen kannalta tulee julkisrahoitteista palvelutoimintaa voida tarkastella organisaatiorakenteen kautta eri hierarkiatasoilla palvelujen kautta eri hierarkiatasoilla asiakkaiden kautta eri tasoilla aikaan sidottuna, eri aikajaksoilta, eri laskenta- / tarkastelujaksoilta oman ja ulkoisen tuotannon osalta / tuottajittain ydin-, tuki- ja hallintotoimintaan eroteltuna johtamisen ja toiminnan ohjauksen eri rooleissa ja tasoilla (valtuustotasolta aina tiimin / yksittäisen työntekijän tasolle) Ydinpalvelutoiminnassa on useita osapuolia, josta syystä myös näkökulmia on monia. Merkittävimmät osapuolet ovat, Palvelun käyttäjä [osarahoittaja] asiakas Palvelun järjestäjä, palvelun omistaja [osarahoittaja] Palvelun tuottaja Palvelun maksaja, rahoittaja, ohjaaja = valtiovalta Elinkeinoelämä

12 Sote-tietojohtaminen 12 (112) 2.3 Kuntien tiedolla johtamisen päätehtävät Kuntien ydinpalveluissa on samoin kuin muuallakin tiedolla johtamisessa jäsennettävissä kaksi päätehtävää. Tiedolla johtamisen kaksi päätehtävää ovat: MITÄ mitä palveluja tarjotaan asiakkaille, mikä on palvelun sisältö, mille asiakasjoukolle, palvelujen määrä o Määritetään tavoitteet ja tarjotaan käyttöön resurssit MITEN miten palvelut järjestetään parhaiten, miten palvelut tuotetaan parhaiten Kuva 2 : Julkisrahoitteisten palvelujen päätöksenteon kysymykset ja vastaukset Ydinpalvelujen perimmäinen päämäärä on kokonaishyödyn maksimointi. mahdollisimman suuri saatava hyöty käytettävissä olevilla rajallisilla resursseilla Aidoimmillaan tiedolla johtaminen on sitä, että huomioidaan päätöksenteossa kaikki toiminnan osapuolet; heidän tarpeensa, panos tuksensa ja hyötynsä. Tällöin päästään kokonaistuottavuuden ja -vaikuttavuuden kannalta parhaaseen tulokseen ja estetään osaoptimointi sekä muu epätarkoituksenmukainen toiminta. Julkishallinnon organisaatio katsoo toimintaa lopulta kustannusvaikuttavuuden kannalta ja pyrkii siinä mahdollisimman hyvään tulokseen. Asiakas taas pyrkii palvelujen käytön kautta mahdollisimman suureen hyvinvointihyötyyn, sitä kautta elämänlaatuun ja onnellisuuteen. Mittaamisen kannalta tällä hetkellä ei ole käytössä elämänlaadun saatikka onnellisuuden mittareita eikä johdonmukaista mittaustapaa. Siksi

13 Sote-tietojohtaminen 13 (112) esimerkiksi pilottihankkeessa käytettiin asiakkaan toimintakykyä ja sen kehittymistä vaikuttavuuden mittaamisessa. Kuva 3: Palvelun järjestäjä hakee SoTe-palevuissa kustannusvaikuttavuutta ja asiakas hyvinvointihyötyä 2.4 Julkisrahoitteisten palvelujen tiedolla johtamisen nykytila ja puutteet Kuntien ydinpalveluissa ei olla tällä hetkellä käytetty hyväksi tiedolla johtamisen mahdollisuuksia. Johtamisessa ja toiminnan ohjauksessa tarvittavaa tietoa tuotetaan eri lähteistä erillisinä prosesseina ja tietojoukkoina. Toimintaa suunnitellaan hyvin pitkälle edelleen erikseen taloussuunnittelun ja toiminnansuunnittelun prosesseissa. Resursseihin ja niiden käyttöön liittyvä tieto raportoidaan pääasiassa taloushallinnon järjestelmistä euromääräisinä eikä niitä yhdistetä toiminnan tietoihin. Raportoinnin kohteina on organisaatiorakenne ja sen hierarkiatasot sekä palvelun tehtävä- tai tuoteryhmätaso. Toiminnan tiedot raportoidaan erikseen useista operatiivisista järjestelmistä pääasiassa suoritetasoisena. Jos suoritekustannuksia tai -hintoja lasketaan, ne ovat keskiarvoja, ei tuoteta asiakasryhmille tai asiakassegmenteille taikka asiakastasolla. Kustannuslaskentaa ei tehdä johdonmukaisesti eivätkä laskennan kohteet ole riittävällä tarkkuustasolla. Tuottavuutta ei pystytä laskemaan johdonmukaisesti eikä sen kehittymiseen vaikuttavia tekijöitä pystytä erottamaan. Toiminnan vaikuttavuuden mittareita ei ole pystytty määrittämään eikä vaikuttavuuden mittaamista pääsääntöisesti tehdä. Toiminnan laatua mitataan puutteellisesti, lähinnä pyritty mittaamaan osittain resurssien laatua, ei prosessien tai tuotosten laatua. Asiakaskokemustietoa ei ole tuotettu päätöksenteon pohjaksi. Nykyinen päätöksenteon tieto ei ole tasapainoista, koska ei ole tuotettu asiakasnäkökulmasta riittävää tietoa. Ei tiedetä riittävällä tasolla tietoa asiakkaan tarpeista, palvelukäyttäytymisestä eikä asiakkaan palvelukokemuksesta.

14 Sote-tietojohtaminen 14 (112) Ei pystytä ennakoimaan riittävällä tasolla tulevaa toimintaympäristön kehittymistä eikä oman toiminnan kehittymistä. Ennustamisen, simuloinnin ja optimoinnin menetelmiä eikä työkaluja ole käytettävissä. 3 TIEDOLLA JOHTAMISEN HYÖDYT JA MAHDOLLISUUDET JULKISRA- HOITTEISISSA PALVELUISSA On itsestään selvää, että jos päätöksentekijöillä on käytettävissä tarvittava oikea ja ajantasainen tieto, voidaan tehdä huomattavasti parempi päätöksiä ja kehittää toimintaa aivan eri tavoin kuin puutteellisen tiedon varassa toimien. Kun otetaan käyttöön tiedolla johtamista tukevia järjestelmiä ja palveluja ja sillä tuotettu tieto, voidaan löytää omasta toiminnasta eniten kehittämistä vaativat palvelut ja toiminnot, arvioida luotettavasti näistä kehittämiskohteista saatavia hyötyjä ja kustannuksia täten priorisoida oikein kehittämisen kohteet ja siten voidaan rajalliset resurssit suunnata tuottavimpiin ja vaikuttavimpiin kehittämiskohteisiin saada todellista tietoa miten kehittämistoiminta vaikuttaa tuottavuuden ja vaikuttavuuden kehittämistavoitteisiin nähden voidaan seurata johdonmukaisesti, jatkuvasti ja riittävän ajantasaisesti palvelutoiminnan onnistumista niin tuottavuuden, laadun kuin vaikuttavuudenkin suhteen saadaan oikeaa tietoa kokonaistuottavuudesta ja vaikuttavuudesta kun voidaan yhdistää eri toimintojen tietoja ja tarkastella laajempia palvelukokonaisuuksia voidaan suunnitella toimintaa niin, että samanaikaisesti nähdään toiminnan taloudelliset ja toiminnalliset vaikutukset ja tunnusluvut saadaan jatkuvaa ja ajantasaista tietoa palvelutoiminnan asiakasryhmäkohtaisesta tuottavuudesta ja vaikuttavuudesta sekä sen perusteella voidaan ohjata ja tehdä korjaavia toimenpiteitä entistä nopeammin ja sitä kautta taloudellisemmin saadaan todellista tietoa tuottavuuden ja vaikuttavuuden kehittymisestä ja kehittämistarpeista ja kohteista Tuotetun tiedon avulla voidaan olennaisesti parantaa toiminnan tuottavuutta ja vaikuttavuutta asiakaslähtöisesti. Useissa tutkimuksissa ja käytännön tiedolla johtamisen hankkeissa on havaittu, kuinka paljon eri kuntien toiminta ja tuloksellisuus poikkeaa toisistaan. Samoin organisaatioiden sisällä eri toimintayksiköiden välillä on hyvin suuria eroja tuloksellisuudessa. Kun erot yksiköiden välillä saadaan esille, voidaan varsin helposti ja nopeasti heikoimmat yksiköt kehittää tiedon avulla yhtä hyvin toimiviksi kuin parhaat yksikötkin. Kunnissa on valtavan suuri kehittämispotentiaali, mutta kehittämisen suuntaamista ja kohdistamista varten tarvitaan tietoa. Kuntien palvelutoiminnan kustannuksista selkeästi merkittävimmän osan muodostavat henkilöstöstä aiheutuvat kustannukset. Tällä hetkellä huonosti tiedetään heikosti työn kustannusrakenne; kuinka suuri osa kustannuksista aiheutuu ydinpalveluihin kohdistuneesta työpanoksesta, kuinka paljon tukipalveluihin ja hallintoon kohdistuneista työpanoksista. Avainkysymys on, kuinka suuri osa resursseista käytetään asiakkaalle lisäarvoa tuottavaan työhön. Tämän tiedon saa tiedolla johtamisen järjestelmistä. Henkilötyön tuottavuuden parantaminen on kuntien tulevan menestyksen avainkysymys. Palvelun järjestäjän roolissa on merkittävää tietää eri tuottajien tuloksellisuus niin tuottavuuden, vaikuttavuuden kuin laadunkin suhteen. Tämä tieto on saatavissa tiedolla johtamisen järjestelmistä. Näin voidaan kehittää monituottajaympäristöä.

15 Sote-tietojohtaminen 15 (112) Tiedolla johtamisen prosesseja, palveluja ja järjestelmiä kehittämällä saadaan olennaista taloudellista ja toiminnallista hyötyä kunnille. Oikein toteutettuna saatavat hyödyt ovat moninkertaisia verrattuna siihen uhrattuihin kustannuksiin. On huomioitava, että hyvin suunniteltu ja toteutettu tiedolla johtamisen järjestelmä tukee Strategisen tason päätöksentekoa ja ohjausta Kehittämistoimintaa Operatiivista johtamista ja ohjausta Ulkoisentietohuollon rationointia ja tehostamista Monituottajaympäristön hallintaa ja kehittämistä (mm palvelusetelit) Valtiovallan vastuulla olevaa toimintaa ja tiedonvälitystä valtion ja kuntien välillä sekä Jatkossa myös asiakkaiden palvelua

16 Sote-tietojohtaminen 16 (112) 4 TIEDOLLA JOHTAMISJÄRJESTELMIEN TOTEUTUKSEN JA KÄYTTÖÖN- OTON KRIITTISET MENESTYSTEKIJÄT Tiedolla johtamisympäristön toteutuksessa ja käyttöönotossa on monia haasteita ja sudenkuoppia, jotka voidaan voittaa, Tietotarpeet tietää johto = käyttäjät Johdon tulee sisäistää tiedon merkitys ja johdon tulee sitoutua Tiedolla johtamiseen Strategiaprosessi tulee nivoa osaksi Tiedolla johtamista Toiminnan kehittämisestä vastaavien osallistuminen ja toiminnan kehittäminen tulee nivoa osaksi Tiedolla johtamista Tietoteknisten ratkaisujen tulee tukea tiedon käyttäjien päämääriä Tietoteknisen toteuttamiseen tulee varata riittävästi hyvän ammattitaidon omaavia resursseja Edetään vaiheittainen toteuttamisessa ja käyttöönotossa, jatkuva oppiminen ja toteutuksen suuntaaminen suurimpia hyötyjä mahdollistavaan suuntaan Tulee pystyä turvaamaan tuotetun tiedon riittävä luotettavuustaso Tiedon käyttöympäristöt; oikea, vain tarvittava tieto oikeaan paikkaan ja oikealla tavalla esitettynä = selkeät tarpeen ja käyttötilanteen mukaiset käyttöliittymät

17 Sote-tietojohtaminen 17 (112) 5 PAIKALLIHALLINNON ORGANISAATIOIDEN TIEDOLLA JOHTAMISEN VIITEKEHYS Ydinpalvelujen johtamiseen ja kehittämiseen liittyvä päätöksenteko tulee tapahtua tiedon avulla. Kunnan sisäinen johtaminen tapahtuu monella tasolla. Tiedolla johtamisen kannalta ylimmällä päätöksentekotasolla on valtuusto ja alimmalla tasolla tiimiesimiestason johto. Päätöksenteon kriittisimmät osat keskittyvät tiimalasin suppilo-osaan, jolla alueella ylin virkamiesjohto ja luottamismiesjohto toimivat. Vaikka Tiedolla johtamisen kehitystyö usein alkaakin tämän kohdan tarpeista, tulee sen laajeta joka tapauksessa koko tiimalasin alueelle ja tasoille. On myös käytännön esimerkkejä siitä, että toimialoittain voidaan edetä tiedolla johtamisen kehittämisessä tuloksellisesti myös aloittamalla operatiivisen johtamisen ja toiminnan ohjauksen tarpeista, kunhan huomioidaan tavoitetila, jossa näin toteutetun ympäristön tulee tukea jatkossa myös ylemmän tason johtamista ja integroitua siihen kivuttomasti. Kuva 4 Tiimalasi kuvaa hyvin paikallishallinnon organisaatiota ja päätöksentekoa 5.1 Julkisrahoitteisten palvelujen pääprosessit ja vaiheet Julkisrahoitteisissa palveluissa ydinprosessit ovat asiakkaille tarjottaviin palvelukokonaisuuksiin liittyviä kokonaisuuksia. Kaikkia näitä ydinprosesseja tulee johtaa, ohjata ja kehittää tiedon avulla. Tiedolla johtamista tapahtuu siis kaikissa ydinprosesseissa ja kaikissa prosessin päävaiheissa. Prosessikartoissa johtaminen on usein mallinnettu omaksi pääprosessikseen. Johtaminen voidaan käsittää myös ydinprosessien yhteisenä tukiprosessina. Tiedolla johtaminen voidaan käsittää myös laajemmassa viitekehikossa, jossa se tukee myös kaikkia osapuolia toiminnan kehittämisessä ja jatkuvassa parantamisessa oman organisaation ulkopuolellakin.

18 Sote-tietojohtaminen 18 (112) Kuva 5 Prosessikartassa esitetään organisaation tärkeimmät prosessit Johtaminen jaetaan usein strategiseen, taktiseen ja operatiiviseen tasoon. Kokemuksen pohjalta olemme jäsentäneet johtamistoiminnan Strategiaprosessiin, Kehittämisprosessiin ja Operatiiviseen prosessiin Ydinpalveluihin liittyy nyt ja tulevaisuudessa niin suuria haasteita, että tuloksellinen operatiivinen toiminta edellyttää voimakasta toiminnan kehittämistä. Tätä kehitystoimintaa tukemaan tarvitaan riittävän oikeaa ja ajantasaista tietoa. Toisaalta taktisen tason tietoa käytetään niin strategisella kuin operatiivisellakin tasolla. Em syistä emme ole jäsentäneet ja mallintaneet erillistä taktista Tiedolla johtamisen tasoa.

19 Sote-tietojohtaminen 19 (112) Kuva 6 Tiedolla johtaminen tapahtuu strategia-, kehittämis-. ja operatiivisella tasolla Tiedolla johtamista tapahtuu monella organisaatio- / päätöksentekotasolla, ja kullakin näistä on tyypillisesti tarve käyttää päätöksenteossa omanlaista tietojoukkoa. Tiedolla johtamisen toiminnallisuus jäsentyy myös osatoiminnallisuuksiin. Kukin osatoiminnallisuus tuottaa erityyppistä tietoa päätöksenteon tarpeisiin. Kussakin osatoiminnallisuudessa tarvitaan myös hieman erityyppistä lähtötietoa.

20 Sote-tietojohtaminen 20 (112) 5.2 Tiedolla johtamisen toiminnalliset moduulit Julkishallinnon organisaatioissa Tiedolla johtaminen ollut tähän mennessä lähinnä operatiivisista tietojärjestelmistä tapahtuvaa perinteistä raportointia. Samoin toiminnan suunnittelua varten on tehty erilaista laskentaa. Raportointi ja toiminnan suunnittelun laskenta on tyypillisesti tehty erikseen talous- ja toimintatiedoille. Myös kustannuslaskentaa on tehty kriittisimmiltä osin. Samoin erillisissä toimintolaskentaprojekteissa on tuotettu toimintotason laskentatietoa. Tiedolla johtamisessa tarvittava lähtötieto syntyy palvelun reaali- ja rahaprosessissa. Tyypillisesti rahallista ja toimintatietoa sekä resurssitietoa hallitaan ja käytetään erillisissä tietojärjestelmissä T1 Kohteiden määritys ja mallinnus Tiedolla johtamisprosessissa tietoa kohdistetaan monen tyyppisiin kohteisiin. Tietojen kohdistamista varten kohteet tulee määritellä, luokitella ja muodostaa tarvittavat koodistot ja koodit. Nämä tiedot muodostavat rungon Tiedolla johtamisessa tarvittavasta master datasta. Kuva 7 Tiedolla johtamisen toiminnallinen viitekehys T5 - Kustannuslaskenta Toiminnallinen moduuli, jossa rahaprosessin yksikkö- ja palvelukohteille tuotetuista kustannustiedoista lasketaan kustannukset halutuille laskentakohteille. Kustannuslaskennan merkittävimmät ulottuvuudet ja ulottuvuuksien [laskentakohteiden] tasot ovat Palvelutoiminnan ulottuvuus [Palvelutuotehierarkia]

21 Sote-tietojohtaminen 21 (112) Palvelutuoteryhmätaso [oma/ulkoinen : ydin/tukipalvelut] Palvelutuotetaso [oma/ulkoinen : ydin/tukipalvelut] Suoritetaso [tuotetason erikoistapaus] [oma/ulkoinen : ydin/tukipalvelut] Asiakasulottuvuus o Asiakaskunta [faktinen, potentiaalinen] o Asiakassegmenttitaso [staattinen, dynaaminen] o Asiakastaso [anonyymi, tunnistettava] Organisaatioulottuvuus o o o o Kunta Toimiala Palvelualue Palveluyksikkö / Kustannuspaikka Suositus: Tietovarasto tulee suunnitella ja mallintaa niin, että siihen voidaan tallentaa kustannuslaskennan vaatimaa lähtö tietoa ja siten myös yleisessä Tiedolla johtamisen ympäristössä voidaan tuottaa tarvittava kustannustieto. T2 - Toimintolaskenta Toimintotason tietoa tarvitaan monen muun Tiedolla johtamismoduulin lähtötietoina, jolloin toimintolaskennan otoksen kautta saatuja ajureita käytetään tietyn ajan erityisesti palveluprosessien kehittämisessä, jolloin toimintotason laskentaa tehdään pääsääntöisesti projektityyppisesti. Toimintoryhmätason laskentaa voidaan tehdä myös jatkuvana laskentana, jolloin ajuritieto tuotetaan uudelleen laskentajaksoittain. Kriittisissä palveluissa voidaan toimintotason tietoa tuottaa myös jatkuvana laskentana. Suositus: Tietovarasto tulee suunnitella ja mallintaa niin, että siihen voidaan tallentaa toimintotason tietoa ja siten myös yleisessä Tiedolla johtamisen ympäristössä voidaan tuottaa toimintotason tietoa. I1 Selittävät mittarit/indikaattorit (selittävä tunnusluku) Ovat tietoa, jotka selittävät toimintaa kuvaavien osoittavien mittaritietojen arvoja. Selittävät mittarit kuvaavat erillisesti kunkin tekijän osuutta / vaikutusta. I2- Tunnusluvut Ovat tietoja, toimintaa kuvaavia perustunnuslukuja tai johdettuja tunnuslukuja. Tunnuslukukäsitteen rinnakkaiskäsitteitä : komponenttitason tiedot, perustiedot, perusluvut ] I3 - Mittarit

22 Sote-tietojohtaminen 22 (112) Ovat tietoa, jotka kuvaavat jalostetussa muodossa toimintaa. Mittaritiedot ovat toiminnan kehittämisen ja päätöksenteon kannalta olennaisia tietoja. I4 Osoittavat mittarit / indikaattorit (osoittava tunnusluku) Ovat tietoa, jotka kuvaavat / osoittavat mitattavan ilmiön tilaa kokonaisvaltaisesti. I5 Tavoitteet Ovat tietoa, joka kuvaa päämäärään pääsemisen osatekijöitä. Tavoitetieto koostuu tavoitteesta ja tavoitemittariarvosta. T6 Seuranta ja ohjaus Toiminnallinen moduuli, jonka avulla tuotetaan toimintaa kuvaavaa tietoa, jotta voidaan reagoida, suunnata ja ohjata palvelutoimintaa. Seurantatieto koostuu normaalin raporttitiedon lisäksi erilaisista mittari-, indikaattori- ja tunnuslukutiedoista. T10 Tilastointi Tilastoinnin tarpeet muodostuvat Sisäisistä tarpeista ja Ulkoisen tarpeista Tilastotiedot ovat osittain samoja kuin mitä muissa Tiedolla johtamisen toiminnoissa tarvitaan. T11 Arviointi Arviontitoiminta jakautuu Sisäiseen ja Ulkoiseen arviointiin Arviointitiedot ovat osittain samoja kuin mitä muissa Tiedolla johtamisen toiminnoissa tarvitaan. T7- Tutkimus Kuntien sisällä tehdään varsinaista tutkimustoimintaan varsin vähän. Kuitenkin kuntien strateginen ja operatiivinen johto tarvitsee päätöksenteon tueksi varsin moninaista vain tutkimustoiminnan kautta saatavaa tietoa. Vain suurimmilla kaupungeilla on merkittävää omaa organisoitua tutkimustoimintaa. Valtionhallinnossa on useita sektorikohtaisia tutkimuslaitoksia. Tutkimustoiminta tuottaa usein samantyyppistä tietoa kuin analyysitoiminnot. Tutkimustoiminta on useimmiten projektiluontoista, tiettyyn ongelmaan, kohdejoukkoon ja aikaan sidottua. Toisaalta joskus aikajänne voi olla pitkäkin, joten tietotuotanto voi lähellä jatkuvaa ja osa tutkimuksista tehdään jatkuvatyyppisesti toistamalla se määrävälein. T8 - Vertailuanalyysi

23 Sote-tietojohtaminen 23 (112) Toiminnallinen moduuli, jonka avulla vertaillaan ja analysoidaan yksiköiden välistä toimintaa ja tuotetaan jalostettuja analyysituloksia eri Tiedolla johtamistarpeiden tueksi. Usein vertailuanalyysiä tekee ulkoinen toimija, mutta sitä voi kyllä tehdä myös hyväksikäyttävä organisaatio tietojensa ja taitojensa puitteissa. T9- Vertailukehittäminen Toiminnallinen moduuli, jonka avulla tehdään organisaatiossa oman toiminnan vertailua ja arviointia omien yksiköiden ja oman toiminnan kannalta sopivien ulkoisten referenssiyksiköiden välillä. Tiedon avulla löydetään kehittämiskohteita ja voidaan seurata kehittämistoimenpiteiden vaikutuksia. Vertailukehittämisessä voidaan tehdä myös yksinkertaista yksiköiden välistä toiminnan analysointia. K6 Kertoimet, muuttujat, tunnusluvut Tutkimusten avulla pyritään luomaan tarkasteltavasta toimintaympäristöstä matemaattinen malli, jonka tietoja voidaan käyttää hyväksi edelleen Tiedolla johtamisen analyyttisissä [simulointi, ennustaminen, optimointi, prosessien kehittäminen ] moduuleissa. Tutkittava ilmiö mallinnetaan ja mallia analysoimalla erilaisilla menetelmillä saadaan tuotettua ilmiön käyttäytymistä kuvaava matemaattinen malli. Matemaattinen malli on usein käytännössä joukko funktioita, joissa on mukana muuttujia, kertoimia sekä matemaattisen mallin luottavuutta, tarkkuutta ja käyttökelpoisuutta kuvaavia tietoja esimerkiksi merkitsevyystietoa, riippuvuustietoja ja hajontatietoja. K7 Tilastollinen merkitsevyys On tietoa, joka viittaa todennäköisyyteen, jolla hyväksytään muuttujien välisen yhteyden olemassaolon tutkimusaineistossa. Tilastollinen merkitsevyys tarkoittaa tilastotieteessä sitä, että on epätodennäköistä, että tulos olisi sattumaa. "Tilastollisesti merkitsevä ero" tarkoittaa ainoastaan, että ero on olemassa, ei sitä että se olisi erityisen suuri tai muuten merkittävä. Tilastollisen testin varmuus ilmoitetaan 95 %:n, 99 %:n ja 99.9 %:n merkitsevyystasoina. Esim. 95 %:n taso merkitsee sitä, että on vain 5 %:n mahdollisuus sille, että otosaineistossa todettu yhteys ei ole todellinen perusjoukossa esiintyvä ilmiö. Tilastollisen merkitsevyyden käsitettä tarvitaan, koska tilastollisessa tutkimuksessa ei useinkaan ole käytettävänä koko perusjoukkoa, vaan ainoastaan rajallinen otos siitä. Otoksessa on perusjoukkoon verrattuna aina jonkin verran sattuman aiheuttamaa heilahtelua, joten otoksissa havaittu ero esimerkiksi keskiarvossa ei sellaisenaan todista mitään ennen kuin se on todettu tilastollisesti merkitseväksi. K8 Tilastollinen riippuvuus / korrelaatio On tietoa, joka kuvaa muuttujien yhteisvaihtelua. Tilastollisten riippuvuuksien toteaminen, selittäminen ja viime kädessä niiden hyödyntäminen esimerkiksi tulevaisuuden ennustamisessa on analyyttisen Tiedolla johtamisen keskeinen tehtävä. Pearsonin korrelaatio on tavallisin tarjolla olevista menetelmistä mitata kahden muuttajan välistä tilastollista yhteyttä tiiviisti yhden tunnusluvun eli korrelaatiokertoimen avulla. Palvelutoiminnan mallinnuksessa on tarve käyttää usein monimuuttajamenetelmiä. T12 Palvelujen ja resurssien allokointi : palvelujen kohdentaminen ja rajaus Toiminnallinen moduli, jonka tuottaman tiedon avulla kehitetään allokatiivista tehokkuutta Tehdään oikeita asioita, suunnataan resurssit oikein. Kuntien palvelujen osalta päätöksenteon I-päätehtävä on suunnata rajalliset resurssit mahdollisimman oikein niin, että niistä saadaan mahdollisimman suuri kokonaishyöty. Tämä tarkoittaa käytännössä toiminnan allokointia ja viime kädessä resurssien allokointia eri palvelujen/palvelutuotteiden kesken. Julkisrahoitteisten palvelujen osalta allokointitehtävässä on yksityisiä markkinaehtoisia palveluja enemmän reunaehtoja ja rajoitteita. Samoin kokonaishyödyn käsite on poikkeava.

24 Sote-tietojohtaminen 24 (112) Kokonaishyödyn maksimoinnissa myös julkisrahoitteisissa palveluissa merkittäväksi seikaksi tulee käytettävä laskentakorko. Allokointitehtävän tekee haasteelliseksi myös ennakoivien ja ennaltaehkäisevien palvelujen hyötyjen nykyinen tietotaso sekä hyötyinä käytettävä mittari ja arvonmääritys. Suositus: Aluksi allokoidaan resurssien suuntaamista suppealla palvelujoukolla. Myöhemmin otetaan käyttöön yhteismitallista hyötyä kuvaava tieto ja tuotetaan palvelukohtaista rajahyötyä kuvaavaa tietoa. T13 Prosessien kehittäminen Toiminnallinen moduli, jonka avulla voidaan kehittää prosesseja löytämällä kehityskohteet /-kohdat ja tuottamalla mittaritietoa kehittämistyön vaikutuksista. Prosessikäsitteen sisältö voi olla erilainen. Palvelujen kehittämisen osalta prosessi voidaan käsittää tilaajan näkökulmasta prosessina, joka käsittää laajempia tilaajan vastuulla olevia palvelukokonaisuuksia tuottajan näkökulmasta prosessina, jossa tuotantoprosessi vakautuu aliprosesseihin ja vaiheisiin asiakkaan kannalta palveluprosessiin, joka koostuu yksittäisten palveluiden käytöstä tai laajemmista palveluketjuista Tilaajan ja tuottajan näkökulmasta o o tietyn asiakasryhmän käyttämistä palveluista tai tiettyjen palvelujen kokonaisuudesta Prosesssien kehittämisen ja mittaamisen kannalta näillä eri prosessikäsitteillä ja näkymillä on hyvin erilaiset tietosisältövaatimukset ja toiminnalliset ja tiedonhallinnalliset tarpeet. Suositus: Jos käytössä tilaaja/tuottajamalli, otetaan ensin mittauskohteeksi tilaajaprosessit [palvelukokonaisuudet]. Toisessa vaiheessa määritetään olevan kokemustiedon avulla kriittisimmät ja palvelujen kehittämisen kautta suurinta hyötyä saavat asiakasryhmät [dynaamiset asiakassegmentit esim syrjäytymisvaarasssa olevat nuoret, palvelujen suurkuluttajat, moniongelmaperheet ] ja määritetään näille avainmittarit. Yksittäisten palvelutuotantoprosessien vaihemittauksessa tulisi tutkia erillisten tähän tarkoitukseen kehitettyjen prosessimittausvälineiden käytettävyyttä ennen toteutustyötä. T14 Simulointi Toiminnallinen moduli, jonka avulla voidaan simuloida erilaisia vaihtoehtoisia tilanteita ja toiminnallisia vaihtoehtoja tuottamalla oletetun tilanteen / toiminnan kautta syntyviä toiminnan tuloksia tunnuslukujen, mittareiden ja indikaattoreiden avulla. Suositus: Aluksi voi simuloinnissa käyttää aikaisemmasta omasta toiminnasta mitattuja laskenta-arvoja / parametreja [osittain ajurityyppisinä tietoina]. Toisessa vaiheessa omaa liiketoimintaa mallinnetaan tärkeimmiltä ja kriittisimmiltä osin, ja jos näin saadut uudet simulointiparametritiedot näyttävät relevanteilta otetaan niitä asteittain simuloinnissa käyttöön. Myös ulkoisten toimijoiden tuottamia parametreja otetaan jatkossa käyttöön, samoin voidaan ottaa omaan analyysiin ulkoisten referenssiorganisaatioiden tietoja. K9 - Skenaariot Ovat tietoa, joka kuvaa tulevaisuutta, ja jossa on esitetty organisaation tulevaisuuden toimintaympäristön/t sekä organisaation ja sen osapuolten toimenpiteet näissä ympäristöissä tavoitteiden saavuttamiseksi. Skenaariomenetelmällä luodaan loogisesti etenevä tapahtumasarja, jonka tarkoituksena on näyttää, miten mahdollinen, joko todennäköinen, tavoiteltava tai uhkaava tulevaisuudentila kehittyy askel askelelta nykytilasta." Skenaariomenetelmän käyttö johtaa loogisesti joko strategisen päätöksenteon uudelleen määrittelyyn tai sen täsmentämiseen organisaatiossa.

25 Sote-tietojohtaminen 25 (112) Skenaarioiden luonnissa käytetään hyväksi sekä aikaisemmasta toiminnasta tuotettua empiiristä tietoa että matemaattisten mallien kautta tuotettua analyysitietoa. Suositus: Aluksi luodaan vain toimintaympäristön muutoksen kautta syntyviä todennäköisimpiä tulevaisuustilanneskenaarioita. Näitä käytetään simuloinnin ja ennustamisen pohjatietona. T15 Ennustaminen Toiminnallinen moduuli, jonka avulla tuotetaan laskennallinen, tilastotieteeseen perustuva objektiivinen arvio siitä mitä tulee tapahtumaan. Ennuste ei ota kantaa siihen: Mitkä meidät tavoitteet tai budjetti on tai mitä me toivomme tapahtuvan? Ennusteessa käytetään lähtötietoina aikaisemmasta toiminnasta syntynyt paras myös ennustejaksoa kuvaava tieto sekä ennusteeseen valitaan todennäköisin skenaariotieto. Suositus: Aluksi käytetään todennäköisimmän skenaarion tilanteen pohjatietoja toiminnan ennustamisessa. Samoin ulkopuolisten ennustuslaitosten tuottamia tietoja käytetään pohjatietoina. Myöhemmin voidaan tuottaa myös analyyttisillä välineillä omia ennusteita. T16 Optimointi Toiminnallinen moduuli, jonka avulla pyritään löytämään paras päätöksentekovaihtoehto. Erityyppisiin optimointitehtäviin käytetään erilaisia optimointimenetelmiä ja algoritmeja. Käytännössä optimointi jakautuu ennalta tiedossa olevista vaihtoehdoista parhaan valintaan [lähellä simulointia] kaikkien mahdollisten vaihtoehtojen joukosta parhaan vaihtoehdon löytämiseen Suositus: Aluksi lasketaan vain tiedossa olevista vaihtoehdoista arvot ja näiden perusteella saadaan selville näistä paras päätösvaihtoehto. Myöhemmin otetaan käyttöön välineitä, joiden avulla voidaan esimerkiksi tuottaa tehokasta rintamaa kuvaavaa tietoa.

26 Sote-tietojohtaminen 26 (112) 5.3 Strateginen ja operatiivinen johtaminen Strateginen johtaminen painottuu päätöksenteon ylimmille tasoille ja se painottuu enemmän myös tavoitteiden luontiin ja suunnitteluun. Se poikkeaa tietotarpeiltaan myös organisaatioittain. Tavoitteiden välillä on suuriakin painotuseroja. Ohjaussykli on pitkähkö. Operatiivinen johtaminen painottuu strategian jalkautuksen kautta enemmän toiminnan seurantaan ja ohjaukseen. Ohjaussykli voi olla hyvinkin lyhyt ja tietotarve nopea ja tarvittaessa. 5.4 Muuttuva ja organisaatiokohtainen sekä pysyvä tietotarve Tiedolla johtamisessa osa tiedoista on organisaatiokohtaisia ja myös ajallisesti muuttuvia, koska esim strategisen tason tavoitteet ka kehittämiskohteet muodostuvat kunkin organisaation erilaisen lähtötilanteen, toimintaympäristön ja päämäärien kautta. Näiden tietojen avulla saadaan selville kehittämistavoitteiden onnistuminen ja ohjataan kehittämistoimintaa. Nämä tiedot ovat usein käytössä vain hankkeen ajan. Osa tiedoista on kaikille organisaatioille yhteistä ja ajallisesti varsin pysyvää. Näiden pohjalta voidaan seurata vertailukelpoisesti ja pitkäkestoisesti toiminnan kehittymistä niin organisaatioiden yksiköiden välillä kuin organisaatioiden keskenkin. 5.5 Ydinpalvelujen Tiedolla johtaminen verrattuna talouden ja resurssien johtamiseen Ydinpalvelujen Tiedolla johtaminen poikkeaa oleellisesti hallinnon [taloushallinto, henkilöstöhallinto ] Tiedolla johtamisesta. Tiedolla johtamisen järjestelmiä on kunnissa kehitetty tähän mennessä lähinnä keskushallinnon tarpeisiin, raportointikohteina lähinnä talouden ja henkilöstöhallinnon tiedot, talousnäkökulma on korostunut. Kuntien perustehtävä on ydinpalvelujen järjestäminen, ei hallinto. Kuntien ydinpalvelujen Tiedolla johtamisessa tarkastellaan toimintaa hyvin voimakkaasti asiakasnäkökulmasta. Perinteisesti hallinnon Tiedolla johtamisessa asiakaskunta on käsitetty yhtenä kokonaisuutena tai vain ikäryhmittäisinä luokkina. Ydinpalvelujen johtamisessa on tarve tarkastella asiakaskuntaa asiakassegmenteittäin. 5.6 Ulkoinen tietohuolto osana Tiedolla johtamista Ulkoinen tietohuolto on merkittävä osa Tiedolla johtamisympäristöä, koska merkittävä osa tarvittavasta tiedosta syntyy etenkin jatkossa ulkoisissa [muussa kuin omassa] organisaatioissa em ulkoiselle tiedolle ei ole useinkaan operatiivisissa järjestelmissä tallennuspaikkaa ulkoisissa organisaatioissa tapahtuva toiminnan tilastointi, arviointi ja muu tietotarve on jatkossa kustannustehokkainta toteuttaa tietovaraston kautta, varsinkin uusien raportointitarpeiden ja tilanteessa jossa ulospäin välitettävä tietojoukko sisältää monen lähdejärjestelmän tietoja

27 Sote-tietojohtaminen 27 (112) Kuva 8 Tavoitetilassa suuri osa ulkoisesta tiedonvälityksestä hoidetaan yritystason tietovaraston kautta

28 Sote-tietojohtaminen 28 (112) 6 KUNTIEN PALVELUTOIMINNAN ONNISTUMISEN TULOKSELLINEN MITTAAMINEN Strategiaprosessin kautta kehitettävät määritykset Kun strategisista tavoitteista johdetaan mahdollisimman hyvät toiminnan kehittämisen toimenpiteet sekä niille määritetään mahdollisimman hyvät mittarit, on tärkeä pystyä arvioimaan riittävällä tasolla toimenpiteen vaikutus tavoitteeseen ja millä mittarilla mahdollisimman hyvin voidaan todentaa toimenpiteen onnistuminen ja sen vaikutus. Kuva 9 Merkittävä osa tiedolla johtamisen mittareista pohjautuu strategisiin tavoitteisiin Strategiaprosessin kautta syntyvät mittarit. Strategiatyö jakautuu käytännössä ylätason strategian luontiin, jossa prosessissa määritetään näkökulmittain ja kriittisten menestystekijöiden mukaan strategiset tavoitteet ja näille toimenpiteet. Tässä yhteydessä myös tulee määrittää strategisen tavoitteen onnistumista kuvaavat mittarit ja toimenpiteiden onnistumista kuvaavat mittarit. Tällöin ko mittarit määräytyvät vain ylimmille organisaatio ja prosessitasoille. strategian jalkauttamiseen alemmille organisaatio- / prosessitasoille, jolloin määritetään alemmille tasoille ylemmän tason tavoitteita tukevat toimenpiteet ja niiden onnistumista kuvaavat mittarit. Tässä prosessissa käytännössä arvioidaan siis kustannustehokkaimmat kehittämistoimenpiteet, joiden avulla tulee päästä ylemmän tason tavoitteisiin, siis ajatuslogiikka pitää sisällään jo sen, että kehittämistoimenpiteen onnistuminen tulee selittämään osan tavoitteen toteutumisesta, jolle on oma osittava mittari määritetty. Näin kehittämistoiminnan mittarit ovat jo valmiiksi määritetty selittäviksi tiedoiksi [selittäviksi mittareiksi] [nämä ovat vain osa selittävistä mittareista]

29 Sote-tietojohtaminen 29 (112) Jatkuvaa toiminnan seurantaa ja ohjausta varten tulee lisäksi määrittää muut pysyvät selittävät tekijät = selittävät mittarit. Nämä eivät ole siis kehittämistoimenpiteiden kautta syntyviä vaan muita selkeitä tekijöitä, jotka vaikuttavat oleellisesti osittavan mittarin arvoihin, ja joita tulee jatkuvasti seurata. Näiden mittaritietojen avulla löydetään mihin korjaavia / kehittäviä toimenpiteitä tulee jatkuvan toiminnan seurannan yhteydessä kohdistaa. Kuva 10 Mittarit polveutuvat strategian jalkautusprosessista Riippuen valituista näkökulmien, havaitaan usein että käytännössä osa näkökulmista on toisille näkökulmalle edellytyksiä luovia. Esimerkiksi jos näkökulmana on henkilöstö / resurssit sekä prosessit / toiminnan tehokkuus ovat nämä näkökulmat selkeästi tuottavuus- ja vaikuttavuusnäkökulmalle edellytyksiä luovia. Siksi edellytyksiä luovat mittaristotkin usein tällöin asemoituvat tuottavuus- ja vaikuttavuusmittareiden alle.. Samoin usein laatumittarit asemoidaan vaikuttavuusmittareiden [myös talous] alle, koska palvelun laatu korreloi hyvin voimakkaasti [osittain sisältyy vaikuttavuuteen] vaikuttavuuden ja tuottavuuden kanssa.

30 Sote-tietojohtaminen 30 (112) Kuva 11 Usein vain tuottavuus- ja vaikuttavuusnäkökulmat kiteytyvät ylätasolle 6.1 Mittareiden luokittelu Mittaamista ja mittareita luokitellaan eri näkökulmista. Seuraavassa merkittävimmät luokittelutavat, käsitteistö on tässä pääasiassa tuottavuuteen liitetty, mutta kukin näistä on sovellettavissa myös vaikuttavuuteen ja laatuun. Tuottavuuden tason mittaus (absoluuttinen staattinen tuottavuusmittari) Tuottavuuden muutoksen mittaus (dynaamiset tuottavuusmittarit) Kokonaistuottavuus kattavin tuottavuuskäsite, joka määritellään tarkastelujakson koko tuotoksen ja sen aikaansaamiseksi käytettyjen kaikkien panosten suhteeksi. Kokonaistuottavuudessa otetaan täten huomioon kaikki tuottavuuteen vaikuttavat osatekijät ja panokset kokonaisuuden laskemiseksi. Osittaistuottavuus tarkoittaa kokonaistuottavuuden ja yhden panosryhmän välistä suhdetta, jolloin kukin osatuottavuus kuvaa oman panosryhmänsä käytön tehokkuutta. Tällä käytäntöön paremmin soveltuvalla mittaustekniikalla voidaankin tarkastella tiettyjen osatekijöiden vaikutusta kokonaistuottavuuteen. Suora mittaus mitataan suoraan tuottavuutta Välillinen mittaus valitaan mitattavia apukohteita, joista saatujen mittaustulosten kautta pyritään selittämään itse tuottavuutta. Tällaisia apukohteita voivat olla muun muassa ylituotanto, tarpeettomat kuljetukset, myöhässä olevat tilaukset, alhainen kapasiteetin käyttöaste, odotusajat, ylisuuret varastot ja runsaat poissaolot Ennakoivat [ennustava] voidaan muodostaa / saada käyttöön etukäteen, jota voidaan käyttää ennustamisessa

31 Sote-tietojohtaminen 31 (112) Reagoivat [selittävä] saadaan käyttöön vasta jälkikäteen, joten nämä kuvaavat mennyttä toimintaa Määrälliset kuvaavat määriä, esimerkiksi suoritemääräiset tuottavuusmittarit, jolloin tuottavuutta mitataan muun muassa syntyvä tuotosmäärän ja sen tekemiseen käytetyn työmäärän suhteella Laadulliset kuvaavat laadullisia tekijöitä [laatutekijä, asteikko/luokittelu ja arvo] Objektiiviset tuottavuusmittarit. Objektiiviset mittarit perustuvat määrälliseen informaatioon, jota voidaan mitata mahdollisimman suoraan kohteesta ja joka on mittaajan arvoista riippumatonta. Ovat johdettu selkeistä kaavoista ja tulokset ovat yksiselitteisiä. Mittavat sekä tuotoksia että toimintaa. Subjektiiviset tuottavuusmittarit. Niiden avulla voidaan kartoittaa erilaisten sidosryhmien arvioita organisaation tuottavuudesta. Usein mittaus suoritetaan kohdistamalla kysely tietylle sidosryhmälle. Subjektiivisina arvioijina voivat näin ollen olla organisaation johto, työntekijät tai vaikkapa asiakkaat. Subjektiiviset tuottavuusmittarit ovat mittareita, joilla pyritään selvittämään työntekijöiden tai yrityksen tuottavuutta henkilökohtaisiin mielipiteisiin, käsityksiin ja näkemyksiin perustuen. Niillä voidaan mitata myös sellaisten tekijöiden ilmenemistä, jota on vaikeaa havaita objektiivisilla, esimerkiksi tietojärjestelmien sisältämään dataan perustuvilla mittareilla. Ovat arvioita menestystekijän tilasta, suuntaa-antavia tietoja tilasta, epätarkkuustaso joskus merkittävä. Osoittavat tiedot, ovat tietoa, jotka kuvaavat / osoittavat mitattavan ilmiön tilaa kokonaisvaltaisesti. Selittävät tiedot, ovat tietoa, jotka selittävät toimintaa kuvaavien osoittavien mittaritietojen arvoja. Selittävät mittarit kuvaavat erillisesti kunkin tekijän osuutta / vaikutusta. Oikaisevat tiedot, ovat tietoa jotka kuvaavat esimerkiksi sellaisia olosuhdetekijöitä, joiden vaikutuksesta tulee osoittavia tai selittäviä tietoja oikaista vertailukelpoisiksi Suora mittari saadaan mittaamalla yhtä asiaa, esim. käytetyt työpäivät. Mittaa kohdetta välittömällä tavalla. Epäsuora mittari mittaa tarkasteltavaa ilmiötä kuvaavaa asiaa, joka liittyy siihen läheisesti, esimerkiksi epäsuorasti tuottavuutta kuvaavia virheiden määrää, henkilöstön vaihtuvuutta ja työssä jaksamista Johdettu mittari lasketaan suorista tai johdetuista, esim. käyntejä / työpäivä Indeksi- / luokkamittari jalostetaan suorasta tai johdetusta mittarista tai mittareista antamalla erilaisia painokertoimia sekä käyttäen jalostetulle mittarille luokitusta ja sitä kautta saatua luokka-arvoa Absoluuttista arvoa kuvaava mittari. jolloin mittarin arvo kuvaa ilmiön absoluuttista arvoa mittausasteikolla Suhteellista osuutta kuvaava mittari, jolloin mittarin arvo ilmaistaan osuus- / prosenttiarvona. Monessa tilanteessa suhteelliset osuusarvot kertovat selkeämmin ilmiöstä ja sen kehityksestä verrattuna absoluuttisiin arvojoukkoihin [esim työajan rakenne, ydin-tuki-hallinto osuus]

32 Sote-tietojohtaminen 32 (112) Kuva 12 Mittareiden luokittelu mittaustavan ja tietotyypin mukaan Julkisrahoitteisten ydinpalvelujen kokonaisvaltaisessa johtamisessa, toiminnan suunnittelussa ja toiminnanohjauksessa tarvitaan erityypistä tietoa. Vastaavissa hankkeissamme olemme jäsentäneet mittaritiedot alla olevan kuvan mukaisiin luokkiin. Mittareiden määrityksen ja BI-ympäristöön implementoinnin yhteydessä on hyvä tiedostaa luokittelu, eri luokkien tietojen käyttökohde, -tapa ja sisältö. Usein Bi-hanke vaiheistuu ja etenee myös tietoluokka kerrallaan. Samoin joudutaan ottamaan kantaa missä ympäristössä [operatiivinen ODS- Toimiala DW/BI Enterprise DW/BI] eri luokkien mittaritiedon jalostaminen on järkevintä tehdä. On otettava huomioon, että strategioiden luonti ja ylläpito tapahtuu myös eri tasoilla. Yleistettynä strategiatasot ovat, Organisaatiostrategia (enterprise / corporate level strategy) Toimialastrategia (business level strategy) Toimintostrategia (functional strategy) Tiedolla johtamisen kannalta ongelmaksi muodostuu usein strategioiden väliset ristiriidat, jotka havaitaan vasta mittarityössä. Toinen ongelma on hidas toimintaympäristön muutoksiin reagointi strategiatyössä [päästrategia valtuustokausittain esim]. Näin tavoitteisiin johtuvien mittariketjujen generoinnissa saattaa tulla ongelmia. Osa mittareista on samoja eri johtamisen ja toiminnanohjauksen tasoilla, tällöin useimmiten voidaan mittarien arvoja käyttää ohjauksessa myös tasojen välillä [tyypillisesti talous].

33 Sote-tietojohtaminen 33 (112) Osa mittareista on spesifisiä eri tasoilla, tällöin käyttö suoraan eri tasoilla tai mittaritietojen johtaminen alemmalta tasolta ei ole järkevää tai edes mahdollista [tyypillisesti vaikuttavuusmittarit]. Kuva 13 Palvelutoiminnan johtamisessa tarvitaan eri tilanteissa ja eri tasoilla erilaista tietoa

34 Sote-tietojohtaminen 34 (112) Erittäin toimivaksi tavaksi on muodostunut mittareiden luokittelu / jäsentäminen osoittaviin [LAG-type] selittäviin ja [Lead-type] ja oikaiseviin Kuva 14 Mittarit tulee jäsentää osoittaviin, selittäviin ja oikaiseviin Lead-tyypin mittareista osa on selittäviä ja osa myös ennustavia. Jako on osittain käyttötarkoituspohjaista, samaa mittaritietoa käytetään osittavan tietyn mittarin selittävänä tietona, mutta sama leadmittaritieto voi toimia muussa yhteydessä myös ennustavana tietona [=mittarin arvo tällöin ennustaa esim jonkin osoittavan mittarin tulevaisuudessa tapahtuvaa muutosta / kehitystä]. Puhtaasti selittävät mittarit jakautuvat vielä pysyviin toimintaa selittäviin ja toiminnansuunnitteluprosessin kautta syntyviin, määrätyn kehittämistoimenpiteen aikana käytettäviin, onnistumista selittäviin Strategia- ja toiminnansuunnitteluprosesseissa määritetään toiminnan kehittämisen painopisteitä, mitkä konkreettisesti näkyvät asetettuina toimenpiteinä [usein kehittämistoimenpiteinä], joiden onnistumisen mittaamista varten määritetään omat mittarinsa. Näillä kehittämistoimenpiteillä pyritään siis vaikuttamaan osittavan mittarin arvoon.

35 Sote-tietojohtaminen 35 (112) Kuva 15 Hyvä selittävä mittarisetti sisältää kehittämistoiminnan onnistumista selittäviä, pysyvää toimintaa selittäviä sekä ennustavia tietoja Kuvattaessa Tiedolla johtamisen prosessia ja mittaamista usein jatkuva toiminta jaetaan vain kahteen, strategiseen ja operatiiviseen tasoon. Taktinen taso erillisenä prosessina tulee selkeästi esille kyllä strategian jalkauttamisessa ja toiminnan suunnittelussa. Mittaamisen kannalta otetaan omaksi tasoksi usein myös kehittämisprosessi [käytännössä kehittämishanketaso], ei jatkuva kehittäminen]. Kuva 16 Muuttuvassa ympäristössä tarvitaan yhä enemmän tietoa joka syntyy oman organisaation ulkopuolella

36 Sote-tietojohtaminen 36 (112) Alimmilla päätöksentekotasoilla tarvittava tieto syntyy suurimmalta osin omasta toiminnasta. Mitä ylemmällä päätöksentekotasolla ollaan, sitä enemmän tarvitaan myös ulkoista tietoa. Ulkoinen ja sisäinen tieto tulee olla yhdistettävissä ja käytettävissä yhtenä kokonaisuutena. 6.2 Hyvien strategisten ja operatiivisten mittareiden määrityksestä Olemme kehittäneet yhdessä asiakkaidemme kanssa julkisten palvelujen Tiedolla johtamishankkeissa tuottavuus-, laatu- ja vaikuttavuusmittareiden määritysmenetelmän, joka on käyttökelpoinen kaikissa julkisten palvelujen Tiedolla johtamishankkeissa. Kuva 17 Mittareiden määritysmenetelmän kehikko SoTe-alueella on tiedossa, että hyvien mittareiden määritys ei ole aina onnistunut. Tiedolla johtamishankkeen yhteydessä on syytä ainakin tärkeimpien mittareiden osalta arvioida ovatko käytössä olevat mittarit tarkoituksenmukaisia ja hyviä. SoTe-alueen johdon ja toiminnanohjauksen mittareiden määrityksessä ja valinnassa tulee kiinnittää erityistä huomiota mittarin pätevyyteen [validiteetti, tarkoituksenmukaisuus] mittarin luotettavuuteen[reliabiliteetti] ja siihen, että otetaan käyttöön vain ehdottoman tarpeelliset mittarit otetaan ensin käyttöön kustannustehokkaat [käytännöllisyys] mittarit

37 Sote-tietojohtaminen 37 (112) Erityisen haastavaa SoTe-alueella on muutosherkkyyden ja mittarin arvoon kohdistuvan vaikutuksen tiedostaminen esimerkiksi asiakasrakenteen muutostilanteissa. Tämän haasteen osalta on hankkeissa kertynyt erittäin hyvä tietämys miten ja missä tilanteissa tulee mittaritietoja vakioida [tekijät ja laskenta], tuottaa asiakassegmenttitasolla tai suhteuttaa. Mittarin validiteetti Mittarin validiteetilla tarkoitetaan sen pätevyyttä eli sen hyvyyttä mitata juuri sitä, mitä sen on tarkoitus mitata - tarpeeksi kattavasti ja tehokkaasti. Mittaria on osattava käyttää oikeaan kohteeseen, oikealla tavalla. Mittarin reliabiliteetti Reliabiliteetti-sana tarkoittaa 'luotettavuus', 'käyttövarmuus' ja 'toimintavarmuus'. Jos mittari on täysin reliaabeli, siihen eivät vaikuta satunnaisvirheet eivätkä olosuhteet. Olosuhdemuutokset muutosherkkyys esim asiakasrakenteelle Mittarin käytännöllisyys kuvaa mittarin kustannustehokkuutta eli kuinka paljon nähdään vaivaa hyötyyn nähden. Toisaalta, jos mittari ei ole relevantti, se ei myöskään ole käytännöllinen. Mittarin relevanttisuus kuvaa mittarin olennaisuutta sen käyttäjän kannalta. Relevanssi on myös tilanne- ja käyttötarkoitussidonnainen ominaisuus, koska joissakin tilanteissa on tärkeää saada tietoa jostakin tietystä asiasta. Toisaalla samalla mittarilla ei välttämättä ole mitään käyttöä. Kuva 18 Mittareiden määritystaulukko Mittarikuvaustaulukon sisältö mittarin nimi mittarin luokka [tuottavuus, vaikuttavuus, laatu ja alaluokat] mittarin kuvaus huomioitavaa määritystilanne o strategiasta johdettu o pysyvä tyyppi = osoittava, selittävä, ennustava suora/epäsuora mittaus objektiivinen / subjektiivinen mittari validiteetti reliabiliteetti tuottamisfrekvenssi

38 Sote-tietojohtaminen 38 (112) laskennan perustiedot [komponentit ] ulottuvuudet Tiedolla johtamisen tietotarvekartoitusvaiheessa taulukko laajenee tai siihen tulee toinen osa, johon kuvataan mm missä tilanteissa tietoa käytetään, missä ulottuvuuksissa ja hierarkiatasoilla tietoa esitetään.

39 Sote-tietojohtaminen 39 (112) 7 TIETOJEN KOHDENTUMINEN Palvelutoiminnan tiedot kohdentuvat eri ulottuvuuksiin. Kuva 19 Palvelutoimintaa kuvaavien tietojen tärkeimmät ulottuvuudet ja hierarkiatasot Palvelutoimintaa tulee tarkastella tehtäväkäsitteen, palvelutuotekäsitteen ja prosessikäsitteen kautta. Tuotannontekijöitä voidaan tarkastella sekä tuotannontekijöittäin määrätietoina ja -määräisinä Tuotannontekijät/Kustannukset jaotellaan

40 Sote-tietojohtaminen 40 (112) Välittömiin Välillisiin Muuttuviin Kiinteisiin Tieto kohdistuu organisaatio-käsitteeseen. Organisaatioilla / osapuolilla / toimijoilla on erilaisia rooleja, mm palvelun järjestäjä, palvelun tuottaja, oma/ulkoinen tuotanto. -määräiset tiedot kustannusnäkökulma. Tieto kohdistuu asiakas-[palvelun kohde] käsitteeseen eri tasoilla asiakaskunta asiakassegmentti asiakas Palvelua voidaan toteuttaa/tuottaa rinnakkaisilla tuotantotavoilla. Tieto on sidottu aikaan. Palvelutoimintaa tulee tarkastella ydin-, tuki- ja hallintotoimintoihin jakautuneena Jotta tarvittava tieto voidaan tuottaa päätöksenteon tueksi, toiminnallinen tieto tulee kerätä prosessitapahtumatasolla. Mittaritiedon tuottamiseen asiakassegmenttitasolla on muonia syitä, Palvelujen suunnittelun ja ohjauksen päätöksenteko kohdistuu asiakasryhmiin -> tarvitaan asiakasryhmätason tuottavuus- ja vaikuttavuustietoa Asiakaskuntakohtaiset mittarit ovat muutosherkkiä [esim asiakasrakenteelle] -> sisäinen ja ulkoinen benchmarkaus asiakaskuntatasolla epävarmaa Asiakassegmenttikohtainen mittarilaskenta edellyttää asiakaskohtaista mittari / tunnusluku laskentaa -> asiakaskohtainen tuottavuus- / kustannustieto on erittäin arvokasta erilaisissa analyyseissä

41 Sote-tietojohtaminen 41 (112) 8 ESIMERKKEJÄ HYVISTÄ MITTAREISTA SoTe-hankkeessa sovellettiin mittarimäärityksissä kehitettyä mittarimääritysmenetelmää, jonka pohjalta valittiin todellisessa operatiivisessa ympäristössä tuotettavaksi seuraavat perusmittarit, Kuva 20 Esimerkki kompaktista pilotoidusta mittarijoukosta Palvelutoiminnan mittaamisessa tulee olla käytettävissä riittävästi tietoa myös sellaisista rinnakkaispalveluista, joilla on merkittäviä riippuvuuksia. Esimerkiksi säännöllisen kotihoidon osalta tällaisia rinnakkaispalveluja ovat omaishoidon tuen palvelut sekä suunnittelemattomien terveyspalvelujen käyttö. Siksi säännöllisen kotihoidon piirissä olevien asiakkaiden osalta tarvitaan kyseiset kustannustiedot. Samoin pilotissa tuotetut selittävät mittarit eivät pysty riittävästi kertomaan mitkä seikat selittävät toiminnan tason tai muutoksen. Samoin pilotteihin valittu mittaristo ei ollut riittävän tasapainoinen. Esimerkiksi asiakaskokemustieto puuttui, samoin sairaspoissaolotieto. Operatiivisella johdolla on lisäksi tarve porautua tarkemmin palvelutuotannon tunnuslukutietoihin. Tunnusluvut ovat osoittavien ja selittävien mittareiden lähtötietoja / välituloksia, joten niiden osalta tarvitaan vain julkaista ne (ei lisälaskentaa).

42 Sote-tietojohtaminen 42 (112) Kuva 21 Esimerkki tasapainoisesta ja kompaktista mittarijoukosta Käytännössä mittaritietojen tuottaminen vaiheistuu. Seuraavassa on esitetty tyypillinen 1. vaiheen mittarisisältö. Kuva 22 Esimerkki ensimmäisen toteutusvaiheen mittarijoukosta

43 Sote-tietojohtaminen 43 (112) Seuraavassa kuvassa on esitetty esimerkin omaisesti temaattinen mittaritaulu, jossa mittarinimen alla on vasemmalla esitetty absoluuttinen mittariarvo ja värikoodilla sen suhtautuminen tavoitearvoon sekä oikealla puolella suhteellinen muutostieto edelliseen mittaukseen verrattuna. Lisäksi mittarinimilaatikon väri kertoo absoluuttisen ja muutostiedon pohjalta säännöstön kautta lasketun yleisen toimintatasostatuksen. Kuva 23 Esimerkki mittareiden suunnitellusta käyttöliittymästä

44 Sote-tietojohtaminen 44 (112) 9 MITTAREIDEN LÄHTÖTIEDOT Mittaritieto on tyypillisesti laskentaprosessien kautta saatavaa, jalostettua tietoa. Jalostusprosessissa käytetään tarvittavia lähtötietoja, jotka syntyvät operatiivista palvelutoimintaa tukevissa tietojärjestelmissä. Ydinpalvelujen toiminta jakautuu reaali- ja rahaprosessiin. Reaaliprosessissa ja sitä tukevissa tietojärjestelmissä syntyy toiminnallinen tieto. Rahaprosessissa ja sitä tukevissa tietojärjestelmissä käsitellään rahayksiköissä olevaa tietoa, esim Käytettävissä oleva rahamäärä Käytetty rahamäärä Käytetyn rahamäärän kohdistaminen toiminnallisiin kohteisiin. Rahallinen tieto syntyy pääasiassa palvelutoiminnassa tarvittavien tuotannontekijöiden käytöstä. Toiminnallinen tieto tulee kerätä prosessitapahtumatasolla. Palvelutoiminta koostuu usein toiminnallisista kokonaisuuksista, joita halutaan käsitellä tietotuotannossa omina loogisina kokonaisuuksina, esim palvelukokonaisuus, hoitokokonaisuus, episodi, kurssi, projekti, hanke jne. Tämä tarve tarkoittaa käytännössä sitä, että operatiivisissa järjestelmissä tulee yksittäinen tapahtumatieto pystyä kohdistamaan ko kokonaisuuksille ja ko tunnustieto tulee tallentua operatiivisiin tietokantoihin mahdollisimman automaattisesti. Osittain käyttäjä joutuu huolehtimaan ko kokoavien tunnustietojen syöttämisestä toiminnan aikana. Toiminnan laatua kuvaava tieto tulisi pystyä generoimaan toimintatiedosta. Aina kuiten käytännössä tarvitaan myös erillistä laatumittausta ja laatutiedon erillistä keräämistä. Toimintaa halutaan yhä enemmän tarkastella prosessinäkökulmasta. Operatiiviset järjestelmät eivät tue prosessiajattelua, niissä prosessitapahtumat eivät kohdistu prosesseihin eivätkä niiden vaiheisiin. Joltain osin voidaan luoda säännöstöjä, joilla voidaan jälkikäteen prosessitapahtumia linkittää jälkikäteen mallinnettuihin prosessikohteisiin. Tarvittavien lähtötietojen kannalta kriittistä on, Lähtötietojen kattavuus Lähtötietojen laatu Lähtötietojen kohdentuvuus Suomessa ei ole käytössä tietojärjestelmiä, joissa palvelujen toiminnallinen, resurssi- ja rahallinen tieto olisi yhtenäisessä tietojärjestelmässä. Tiedolla johtamisessa toimintaa tarkastellaan kuitenkin kokonaisvaltaisesti eli rahallinen tieto halutaan kohdistaa kattavasti toimintatietoihin. Rahaprosessin kautta syntyvä tieto: Rahaprosessissa tapahtumatieto [vienti] kohdistuu primääristi organisaatiorakenteen mukaisiin yksiköihin tilitasolla [meno- ja tulotilit]. Alimpana organisaatiotasona on kustannuspaikka. Vienneissä tunnisteina/kohdistustekijöinä on käytettävissä myös asiakas ja palvelu. Kuitenkaan tapahtumatason tieto ei kohdistu riittävän kattavasti palveluiden osalta palvelun kohteeseen [loppuasiakas] tai palvelutuotehierarkian alimmille tasoille [palveluryhmä, palvelutuote, laskennallinen suorite]. Näin rahaprosessin tietojen avulla ei voida kohdistaa kustannuksia palvelutuotteille eikä palvelun kohteille. Siten palvelujen tietojohtamista tukevissa tietovarastoissa taloustietojen ei tarvitse olla tapahtumatasolla, vaan useimmiten laskentajakson kustannuspaikoittainen ja kustannuslajeittainen lähtötieto riittää. Reaaliprosessin kautta syntyvä toiminnallinen tieto: Erilaisissa palvelua tukevissa operatiivisissa asiakastietojärjestelmissä tallennetaan asiakkaan palvelutoimintaan liittyvää prosessivaihe tai palveluta-

45 Sote-tietojohtaminen 45 (112) pahtumatason tietoa. Operatiivisissa palvelujärjestelmissä ei ole aina Tiedolla johtamisen tarpeisiin soveltuvaa palvelutuoteluokittelua, johon tapahtumatason tieto kohdistuisi automaattisesti. Rahallinen tieto joudutaan kohdistamaan erillisessä prosessissa toiminnallisiin kohteisiin, palvelutuotehierarkian ja asiakashierarkian kohteisiin. Kuva 24 Kustannusten kohdistamisen päävaiheet Rahallisen tiedon kohdistaminen toimintaan tapahtuu kahdessa tasossa ja vaiheessa: Vaihe 1 Toiminnan menot kohdistetaan yleisen kustannuslaskennan sääntöjen ja periaatteiden mukaan palvelutuotehierarkian kohteille Vaihe 2 Palvelutuotteisiin kohdistuneet kustannukset kohdistetaan yksittäisiin asiakkaisiin Vaihe 2:ssa kustannustieto voidaan kohdistaa eri menetelmillä yksittäisiin asiakkaisiin ja asiakasryhmiin/ -segmentteihin. Tapa 2.1:ssä yksittäisten asiakkaiden laskentajakson palvelujen tuottamisessa käytettyjen tuotantovälineiden käyttötietojen [toimintatietoa] kautta lasketaan kullekin asiakkaalle laskentajakson kustannukset. Tätä tapaa käytettiin SoTe-Tiedolla johtamishankkeen määrittelyssä ja piloteissa. Tapa 2.2:ssa käytetään aikaisemmin tuotetun tuotannontekijöiden käytön kautta kullekin asiakasryhmälle -segmentille laskettuja suhteellisia kustannuskertoimia. Tällöin laskentajakson kokonaiskustannukset jaetaan edeltä laskettujen ns suhteellisten ajuritietojen pohjalta pohjalta yksittäisille asiakkaille ja asiakasryhmille. Esimerkkinä tästä esimerkiksi DRG-pisteiden tai RUGluokkien / CMI-lukujen kautta tapahtuva kustannuslaskenta. 9.1 Tuottavuusmittauksen lähtötietojen suurimmat ongelmat ja haasteet Tuottavuudessa lasketaan panosten ja tuotosten välistä suhdetta. Tuotoksina on yleisimmin palvelun määrää kuvaavat tunnusluvut, yleisin suoritteiden määrä tai jonkin palvelutuotehierarkiatason määrätieto. Panoksia kuvataan yleisimmin kustannukset -määräisinä tai sitten tuotannontekijän määrinä. Tuottavuusmittauksen suurin haaste on se, kuinka hyvin lähtötiedoista voidaan kustannukset kohdistaa palveluille ja asiakkaille. Kustannusten kohdistamisessa asiakkaille tärkeintä on saada riittävä lähtötieto siitä, miten tuotannontekijöiden käyttö kohdistuu asiakastasolla.

46 Sote-tietojohtaminen 46 (112) Palvelutoiminnassa merkittävin tuotannon tekijä on henkilöstö. Henkilötyön kohdistumistietojen kannalta toiminta jakautuu asiakkaiden luona tapahtuvaan palveluluun toimipaikoissa tapahtuvaan palveluun Asiakkaiden luona tapahtuvassa palvelussa on tieto henkilötyön kohdistuminen asiakkaille yleisesti ottaen paremmin saatavissa kuin toimipaikoissa tapahtuvassa palvelussa. Asiakkaiden luona tapahtuva palvelu edellyttää suunnitellut käyntitiedot ja yleensä myös käynnin toteumatiedot kirjataan tietojärjestelmiin. Samoin näissä palveluissa suoraan asiakkaille palvelua tuottavien henkilöiden osuus on suurempi kuin toimipaikoissa annettavissa palveluissa. Toimipaikoissa tapahtuvassa palvelussa henkilöresurssit ja asiakas kyllä pääsääntöisesti liittyvät tietojärjestelmissä yhteen esim ajanvaraustietojen kautta täsmentyen palvelun antamisen yhteydessä. Näissä palveluissa suurempi osa tuotannontekijöistä jää kohdistumatta yksittäiseen asiakkaaseen ja asiakkaan palvelun todellinen henkilötyöaika kirjautuu tietojärjestelmiin karkeammalla tasolla. Usein asiakkailla kustannuspaikkarakenne on sellainen, että siitä ei voi riittävällä luotettavuustasolla johtaa palvelutuote- / suoritetasolle kustannustietoja. Siksi yksittäisillä kustannuspaikoilla tulisi tuottaa ydinpalvelun kannalta mielellään vain yhtä palvelutuotetta tai palvelutuotteiden väliset jyvitystekijöiden tulisi olla luottavasti laskettavissa. 9.2 Vaikuttavuusmittauksen lähtötietojen suurimmat ongelmat ja haasteet Vaikuttavuutta parhaiten kuvaavien mittareiden osalta tarvittavan lähtötiedon keruuta ei tapahdu johdonmukaisesti osana nykyistä palveluprosessia. Siksi vaikuttavuuden mittareina joudutaan käyttämään hieman heikompia mittareita, joiden lähtötieto keräytyy jo nyt riittävällä kattavuudella ja laadulla tietojärjestelmiin. Näistä mittareista esimerkkinä palvelutarvetta kuvaavat tiedot ja mittaristot, joita voidaan käyttää johdetusti palvelun asiakasvaikutusta indikoivina tietoina. Tiedolla johtamisessa jalostettavat tiedot jalostetaan eri tietojärjestelmissä tallennetuista lähtötiedoista. Osa lähtötiedoista tosin käytännössä tallennetaan erikseen tietovarastoon.

47 Sote-tietojohtaminen 47 (112) 10 KUSTANNUSTEN KOHDISTAMISMALLI ASIAKAS JA ASIAKASSEGMENT- TITASOLLE Asiakkaiden luona tapahtuvassa palvelussa kustannukset voidaan kohdistaa asiakastasolle riittävän toimintatiedon avulla. Kuva 25 Asiakassegmenttitason tuottavuusmittarit jalostuvat asiakastasolla tuotetuista tuottavuustiedoista Laskennassa tarvittavat lähtötiedot: Toteutunut työaika [Titaniasta tai HR/Palkkajärjestelmästä] aika h Käyntitiedot [asiakastietojärjestelmästä] käynnin pituus [tai aloitusaika ja lopetusaika] käynnin aloitusaika [kellonaika tai ap / ip ] asiakas ID palvelua antanut henkilö / henkilöstöryhmä Toimintakykyluokkatieto [RAI tai Rava tai asiakaspalvelujärjestelmä]

48 Sote-tietojohtaminen 48 (112) asiakkaan toimintakykyluokka Kustannustiedot [laskettu taloustiedoista] kohdistettu palveluun kustannuslajeittain ydin- ja tukipalveluittain tilaaja ja tuottajajaolla Laskennassa palveluun kohdistuva kokonaiskustannustieto kohdistetaan yksittäisille suoritteille ja siitä kustannustieto aggregoidaan asiakas- ja asiakassegmenttitasolle. Jos kustannukset kohdistuvat eri tavalla toimintaan kustannuslajeittain, tulee laskenta tehdä kustannuslajeittain käyttäen kulloiseenkin kustannuslajiin parhaiten sopivaa kohdistustekijää. Säännöllisen kotihoidon osalta kaikkien kustannusten kohdistamistekijänä voidaan käyttää henkilötyön määrää, siksi alla olevassa prosessikuvassa on kokonaiskustannukset kohdistettu yhtenä kokonaisuutena toimintaan. Kuva 26 Asiakastason tuottavuustiedon laskentamalli

49 Sote-tietojohtaminen 49 (112) 11 JULKISTEN ORGANISAATIOIDEN TIEDOLLA JOHTAMISEN MITTAUSYM- PÄRISTÖ Julkishallinnon organisaatioiden järjestämissä ja osittain tuottamisen palvelun osalta on tyypillistä se, että oman toiminnan vaikutusten erottaminen ulkoisista vaikutustekijöistä on usein vaikeaa ja ulkoisten vaikutustekijöiden osuus saattaa olla kokonaisvaikutuksesta hyvin merkittävä. Merkittävimpiä ulkoisia mittaukseen vaikuttavia tekijöitä ovat muun toiminnan vaikutus o o muu kuin mitattava toiminta vaikuttaa olennaisesti mittarin arvoon asiakkaan oma toiminta vaikuttaa olennaisesti mittarin arvoon ulkoisten rakennetekijöiden vaikutus o riippuen mittarityypistä [mm johdetut mittarit, suhteutustekijät] mittarin arvo voi olla hyvin muutosherkkä ulkoisten rakennetekijöiden vaikutuksille Kuva 27 Oma toiminta ei selitä usein mittarin arvosta kuin vain osan 11.1 Julkisrahoitteisten ydinpalvelujen mittausympäristö Toimintaa kuvaava mittaustieto kertoo aina itse toiminnasta, mutta useimmiten mittarin arvoon vaikuttaa myös toimintaympäristön muutokset sekä eri organisaatioiden toimintaympäristöjen väliset erot. Tiedolla johtamisessa eri osapuolten välillä on usein erilaisia käsityksiä kertooko/kuvaako mittari totuudenmukaisesti toiminnasta. Usein mittarin arvoon ei luoteta tai sen mittausarvo ja sen merkitys asetetaan kyseenalaiseksi [=ulkoiset tekijöiden muutokset/erot vaikuttavat mittariarvoon enemmän kuin oma toiminta]. Mittauksessa on tärkeä pyrkiä erottamaan olosuhdetekijöiden vaikutus Toimintaympäristön erot

50 Sote-tietojohtaminen 50 (112) Toiminnalliset yksiköt poikkeavat rakenteellisesti eriasteisesti toisistaan. Eroavaisuudet ovat niin suuria, että niiden vaikutus tulee tietää ja tulee pystyä erottamaan ja mittamaan eroavaisuuksien vaikutus varsinaisen toiminnan vaikutuksesta Kuva 28 Paikallishallinnon organisaatioiden toiminta poikkeaa rakenteellisesti toisistaan Paikallishallinnossa mittauksen kannalta merkittävimpiä rakenteellisia eroja ovat Kuntarakenne-erot o o kuntakoko kuntatyyppi [tiiveys: elinkeinoalueen keskus, tiivis kaupunkirakenne, haja-asutustyyppi ja osuus] Väestörakenne-erot o o o o Ikäluokittainen väestörakenne Väestön tulotaso-, sosiaaliset, terveys-, sairastuvuus yms erot Tulotasoerot Huoltosuhde-erot Elinkeinorakenne-erot o Yksikön oma elinkeinorakenne [elinkeinojen suhteellinen osuus] Erot kunnan kasvussa o Kasvunopeus

51 Sote-tietojohtaminen 51 (112) o Kasvun rakenne [väestömäärä, väestörakenne, elinkeinorakennemuutos, työpaikkojen määrämuutos ] Palvelurakenne-erot o o o o Palvelujen järjestämistapa [oma palvelualue] Palvelujen volyymien väliset suhde-erot Tuotantotapa [oma, monituottajamalli, yhteinen, ulkoinen ] Organisoitumismalli - Tilaaja-tuottamalli Asiakasrakenne-erot o o Palvelutarpeen mukainen asiakasrakenne Palvelujen käytön mukainen asiakasrakenne Julkisten palvelujen osalta aletaan yhä enemmän varautumaan tuleviin suuriin muutoksiin, joita ovat Väestön ikääntyminen ja siitä johtuva huoltosuhteen voimakas heikkeneminen Palvelujen rahoituspohjaan ja mahdollisuuksiin Kun näitä asioita halutaan huomioida, tulee tarkasteltavaksi em rakennetekijöiden vaikutukset palvelujen käytön kehittymiseen ja rahoituspohjaan ja mahdollisuuksiin. Siksi tulee harkittavaksi tulisiko jatkossa ilmiöitä suhteuttaa rahoittavaan asiakasjoukkoon ja selkeämmin ottaa laskennoissa pohjatiedoksi rakenteen ennustettu muutos. Yksi kiinnostava mittari olisi taloudellisen tai väestöllisen huoltosuhteen tiedon tuottaminen kuntakohtaisesti. Palvelujen käyttö yli kuntarajojen lisääntyy. Tähän liittyvää reaali- ja rahaprosessia tukemaan tarvitaan jatkossa tuottaa mittaritietoa myös kuntatasolla. Tämä tuo uuden tason asiakasulottuvuuteen. Kuva 29 Kunnissa palveluja käyttävät yhä laajemmin myös ulkokuntalaiset

52 Sote-tietojohtaminen 52 (112) Toimintaympäristön erojen vaikutukset ja huomioiminen mittauksessa Kun yksiköiden toimintaa verrataan tulee huomioida riittävällä tasolla se, että Yksiköiden toimintaympäristön eroavat toisistaan Yksiköiden sisällä toimintaympäristö muuttuu ajan myötä Yksiköiden väliset ajan myötä tapahtuvat toimintaympäristön muutokset poikkeavat toisistaan Kuva 30 Organisaatioiden asiakasrakenne muuttuu ajan myötä Tuottavuuden mittari kertoo tuotosten ja panosten välisestä suhteesta. Tuottavuusmittareissa käytetään usein erilaisia suhteuttavia tekijöitä tuotannontekijöihin suhteutus väestömäärään suhteutus suhteutus aikaan eri tekijöiden välinen suhteutus Toimintaympäristön muutokset ja erot vaikuttavat hyvin eri tavalla ja eri asteisesti mittausarvoon riippuen siitä, mitä suhteuttavaa tekijää käyttää. Eri palveluissa on faktisen ja potentiaalisen asiakaskunnan välinen suhde hyvin eri tasoilla. Esimerkiksi perusopetuksessa on ko suhdeluku ihan eri tasolla kuin vaikka päivähoidossa ja toimeentulon saajissa.

53 Sote-tietojohtaminen 53 (112) Tuotoksiin vaikuttavat tekijät Yksikön väestömäärä ja väestön rakennetekijät vaikuttavat absoluuttiseen palvelutarpeeseen ja osittain asiakasrakenteeseen. Asiakasrakenteeseen vaikuttaa myös palvelun järjestäjän päätökset palvelutarjoomasta, -tarjonnasta ja ohjauksesta. Panoksiin vaikuttavat tekijät Asiakasrakenteella on oleellinen vaikutus tuotoksiin ja niiden tuottamiseen vaadittaviin panoksiin. Palvelujen tuotosten järjestäminen ja tuottaminen vaatii panoksia. Palveluja voidaan tuottaa omana tuotantona ostaa ulkoisilta tuottajilta Oman tuotannon ja ulkoisen tuotannon osalta tuotannontekijöiden käyttö ja niiden kustannukset poikkeavat, joten niitä tulee mitata erikseen. Ulkoisessa tuotannossa maksetaan tuotehinta + tilaajakustannukset. Eri palveluissa ja yksiköissä tuotannontekijöitä käytetään erilaisilla suhteilla ja volyymeillä. Tuotannontekijöiden käytöstä aiheutuu kustannuksia, siten eri palveluissa ja eri yksiköissä kustannusrakenne poikkeaa toisistaan. Kuva 31 Osa palveluista on elämänkaarivaiheeseen sidottuja ja asiakkaalla on erilainen rooli myös elämänkaaren eri vaiheissa Henkilöresurssit ja niiden käytön erot selittävinä tekijöinä

54 Sote-tietojohtaminen 54 (112) Julkisrahoitteisissa ydinpalveluissa merkittävin kustannustekijä on henkilöstö [ 70-95% kaikista kustannuksista]. Siksi erityisesti tämän kustannuslajin osalta tulle pyrkiä kustannusten kohdistamisessa ja laskennassa hyvään tasoon. Henkilöstöstä aiheutuvat kustannukset ovat eniten riippuvaisia Henkilöstörakenteesta [henkilöstö-/ammattiryhmien välinen suhde] Henkilöstön / henkilöryhmien palkkatasosta Henkilötyöresurssin palkanmaksuajasta suhteessa teoreettiseen henkilöstövolyymiin [palkallisen työajan osuus%] Henkilöstöresurssin käytettävyydestä palvelutoiminnassa suhteessa palkalliseen työaikaan Henkilötyön käytöstä palvelutuotannossa [ydinpalvelu- tuki -hallinto / välitön -välillinen] Työajan rakenne [päivätyö, ilta, yö, viikonloppu ] Työajan rakenne [normaali / ylityö] Kuva 32 Henkilöstöön kohdistuvien kustannusten komponentit Miten vakioinnin avulla saadaan parempaa ja vertailukelpoisempaa tietoa? Vakiointia tehdään ja ulkoisten olosuhde- ja ympäristötekijöiden vaikutusta huomioidaan esimerkiksi kun, koko omaa organisaatioita verrataan muihin vastaaviin organisaatioihin oman organisaation sisällä vertailtaessa eri yksiköitä keskenään vertailtaessa koko oman organisaation kehittymistä ajallisesti vertailtaessa eri yksiköiden toiminnan kehittymistä ajallisesti

55 Sote-tietojohtaminen 55 (112) Kuva 33 Vakiointia voidaan tehdä eri tekijöiden kautta Vakiointi - Koko oman organisaation benchmarkkaus muihin vastaaviin organisaatioihin Usein johdetut mittarit kuvaavat kahden tekijän välistä suhdetta, esimerkiksi palvelun kustannukset / asukas tai asiakas. Esimerkiksi mittari Yli 65-vuotiaiden säännöllisen kotihoidon kustannukset / kunnan asukas kuvaa tietyn asiakasjoukon kustannuksien määrää suhteessa koko kunnan asukasmäärään. Mittarin arvoon vaikuttaa suuresti kunnan väestörakenne ja erityisesti mikä on yli 65-vuotiaiden määrä suhteessa koko väestömäärään. Tällöin on haasteellista mieltää mitä oikein mittari todellisuudessa kertoo ja kuinka eri organisaatioiden mittariarvoja tulee tulkita vertailumielessä. Tämän mittarin osalta usein tehdään väestöön kohdistuva vakiointi, jossa lasketaan uusi ikävakioitu mittariarvo. Ikävakiointi kannattaa tehdä valtakunnan väestöön. Laskennassa voidaan vakioida kustannuksia, asukasmäärää tai ikäluokkaväestöä. Kun tehdään tällainen vakiointi, itse asiassa tuotetaan mittari [ikävakioitu kustannus / asukas], jonka arvot ovat kaupunkien kesken suhteellisesti samoja kuin Kustannus/yli 65-vuotias-mittarillakin. Ikävakioitu kustannus /asukas-mittarin arvoon vaikuttaa olennaisesti palvelun kaupunkikohtainen peittävyys. Periaatteessa voidaan vakioida mittari myös peittävyyden mukaan.

56 Sote-tietojohtaminen 56 (112) Peittävyydellä vakioitu kustannus/asukas-mittarin arvoon vaikuttaa olennaisesti se, kuinka paljon palvelua annetaan aikayksiköissä asiakasta kohti. Tämän palvelun aikamääränkin suhteen voidaan tehdä vakiointia. Tarkemmin kuvaus vakioinneista ja ulkoisten olosuhde- ja ympäristötekijöiden huomioimisesta mittaamisessa on käsikirjan liiteosassa. Vakiointi - Koko oman organisaation kehittymisen benchmarkkaus ajallisesti Usein ei ole käytössä valtakunnantason vakiointitietoja. Usein myös ulkoiset olosuhde- ja ympäristötekijät muuttuvat yksittäisen kunnan sisällä jo vuoden aikanakin. Tällöin voidaan ajallisessa vertailussa huomioida olosuhde- ja rakennetekijöiden vaikutus. Ajallista vertailua tehtäessä tulee rahan arvon muutos = inflaatio tai deflaatio huomioida laskennassa. Tämä tarkoittaa käytännössä sitä, että tulee laskea myös deflatoidut kustannukset ja siitä johdetut mittariarvot. Näin saadaan selville reaalisen kustannusmuutoksen vaikutus. Esimerkissä Tampereen kaupunki, säännöllinen kotihoito: Kun tarkastellaan kokonaiskustannuksia vuosina 2010 ja 2011, ne nousevat 4,82% (syynä nousuun asiakkaiden ikääntyminen, yli 65-vuotiaiden määrän kasvu ja siitä johtuva palvelutarpeen kasvu). Oheisessa ennustemallissa pohjana on tilastokeskuksen väestöennuste. Asiakastarpeen kasvu on ennustettu käyttäen SoTe-Tiedolla johtamishankeessa tuotettua empiiristä tietoa miten eri ikäryhmissä palvelutarve kehittyy ja kohdentuu eri ikäryhmissä MAPLe-luokkiin. Näin saadaan ennusteasiakasmatriisi, jossa kullekin matriisin alkiolle on tuotettu SoTe-hankkeessa myös asiakassegmenttikohtainen kustannustieto. Näin voidaan tehdä varsin tarkka kustannusennustelaskenta vuodelle Kun tarkastellaan asiakaspalveluvuoden kustannuksia 2010 ja 2011, ne nousevat asiakkaiden ikärakenteen nousun takia 0,29%. Siis Tampereen ikärakenteen kehittyminen nostaa asiakaskohtaisia kustannuksia varsin hitaasti. Kun tarkastellaan asiakaspalveluvuoden kustannuksia 2010 ja 2011, ja oletetaan, että valtakunnan asiakasrakenne olisi Oulun mukainen, olisi vakioinnin vaikutus Tampereen asiakaspalveluvuoden kustannuksiin +16,00%.

57 Sote-tietojohtaminen 57 (112)

58 Säännöllisen kotihoidon kustannukset Sote-tietojohtaminen 58 (112) Tuotettuja vakioituja arvoja, esitetään ja käytetään rinnan vakioimattoman arvon kanssa. Vakioitujen arvojen esitys Kustannukset 2010 Ikävakioidut kustannukset 2010 Asiakkkaan ikäluokkavakioidut kustannukset 2010 Asiakasrakenne vakioidut kustannukset 2010 Kuva 34 Esimerkki kustannusten vakioinnin tuloksista Kun näitä arvoja käytetään ajalliseen vertailuun tulee huomioida, että vakioinnin parametrien arvot myös muuttuvat ajan myötä, esimerkiksi valtakunnantason väestörakenne muuttuu kaiken aikaa. Tämä tulee huomioida, jos vakioituja arvoja käyttää ajallisessa tarkastelussa. Vuositasolla muutokset vakioinnin parametreissa ne ovat usein pienehköjä, mutta pitemmissä tarkasteluissa muutokset voivat olla suuriakin. Vakioinnin laskentaesimerkkejä on esitetty käsikirjan liitteessä Vakioidun tiedon rajoitteista Jos oman organisaation tietoja vakioidaan valtakunnantasolla, tulee huomioida, Vakioinnissa käytettävät valtakunnantason tiedot muuttuvat ajan mukaan Tämä tarkoittaa käytännössä sitä, että eri vuosina valtakunnantasoon vakioituja oman organisaation tietoja ei voi käyttää aikasarjatyyppisesti, koska ne eivät kuvaa todellista oman toiminnan reaalista muutosta Miten ulkoisten ja rakennetekijöiden sekä oman toiminnan kehittämisen reaalinen vaikutus tulisi erottaa mittarilaskennassa? Päätöksenteossa on tärkeää saada oikeaa informaatiota. Jokin mittariarvo kertoo määritelmänsä mukaisesti ilmiöstä. Usein mittarin arvoon ja sen kehittymiseen vaikuttaa erilaisia rakenteellisia ja ulkoisia tekijöitä. Parhaan informaatioarvon mittari kertoo, jos voidaan erottaa näiden tekijöiden vaikutus mittariar-

59 Sote-tietojohtaminen 59 (112) vosta ja sen kehittymisestä. Näin saadaan esille tärkin tieto, joka on usein miten oman toiminnan kehittämisen vaikutukset ovat. Esimerkiksi jos tarkastellaan palvelun kokonaiskustannusten kehittymistä, saadaan selville mikä osa on väestökasvun ja väestörakenteen, asiakasrakenteen sekä oman toiminnan kehittämisen vaikutusta. Alla olevassa kuvassa on kuvattu hankkeen yhteydessä testattua laskentamallia, jossa tuotetun asiakassegmenttikohtaisen kustannus- ja vaikuttavuustiedon ja ikäluokkakohtaisen väestöennusteen [lähtötiedot] sekä käyttäjän antamien asiakasrakenteen ja kustannus- ja vaikuttavuustekijöiden kehitysolettamien pohjalta laskentamalli tuottaa simuloidut /ennustetut kustannusten, tuottavuuden ja vaikuttavuuden kehittymisen mittariarvot. Kustannusten ja vaikuttavuuden mittarit on avattu niin, että nähdään mikä osuus kokonaismuutoksesta on rakenteellisten tekijöiden vaikutusta (väestömäärän kehityksen vaikutusta, ikäluokkajakauman vaikutusta, palvelurakenteen vaikutus, asiakasrakenteen vaikutusta) ja mikä on oman toiminnan kehittämisen vaikutusta (työn tuottavuuden kehittymisen vaikutusta, vaikuttavuuden kehittymisen vaikutusta). Kuva 35 Kaaviokuva toteutetusta simuloinnin ja ennustamisen laskentakoneesta Alla olevassa kuvassa nähdään, että verrattuna Tampereen säännöllisen kotihoidon toimintaa tietyillä ehdoilla vuosien 2010 ja 2011 välillä, säännöllisen kotihoidon kokonaiskustannukset kasvavat vuonna 2011: niin siitä väestökasvun ja rakenteen vaikutus on , asiakasrakenteen muutoksen vaikutus on , oman toiminnan kehittämisen vaikutus: o tuottavuuden kehityksen vaikutus on o Vaikuttavuuden kehityksen vaikutus on

60 Vaikuttavuusmuutos asiakspalveluvuosiin Vaikuttavuus-muutos Reaalituottavuus Kustannusmuutos Asiakasrakenne Väestökasvu ja - rakenne Kokonaismuutos Sote-tietojohtaminen 60 (112) Säännöllisen kotihoidon kokonaiskustannusmuutos Tampereella Kuva 36 Laskentaesimerkissä näkyy hyvin kuinka voimakkaasti eri tekijät vaikuttavat kustannusmuutoksiin Tarkasteltaessa toisentyyppistä asiakaskaspalveluvuoden kustannuskehitystä = asiakastuottavuusmittaria [asiakaspalveluvuoden kustannus] saadaan selville laskennassa, että säännöllisen kotihoidon asiakaspalveluvuoden kustannus nousee + 0,24 %, josta väestökasvun ja rakenteen vaikutus on -0,01 % asiakasrakenteen muutoksen vaikutus + 2,31 % oman toiminnan kehittämisen vaikutus o tuottavuuden kehittämisen vaikutus on -1,53 % o vaikuttavuuden mittaus -0,53 %

61 Sote-tietojohtaminen 61 (112) Asiakaspalveluvuoden kustannuskehitys Tampereella 3,00 % 2,50 % 2,31 % 2,00 % 1,50 % 1,00 % 0,50 % 0,00 % -0,50 % -1,00 % -1,50 % -2,00 % 0,24 % -0,01 % Kokonaismuutos Väestökasvu ja - rakenne Asiakasrakenne Reaalituottavuus Kustannusmuutos -1,53 % Vaikuttavuus-muutos -0,53 % Kuva 37 Laskentaesimerkissä näkyy hyvin kuinka voimakkaasti eri tekijät vaikuttavat tuottavuusmittariin Tässä nähdään, että eri tekijöiden suhteutetuissa mittarityypeissä ulkoisten ja rakennetekijöiden vaikutuksen osuus on erilainen. Täistä esimerkeistä nähdään myös selvästi, että ulkoisten ja rakennetekijöiden vaikutus on usein hyvin merkittävä. Tämä tarkoitta sitä, että ilman ulkoisten ja rakennetekijöiden vaikutuksen esille ottamista kokonaismittarista ei pystytä tulkitsemaan oman toiminnan vaikutusta mittariarvon kehittymiseen. Siksi on suositeltavaa, että kriittisimmistä mittareista erotetaan ulkoisten ja rakennetekijöiden vaikutus. Tässä esitetyt esimerkkilaskennat on kuvattu yksityiskohtaisemmin käsikirjan liitteessä Mittaritiedon viitearvot ja niiden sisältö sekä esitysmuodot Toimintaa kuvaava mittaustietoa halutaan käyttää eri päätöstilanteissa ja erityyppisissä toiminnoissa aina tarkoituksenmukaisesti. Tyypillisimpiä mittaustiedon käyttö-/esitystilanteita ovat, mittarin tieto esitetään absoluuttisena mittausarvona mittaritieto esitetään yhdessä vastaavan mittarin historiatiedon [aikasarja] kanssa mittarin tieto kuvaa tapahtunutta muutosta kahden mittauksen välillä mitattua tietoa verrataan tavoitteen mukaiseen arvoon mitattua tietoa verrataan herätteiden / hälytysten raja-arvoihin esitetään mitattu tieto yhdessä ennustetiedon kanssa mitattua toimintaa verrataan referenssitoimintaan, joka voi olla esim o muut yksiköt [sisäinen benchmarkaus], koko organisaation keskiarvo o ulkoiset referenssiorganisaatiot [verrokkiorganisaatiot] o kansallisen tai aluetason toiminta

62 Sote-tietojohtaminen 62 (112) Ilmiön mitattu arvo [mittarin arvo] esitetään lähes aina absoluuttisena arvona. Absoluuttinen arvo esitetään tyypillisesti yhdessä historiatiedon [aikaisemmat mittariarvot] kanssa. Näin voidaan havainnollistaa toiminnan kehittymistä. Absoluuttista mitattua arvoa halutaan verrata tavoitteen mukaiseen mittariarvoon. Yksittäisen tavoitearvo lisäksi usein määritetään ohjaustiedon pelkistämistä ja havainnollistamista varten tavoitearvosta poikkeavia ns liikennevalovyöhykkeiden raja-arvoja, esim vihreän, keltaisen ja punaisen alueen raja-arvot. Erilaisia herätteiden ja hälytysten raja-arvoja käytetään mahdollisimman nopean ja reaaliaikaisen reagoinnin tarpeisiin. Herätteet ja hälytykset hoidetaan sovittujen informaatiokanavien kautta [työpöytäherätteet, sähköpostit, tekstiviestit ]. Hälytys- / heräteraja voi olla eri kuin keltaisen ja punaisen alueen välinen raja-arvo. Kuva 38 Tavoitteille ja hälytyksille määritetään raja-arvot, jotka halutaan myös esittää mittariarvojen kanssa Usein on johdolle / toimintaa ohjaaville henkilöille on merkittävämpää ja havainnollisempaa välittää tieto toiminnan muutoksesta, sen suunnasta ja voimakkuudesta kuin absoluuttisesta arvosta. Tyypillisesti tällöin esitetään muutos suhteellisena [esim prosentuaalisesti]. Kuva 39 Muutostieto on usein olennaisempaa käyttäjälle kuin absoluuttinen mittausarvo

63 Sote-tietojohtaminen 63 (112) Toiminnanohjauksessa oikeiden ja tehokkaimpien kehittävien toimenpiteiden löytämistä auttaa liittämällä omalla vastuulla kuvaavaan mittaustietoon sopivien referenssiyksiköiden vastaava tieto mikäli se on saatavissa. Tällöin oman toiminnan sisäinen ja ulkoinen benchmarkaus tulee jatkuvaksi toiminnaksi. Kuva 40 Yksiköiden tietoja halutaan esittää yhdessä koko organisaation keskiarvotietojen kanssa Johtamiseen ja toiminnan ohjaukseen kuuluu myös tulevaa toimintaa ennakoivan ja ennustavan tiedon hyväksikäyttö. Tällöin mitatun toiminnallisen tiedon lisäksi halutaan esittää käytettävissä oleva ennustava tieto päätöksentekoa tukevana tietona. Kuva 41 Johdolle on tärkeää saada käyttöön tulevan toiminnan ennustetieto

64 Sote-tietojohtaminen 64 (112) 12 TIEDOLLA JOHTAMISJÄRJESTELMÄN VAIHEITTAISEN TOTEUTUKSEN JA KÄYTTÖÖNOTON KONSEPTI JA PERUS ROAD MAP 12.1 Tiedolla johtamisen kehittäminen tulee pohjautua lisäarvomalliin Tiedolla johtamisen avulla tulee pystyä luomaan organisaatiolle lisäarvoa. Nykyiseen tilanteeseen nähden tulee pystyä vähentämään tietotuotannon kokonais(yksikkö)kustannuksia ja luomaan uutta liiketoimintaarvoa. Tiedolla johtamisjärjestelmien kehittäminen on perusteltua vain, jos siitä saatava lisäarvo on suurempi kuin kustannukset. Kehittämisvaihtoehdoista valitaan se, mikä o o antaa suurimman nettohyödyn (nettolisäarvon) tai hyöty/kustannussuhde on paras Kuva 42 Tiedolla johtamisen kehittämistä ohjaa lisäarvoajattelun malli Tiedolla johtamisjärjestelmiin liittyvät hyödyt ovat välittömiä (kustannushyötyjä) tai välillisiä (paremman tiedon avulla voidaan toimintaa kehittää ja tehdä parempia päätöksi, jotka taas lisäävät palvelutoiminnasta saatavia hyötyjä sekä parantaa hyöty/kustannussuhdetta)

65 Sote-tietojohtaminen 65 (112) Arvonluonti tapahtuu vaiheittain etenevän prosessin kautta, prosessi on tavoitteellisesti jatkuva. Bikehitysprosessissa löytyy aina parannettavaa. Parantaminen tapahtuu käyttökokemuksista kerätyn tiedon avulla, samoin kuin uusien tarpeiden ja tavoitteiden toteuttamisen kautta. Kehittämisprosessissa tulee pystyä mittaamaan tärkeimmät tulokset ja kehittämistoiminnalla aikaansaatujen muutosten vaikutukset, samoin kuin todelliset panostuksetkin Tiedolla johtamisen kehittämishankkeen päävaiheistus Tiedolla johtamisjärjestelmän kehittämishanke jakautuu neljään päävaiheeseen, 1. Strategiavaihe 2. Määritysvaihe 3. Toteutusvaihe 4. Hyväksikäyttövaihe Usein organisaatioissa on lähdetty rakentamaan tietovarastoja ja johdon raportointijärjestelmiä ilman minkäänlaista strategista suunnitelmaa. Parhaaseen lopputulokseen päästään kun organisaation ylimmällä tasolla tehdään tarvittavia strategisia linjauksia ja päätöksiä, esimerkiksi mitä tiedolla johtamisella tavoitellaan, sitoudutaan sen kehittämiseen sekä yhteen sovitetaan se organisaation muiden strategioiden kanssa. Kuva 43 Tiedolla johtamisen kehittäminen tapahtuu vaiheittain etenevänä prosessina

66 Sote-tietojohtaminen 66 (112) BI-Strategia vaihe Tiedolla johtamisen kehittäminen alkaa BI-strategian luonnilla, sisältäen tehtävät, Oman palvelutoiminnan analyysi ja Tiedolla johtamisen rooli siinä BI-strategian luonti Toteutettavuuden arviointi Oman palvelutoiminnan analysointi, kypsyystasoanalyysi Omaa palvelutoimintaa analysoidaan Tiedolla johtamisen näkökulmasta Palvelutoiminnan viitekehys Palvelutoiminnan tulevat haasteet ja kehitystarpeet Tiedolla johtamisen rooli Tiedolla johtamisen nykyinen kypsyystasoanalyysi Kypsyystason analysointi tulee tehdä johonkin viitekehikkoon esim. kypsyysmallipohjat TDWI BIkypsyystasomalli, Gartnerin BI-kypsyymalli tai Logican Bi-kypsyysmalli. Alla olevassa kuvassa on otettu moduleja TDWI- ja Logica-malleista ja lisätty SoTe-hankkeen kokemusten pohjalta elementtejä. Kuva 44 Tiedolla johtamisen kypsyystasomalli

67 Sote-tietojohtaminen 67 (112) Organisaation oman Tiedolla johtamisen ympäristön kypsyystaso määritetään hankkeen alussa strategiavaiheessa ja kypsyystason kehittymistä seurataan siitä eteenpäin. Tiedolla johtamisen kypsyystaso jakautuu järjestelmä[tiedonhallinnan arkkitehtuuri]tason lähtötietojen[käytettävissä oleva raaka-data] tason [mukana myös kattavuus- ja laatutaso] toiminnallisen tason jalostetutun [käyttäjien tarpeiden mukainen] tietosisällöllisen tason käytön laajuustason [toimiala-, palvelu-, prosessikattavuus] käyttötilanteiden ohjaustason osakypsyystasoihin BI-strategian luonti ja tiedottaminen BI-strategian tulee pohjautua em palvelutoiminnan analyysin tuloksiin ja sen täytyy tukea organisaation yleisen strategian [strategioiden] toteuttamista. BI-strategiassa tulee keskittyä olennaiseen: BI-strategian tulee vastata Mikä on BI-toiminnan sisältö (rajaus) o Mitä se toiminnallisesti sisältää o Mitä se on tietosisällön kannalta Kenen käyttöön BI-tuottaa palveluja ja tietoja Miten BI-toiminta organisoidaan ja hallitaan (hallintomalli) o Vastuut ja roolit o Päätöksentekotapa ja prosessit o Organisaatiomalli Toteutettavuuden arviointi Toteutettavuuden tarkastelussa selvitetään miten BI strategian toteuttaminen parhaiten onnistuisi ja mitkä ovat parhaiden vaihtoehtoisten toteutustapojen ja etenemismallien hyödyt ja kustannukset BI-Määrittely vaihe Toteutettavuustarkastelun tuloksista riippuen joko jatketaan Tiedolla johtamisen kehittämistä tai ei. Tiedolla johtamisen kehittäminen jatkuu BI-määrittelyvaiheella, sisältäen tehtävät, Vaatimusten määrittely ja prototyypin luonti Arkkitehtuurimäärittely POC Tiedolla johtamisen kehittäminen etenee vaiheittain tyypillisesti toimialoittain / palvelualueittain ja myös tiedon jalostusaste kehittyy vaiheittain ja käyttö laajenee vaiheittain eri käyttäjä-

68 Sote-tietojohtaminen 68 (112) ryhmille. Tiedolla johtamisen kehitystyö etenee vaiheittain eri osa-alueilla (ovat yhteneviä kypsyyden osa-alueille), Käytettävissä olevan lähtötiedon osalta (toimialoittain, palveluittain, prosesseittain) Käytettävissä olevan tiedon kattavuus ja laatutaso Jalostetun tiedon osalta (käyttäjien tarvitsemat tiedot) Tiedon jalostuksen toiminnallisuus (perusraportoinnista aina optimointiin ja automaattisen ohjaukseen asti) ETL-prosessin automaatioaste Tietovaraston arkkitehtuuriratkaisun osalta Johdon ja toiminnan ohjauksen tasoilla (ylimmästä johdosta aina yksittäiseen työntekijään/asiantuntijaan) On huomioitava, että kehitystyö voi edetä hyvinkin eri tahtiin eri osa-alueilla. Etenemistä ohjaavat käyttäjien tarpeet ja kehitystyöstä saatava hyöty-/kustannussuhde Tavoitetilan ja 1.toteutusvaiheen vaatimusmäärittely Määrittelyvaiheessa kuvataan tavoitteellinen taso ja vaiheittaisen etenemisen välitasot, joista tarkimmalla tasolla ensimmäinen toteutusvaihe. Määrittelyvaiheen tueksi tehdään rinnalla suppea, ensimmäisten toteutusvaiheiden toiminnallisuutta simuloiva ja testaava POC, jonka tulokset osaltaan ohjaavat toteutusvaihetta. Vaatimusten määrittely tehdään tyypillisesti työpajoissa, joissa tietotarvevaatimukset kanavoituvat tiedon tarvitsijoiden ja käyttäjien kautta. Vaatimusmäärittelyn aikainen aineisto kuvaa liiketoiminnallisia vaatimuksia ja sen tulee olla kuvattu selkeästi ja tavalla jota tiedon tarvitsijat (johto eri tasoilla, toiminnan suunnittelusta ja ohjauksesta vastaavat ) ymmärtävät. Tämä vaihe on kriittinen koko Tiedolla johtamishankkeen onnistumiselle; tiedon tarvitsijoiden tulee nähdä työskentelyn aikana konkreettisesti tulevaisuudessa saavutettava hyöty. Näin voidaan johto sitouttaa ja motivoida jatkuvaan kehittämiseen. Tietotarpeen kartoitusten yhteydessä tulee myös määrittää eri käyttötilanteisiin sopivimmat tiedon esitystavat ja muodot. Tämä osaltaan motivoi määritys- ja kehittämistyötä. Määrittelyvaihe toteutuu kahdella tasolla, ensimmäisellä = ylätasolla tehdään sellaista määritystyötä, joka kuvaa koko DW/BI-järjestelmän kannalta yleisimmät ja kriittisimmät vaatimukset, jotta voidaan tehdä kokonaisarkkitehtuurin kannalta määritystä, suunnittelua ja ratkaisuja parhaiten tavoitteita tukevaksi toteutusympäristöksi. toisella = alatasolla tehdään sellaista määritystyötä, jonka pohjalta voidaan tehdä tietovaraston ja BI-sovellusten vaiheittaista suunnittelu ja toteutustyötä. Tämän tason määrittelyjen pohjalta tehdään myös prototyypin POC-toteutus, jotta voidaan varmistua tavoitteiden toteutumisesta ja toteutettavuudesta sekä käytettävyydestä.

69 Sote-tietojohtaminen 69 (112) Kuva 45 Tiedolla johtamisen kehitystyöhön osallistuvat sekä käyttäjien edustajat että ICTasiantuntijat. Kullakin on tässä oma roolinsa ja tehtävänsä Arkkitehtuurin määrittely ja suunnittelu Tietojärjestelmän määrittely- ja suunnittelu tapahtuu toimintotasolla tietotasolla järjestelmätasolla teknologiatasolla Määrittelyvaiheessa tehdään käsitteellisen ja osittain loogisen tason arkkitehtuurimääritykset ja valinnat. Suunnitteluvaiheessa tehdään tarkempi loogisen tason ja teknisen tason suunnittelu. Teknistä arkkitehtuuriympäristöä, työtä ja vaihtoehtoja on tarkemmin kuvattu kappaleessa PoC-toteutus ja testaus PoC:ssa (Proof of Concept) testataan ja todennetaan todellisessa tuotantoympäristössä merkittävimpiä toteutettavuuteen ja käytettävyyteen liittyviä osia. PoC:n avulla ei pelkästään todenneta teknistä toteutettavuutta vaan pyritään myös todellisille loppukäyttäjille tarjoamaan näytepala BI:n tarjoamista mahdollisuuksista. Sitä kautta voidaan PoC:n käytöstä saatujen käyttökokemusten pohjalta tehdä tarvittavia

70 Sote-tietojohtaminen 70 (112) muutoksia 1.toteutusvaiheen suunnitelmiin ja teknisiin ympäristöihin ja välinevalintoihin. Samoin PoC on erittäin hyvä tapa motivoida BI-hankkeeseen sitoutuneita henkilöitä BI-Toteutus vaihe Tiedolla johtamisen kehittäminen jatkuu toteutusvaiheella, sisältäen tehtävät, Tietovaraston toteuttaminen Tiedon raportointi- ja analysointitoimintojen toteutus Järjestelmän käyttöönotto Tiedolla johtamisen kehittäminen etenee vaiheittain tyypillisesti toimialoittain / palvelualueittain ja myös tiedon jalostusaste kehittyy vaiheittain ja käyttö laajenee vaiheittain eri käyttäjäryhmille Tietovaraston toteuttaminen Tietovaraston toteuttaminen tapahtuu tyypillisesti peräkkäisinä vaihekokonaisuuksina, jolloin kulloisenkin vaiheen aikana suunnittelu ja toteutustyö sisältää kompaktin tietokokonaisuuden, joka tarvitaan tiettyjen tähän vaiheeseen määritettyjen jalostettujen tietojen tuottamiseen BI-välinein BI-sovellusmodulien toteuttaminen BI-sovellusmodulien (raportit, mittaritiedot ) toteutus on enemmän iteratiivista, jossa pyritään saamaan kehitystyön aikana jo palautetta sovellusten loppukäyttäjiltä (käytettävyyden maksimointitavoite) Järjestelmän käyttöönotto Ensimmäisten toteutuskokonaisuuksien käyttökokemusten pohjalta on tärkeää analysoida tuloksia, ja tehdä niiden pohjalta tarvittavia muutoksia BI-strategiaan, etenemissuunnitelmaan ja myös arkkitehtuuriratkaisuihin BI-Hyödyntämisvaihe Tiedolla johtamisen hyödyntämisvaihe sisältäen tehtävät, Ylläpito ja käytön tuki Tietoresurssien hallinta Tiedon jakelu 12.3 Tiedolla johtamisen kehittäminen ja kokonaisarkkitehtuurinäkökulma Tiedolla johtamisen palvelut, tiedot ja järjestelmät ovat osa kuntien ICT-ympäristöä, jonka kehittäminen tulisi pohjautua ylemmän tason arkkitehtuurilinjauksiin. Käytännössä tällä hetkellä ei kunnissa ole kattavaa kokonaisarkkitehtuurityötä tehty. Tiedolla johtaminen tulee nivoa osaksi kokonaisarkkitehtuuria määrittämällä Tiedolla johtamisen viitearkkitehtuuri. Kun organisaation lähteen johdonmukaisesti kehittämään tiedolla johtamista omana hankkeena/projektina, tulee tällöin huomioida mahdolliset ylemmän tason arkkitehtuurilinjaukset ja arkkitehtuurit

71 Sote-tietojohtaminen 71 (112) samalla luoda ja kuvata tiedolla johtamisen viitearkkitehtuuri Kokonaisarkkitehtuurirakenne Julkisen hallinnon yhteinen kokonaisarkkitehtuuri Paikallishallinnon organisaation kokonaisarkkitehtuuri Valtionhallinnon kokonaisarkkitehtuuri Opetus-, tiede- ja kulttuuri viite- ja kohdearkkitehtuuri Terveys- ja hyvinvointialueen viite- ja kohdearkkitehtuuri Paikallisen SoTeorganisaation viite- ja kohdearkkitehtuuri Paikallisen opetus- ja kulttuuriorganisaation viite- ja kohdearkkitehtuuri Kehittämis- ja toteutusprojektit Pr1 Kehittämis- ja toteutusprojektit Pr2 Kehittämis- ja toteutusprojektit Pr3 Yhteinen kokonaisarkkitehtuuri Organisaation kokonaisarkkitehtuuri Kuva 46 Julkisen hallinnon kokonaisarkkitehtuurirakenne Koska käytännössä Tiedolla johtamisympäristöjen kehittäminen kulkee rinnan kokonaisarkkitehtuurin kehittämisen kanssa, on järkevä kuvata Tiedolla johtamisympäristöjen kehittämistyössä toimintaan, tietoon, tietojärjestelmiin ja teknologiaan liittyvät määritykset yhteisesti sovittavaan kehikkoon ja jäsentää määrityksissä ja suunnitelmissa syntyvä tieto yhteisesti sovittavalla tavalla.

72 Sote-tietojohtaminen 72 (112) Periaatteellinen Taso MILLÄ EHDOILLA Arkkitehtuuriperiaatteet Rajaukset ja reunaehdot Strategiat Standardisalkku Kehittämisvaatimukset ja tavoitteet Sidosarkkitehtuurit Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Käsitteellinen Taso - MITÄ Sidosryhmät Sidosryhmien vaatimukset ja tavoitteet Palvelut Käsitemalli Tietojärjestelmäpalvelut Teknologiapalvelut Looginen Taso - MITEN Fyysinen Taso - MILLÄ Sidosryhmät - tiedot Prosessilista/kartta Tietomallit Prosessikuvaukset Tietovirrat Prosessit-tiedot Päätietoryhmät Loogiset tietovarannot Fyysiset tietovarannot Koodistot, sanastot Looginen tietojärjestelmäpalveluiden jäsennys Järjestelmät-tietovarannot Järjestelmät-prosessit Järjestelmäsalkku Integraatiokartta Liittymät ja rajapinnat Teknologiakomponentit Verkkokaavio Sijoituskaavio Teknologiasalkku Kuva 47 Kokonaisarkkitehtuurin viitekehikko (JHS 179) Esimerkiksi SoTe-alueen tiedolla johtamisjärjestelmien kehitystyössä tulee konkreettisesti esille sidosarkkitehtuurien liityntäpinnat ja missä kohdin on syytä ja tarve tukeutua ylemmän tason arkkitehtuurimäärityksiin. Periaatteellinen Taso MILLÄ EHDOILLA Kehittämisvaatimukset ja tavoitteet Rajaukset ja reunaehdot Strategiat Standardisalkku Arkkitehtuuriperiaatteet Sidosarkkitehtuurit Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Käsitteellinen Taso - MITÄ Sidosryhmät Palvelut Käsitemalli Tietojärjestelmäpalvelut Teknologiapalvelut Looginen Taso - MITEN Sidosryhmät - tiedot Looginen tietojärjestelmäpalveluiden Prosessilista/kartta Tietomallit jäsennys Prosessikuvaukset Tietovirrat Loogiset tietovarannot Teknologiakomponentit Fyysinen Taso - MILLÄ Fyysiset tietovarannot Koodistot, sanastot Liittymät ja rajapinnat Järjestelmäsalkku Verkkokaavio Paikallinen (kunta) Palvelut Prosessit Kansallinen toimialakohtainen Sote-palveluluokitus (STM, THL) Kansallinen toimialariippumaton Kuntien palveluluokitus (Kuntatilastointi) Julkisen hallinnon yhteinen (JulkICT) Palvelutoiminnan käsitemalli Sote-tietovarannot Sote-indikaattorit Sote-käsitemalli Sote-tietovarannot Tilasto-tietovarannot Julkisen hallinnon käsitemalli Perustietovarannot Kunnan tietojärjrestelmät Tiedonsiirtorajapinnat Tiedonsiirtorajapinnat Tiedonsiirtorajapinnat Tiedonsiirtorajapinnat Yhteiset periaatteet Yhteiset periaatteet Yhteiset periaatteet Yhteiset periaatteet

73 Sote-tietojohtaminen 73 (112) Kuva 48 Kokonaisarkkitehtuurin mukaisessa kehitysmallissa huomioidaan sidosarkkitehtuurit ja tehdään myös yli organisaatiorajojen meneviä päätöksiä ja kehitystyötä Toiminta-tasolla käytännössä tulee olla ensin selvillä johtamisen, toiminnan suunnittelun ja seurannan ja kehittämisen pääprosessit ja niiden päävaiheet joissa Tiedolla johtamisen palveluja tarvitaan, ks kappale 4.1. Tiedolla johtamisen pääpalvelut tulee kuvata ensin tavoitteellisella tasolla. Tästä on esimerkki hankkeessa luotu palvelukokonaisuus ja jäsennys kappaleessa 4.2. Palveluita määritettäessä ja kuvatessa tulee samalla kuvata merkittävimmät sidosryhmät ja niiden roolit. Prosessinäkökulmasta tulee jäsentää ydinpalvelujen prosessit, johtamisen prosessit sekä Tiedolla johtamisen kehittämisen prosessi. Ydinpalvelujen prosessikuvaukset kertovat miten ydinpalvelujen prosessit toimivat ja mihin kohtaan johtamisen prosessi näissä liittyy. Johtamisen prosessikuvaukset kertovat miten johtamisen prosessi toimii. Tämä tarvitaan DW/BIhankkeissa tarkemmalla tasolla kuin ydinpalvelujen prosessikuvaukset. Tiedolla johtamisen kehittämisen prosessikuvaus kertoo miten Tiedolla johtamista tukevien järjestelmien ja palvelujen kehitys tapahtuu, useimmiten tukien vaiheistettua etenemismallia. Ydintehtävät BI-hankkeissa : Määrittää mitä palveluja tarvitaan Tiedolla johtamisessa eri palveluissa ja prosesseissa johtamisen, organisaation, prosessien ja palvelujen hierarkiatasoilla. JHS179Toiminta-arkkitehtuurin suunnittelun tarkoituksena on suunnitella ja kehittää organisaation strategisia tavoitteita toteuttavaa ydintoimintaa, sitä tukevia tukitoimintoja, toiminnan vaatimia resursseja sekä toiminnan lopputuloksena olevia tuotoksia tai palvelutarjontaa. Toiminta-arkkitehtuurin lähtökohtina ovat organisaation toimintaa ohjaava lainsäädäntö, kuvaus organisaation toiminnan nykytilasta ja siitä johdettu tavoitetila, strategiakuvaukset, mahdolliset skenaariokuvaukset sekä organisaation rakenne ja vastuualueet, toiminnalliset tarpeet ja trendit. Toiminta-arkkitehtuuri on tapa jäsentää ja hahmottaa toimintaa sekä toiminnan kehittämistä organisaation tavoitteiden näkökulmasta. Kuvauksissa lähdetään liikkeelle vaatimuksista ja hahmotellaan niitä vasten palvelut ja prosessit ylätasolla. Ylätason kuvauksen jälkeen kuvataan toimintamallit sekä tarvittavan tasoiset tarkemmat prosessikuvaukset. Toiminnan selkeyttämiseksi kuvauksia voidaan tehdä huomioimalla eri arkkitehtuurinäkökulmat. Etenemisjärjestykseen vaikuttavat organisaatiossa jo olemassa olevat kuvaukset sekä kuvausten taso. Mikäli kuvaukset ovat olemassa ja ne sisältävät tarvittavat tiedot päätöksen teon ja johtamisen tueksi, ei kuvauksia tarvitse tehdä uudelleen, vaan niitä muutetaan tarvittaessa tai seuraavilla suunnittelukierroksilla. Tieto-tason käsittely alkaa käytännössä siitä, että määritetään eri johtamisprosesseissa ja päävaiheissa ja tasoilla tarvittava jalostettu tietotarve. Tämän tiedon pohjalta luodaan looginen ja fyysinen käsite- ja tietomalli, jotka ovat myös osittain riippuvaisia tietovaraston arkkitehtuuriratkaisusta. Tiedolla johtamisessa tietoarkkitehtuurin määrityksen yhteydessä korostuu tiedonjalostuksessa tarvittavien lähtötietojen (raaka-data) tietolähteiden, kattavuuden ja laadun selvitystyö. Tiedolla johtamisessa korostuu myös erilaisten koodistojen, luokittelujen ja koodilistojen merkitys. Tässä vaiheessa aloitetaan myös rajapintojen ja liittymien määrittely.

74 Sote-tietojohtaminen 74 (112) JHS179Tietoarkkitehtuurissa tarkastellaan organisaation tietotarpeita, tietopääomaa, tietojen välisiä suhteita sekä informaatioarvoketjuja. Lisäksi tarkastellaan tietojen rakenteita sekä tiedon organisointia ja hallintaa. Tarkoituksena on luoda organisaatiotasoinen yhteinen näkemys organisaation keskeisestä tietopääomasta ja helpottaa tiedon ja siitä jalostetun informaation käyttöä, hyödyntämistä ja löytämistä. Tietoarkkitehtuurin kuvauksen tarkoituksena on helpottaa tiedon välittämistä eri toimintojen ja prosessien kesken sekä tiedon hallintaa. Organisaatiossa tarvittavan tiedon alustava määrittely on osa toimintaarkkitehtuuria ja sisältyy toiminnalle asetettuihin vaatimuksiin. Toiminnan vaatimuksien pohjalta määritellään organisaation ydintiedot päätietoryhmittäin. Myös organisaatiossa olemassa olevat tietojärjestelmät käsittelevät ja synnyttävät tietoa. Tällöin voidaan tunnistaa päätietoryhmiä myös järjestelmien näkökulmasta lähtien. Tietoarkkitehtuurin keskeisimpiä tavoitteita on löytää, määrittää, jäsentää ja kuvata organisaation kannalta keskeisimmät tietotarpeet, jotka liittyvät kriittisimpiin ydin- ja palveluprosesseihin. Tietoarkkitehtuurissa tulee huomioida ja hallita tiedon muuttuminen ajan, ympäristön tarpeiden, käyttäjän tulkinnan ja mieltymyksen sekä trendien suhteen. Lisäksi tulee huomioida tietoturva- ja tietosuojavaatimukset (kts. VAHTI-ohjeet, Tiedon määrittelyssä ja kartoituksessa tulee huomioida tiedonlähteiden riittävän laaja-alainen seuranta ja keskeisten tiedonlähteiden valinta. Ydintehtävät BI-hankkeissa : Määrittää mitä tietoa ja lähtötietoa tarvitaan Tiedolla johtamisen eri palveluissa ja prosesseissa johtamisen, organisaation, prosessien ja palvelujen hierarkiatasoilla a. Mallintaa Tiedolla johtamisessa tarvittavien lähtötietojen looginen ja fyysinen tietomalli sekä määrittää käsitteistö, koodistot ja sanastot. Rajapinnat ja liittymät. Järjestelmä-tasolla kuvataan tavoitetilan sovellus- / järjestelmäarkkitehtuuriratkaisut. Integraatioratkaisun rajapintakuvaus ja palvelukuvaus tehdään tarkemmalla tasolla. JHS179Järjestelmäarkkitehtuuri Tietojärjestelmien tarkoituksena on tukea organisaation toimintaa, toimia työvälineenä operatiivisissa prosesseissa ja hallita organisaation tietoja. Tietojärjestelmät muodostavat merkittävän osuuden organisaatioiden ICT-kustannusrakenteessa ja siksi on järkevää tavoitella myös tietojärjestelmäratkaisujen osalta mahdollisimman suuria hyötyjä kustannusten- ja riskienhallinta huomioiden. Tähän auttaa kokonaisarkkitehtuurin suunnittelun käyttäminen tietojärjestelmien suunnittelua ja kehittämistä ohjaavana tekijänä. Teknologia-tasolla kuvataan teknologia, johon tavoitetilan tekninen toteutus perustuu. Teknologiaarkkitehtuurin määrittelyssä otetaan huomioon palvelutuotannon ratkaisun malli. JHS179Teknologiarkkitehtuuri Teknologia-arkkitehtuuri vastaa kysymyksiin miten ja millä. Teknologia-arkkitehtuuri on kehittämisen näkökulmasta mahdollistava tekijä. Teknologia-arkkitehtuurin keskeinen tavoite on linjata ja rajata käytettävät tekniset vaihtoehdot, standardit ja rakenteet siten, että kokonaisuus tukee parhaalla mahdollisella tavalla organisaation tavoitteita. Linjaukset ovat yhteiseksi sovittuja teknisiä ratkaisuja, jotka on kuvattu teknologiasalkussa (kts Teknologiasalkku). Salkun sisältö koostuu erilaisista teknisistä ratkaisuista. Tällaisia voivat olla muun muassa integraatioarkkitehtuuri, tunnistaminen tai hakukoneratkaisu. Teknisten linjausten lisäksi teknologia-arkkitehtuurin kehittämistä ohjaavat arkkitehtuuriperiaatteet (vrt. liite 5 Arkkitehtuuriperiaatteiden kuvaus). European Interoperability Framework:n (EIF) teknologianäkökulman periaatteet ovat keskeinen lähtökohta yhteentoimivuutta suunniteltaessa ( Lisäksi tulee perustella arkkitehtuuriratkaisut. Samoin tulee kuvata yhteentoimivuus / yhtenevyys organisaation tavoitetilan kokonaisarkkitehtuuriin [mikäli olemassa].

75 Sote-tietojohtaminen 75 (112) 12.4 Tiedolla johtamisen kehittäminen KA-mallin mukaisesti Tiedolla johtamisen parhaiden käytäntöjen mukainen kehittämismalli voidaan yhdistää KA-mallin mukaiseen kehikkoon. Käytännössä tällöin hankkeen alussa luodaan BI-strategia. Ensimmäisen vaiheen totutuksessa noudatetaan näistä strategisia periaatteita. Kuva 49 Tiedolla johtamisen kehittämisen vaiheistus KA-mallia noudattaen Kun edetään seuraavien vaiheiden toteutuksiin, tarvemäärittelyt peilataan aina ensin strategisiin linjauksiin ja tehdään toteutuspäätös. Tarvittaessa BI-strategiaan tehdään toimintaympäristön, tarpeiden tai tavoitteiden muuttumisen kautta muutoksia. Kuva 50 Tiedolla johtamisen jatkuva kehittäminen KA-mallin mukaisesti

76 Sote-tietojohtaminen 76 (112) Tiedolla johtamissa tarvittavat tiedot ja ydintietojen [MD] hallinto [Data Governance] ja hallinta [Mater Data Management MDM] Tiedolla johtamisessa tarvittavien johdettujen ja perustietojen tuottamisessa tarvitaan lähtötietoina merkittävä osa organisaation ydintiedoiksi luokiteltavaa tietoa. Nämä on tarve tuoda tietovarastoon ja hallita tietovarastossa. Ydintietojen kattavuus- ja laatuvaatimukset ovat muuta tietoa tiukemmat. Jos organisaatiossa on määritetty ja käytössä kattavasti prosessit ja välineet ydintiedon hallintaan, tiedolla johtamisen järjestelmät ovat enemmänkin hyväksikäyttäjän roolissa ydintiedon hallinnan kokonaisuudessa. Mikäli organisaatiossa ei ole käytössä ydintiedon hallintajärjestelmiä, joudutaan tietovaraston ja ETLprosessien määrittelyssä, suunnittelussa ja toteutuksessa useimmiten panostamaan ydintietojen laadunhallintaa erikseen. Tällöin usein organisaation laajoissa tietovarastohankkeissa toteutetaan itse asiassa ydintiedon hallinnan alimpien kypsyystasojen mukaisia ratkaisuja. Kuva 51 Ydintietojen kehittäminen etenee myös vaiheittain eri kyspsyystasojen kautta.

77 Sote-tietojohtaminen 77 (112) Kuva 52 ydintietojen hallinnan kehittäminen alkaa usein keskitetyn tietovaraston rakentamisen yhteydessä Kuva 53 Ydintiedon kypsyystasomalli

78 Sote-tietojohtaminen 78 (112) 12.5 Vaiheittainen eteneminen, road map Laajat tietojärjestelmät on hyvä toteuttaa vaiheittain, koska näin saadaan jo aikaisessa vaiheessa osia järjestelmästä / tiedoista hyötykäyttöön[nettohyödyn maksimointi] ensin kannattaa toteuttaa sellaiset osat joiden käyttöönotto on kiireellisintä ja joiden kustannus hyötysuhde on suurin[nettohyödyn maksimointi] toisaalta ensin ei usein kannata toteuttaa vaikeimpia osia, joiden onnistumisessa ja aikatauluissa on suurta epävarmuutta [riskien hallinta ja pienentäminen] ensimmäisten osien käyttökokemusten pohjalta voidaan tarvittaessa tehdä kokonaisuuden jatkototeutukseen toteutettavuutta parantavia muutoksia [riskien hallinta ja pienentäminen] jo alkuvaiheessa nähdään onko tavoiteltu kustannus / hyötysuhde ja muut tavoitteet saavutettavissa [riskien hallinta ja pienentäminen ja allokointi] Tiedolla johtamisjärjestelmien osalta etenemisen vaiheistus kohdistuu lähinnä tuotettavan tiedon sisällön vaiheistukseen tuotettavan tiedon kohdistamisen ja kohdistamistason vaiheistukseen Bi-modulien toiminnalliseen vaiheittaisen kehittämiseen ja käyttöönottoon

79 Sote-tietojohtaminen 79 (112) Kuva 54 Esimerkki tiedolla johtamisen vaiheittaisesta kehittämisestä Tuotettavan tiedon sisällöllinen vaiheistus heijastuu myös tietovaraston toteuttamisen vaiheistukseen. Vaiheistuksessa näkyy samoja elementtejä kuin mitä kypsyystason näkökulmissakin on. Vaiheistus kulminoituu siihen, lähdetäänkö tietovarastoa rakentamaan suoraan DW/EDV-pohjalta vai lähdetäänkö ensivaiheessa liikkeelle tuottamalla lähdejärjestelmistä tunnuslukutason tietoa datamartteihin. Tietovaraston rakentuu vaiheittain, käytännössä pyritään viemään tiedot yksi lähdejärjestelmän tietovarasto kerrallaan. Järjestyksen määrää käyttäjien tietotarve sekä tietojen linkitystarve. Järjestykseen vaikuttaa osin myös lähdejärjestelmän tietojen kattavuus- ja laatutaso. Ydintietojen osalta tietojen käyttävyyden parantaminen tulee hoitaa MD hallinto- ja hallintamallien mukaan. Ydintietoihin sisältymättömien tietojen osalta laadunparannus hoidetaan tapauskohtaisesti. Uuden toiminnallisuuden kehittämisessä kannattaa edetä POC-mallin mukaan mikäli toiminnallisuuden kehittämiseen liittyy merkittäviä riskejä tai epävarmuutta. Tällöin POC:n toiminnallisuus testataan pienemmällä lähtötietoaineistolla. Näin ei turhaan sidota tietovaraston laajentamiseen resursseja, ennen kuin on varmistettu että tietoa voidaan tavoitteen mukaisesti hyödyntää. Tiedolla johtamisen järjestelmäympäristö jaetaan Back End = Tietovarasto ja Front End Tiedon jalostamisen ja hyödyntämisen osioihin. Tämä jako näkyy usein myös tiedolla johtamisen hankkeissa niin, että panostetaan alussa erittäin paljon ja pitkään varsin kattavan tietovaraston rakentamiseen ja hyödyntäminen alkaa vasta myöhemmin. Järkevää vaiheistusta on se, että tietovarasto voidaan rakentaa vaiheittain ja ensimmäinen vaihe toteutetaan varsin nopealla aikataululla ja sen hyödyntämisvälineet rakennetaan osittain rinnan tietovaraston rakentumisen aikana. Näin saadaan mahdollisimman nopeasti hyötyjä ja käyttäjiä on helpompi motivoida työhön. Kuva 55 Tiedolla johtamisen järjestelmäympäristö jaetaan Back End = Tietovarasto ja Front End Tiedon jalostamisen ja hyödyntämisen osioihin

80 Sote-tietojohtaminen 80 (112) 13 TIEDOLLA JOHTAMISJÄRJESTELMIEN TIETOTEKNISET ARKKITEHTUU- RIVAIHTOEHDOT 13.1 Tietovarasto-pohjainen raportointiratkaisu Periaateratkaisu Johdon raportointia, toiminnan seurantatilastoja ym. yhteenvetoja on tuotettu tietojärjestelmistä aina. Perinteinen ja edelleen käytössä oleva ratkaisu liittää raportit osaksi operatiivista järjestelmää tavallaan yhdeksi osajärjestelmäksi muiden joukossa. Raportit tuotetaan tällöin suoraan operatiivisesta tietokannasta. Tämä toteutusmallia käytetään kunnissa paljon ja se puolustaa edelleen paikkaansa varsinkin yksikkö- tai toimintokohtaisessa käytössä. Rinnalla on kuitenkin yhä enemmän alettu rakentaa ns. tietovarasto (DW, Data Warehouse) -pohjaisia raportointijärjestelmiä, jotka soveltuvat erityisesti johdon raportoinnin perustaksi. Tietovarastolla tarkoitetaan kokoelmaa integroituja tietokokonaisuuksia, jotka ovat suunniteltu tukemaan päätöksentekoa ja joiden jokainen tietoyksikkö on suhteessa johonkin ajan hetkeen. Tietovarasto sisältää perustietoja ja mahdollisesti niihin liittyvää summattua yhteenvetotietoa. DW-pohjaisella ratkaisulla on seuraavia etuja: Eristää raportoinnin tuotannosta selkeyttäen järjestelmäarkkitehtuuria, mm. muutokset lähdejärjestelmissä eivät välttämättä heijastu raportointijärjestelmään Vähentäen raporttiajoista johtuvia suorituskyky- ym. haittoja operatiivisille järjestelmille Mahdollistaa eri tietojärjestelmien tietojen yhdistelyn keskitettyyn tietovarastoon Tiedot ovat helpommin saatavilla ja uusiokäytettävissä Mahdollistaa tietokannan rakenteellisen toteutuksen raportointikäytön vaatimusten mukaan, mm. vasteaikojen optimointi Tehostaa tiedon laatutarkistuksia Luo perustan tietopohjaiselle johtamiselle ja toiminnanohjaukselle Tietovarastoratkaisujen teknisiä ratkaisuja voidaan tarkastella käyttäjä ja prosessien tukemisen- ja arkkitehtuurin näkökulmasta Käyttäjä- ja prosessien tukemisen näkökulma Tietovarastojen toteutuksessa korostuu käyttäjälähtöisen suunnittelun merkitys. Tietovarastointihankkeet lähtevät usein liikkeelle tietojen hyödyntämisen mallintamisesta. Tarkoituksena on varmistaa, että tietovarasto tuottaa tarvittavat tiedot oikeille henkilöille, oikeilla rajauksilla oikeaan aikaan. Tietojen hyödyntämisen mallintamisella varmistetaan, että tiedot ovat oikeassa ja järkevästi sekä nopeasti hyödynnettävässä muodossa. Tietovarastojen kehityksessä ei pidä unohtaa tiettyjen vakioraporttien merkitystä. Tietovaraston tulee mahdollistaa joustavat tiedon omaehtoisen raportoinnin-käyttötarpeet, mutta silti jopa 80 90% tiedon käytöstä pohjautuu nopeisiin tiettyä tarvetta varten tuotettuihin valmisraportteihin. Käyttäjien tulee saada tiedot yhdellä tai joissakin tapauksissa ilman yhtään hiiren klikkausta. Vakioraportit voidaan käynnistää portaalin kautta ja yhä useammin toimittaa oikeille käyttäjille oikeaan aikaan. Kun valmisraportteihin

81 Vaativuus (käyttäjät) Vaativuus (käyttäjät) Sote-tietojohtaminen 81 (112) mahdollistetaan linkitys joustavaan OLAP-palveluihin raporttien pohjana olevasta tietovarastosta, saadaan yhdistettyä molempien osa-alueiden hyvät puolet. Mitkä Mitkämuut muutasiat voisivat voisivat olla olla tärkeitä? tärkeitä? Mitä Mitätapahtunee tapahtunee huomenna? huomenna? Data Mining OLAP Käyttäjät Käyttäjät N N klikkausta klikkausta Kolme Kolmeklikkausta Miksi Miksise se tapahtui tapahtui eilen eilen? Ad Hoc kyselyt Kaksi Kaksiklikkausta klikkausta Yksi Yksiklikkaus klikkaus Mitä Mitätapahtui tapahtuieilen? Operatiivinen raportointi Tieto Kuva 56 : Tiedon hyödyntämisen tasot Tietylle joukolle käyttäjistä tulee mahdollistaa tarkemmat analysoinnit Data Mining -työkaluilla, mutta tyypillisesti koko käyttäjämäärästä näiden analyytikoiden osuus organisaatiosta riippuen on 1-3 %. Raportointivälineitä valittaessa onkin syytä miettiä organisaation käyttötarpeita tarkoin, jotta valittavat raportointivälineet täyttävät ne. Raportointivälineissä kukin tiedon hyödyntämistaso saattaa vaatia omat lisenssit ja yleensä korkeammalla hyödyntämistasolla olevien lisenssien hinnat ovat korkeammat. Eri raportointivälinetoimittajien hinnoitteluperiaatteet saattavat kuitenkin poiketa huomattavasti toisista Arkkitehtuuri näkökulma Tietovarastointihankkeissa korostuu arkkitehtuurin ja infrastruktuurin tärkeys. Infrastruktuurin merkitys korostuu tietovarastoinnissa sen vuoksi, että järjestelmien elinikä ylittää usein operatiivisten järjestelmien eliniän. Infrastruktuurin huolellisella valinnalla mahdollistetaan uusien aihealueiden joustava lisäys järjestelmään ilman, että järjestelmän perustaan joudutaan tekemään suuria muutoksia. Suurissa tietovarastoissa arkkitehtuuri kannattaa pohjautua keskitettyyn tietovarasto (Enterprise Datawarehouse (EDW))-ajatteluun (kuva 6). Siinä tiedot kerätään ETL (Extract/poimi Transform/muokkaa Load/lataa)-välineellä lähtöjärjestelmistä keskitettyyn tietovarastoon, josta tarvittaessa muodostetaan aihealuekohtaisia data martteja hyödynnettäväksi raportointiportaalin kautta. Raportointi/palveluportaalin kautta voidaan tarvittaessa tuottaa tarvittavat palvelut myös partnereille ja sidosryhmille.

82 Sote-tietojohtaminen 82 (112) Kuva 57 : Tietovarastoinnin yleinen arkkitehtuuri Keskitetyllä tietovarastolla (EDW) varaudutaan tietojen joustavaan käyttöön johtamis- ja suunnitteluprosesseissa sekä kumppaneiden ja sidosryhmien välisessä tietojen vaihdossa. Tiedolla johtamisessa EDW:n merkitys korostuu, koska tavoitteena on yleensä yhdistää tietovarastosta saatavat historiatiedot mittaristoseurantaan ja edelleen seuraavan suunnittelukauden tavoitteiden asetteluun. The Data Warehouse Instituten (TDWI) ja Gartnerin liiketoimintatiedon hallinnan ja suorituskyvyn johtamisen kypsyysmalleissa korostetaan EDW:n merkitystä siinä vaiheessa kun liiketoimintatietoa käytetään strategisella tasolla, jolloin prosesseja seurataan työpöytien avulla (dashboards) ja suorituskyvyn mittareita sekä liiketoiminnan suorituskykyä käytetään vertaamaan nykytilaa sekä yrityksen strategisia tavoitteita Tietovarastoinnin infrastruktuurin on mahdollistettava tietovaraston laajentamisen sekä aihealueiden osalta että tietojen volyymin osalta. Lisäksi sen on mahdollistettava sen päälle ja avulla rakennettavien palveluiden joustavan kehittämisen. Käyttöoikeudet toteutetaan tietoturvallisesti käyttöoikeushallintaperiaatteiden mukaisesti käyttäjärooleihin perustuen. Käyttäjärooleihin sidotaan oikeudet siten, että kukin käyttäjä saa nähdä vain hänelle kuuluvat tiedot. Kuva 5 esittää tietojen jalostumista operatiivisten järjestelmien perustiedoista julkaisujärjestelmien kautta esitettäväksi informaatioksi. Kuvan vasemmassa laidassa ovat lähdejärjestelmät eli perustiedot ja oikeassa laidassa tietojen hyödyntämiseen liittyvät toiminnot. Käyttäjä kirjautuu järjestelmään, järjestelmä autentikoi käyttäjän tunnistusmoduulin avulla, hakee käyttäjän käyttäjävaltuustiedot ja esittää käyttäjälle hänen oikeuksiensa mukaisen näkymän. Kuvan alalaidassa ovat järjestelmän ylläpitoon liittyvät toiminnot. Näihin kuuluvat ylläpidon ja tietojen latauksen hallinnan toiminnot.

83 Sote-tietojohtaminen 83 (112) ETL-välineen avulla toteutetaan tietovarastoon siirrettävien tietojen lataus, puhdistus, muokkaus ja tallennus. Jos siirrettävissä tiedoissa on ongelmia tai virheellisyyksiä, niitä ei välttämättä ladata järjestelmään vaan havaitut virheet ilmoitetaan tietokannan lokien kautta tietojen ylläpitäjille. Virheiden korjausten jälkeen tiedot ladataan uudelleen järjestelmään. Toteutettavat tarkastukset käyttävät hyväkseen järjestelmän välialueelle (staging area) tietokantaan talletettuja parametri-, siirtojen kontrollointi ja ohjaustietoja. Näiden tietojen avulla ohjataan esimerkiksi mahdollisia laskentoja, joita järjestelmään tuleville tiedoille tulee tehdä. Välineen avulla toteutetaan ajastetusti automaattisesti ajettavat tarkistus-, siirto- ja muistutusohjelmat. Markkinoilla on olemassa paljon erilaisia ETL-välineitä. Alla olevassa kuvassa on Gartnerin näkemys vuonna 2010 merkittävimmistä välineistä. Kuva 58 : Gartnerin näkemys merkittävistä ETL välineistä

84 Sote-tietojohtaminen 84 (112) Tietojen raportoinnin helpottamiseksi keskitetyn tietovaraston tiedoista muodostetaan raportointia varten raportointikanta/data mart -tietoja eli pienempiä kokonaisuuksia. Tietoja raportoidaan pääsääntöisesti raportointikannoista raportointi-välineiden avulla palveluportaalin kautta. Alla olevassa kuvassa on Gartnerin näkemys merkittävimmistä raportointivälineistä (BI-välineistä). Kuva 59 : Gartnerin näkemys merkittävistä BI-alustoista Tietovarastossa on kolmenlaisia tietokokonaisuuksia: latausalueen-, EDW- ja DW-alueen tiedot. Nämä talletetaan tietokantaan. Tietokantojenkin osalta tarjonta on runsas. Näitä ovat esimerkiksi Oracle 11g, IBM DB/2, MySQL, MS-SQL Server ja SAS. Välinevalintojen tekeminen on erittäin tärkeä vaihe tietovaraston rakentamisessa. Näitä valittaessa on huomioitava välineiden keskinäinen yhteensopivuus sekä välineiden yhteensopivuus olemassa olevaan infrastruktuuriin (esim. laitteet, käyttöjärjestelmät, käytössä olevat selaimet, käyttövaltuudet, tunnistautuminen) Keskitetyn tietovaraston tietomallinnus Operatiivisten tietojärjestelmien tietokannat on suunniteltu operatiivisen toiminnan näkökulmasta tehokkaiksi ja helppokäyttöisiksi. Useinkaan ne eivät sovellu hyvin raportointikäyttöön rakenteensa takia.

85 Sote-tietojohtaminen 85 (112) Seuraavassa kuvataan ja kolme eri tyyppistä keskitetyn tietovaraston tietomallinnusta. Yleensä raportointikannassa tiedot mallinnetaan raportoinnin kannalta optimaalisella tavalla. Tällöin käytetään mm. ns. tähtimallia tietovarastointimallinnuksessa. Keskitetyn tietovaraston mallinnukset voivat noudattaa: normaalimuotoinen, Kimballin tähti/lumihiutale tai Data Vault mallinnusta. Kunkin tietomallinnuksen ominaisuuksia on arvioitu SWOT-taulukoissa Normaalimuotoinen tietovarasto Tässä mallinnuksessa keskitetty tietovarasto on mallinnettu operatiivisista järjestelmistä tutulla normalisoidulla mallinnuksessa. Tällöin on suositeltavaa, että tiedot ovat mallinnettu vähintään 3. normaalimuodolla. Vaikka mallinnus toteutetaan samalla tavalla kuin operatiivisten järjestelmien tietomallinnus, niin indeksointia ei välttämättä kannata toteuttaa samalla tavalla. Normalisoinnista on olemassa useita oppikirjoja ja asiaa voi katsoa esim. Normalisoinnin perusajatuksena on mallintaa taulurakenne siten, että taulut eivät sisällä toisteista tietoa. Jos tällaista tietoa esiintyy, niin tiedot puretaan omiksi tauluiksi. Kolmannessa normaalimuodossa kunkin taulun tiedot liittyvät yksilöivään avaimeen. Jos jokin tieto liittyy avaimen osaan, niin tällöin kyseiset tiedot muodostavat oman taulun. VAHVUUDET HEIKKOUDET Tiedot on yhtenäistetty. Mallinnustapaa on sovellettu useassa paikassa (operatiiviset järjestelmät) ja mallinnuksen osaajia löytyy paljon. Tietovaraston rakenne voidaan toteuttaa samantapaiseksi kuin operatiivisessa järjestelmässä (nopeuttaa toteuttamista). Vaatii paljon työtä tietojen integrointivaiheessa (yleensä tiedot yhdenmukaistetaan latausalueelta vietäessä tällä mallinnuksella toteutettuun keskitettyyn tietovarastoon). Tietojen laajentamisvaiheessa on tiedettävä tarkasti missä järjestyksessä kukin tieto ladataan kantaan, jotta viite-eheydet säilyisivät. MAHDOLLISUUDET UHAT Helppo lisätä uusia tietokokonaisuuksia, jos tietää oikean järjestyksen. Jos rakenne on toteutettu operatiivisen tietojärjestelmän pohjalta, niin toimiiko rakenne myös niissä tapauksissa, kun lähtöjärjestelmä muuttuu => asia otettava huomioon tietomallinnuksessa.

86 Sote-tietojohtaminen 86 (112) Erilliset data mart-tiedostot ns. Kimballin malli Tässä arkkitehtuurimallissa ei pyritäkään tiedon yhtenäistämiseen vaan toiminto/aihekohtaiseen raportointiin, jossa tiedot saadaan raportointitarkoituksiin muodostetuista erillisistä data mart -tiedostoista. Data mart voi sisältää esimerkiksi seuraavia tietoja: suoritteet, myyntilaskutus, hankinnat, työntekijät, palkkakustannukset. Data mart on suppeahko ja rajattu tietovarasto, joka sisältää tiettyyn kohdealueeseen liittyvät tiedot. Kuva 3 havainnollistaa ratkaisumallia. Kuva 60 : Erilliset data mart -tiedostot Malli koostuu faktoista, joilla tarkoitetaan tarkastelun/analysoinnin kohteena olevia tietoja ja dimensioista (ulottuvuuksista), jotka edustavat tarkastelunäkökulmia. Keskitetyssä tietovarastossa tähtimalliset faktat voivat käyttää samoja dimensioita. Tähtimalli soveltuu erityisesti poimintakyselyihin ja porautumistoimintoihin ja siitä voidaan tuottaa normalisoinnilla ns. lumihiutalemallin mukainen tietovarasto, joka on tähtimallia joustavampi muutostarpeille. Kuvassa 4 esimerkki tähtimallista.

87 Sote-tietojohtaminen 87 (112) Kuva 61 : Esimerkki tähtimallista VAHVUUDET HEIKKOUDET Nopea implementoida. Muutokset kohdistuvat usein vain yhteen data martiin. Tietovarastointipuolella paljon osaajia. Tiedon yhdisteleminen ei ole mahdollista tai se voi olla vaikeasti toteutettava. Ei yhdistettyä näkyvyyttä yli organisaation. Tietoja ei ole yhtenäistetty. Suunniteltu alun perin raportoinnin näkökulmasta johon on lisätty tietomallinnukseen uusia tapoja hoitaa tietovarastoinnille tyypillisiä tilanteita. MAHDOLLISUUDET UHAT Uusien raportointi tarpeiden toteuttaminen helppoa. Lähdejärjestelmien muutokset saattavat olla ongelmallisia. Tarve saada yritystason näkyvyys. Jos lähtöjärjestelmä vaihtuu, niin mahdollisesti ei saada historiatietoja muokattua haluttuun muotoon raportointitarpeiden muuttuessa (ei ole käytössä enää vanhaa lähtöjärjestelmää) Data Vault -mallinnus

88 Sote-tietojohtaminen 88 (112) Data Vault-menetelmä on suunniteltu erityisesti EDW-tyyppisten tietovarastojen toteutukseen. Data Vault -menetelmä tukee tietovaraston skaalautuvuutta, muutosjoustavuutta ja se huomioi myös tietojen historiointivaatimukset. Erityisesti menetelmässä on panostettu tietojen jäljittämiseen ja auditointiin, mikä on osoittautunut tärkeäksi mm. valvontaan ja seurantaan liittyvien viranomaisvaatimusten tiukentuessa (ns. compliance-vaatimukset). Data Vault -tietomallissa tiedot jäsennetään kolmeen kategoriaan (taulu-tyyppiin): Hubi (Hub) vastaa käsitemallissa käsitettä, esimerkiksi asiakas, tuote, lasku. Hubi-taulun attribuutteja ovat mm. liiketoiminta-avain (esim. henkilön hetu), surrogaattiavain, tietolähde ja tiedon lataus päivämäärä. Satelliitti (Satellite) liittyy hubeihin tai linkkeihin. Yhdellä hubilla/linkillä voi olla useita satelliitteja. Pääosa tietosisällöstä on yleensä satelliiteissa ja ne myös historioivat (versioivat) tietoja päivityssyklin mukaan. Linkki (Link) yhdistää yleensä hubeja sisältäen hubien perusavaimet. Linkit määrittävät EDW:n karkeisuutta ja hierarkioita, vrt käsitemallin suhteet. Kuva 62 : Esimerkki Data Vault -tietomallin periaatteesta Data Vaultissa on usein myös irrallisia aputauluja ns. referenssitauluja, joihin on taltioitu esimerkiksi koodistoja. Data Vault -mallinnus aloitetaan yleensä tunnistamalla ja kuvaamalla hubit ja niiden väliset suhteet. Tämän jälkeen kuvataan näiden sisältöä tarkentavat ja täydentävät satelliitit. Määritelmän mukaan EDW suunnitellaan välttäen tiedon monistamista eli pyritään käyttämään tietovarastossa kolmatta normaalimuotoa. Tähän on myös käytännön syynsä, koska suurissa järjestelmissä EDW-kanta voi normalisoimattomana viedä kohtuuttomasti levytilaa. Tämä ominaisuus tarkoittaa käytännössä sitä, että pilkotaan HUB:n/Linkin ominaisuudet omiksi satelliitti tauluiksi (esim. asiakkaan perustiedot voisivat olla yhdessä satelliitissa ja osoitetiedot toisessa).

89 Sote-tietojohtaminen 89 (112) VAHVUUDET HEIKKOUDET Suunniteltu keskitettyyn tietovarastoon huomioiden historioinnin ja laajennettavuuden. Selkeät perusperiaatteet, joita noudattamalla saadaan toimiva kokonaisuus. Tietoja voidaan tuoda myös SOAP sanomilla (ei vaadi täydellisiä tietoja). Latausten toteuttaminen yksinkertaista. Vaatii oman raportointikannan, josta tuotetaan raportointi (tämä voi noudattaa tähtimallia). MAHDOLLISUUDET UHAT Voidaan kehittää ketterillä menetelmillä laajentaen kokonaisuutta askeleittain. Jos perusperiaatteita ei noudata, niin laajennettavuus kärsii. SoTe-hankkeessa on laadittu alustava Data Vault pohjainen EDW-relaatiomalli, joka pohjautuu HL7- standardointiyhteisön julkaisemaan RIM-viitetietomalliin (Reference Information Model). RIM on hyväksytty ISO-standardiksi 2006 ja sen käyttö on levinnyt laajalle terveydenhuollon tietojärjestelmissä. SoTetietomallin ja relaatiomallin alustavat kuvaukset on koottu erilliseen dokumentaatioon. Kuva 6 esittää laadittua relaatiomallia. Suomessa on selvitetty RIM-mallin soveltuvuutta sosiaalitoimen käyttöön ja Tikesos on laatinut sosiaalitoimen sanastoa RIM:n pohjalta. Käytännön sitoutumisesta ei ole kuitenkaan tehty päätöksiä eikä suosituksia.

90 Sote-tietojohtaminen 90 (112) Kuva 63 : SoTe EDW:n alustava relaatiomalli Suositus: Tiedolla johtamishankkeissa suosittelemme keskitetyn tietovaraston perustamista, joissa EDW kanta mallinnetaan Data Vault menetelmällä ja raportointikannassa hyödynnetään tähtimallia ETL-prosessi Yleiskuvaus Indikaattorien tuottaminen, kuten raportointi yleensäkin on prosessi, joka koostuu vaiheista ja niihin liittyvistä tehtävistä. Erilliseen tietovarastoon perustuvan raportointijärjestelmässä tätä ensivaihetta kutsutaan ETL-prosessiksi: Extract/poimi Transform/muokkaa Load/lataa. Lähtötiedot haetaan suoraan operatiivisista ja hallinnollisista järjestelmistä tai siirtotiedostoista, yhdistellään ja muokataan EDW-tietokannan määrittämään yhtenäiseen muotoon. Tiedot viedään EDW kantaan sillä tarkkuustasolla kuin tiedot ovat saatavilla lähtöjärjestelmistä. Tässä vaiheessa ei tehdä tiedoille mitään summauksia. EDW kannasta tiedot kootaan omina latauksina Data Mart kantaan. Tällöin tietoja voidaan jatkojalostaa raportoinnin vaatimilla tavoilla.

91 Sote-tietojohtaminen 91 (112) Muokkausvaiheeseen kuuluu monia osatehtäviä: virheiden tarkistusta, koodien muunnoksia, summatasojen laskemista ja tietojen historiointia. Tässä on siis oletuksena, että lähtötiedot on kirjattu sähköiseen muotoon kunnan tai ulkoisen palvelutarjoajan operatiivisten ja hallinnollisten järjestelmien tietokantoihin. Kuva 64 : Raportointijärjestelmän ETL-prosessin vaiheet Kuva 11 esittää ETL-prosessointia EDW-tyyppisessä tietovarastoympäristössä, missä voidaan tunnistaa neljä osaprosessia: kuvassa ETL1, 2, 3 ja 4. ETL1 prosessissa tiedot poimitaan lähtötietojärjestelmien tietokannoista (näkymärajapinnoista) tai niistä tuotetuista siirtotiedostoista. Kutakin liittymää kohti perustetaan sitä vastaava taulu. Tiedot ladataan sellaisenaan koontialueen tauluihin. Tässä vaiheessa tietosisällölle ei tehdä mitään muutoksia (ainoastaan toteutetaan mahdolliset merkistömuunnokset). Poimintoja tehdään tarpeen mukaan kerran päivässä (yössä), viikottain, kuukausittain ja joskus vain vuosittain. Eri tietoryhmät päivitetään usein erilaisissa sykleissä. ETL 2 prosessissa tiedot siirretään EDW kantaan tehtyihin tauluihin. Liittymien tiedot puretaan EDW mallinnuksen mukaisiin tietoihin. Tässä vaiheessa suoritetaan tietojen oikeellisuustarkastuksia ja muita mahdollisia tietojen käsittelyjä, jos tietomallinnus pohjautuu normalisoituun tai tähtimalliseen ratkaisuun. Data Vault pohjaisessa ratkaisussa tiedot viedään sellaisenaan (halutaan säilyttää jäljitettävyys). ETL 3 prosessissa voidaan tietovarastoon tuoduista tiedoista muodostaa erilaisia johdettuja tietoja. Esimerkiksi tietovaraston tietoja voidaan käyttää toimintolaskennan pohjana, jolloin osaprosessissa lasketaan erilaisia tunnuslukuja/kustannuksia ja tulokset talletetaan tietovarastoon. ETL 4 prosessissa EDW kannasta muodostetaan esimerkiksi toimiala- ja yksikkökohtaiset paikallisvarastot eli ns. data mart-tiedostot sekä OLAP (On-line Analytical Processing) kuutiot. Näitä käytetään rajatulla kohdealueella tietojen jatkojalostukseen. Usein vasta tässä vaiheessa tehdään myös valtaosa tiedon laatutarkistuksista, joka kattaa mm. tiedon oikeellisuuden tarkistamisen määriteltyjä arvoalueita tai päättelysääntöjä vasten. Tässä yhteydessä puhdistetaan virheet ja täydennetään puuttuvat tiedot.

92 Sote-tietojohtaminen 92 (112) Tehokkuuden ja tietojen laadunkin takia tavoitteena on, että ETL-prosessin eri vaiheet muodostavat mahdollisimman automatisoidun ja saumattoman kokonaisuuden. Usein raskaat ja aikaa vievät poimintaja latausajot ajastetaan käynnistymään toimistotyöajan ulkopuolella, jotta ei häiritä operatiivista tietojärjestelmien käyttöä. Prosessit voivat sisältää manuaalitehtäviä, mutta nämä henkilösidonnaiset toimenpiteet tulee minimoida. Varsinkin suurissa organisaatioissa ja järjestelmissä on kiinnitettävä huomiota prosessin tehokkuuteen eli läpimenoaikoihin ja resurssien käyttöön (prosessoriteho, muisti, levytila). Suurien aineistojen käsittelyssä nämä tekijät voivat olla kriittisiä. ETL-prosessi on aina monivaiheinen ja siten altis myös häiriöille. Virhetilanteista toipuminen on suunniteltava huolella vastaamaan vikasietoisuudelle asetettuja vaatimuksia. Lähtötietojen tarkistuksiin, koodimuunnoksiin, yhdistelyyn, summauksiin, ja muuhun tiedon jalostukseen ETL-prosessissa kannattaa myös panostaa, sillä tulos näkyy selkeinä, helppokäyttöisinä tietorakenteina ja sitä kautta tehokkuutena tiedon jalostusvaiheessa. Edun huomaa varsinkin, kun tulee mahdollistaa loppukäyttäjien itsenäinen raportointi. Tietojen yhdistämisessä auttaa jos yrityksessä on käytössä ydintietojen keskitetty hallinta (Master data management MDM). ETL-prosessin hallinnoinnissa käytetään apuna metatietoja, jotka kuvaavat tietosisältöä, itse ETLprosessin kulkua ja toteutustekniikoita. Metatietoja hyödynnetään ETL-prosessin ohjauksessa, raporttien ohjelmoinnissa ja loppukäyttäjien tukena itsenäiskäyttöisten BI-välineiden yhteydessä. Metatiedot kattavat tietosisällön lähdetiedoista aina EDW-kannasta luotuihin data mart- tiedostoihin ja OLAP-kuutioihin saakka. Metatiedoista tarkemmin kappaleessa 4. SoTe-määrittelyt eivät ole teknologiasidonnaisia, joten niissä kunnissa, joissa DW-järjestelmiä on jo käytössä voidaan tukeutua niissä käytettyihin toteutustekniikoihin myös määriteltyjen SoTe-indikaattorien tuottamisessa Poiminta / Extract Yleistä tietojen poiminnasta ETL-prosessin tekninen toteutus perustuu yleensä tietokantapohjaisuuteen ja eräajo-ohjelmiin. Poiminta-, muokkaus- ja lataus-ohjelmat voidaan toteuttaa räätälöiden, mutta yhä useammin käytetään varta vasten tarkoitukseen tehtyjä ETL-ohjelmistotuotteita. Nämä tarjoavat toimintoja, joiden avulla voidaan tehostaa ja hallita prosessia ja välineistä löytyy tuki useille eri teknisille ympäristöille. DW-järjestelmän toteutuksessa valtaosa työmäärästä käytetään yleensä ETL-prosessiin, joten kehitystyön tehostaminen tässä kohden on suositeltavaa. ETL-prosessin tehtävät suoritetaan usein määräajoin suoritettavina eräajoina, mutta rinnalla on alettu rakentaa myös ajantasaisia yhteyksiä operatiivisista sovelluksista EDW-kantaan. Online-pohjainen ratkaisu on tarpeen, kun halutaan seurata reaaliajassa esimerkiksi jonkin palvelun toimivuutta, analysoida ruuhkahuippuja jne. Tapahtuma- ja suoritetiedot siirretään välittömästi EDW-kantaan, mistä voidaan päivittää ajantasaiset tilannekohtaiset mittarit ja raportit. Kyse on tavallaan toiminnan jatkuvasta monitoroinnista, englanniksi BAM, Business Activity Monitoring. Tietojen poiminta lähdetietojärjestelmistä voidaan toteuttaa useilla eri tekniikoilla. Yleisin siirtotapa on eräajopohjainen, mikä mielletään usein vanhentuneeksi ratkaisuksi, vaikka sillä on edelleen paikkansa lähdetietojen tiedonsiirrossa. Ratkaisu soveltuu erityisen hyvin tietomassojen käsittelyyn silloin, kun tiedon ajantasaisuusvaatimus ei ole kriittinen. Kunnissa esimerkiksi monet seurantaraportit ajetaan kerran kuukaudessa. Tiedonsiirrossa käytetään yleensä FTP (File Transfer Protocol) -tekniikkaa, mikä tukee kaikkia tietomuotoja ja useita teknisiä ympäristöjä. Jos tiedostosiirtoja joudutaan tekemään avoimen verkon kautta, voidan tarpeen mukaan käyttää salausta tukevia siirtoprotokollia, kuten SSL (Secure Sockets Layer). Poimintaajot voidaan automatisoida ajastamalla ne halutun päivityssyklin mukaisesti. Ajojen ajastaminen on suositeltavaa aina, kun se on mahdollista toteuttaa. XML (extensible Markup Language) on yleisesti käytössä oleva standardi rakenteellinen kuvauskieli, jolla tiedon merkitys on kuvattavissa tiedon yhteyteen samaan tiedostoon. XML-kehittäjä on World Wide Web

93 Sote-tietojohtaminen 93 (112) Consortium. Tekniikka sopii erittäin hyvin käytettäväksi siirtotiedostojen standardina formaattina ETLprosessissa. XML-tiedostojen käsittelyyn on tarjolla myös paljon erilaisia sekä kaupallisia että avoimeen lähdekoodiin perustuvia apuohjelmistoja. Järjestelmäintegraatioissa nykyään paljon käytetty Web Service tekniikka soveltuu hyvin käytettäväksi myös poimintaratkaisuissa. Web services tekniikka ei ole parhaimmillaan suurien tietomassojen siirrossa, vaikka sanomien tekniset kokorajoitukset eivät erityisen tiukat olekaan. Reaaliaikaisen tiedonvälityksen tekninen toteutus BAM-pohjaisissa järjestelmissä perustuu usein asynkronisiin web services - sanomiin, joita operatiiviset järjestelmät esimerkiksi palveluväylän (ESB, Enterprise Service Bus) kautta lähettävät EDW-järjestelmään. Poiminta-ajossa voidaan poimia aina kaikki tiedot tai vain edellisen poiminnan jälkeen lisätyt tai muuttuneet tiedot. Edellinen ratkaisu on yksinkertainen, jälkimmäinen pyrkii optimoimaan siirrettävän datan määrää ja sen käsittelyyn tarvittavia resursseja SoTe tietojen poiminnat SoTe-hankkeessa määriteltyjen indikaattorien tarvitsemat lähtötiedot poimitaan pääasiassa taloushallinnon/kirjanpidon, henkilöstöhallinnon ja kotihoidon operatiivisista perusjärjestelmästä. Eri kunnissa on käytössä osin samoja järjestelmiä, mutta tuotekirjoa on ja järjestelmätoimittajien tuki poimintatiedostojen toteuttamiselle vaihtelee. Valmiita poimintaohjelmia on olemassa vain osalle vaadittavasta tietosisällöstä. SoTe-hankkeessa määriteltyjen indikaattorien vaatima tietosisältö voidaan jäsentää neljään kategoriaan: Toimintatiedot Taloustiedot Perustiedot Koodistot Toimintatiedot kuvaavat operatiivista toimintaa ja ne päivitetään EDW-kantaan inkrementaalisesti päivityssyklin mukaan. Lähtötiedot poimitaan käytössä olevista operatiivisista järjestelmistä. Useissa indikaattoreissa tarvitaan näitä toiminta-tietoja, joita ovat esimerkiksi asiakkaan tunniste, tukipalvelutapahtuma ja tapahtuman kesto. Taloustiedot ovat niin ikään inkrementaalisesti täydennettäviä toiminnan kustannuksia kuvaavia tietoja. Näitä ovat esimerkiksi kustannuslaji, kustannus (euroa) ja tukipalvelun hinta. Poiminnat kohdistuvat kirjanpidon, laskutuksen ja reskontran järjestelmiin. Perustiedot ovat harvoin muuttuvia asiakkaan, henkilöstön tai organisaation perustietoja, jotka poimitaan yleensä useista eri järjestelmistä. Tällaisia ovat mm. asiakkaan syntymäaika ja organisaation tunniste. Tavoitteena on poimia mukaan vain muuttuneet, lisätyt tai poistetut tiedot. Koodistoja ja ohjaustietoja päivitetään harvoin, mutta tehdyt muutokset tulee poimia keskitetystä koodistokannasta tai eri järjestelmien yhteydessä ylläpidettävistä koodistoista. Poimittavien lähtötietojen tietosisällöt tulisi standardisoida vastaamaan mahdollisimman tarkoin EDW:n sisältöä. Kukin tietosisältö voidaan tuottaa yhden poiminta-ajon tuloksena tai ne voidaan koota ETLprosessin muokkausvaiheessa kuntien lähdejärjestelmistä ja niiden rajapinnoista riippuen. Poiminta-aineisto sisältää myös täydennyksiä ja korjauksia aiempien kuukausien EDW:ssä oleviin tietoihin Muokkaus / Transform Yleistä tietojen muokkauksesta Muokkausvaiheessa valmistellaan lähdetietojärjestelmistä poimitut aineistot ennen latausta EDW tai Data Mart-kantaan, jonka tietosisältö ja rakenne määrittävät lähtötietojen muokkaustarpeen. Muokkausvaiheen toteutus on usein työläin osa ETL-prosessia. Tässä vaiheessa tehdään mm. seuraavia toimenpiteitä: Tietomuodon teknisiä muunnoksia, esimerkiksi CSV-tiedoston muunto XML-tiedostoksi

94 Sote-tietojohtaminen 94 (112) Tietojen tallennusmuodon yhtenäistäminen, esimerkiksi päiväys muotoon pp.kk.vvvv Tietojen normalisoinnit ja denormalisoinnit Taulujen avaimien määrittelyt, myös surrogaattiavaimet Summatasojen ja muiden laskennallisten tietojen luonti Tietojen tarkistus Tietojen historointi Muokkausvaiheessa yhtenäistetään eri tietolähteistä poimitut tiedot. Esimerkiksi koodistot voivat vaihdella eri toimittajien tietojärjestelmissä ja ne tulee sovittaa yhteismitallisiksi. Aina ei yksiselitteistä vastaavuutta esimerkiksi käytetyille koodeille löydy, jolloin on tyydyttävä likiarvoon tai hylättävä ko. tieto kokonaan aineistosta. Virheelliset tai puutteelliset tiedot tulee korjata tai hylätä tässä vaiheessa. ETL-valmisohjelmiston avulla voidaan tehokkaammin hallita tulee erilaisten loogisten tarkistussääntöjen ja muiden muokkaustoimenpiteiden ylläpitoa. Muokkausvaiheessa suoritetaan tietojen aggregointia ja tehdään tarvittavat laskutoimitukset, lasketaan esimerkiksi summatietoja valmiiksi SoTe-tietojen muokkaus Vaikka EDW:n tietosisältö SoTe-indikaattorien osalta olisikin sama eri kunnissa, ovat lähdejärjestelmien tietosisällössä eroja, jolloin muokkausohjelmien vakiointi on haasteellista. Niihin jää helposti lähdejärjestelmäriippuvuutta. Monien indikaattorien tuottaminen edellyttää kustannustietoja, joita ei saada valmiissa muodossa lähdejärjestelmistä. Muokkausvaiheessa tehtävät laskutoimitukset on kuvattu dokumentissa SoTe Tietojohtaminen Kotihoidon Indikaattoreiden laskentasäännöt Lataus / Load Yleistä tietojen latauksesta Kun uusi raportointijärjestelmä otetaan käyttöön luodaan aluksi tyhjä EDW-kanta. Ensivaiheessa latausohjelmilla viedään vielä tyhjiin tauluihin sisältöä. Jatkossa latausohjelmilla täydennetään päivityssyklin mukaan tietovarastoa lisäämällä siihen taulurivejä ja tarvittaessa myös uusia tauluja. Usein päivitysperiaate on kumuloiva, jolloin aiemmin viedyt tiedot säilyvät kannassa. Joskus päivitys korvaa joltakin osin aiempia tietoja. Latausvaihe on yleensä varsin suoraviivainen. Tietojen latausjärjestys on mietittävä taulujen riippuvuudet sekä tietojen mallinnustapa huomioiden. Käytettäessä Data Vault tietomallinnusta latausjärjestys voi olla aina sama: ensimmäisessä vaiheessa ladata HUB taulut, toisessa vaiheessa LINK taulut ja lopuksi Satelliitti taulut. Jos kantaan tulee uusia tauluja, niin lataus pitää lisätä haluttuun vaiheeseen. Vaiheen sisällä järjestyksellä ei ole väliä SoTe-tietojen lataus Määriteltyjen indikaattorien vaatimat latausohjelmat voidaan vakioida, siltä osin kuin EDW-tietosisältö ja rakenne on standardi. Käytännössä ne joudutaan kuitenkin sovittamaan käytettyihin EDW-kannan ja ETLprosessin toteutusteknologioihin. Latausajot tulee automatisoida mahdollisimman pitkälle Tietojen jalostaminen Yleistä

95 Sote-tietojohtaminen 95 (112) EDW-pohjaista järjestelmää voidaan hyödyntää organisaatiossa monin tavoin. Tietovarasto on suunniteltu tietosisällöltään laajaksi ja sen kautta on mahdollista periaatteessa tuottaa valtaosa kunnan ja eri toimialojen johtamisessa tarvittavista raporteista. Tiedon jalostaminen on prosessi, jonka lopputulos voi olla mm.: Raportti Tilasto Aikasarja Muu yhteenveto Tunnusluku Indikaattori Mittari Paikallisvarasto (data mart) OLAP-kuutio Jalostettu tieto tuotetaan EDW:n lähtötiedoista laskutoimitusten ja tietojen yhdistelyn avulla. Lähtökohtana on aina johtamisessa tai muussa kunnan toiminnassa ilmenevä tietotarve. Lainsäädännön ja muiden vakiintuneiden ohjaus- ja seurantamallien edellyttämät tilannekatsaukset tuotetaan vakioraportteina esimerkiksi kuukausittain. Kunnallishallinnossa ja eri toimialojen johtamisessa käytetään paljon tällaisia säännöllisesti samanmuotoisina julkaistavia perusraportteja. Nämä toteutetaan yleensä samalla kuin tietovarastokin ja niitä ylläpidetään tarpeen mukaan. Loppukäyttäjän kannalta vakioraportit eivät edellytä tietosisällön erityistuntemusta tai teknistä osaamista. Raportit julkaistaan usein sähköisessä muodossa web-sivustolla tai sähköpostin kautta. Paperimuotoinen julkaisumuoto on tietysti edelleen käytössä. Perus- ja vakioraportoinnin lisäksi EDW-järjestelmän tekniset ratkaisut mahdollistavat myös ns. ad hoc raporttien tuottamisen ja omaehtoisen itsenäiskäyttöisen tietojen jatkojalostuksen. Ad hoc raportit ovat akuuttiin ja usein tilapäiseen tarpeeseen laadittavia pikaraportteja, jotka voivat minimissään olla yksittäisiä tunnuslukuja. Näiden laatiminen edellyttää EDW:n tietosisällön tuntemusta ja teknisten raportointivälineiden hallintaa. Hyödyllisiksi koetuista pikaraporteista voidaan tehdä vakioraportteja. Jalostusvaiheessa tuotetaan EDW-kannasta myös data mart ja syvemmälle menevään analysointiin tarkoitettuja OLAP (online transaction processing) tiedostoja. Tietoja voidaan toimittaa jatkojalostukseen muihin tietojärjestelmiin ja organisaatioihin. Loppukäyttäjien itsenäiskäytön eri tarpeisiin on saatavilla runsaasti ohjelmistoja. Yksinkertaisiin tehtäviin käytetään Excel-tyyppisiä taulukkolaskenta tai listausohjelmistoja. Suunnittelijat ja tutkijat tarvitsevat monipuolisempia työkaluja ja vastaavasti enemmän asiantuntemusta. Kuntatasoinen EDW tietovarasto kokoaa siis keskitetysti yhdenmukaistettua tietoa eri sektoreilta ja tavoitteena on kokonaisnäkemyksen muodostaminen kunnan toiminnasta. EDW-kantaan kootaan pääasiassa raakadataa eli yksilö-, yksikkö-, suorite- ja tapahtumatason tietoa, joka toimii raaka-aineena tietojen jalostuksessa. Jalostettuja tietoja voidaan edelleen taltioida myös EDW-kantaan silloin, kun niitä uusiokäytetään laajemmin esimerkiksi tietojen yhdistelyssä tai muussa jatkojalostuksessa Data mart -tiedostot EDW-kannasta tuotetaan kohderyhmäkohtaisesti, toimintokohtaisesti tai eri organisaatioyksiköiden käyttöön paikallistiedostoja, joita kutsutaan data mart tiedostoiksi tai paikallisvarastoksi. Nämä ovat tavallaan omia pienempiä DW-kantoja rajatulla tietosisällöllä ja tietylle kohderyhmälle suunnattuja. EDW:stä poimittuja tietoja voidaan jalostaa valmiiksi, jotta ko. sidosryhmät voivat helpommin tuottaa niistä raportteja omiin tarpeisiinsa. Data martit tuotetaan tietyllä tavalla myös oman ETL-prosessinsa kautta: lähdetietona on EDW-kanta ja usein tehdään summauksia, yhdistelyjä tai muita muokkaustoimia ennen latausta data mart -kantaan. Data mart-aineistoja voi kertyä ajan kuluessa runsaasti, jolloin niiden hallinnassa voidaan käyttää apuna ETL-ohjelmistoja tai muuta tiedostojen hallintajärjestelmää.

96 Sote-tietojohtaminen 96 (112) Määriteltyjä indikaattoreita varten voidaan tuottaa oma data mart tietokanta, joka sisältää laskutoimituksin jalostettuja tietoja. Näin kaikki indikaattorit voidaan tuottaa samalla kertaa ja aineisto on helpommin käytettävissä mahdollista jatkoanalyysiä varten. Ratkaisu on perusteltua myös tietojen historoinnin takia. Indikaattorit voidaan tallentaa myös EDW kantaan, josta niistä siirretään Data Mart kantaan halutut indikaattorit. Historoitujen data martien pohjalta voidaan ajan kuluessa laatia yhteenvetona mm. aikasarjoja OLAP-kuutiot ja -järjestelmät Vaativampaan analysointiin, porautumiseen ja louhintaan (data mining) tarvitaan monipuolisempia ratkaisuja. OLAP (On-line Analytical Processing) -järjestelmä tarjoaa käyttäjälle moniulotteisen ja käsitteellisen näkymän organisaatioon tai toimintaan liittyvään tietoon. OLAP-kuutioit sisältävät datan ja niitä voidaan pitää data martien erikoistapauksena. Kuutio-muoto on moniulotteinen, jossa fakta- ja dimenssiotiedot ovat yhdessä. Nimestä huolimatta ulottuvuuksia on usein enemmän kuin kolme. OLAP-järjestelmä sisältää monipuoliset käyttäjäystävälliset analyysityökalut datakuution käsittelyyn. Tiedon esittämiseen käytetään reaalimaailman käsitteitä, jolloin loppukäyttäjän on helppo hahmottaa eri ulottuvuuksien merkitykset ja niiden väliset suhteet. Käyttäjä voi muokata näkymää haluamakseen, näkymästä voi poistaa ulottuvuuksia ja tarkasteluun voi rajata vain tietyn osan koko tietokuution sisällöstä. Analysoitu ja tiivistetty tieto voidaan tulostaa raportiksi. On huomattava, että OLAP-tekniikan käyttö edellyttää sitä tukevaa ohjelmistoa ja käyttäjiltä riittävää teknistä ja menetelmällistä osaamista. Myös tietosisällön hyvä tuntemus on välttämätöntä kuution käsittelyssä. OLAP-kuution luonnissa ja analysointia tukevan työkalun valinnassa voi hyödyntää ns. FASMI, Fast Analysis of Shared Multidimensional Information, Nigel Pendse, määrittelyä, jonka mukaan kuution ja sen käsittelyyn tarkoitetun ohjelmiston tulee täyttää viisi vaatimusta: Fast: nopeat vasteajat. Kyselyyn tulee saada vastaus lähes aina alle viidessä sekunnissa. Tarve liittyy analysoinnin työskentelytapaan, joka on luonteeltaan nopearytmistä. Suurissa kuutioissa vasteaikoja voidaan nopeuttaa mm. summatasojen avulla. Analysis: analysointiominaisuudet. Järjestelmän tulee mahdollistaa kaikki analysoinnin perustoiminnot. Käytön tulee olla riittävän helppoa ja käyttäjän on voitava tehdä omia ad hoc kyselyitä. Shared: jaetut tiedot. Järjestelmän tulee tukea useaa samanaikaista käyttäjää, mikä ei ole yleensä ongelma, koska kuutioiden käyttöön on vain lukuoikeudet. Päivitystoiminnot ovat erikoistapauksia. Multidimensional: moniulotteisuus. Moniulotteisuus on OLAP:n keskeisin ominaisuus. Käyttäjä voi tarkastella kuution tietoja moniulotteisesti useista erilaisista käsitteellisistä tarkastelunäkökulmista. Tyypillisiä ulottuvuuksia ovat aika, paikka ja organisaatio. Lisäksi tulee tukea tiedon hierarkkisuutta. Information: kattavat tiedot. Järjestelmän tulee sisältää kaikki kohdealueen analysoinnissa tarvittava data ja mahdollistaa sen hallinta ja analysointi. OLAP-kuutio soveltuu helppokäyttöisyytensä takia hyvin myös ns. ad hoc analyysien tekoon. Tiedon louhinta (data mining) ja porautuminen(drill-down) liittyvät kuution käsittelyyn. Louhinnalla yritetään löytää suuresta tietojoukosta uusia, analysoinnin kohteen kannalta merkittäviä tietoja. Louhintaa käytetään esimerkiksi optimoinnissa, tiedon luokittelussa ja ennustamisessa. Porautuminen tarkoittaa nimensä mukaisesti siirtymistä alemmille hierarkiatasoille, esimerkiksi vuositasolta, kuukausi-, viikko- tai päivätasolle. Usein porautumista käytetään myös organisaatioyksiköitä tai maantieteellisiä alueita analysoitaessa.

97 Sote-tietojohtaminen 97 (112) 13.4 Metatiedot Metadata on tietoa tiedosta eli se kuvaa tiedot, joita järjestelmän eri vaiheissa käytetään. Metadassa kuvataan tietosisällön lisäksi tiedon käsittelysäännöt ja käytettävät välineet. Metatiedoilla onkin hallittavuuden ja tiedon laadun kannalta sitä suurempi merkitys mitä laajemmasta raportointijärjestelmästä on kyse. Kuten edellä on kuvattu DW-pohjainen järjestelmä on laaja kokonaisuus, joka koostuu useista prosesseista ja tehtävistä. Metadata liittyy kaikkiin vaiheisiin, tehtäviin ja jopa käytettyihin tekniikoihin. Kuva 65 : Metatietojen hallinta kattaa koko DW-järjestelmän Metatiedon avulla voidaan parantaa tietovaraston tietosisällön laatua, käytettävyyttä ja muutoshallintaa. Siitä on hyötyä sekä järjestelmän toteuttajille että loppukäyttäjille. Henkilösidonnaisuutta voidaan vähentää kattavalla metadatalla. Metadata voidaan jakaa kahteen luokkaan: Tekninen metadata Toimintaa ja sisältöä kuvaava metadata Tekninen metadata kuvaa mm. tietojen teknisiä formaatteja (tyyppi, pituus), järjestelmän edellyttämiä laitteistoja varusohjelmistoja, rajapinnoista, poiminta- ja latausohjelmista, levytiloista ja hakemistoista. Tietojen eheyssäännöt ja tekniset muunnokset sekä käyttöoikeustiedot ovat osa teknistä metadataa. Toimintaa ja sisältöä kuvaava metadata kattaa tietojen merkityksen kuvauksen liike/palvelutoiminnan termein ilmaistuna. Lisäksi kuvataan lähdetietojärjestelmät, ETL-prosessit ja laskentasäännöt. Metadata toimii tietovaraston tietohakemistona, jolloin laajastakin EDW-kannasta voidaan löytää tarvittavat tiedot. Suurien kantojen käsittely ilman metatietoja on lähes mahdotonta ja johtaa joka tapauksessa henkilösidonnaiseen työtapaan. Metatietoja tarvitaan myös tietojen syntyhistorian jäljittämisessä (audit trail). Niiden avulla saadaan selville missä yksittäinen tieto on kirjattu, kenen toimesta ja milloin kirjaaminen on tehty. Näin voidaan selvittää myös muista tiedoista johdetut tiedot. Tietovarastojen metatietojen kuvaamiseen on käytettävissä on Object Management Group:n (OMG) kehittämä standardi Common Warehouse Metamodel (CWM), joka ei ole kuitenkaan Suomesssa kovin laajassa käytössä. Toimittajista mm. IBM ja Oracle tukevat DW-tuotteissaan CWM-standardia.

98 Sote-tietojohtaminen 98 (112) Juhdan JHS143-standardi määrittää asiakirjojen metatiedot, jota voi osin soveltaa tietovarastoissa, mutta se ei ole sellaisenaan läheskään riittävä tähän tarkoitukseen. Tikesos on määritellyt enemmän substanssia huomioivia metatietoja, mutta nekin liittyvät asiakirjoihin. Sosiaalihuollon asiakasasiakirjojen metatiedot, versio 1.0 on julkaistu Metadatan luonti ja ylläpito on oma tehtävänsä. Tiedot syötetään yleensä omaan tietokantaansa (repository) tai käytössä voi olla myös erityinen metadatojen hallintaan tarkoitettu väline. Käytettävyyden kannalta on suositeltavaa hallita metadata sähköisessä muodossa ja teknisesti raportointijärjestelmän yhteydessä. Ihannetilanteessa metadatan hallinta on tiiviisti integroitu raportointijärjestelmään.

99 Sote-tietojohtaminen 99 (112) 14 TIEDOLLA JOHTAMISHANKKEIDEN PROJEKTOINTIMALLIT Riippuen BI-strategian toteutussuunnitelmissa tehdyistä arkkitehtuuri- ja vaiheistuspäätöksistä tulee BIkehityshankkeeseen valita asikastilanteeseen soveltuvin projektointi- ja työskentelymalli. Seuraavassa kuvattu scrum-mallin soveltamista BI-kehityshankkeissa Scrum-malli Sovellettu Scrum-menetelmä tarjoaa seuraavat hyödyt: Asiakas pystyy reaaliaikaisesti (päivittäin) seuraamaan etenemistä ja ohjaamaan sen toimintaa tarvittaessa Eri toimittajilla toimivat tiimit saavat reitin kommunikoida kehitystä ja voivat vaikuttaa esteisiin, jotka hidastavat tekemistä joko tiedon puutteen tai muiden syiden vuoksi Tuottaa näkyviä tuloksia jatkuvasti ja tulosten avulla voidaan ohjata toimintaa BI-palvelu ja projektit koostuvat vähintäänkin seuraavista eri tiimeistä: BI/DW tiimit, jotka vastaavat portaalin ja raportoinnin sekä tietovarastoinnin kehittämisestä ja ylläpidosta Operatiiviset järjestelmät tiimi, joka vastaa yhteistyöstä operatiivisten järjestelmätoimittajien (sisäiset ja ulkoiset) kanssa. Yhtenä tärkeimmistä tehtävistä on varmistaa tietojen välittämisestä rajapintoihin Muita tiimejä voidaan muodostaa tarpeen tullen (esim. testaustiimi ja liittymätiimi). Näillä kaikilla tiimeillä on yhteisenä päämääränä tuottaa käyttäjille tarvittavat raportit ja tiedot, joiden avulla käyttäjät voivat hyödyntää ja käyttää järjestelmän tietoja oman työnsä pohjana. Tiedon tulee liikkua mahdollisimman nopeasti ja joustavasti tiimien ja asiakkaan välillä. BI-palveluvastaava on vastuussa siitä, että kokonaisuus toimii ja että jokainen tiimi tekee oikeita tehtäviä.

100 Sote-tietojohtaminen 100 (112) Main Product Owner Priorisoi Product Backlog Näkymä kokonaisuuteen Deputy A Product owner Deputy A näkymä Product Backlogista Deputy B product owner Deputy B näkymä Product Backlogista Näkymä kokonaisuuteen Ketterä Kehitys- ja ylläpitotehtävien hallintajärjestelmä BI-Palvelu vastaava Scrum Master A Tehtävät Vastuu: Operatiiviset järjestelmät Tehtävät Scrum Master B Vastuu: BI/DW tiimi 1 Tehtävät Scrum Master C Vastuu: BI/DW tiimi 2 Scrum Master D Vastuu:Tiimi n Tehtävät BI-palvelu Kuva 66 : BI-palvelun ja projektin organisointi Itse Scrum-mallista löytyy useita kattavia esityksiä verkosta (esimerkiksi: tai tai ) Scrum-prosessimalli Scrum-ohjelmistokehitysmalli (kuva 12) perustuu sovelluksen toiminnallisuusluetteloon (Product Backlog) ja sen toteuttamiseen inkrementaalisesti osa kerrallaan sprinteissä (Sprint). Toiminnallisuusluettelo kehittyy ajan myötä (asioita tulee lisää, poistuu ja priorisoinnit muuttuvat). Toiminnallisuusluettelo on nk. projektin tiekartta. Main Product Owner kertoo tarpeet ja priorisoinnin ylätasolla ja Deputy Product Ownerit muodostavat tästä eri osa-aluille priorisoinnit. Scrum-tiimit toimivat Deputy Product Ownerien antamien priorisointien pohjalta. Yhteen Scrum tiimiin kootaan jäseniä tarvittavilta tahoilta (mukana on asiakkaan edustajia sekä eri toimittajien edustajia tarpeen mukaan). Product Backlog sisältää asiakkaan tarpeet, uudeet kehitystehtävät, muutokset olemassa oleviin toiminnallisuuksiin (muutoksenhallinta) sekä jatkuvan palvelun tehtävät. Kun toiminnallisuusluettelo on muodostettu, aloitetaan ensimmäisen sprintin suunnittelu. Sprintti on jaettu kahteen osaan: osa yksi ja osa kaksi. Tämän lisäksi sprintin suunnittelu on aikarajoitettu kestämään maksimissaan 8 tuntia 4 viikon mittaiselle sprintille. Ensimmäisessä osassa tiimi ja asiakkaan projektipäällikkö käyvät toiminnallisuusluettelon tärkeimmät asiat läpi, jotka hän haluaisi saada valmiiksi sprintin aikana. Tämä sprint planningin ensimmäinen osuus keskittyy siihen, mitä pitäisi saada valmiiksi. Koska scrum tiimi hoitaa myös jatkuvan palvelun tehtävistä kyseisen aiheualueen osalta, niin tällöin pitää tiimille huomioida jatkuvan palvelun suorittamiseen kuluva aika (eli tätä kautta tulee lisää tehtäviä tehtäväksi) varaten sovittu prosenttimäärä työaikaa näiden äkillisten tehtävien suorittamiseen. Kun on tiedossa, mitä pitäisi saada valmiiksi, alkaa sprintin suunnittelun osa kaksi. Osassa kaksi tiimi vetäytyy miettimään, kuinka paljon toiminnallisuuksista on mahdollista toteuttaa sprintin aikana. Tänä aikana tiimi muodostaa sprintin tehtävälistan (sprint backlogin), joka sisältää sprintissä tehtävät asiat pilkottuina pienempiin osiin (yhden tehtävän pituus maksimissaan päivän mittainen). Tiimi aloittaa sprin-

101 Sote-tietojohtaminen 101 (112) tin tehtävälistan muodostamisen korkeimman prioriteetin omaavasta toiminnallisuudesta. Toisin sanoen sprintin osassa kaksi saadaan tieto siitä, miten toiminnallisuudet saadaan toteutettua. Sprintin suunnittelun lopuksi on tiedossa, mitä sprintin aikana on tarkoitus saada valmiiksi ja miten nämä asiat saadaan valmiiksi. Tämän jälkeen sprintti lyödään lukkoon. Tämä tarkoittaa, ettei sovitun sprintin aikana lisätä tehtävää toiminnallisuutta vaan uudet asiat siirretään seuraavaan sprintiin. Kunkin sprintin lopputuloksena syntyy kyseiseltä osin täysin valmis osuus sovelluksesta. Ensimmäisen kahden sprintin aikana on mahdollista, että tiimit yli-/alisuoriutuvat. Eli voi tulla vastaan tilanne, että saataisiinkin tehtyä enemmän asioita kuin suunniteltu ja tällöin voidaan Deputy Product Ownereilta pyytää uusia tehtäviä Product Backlogista. Tilanne voi olla myös päinvastainen. Joka tapauksessa yli-/alisuoriutumisesta ilmoitetaan välittömästi Deputy Product Ownerille. Kuva 67 : Scrum-ohjelmistokehitysmalli Sprintit jaetaan siten, että ensimmäinen sprintti sisältää asiakkaalle eniten arvoa tuottavat tehtävät ja ovat näin ollen priorisoinnissa korkeimmalla. Seuraavat sprintit sisältävät taas seuraavaksi eniten arvoa tuottavat jne. Sprinttien pituudet vaihtelevat 3-30 päivän välillä. Asiakkaan edustaja (Deputy Product Owner) päättää tämän priorisointijärjestyksen. Kuvassa 13 esitetään esimerkki toimintaluettelosta yhden sprintin osalta. Samanaikaisesti voidaan tarkastella useampia sprinttejä (kuvan oikeassa laidassa on näkyvissä eri sprinttejä). Kuva 68 : Esimerkki toiminnallisuusluettelosta yhden sprintin osalta Toteutus etenee sovitun mallin mukaisesti kaikissa eri tiimeissä samanaikaisesti. Ilman samanaikaisuutta ja yhteistä mallia aikataulun saavuttaminen vaikeutuu. Tiimien koordinointi tapahtuu kokousten ja yhteisten suunnitelmien avulla. Kuvassa 14 esitetään yhden hankkeen osalta tilannekuva eri osa-alueiden etenemisestä:

102 Sote-tietojohtaminen 102 (112) Kuva 69 : Kokonaiskuva useamman osa-alueen osalta Koko hankkeen osalta voidaan saada kokonaiskuva toteutuksen etenemisestä kuvan 15 mukaisesti.

103 Sote-tietojohtaminen 103 (112) Kuva 70 : Hankkeen tehtävät ja tehtävien vaihe Scrum-roolit kehityksessä Scrum-ohjelmistokehitysmenetelmässä on kolme pääroolia: Main Product owner, omistaa lopputuloksen ja vastaa siitä loppuasiakkaille, Deputy Product Owner, omistaa osa-alueen lopputuloksen ja vastaa siitä, että se on Main Product Ownerin tarpeiden mukainen ScrumMaster, vastaa siitä, että toimitaan scrum-prosessin mukaisesti ja että tehdään teknisesti oikeita asioita. Team, joka toteuttaa varsinaisen ohjelmiston, tiimiin kuuluu eri osaamisia omaavia henkilöitä. Esimerkiksi arkkitehti, testaaja, ohjelmoijia, substanssialueen asiantuntijoita, käyttöliittymäasiantuntija Scrum-kokoukset Seuraavassa kappaleessa on kuvattu Scrum-menetelmän mukaisten kokouskäytäntöjen soveltaminen BIpalvelussa/projekteissa ja yhteistyömallissa eri toimittajien kesken. Alla olevan taulukon ensimmäisessä sarakkeessa on kuvattu scrum-kokouksen nimi, toisessa kokouksen tarkoitus, kolmannessa se kuinka kokousta hyödynnetään ja neljännessä kokouksen järjestämistapa.

104 Sote-tietojohtaminen 104 (112) Scrumkokous Tarkoitus Osallistujat Käyttö Kokous Sprint planning meeting Suunnitellaan yhden päivän workshop kokouksessa sprinttiin kuuluva osuus kokonaistoteutuksesta ja arvioidaan työmäärät Deputy product owner, scrum master, osa tiimien henkilöistä. Pidetään tiimien yhteinen kokous, jossa suunnitellaan, mitä seuraavaan sprinttiin toteutetaan. toteutetaan. Deputy Product owner eli asiakas päättää vaiheistuksen eli on mukana kokouksessa. Asiakkaan tai toimittajan tiloissa pidettävä kokous Daily scrum Päivittäinen tiimin tilannekatsaus ( tehty eilen, teen tänään, ongelmat ) (max 15 min). Tarvittaessa (optionaalinen): mahdolliset ratkottavat ongelmat. Halutessaan Deputy product owner, scrum master), tiimi Yksittäisen tiimin sisäinen kokous pidetään päivittään. Video/livemeeting/ netmeeting/connectpro - kokous/puhelinpalaveri Ensin tilannepalaveriasiat (15 min), sen jälkeen tarvittaessa (optionaalinen) mahdolliset ratkottavat ongelmat. Scrum of scrums Tiimien välinen tilannepalaveri max 15 min + 15 min. Pidetään kaksi kertaa viikossa tiistaisin ja torstaisin (mitä tiimi tehnyt, mitä tekee seuraavaksi, hidastaako joku asia tekemistä, tuleeko tiimin oma toiminta aiheuttamaan esteitä muille tiimeille). Ensin tilannepalaveriasiat (15 min), sen jälkeen tarvittaessa (optionaalinen) mahdolliset Deputy Product Owners. Scrum Masters, tarvittaessa tiimien edustajia (max 1-2 tiimistä). Käytetään koordinoimaan eri tiimien yhteistyötä. Nopea reitti saada tietoa ja kertoa omasta edistymisestä ja ratkoa ongelmia. Video/livemeeting/ netmeeting/connectpro - kokous/puhelinpalaveri

105 Sote-tietojohtaminen 105 (112) ratkottavat ongelmat. Sprint review Esitellään sprintin tulokset ohjausryhmälle (max 4 h). Käydään läpi sprintin aikana tehdyt ja tekemättömät tehtävät. Sovitaan jatkotoimenpiteistä. Palvelun / Projektin ohjausryhmä, Deputy Product Owners, ScrumMasters,,tarvittaessa tiimin henkilö Käytetään sekä yksittäisten projektin/tiimin tulosten esittelyyn että eri tiimien välisten tulosten (kokonaisuuden esittelyyn). Sekä palvelun seurantaan Asiakkaan tiloissa pidettävä kokous Sprint retrospective Kaikki Tiimin jäsenet arvioivat mennyttä sprinttiä ja tehdään tarvittavat korjaustoimet prosessiin, välineisiin ja työskentelytapoihin, selvitetään mikä meni hyvin, mitä voidaan parantaa seuraavaan sprinttiin. ScrumMaster ja tiimin henkilöt Tiimin toiminnan sekä prosessin kehittäminen Jos tiimien välisenä: Asiakkaan tiloissa pidettävä kokous tai Video/livemeeting/ netmeeting/connectprokokous Muussa tapauksessa kunkin tiimin omissa tiloissa Scrum-seuranta Scrum-prosessissa sprintin etenemistä voidaan seurata usealla eri tavalla kunkin Scrum tiimin osalta. Burndown Chartissa samaan kaavioon tiivistetään sprintin tilanne aikataulun, tehtävien etenemisen ja työmäärän osalta. Kuvassa 16 on esimerkki seurantakaaviosta, jota voidaan soveltaa käytettäväksi. Kun eri tiimit raportoitavat etenemisestään, asiakas ja eri tiimit saavat nopeasti kokonaiskuvan ylläpito-ja kehitystehtävien etenemisestä sekä tilanteesta.

106 Sote-tietojohtaminen 106 (112) Kuva 71 : Esimerkki burndown chart yhden sprintin osalta Samaa asiaa voidaan vaihtoehtoisesti tutkia myös kaikkien/ratkaistujen tehtävien suhteen kuvan 17 mukaisesti.

107 Sote-tietojohtaminen 107 (112) Kuva 72 : Luodut/ratkaistut tehtävät Vastaavia tietoja voidaan tarkastella myös kehittäjittäin, jotta voidaan tarvittaessa jakaa työtä tasaisemmin eri tekijöiden kesken. Samassa kuvassa on mukana kaikki toimitukseen liittyvät henkilöt (kuvassa 18 on mustattu muiden kuin Logican henkilöiden nimet).

108 Sote-tietojohtaminen 108 (112) Kuva 73 : Avoinna olevat tehtävät henkilöittäin Vaihtoehtoisesti voidaan tarkastella etenemistä myös Product backlog tehtävätasolla kuvan 19 mukaisesti. Kuva 74 : Sprintin tehtävien tila BI/DW-hankkeisiin soveltuvat ketterät menetelmät (Agily BI method) ja näitä tukevat työkalut. Työkalut ovat kaikkien osapuolten käytössä.

109 Sote-tietojohtaminen 109 (112)

110 Sote-tietojohtaminen 110 (112) 15 JOHDON KÄYTTÄJÄNÄKYMÄ TIETOON ERI TIEDOLLA JOHTAMISEN PÄÄALUEILLA SOTE ESIMERKEIN 15.1 Mittaritiedon käytettävyysvaatimukset johtamisessa Varsinkin operatiivisessa johtamisessa mittaritiedon merkittävin käyttötapa on seurata toiminnan kehittymistä tavoitteisiin nähden ja ohjata toimintaa palvelutoimintaa kuvaavan tiedon avulla. Tällöin siis halutaan käytännössä ensin tietää mikä on toiminnan toteutunut taso o tavoitteisiin nähden ja o mikä on ollut toiminnan kehityksen suunta ja voimakkuus sen jälkeen halutaan tietää mikä selittää toiminnan kehityksen suunnan ja voimakkuuden selittävien tietojen pohjalta tulee pystyä löytämään mihin asiaan tulee kohdistaa kehittäviä toimenpiteitä Edellä mainitut osoittavat ja selittävät tiettyä palvelukokonaisuutta tai prosessikokonaisuutta kuvaavat tarvittavat tiedot tulee ohjausroolihenkilön saada käyttöön mahdollisimman helposti ja selkeästi esitettynä. Kaikilla toiminnanohjauksen tasoilla ja palveluilla voidaan käyttää käytännössä hyväksi todettua johdon käyttöliittymämallia. Tässä käyttöliittymämallissa ylätasolla käyttäjä saa eri tasoilla nähtäväksi osoittavan mittaritiedon ja samalla käyttöliittymässä näkyy suoraan merkittävimpien selittävien tekijöiden mittaritiedot Mittaritiedon tyypilliset esitystavat toiminnanohjauksen eri rooleissa Johtamisessa ja toiminnanohjauksessa tarvittavaa tietoa käytetään eri johtamis- ja ohjausrooleissa tarkoituksenmukaisessa käyttöliittymässä ja muodossa. Nämä käyttötavat ja muodot ovat osittain erilaisia riippuen organisaation toimintaympäristöstä ja omista tavoitteista ja mieltymyksistä. Nämä siis aina määritetään tarkemmin BI-kehityshankkeen yhteydessä.