Julkisen sektorin tietovarantojen ylläpidon kustantaminen

Julkinen sektori rakentaa nyt tietovarantojaan osittain uusiksi osittain tyhjästä. Osa virkamieskunnasta ymmärtää, että ne liitetään useasti osaksi kansallista palveluväylää muiden(kin) hyödynnettäksi. Näin osittain mahdollistetaan ”only once” –periaate eli että uusi tieto kysytään kansalaiselta vain kerran. Jälkimmäinen lause on aika lailla suoraan tuoreista digitalisoinnin periaatteista (http://digisuomi.fi).

Tähän samaan rumbaa olen omassa virastossa liittynyt. OKM:ssä on käynnissä KOSKI-hanke, tutumpi ehkä vanhalla nimellä TOR, todennetun osaamisen rekisteri. Istun myös sen ohjausryhmässä. Samoin osastollamme on tehty pohjatyötä varhaiskasvatuksen tietovarannon perustamiseksi. Lisäksi YTL uusi rekistereitään ylioppilastutkinnon sähköistämisen (vanhahtava termi, mutta olkoon) yhteydessä ja varmaan muitakin mistä en edes tiedä. Puhumattakaan muista toimialoista, niistä tiedän vielä vähemmän.

Joka tapauksessa olen mallintanut oman osastomme ”arkkitehtuuria” edellisistä lähtökohdista ponnistaen ja lean sekä API-first ajattelua hyödyntäen. Haasteeksi ei nouse se etteikö tietovarantoja saada kehitettyä ja vietyä tuotantoon. Toki siinäkin prosessissa olisi suoraviivaistamista ja opin ottamista yksityiseltä sektorilta. Lähdetään kuitenkin siitä että tietovarannot saadaan tehtyä, data alkaa virtaamaan niihin eri lähteistä ympäri Suomea pääasiassa rajapintojen kautta mutta välillä muillakin keinoilla. Oletetaan vielä lisäksi että virastoissa on ymmärretty asiakaslähtöisyys eli kehityksessä on kuultu asiakasta koko kehitysprosessin ajan.

Millä kustannetaan järjestelmien ylläpito ja jatkokehitys?

Tämä on kysymys joka minullekin on esitetty. Resursseja ei ole tällä hetkellä momenteissa ja resursseja vielä tiputetaan. Jotain siis pitää keksiä. Oma reseptini on että:

otetaan lean canvas käteen jokaisen palvelun kohdalla ja mietitään sen avulla liiketoimintamallit.

Yksittäinen virkamies ei sitä canvasta täytä käyttäen kuukauden työpanosta, vaan sopivien sidosryhmien kanssa, mielellään ne asiakkaat jossain kohdin mukana. Lähtökohta pitää olla että canvaksia on useita ja ne iteroituvat eivätkä ole staattisia. Lean canvaksen avulla voidaan miettiä rahoitus ylläpidolle osittain.

Optimi voitaisiin saada yhdistämällä lean canvas ja avoimen tuotteen hallintamalli.

Pitänee tarkentaa että ei se lean canvas välttämättä suoraan sovellu mihinkään. Sekin on kehitetty tiettyyn kontekstiin, joka ei geneerisenä mallina sovellu ehkä sinällään suoraan julkiselle sektorille. Lienee paikallaan kokeilujen kautta etsiä lean canvaksesta muokattu versio tai versioita. Codento on tätä muokkausta jo tehnyt ja kehittänyt siihen ympärille lisää toimintatapoja. Tällainen lean canvas pohjainen lähestyminen sinällään olisi jo tervetullutta julkisella sektorilla niiden perinteisten hankesuunnitelmien tueksi/sijasta. Avoimen tuotteen hallintamalli on toinen työkalu jota voisi soveltaa laajemmin.

Kansallinen palveluväylä perustuu rajapintapalvelujen (API + tuotteistus) hyödyntämiseen.

Tämän lisäksi nostaisin esiin rajapinnat ja niihin liittyvät liiketoimintamallit. Kuten alussa tuli sanottua, kansallinen palveluväylä on konteksti, jonka kautta tietovarantoja tullaan pääsääntöisesti hyödyntämään. Lean canvas ei suoraan sovellu rajapintapalvelun liiketoiminnan mallintamiseen. API yhteisö onkin kehittänyt ensimmäisen version rajapintojen liiketoiminnan suunnitteluun – API Model Canvas. Se on hyvin samanlainen kuin Lean Canvas mutta fokusoi määrittelyn rajapintapalveluun. Näin ollen tulisi käyttää API Model Canvasta rajapintapalvelujen liiketoiminnan mallintamiseen ja suunnitteluun.

Myös tässä kohdin optimi voisi löytyä yhdistämällä API Model Canvas ja avoimen rajapinnan hallintamalli. 

Tarkemman kuvauksen API Model Canvas käytöstä löydät API:suomi sivustolta.

APIModelCanvas-450x322

Palataan alkuperäiseen aiheeseen eli haasteeseen miten rahoitetaan tietovarantojen ylläpito? Yksi malli voisi olla konsortiotyyppinen ratkaisu, jossa keskeiset tietovarantojen hyödyntäjät maksavat osan ylläpidosta. Hehän siitä hyötyvät eniten, joten lienee paikallaan että he sen ylläpitoon myös osallistuvat. Tässä mallissa käytöstä ei makseta ja jokainen rajapintapalvelu on palveluväylän kautta otettavissa sellaisenaan käyttöön. Toisinaan tämä johtaa ehkä tilanteeseen että rahaa siirretään taskusta toiseen, koska virastot hyödyntävät keskenään toistensa tietovarantoja (optimi ja tavoite).

Perusrajapintapalvelujen päälle lisäarvorajapintapalveluja

Näin ollen pitää miettiä myös toisia rahoitusmalleja täydentämään edellistä. Yksi vaihtoehto on rakentaa muokattava rajapintapalvelu hajallaan olevien tietovarantojen päälle. Todellisuudessa yhdellä toimialalla on useita tietovarantoja, joissa on loogisesti tietyn tyyppiset tiedot. Ei siis ole mitään megalomaanista OKM sammiota, jossa on kaikki tieto yhdessä purkissa. Edellisessä vaihtoehdossa rajapintapalvelut, jotka tarjoavat kapean tietovirran toimialan kaikkeen tietoon ovat sellaisenaan kiinni palveluväylässä ja muiden hyödynnettävissä. Sinällään ihan hyvä perusratkaisu.

Aina ei kuitenkaan tiedon hyödyntäjän tarpeita täytetä yhden rajapintapalvelun sisältämällä tiedolla, vaan tarvitaan yhdistelmiä eri tietovirroista. Puhutaan monesti mashup –rajapinnoista. Tällöin tulisi tuottaa asiakkaiden tarpeiden mukaan muokattava rajapintapalvelu toimialan tietovarantojen päälle. Yhteiskunta on menossa kohti palveluyhteiskuntaa, jossa sen sijaan että tehdään kaikki itse (tehdään se mashup omassa palvelussa), ostetaan palvelu jostain valmiina. Kukin toimiala voisi siis tuottaa (yhdessä yksityisen sektorin kanssa) omien perusrajapintapalvelujen päälle lisäarvorajapintapalveluja, jotka yhdistelisivät tietovirtoja asiakkaiden tarpeisiin.

Edellä olevan pohdinnan perusteella voisi miettiä, että olisi seuraavia rajapintapalvelujen liiketoimintamalleja:

  • Avoimet rajapinnat (palveluväylän ulkopuolella) rajallisten tietojen tai käyttömääräoikeuksin. Vähän niin kuin freemium malli softabusineksessa. Tässä on se haaste että helposti tulee rajapintapalvelu, joka ei tarjoa kenellekään mitään eikä ole kovin hyödyllinen. Ei tietysti aina. Avoimille rajapinnoille on tilauksensa. Lisäksi avoimet rajapinnat ovat innovaation mahdollistava ydin API-taloudessa.
  • Perusrajapintapalvelut kansallisen palveluväylän kautta. Eli siis pääsy yksittäisen eksaktin rajapintapalvelun kautta aina yhteen varantoon. Suurimmat hyödyntäjät sitoutuvat osallistumaan ylläpitokuluihin.
  • Lisäarvorajapintapalvelut, jotka ovat mashup rajapintapalveluja. Palvelun voi ostaa itselleen käyttöön kuukausi tai vuositilauksella. Tässäkin voisi olla hyvä suunnata kohti itsepalvelua sen sijaan että tehdään aina joka tarpeeseen kooditasolla toteutus. Se tulee kalliiksi ja on hidasta. Pitäisi siis rakentaa käyttöliittymä tason ratkaisu, jossa palvelun tilaaja voi itse määrittää mitä tietoja haluaa saada; missä järjestyksessä ja missä muodossa (JSON/XML/tiedosto). Palvelun hyödyntäjä tekee itse työt eli määrittää generoitavan rajapinnan yhdistelmätietomallin ja muut ehdot. Toki tässä voi myydä rinnalla myös avaimet käteen palvelua, jossa asiakas vain toimittaa palvelun omistajalla tiedot tarpeistaan ja palvelun omistaja tekee työt (saman käyttöliittymän kautta).
  • Edellinen modifikaatio olisi lisäarvorajapintapalvelut, jotka yhdistävät palvelun omistajan tietovirtoja ja muiden tietovirtoja. Sama käyttöliittymä, mutta lisää vaihtoehtoja mistä tiedot voivat tulla. Tämän palvelun avulla kansalaisen palvelunäkymätkin voitaisiin populoida.
Mainokset

Kommentoi

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s