Lääkärit ohjelmistoja ostamassa

Otso nosti hyvin esiin IT-ammattilaisten puutteen Apotti-hankkeessa, mikä riskeeraa hankittavan ohjelmiston laadun. Ohjelmistojen ostamisessa tarvitaan myös ostamisen eli rahan ammattilaisia. Heitäkään ei Apotin hanketoimistossa tai ohjausryhmässä näytä olevan, joten tuleva todennäköinen epäonnistuminen kaupallisissa neuvotteluissa tuntunee myös veronmaksajien kukkarossa nykyistä arviota vahvemmin.

Apotin arvion mukaan laadukas ja toimiva ohjelmisto säästäisi toiminnan tehostumisen kautta sosiaali- ja terveyssektorin kuluja 330 miljoonaa euroa. Hanketoimiston hankintaosaamisen puute kostautuu laaduttomana ja heikosti toimivana järjestelmänä, joka säästöjen sijaan vain aiheuttaa lisää kuluja.

Sosiaali- ja terveyssektori on tärkein kaupunkilaisten hyvinvointiin vaikuttavan kunnan palvelu. Meillä ei ole varaa ohjata sitä heikosti toimivilla tietojärjestelmillä.

Alla kuvaan valitun mallin ja mahdollisia vaihtoehtoisia hankintamalleja pääpiirteissään, yleistäen ja yksinkertaistaen paljon tuodakseni esiin nykytilan riskejä ja vaihtoehtoja.

A) Ostaminen monoliittisesti (tällä hetkellä valittu malli)
Kuvaukset tarpeista ja prosesseista ovat heikot. Hankkeessa mukana olevien sote-asiantuntijoiden tulisikin tehdä enemmän määrittelytyötä (esim. 6kk – 1 v.) ennenkuin niiden pohjalta uskaltaa monoliittiohjelmistoa lähteä hankkimaan. Nyt Hankeilmoitus ja kuvaukset ovat sillä tasolla, että epäonnistuminen on todennäköistä eli kustannukset eivät pidä, ohjelmisto ei toimi tai ohjelmisto ei toimi siten kuin sen tarvitaan toimivan.

Pahimmillaan budjetti ylittyy pahasti eikä ohjelmisto toimi tarpeeksi hyvin tai oikein, mutta sitä ei voi palauttaa. Softan ostamista ei voi verrata minkään fyysisen kohteen, kuten talon tai sillan tai auton, ostamiseen. Ohjelmiston taitamaton ostaja päätyy periaatteessa toimivan, mutta käytännössä erittäin huonosti toimivan tuotteen käyttäjäksi ilman todellista reklamointimahdollisuutta ja saa lisäksi maksaa jokaisesta haluamastaan korjauksesta tai parannuksesta, jos niitä ylipäätään on mahdollista tehdä.

B) Ostaminen / tuottaminen osissa
Riskittömämpi kuin monoliittinen, mutta kuvauksien ja suunnittelun pitäisi olla samoin merkittävästi paremmalla tasolla, ainakin ensimmäisenä aloitettavista osista ja kokonaisarkkitehtuurista. Mutta näiden tekeminen on paljon pienitöisempää kuin yllä mainittujen prosessien.

C) Ostaminen itse tehtynä iteratiivisen kehitysmallin mukaan
Riskittömämpi kuin monoliittinen ja tällöin prosessit voidaan kehittää ohjelmaa kehitettäessä. Tilaajalla on hyvä hallinta kustannuksista ja siitä, mitä ohjelmiston tulee tehdä nyt, ja mitä uutta tai tarkempaa siihen olemme keksineet olennaiseksi seuraavien kehitystyövuosien aikana. Avasin tätä mallia hieman enemmän taannoisessa yleisluontoisessa postauksessani.

Perusedellytyksenä jokaisessa mallissa onnistumiselle on kuitenkin se, että hanke (sekä kaupunki että HUS) osaavat ostaa ja hankkia ohjelmistoja. Osaaminen on nyt hyvin heikkoa, ja päättäjien tulisikin varmistua riittävästä osaamisesta hyvissä ajoin ennen hankeilmoituksen (tarjouspyyntö) kirjoitusta.

Eli, perusosaaminen ensin kuntoon ja sitten hankeilmoitus uusiksi, oli valittu malli mikä hyvänsä.

Nykytilanne Apotissa on pelottava. Ohjelmistojen ostamisen osaaminen puuttuu, veronmaksajien piikki on poliitikkojen toimesta avattu, sote-sektori hukkaa jo nyt resursseja tehottomiin nykyisiin järjestelmiin, hankintalaki pakko-ohjaa huonoon valintaan politrukin lailla ja koko hankkeen johdossa on kokoelma omnipotentteja ja ylimielisiä lääkäreitä.

Vastaa

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