Artikkelisarja: Kuntauudistus – avoin tie parempiin palveluihin
Kirjoittajat: Martin von Willebrand ja Outi Jousi
Kuntien palveluita ohjataan ja tehostetaan tietojärjestelmillä. Kuntauudistuksesta seuraa myös tietojärjestelmien uudistaminen, mikä mahdollistaa palveluiden parantamisen. Kuntauudistus voi tarkoittaa kuntien kasvavaa yhteistyötä tai kuntien yhdistämistä: joka tapauksessa siitä seuraa tietojärjestelmien uudistamistarpeita, kun eri tietojärjestelmillä tuotettuja palveluita tuleekin jatkossa tuottaa yhdellä tietojärjestelmällä tai kun tietyn palveluprosessin pitää ulottua tietojärjestelmästä toiseen.
Kuntauudistusten myötä on tulossa tietojärjestelmien hankintoja: näitä ovat ainakin tietojärjestelmien liittämisprojektit, laajentamisprojektit – olemassa oleva tietojärjestelmä laajennetaan kattamaan isompi alue – ja kokonaan uudet ERP-projektit.
Tietojärjestelmien hankkiminen ei ole yksinkertaista, eikä helppoa. Sen lisäksi, että kuntien tulee osata tietojärjestelmien uudistaminen toiminnan uudistuessa, tulee myös noudattaa hankintalakia. Hankintalakia on kritisoitu huonosta soveltuvuudesta vaikeisiin hankintoihin.
Tässä artikkelissa katsotaan vaativien tietojärjestelmien, toiminnanohjausjärjestelmien (mm. ERP-järjestelmien) hankintaa hankintalain soveltamisen näkökulmasta. Miten hankintalakia tulee soveltaa vai onko hankintalaki itse ongelma tietojärjestelmiä hankittaessa?
Onnistunut hankinta ja hankinnan toiminnalliset vaiheet
Jotta voidaan tavoitella hankinnan onnistumista, tulee aikaisessa vaiheessa määritellä, milloin hankinta on onnistunut. Hankinnassa pitäisikin pystyä hahmottamaan seuraavat osat:
- Tarvemääritys: projekti alkaa alustavalla tarpeen määrittelyllä. Vaiheessa tulee keskittyä määrittelemään omaa toiminnallista tarvetta, eikä teknologista ratkaisua. Tässä vaiheessa otetaan myös kantaa alustavaan aikataulutarpeeseen sekä raamitetaan kustannuksia (omat ja ulkopuoliset). Tässä yhteydessä on myös mietittävä, milloin hankinta on onnistunut.
- Oma pesä kuntoon: Tarvemääritys tarkentuu, kun sitä tekemään kytketään oikeat ihmiset ja varmistetaan johdon tuki sekä tarvittava poliittinen tuki. Tietohallinto tai hankintayksikkö ei voi tehdä tietojärjestelmää koskevaa hankintaa yksin, vaan palvelua käytännössä tuottavat on kytkettävä mukaan. Tämä myös edesauttaa järjestelmän käyttöönottoa.
- Konsultoiva myynti ja tekninen vuoropuhelu: kun tarvemääritys on tehty ja oikeat henkilöt kytketty, tulee aloittaa vuoropuhelu mahdollisten toimittajien kanssa. Tämä on oikea aika tutkia, mitä ratkaisuvaihtoehtoja hankintayksikön tarpeeseen on hankittavissa. Tässä vaiheessa pitää myös selvittää toimittajien käyttämät, tyypilliset hinnoittelurakenteet ja vaihtoehdot, vaikkakin julkisissa hankinnoissa hinnoittelurakenteesta päättää hankintayksikkö tarjouspyynnössään.
- Tarjouspyynnön valmistelu ja tarjouspyyntö: Kun tarve on tiedossa ja markkinoiden tilanne on kartoitettu tarvetta vasten, on aika valmistella tarjouspyyntö. Tarjouspyyntö tulisi tehdä sellaiseksi, että useampi toimittaja ja kilpaileva ratkaisu ja teknologia on mahdollinen. Tarjouspyyntö ja sitä edeltävä menettely voi olla epäonnistunut, mikäli vain yhtä ohjelmistoteknologiaa tarjotaan tai toimittajajoukko on suppea. Tuntemus markkinoista ja hinnoittelukäytännöistä auttaa tekemään sellaisen tarjouspyynnön, jolla saadaan mahdollisimman yhteismitallisia tarjouksia. On tärkeää varmistaa, että toimittajat voivat tehdä tarjouksen (eikä tarjouspyynnössä pyydetä esim. teknologiaa tai sopimusehtoa, joka on jollekin potentiaaliselle tarjoajalle täysin mahdoton ja samalla hankintayksikölle vain vähämerkityksellinen) ja tämän varmistamiseksi hankintayksikkö voi lähettää tarjouspyyntöluonnoksensa toimittajien kommentoitavaksi ennen tarjouspyynnön julkaisua (osana ns. teknistä vuoropuhelua). Julkisissa hankinnoissa tulee keskittyä myös vertailukriteerien muodostamiseen (laatu ja hinta).
- Tarjoajien soveltuvuuden tarkistaminen: hankintayksikön tulee varmistaa, että tarjoajayritykset täyttävät niille asetetut kriteerit. Käytännön elämässä tätä vaihetta kutsutaan yleisesti kelpoisuusarvioinniksi. Hankintalaissa on lueteltu ne seikat, joita toimittajilta voidaan edellyttää. Vasta tämän vaiheen jälkeen on sallittua arvioida varsinaisia tarjouksia. Näitä vaiheita ei tule sotkea keskenään, joten hankintayksikön tulee olla varovainen, ettei se käytä samaa seikkaa sekä soveltuvuus- että vertailukriteerinä.
- Tarjousvertailu ja päätös: mikäli hankinta on hyvin valmisteltu, on tarjousvertailun tekeminen suoraviivaista, koska tarjouspyynnön tulee sisältää kaikki tarvittava pisteytykseen liittyvä tieto. Käytännössä joudutaan kuitenkin usein tekemään rajanvetoa ja mahdollisesti pyytämään täydennyksiä tarjoukseen/tarjouksiin. Hankintayksikön on hyvä muistaa, että hintaa koskevaa seikkaa ei voi täydennyttää. Tarjousvertailun jälkeen toimittajasta ja ratkaisusta tehdään hankintapäätös.
- Sopimus: julkisissa hankinnoissa ei voida neuvotella sopimusehdoista tarjouspyynnön julkaisun jälkeen. Hankintayksikön tulee sisällyttää tarjouspyyntöönsä ainakin ne sopimusehdot, jotka vaikuttavat hintaan ja toimittajan mahdollisuuteen ylipäätään osallistua tarjouskilpailuun. Hankintasopimus julkaistaan osana tarjouspyyntöä ja se sitoo kumpaakin osapuolta. Vaikka hankintayksiköllä onkin laaja valta sopimusluonnoksen kirjoittamisessa, siihen on kuitenkin hyvä pyytää kommentteja teknisen vuoropuhelun kuluessa.
Hankintalain mukaiset hankintamenettelyt
Hankintalaissa on säännelty ne menettelyt, joita noudattaen hankintayksikkö voi hankintansa toteuttaa. Järeitä tietojärjestelmähankintoja tehdään useasti neuvottelumenettelyllä tai kilpailullisella neuvottelumenettelyllä. Näiden menettelyiden käyttö on mahdollista vain silloin, kun hankintalaissa asetetut käyttöedellytykset täyttyvät.
Hankintayksikön on hyvä huomata, että neuvottelumenettelyiden toteuttaminen on varsin työlästä, joten mikäli hankinnan kohde on mahdollista kuvata tarjouspyyntöön jo lähtötilanteessa tai esimerkiksi julkista tietopyyntöä hyödyntämällä, on avoimen menettelyn valinta suositeltavaa neuvottelumenettelyiden sijaan.
Hankintayksikön on mahdollista hankkia markkinoilta lisätietoa tietojärjestelmähankintansa tueksi muutoinkin kuin toteuttamalla hankintansa neuvottelumenettelynä. On mahdollista tehdä tietopyyntö HILMA-hankintailmoituspalvelun kautta tai järjestää tekninen vuoropuhelu kaikkien toimittajakandidaattien kanssa.
Hankintayksikkö voi varsinaista tarjouspyyntöä edeltävässä ennakkoilmoituksessa kertoa miten toimittajat voivat ilmoittautua tekniseen vuoropuheluun ja esimerkiksi varata oman tapaamisaikansa. Käytännössä tekninen vuoropuhelu voidaan toteuttaa esimerkiksi lähettämällä tarjouspyyntöasiakirjoja toimittajille kommentointia varten. Toimittajat on myös mahdollista tavata, mutta hankintayksikön tulee huolehtia kaikkien toimittajakandidaattien tasapuolisesta kohtelusta mm. tiedonsaannin ja aikataulujen suhteen.
Ketterä vaihtoehto
Viime vuosina hankintayksiköt ovat yhä kiihtyvällä tahdilla kiinnostuneet ketterien menetelmien käyttämisestä hankkimansa tietojärjestelmän toteutusprojektissa. Erona vanhaan ns. vesiputousmalliseen menetelmään on se, että ketterää järjestelmää valmistettaessa voidaan jatkuvasti huomioida uusia ideoita ja siten lopputulos voi vastata tarvetta aiempaa paremmin. Vesiputousmallisessa kehityksessä koko tietojärjestelmä suunnitellaan kerralla, eikä valituista ratkaisuista poiketa.
Hankintalain perusoletushan on vastakkainen kuin ketterien menetelmien: kaikki järjestelmään liittyvät ratkaisut pitäisi osata tehdä jo ennen kuin ensimmäistäkään koodiriviä on kirjoitettu. Tälle etukäteen suunnitellulle tietojärjestelmälle kilpailutetaan hinta ja sen jälkeen toimittaja toteuttaa järjestelmän.
Ketterän järjestelmäkehityksen mahdollistaminen julkisissa hankinnoissa edellyttää mm. sitä, että hankintayksikkö ei vertaile lopputuloksen kiinteää hintaa, vaan pikemminkin työn veloitusperustetta (esim. tuntiveloitusta) ja tekijöitä. On tärkeää varmistaa, että saatavat tarjoukset ovat vertailukelpoisia. Kilpailutuksen vertailukriteereihin ja muuhun sisältöön on kiinnitettävä runsaasti huomiota erityisesti tällaisissa kilpailutuksissa.
Hankintayksikön tulee varata riittävästi henkilöresursseja järjestelmän kehitystyöhön, koska järjestelmä kehitetään yhteistyössä toimittajan kanssa, Näin ollen hankintayksikön tulee kyetä nopeisiin ratkaisuihin kehitystyön edetessä.
Hankintalakia koskevia väärinkäsityksiä
Tässä yhteydessä haluamme oikaista tiettyjä usein esiintyviä väärinkäsityksiä hankintalaista:
- Ketterät menetelmät
- Väärinkäsitys: ”Ketteriä menetelmiä ei voida käyttää.”
- Oikeasti: Ketteriä menetelmiä on käytetty menestyksekkäästi muutamissa hankinnoissa, mutta niiden käyttö edellyttää sopimusehtojen ja vertailuperusteiden erityisen huolellista valmistelua, koska aihe on vielä kaikille uusi, myös toimittajakunnalle.
- Hankintakaudet
- Väärinkäsitys: ”On pakko hankkia enintään neljän vuoden sopimuskausia”
- Oikeasti: Hankintalaki ei säätele hankintasopimuksen kaudelle mitään tiettyä ylärajaa, ellei kyseessä ole puitejärjestely (ja nyt emme käsittele puitejärjestelyitä vaan yksittäistä hankintaa). Hankintasopimukset on tehtävä kestoltaan tosiasiallista tarvetta vastaaviksi. Monessa palveluhankinnassa neljä vuotta voi olla järkevä aika, mutta ERP-järjestelmien osalta käyttöönotto ja kehitys voi kestää vuoden tai pidempäänkin, edellyttää palveluprosessien muuttamista hankintayksikössä ja uudistettujen palveluprosessien ja tietojärjestelmän käyttöönoton jälkeen tosiasiallinen käyttöaika on usein yli 5 vuotta. Toisaalta jokaisessa tietojärjestelmähankinnassa tulisi pyrkiä välttämään lukittautumista yhteen toimittajaan ja tehdä toimia sen varmistamiseksi, että toimittaja voidaan tarvittaessa vaihtaa. Eli vaikka tietojärjestelmän käyttöoikeuksien hinnat hankitaan tai sidotaan jopa 10 vuodeksi, tulisi palvelut ja jatkokehitystyöt eriyttää järjestelmän käyttöoikeuksista.
- Avoin lähdekoodi
- Väärinkäsitys: ”Avointa lähdekoodia ei voida hankkia”
- Oikeasti: Hankintayksikkö voi hankkia tietojärjestelmän, johon sille tulee laajat kopiointi-, muuttamis-, ja edelleenjakeluoikeudet. Tällaiset oikeudet vastaavat avoimen lähdekoodin määritelmää. (Hankintayksikkö voisi vaatia myös täysiä tekijänoikeuksia, mutta se ei yleensä ole suositeltavaa.) Sen sijaan hankintayksikön ei tule ilman painavaa syytä rajoittaa toimitettavan järjestelmän lisensiointia esimerkiksi johonkin tiettyyn avoimen lähdekoodin lisenssityyppiin. Lisenssien välisiä yhteensopivuusvaatimuksia voidaan esittää simerkiksi silloin kun halutaan yhdistää hankittava järjestelmä jonkun toisen, avoimesti lisensioidun järjestelmän kanssa. Niin kuin kaikissa muissakin hankinnoissa, tulee varmistaa, ettei suosita ketään yksittäistä toimijaa. Mikäli kyseessä on tilanne, jossa hankintaan työtä jo olemassa olevaan avoimen lähdekoodin järjestelmään, pitää työ luonnollisesti kilpailuttaa.
- Neuvottelumenettely
- Väärinkäsitys: ”Neuvottelumenettely on ainoa mahdollinen hankintamenettely isoissa tietojärjestelmäprojekteissa.”
- Oikeasti: Hankintayksikkö voi käyttää mm. avointa tai rajoitettua menettelyä ja niiden apuna teknistä vuoropuhelua, huolellista markkinakartoitusta ja tietopyyntöjä. Tällä tavoin voi olla mahdollista saavuttaa tavoite neuvottelumenettelyä kevyemmin ja nopeammin. Ylipäätään neuvottelumenettelyä voidaan käyttää vain silloin, kun hankintalaki sen mahdollistaa.
Lopuksi
IT-projektissa voidaan ”mennä helvettiin tai taivaaseen”, mutta hankintalaki ei sitä suoraan ratkaise. Hankintayksikön kannattaa valmistella hankinta hyvin, koska tietojärjestelmän lopputulos on pitkälti kiinni tarjouspyynnön valmistelun laadukkuudesta. Tarjouspyynnön luominen onkin julkisen hankinnan tärkein ja pitkäkestoisin vaihe, johon hankintayksikön tulee panostaa.
Tarjouspyynnön julkaisun jälkeen hankintayksikkö ei voi enää neuvotella valitun toimittajan kanssa. Sen sijaan tarjouspyynnön kirjoittamisessa hankintayksiköllä on laaja valta hyppysissään. Tämä on keskeinen asia ymmärtää neuvottelutilanteen hahmottamiseksi: ennen tarjouspyynnön valmistumista hankintayksiköllä on suuri neuvotteluvalta, sen jälkeen neuvottelukeinoja ei juuri enää ole. Tarjouspyyntöä kirjoitettaessa tulee neuvotteluvoimaa kuitenkin käyttää järkevästi: mikäli tarjouspyyntö laaditaan niin, että siihen ei saada vastauksia, voi hankintayksikön asema hankaloitua esim. aikataulullisesti.
Hankintayksikön kannattaakin huomioida, että sen on mahdollista hankkia muutakin kuin perinteisillä menetelmillä toteutettuja suljetun lähdekoodin järjestelmiä. Lopputulos voi olla parempi, edullisempi ja nopeammin käytettävissä, jos toimittajalle annetaan mahdollisuus hyödyntää halutessaan myös avointa lähdekoodia ja tehdä työnsä ketterästi. Hankintalaki ei siis estä hyvän tietojärjestelmän hankkimista, vaan kulloiseenkin hankintaan kannattaa valita parhaiten sopivat menetelmät.
Yleisiä suosituksia hankinnan onnistumista ajatellen:
- Julkisissa hankinnoissa tarjouspyynnön valmisteluun kuluu yleensä useita kuukausia aikaa. Mammuttiluokan hankinnoissa aikaa voi mennä vuosikin. Viivästyksiin täytyy myös varautua. Määrittele aikataulu- ja budjettiraami aikaisessa vaiheessa.
- Älä määrittele teknologista ratkaisua ennen kuin markkinatarjontaa on aidosti selvitetty. Parasta on jättää teknologiavalinta itse hankintapäätökseen (eli antaa parhaan voittaa, tarjouspyynnössä asetettuja kriteerejä soveltaen), jolloin tavoitteet täyttävät teknologiat ja toimittajat voivat kilpailla loppuun asti.
- Määrittele aikaisessa vaiheessa, koska hankinta on onnistunut ja mitkä ovat hankinnan toiminnalliset tavoitteet. Jos tavoitteita ei ole määritetty kunnolla, eivät omat henkilöt saati toimittajan henkilöt, pysty työskentelemään tavoitteiden saavuttamiseksi. Pyri tekemään riittävän pieniä, mutta lopputuloksia tuottavia projekteja, ja vältä mahdollisuuksien mukaan mammuttiprojekteja. Isot projektit kannattaa yleensä vaiheistaa. Epäonnistumisen riski kasvaa projektin koon ja keston kasvaessa: aikaisessa vaiheessa syntyvät näkyvät tulokset yleensä taas vähentävät epäonnistumisen riskiä ja mahdollistavat projektin ohjaamista. Tarkenna toiminnallisia tavoitteita tarvittaessa ennen tarjouspyynnön julkaisemista, kun markkinatilannetta on teknisen vuoropuhelun tai tietopyyntöjen avulla selvitetty.
- Sitouta oma henkilökunta projektiin, mukaan lukien toimintaa toteuttava henkilökunta, johto, tietohallinto ja hankintaosasto. Organisaatiosta riippuen poliittinen tuki voi olla myös tarpeen. Tarvittaessa hanki markkina-asiantuntemusta ja/tai hankintaosaamista. Muista, että projektin aikana tarvitaan myös henkilökuntasi panosta. Ostajan projektipäällikön valinta on ehkä yksi tärkeimpiä henkilövalintoja: hänen työnsä edellyttää jämäkkää otetta ja on usein vaatimista sekä omilta että toimittajalta.
- Arvioi toimittajan tarjoamia henkilöitä osana laatuvertailua. Tähän voidaan kytkeä myös keskeisien henkilöiden haastatteluita (esim. toimittajien projektipäälliköt). Ketään tarjouskilpailussa mukana olevaa ei saa syrjiä ja erityisesti henkilöiden arvioinnin ja haastatteluiden osalta on tärkeää hyödyntää hankintaosaamista, sillä (tästäkin) asiasta on kehittynyt markkinaoikeuskäytäntöä.
- Työskentele sitä vastaan, että lukittautuisit yhteen toimittajaan tai teknologiaan. Parhaassa asemassa olet, jos syntyvä tieto on tallennettu avoimen standardin mukaisella tavalla , järjestelmän rajapinnat ovat ostajan tuntemia ja avoimia, järjestelmä on modulaarinen, hankkijalla on oikeus ja mahdollisuus kehittää (omasta tai toisen toimittajan toimesta) järjestelmää ja järjestelmän käyttöä on mahdollista laajentaa esim. toiseen kuntaan. Kaikkia näitä ei mitenkään aina voi saavuttaa, mutta vähimmillään tulisi vaatia, että tiedot on tallennettu avoimen standardin mukaisella tavalla ja että järjestelmä on avoimien rajapintojen johdosta yhdistettävissä muihin järjestelmiin. Lopulta lukittautumisen aste ratkaisee sen, kuinka kalliiksi tulee luopua järjestelmästä sen elinkaaren päättyessä ja ottaa käyttöön uusi, toisen teknologian järjestelmä. Yksinkertainen tapa sälyttää toimittajalle vastuu tiedon tallettamisesta avoimessa muodossa on vaatia toimittajalta, että sopimuskauden loppuessa kaikki tieto, siltä osin kuin se ei ole tallennettu avoimessa muodossa, muutetaan toimittajan kustannuksella avoimeen, standardin mukaiseen muotoon.
- Sovi riittävän pitkästä sopimuskaudesta niin, että siihen mahtuu sekä projekti, varsinainen tuotanto että siirtyminen järjestelmästä ja/tai toimittajasta uuteen.
Martin von Willebrand
Martin von Willebrand on asianajaja, osakas ja teknologiaryhmän vetäjä Asianajotoimisto HH Partnersilla sekä hallituksen ja ohjausryhmän jäsen COSS ry:ssä. Hän neuvoo yrityksiä ja organisaatioita lukuisissa teknologian hyödyntämiseen liittyvissä oikeudellisissa kysymyksissä ja hänen asiantuntemustaan alalla suositellaan laajalti (mm. Legal 500, Chambers Europe, Best Lawyers ja useat muut julkaisut). Hänellä on laaja-alaisesti kokemusta sekä tietojärjestelmähankinnoista että avoimen lähdekoodin kysymyksistä, ml. hankinnoista, lisensionnista ja projektien perustamisesta.
Outi Jousi
Outi Jousi on lakimies ja aiemmin toiminut ohjelmistosuunnittelijana. Työkseen hän kilpailuttaa mm. merkittäviä tietojärjestelmähankintoja ja luennoi aiheesta hankintayksiköille.