Vaikutin keväällä Helsingin IT-strategiapaperin sisältöön kaupunginhallituksen tietotekniikkajaoston varajäsenenä. Sen uumenissa on mitä vallankumouksellisimpia periaatteita Suomen kuntien IT:n kehittämiseksi ja verovarojen tehokkaasta käyttämisestä hankinnoissa. IT-hankinnoista julkaistaan lähiaikoina liite, mutta odottelun ajaksi jaan pohdintojani muutamista lisenssien tarjoamista keinoista torjua toimittajaloukkuja.
Tarkastelen kolmea tyypillistä ohjelmistohankintatapausta joihin törmää valtionhallinnossa, kunnissa ja suurissa yrityksissä. Jokaisessa tapauksessa on tyypillinen sisäänrakennettu ongelma eli haaste, johon esitän kehittämäni esimerkkiratkaisun.
1. Ostetaan työtä, muttei omisteta lopputulosta
Ongelma: Tyypillinen tilanne suurissa ohjelmistohankinnoissa on asiakkaan tarpeisiin erityiskehitetyn järjestelmän tilaaminen. Paitsi, että usein mokataan antamalla myyjän päättää mitä ostetaan (vaatimusmäärittely), epäonnistutaan myös työn tuloksen omistamisen hallinnassa. Tällaisissa projekteissa työn eli ohjelmistokehityksen lopputuloksen laatu on usein heikkoa sekä ongelmien korjaaminen ja tuotteen jatkokehittäminen vaikeaa. Se ajaa organisaatiot säännöllisin välein ostamaan uusia huonoja järjestelmiä tai käyttämään turhan paljon rahaa hankalasti kehitettävän järjestelmän muutoksiin. Se on organisaation kannalta rahareikä, koska maksetaan virheistä. Samalla huonolla järjestelmällä on vaikeasti mitattava, mutta suuri ulkoiskustannus; se haittaa aktiivisesti organisaation toimintaa sen sijaan, että se tukisi sitä.
Ratkaisu: Kun hankintaa suunnitellaan, kirjataan tarjousehtoihin vaatimus, että ohjelmiston lähdekoodi julkaistaan avoimella lisenssillä. Paitsi, että avoimella lisenssillä julkaiseminen huomattavasti edesauttaa tuotteen jatkokehitettävyyttä ja dokumentoitavuutta, luo se myös toimittajalle mielenkiintoisen laatukannustimen; uskottava ohjelmistotoimittaja ei omissa nimissään kehtaa julkaista roskaa kaikkien nähtäväksi. Ratkaisu voi nostaa tarjouskilpailussa hintoja lievästi, mutta ratkaisu säästää tulevaisuudessa huomattavasti enemmän.
2. Ohjelmisto palveluna vai datan Moolok?
Ongelma: Ohjelmisto palveluna tai SaaS (software-as-a-service) on yleistyvä IT-järjestelmän toimituskonsepti. Sen keskeinen idea puhtaimmillaan on, että asiakkaan ei tarvitse tietää mitään järjestelmän toiminnasta tai toteutuksesta; asiakas vain käyttää sitä ja ”se vain toimii”. Haasteeksi koituu yleensä kuitenkin datan, eli järjestelmään tallennetun tiedon omistaminen. Mitä tiedon siirtäminen toiseen järjestelmään maksaa? Onko se edes mahdollista? Ollaanko toimittajan kanssa naimisissa ikuisesti?
Ratkaisu: Datan siirtämisestä ulos järjestelmästä on sovittava tarkkaan hankintasopimuksessa ja sen muotoilulle on asetettava ehtoja hankkeen vaatimusmäärittelyssä. Asiakkaan datan lunastamiselle on oltava määräaika ja ennustettava hintakatto. Asiaa voi miettiä sopimusteknisesti tiedon lisensoimisesta toimittajalle vastaavalla tavalla kuin asiakas maksaa järjestelmän käyttölisenssistä. Ihannetilanne on asiakkaalle tietenkin se, että datan saa standardimuotoisena milloin vain ulos avoimia rajapintoja pitkin ilman erillistä pyyntöä ja se on tavoite, jota kohti kannattaa yrittää ostovaltaa käyttävinä organisaatioina viedä markkinoita.
3. Panttivankidraama, eli mysteerien laatikko ja salainen loitsukirja
Ongelma: Usein isoissa tietojärjestelmähankinnoissa säilytetään vähintään optio siitä, että asiakkaan tarpeisiin erityiskehitetyn järjestelmän toimittaja myös hoitaa ulkoistetusti sen ylläpidon käyttöönoton jälkeen. Tässä kuitenkin piilee sisäänrakennettu vaara, että toimittaja rakentaa järjestelmästä sellaisen, ettei kukaan muu osaa sitä ylläpitää ja tekee itsestään välttämättömän. Tämä on klassinen toimittajaloukku, joka maksaanee Suomessa vuosittain yhteensä satoja miljoonia jos ei miljardeja euroja. Ratkaisulle on siis huutava pula ihan kestävyysvajeenkin ratkaisussa.
Ratkaisu: Eriytetään ylläpito ja ohjelmiston kehitystyö eri hankinnoiksi, jotka kilpailutetaan erikseen. Jotta järjestelyssä voitetaan mitään, täytyy ohjelmistossa olla avoimet ja hyvin dokumentoidut rajapinnat sekä toiminnot, koska sen täytyy olla minkä tahansa toimittajan ylläpidettävissä kohtuullisella perehtymisellä. Yksinkertainen tie tähän on ohjelmiston julkaisu avoimella lisenssillä, jolloin kuka tahansa voi sen toimintaan perehtyä ja kehittää sille ylläpitokonsepteja, joita tarjota kilpailukykyisin hinnoin. Näin avataan kilpailut myös pienemmille toimijoille, mikä vuorostaan parantaa suurten toimittajien kilpailukäyttäytymistä.
4. Visio: Ketterä hankintaprosessi suunnittelukilpailulla
Ongelma: Mielenkiinto pk-yritysten ja avointen lisenssien hyödyntämisessä julkisen sektorin järjestelmähankinnoissa on kasvava. Yleensä pullonkaulaksi kuitenkin muodostuu se, että ei ole olemassa prosesseja käsitellä pieniä ja/tai nuoria toimittajia, joilla ei ole merkittäviä referenssejä.
Ratkaisuksi tarjoan ylläolevaa kehittämääni ketterämpää hankintamenettelyä, joka toimii erityisen hyvin avoimen lähdekoodin ja pk-yritysten toimintaympäristössä. Hankinta toteutetaan suunnittelukilpailuna, jossa IT-järjestelmän MVP:n (Minimum Viable Product) tai demotapauksen vaatimusmäärittely julkaistaan avoimesti verkossa, ja kuka tahansa voi tarjota siihen rakentamalla esittelytoteutuksen järjestelmästä. Toimittajien annetaan tehdä yhteistyötä ja myös tarjota yhdessä, koska toimittajat voivat olla vahvoja eri osa-alueilla. Kun on edetty hankintaan, täytyy tietenkin järjestelmä julkaista avoimella lisenssillä. Näin kannattaa menetellä, koska jos toimittajalta työ jää lopulta kesken tai tulee yllättäviä kustannuksia, voi järjestelmää kätevästi jatkokehittää. Teoriassa voidaan jopa törmätä tilanteeseen, jossa vapaaehtoisjoukot lähtevät toteuttamaan pieniä järjestelmiä.
—-
Hankintaprosessien luotettavuussuunnittelu edellyttää tietenkin huolellista sopimusjuridista osaamista, projektinhallintakykyä ja hankintaohjausosaamista, mutta nämä toimivat korkeimman tason ratkaisuina, jotka merkittävästi ohjaavat suuntaa, johon hankintaprosessi kehittyy. Suosittelen kokeilemaan näitä ratkaisuja, ja tulen mielelläni kertomaan niistä lisää.
Laastareita ongelmaan joka on huonon osaamisen tulos Suunnittelijan pitäisi ymmärtää suunnittelun tärkeys. Ei ostamispolitiikalla korjata suunnitteluosaamisen olemattomuutta joka on ydinonglema.
Hyvä postaus, kiitos!
Muutenkin julkisella rahalla tehdyt ohjelmistot pitäisi julkaista avoimella lähdekoodin lisenssillä jo siksi että koodi on verorahalla kustannettu. Tällöin sen pitäisi myös olla yleishyödyllistä. Avoin lähdekoodi mahdollistaa innovaation jatkumisen eikä pysähtymisen projektin loppuun.
Tuo putki jossa tehdään suunnittelukilpailu, jaetaan speksi julkisesti verkkoon, ja rakennetaan kuluihin perustuvalla kertabudjetilla kilpailevat demot, ennen hankintaa, toimii muuten hienosti. Open Knowledge Finlandin, Sitran ja Forum Virium Helsinkin järjestämän Datademo-projektin tuloksista voi käydä katsomassa konkreettisesti miten homma toimii http://datademo.fi/.
IT-hankinnatkin ovat toki tärkeitä. Mutta olisi pikapuolin erittäin mielenkiintoista lukea näkemyksiäsi tästä neljännesmiljardin kustantavasta teille päättäjille ehdotetusta hankinnasta: http://www.hs.fi/kaupunki/a1434084263451
Olin hyvin keskeinen henkilö tuon edellisen automaattihankinnan torppaamisessa, kuten voi kaivaa arkistosta https://liljat.fi/tag/siemens/ . Istun HKL:n johtokunnassa, jonka hallintoalaan kuuluu metrot ja raitiovaunut ja myös automaattihanke. Olen aiemmin kirjoittanutkin tuosta problematiikasta. Suhtaudun skeptisesti automatisaatiohankkeen onnistumiseen kustannusraamissa, toisaalta taas kapasiteettiongelma huolettaa. Päätämme huomenna kokouksessa asiasta jotain; siellä istuttaneen iltamyöhään vääntämässä asiasta.
Myös tämän tyyppisillä malleilla on tuotettu runsaasti huonosti toimivia ja suljettuja yksittäisiä ratkaisuja. Sellaisia satunnaisia ja huonosti kokonaisuutta palvelevia yksittäisiä ohjelmistokehityspyrähdyksiä, joihin on sijoitettu yhteisiä rahoja ilman todellista vastinetta.
Avoimet rajapinnat ja laadukas käyttöliittymäsuunnittelu ovat unohtuneet. Lisäksi tietoturvanäkökulma on jäänyt kevyelle tarkastelulle. .
Mikään valmis hankintaprosessi ei toki korvaa hankintaosaamista tai suunnittelua.
Kohdassa ”4. Visio: Ketterä hankintaprosessi suunnittelukilpailulla” on sellainen iso, mainitsematta jäänyt asia, kuin että miten tehdä osallistumisesta kiinnostavaa toimittajille? Esimerkiksi, palkitaanko parhaat suunnittelukilpailun ehdotukset, ja jos, niin miten?
Verrattuna vaikkapa arkkitehtikilpailuihin, ohjelmistotuotannossa on sellainen ongelma, että saadakseen järkevän demon aikaan joutuu usein tekemään suuren osan vaadittavasta työstä valmiiksi.
Varsinkaan pienempien yritysten kannalta ei olisi ollenkaan hyvä asia, mikäli ala muuttuisi uhkapeliksi siitä, että kuka uskaltaa ottaa isoimman taloudellisen riskin projektin saamiseksi, ilman tarkkaa käsitystä sen kannattavuudesta. Pienemmälle yritykselle yksi tai muutama virhearvio tarkoittaisi pian konkurssia.
Suuret riskit olisivat huono asia myös hankkijoiden ja veronmaksajien kannalta, koska mitä suuremmat riskit, sitä suuremmat pitäisi myös palkkioiden olla, jotta hommaan kannattaisi lähteä.
Esimerkki:
Jos halutaan, että 10 firmaa ottavat kukin 100 000 € riskin kilpaillakseen 500 000 € budjetilla tehtävissä olevasta projektista, niin voittajan pitäisi saada enemmän kuin 1 000 000 € ekstraa, jotta riskin otto olisi perusteltavissa. Eli sitten voittajalle pitäisi maksaa sanotaan vaikkapa 1 600 000 €. Toisaalta, jos hankinta pystyttäisiin hoitamaan kokonaan riskeittä toimittajien puolelta, niin maksuksi riittäisi 500 000 €.
Olisivatko demojen hyödyt tässä tapauksessa sen arvoisia, että kustannukset moninkertaistuvat, vai kannattaisiko kyseinen raha käyttää ennemmin johonkin muuhun? Riippuu varmaan paljon tapauksesta, mutta joka tapauksessa demojen aiheuttamien kustannusten sekä osallistujien määrän rajoittamista kannattaa varmasti miettiä etukäteen, jos tuolla mallilla lähtee hankkimaan.
Mikäli niitä ei rajoiteta, niin projektit menevät todennäköisimmin niille toimittajille, joka ovat huonoimpia matematiikassa, mikä taas ei ole toivottavaa. Kertaluonteisessa tavarahankinnassa sellainen voisi vielä toimia, mutta laajempien järjestelmähankintojen kohdalla tavoiteltavin tilanne olisi hyvin toimiva ja kaikkia osapuolia hyödyttävä pitkäjänteinen yhteistyö. Jotta siihen päästään, niin työn pitää olla jatkuvasti kannattavaa toimittajille, ei lottoarvontaa.
Itse näen avoimen lähdekoodin, avointen rajapintojen, avoimen datan, samoin kuin koodin ja datan taloudellisten tekijänoikeuksien siirtämisen edellyttämisen hankinnan ehdoissa paljon tärkeämpänä asiana kuin prosessin, jolla järjestelmä lopulta tuotetaan. Monenlaiset prosessit voivat toimia eri tilanteissa ja joustavuus prosessin suhteen kannattaa säilyttää.
Sen sijaan hankkimalla suljettua ja jättämällä omistajuus toimittajalle saadaan varmasti kallista aikaan, oli prosessi mikä tahansa.
Yksi kilpailuasemaa tasaava järjestely on sellainen, jossa osallistujille annetaan pieni (esim. muutaman tonnin) budjetti, jota saa hyödyntää selvitettyjä (uskottavia) toteutuneita kuluja vastaan. Näin on vissiin jossain meneteltykin.
Pyytäkää nyt ihmeessä lisäselvityksiä metron automatisoinnista. Esimerkiksi millaiset valmiudet uudella M300 sarjan junilla on toimia automaatilla? Muutenkin M300 junien toimivuudesta liikenteessä ei ole vielä mitään näyttöä, eikä kokemusta. M100 junat on nyt peruskorjattuina toimineet loistavasti, eikä kukaan ole pystynyt osoittamaan että niillä ei voitaisi liikennöidä vielä pitkään esim. vuoteen 2027. M200 kalusto on vasta 15 vuoden ikäistä, hyvin toimivaa ja olisi sääli, jos ne nyt kesken elinkaartaan päätettäisiin romuttaa. Lisäksi voisitte kyseenalaistaa onko esitetyt liikennemäärien kasvuennusteet realistisia, vai onko niissä raskasta ylimitoitusta? Automatisoinnin investoinnilla saa paljon muutakin aikaiseksi joukkoliikenteen saralla. Mikäli päädytte puoltamaan automatisointihanketta, niin Siemens tulee olemaan erittäin vahvoilla, mikäli päättää kilpailuun osallistua. Siemensin voitettua kilpailu on tiedossa erittäin kireä toteutus, jossa asiakkaan ääntä ja toiveita tuskin tullaan paljoakaan huomioimaan. Lisäksi kun HKL tulee häviämään Siemensille oikeudessa on järjestelmästä maksettu hinta sietämättömän korkea. Hirvittää tämä meno näin veronmaksajana.