Älä osta sikaa paperilla

Me suomalaiset olemme hieman naiivia kansaa. Jos jotain on kirjoitettu paperille, niin oletamme sen olevan totta. Kun IT-hankkeen sopimukseen kirjoitetaan että halutuilla ominaisuuksilla varustettu järjestelmä on käyttökunnossa sovittuna päivänä, niin meillä on tapana uskoa tähän. Todellisuudessahan on ihan sama mitä sinne sopimuspaperiin on kirjoitettu, niin IT-hanke menee usein kiville.
Olen todistanut toistuvasti tilanteita, missä IT-projektin alussa on myyty epärealistinen sopimus, jossa luvataan kuu taivaalta. Sopimukseen on usein kirjattu erilaisia rangaistuksia ostajan mieltä rauhoittamaan. Todellisuudessa, sitten kun projekti on ajettu kiville, ei käytännössä kuitenkaan ole muuta tehtävissä, kuin jatkaa projektia. Rangaistusten käyttäminen olisi niin työlästä, että on helpompi vain yrittää puskea projekti maaliin. Rangaistukset ajaisivat pahimmillaan vain toimittajan konkurssiin. Tämähän ei ainakaan nopeuttaisi järjestelmän valmistumista. Usein ei myöskään paljon hidastaisikaan.
Väitän että alusta asti win-win ajattelulla prosessiin sisäänrakennettu läpinäkyvyys vie pidemmälle kuin vanhakantainen tiukka sopimusneuvottelu. Kokemuksen syvällä rintaäänellä väitän, että ajattelu lähtee luisumaan jommalle kummalle uralle heti tarjousprosessista alkaen. Väitän myös että kulttuurimuutoksen win-win ajatteluun ja läpinäkyvyyteen voi ostaa organisaatioon ulkopuolelta ulkopuolisen konsultin muodossa, ellei oma organisaatio siihen taivu. Ulkopuolinen pystyy ravistelemaan organisaatiota rohkeammin ja objektiivisemmin.

Ostoprosessi

Tietojärjestelmäprojekti ostetaan usein samalla kaavalla: Ylempi johto luo uuden bisnesvision, keskijohto kerää jonkinlaisen vaatimuslistan uudelle järjestelmälle ja hankintaosasto pyytää tarjousta tutuista IT-yrityksistä. Vastapuolella, tarjouksen antavassa yrityksessä, myyjä antaa vapaalle projektipäällikölle tehtäväksi arvioida paljonko työtä projekti vaatii. Tämän pohjalta myyjä hinnoittelee hankkeen toteutuksen ja jättää tarjouksen. Lopuksi tilaaja valitsee usein halvimman tarjouksen.
Projektipäällikön näkökulmasta tätä yleistä ostotapaa voi lähestyä karrikoiden kolmesta tulokulmasta, jotka esittelen seuraavissa kappaleissa. 

1. Myy halvalla ja tinkaa jatkoa

Tämä perälauta-malli on klassinen toimintatapa, joka tuottaa kaikille osapuolille pahaa mieltä ja harmaita hiuksia. Tässä mallissa annetaan niin halpa tarjous, että asiakas ei voi olla tarttumatta siihen. Tämän jälkeen hankkeessa koodataan paljon, dokumentoidaan vähän ja käytetään yleisesti alhaisen kypsyystason systeemityömallia. Projekti ajetaan tietoisesti tai vahingossa sekä aikataulun että työmäärien puolesta perälautaan. Tämän jälkeen alkaa toimintamallin työläin vaihe. Kun aikataulu ja budjetti on käytetty, niin ensin etsitään syyllistä arvioiden ylittymiselle. Seuraavaksi pohditaan, onko projektille mahdollista ostaa pieni jatko-osa, jolla projekti saadaan pelastettua. Sillä ”Eihän jo tehtyä kallista koodia kannata hukkaankaan heittää”. Tämä työläs ja riitainen syyllisen etsimisen ja toistuvien jatkomaksujen vaihe jatkuu, kunnes hanke saavuttaa riittävän toiminnallisuuden tai hanke viimein lopetetaan rohkeasti kesken. Käytännössä toteutuneet hinta, aikataulu ja vaatimukset ovat muuta kuin mitä alun perin tarjottiin.

Kuva 1: Perälauta-mallissa hinta arvioidaan alakanttiin. Toteutusvaiheessa hinta ja aika venyvät arvioidusta, vaatimusten jäädessä alakanttiin.
Kuva 1: Perälauta-mallissa hinta arvioidaan alakanttiin. Toteutusvaiheessa hinta ja aika venyvät arvioidusta, vaatimusten jäädessä alakanttiin.

2. Myy puskuria
Laadukasta työtä tekevä IT-talo harvoin tekee halpaa tarjousta. Sen sijaan he pyrkivät tekemään realistisen tarjouksen. Sekä tarjous että siihen vastaava tarjouspyyntö kuvaavat lähes poikkeuksetta vain pienen osan järjestelmän todellisesta, lopullisesta toiminnallisuudesta. Ylätason vaatimukset kattavan tarjouspyynnön laatimisen yhteydessä unohdetaan usein kokonaisia käyttäjäryhmiä, puhumattakaan teknisemmistä ei-toiminnallisista vaatimuksista. Puskurin myymisellä pyritään ennakoimaan nämä tarjouspyynnöstä puuttuvat näkökulmat ja hinnoittelemaan projektin aidosti sille tasolle, mitä järjestelmän valmiiksi saattaminen oikeasti vaatii. Emme tiedä miten hanke etenisi käytännössä, koska tämä hanketarjous ei koskaan voita.
Kuva 2: Tarjousvaiheessa hinta ja aika arvioidaan realistisesti, jolloin toteutusvaiheeseen ei koskaan päästä.
Kuva 2: Tarjousvaiheessa hinta ja aika arvioidaan realistisesti, jolloin toteutusvaiheeseen ei koskaan päästä

3. Myy ketteryyttä
Ketterässä ajattelussa myönnetään heti kärkeen että sen paremmin tarjouksen pyytäjä, kuin tarjouksen jättäjäkään, eivät pysty nykytiedon valossa arvioimaan hankkeen todellista laajuutta. Tämän vuoksi käytetään vaiheittaista projektimallia, jossa projektitiimi tekee muutaman viikon etapeissa järjestelmän toteutusta tiiviissä yhteistyössä tilaajan ja loppukäyttäjien kanssa. Joka etapista valmistuu demo, joka toteuttaa osan vaatimuksista. Vaatimukset toteutetaan korkean kypsyystason systeemityömallilla, niin että kokonaisuus on versiohallittu ja dokumentoitu. Kunkin etapin hinta ja etapissa valmistuneet vaatimukset ovat kaikille täysin läpinäkyviä. Hankkeen todellinen valmistumisvauhti ja suunta ovat läpinäkyviä niin asiakkaalle kuin toteuttavalle osapuolellekin. Ellei etapista tule jostain syystä mitään valmista pihalle, niin nopeus on asiakkaan näkökulmasta 0. No excuses. Hanke voidaan milloin vain lopettaa tai siirtää toiselle toimittajalle.
Kuva 3: Tarjousvaiheessa sitoudutaan joustavuuteen, toteutus realisoituu hallitusti pala palalta.
Kuva 3: Tarjousvaiheessa sitoudutaan joustavuuteen, toteutus realisoituu hallitusti pala palalta.

Sitoudu joustavuuteen

Tilanne ei ole todellisuudessa näin mustavalkoinen. Ketteryyden etuja voidaan hyödyntää, vaikka projekti haluttaisiinkin ostaa staattisella aikataululla ja hinnalla. Voidaan laatia ketterä tarjous, jossa vaatimukset priorisoidaan niihin jotka on pakko saada ja niihin jotka olisi hyvä saada. Ensimmäisten etappien vauhti antaa projektin alussa suuntaa siitä, minkä verran ominaisuuksia annetulla budjetilla ehditään toteuttamaan. Tämän pohjalta voidaan hienosäätää alussa annettuja prioriteetteja. Avoin keskustelu vaatimusten prioriteeteista toimittajan ja asiakkaan välillä on tärkeää. Alla olevaan listaan on hahmoteltu esimerkinomaisesti tasoja, joilla vaatimuksia voi hankkeen alussa jaotella. Jo yksinkertainen priorisointi avaa arvokkaan keskusteluyhteyden toteuttajan ja tilaajan välille vaatimusten riippuvuuksista, aikatauluista ja pidemmän aikavälin tavoitteista.

  • Alfa 0.1: Teknologiademot asiakkaalle uusista sovellustavoista
  • Beta 0.5: Arkkitehtuuridemot, joissa toiminnallinen ja ei-toiminnallinen perustoiminnallisuus todistettavasti toteutettu
  • Tuotanto 1.0: Tärkeimpien käyttäjäryhmien tärkeimmät toiminnot
  • Tuotanto 1.1: Kaikki ”pakolliset” toiminnot, joita ei vielä ole aivan pakko saada 1.0 versioon
  • Tuotanto 2.0: Spekulatiiviset vaatimukset, jotka elävät voimakkaasti, eivätkä sellaisenaan välttämättä toteudu koskaan.

Kaikki alkaa tarjouspyynnöstä

Vai alkaako sittenkään? Tarjousprosessi määrittää hankkeen onnistumisedellytykset. Tarjousprosessin tavoitteena on hankkia oikeita asioita, oikealla tavalla. Tarjousprosessin aikana voidaan sitoa sellaisia muuttujia, jotka ajavat hankkeen myöhemmin karille. Prosessissa voidaan myös jättää sopimatta joitain, hankkeen onnistumisen kannalta elintärkeitä asioita. Jo ennen tarjouspyyntöä tulee tunnistaa muutoksen tavoitteet ja vasta sitten lähteä pohtimaan teknisiä vaatimuksia. Harvalta ihmiseltä löytyy kaikkea tarjousprosessin vaatimaa osaamista. Prosessi vaatii aina yhteistyötä; Organisaation sisäistä yhteistyötä ja yhteistyötä toimittajakandidaattien kanssa.

Yhteenveto

Artikkelin on tarkoitus rohkaista avoimeen kommunikaatioon IT-hankinnoissa. Tarjouksen sparraaminen mahdollisten toimittajien kanssa lisää kaikkien osapuolien ymmärrystä tavoitteista, tarpeista ja toteutusvaihtoehdoista. Paras tapa varmistaa hankkeen onnistuminen niin aikataulun, budjetin kuin vaatimusten suhteen, on aloittaa hanke laadukkaalla tarjousprosessilla. Usein on perusteltua käyttää ulkopuolista konsulttia jo tarjousprosessin läpiviennissä. Ulkopuolinen henkilö tuo objektiivista osaamista ja kokemusta, sekä uskaltaa haastaa mahdollisia haitallisia toimintatapoja ja ajatusmalleja puolin ja toisin. Toisaalta, on myös olemassa paljon esimerkkejä pelastetuista IT-hankkeista, joissa toimittajan vaihto on tehty vasta kun alkuperäinen sopimus on ajettu kiville. Avoin tosiasioiden tunnistaminen ja nopea, ketterä päätöksenteko ovat nykyaikaisen johtamisen peruskiviä.

Jari Hietaniemi

Jari Hietaniemi

Jari on yksi Goforen monilahjakkaista palveluarkkitehdeista. Hänen ydinosaamistaan on monimutkaisten sekä laajojen tietojärjestelmähankkeiden suunnittelu ja vetäminen. Jarin filosofian mukaan projektipäällikkö on tarvittaessa myös myyntiedustaja, innovaattori, laatupäällikkö, tekninen suunnittelija ja henkilöstöesimies samassa paketissa. Hänen monipuolinen kokemuksensa ja valmentava tyylinsä vievät projektit laadukkaasti maaliin sekä tuovat myös uudenlaista ajattelua ja draivia kohdeorganisaatioon.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Yleisradio (Yle) valitsi Goforen kumppanikseen palvelukehittämisen puitejärjestelyyn. Goforen asiantuntijat tarjoavat konsultointi- ja asiantuntijapalveluja arkkitehtuurin ja prosessien kehittämistä koskevalla palvelualueella. Palveluja käytetään Ylessä esimerkiksi kokonaisarkkitehtuurin ja arkkitehtuuriprosessien kehittämiseen kokonaisuutena sekä Ylen eri domain-alueilla.
Suoran kumppanuuden lisäksi Gofore on mukana alihankkijana puitejärjestelyn ICT- ja tuotanto tekniikkapalvelujen kehittämisen, hankinnan ja hallinnan palvelualueella.
 
Lisätietoja:
Gofore Oy
Juha Virtanen, myyntijohtaja
050 413 3136, juha.virtanen@gofore.com
Yleisradio Oy
Roope Sovala, IT Manager
0400 982288, roope.sovala@yle.fi

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Goforen rekrytointiputkessa virtaus on jatkuvaa, ja virta tuo mukanaan myös entisiä nokialaisia. Moni Keilaniemen ja Hervannan kasvatti on rantautunut Goforelle.
Mitkä ovat rekrytoinnista vastaavien neuvot töiden hakuun Goforelta? Minkälaiselle osaamiselle on kysyntää ja mihin hakemuksessa kannattaa kiinnittää huomiota?
Haastattelussa Goforen rekryvastaava Mari Wuoti ja kulttuurijohtaja Erkki Salminen.

Paljonko paikkoja on ylipäätään auki?

Mari: Meillä on jatkuvasti yli 10 erilaista paikkaa auki. Tänä vuonna palkkaamme noin 100 työntekijä, mutta silti seula on tiukka. Tarkempia taitoja on eritelty nettisivujemme avoimissa työpaikoissa, mutta myös avoimen hakemuksen tekeminen kannattaa.

Minkälaisia osaajia etsitte?

Erkki: Tarpeita on hyvin monenlaisia. Sovelluskehityksen lisäksi teemme muun muassa johdon konsultointia, palvelumuotoilua, käytettävyyssuunnittelua, graafista suunnittelua, hankehallintaa ja arkkitehtuurikonsultointia.
Mari: Nyt suurin tarve on kokeneille kehittäjille ja palveluarkkitehdeille.
Kehitystehtävissä haasteena monella ex-nokialaisella on kuilu Nokialla opitun teknologian ja täällä tarvittavan teknologian välillä. Esimerkiksi hakija on saattanut käyttää Nokia-aikanaan jotain tiettyä teknologiaa ja on siinä mestari. Meidän asiakkaat odottavat palveluidensa kehittämistä moderneilla teknologioilla. Jos kehittäjä pystyy heittäytymään uudella teknologialla noviisitasolle ja ylittämään teknologiakuilun, niin töitä löytyy.
Palveluarkkitehdiksi toivovan osaamissalkkuun mahtuu esimerkiksi laajaa, ulkoisille asiakkaille tehtyä projektinhallintaa, vaatimusmäärittelyä tai arkkitehtuurisuunnittelua, kädet savessa otteella. Ketterien menetelmiien tuntemuksesta on apua tässäkin tehtävässä.

Olin Nokialla huippuspesialisti, kuinka erityisosaamistani voi hyödyntää jatkossa?

Mari: Paljon on merkitystä kuinka oman osaamisensa ilmaisee ja onko halukas myös oppimaan uutta. Jos meillä on kaksi hakijaa täsmälleen samalla taustalla, mutta toinen hakijoista on tehnyt jotain oman osaamisensa eteen, niin ero hakijoiden välillä on jo aika iso.
Erkki: Meille hakeneilla ex-nokialaisilla on monesti paljon hyvää kokemusta, mutta osaamisen avaaminen työhakemuksessa on vaikeaa. Telekommunikaatioala vilisee akronyymejä, jotka eivät ole meidän kaltaiselle yritykselle tuttuja. Hakija saattaa vaikka kertoa mitä protokollia on ollut kehittämässä, kun oleellisempaa olisi kuvata mitä tästä työstä syntynyt kokemus ja osaaminen merkitsevät uudelle työnantajalle ja sen asiakkaille.
Mari: Odotamme hakijoilta innostuneisuutta. Irtisanomisen jälkeen hakija voi olla alamaissa ja se on täysin inhimillistä. Silti innostuksen pitää näkyä hakemuksessa ja haastattelussa. Onko hakija selvittänyt itselleen mitä haluaa, miksi juuri haettu tehtävä motivoi ja miksi haluaa kiihkeästi tulla valituksi?

Mihin hakemuksessa kannattaa panostaa?

Mari: Kannattaa käyttää hetki sen miettimiseen mitä tällainen firma tarvitsee? Olemme konsultteja, jotka tekevät asiakkaille projekteja. Olemme todella otettuja, kun joku haluaa meille töihin, mutta vastaavasti toivomme hakijan miettivän, mitä hän toisi lisää meille.
Erkki: Myytävyys on todella tärkeä näkökulma, joka monelta hakijalta unohtuu. Ei suinkaan ainoa, mutta tärkeä. Ensimmäinen askel konsulttibisneksessä on pystyä myymään itsensä asiakkaalle.
Mari: Hyvin muotoillun CV:n merkitys on tärkeä. Vaikka ura olisi kuinka pitkä, niin CV:n pitää olla tiivis. Sieltä pitää ymmärrettävästi löytyä oma osaaminen ja kokemus sellaisessa muodossa, että sisällön ymmärtää sujuvasti.

Haluanko edes hakea? Te olette niin ketteriä ja minä tykkään siiloista, linjaorganisaatioista ja byrokratiasta?

Mari: Soveltuvuus on työhaastatteluissa vakioaiheita. Pari kertaa olen työhaastattelussa heittänyt seuraavan case-tehtävän: Saavut aamulla töihin, asiakas tulee paikalle 15 minuutin päästä. Huomaat, että edellisenä iltana konttorilla on vietetty laatuaikaa työkavereiden kanssa. Mitä teet? Aktiivisuutta ja itseohjautuvuutta tarvitaan kaikilla rintamilla.
Erkki: Meidän organisaatiomallimme perustuu yhdessä tekemiseen, avoimuuteen ja keskinäiseen luottamukseen. Tämä voi olla alkuun pieni kulttuurishokki erilaisesta organisaatiosta tulevalle. Silti moni pitkänkin työuran byrokratiassa viettänyt oppii nopeasti uusille tavoille, jos itse haluaa.

Mari: Samat ohjenuorat pätevät myös rekrytoinnissamme. Pieni rekrytiimimme arvioi jokaisen hakemuksen henkilökohtaisesti, eikä meillä ole käytössä automaattia seulomassa hakemuksia. Arvioimme samalla myös osaamisen soveltuvuutta mahdollisiin muihin rooleihin. Vastaamme aina jokaiselle ja annamme mahdollisuuksien mukaan palautetta.

Jos Gofore vaikuttaa paikalta, jossa sinäkin voisit viihtyä, ja tulevaisuuden visiomme kohtaavat, ole meihin rohkeasti yhteydessä!

Avatar

Juho Pentikäinen

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Malleilla ja menetelmillä voidaan katalysoida muutosta sekä saada siihen ryhtiä ja johdettavuutta. Digitaalinen muutos ja sitä toteuttavat sähköiset palvelut ja tietojärjestelmät eivät kuitenkaan synny yksin insinöörimäisillä lähestymistavoilla, vaan tarvitaan myös ideointia, innovointia ja vuorovaikutusta – sekä uskallusta astua menetelmäkehikkojen ulkopuolelle.
Kattava ja tehokas palveluiden ja prosessien muotoilun menetelmäpakki kootaan sovittamalla yhteen kokonaisarkkitehtuuria, palvelumuotoilua ja leania. Lean on asiakasarvon maksimointiin pyrkivä johtamisfilosofia, kun taas kokonaisarkkitehtuuri ja palvelumuotoilu ovat menetelmiä ja välineitä kehittämistoiminnan tueksi – niitä voidaan soveltaa lean-toiminnan osana, leania tukien tai siitä täysin irrallaan. Näissä kaikissa on olemassa toisiinsa linkittyviä elementtejä, joiden ymmärtäminen tuottaa kehittäjälle välineet ja keinot tehokkaaseen asiakaslähtöiseen palveluiden ja prosessien kehittämiseen.

Eikö kokonaisarkkitehtuuri jo kuollut?

Ei – kiihtyvä kehitystahti on vain vaikuttanut sen luonteeseen ja tekemisen tapaan: kokonaisarkkitehtuurityö on muuttunut ja muuttuu ketteräksi. Ketteryys edellyttää välitöntä arkkitehtuurikyvykkyyttä: enää ei ole aikaa tehdä kattavia nykytilaselvityksiä, vaan tilannekuvan on oltava jo hanskassa ja on keskityttävä mahdollisuuksien näkemiseen.
Enää ei voi tuottaa laajoja suunnitelmia varastoon, vaan pitää suunnitella virtaviivaisesti ja tuottaa arkkitehtuurivaatimuksia jatkuvasti kehitystyön imussa. Tekeminen ei ole enää isoja projekteja, vaan jatkuvaa muutosten, vaatimusten ja toimivien tuotosten kehittämisvirtaa. Suunnitelmat ovat kiteytyneet pitkistä dokumenteista yksinkertaisiin arkkitehtuurivisioihin ja konsepteihin. Niiden näkökulmat ja elementit heijastavat yhä vahvasti kokonaisarkkitehtuuria.

Lean valtaa kehittämiskenttää

Yhä suurempi osa kehittämistoiminnan johtamisesta on muuttumassa leaniksi. Ketterä kehittäminen ja DevOps ovat tuoneet välitöntä lean-filosofiaa takaovesta sisään moneen organisaatioon, ja ne ovat muuttaneet resurssikeskeiset toimintamallinsa asiakas- ja lopputulosorientoituneiksi. Lean on kulttuurinen toiminnan malli, jonka ytimessä on jatkuva oppiminen ja toiminnan parantaminen.
Lean-filosofian mukaan johdettu toiminta on asiakaslähtöistä. Toiminta järjestetään asiakkaan kannalta mahdollisimman viiveettömäksi ja asiakasarvoa parhaiten tuottavaksi. Usein lean-kehittämisen fokus on kuitenkin vahvasti sisäisissä prosesseissa ja palveluprosessien hukkien minimoimisessa – keskitytään prosessin viiveettömyyteen ja unohdetaan tai jätetään vähemmälle huomiolle se, miten asiakkaan palvelukokemus kokonaisuudessaan synnytetään.

Palvelumuotoilu viimeistelee paketin

Palvelumuotoilun lupaukset ovat samankaltaisia kuin leaniin liittyvät asiakasarvon maksimointilupaukset. Leaniin verrattuna palvelumuotoilussa on kuitenkin kaksi keskeistä eroa: palvelumuotoilu on yksittäiseen kehittämiskohteeseen sovellettava menetelmäjoukko, kun taas lean on filosofia ja jatkuvaa toimintaa. Palvelumuotoilu keskittyy asiakkaan palvelupolun ja siinä syntyvän kokemuksen trimmaamiseen, kun taas leanissa on kyse enemmänkin itse palveluprosessin ja sen pullonkaulojen viilauksesta. Palvelupolku syntyy palveluprosessin, palvelukanavien ja vuorovaikutustilanteiden tuloksena, mutta näkökulma ja kehittämisen fokus ovat näissä yleensä erilaisia. Palvelumuotoilu tukee hyvin leanin tavoitteita ja auttaa asiakasarvon viimeistelemisessä.

Tehokas muotoilun kokonaisuus

Lean, palvelumuotoilu ja kokonaisarkkitehtuuri synnyttävät yhdessä vahvan asiakaslähtöisen kehittämisen työkalupakin – siis tavan tehdä muotoilua (Kuva 1). Muotoilu sovittaa tuotteen tai palvelun käyttötarpeeseensa ja perustuu asiakasarvon maksimointiin toiminnan kaikissa osissa.

Työkalukokonaisuudessa lean on vertikaalinen asiakasarvon luomiseen keskittyvä johtamisfilosofia, joka risteää sekä palvelupolun että palveluprosessin kanssa. Palvelumuotoilu on horisontaalinen kehittämismenetelmä. Sen avulla suunnitellaan ja kehitetään asiakkaan palvelukokemusta, mutta ei varsinaisesti leanin ja kokonaisarkkitehtuurin ytimessä olevaa palveluprosessia tai toiminnan kyvykkyyksiä. Kokonaisarkkitehtuuri taas on nimenomaan toiminnan rakenteellinen suunnittelumenetelmä, joka keskittyy pitkälti sisäisten toiminnan kyvykkyyksien synnyttämiseen.
Menetelmien yhdentyminen merkitsee kokonaisvaltaista onnistumista. Asiakkaan palvelukokemus paranee, prosessi tehostuu ja samalla syntyvät joustavat rakenteet, jotka luovat uutta kehityspotentiaalia. Kun digitaalisen muutoksen suunnittelussa ja johtamisessa yhdistetään kokonaisarkkitehtuurityötä, lean-filosofiaa sekä palvelumuotoilun menetelmiä, asiakas saatetaan voittajana maaliin.
 

Gofore muotoilee -blogisarja. Digitalisaatio, asiakaslähtöisyys ja ketteryys ovat päivän sanoja. Puhujia ja tekijöitä on moneen lähtöön. Me Goforessa tiedämme mistä puhumme, sillä hallitsemme digitaalisen muutoksen koko ketjua asiakkaan liiketoimintamallin kehittämisestä suunnitteluun ja palveluiden toteuttamiseen. Vahvuutemme on muotoilun osaaminen ja kokemus asiakkaalta asiakkaalle. Gofore muotoilee -blogisarja kertoo osaamisestamme, ajatuksistamme ja kokemuksistamme modernin työkulttuurin, palveluiden sekä toiminnan kehittämisessä.

Avatar

Juha Siltanen

Juha on kokonaisarkkitehtuurin ja lean-kehittämisen asiantuntija. Juha johtaa Goforen muotoilupalveluita ja niiden kehittämistä.

Piditkö lukemastasi? Jaa se myös muille.

Gofore on mukana Terveydenhuollon Atk-päivillä Lahdessa 24.–25.5. tapahtuman pääyhteistyökumppanina.  Atk-päivillä käsitellään monipuolisesti erilaisia sote-sektorin ajankohtaisia aiheita. Me goforelaiset haluamme erityisesti nostaa esille avoimuuden merkityksen sote-tietojärjestelmien kehityksessä.
Avoimuutta voidaan toteuttaa arkkitehtuurivalintojen kautta – avoimina rajapintoina, avoimena lähdekoodina. Toisaalta se voi tarkoittaa myös avoimia sote-tietojärjestelmien markkinoita, sellaisia, jotka toivottavat tervetulleeksi vapaan kilpailun ja kaikki uutta luovat ja edistykselliset toimijat. Avoimilla markkinoilla parhaat erottuvat edukseen. Samoin tilaajalla on mahdollisuus elää tarpeiden mukaan ja valita kulloiseenkin tilanteeseensa parhaiten sopivat ratkaisut. Tilaajalta tämä edellyttää uudenlaista osaamista hankintojen kilpailuttamiseen ja sopimusten laatimiseen sekä kykyä purkaa toteutushankkeet modulaarisiin osiin ja hallita monitoimittajaympäristöä.
Parhaimmillaan avoin arkkitehtuuri ja avoimet rajapinnat mahdollistavat avoimien markkinoiden kehittymisen. Tavoitteena tulisi olla ekosysteemi, joka rakentuu itsestään ja luonnollisesti innovatiivisten toimijoiden ja kehittäjäyhteisön luodessa uusia tapoja hyödyntää tietopääomaa ja tuottaa käyttäjien tarvitsemia palveluita. Näemmekin, että tätä kehitystä tulisi rohkaista ja ruokkia, ei rajoittaa erilaisin keinotekoisin kilpailullisin estein.
Atk-päivillä esimerkkinä standardoidun avoimen rajapinnan käytöstä on goforelaisten kehittäjien toteuttama HL7 FHIR -demo. Demo integroituu Omakannan omatietovarantoon ja siihen pääsee tutustumaan Goforen ständillä. Lisää demosta Stefan Baggströmin blogissa.
Goforen Antto Seppälä puhuu tiistaina 24.5. klo 16 (sali 4) aiheesta Unelmana avoin kehittäjäyhteisö – edellytys digiloikalle? Anton ajatuksiin avoimista sote-markkinoista voi tutustua hänen blogissaan.
Stefanin ja Anton lisäksi Goforelta ovat mukana Riitta Alkula, Arto Puikkonen ja Kristiina Härkönen. Löydät meidät ständiltä 34. Tapaamisiin Lahdessa!

Avatar

Kristiina Härkönen

Kristiina on kokenut it-alan asiantuntija, jolla on laaja-alainen kokemus tietojärjestelmien kehittämisestä ja tietojärjestelmäprojektien hallinnasta. Hän on toiminut lukuisien ohjelmistoprojektien eri vaiheissa vastaten ohjelmistojen määrittelystä ja suunnittelusta sekä projektien aikataulun ja etenemisen seurannasta. Lisäksi Kristiinalla on kokemusta kokonaisarkkitehtuurityöstä, ohjelmistotuotannon prosessien kehittämisestä ja järjestelmähankkeiden auditoinnista. Kristiinan erityisosaamista ovat projektinhallinnan menetelmät, tietojärjestelmien määrittely ja suunnittelu sekä kokonaisarkkitehtuuri.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Asiakaskeskeinen ajattelu ja teknologian hyödyntämisen mahdollisuudet julkisen sektorin sosiaali- ja terveydenhuollon kehittämisessä ovat jo laajalti hyväksyttyjä totuuksia. Tavoitteena on parantaa asiakaskokemusta, kehittää uusia toimintamalleja ja tehostaa ydin- ja tukitoimintoja. Digiloikan edellytykseksi on sote-tietojärjestelmien osalta puhuttu avoimista rajapinnoista ja integraatioiden merkityksestä. Sinänsä keskustelussa ei ole mitään vikaa, mutta mielestäni kysymys on suuremmasta asiasta. Todellinen digiloikka vaatii ennen kaikkea avoimia ja terveitä ICT-markkinoita. Tämä on perusvaatimus innovatiivisten palvelumallien kehittämiselle sekä julkisen sote-sektorin kilpailukyvylle tulevassa sote-mallissa. Epäterve markkinatilanne on johtanut tilanteeseen, jossa toimittaja- ja dataloukut estävät usein toimintamallien kehittämisen ja uusien toimintatapojen luomisen.
Sähköinen tiedonvälitys, sensoriteknologia ja kehittyneet analytiikkatyökalut mahdollistavat asiakaslähtöiset palvelut sekä laadun ja vaikuttavuuden paremman seurannan. Tiedon uudenlaisella hyödyntämisellä voidaan rikkoa organisaatiorajoja ja integroida eri toimintoja moniammatillisiksi palveluiksi. Palveluita voidaan myös personoida asiakkaan terveydentilan ja arjessa pärjäämisen suhteen (esim. Suuntima). Asiakaslähtöisten arvoverkostojen syntymisen edellytys on, että asiakkaiden tieto on hallinnassa ja sitä voidaan hyödyntää yksittäisten sovellusten ulkopuolella. Tämä on kuitenkin tällä hetkellä hyvin haastavaa.
Sote-uudistus on vapauttamassa markkinoita Suomessa. Julkisen sektorin kilpailukyvyn kannalta mielestäni ICT markkinoiden sulkeutuneisuus on huolestuttava ilmiö. Mikäli julkinen sektori ei pääse eroon toimittajaloukuista ja datalukoista ei kilpailun kannalta oleellista tuottavuusloikkaa voida saavuttaa. Yksityiset toimijat, kuten esimerkiksi Pihlajalinna, pyrkivät hallitsemaan sote-sektoria kokonaisuutena asiakkaan näkökulmasta. Toiminnan suunnittelu ja tehokas järjestäminen perustuu kokonaiskuvan ymmärtämiseen ja tiedon hyödyntämiseen. Tämä mahdollistaa tehokkaammat toimintamallit kokonaisuutta optimoiden. Myös esimerkiksi Meedoc on mullistamassa terveydenhuoltoa kehittämällä alustamaista toimintaa yhdistäen teknologian avulla lääkäreitä ja asiakkaita ilman raskasta organisaatiota tai fyysisiä tiloja.
Avoimien markkinoiden mahdollistamiseksi vaaditaan julkisilta sote-toimijoilta rohkeutta lähteä uudistamaan ennen kaikkea hankintaperiaatteittaan ja sopimusteknisiä asioita. Järjestelmäprojekteissa tulisi pyrkiä modulaarisiin ja hallittaviin kokonaisuuksiin. Tilaajien tulisi pyrkiä vaatimaan osana toimitusta avointa lähdekoodia tai vähintään yhtäläistä käyttöoikeutta syntyneeseen lähdekoodiin, tietojen hallintaa sekä järjestelmien jatkokehitysoikeutta itselleen. Mikäli tiedot tai tietojärjestelmät eivät ole organisaation hyödynnettävissä vapaasti järkevin kustannuksin, niin uusien asiakaslähtöisten toimintamallien kehittäminen on hankalaa. Toinen ratkaisu voisi olla, että tilaajat hankkisivat valmiiden tuotteiden tai järjestelmien sijaan ketteriä kehitystiimejä. Tarkoituksena ei olisi siis määritellä lopputulosta etukäteen liian tarkasti, vaan uskallettaisiin kokeilla ja oppia. Pyrkimyksenä olisi kehittää rinnakkain uutta toimintamallia ja sen mahdollistavaa sähköistä palvelua yhdessä asiakkaiden ja ammattilaisten kanssa. Tämä avaisi ovet todelliselle digiloikalle.
Muilla julkishallinnon sektoreilla on jo syntynyt avoimempia markkinoita. Eri hallinnonaloille on tullut uusia ketteriä ja innovatiivisia toimijoita, mikä on synnyttänyt tervettä kilpailua ja haastanut myös vanhoja toimittajia kehittämään omia toimintamallejaan. Terve kilpailu on parantanut asiakkaiden mahdollisuuksia löytää kustannustehokkaimmat ja vaikuttavimmat toimittajat kulloiseenkin tilanteeseen. Tilanne on hyödyttänyt niin julkishallinnon organisaatioita, veronmaksajia kuin suomalaista ICT-sektoria kokonaisuutena. Hyviä esimerkkejä vaikuttavista julkisista palveluista löytyy esim. Blue Arrow awardsin ehdokaslistoilta.
On mielenkiintoista nähdä tapahtuuko julkisella sote-sektorilla samanlaista positiivista kehitystä. Hyvänä esimerkkinä innovatiivisesta kehittämisestä on Terveydenhuollon Atk-päivillä esitettävä FHIR-demo, jossa eri järjestelmätoimittajat ovat yhteistyössä kehittäneet uudenlaisia yhteiskäyttöisiä sovelluksia. Markkinoiden avautumisen kannalta on ollut myös positiivista seurata Una-hanketta, jossa on vakavasti mietitty modulaarista järjestelmäkokonaisuutta. Tämä voisi mahdollistaa hajautetun hankinnan ja markkinoiden avaamisen kilpailulle, mikä olisi kaikkien etu.
 

Avatar

Antto Seppälä

Antolla on lähes kymmenen vuoden kokemus sosiaali- ja terveydenhuollon kansallisista ja kansainvälisistä tutkimus- kehitys- ja arviointiprojekteissa. Hän on perehtynyt erityisesti sote-sektorin tietojärjestelmiin ja toimintamalleihin, lainsäädäntöön sekä tieto- ja viestintäteknologian mahdollisuuksiin henkilökohtaisen terveyden ja hyvinvoinnin hallinnassa.

Piditkö lukemastasi? Jaa se myös muille.

Hallituspartnerit ry on palkinnut Gofore Oy:n Kultaisella Nuijalla tiistaina 17.5.2016. Palkinto jaetaan pk-yritykselle huomionosoituksena hyvästä hallitustyöstä.
Harkittaessa huomionosoituksen saajaa käytetään kriteeristöä, jossa yrityksen avautuminen ja hallitustyön tuloksellisuus ovat keskeisesti tunnistettavissa esimerkiksi hyvän kasvun, onnistuneen strategian, uudistumisen ja kansainvälistymisen aikaansaajaksi.
Huomionososoituksen saajan valitsee yrityselämän ja pk-yritysten hallitustyön ansioituneita asiantuntijoita. Palkintolautakunnan kokoonpano vuonna 2016:

  • Matti Alahuhta, hallituksen pj. Elinkeinoelämän Keskusliitto
  • Anne Berner, hallituksen pj. Oy Vallila Interior Ab
  • Timo Salli, toimitusjohtaja Katsa Oy
  • Risto Siilasmaa, hallituksen pj. Nokia Oyj
  • Arno Ahosniemi, päätoimittaja Kauppalehti Oy.

 
>> Lue lisää Kauppalehden verkkolehdestä.
 

Mallikasta hallitustyöstä. Ali Saadetdin (vas.) , Timur Kärki ja Petteri Venola toimitiloissaan Tampereella. Kuva: Annamari Tolonen
Mallikasta hallitustyöstä. Ali Saadetdin (vas.) , Timur Kärki ja Petteri Venola toimitiloissaan Tampereella. Kuva: Annamari Tolonen

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Me kaikkihan tiedämme, että maailma on täynnä epäonnistuneita ohjelmistoprojekteja. Devaaja kertoo: ”jos saisin yksin koodata kaiken, niin homma menisi täydellisesti maaliin”. Johtaja sanoo vastaan: ”jos homma olisi tehty niin kuin suunnittelin, niin se olisi valmis jo”. Klassinen toisten osoittelun ja syyllistämisen kierre on valmis. Noh, laitetaanpa devaaja johtamaan isoa organisaatiota ja johtaja koodaamaan, niin nurina laantuu molemmissa päissä. Hetken hiljaisuuden jälkeen molemmat ottavat hatun päästä ja kysyvät ”kuinka tämä sitten oikeasti olisi järkevää hoitaa?”. Tästä päästään kokemuksen kautta opittuihin hyviin suunnittelu- ja toimintamalleihin, joita hyödynnetään niin koodauksessa kuin johtamisessa. SAFe (Scaled Agile Framework) poimii näitä hyväksi havaittuja toimintatapoja laidasta laitaan.

SAFe skaalaa ketteryyttä

Ketterän kehityksen menetelmät ja Lean-ajattelu ovat tuttuja käytännössä kaikille nykypäivänä onnistuvia kehityshankkeita tehtaileville tiimeille. Myös isoissa organisaatioissa on opittu, että kehitysprojektit kannattaa ensisijaisesti pitää pieninä ja lyhyinä.
Mutta entä kun halutaan tehdä jotain suurta? Miten hallita isoa hanketta, jossa on satoja kehittäjiä, useita alitiimejä ja aliprojekteja? Kaikki tietävät jo kuinka käy, kun isoa it- hanketta lähdetään johtamaan perinteisellä vesiputousmallilla. Kehityksen tulisi jotenkin säilyttää ketteryys huolimatta siitä, että tehdään isoa järjestelmää. Kun ketterien kehittäjien lukumäärä ylittää muutaman kymmenen kehittäjän haamurajan, niin tarvitaan jotain muuta kuin pelkkää tiimitason toimintaa. Jo pelkästään tiimien keskinäisen kommunikaation lisääntyminen aiheuttaa haasteita. Entä miten varmistetaan tiimien pelaaminen samaan maaliin? Miten maksimoidaan tehtyjen maalien lukumäärä ja tuotetaan asiakkaalle lisäarvo annetuissa aikataulu- ja resurssirajoitteissa? SAFe tarjoaa näihin kysymyksiin ratkaisuja ja toimintamalleja.

SAFe historia

Scaled Agile Framework tuo vastauksen siihen, kuinka ketterä kehitys voidaan skaalata suurhankkeeseen. Vuonna 2008 mallin kehittänyt Dean Leffingwell puhui ”Lean and Scalable Requirements Model for Agile Enterprises” -mallista, josta vähitellen muodostui ensimmäinen SAFe-versio vuonna 2011. Tällä hetkellä standardin versio on 4.0. Dean on harjoitellut SAFella ja sen esimuodoilla ketterän kehityksen skaalausta monissa suurissa yrityksistä. SAFella on skaalattu sekä puhtaita ohjelmistoprojekteja että laiteprojekteja. Nimekkäitä SAFe-käyttäjiä ovat esimerkiksi GE, Intel, LEGO, John Deere, Nokia ja Nordea.
SAFe ei ole itsessään ainutlaatuinen malli. Muita ketterän kehityksen skaalaukseen ohjeita antavia malleja ovat esimerkiksi Agility Path Framework, Disciplined Agile Delivery, Holistic Software Engineering ja Enterprise Scrum. SAFe-malli lainaa ideoita esimerkiksi Scrum, Kanban, Lean, XP ja Principles of Product Development Flow -alueilta. Käytännössä SAFe kuvaa geneerisen toimintamallin ja joukon hyviä toimintatapoja, joiden avulla iso hanke on mahdollista toteuttaa ketterästi. SAFe-mallin käyttäminen vaatii kokemusta ja ymmärrystä, mutta se dokumentoi lukemattomia hyviä käytäntöjä, joiden avulla on mahdollista välttää isolle hankkeelle tyypilliset sudenkuopat. SAFe-malli tarjoaa erinomaisen lähtökohdan, kun toteutetaan isoa kehityshanketta tai halutaan jalkauttaa ketterä kehitys isoon organisaatioon.
Pitkän linjan projektipäällikön näkökulmasta parasta SAFe:ssa on sen laajuus. Sen lisäksi että SAFe tarjoaa mallin ketterän kehityksen ylöspäin skaalaamiseksi, niin SAFe neuvoo, mitä tehdä, kun esimerkiksi ei tiedetä kuinka budjetoida hanke yrityksessä. Se kertoo, miten kirkastaa strategian epäselvyyttä, kuinka järjestää vanhojen tuotteiden ylläpito suhteessa uudiskehitykseen, miten suunnata tiimit, joilla ei ole yhteisiä tavoitteita tai mitä tehdä, kun tuotepäälliköt antavat ristiriitaisia ohjeistuksia kehitystiimeille. Julkishallinnon toiminnan kehittämisen ohjenuoranahan käytetään JHS suosituksia, joiden mukaisiin kuvauksiin myös SAFe taipuu ketterästi.
 

Kuva 1: SAFe on yksi uusi työkalu organisaation ketteryyden kehittämiseen.
Kuva 1: SAFe on yksi uusi työkalu organisaation ketteryyden kehittämiseen.

SAFe kritiikki

Yksilö- ja tiimitasolta tarkasteltuna maailma näyttää usein yksinkertaiselta. Ei tarvitse välittää muista kuin omaa tiimiä koskevista asioista. Tällöin toiminta tuleekin säilyttää yksinkertaisena. Tiimitasolla SAFe poimii toimintamalleja Scrum, Lean, XP, Kanban ja DevOps -ideologioista. SAFe myös toteaa, että tiimillä on valta valita omat toimintatapansa, niin pitkään kuin ketteryyden periaatteet täyttyvät.
Moni Scrum-fanaatikko kokee, että hanke kuin hanke onnistuu hyvältä tiimiltä kun vain seurataan Agile Manifeston periaatteita ja mahdollisesti toteutetaan kevyt tiimien välinen koordinaatiomekanismi esimerkiksi Scrum-of-Scrums tai Communities of Practice -tyylisesti. Jokainen isossa hankkeessa mukana ollut tietää, että asia ei ole näin yksinkertainen. Tarvitaan koko organisaation lävistävä asenne- ja toimintatapamuutos, johon SAFe tarjoaa hyvät eväät. SAFe tarjoaa mahdollisuuden siirtyä ketterään kehitykseen aikaisempaa nopeammin ja helpommin, ilman että kaikkea tarvitsee opetella kantapään kautta. Samaan hengenvetoon on todettava, että SAFe ei ole hopealuoti. SAFe vaatii koko organisaation lävistävää, ketterän ajattelun hyväksymistä. SAFe on myös laaja, ymmärrystä ja sovelluskykyä vaativa ohjeistus.
On naiivia ajatella, että mikään ohjeistus olisi täydellinen. On tyhmyyttä ajatella, että itse jo tietäisi parhaat ratkaisuvaihtoehdot kaikkiin eteen tuleviin ongelmiin. Ketteryys on nöyryyttä olla avoin (myös toisten keksimille) uusille ideoille, ratkaisuvaihtoehdoille ja toimintamalleille. Ketteryys on älykkyyttä pitää kiinni omista mielipiteistään tilanteissa, joissa kokee niiden toimivan hyvin.

SAFe rakenne

SAFen taustalta löytyy paljon periaatteita ja ydinarvoja, jotka auttavat ohjaamaan päätöksentekoa oikeaan suuntaan. Varsinaisen tuotekehityksen SAFe jakaa lyhykäisyydessään neljään hierarkiatasoon: Portfolio, arvovirta, hanke ja tiimi.
Portfoliotasolla hallitaan pitkän aikavälin suunnitelmaa ja business casea, sekä arvovirtoja, joista koostetaan liiketoiminta- ja arkkitehtuuriteemat ohjaamaan pitkän aikavälin rahankäyttöä. Arkkitehtuuri- ja ei-toiminnalliset-vaatimukset huomioidaan hierarkian huipulta saakka.
Arvovirrat otetaan käyttöön vasta todella isoissa, satojen ihmisten hankkeissa. Arvovirrat ovat pitkän aikavälin strategisia teemoja. Arvovirtojen myötä ”arvoa virtaa” jatkuvasti liiketoiminnalle, asiakkaalle tai käyttäjälle. Arvovirtojen työ aikataulutetaan toteutusjuniin, joilla koordinoidaan hanketason työn rytmitystä.
Hanketasolla (program) käytetään portfoliotasolta tulevaa priorisointia hankkeiden kehityksen ohjaukseen. Hankkeiden välillä kehitys synkronoidaan samalla syklillä etenevillä toteutusjunilla (ART, Agile Release Train).
Tiimitasolla seurataan tuttuja ketterän kehityksen toimintatapoja ja tuotetaan säännöllisesti, niin tiimitasoista kuin tiimien työt yhdistäviä julkaisuja. Ideologia nojaa jatkuvan julkaisun malliin, missä asiakkaalle voidaan toimittaa uusi julkaisu milloin vain.
 

Kuva 2: SAFe hierarkiassa on neljä tasoa.
Kuva 2: SAFe hierarkiassa on neljä tasoa.

SAFe Suomessa

Suomessa on jo monia yrityksiä, jotka ovat valinneet Scaled Agile Frameworkin menetelmäkehikokseen vastatakseen ketterän kehityksen skaalautumisen haasteisiin. Maailmalla SAFe on jo vakiinnuttanut asemansa. Ketteryyden skaalaamiseen ylöspäin SAfe:a käytti maailmalla 27 % yrityksistä vuonna 2015 (19 % 2014). Tätä enemmän on käytössä vain Scrum of Scrums/Scrum. SAFe lupaa, että läpimenoaika markkinoille on 30–75 % nopeampaa SAFe:n avulla. 

Gofore SAFe

SAFe:n käyttö vaatii yleensä organisaation läpi leikkaavaa muutosta. Hankkeeseen sopivien ketterien ja Lean -periaatteiden valitseminen, oppiminen, käyttäminen ja soveltaminen ovat yksinkertaiset teesit menestykseen. Ketteryys ei ole rakettitiedettä, mutta vanhoista, jäykistä toimintamalleista, rakenteista ja asenteista luopuminen on usein kivuliasta.
Olemme Goforessa tottuneet tekemään vaativia ja vaikuttavia toimeksiantoja. SAFe:n olemme havainneet toimivaksi työkaluksi varsinkin suurten hankkeiden läpiviemisessä. Meiltä löytyy lukuisia SAFe-sertifioituja ammattilaisia, jotka tuntevat menetelmän parhaat käytännöt ja suurimmat sudenkuopat. Goforen asiakaskunnassa onkin havaittavissa nousevaa trendiä SAFe:n suhteen. Yhä useampi organisaatio haluaa ajaa ison hankkeen hallitusti maaliin – tavoitteet ja aikataulut täyttäen niin paperilla kuin myös käytännössä.

Jari Hietaniemi

Jari Hietaniemi

Jari on yksi Goforen monilahjakkaista palveluarkkitehdeista. Hänen ydinosaamistaan on monimutkaisten sekä laajojen tietojärjestelmähankkeiden suunnittelu ja vetäminen. Jarin filosofian mukaan projektipäällikkö on tarvittaessa myös myyntiedustaja, innovaattori, laatupäällikkö, tekninen suunnittelija ja henkilöstöesimies samassa paketissa. Hänen monipuolinen kokemuksensa ja valmentava tyylinsä vievät projektit laadukkaasti maaliin sekä tuovat myös uudenlaista ajattelua ja draivia kohdeorganisaatioon.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

FHIR-demo esittelee terveydenhuollon tulevaisuuden yhteensopivia ja tehokkaita ratkaisuja, jotka hyödyntävät HL7 FHIR -standardiin perustuvia avoimia rajapintoja. Gofore esittelee demossa sydäntautipotilaiden ryhmävalmennuksen ratkaisua, jossa ammattilainen seuraa potilaiden itsensä tekemiä verenpaineen ja painon mittausten trendejä.
Kansalainen tekee mittauksensa lääkintälaitedirektiivin mukaisilla mittalaitteilla, joista tieto siirtyy automaattisesti Kelan tarjoamaan Omakannan omatietovarantoon FHIR-rajapinnan ylitse. Ammattilaisella on käytössään moderni sovellus, josta näkee koko ryhmän tilanteen nopeasti ja helposti. Järjestelmään on integroitu Duodecimin päätöksentukijärjestelmä, jonka kanssa kommunikoidaan CDS Hooks määrittelyn mukaisesti hyödyntäen FHIR-resursseja. Toteutus on sujunut hyvinkin suoraviivaisesti, joten täytyy todeta standardin hyvyys opittavuuden ja toteutettavuuden osalta. Järjestelmän lähdekoodit julkaistaan avoimesti GitHubissa esimerkkinä FHIR-toteutuksesta taustajärjestelmään ja web-käyttöliittymään. Demossa on mukana 20 sote ICT-järjestelmien johtavaa kehittäjäorganisaatiota sekä Kanta-palveluista vastaavat kansalliset toimijat. Gofore on vastannut demonstraatioprojektin koordinoinnista. Tapahtuman järjestäjänä toimii HL7 Finland ry.
HL7 FHIR on standardi, joka mahdollistaa tiedon liikkumisen terveydenhuollon tietojärjestelmien välillä ennennäkemättömän helposti ja ketterästi. Sen avulla voidaan integroida järjestelmiä yhteen päivissä tai viikoissa, kun aiemmin siihen tarvittiin kuukausia. Standardissa hyödynnetään moderneja web-teknologioita ja parhaimpia paloja aiemmista HL7- standardeista. Nämä yhdessä mahdollistavat nopean oppimisen ja toteutuksen. FHIR-standardin kokeiluversio on jo valmiina ja käytettävissä toteutuksiin. Normatiivisen statuksen standardi saavuttanee ensi vuonna, mutta se ei estä standardin käyttöä jo tänään – ja näin on jo tehtykin maailmalla.
Mukana demossa on laaja joukko erilaisia tietojärjestelmiä: kansalaisille suunnattuja mittalaitteita ja sovelluksia, ammattilaiselle räätälöityjä ratkaisuja, laboratoriojärjestelmiä, toiminnanohjausjärjestelmiä, potilastietojärjestelmiä, kansalaisen Omakanta-omatietovaranto (PHR) sekä monia muita. Osassa toteutuksia käytetään potilastietojärjestelmätoimittajien FHIR-palvelimia ja myös Smart-on-FHIR integraatiot ovat esillä. Demon suuri osanottajajoukko kertoo kiinnostuksesta ja panostuksesta edistää FHIR-standardin käyttöönottoa Suomessa. FHIR-standardin soveltaminen Suomessa tapahtuu HL7 Finland ry:n kautta.
Tervetuloa tutustumaan vaikuttavaan ja monipuoliseen FHIR-kokonaisuuteen messualueelle. Demon esittely jakaantuu useammalle eri ständille – tunnistat ne liekkilogosta. HL7_FHIR_logo
Ennakkotunnelmiin pääset Lahden Messukeskuksen kokoustiloissa jo maanantaina 23.5. kello 18:30 järjestettävässä infotilaisuudessa, joka on avoin kaikille Atk-päivien osallistujille. Goforen tavoitat ständiltä #34 –tule ja kysy lisää tulenkantajilta!
®Health Level Seven, HL7, FHIR and the [FLAME DESIGN]® are registered trademarks of Health Level Seven International, registered in the US Trademark Office.

Lue lisää sote-sektorin ajankohtaisista aiheista Goforen blogista:

 

Avatar

Stefan Baggström

Stefan toimii terveyden ja hyvinvoinnin toimialavastaavana Goforella. Stefan on johtamisen, ketterien menetelmien ja tietojärjstelmäarkkitehtuurien asiantuntija. Työssään hän pyrkii kehittämään asiakaskeskeisiä ratkaisuja ja toimintatapoja kokonaisvaltaisesti kohti jatkuvan onnistumisen mallia.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Tutustu Goforen asiakaslehteen