Apotti
Olin muutama vuosi sitten lääkärin vastaanotolla Kivenlahden terveysasemalla Uuden Vuoden aattona. Lääketieteelliset asiat oli aika nopeasti käsitelty mutta sitten tulivat esiin tietojärjestelmät. Ihmettelin miksi minun pitää aina kertoa koko sairashistoriani, eikö niitä ole kirjattu sinne tietojärjestelmään.
Tämä lääkäri kertoi, että hän oli osallistunut lukuisiin suunnittelutapahtumiin, joihin osallistui aina paitsi lääkereitä myös poliitikkoja. Päätöksiä ei juuri syntynyt.
Meillä meni Uuden Vuoden aattona aika pitään kun huomasimme puhuvamme samasta asiasta, kuinka toimiva tietojärjestelmä toteutetaan.
Olen elämäntyöni tehnyt pankkien tietojärjestelmäsuunnittelussa. Voin vakuuttaa, että jos pankeissa projektit olisi toteutettu niin kuin tämä lääkäri kertoi, olisimme vielä shekkimenenetelmän käyttäjiä. Meillä pankeissa projektipäällikkö vastasi siitä, että toimeksiantan hyväksymä projektisuunnitelma toteutuu. Olin usean projektin vetäjänä, joten puhun kokemuksen ”syvällä rintaäänellä”. Tämä sama pätee myös muillakin aloilla ja etenkin rakennusalalla.
Mielestäni tarkein syy siihen etteivät terveudenhoitoalan tietojärjestelmät ole onnistuneet on siinä, että toimeksiantajia on liikaa ja he eivät ole yksimielisiä siitä mikä pitää olla lopputulos. Tavoitetta muutetaan koko ajan. Toinen tärkeä syy on siinä, ettei toimeksiantajilla ole ammattitaitoa valvoa toteutusta ja sen etenemistä.. Alaa tuntematon projektin valvontaryhmä ei onnistu tehtävässään.
Itselläni on samanlaisia kokemuksia käyttäjän / tilaajan puolelta aina 90 -luvun alkupuolelta alkaen aina 2000-luvun puoleen väliin saakka ( sitten jäin eläkkeelle ja väistin erään suuren tietojärjestelmähankkeen käyttööottovaiheen ).
Eräitä tyypillisiä piirteitä näissä tietojärjestelmähankkeissa olen havainnut vuosien kuluessa:
1. Tilaajan ja toimittajan välisen ymmärtämyksen puute.
2. Tilaajalla on ennestään tietynlainen manuaalisten menetelmien toimintamalli, joka halutaan sopeuttaa uuteen tietojärjestelmään.
3. Toimittajalla on ennestään valmiina jollekin toiselle asiakkaalle kehitetty järjestelmä, joka halutaan myydä sellaisenaan ja mahdollisimman pienin muutoksin uudelle asiakkaalle.
4. Tarjouspyynnön teknisen ja toiminnallisen osion laatiminen edellyttää sen tekijältä laajaa ymmärrystä tietojärjestelmistä ja toisaalta omista toimintamalleista. Kaikki pitää osata määrittää pilkun tarkasti.
5. Jos et ole jotain ominaistuutta osannut sisällyttää tarjouspyyntöön ja sopimukseen saat sen kyllä jälkikäteen lisätyönä ja maksat siitä paljon. Monestihan tarjoaja on rakentanut tällaisi lisärahastusmahdollisuuksia jo alkuperäiseen tarjoukseen piiloon.
6. Vaikka sopimuksen tekniset ja toiminnalliset ominaisuudet on määritelty tarkasti, joudutaan hankkeen aikana paljon määrittelemään jos jonkinlaisia ominaisuuksia ja toimintamalleja.
7. Asiakas toimiin järjestelmän testaajana, ei pelkästään toimittaja. Siihen kuluu mittavasti aikaa ja resursseja. Kaikki testauksissa ilmenneet viat, bugit ja ongelmat on kirjattava pilkun tarkasti, jotta ne voidaan reklamoida toimittajlle. Tähän kuluu tilaajalta mittavasti resursseja joka on pois normaaleista tehtävistä.
8. Ennen kuin järjestelmää voidaan kunnolla testata, pitää testaamiseen osalistuva tilaajan henkilöstö koulutta järjestelman käyttöön.
9. Jotta testaukseen osallistuva henkilöstö voidaan kouluttaa järejstelmän käyttöön, tulee järjestelmän toimia edes joten kuten.
10. Laajan ja jopa vähän pienemmänkin järjestelmän käyttöönotto testauksineen ja reklamointeineen kestää noin 3 – 5 vuotta. Ja sitten kun järjestelmä on saatu jotakuinkin käyttöön ja toimivaksi, alkaa käyttölaitteet vanhentua eikä niiden ylläpitoa enää tueta. Sitten voidaankin aloittaa uuden järjestelmän hankinta…
Todettakoon, että en liene ainoa, joka on jo 90 -luvulta alkaen törmännyt em. ilmiöihin. Tuleekin mieleen, että eikö tähän ole vieläkään saatu kehitettyä sellaista hankemallia, että joka kerta ei törmättäisi samoihin ongelmiin ?
Muuten, silloin kun tälläinen mittava muutos joka laajan tietojärjestelmän käyttöön otto on, siinä on mahdollisuus myös karsia vuosikymmenien aikana organisaatioon jämähtäneitä toimintoja, joilla ei ole enää mitään todellista merkitystä, mutta jotka edelleen roikkuvat mukana, ”kun aina ennenkin on näin tehty”.
Ilmoita asiaton viesti
”Tuleekin mieleen, että eikö tähän ole vieläkään saatu kehitettyä sellaista hankemallia, että joka kerta ei törmättäisi samoihin ongelmiin ?”
Yksi olisi vaikka se, että ei kilpailuteta tietojärjestelmiä vaan kehitystiimejä.
Toinen olisi vaikka palastella hanketta pienemmiksi palasiksi ja vaikka eri toimittajilla ettei yritetä vääntää kaikkea yhdeksi massiiviseksi tilaukseksi.
Kolmas olisi se, että tilaaja kirjaa tarjouspyyntonsä liitteiksi sanakirjan mitä eri käsitteillä tarkoitetaan, vaatimusmäärittelyn, mallitulosteet mitä järjestelmästä pitäisi tulla ulos, hahmotelmat eri käyttäjäroolien käyttöliittymänäkymistä missä näkyy kaikki keskeiset toiminnot ja hyväksymistestit.
Nythän se touhu on helposti sitä, että tilaajat pyrkivät teettämään toimittajalla ilmaistyönä tilaajan toiveiden arvailua. Tilaajan pitäisi itse tietää mitä oikein haluaa tai sitten pitäisi tilaajaorganisaation sisältä löytyä edes se yksi kaveri joka osaa tilata.
Mitä tulee bugeihin niin saahan ne hoidettua toimittajan puolestakin käytännössä kokonaan pois. Ongelma vaan löytyy taas siitä, että jos tilaaja ei tiedä mitä haluaa ja on rakennettu jotain niin testauksessa voi olla sitä, testataan sitä ”onko tämä nyt sitä mitä piti olla” tai ”toimiiko sillä tavalla kuin ajattelitte sen toimivan”.
Koodin tekeminen heti suoraan täydelliseksi on kuitenkin kalliimpaa, että pitäisi tietää, että vaatimukset ei muutu.
Ilmoita asiaton viesti
”Ihmettelin miksi minun pitää aina kertoa koko sairashistoriani, eikö niitä ole kirjattu sinne tietojärjestelmään.”
Tässä tainnut olla sellaista, että suunnilleen joka ikinen kunta, sairaanhoitopiiri ja yksityinen terveydenhuoltopalvelujen tuottaja on rakentanut omat järjestelmänsä.
Sitten niiden ei tietenkään tarvitse olla keskenään yhteensopivia, että jos muuttaa eri paikkakunnalle tai hoitaa yksityisellä tai mitä tahansa muuta vastaavaa niin tiedot puuttuvat ja niiden toimittaminen eri paikkaan on vähän jännää sitten.
Eipä muuten ole vaikka Nordealla sitä dataa mitä OP asiakkailtaan kerää mutta tietojen siirtymisen puute ilmenee siellä eri tavalla. Esimerkiksi siinä kuinka helposti irtoaa luottoa. Rahat kyllä sitten siirtyvät pankkien välillä.
Virhe on siis tehty silloin kymmeniä vuosia sitten kun alettu siirtymään papereista sähköisiin järjestelmiin kun valtakunnasta puuttunut jonkinlainen tietojärjestelmäministeri. Tuota vahinkoa toki on sitten korjattu sen jälkeen vähitellen.
Ilmoita asiaton viesti
Olen ihmetellyt, että kun mielestäni Kelan kantarekisteriin on jo vuosikausia kerätty tiedot ihmisten lääkärissä ja tutkimuksissa käynneistä sekä resepteistä ja sitä tietä lääkkeiden käytöstä, niin miKsei tätä koko maankattavaa järjestelmää ole kehitetty kuntien tarvitsemaan suuntaan, vaan on ruvettu kehittämään kuntakohtaisia tietojärjestelmiä.
Kelan järjestelmä on mielestäni toiminut hyvin myös meidän tavallisten kansalaisten mielestä. Eikä mielestäni apteekeilla eikä yksityisillä eikä myöskään julkisilla terveysasemilla ole esiintynyt näkyvää tyytymättömyyttä.
Tuntuu mielettömältä terveyshenkilökunnan ajan tuhlaukselta kirjata samoja terveyden hoidon tapahtumia sekä Apottiin että Kantaan.
Ilmoita asiaton viesti
Ei Kantaan kirjata mitään, osa tiedoista menee sinne automaattisesti, osaa (esim. lääkärinlausuntoja) ei sinne voi kirjata.
Julkisen puolen järjestelmät (käytän kahta eri järjestelmää) eivät koskaan toimi kunnolla, aina on bugeja ja häiriöitä. Terveystalossakin on häiriöitä, mutta paljon harvemmin. Sosialismihan ei voi koskaan toimia kunnolla?
Tiedon Life Care -järjestelmästä lääkärit käyttävät nimitystä Nightmare. Paremmin se toki toimii nyt, kuin pari vuotta sitten. Silloin se määräsi itse lääkkeitä lääkäriltä kysymättä, reseptissä saattoi lukea mitä tahansa.
Ilmoita asiaton viesti
En tiedä voiko ihan asiakkaalta vaatia, että sen pitäisi ymmärtää softapuolen asioista jotain. Hyvin usein näin ei ole ja se on joissain tapauksissa hyväkin asia, jos softatalo vain osaa hommansa.
Siis vaikka rahallinen vastuu toki on aina ostajalla, niin ennemminkin syyttäisin ongelmien tapahtumisesta pääasiassa järjestelmän tekijää, joka ei ole osannut kartottaa tarpeita oikein.
Hyvin usein noissa projekteissa kun kuunnellaan asiakkaan puolelta vain kontaktihenkilöitä, jotka ovat pomoja yms. Eli ei kuunnella ollenkaan loppukäyttäjiä ja kartoiteta heidän avulla käyttötapauksia.
Vähän sama kuin Formula 1 tallin omistajan kanssa neuvoteltaisiin, että mitä ja minkälaisia uusia teknisiä ratkaisuja F1-autoon asennettaisiin kuuntelematta ollenkaan itse kuskia ja tallin mekaanikkoja.
Ilmoita asiaton viesti
”En tiedä voiko ihan asiakkaalta vaatia, että sen pitäisi ymmärtää softapuolen asioista jotain.”
Ei sen tarvitse, mutta asiakkaan pitäisi itse tietää mitä oikein haluaa.
Vaatimusmäärittely ja hyväksymistestaus ovat asioita jotka eivät liity pelkästään softaan. Puolustusvoimat voi vaikka tilata panssarivaunun ja vaatimusmäärittelyyn voidaan kirjata, että pitää painaa alle 50 tonnia ja kulkea 60km/h. Hyväksymistestissa sitten vaikka punnitaan koko vekotin ja mitataan nopeus, noin esimerkkinä.
Softalla tuo menee samalla tavalla. On vaikka käyttäjäroolit, kerrotaan kuka saa nähdä mitäkin tietoa, miten tunnistaudutaan järjestelmään ja hyväksymistesteissä sitten ”kun käyttäjä painaa napista ”jee” niin vastaanottajalle tulee tiedosto ”pöö”.
”Eli ei kuunnella ollenkaan loppukäyttäjiä ja kartoiteta heidän avulla käyttötapauksia.”
Niin eikös tämä nyt ole sen tilaajaorganisaation asia tietää mitä haluavat?
Kyllä sekin toimii, että kartoitus on yksi kilpailutettava hanke ja sen voi tehdä eri organisaatio kuin se kuka toteuttaa, jos tilaaja ei itse tiedä mitä haluaa.
Ilmoita asiaton viesti
”Hyvin usein noissa projekteissa kun kuunnellaan asiakkaan puolelta vain kontaktihenkilöitä, jotka ovat pomoja yms. Eli ei kuunnella ollenkaan loppukäyttäjiä ja kartoiteta heidän avulla käyttötapauksia.”
Tuonkin ilmiön tunnistan niin omista kokemuksistani kuin mitä olen muilta aloilta kuullut. Tuossa ilmiössä lienee yksi vaikuttaja se, että jos toimittaja kiertää ja paneutuu todella syvällisesti koko siihen ympäristöön, jossa loppukäyttäjät toimivat, siinä kuluu kirjattavia työtunteja mittavasti. Se nostaa toimittajan kuluja.
Toisaalta itselläni on myös kokemuksia projekteista, jossa toimittaja oli osannut hinnoittelussaan ottaa huomioon toimitusvaiheessa syntyviä ongelmia. Sellaisessa projektissa oli mukava olla, kun joka pikkuviasta ei tarvinnut alkaa vääntämään kättä ensimmäiseksi siitä, ”kuuluuko tämän ongelman ( tai ns. ominaisuuden) korjaaminen toimitukseen vai ei ja onko se laskutettava lisätyö vai ei”.
Näille em. projekteille oli tyypillistä se, että niissä sekä tilaaja että toimittaja olivat yhteistyössä kehittelemässä lopputuotetta. Tilaaja kertoi sekä kuvasi ilmiön ja toimittaja muutti sen algoritmeiksi ja loi järjestelmälle mm. toimivan käyttöliittymän. No menihän niissä kokouksissa aika monta kuppia kahvia.
Ilmoita asiaton viesti
”Toisaalta itselläni on myös kokemuksia projekteista, jossa toimittaja oli osannut hinnoittelussaan ottaa huomioon toimitusvaiheessa syntyviä ongelmia. Sellaisessa projektissa oli mukava olla, kun joka pikkuviasta ei tarvinnut alkaa vääntämään kättä ensimmäiseksi siitä, ”kuuluuko tämän ongelman ( tai ns. ominaisuuden) korjaaminen toimitukseen vai ei ja onko se laskutettava lisätyö vai ei”.”
Jos tuohon jotain jotain käytäntöä pitäisi hakea niin minun mielestä toimittajan asia on hoitaa kaikki sivuvaikutuksista johtuneet häiriöt.
Mutta jos ei ole varsinaisesti mitään häiriötä mutta toimitus ei ole jostain syystä hyväksyttävä, vaikka hyväksymistestit meneekin läpi. Niin silloinhan kyse on siitä, että tarvitaan uusi hyväksymistesti ja muutostöitä.
Siinä panssarivaunuvertauksessa, jos on tilattu <50 tonnin vaunua mutta jätetty mainitsematta, että siinä pitäisi olla painavempi 120mm tykki, eikä 105mm tykki käy mikä alun perin oli ok niin tuollaiset muutokset hyväksymiskelpoisuuteen pitäisi mennä tilaajalle.
Olisi sitten noin niinkuin periaatetasolla selkeä, että "ohjelma on valmis kun hyväksymistestit menee läpi".
Ilmoita asiaton viesti
Vähän laajemmin kuntatason organisaatioiden tietojärjestelmistä:
Ihmettelen räätälöinnin tarvetta, kun kunnat ovat toiminoiltaan kohtuullisen samanlaisia. Jos olisi vähän väljä ”valmispuku”, niin sehän sopisi kaikille? Vertaan siihen, ettei tekstinkäsittelyynkään räätälöidä joka kunnalle omaa järjestlemää, vaan ne kaikki käyttävät valmisohjelmistoa.
Räätälöity järjestelmä on sitten samalla tavalla hinnakkaampi kuin räätälöity pukukin. Ja tietojärjestelmiin on kaadettu rahaa aika lailla, samalla kun kunnista iso osa on kärvistellyt rahapulassa.
Ilmoita asiaton viesti
Olen nähnyt Apotin käyttöliittymän ihan elävänä ja myös kuullut sitä käyttäneiden ammattilaisten ongelmista.
Apotti on kuin Windows käyttöjärjestelmä. Siinä on aivan liikaa välilehtiä ja pikkuikkunoita, joihin sisältämiin ominaisuuksiin perehtyminen vie aikaa aivan tolkuttomasti ja sitähän ei terveydenhuollon ammattilaisilla juurikaan ole. Jokainen uuden ohjelmiston opiskeluun käytetty tunti on pois asiakkailta.
Apotin suurin ongelma on se, että se ei ole käyttäjäystävällinen. Se toimii, kyllä, kunhan käyttäjä ensin oppii tietämään, mitä mistäkin löytyy ja mitä tulee merkitä mihinkin.
Poliisi tulee kompastumaan samaan ongelmaan. Markku Lehto kiteyttikin jo poliisin uuden tietojärjestelmän suurimman ongelman, eli Lehdon listassa kohta kolme. Toimittajalla on ennestään valmiina jollekin toiselle asiakkaalle kehitetty järjestelmä, joka halutaan myydä sellaisenaan ja mahdollisimman pienin muutoksin uudelle asiakkaalle.
Tämä ei toiminut alkuunkaan ja poliisi peruutti jo hyvin pitkälle viedyn tietojärjestelmähankkeen, joka aloitettiin uudelleen. En käsitä, miksi alustaksi ylipäätään hankittiin varastokirjanpitojärjestelmän pohja? Ilmeisesti kustannussyistä.
Apotti maksoi yhteiskunnalle satoja miljoonia. Virossa sama toteutettiin muutamalla kymmenellä miljoonalla. Poliisi on hukkaamassa valtion varoja kymmeniä miljoonia ja prosessi on jo vuosikausia myöhässä.
Hätäkeskuksen Erica-järjestelmän ongelmista ei opittu mitään ja aina vain kiivetään perse edellä puuhun.
Oppia tulisi hakea pelin kehittäjien maailmasta insinöörien sijaan. Veikkaisin, että Supercell kehittäisi paljon toimivamman järjestelmän kuin mihin Tieto tai mikään muu kehittäjä kykenisi.
Jo viisivuotias pystyy pelaamaan melkein mitä tahansa peliä, mutta edes aikuinen ei kykene sisäistämään Apotin kaltaista mammuttia moneen kuukauteen, ellei sitä joudu käyttämään kokoaikaisesti. Apotin ja monen muun tietojärjestelmän ongelmana on myös se, etteivät edes niiden kouluttajat tunne järjestelmien kaikkia ominaisuuksia kokonaisuudessaan ja ongelmia he eivät tuo edes esille.
Ilmoita asiaton viesti
”Toimittajalla on ennestään valmiina jollekin toiselle asiakkaalle kehitetty järjestelmä, joka halutaan myydä sellaisenaan ja mahdollisimman pienin muutoksin uudelle asiakkaalle. ”
”En käsitä, miksi alustaksi ylipäätään hankittiin varastokirjanpitojärjestelmän pohja? Ilmeisesti kustannussyistä.”
Voihan se olla toimittajan kyvyttömyyttä myös.
Minusta jonkun vanhan pohjan kierrättäminen haiskahtaa hyvin pahasti. IT-alalla teknologia kehittynyt sellaista vauhtia, että noin kuudessa vuodessa saadaan samat asiat tehtyä paljon paremmin. Kaksitoista vuotta sitten on sellainen aikajänne, että vanhassa ei ole mitään kierrätettävää.
Näin siis kun tekee tietojärjestelmiä käyttämällä nykyaikaisinta tekniikkaa mitä löytyy. Jos tekee vanhanaikaisesti niin järjestelmä homehtuu ennen aikojaan.
Tietysti tuosta pääsee siihen, että niitä kannattaa myös ylläpitää, että kestävät aikaa.
Ilmoita asiaton viesti
”Oppia tulisi hakea pelin kehittäjien maailmasta insinöörien sijaan.”
Tuossa on ideaa.
Itse olen koukuttunut pelaamaan netissä eräitä globaaleja ( pelaajat ovat ympäri maailmaa ) sotapelejä . Täytyy ihailla kuinka käyttäjäystävällisiä ja todenmukaisia ( entisen alan ammattilaisen silmin ) ne ovat niin audio-visuaaliselta toteutukseltaan kuin mm. sotatekniseltä että taktiselta toteutukseltaan. Myös ”tulosten ja kokemushistorian” kirjaaminen tapahtuu automaattisesti.
Myös käyttöliittymän käytön ja pelaamisen oppiminen ei näissä peleissä vienyt kuin muutaman tunnin aikaa.
Ilmoita asiaton viesti
En usko, että pelikehittäjät ovat sen parempia tekemään jotain backendiä.
Sen sijaan pelejä kehitettäessä voi olla mukana joku joka ymmärtää suunnitella käyttöliittymää.
Kun on kyse jostain lomakkeista, napeista ja valikoista niin näihin nyt ollut olemassa 80-luvulta saakka harmonisointia ja ohjeistusta, että ne saa toimimaan yhdenmukaisesti ja helpoksi käyttäjälle kunhan näitä nyt vaan maltetaan noudattaa. Ohjeistukset, käyttöliittymäharmonisoinnit ja UI frameworkit ratkovat helpoissa tapauksissa 95% käyttöliittymiin liittyvistä asioista.
Ilmoita asiaton viesti
Ei toimeksiantajia ollut Apotissa liikaa.
Päätöksentekijöillä oli käytössään konsultteja, jotka ohittivat käyttäjien sekä maksajien toiveet.
Avoimen koodin pohjalle oltaisiinvoitu tehdä nopeammin korjattava järjestelmä. Lisäksi koodaajien olisi ollut hyvä olla suoraan maksajien palkkalistoilla, olivat he missä maassa tahansa. Nyt maksetaan liikaa jokaisesta muutoksesta ja hitaus on myös ongelma.
Ilmoita asiaton viesti
Eräs olennainen seikka, jota poliitikot ja päättäjät eivät käsitä, on, ettei tietojärjestelmiä pitäisi kehittää monimutkaisuuden mahdollistamiseen vaan käyttäjätason toimintojen yksinkertaistamiseen. Eräs se onnistumisen edellytyksistä olisi rakenteiden ja toimintojen pelkistäminen niin pitkälle kuin mahdollista ennen kuin tietojärjestelmiä aletaan rakentaa. Tämä pitäisi tehdä valtakunnallisella tasolla.
Ilmoita asiaton viesti
Näitä isoja projekteja nähneenä on tullut selväksi, ettei hyvää järjestelmää luoda, jolleivat sekä tilaajan ja toimittajien avainhenkilöt tunne toimintaa, johon järjestelmä luodaan.
Lisäksi ict -osaajia on oltava kaikissa näissä organisaatioissa. Lääkäreiden tai hoitajien käyttö projektissa on turhaa, jollei näillä ole tietotekniikan perusteiden tuntemusta. Yhtä hölmöä on antaa järjestelmän arkkitehtuurin, systeemien ja integraation suunnittelun johto henkilöille, joilla ei omaa työkokemusta kohteen toiminnasta.
Erikseen on mainittava, että sutta tulee, jos kehitystyö vie vuosia.
Ilmoita asiaton viesti
Suomessa on kahdenlaisia tietojärjestelmien käyttöliittymien kehittäjiä.
Lahjakkaat toimivat kehittämässä pelejä. Lahjattomat kehittävät terveydenhuollon tietojärjestelmiä. Siksi tulokset muistuttavat lähinnä esterataa.
Jutussa jostakin tietotekniikan opinahjosta muistan lukeneeni tittelistä nimeltä Käytettävyyden professori.
Missähän sellaiset ovat piileskelleet, kun Suomeen on kehitetty terveydenhuollon tietotekniikkaa?
Ilmoita asiaton viesti