Beta

Hankintamallin valinta

 


Pohjat

Ohjeet


Hankintamallin sisältö

Hankintamalli koostuu

  • Hankinnan arvosta (hankinnan kokonaiskustannukset)
  • Hankintamenettelystä (hankintatapa)
  • Ratkaisun toteuttamistavasta ja vaiheistuksesta
  • Järjestämistavasta (ylläpito)
  • Järjestelmän elinkaaren huomioimisesta

Valitse hankintamenettely

Kilpailutus voidaan toteuttaa kolmella eri tavalla

  • Avoin menettely
  • Rajoitettu menettely
  • Neuvottelumenettely

Ennen hankintaa markkinaselvitystä voidaan tukea teknisellä vuoropuhelulla. Jo teknisessä vuoropuhelussa tulee kiinnittää huomiota toimittajien yhdenvertaiseen kohteluun, jottei myöhemmin tarvitse sulkea osallistunutta toimittajaa pois tarjouskilpailusta.

Avoin menettely

 

Avoin_menettely_small.png

 

Avoin menettely toimii hyvin sellaisissa hankinnoissa, joissa hankinnan kohde ja tarjousten vertailuperusteet ovat suhteellisen yksinkertaisia. Tarjousten vertailun helppous ja johdonmukaisuus nousevat tällöin tärkeiksi, sillä hankintayksikkö ei voi avoimessa menettelyssä rajoittaa saapuvien tarjousten määrää.

Hankintayksikkö julkaisee hankinnasta hankintailmoituksen, johon kaikki halukkaat toimittajat voivat tehdä tarjouksen. Hankintailmoituksen julkaisemisen jälkeen hankintayksikkö saa lähettää tarjouspyyntöasiakirjat myös suoraan sellaisille toimittajille, joilta se haluaa tarjouksen.

 

Rajoitettu menettely

 

Rajoitettu_menettely_small.png

 

Rajoitettu menettely soveltuu erityisesti hankintoihin, joissa olisi odotettavissa paljon tarjouksia tai joissa tarjouksen tekeminen tai tarjousten vertailu olisi poikkeuksellisen työlästä.

Hankintayksikkö julkaisee hankinnasta hankintailmoituksen, johon halukkaat toimittajat voivat pyytää saada osallistua. Ainoastaan hankintayksikön valitsemat ehdokkaat voivat tehdä tarjouksen. Käytännössä hankintayksikkö ensin tutkii, mitkä ehdokkaat täyttävät hankintayksikön asettamat ehdokkaan soveltuvuuden vähimmäisvaatimukset. Sitten se asettaa soveltuviksi arvioimansa ehdokkaat paremmuusjärjestykseen ilmoittamiensa objektiivisten ja syrjimättömien perusteiden nojalla. Lopuksi hankintayksikkö valitsee tarjousmenettelyyn edellä asetetussa paremmuusjärjestyksessä hankintailmoituksessa vähintään ilmoittamansa määrän ehdokkaita. Jos hankintayksikkö on ilmoittanut myös valittavien ehdokkaiden enimmäismäärän, ei ehdokkaita saa valita tuota määrää enempää.

 

Neuvottelumenettely

 

Neuvottelumenettely_small.png

 

Neuvottelumenettelyä saa käyttää vain hankintalaissa luetelluissa tilanteissa. Neuvottelumenettelyä käytetään lähinnä vain poikkeuksellisen vaativissa hankinnoissa ja erityistilanteissa. Neuvottelumenettelyn heikkous on sen vaatima aika ja monimutkaisuus.

Hankintayksikkö julkaisee hankinnasta hankintailmoituksen, johon halukkaat toimittajat voivat pyytää saada osallistua. Hankintayksikkö neuvottelee hankintasopimuksen ehdoista valitsemiensa toimittajien kanssa.

 

Valitus- ja odotusaika

 

Hankinnan_lainvoimaisuus_small.png

 

Kaikkiin hankintamenettelyihin liittyy hankintapäätöksen jälkeen joko muutoksenhaku- tai odotusaika, ennen kuin päätös voi tulla lainvoimaiseksi. Luonnollisesti valitukset tai oikaisupyynnöt tarkoittavat aikataulun pitkittymistä, kunnes ne on asianmukaisesti käsitelty. Käsittelyn kesto on tapauskohtaista ja riippuu siitä edellyttääkö tapaus markkinaoikeuden käsittelyä vai riittääkö lautakuntakäsittely. Odotusaika tarkoittaa sitä aikaa, joka hankintapäätöksen jälkeen tulee odottaa, jotta muutoksenhakuaika menee umpeen ja päätös on lainvoimainen.

Muutoksenhaku- ja odotusaika riippuu hankinnan luonteesta. Mikäli odotusaikaa ei noudateta, hankinta-/toimitussopimuksen voi tehdä heti, mutta muutoksenhakuaika on silti voimassa. Helsingin kaupunki voi lisäksi asettaa erillisellä ohjeistuksella tiukempia noudattamisohjeita hankinnan valitus- ja odotusajalle. 

Muita poikkeuksia: Odotusaika on 0 päivää, jos tarjous tehdään ainoan hyväksyttävän tarjouksen kanssa (jos on esimerkiksi saatu vain yksi tarjous tai muut tarjoukset on hylätty). Odotusaika on 0 päivää, jos kyse on dynaamisen hankintajärjestelmän hankinnasta (HankintaL 49§ - Dynaamisella hankintajärjestelmällä tarkoitetaan täysin sähköistä hankintamenettelyä tavanomaisille ja markkinoilla yleisesti saatavilla oleville hankinnoille).

 

Hankinnan määräajat

Hankintalaki ei aseta määräaikoja EU-kynnysarvon alittaville hankinnoille, mutta hankintayksikkö voi asettaa omissa ohjeissaan sellaisia (ks. hankintakäsikirja).

EU-kynnysarvon ylittävät hankinnat sen sijaan sisältävät vähimmäismääräaikoja hankinnan eri vaiheisiin (ks. Hilma-ohje). 

EU-kynnysarvot:

 

Yleisimmät EU-rajan ylittävät määräajat:

Ennakkoilmoitus:

  • kaikille hankintamenettelyille: 35 pv

Avoin menettely:

  • Tarjouksen jättäminen: 15 pv

Rajoitettu- ja neuvottelumenettely:

  • Osallistumishakeuksen jättäminen: 30 pv (nopeutettuna 15 pv)
  • Tarjousaika: 10 pv

Muutoksenhaku / oikaisuvaatimus hankintapäätökseen

  • Hankintapäätöksen jälkeen: 14 pv (ks. ohjeet Helmissä)
  • Puitesopimuksen alaisen EU-kynnysarvon ylittävä: 10 pv

Jälki-ilmoitus:

  • Hankintasopimuksen jälkeen: 30 pv

Jos on epäselvää mitä odotusaikaa tulee noudattaa, oikea menettely kannattaa varmistaa kaupungin hankinta-asiantuntijoilta. Lähtökohtaisesti odotusaikaa on suositeltavaa noudattaa myös siinä tapauksessa, että laki ei sitä erikseen vaadi. Lain mahdollistama odotusajan noudattamatta jättäminen arvioidaan aina tapauskohtaisesti ja siitä tulee keskustella kaupungin hankinta-asiantuntijoiden kanssa.

 

Valitse toteutus- ja järjestämistavat

Toteutus- ja järjestämistavat rajaavat oleellisesti mitä ratkaisuja voidaan asiakkaalle toimittaa. Kilpailutukseen voi olla hankalaa viedä erilaisia toteutus- ja järjestämistapoja yhtäaikaa.

Ratkaisun toteutustapa

Tietojärjestelmä voidaan toteuttaa asiakkaalle neljällä toisistaan poikkeavalla tavalla:

  • Ohjelmisto palveluna (SaaS)
  • Valmisohjelmiston toimittaminen ja konfigurointi
  • Valmisohjelmistosta räätälöinti
  • Itse toteuttaminen - avoimena lähdekoodina

Valmisohjelmiston sovittaminen ja konfigurointi ilman muutoksia voi edellyttää itse toiminnan sopeuttamista valmisratkaisuun. Siksi valmisohjelmiston hankinnassa usein päädytään sen räätälöintiin. Räätälöinti kuitenkin johtaa tavanomaisesti toimittajaloukkuun, hankalaan järjestelmän korvaamiseen tulevaisuudessa ja selvästi kohonneisiin elinkaarikustannuksiin. Turhaa räätälöintiä tulisikin välttää.

Itse toteuttaminen on perusteltua, jos toiminnan sopeuttaminen järjestelmän vaatimuksiin ei onnistu tai tarvittavaa järjestelmää ei löydy sopivana valmisohjelmistona. Oma toteutus edellyttää, että tehtävälle ratkaisulle on osoittaa kehittämisresurssit, tyypillisesti oma ohjelmistonkehitystiimi. Ratkaisun jatkokehittäminen jää itse kehitettäessä tavanomaisesti oman organisaation vastuulle. Lisäksi toteutus tulisi julkaista avoimena lähdekoodina tai vähintäänkin huolehtia siitä, että hankintayksikkö (tai kaupunki) omistaa toteutettavan lähdekoodin. Tilanne, jossa toimittaja tai joku muu taho omistaa lähdekoodin johtaa yleensä ongelmiin ja tiukkaan toimittajalukkoon. Jos ratkaisu julkaistaan ns. avoimena lähdekoodina muutkin voivat kehittää ja hyödyntää toteutettua ratkaisua. Koodin julkaisu siis mahdollistaa levitessään laajemman kehittäjäyhteisön, jolloin sopivaa ohjelmointiosaamista on helpompi etsiä kuin julkaisemattoman suljetun koodin tapauksessa. Itse toteuttamisessa on yleensä hyvä käyttää ketterää toteutustapaa (ketterän menetelmän betavaihe).

Ratkaisun järjestämistapa

Tietojärjestelmän järjestäminen ja ylläpito voidaan hankkia neljällä perusperiaatteiltaan poikkeavalla tavalla:

  • Omaan palvelinsaliin hankkimalla
  • Ulkoistettuun palvelinsaliin hankkimalla
  • Yksityisenä pilviratkaisuna hankkimalla
  • Julkisena pilviratkaisuna hankkimalla

 

Perinteiset mallit

Perinteisin malli on omassa palvelinsalissa ylläpito. Toki palvelinympäristön eri kerrokset voidaan ulkoistaa eri tasoisesti (sali ja infra, käyttöjärjestelmä, tietokannat, tietojärjestelmä, jne.).

Koko palvelinsali voidaan myös ulkoistaa, mutta hankintamalli silti voi pysyä perinteisenä palvelinsalimallina.

 

Pilvimallit

Uusimmat ylläpitotavat eli pilvimallit käsittävät kaksi periaatteeltaan erilaista vaihtoehtoa. Ns. dedikoitu yksityinen pilviratkaisu (private cloud) tarkoittaa sitä, että kyseistä fyysistä ympäristöä ei käytä yksikään toinen asiakas. Julkinen pilviratkaisu (public cloud) tarkoittaa sitä, että samassa fyysisessä tietojärjestelmäympäristössä on useita eri asiakkaita. Järjestelmäympäristö pitää eri asiakkaiden konfiguraatiot ja tiedot erillään ohjelmallisesti. Dedikoitu ratkaisu on toimittajalle luonnollisesti kalliimpi järjestää, joten myös hintakin on yleensä oleellisesti korkeampi julkiseen pilviratkaisuun verrattuna. Julkiseen ratkaisuun voi yleisesti tehdä paljon vähemmän asiakaskohtaisia muutoksia. 

Tietoturvan ja tietosuojan huomiointi pilvimalleissa

Pilviratkaisuja harkitessa on myös huomioitava tietoturva- ja tietosuojavaatimukset. Julkinen pilviratkaisu, jossa samassa ympäristössä on muitakin asiakkaita, ei sovi kaikelle tiedolle. Kaikista pilviratkaisuista on varmistettava myös, missä maassa ja maanosissa ratkaisu tallettaa tietoja. Ratkaisut, jotka edellyttävät tietojen säilyttämistä Suomen rajojen tai esimerkiksi EU:n alueella voi estää joidenkin pilviratkaisutarjoajien käytön.

Sekä yksityinen, että julkinen pilviratkaisu voi olla joko:

  • SaaS - käytännössä valmisratkaisu vähäisillä muutosmahdollisuuksilla
  • PaaS - virtuaalinen ohjelmistoalusta ratkaisun koodaamiseksi
  • IaaS - virtuaaliserveriympäristö eli infra, joka tarvitsee kaiken muun omatoimisen asennuksen ja ylläpidon
  • DBaaS - virtuaalinen tietokantapalvelu

Aidot pilviratkaisut ovat usein eri tuotteita kuin perinteisellä tavalla ylläpidettävät järjestelmät. Pilviteknologia edellyttää modernia teknistä rakennetta itse tarjottavalta tuotteelta. Sen on sovelluttava jo lähtökohdiltaan useiden, jopa tuhansien eri asiakkaiden yhteiskäyttöön.

Katso lisää pilviratkaisuista ja niiden tietosuojasta täältä.

Huomioi elinkaari

Hankintamallin yhteydessä tulee ottaa huomioon toimituksen lisäksi myös käyttöönotto sekä jatkuvan ylläpidon ja ylläpidon aikaisen pienkehityksen järjestäminen. On myös arvioitava aikaa johon mennessä järjestelmälle oletetaan tulevan merkittävää uudistamistarvetta. Samalla tämä on myös järjetelmään tehtävän investoinnin takaisinmaksuajan takaraja. Investoinnin ja käyttökulujen elinkaarikustannusten tulisi olla taloudellisesti perusteltuja koko arvioidun käyttöajan läpi seuraavaan isompaan uudistamistarpeeseen asti. Tähän sisältyvät silloin myös arvioidut lisäinvestoinnit ja käyttökuluun kohdistuva ylläpidollinen kehitys.

 


Lisää aiheesta

 

Luonnos