Kuinka tehdä Apotti avoimella lähdekoodilla

Julkisen ja yksityisen välillä on eroja, joten kunnan tai valtion ei kannata toimia samoilla periaatteilla ohjelmistojen hankinnassa. Julkinen ostaa järjestelmänsä pidempään käyttöön kuin yksityinen ja julkisella on tarve optimoida investointinsa tasaisemmin ja pidemmälle ajanjaksolle. Julkisella on myös tarve toimia avoimesti kansalaisia kohtaan ja kansalaiset ovat samalla sen (pitkälti käyttämätön) voimavara ohjelmistohankinnoissa. Julkista ohjelmistohankintaa ohjaa myös julkisuuslain, hallintolain, henkilötietolain ja substanssilakien antamien reunaehtojen, hyvän hallintotavan ja hyvän tiedonhallintatavan noudattaminen.

Suomalaisten julkisten IT-hankintojen historia on surullisen kallista veronmaksajille – vaikka samaan aikaan julkisen sektorin tehokkuus kärsii monelta osalta kunnollisten järjestelmien puutteesta. Toisaalta Verohallinto on myönteinen esimerkki. Lisäksi Valdassa on ymmärretty luovuttaa kun epäonnistuminen näyttää todennäköiseltä ja hyödynnetty sen sijaan projektin hyviä saavutuksia muissa tiedonohjaushankkeissa.

Espoon kritiikki Apotti-järjestelmästä tuo perusongelman hyvin esiin:

Espoon mukaan asiantuntijalausunnot osoittavat, että Apotti-hankintaan liittyy isoja taloudellisia ja toiminnallisia riskejä. Asiantuntijoiden näkemykset eivät tue Apotin kaltaisen monoliittisen asiakastietojärjestelmän hankintaa esitetyllä tavalla.

Mutta seuraavasta perustelusta olen vain osittain samaa mieltä:

Apotti-hankinnassa mukana olevilla seitsemällä organisaatiolla ei ole yhteistä strategiaa, johtamisjärjestelmää tai palvelujen tuottamisen toimintamallia. Riskinä olisi, että hankittava järjestelmä määräisi liikaa toiminnallisia ratkaisuja. Asiantuntijoiden mukaan  toiminnan muutoksia ei saada aikaan tietojärjestelmän kautta vaan uudistamalla ensin toiminnallisia prosesseja.

eli vaatimus prosessien yhtenäistämisestä ennen yhteistä hankintaa on työläs ja kallis. Laki antaa jo nyt hyvän pohjan yhteisille prosesseille ja rajoittaa virkamiesten liiallista sooloilua.

Lisäksi ongelmien ratkaisuksi tarjottu “modulaarinen” rakenne ei kuitenkaan ole olennaisin onnistumisen edellytys, sillä myös modulaarisesti toteutetut ohjelmat voivat kärsiä ongelmista “hankinnan, käyttöönoton ja toiminnan” suhteen.

Tällaisen yhteishankkeen ohjelmistotuotannolliset riskit ovat mielestäni parhaiten hallittavissa iteraativisella kehitysmallilla, joka pohjautuu täyteen avoimuuteen ja julkisen lähdekoodin käyttöön. Tällöin eri organisaatioilla tarvitsee olla summittainen käsitys ohjelman pääpiirteistä sekä toimiva yhteistyö kehityksen suunnan ohjaamiseksi. Avoin lähdekoodi mahdollistaa myös eroavienkin tarpeiden hallinnan samassa projektissa. Ohjelmiston kehittyminen käytettäväksi demoversioksi tukee yhteisten prosessien kehittämistä ja palvelee samalla palautteen ja lisäohjauksen muodossa ohjelmiston kehitystä.

Kehitystyö olisi avoimessa säiliössä (repository), jotta siihen voisi laaja yleisö kommentein ja koodein osallistua. Softan viimeisin versio pyörisi useina julkisina testiversioina, jolloin tulevat käyttäjät ja ketkä vain kiinnostuneet kansalaiset voivat raportoida virheitä, käytettävyyshuomioita ja kehitysideoita.

Kehitykseen sopivaa tai sopivia yrityksiä voisi hankinnan aluksi kilpailuttaa ensimmäisten vaatimusten tuottamisessa julkisesti toimivaksi demoksi. Samalla tekijöiden taidot ja tavat tulevat paremmin arvioitua kuin kilpailutuspapereita täyttäessä.

Jos hankinnalla tulee budjetti- tai aikataulupaineita voidaan toimittajien määrää fyysisestä sijainnista riippumatta lisätä tai vähentää kunhan sopimukset on laadittu tämä huomioiden.

Samoin hankkeeseen osallistujien määrä voisi vaihdella joustavasti ja uusia partnereita voisi saada eri puolilta maailmaa. Jos partnereiden määrä kasva merkittävästi niin silloin kehitys- ja ennen kaikkea ylläpitokustannukset pienenevät minimaalisiksi. Ylläpitohan on tunnetusti n. 90 % prosenttia järjestelmän kokonaiskustannuksista hankinnan kustannusten ollessa n. 10 %.

Mutta rajoitteitakin toki on. Hyvällä tarkoituksella tehdyt lait ja asetukset julkisista hankinnoista sekä VM:n “ohjaus” eivät vanhakantaisuudessaan kaikilta osiltaan ehkä mahdollista veronmaksajien varojen optimaalista käyttöä. Jos näin on, lakia olisi syytä muuttaa tinkimättä kuitenkaan niissä säädetyistä laatukriteereistä.

Tuntuu kuitenkin siltä, että tämän Apotti-MUMPS-hankkeen kohdalla ollaan jo menty metsään. Paetkoon siitä laivasta ken voi. Pitää selvittää mitä asialle voi vielä tehdä.

One thought on “Kuinka tehdä Apotti avoimella lähdekoodilla

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 )

w

Muodostetaan yhteyttä palveluun %s