Potilastietojärjestelmän ostaja – näin vältät tyypillisimmät sudenkuopat

Kerroimme aikaisemmin, kuinka tarpeiden määrittely on potilastietojärjestelmän hankintaprosessin kriittisin osa. Konflikti syntyy useimmiten eroavista käsityksistä ja puutteellisista määrittelyistä – organisaatio ei välttämättä tiedä, mitä järjestelmältä lopulta haluaa.

Joskus vasta käyttöönotossa huomataan, että jokaisessa yksikössä on omat prosessinsa ja luullaan, että pelkällä tietojärjestelmän hankinnalla prosessit saadaan kuntoon automaattisesti.

Seuraavassa hetkessä osapuolet saattavat syyttää toisiaan katteettomista lupauksista, aikataulun ja budjetin venymisestä sekä siitä, että järjestelmää joudutaan kehittämään vastaamaan tarpeita, joista alun alkaenkin oli erilaiset käsitykset.

Edellä kuvattu konflikti voidaan välttää organisaation tarpeiden huolellisella määrittelyllä, mutta sudenkuopat eivät suinkaan jää siihen. Tässä artikkelissa paljastamme järjestelmäostajan 7 tyypillisintä sudenkuoppaa sekä keinot niiden välttämiseksi.

1. Kahden järjestelmän loukku

Kahden järjestelmän loukku on yleisin tilanne, kun uusi järjestelmä on jo hankittu mutta vanhaa on yhä ylläpidettävä asiakastiedon takia. Usean master-järjestelmän hankinta viittaa väistämättä määrittelyvaiheen epäonnistumiseen. Asiakkaiden tavoitetila on se, että heillä on käytössään kaikki asiakastiedot ja tietojärjestelmien ydin. Muut sovellustasot voidaan ottaa usealta eri toimittajalta, mutta ne eivät tuo loukkutilannetta.

Sudenkuoppa voidaan ehkäistä määrittelyvaiheeseen panostamalla sekä integraatiomäärittelyllä. Ole aktiivinen määrittelyvaiheessa, huomioi sidosorganisaatiot ja -järjestelmät, pyydä hankintaan apua ja sitouta järjestelmätoimittajat visioosi.

2. Toimittajaloukku

Toimittajaloukku tarkoittaa tilannetta, jossa vanhasta järjestelmästä ei päästä eroon.

Loukku syntyy useimmiten tilanteessa, jossa asiakkaan kaikki ydinprosessit ovat yhdessä ja samassa järjestelmässä. Yleensä järjestelmä on ollut käytössä useita vuosia ja kirjausmalleja on hiottu vuosien saatossa. Järjestelmän käyttökustannukset ovat nousseet ja jatkokehittäminen on haastavaa. Uusien merkittävien muutosten kehittäminen on liian hidasta ja kallista, järjestelmävaihto taas koetaan liian raskaaksi ja mahdottomaksi.

Asiakas- ja potilastietojärjestelmät ovat pitkäaikaisia hankintoja. Siksi toimittajan kyvykkyys, osaaminen ja sitoutuminen yhteistyöhön on tärkeää.

LUE MYÖS: Mistä tiedän, millaiseen potilastietojärjestelmään kannattaa investoida?

3. Budjetti ylittyy, aikataulu venyy

Palataan jälleen määrittelyjen tärkeyteen ja toimittajan kyvykkyyden varmistamiseen. Budjetti ja aikataulu ylittyvät, koska ennalta määrittämättömät asiat otetaan mukaan alkuperäiseen kokonaisuuteen. Toimitusprojektin kokonaisuuden muutoksenhallinta korostuu.

Hyväksy ainoastaan tärkeimmät muutokset alkuperäiseen projektiin, priorisoi ja vaiheista täydentävät osiot myöhemmäksi. 

LUE MYÖS: 5 vinkkiä IT-järjestelmien käyttöönottoprojekteihin

4. Ei olla osattu ostaa – eli määritellä omia tarpeita

Tarjouspyynnöissä on tapana pyytää kaikki mahdollinen. Organisaation ydinprosessit ja trendituotteet tai -toiminnot saattavat olla samalla asiakasprioriteetilla. Asiakkaan liiketoimintojen ja ydinprosessien toimintojen varmistaminen on aina oltava tärkeysjärjestyksessä korkeimmalla. Muut hypetykset huomioidaan vasta tämän jälkeen. Valikoi jo määrittelyvaiheessa ainoastaan ne uusimmat teknologiaratkaisut, jotka organisaatiosi on valmis ottamaan käyttöön. On hyvä huomioida tulevaisuutta, mutta näin et maksa turhasta.

Jos asiakas ei ole osannut ostaa määritellä tarpeitaan, on usein toimittajavalintakin väärä. Asiakas ei saa sitä, mitä oikeasti haluaa, aikataulut muuttuvat ja kustannukset kasvavat. Jälleen palataan määrittelyvaiheen tärkeyteen, johon panostamalla säästetään myöhemmän vaiheen merkittäviä kustannuksia.

LUE MYÖS: Terveydenhuollon asiakastietojärjestelmän tarpeiden määrittely - 8 ohjenuoraa

5. Vaatimuksia on tulkittu eri tavoin

Vaatimuksia ja määrittelyjä tulkitaan aina eri tavoin. Asiakkaan ongelmiin ja tarpeisiin on toimittajilla useita eri ratkaisuja, joista todennäköisesti yksikään ei ole samanlainen toisen kanssa.

Tarjottu ratkaisu voi tarjota lisäarvoa asiakkaalle tai pahimmassa tapauksessa aiheuttaa edelleen ongelmia. Yhteisymmärrys asiakkaan ja toimittajan välillä on varmistettava alusta alkaen.

6. Toimittaja ei salli muiden sovellusten integroimista järjestelmäänsä

Tämä on mahdollinen toimittajaloukkuriski ja aiheuttaa asiakkaan omaan liiketoimintaan haittaa joko välittömästi tai välillisesti, kun asiakas ei kykene muuntautumaan tai kehittämään omaa toimintaansa. Asiakkaan kannalta haastavin asia on se, että tietojärjestelmät rajaavat oman liiketoiminnan kehittämistä. Liiketoiminnan ydinprosessit on varmistettava niin, että asiakas voi valita parhaimmat tietojärjestelmäratkaisut, jotka keskustelevat keskenään tai tarjoavat suoraan laajennusmahdollisuuden ydinjärjestelmään.

Siksi integrointimahdollisuus on aina syytä selvittää viimeistään tarjouspyyntövaiheessa.

7. Vanhan järjestelmän tietojen pysyvää arkistointia ei ole mietitty

Tähän sudenkuoppaan on syytä varautua perustamalla vanhan järjestelmän tietojen arkistoinnille tai tietojen siirrolle oma suunnitelma jo hankintaprosessin alkuvaiheessa. Sitouta nykyiset ja uudet järjestelmätoimittajasi suunnitelmaasi.

Ole askeleen verran edellä muita – lataamalla uuden järjestelmäostajan tarkistuslistan selätät hankintaprosessin hankaluudet ja varmistat, ettei yksikään haaste jää huomiotta ja sudenkuoppa karttamatta.

Teksti on päivitetty 7.6.2021.