 Julkisia hankintoja on riivannut monella alalla jo vuosia tarjoajakato. Hankintayksikkö julkaisee Hilmassa omasta mielestään todella hyvän tarjouspyynnön tarjoajia kiinnostavasta hankinnasta. Lopputuloksena pöydällä ei ole kuitenkaan yhtään tarjousta. Tai saattaa olla yksi, mutta sekin on liian kallis tai ei täytä vaatimuksia. Mistä tämä johtuu? Syitä on tietysti monia, mutta yleistäen voisi sanoa, että tarjoajia ei ole otettu riittävästi huomioon. On ajateltu, että kyllähän tarjoajat automaattisesti ovat kiinnostuneita jättämään tarjouksen, kun siihen mahdollisuus tulee. Tässä tuleekin se iso virhe! Tarjoajat nimittäin valitsevat, mihin tarjouspyyntöihin haluavat vastata. Hyvä esimerkki oli eräässä järjestelmähankinnassa, jossa saimme kaikki etukäteen potentiaalisimmiksi arvioimamme tarjoajat tarjoamaan ja hintatasokin laski markkinavuoropuhelun aikana saaduista tiedoista. Hankintapäätöksen jälkeen sopimuksia valmistellessa kisan voittanut tarjoaja sanoi, että he jättivät tämän tarjouskilpailun vuoksi osallistumatta kolmeen vastaavaan tarjouskilpailuun. Syyksi kertoivat sen, että tässä hankinnassa välittyi yhteistyön henki, eikä perinteinen hankintayksikön "määräysvalta". He halusivat voittaa nimenomaan tämän kisan ja panostivat siihen täysillä! "WAU!", sanoin minä. Olimme onnistuneet kaikissa keskeisissä tavoitteissamme. Lisäksi käyttöönoton jälkeen asiakas on kommentoinut, että ovat olleet erittäin tyytyväisiä lopputulokseen. Kaikin puolin onnistunut hankinta siis! Julkisten hankintojen onnistumisen keskiössä onkin se, kuinka hyvin tarjoajat saadaan sitoutumaan hankintaan. Hyvä kilpailu saadaan aikaiseksi vain silloin, kun mukana on riittävästi laadukkaita tarjoajia. Tämä korostuu aloilla, joilla tarjoajia on hyvin vähän. HR-järjestelmähankinnat ovat tästä hyvä esimerkki. Tarjoajia on koko markkinassa pari kourallista ja hankinnan luonteesta sekä hankintayksikön tarpeista riippuen potentiaalisia tarjoajia on aina käytännössä alle kourallinen. Hyvänä lopputuloksena voidaankin pitää jo sitä, että saadaan kolme tarjousta pöydälle! Tarjoajat valitsevat, mihin tarjouspyyntöihin haluavat vastata Miten tarjoajakokemus otetaan huomioon? Ensinnäkin tarjoajat tulee ottaa aktiivisesti mukaan hankinnan valmisteluun, käytännössä huolellisesti toteutettavan markkinavuoropuhelun keinoin. Myös viestintään tulee kiinnittää huomiota koko prosessin ajan. Hankintayksiköt sanovat järjestävänsä aina ennen hankintaa markkinavuoropuhelun. Väitän, että tätä käytetään kuitenkin keskimäärin erittäin tehottomasti hyödyksi. Liian usein markkinavuoropuhelu toteutetaan siten, että julkaistaan Hilmassa tietopyyntö ja pyydetään tarjoajat esittelemään ratkaisujaan. Hankintayksikkö on saattanut esittää ennalta muutamia kysymyksiä, joihin tarjoajat ovat vastanneet tai vastaavat tarjoajatapaamisten aikana. Keskustelut pyörivät kuitenkin pääasiassa tarjoajan ratkaisun ympärillä. Markkinavuoropuhelun jälkeen on sitten laadittu tarjouspyyntöaineisto ja julkaistaan hankintailmoitus Hilmassa. Lopputuloksena on usein se tyhjä pöytä. Siitä huolimatta, että hankintayksikkö järjesti mielestään laadukkaan markkinavuoropuhelun ja kuunteli tarjoajia. Mikä siis meni pieleen? Keskustelut pyörivät pääasiassa tarjoajan ratkaisun ympärillä Ongelma on yleensä edellä kuvatussa prosessissa se, että tarjoajia kyllä kuunnellaan, mutta heille ei anneta mahdollisuutta ottaa millään tavalla kantaa itse tarjouspyyntöaineistoon. Tämä johtaa siihen, että tarjouspyyntö voi jo soveltuvuusvaatimusten kohdalla olla liian tiukka, jolloin potentiaalinen tarjoaja tippuu heti kättelyssä pois pelistä. Hankinnan kohteen vaatimuksissa voi olla myös sellaisia pakollisia vaatimuksia, joihin tarjoajien on mahdoton sitoutua. Myös sopimusehdoissa voi olla kohtia, jotka aiheuttavat haasteita. Onkin ensiarvoisen tärkeää, että erityisesti avoimella menettelyllä hankittaessa tarjoajille annetaan mahdollisuus nähdä ja kommentoida etukäteen alustavaa tarjouspyyntöä. Itse asiassa kun tämä tehdään huolellisesti, voidaan avoimelle menettelylle saada neuvottelumenettelyn kaltainen prosessi, jossa hankinnan vaatimukset saadaan yhdessä tarjoajien kanssa muokattua hyväksi kompromissiksi. Ja kun tämä tehdään markkinavuoropuhelun keinoin, vältetään neuvottelumenettelyn prosessiin kuuluva kankeus ja työläys. Samalla pitää toki huolehtia hankintalain vaatimuksesta kohdella tarjoajia tasapuolisesti ja syrjimättä. Eli ei käydä keskusteluja vain yhden tarjoajan kanssa, eikä yhden tarjoajan ehdoilla. Tämä on osa myös hankinnan laadun varmistamista. Mikäli tarjoaja havaitsee, että tarjouspyyntöä viedään juuri heidän ratkaisunsa suuntaan, on sillä yleensä hintaa nostava vaikutus. Hyvän tarjoajakokemuksen ohella onkin tärkeää, että osataan pitää koko ajan sopiva kilpailuasetelma. Tämä varmistetaan oikein tehdyllä viestinnällä hankinnan kaikissa vaiheissa! On tärkeää, että osataan pitää koko ajan sopiva kilpailuasetelma! Tarjoajat tulee toki ottaa huomioon myös hankinnan vaatimuksissa ja sopimusehdoissa. Kun hankitaan pitkälle tuotteistettuja pilvipalveluita / SaaS-palveluita, tulee vaatimuksiin herkästi sellaisia kohtia, joihin osan tarjoajista on hankala sitoutua ainakaan tarjouspyynnössä vaaditulla aikataululla. Usein käy niin, että tarjoajat ihmettelevät vaatimuksia, ovatko nämä todella niin tärkeitä asioita, että täytyy tässä olla pakollisena. Myös sopimusehdoissa saattaa olla kohtia, jotka tarjoajan silmissä vaikuttavat jopa tarjoajan "kyykyttämiseltä", vaikka tämä ei useimmiten ole hankintayksikön tarkoitus. Onkin hyvä pohtia, miten asiat kerrotaan, eli miten niistä viestitään. Jääkö tarjoajalle sellainen olo, että tässä tarjoajaa halutaan kyykyttää, vai onko kenties vain kyse epähuomiossa määritellystä turhan tiukasta vaatimuksesta? Tätä tapahtuu usein, kun vaatimuksia kopioidaan aiemmin tehdyistä tai jopa toisen hankintayksikön tarjouspyynnöistä. Hyvin tehty viestintä onkin koko hankintaprosessin ja itse asiassa hankintakaudenkin aikana yksi hankinnan onnistumisen avaimista. Hyvin tehty viestintä on yksi avain hankinnan onnistumiselle Sekin on muuten hyvä muistaa, että kaikille tarjoajille julkiset hankinnat eivät ole tuttuja. Usein varsinkin järjestelmähankinnoissa vanhojen perinteisten toimittajien tilalle haluttaisiin "uutta verta" eli modernimpia toimittajia ja ratkaisuja. Tässä tilanteessa sellaisiakin tarjoajia halutaan saada mukaan, jotka eivät ole välttämättä aiemmin edes osallistuneet julkisiin hankintoihin. Tämä taas korostaa sitä, että tarjoajan soveltuvuusvaatimuksia täytyy harkita erityisen tarkasti. Jos vaaditaan, että tarjoajan pitää esittää viisi referenssiä julkiselta sektorilta, on turha toivoa kisaan mukaan muita, kuin jo markkinassa toimivia. Moderneja tarjoajia ei siis saada mukaan perinteisillä vaatimuksilla! Samoin hankintaprosessi ja sen eteneminen on uusille toimijoille vieraampaa. Tämän vuoksi onkin syytä kiinnittää huomiota siihen, että tarjoajat saavat riittävän informaation prosessin etenemisestä. Joskus olen törmännyt siihen, että jotkin tarjoajat eivät markkinavuoropuhelussa halunneet vastata kysymyksiin, kun pelkäsivät, että kilpailijat saavat nämä vastaukset käsiinsä. Tämäkin on hyvä avata jo tietopyynnössä, että vastaukset käsitellään luottamuksellisina ja itse tarjouspyyntöön liittää vielä selkeät ohjeet, miten liikesalaisuuksia sisältävät tiedot tulee ilmoittaa. Moderneja tarjoajia ei saada mukaan perinteisillä vaatimuksilla Olen useammassa kohdassa edellä viitannut viestintään. On hyvä huomata, että viestintä ei ole pelkästään sitä, miten tiedotamme tarjoajia hankinnasta tai miten teemme yhteydenpitoa. Viestintää on myös se, minkälaisia vaatimuksia ja millä prioriteeteilla päätämme niitä jättää lopulliseen tarjouspyyntöön. Voimme viestiä tarjoajille, että kisassa on mukana muitakin potentiaalisia tarjoajia ja siksi tätä vaatimusta ei laitettukaan pakolliseksi, vaikka se teillä olikin vakio-ominaisuus.
Yhteenvetona voisin sanoa, että vaikka hankinnoissa on kyse aina hankintayksikön tarpeista, ei hankintaa saa tehdä vain hankintayksikön lähtökohdista. Tarjoajat ja heidän kyvykkyytensä tulee ottaa huomioon ja tarvittaessa hankintayksikön tulee olla valmis tinkimään omista tavoitteistaan ja vaatimuksistaan. Myös suhdanteet on hyvä ottaa huomioon. Eräässä hankinnassa törmäsimme tilanteeseen, jossa julkiset hankinnat eivät yksinkertaisesti kiinnostaneet tietyn teknologian tarjoajia juuri sillä hetkellä, koska yrityspuolella oli kädet täynnä töitä. Tässä tilanteessa tarjoajat jättävät vielä herkemmin osallistumatta, joten koko tarjousprosessin helppous on tietysti avainasemassa. Onko teillä haasteita meneillään olevassa hankinnassa tai olette valmistautumassa tulevaan hankintaanne ja pohditte, miten siitä selvitä? Ota yhteyttä, niin keskustellaan, miten me voimme auttaa. Tehdään yhdessä vaikuttavia ja tuloksellisia hankintoja!  Minulta kysytään usein julkisiin hankintoihin liittyen, saako järjestelmätoimittajien kanssa keskustella ennen hankintaa? Vastaushan on, että totta kai saa ja pitääkin! Itse asiassa hankintalakikin kannustaa tähän (Hankintalain 9 Luku 65 §). Miten tätä keskustelua tarjoajien kanssa tulee käydä, jotta siitä saadaan mahdollisimman suuri hyöty hankinnalle? Riittääkö, että pyydetään järjestelmätoimittajat esittelemään ratkaisujaan? Tässä artikkelissa annan muutamia vinkkejä, jotka on laadittu erityisesti julkisiin hankintoihin, mutta toimivat soveltaen toki myös muissa hankinnoissa. Tunne tarpeesi Tee ennen hankintaa huolellinen tarvekartoitus, jonka pohjalta muodostuu alustava vaatimusmäärittely (tämä toimii sitten jo pohjana kilpailutusmateriaalille). Tarvekartoituksessa oleellista on katsoa nykytilan ohella ja erityisesti tulevaisuuteen! Tässä kohtaa on hyvä pohtia mm. seuraavia kysymyksiä:
Tarvekartoituksen pohjalta laaditaan vaatimusmäärittely, joka toimii osana kilpailutusmateriaalia. Tunne markkinat Jotta hankinnassa voidaan onnistua, on välttämätöntä ymmärtää, minkälainen juuri tähän hankintaan liittyvä järjestelmämarkkina on. Millaisia ratkaisut ovat, mitkä ovat niiden vahvuudet ja heikkoudet? Millaisia reunaehtoja tarjoajilla on? Mikäli markkina ei ole entuudestaan tuttu, kannattaa jo vaatimuskartoitusvaiheessa tehdä markkinaselvitys ja tutustua eri ratkaisuihin esim. järjestelmädemojen avulla. Jo tässä vaiheessa on tärkeää osata kysyä oikeita kysymyksiä. Tarjoajat kun tahtovat esitellä vain järjestelmien hyviä puolia, huonojen puolien jäädessä vähemmälle huomiolle. Markkinaselvitys auttaa vaatimusmäärittelyn laatimisessa, kun pohditaan, mitkä vaatimukset voidaan asettaa pakollisiksi ja mistä annetaan kenties laatupisteitä. Näitä tarkennetaan sitten vielä myöhemmin. Mitoita vaatimukset oikein Pelkkä markkinaselvitys ei riitä! Ennen hankintailmoituksen julkaisua on tärkeää käydä vielä huolellinen vuoropuhelu tarjoajien kanssa jo valmiin tarjouspyyntöaineiston kanssa. Tässä tavoitteena on selvittää mm.
Markkinavuoropuhelu kannattaa käydä siten, että tarjoajille annetaan tarjouspyyntömateriaali kommentoitavaksi. Tietopyyntö (RFI) voidaan julkaista joko Hilman kautta, jolloin kuka tahansa pääsee osallistumaan prosessiin tai vaihtoehtoisesti suunnataan tietopyyntö markkinaselvityksen pohjalta muutamalle potentiaaliselle tarjoajalle (tämä tulee tehdä riittävän laajana, jotta ei sorruta kilpailun vääristämiseen). Markkinavuoropuhelussa on syytä kiinnittää huomiota siihen, että tarjoajia kohdellaan tasapuolisesti, eikä ohjata hankintaa vain yhden tarjoajan näköiseksi. Sekin on toki hyvä muistaa, että hankintayksiköllä on oikeuskäytännössä todettu olevan hyvin laaja harkintavalta hankinnan kriteereitä kohtaan. Tasapainoilu em. asioiden kanssa on joskus haastavaa. Huolellisesti tehdyn markkinavuoropuhelun avulla saadaan tarjoukset sellaisilta tarjoajilta, joiden ratkaisut ovat hankintayksikön tarpeiden mukaisia ja tarjoajat, joiden ratkaisu ei täytä tarpeita, saadaan joko rajattua pois tai menestymään kilpailussa heikosti. Samalla varmistetaan kilpailun aikaansaanti ja kohtuuhintaiset tarjoukset. Panosta tarjouslomakkeisiin Liian moni hankinta kompastuu tarjouslomakkeiden puutteisiin. Hintaa ei vertailla kokonaisuuden kannalta järkevästi, oleellisia hinnoitteluelementtejä saattaa jäädä vertailematta tai jätetään mahdollisuus lisälaskutukseen, jota ei ole huomioitu vertailuhinnassa. Referenssitoimitukset on kuvattu liian suppeasti ja soveltuvuusvaatimukset jäävät muutoin liian ohuiksi tai kohtuuttoman raskaiksi. Vaatimusmäärittely on laadittu epäselvästi ja tarjoajat joutuvat arvailemaan, mitä tosiasiassa vaaditaan ja mitä ei. Lopputuloksena saattaa olla vääristynyt tarjoushinta, huonosti mitattava laatu tai jopa koko tarjousvertailu on mahdotonta tehdä. Cloudian tarjouspalvelu on tänä päivänä lähes kaikilla käytössä ja se auttaa osaltaan, mutta sen haasteiden vuoksi tarjousten vertailu voi olla vaivalloista tai jäädä liian suppeaksi. Hyvin laadituilla tarjouslomakkeilla tarjoajien on helppo jättää tarjous ja tarjousvertailukin on tehtävissä hyvin nopeasti ja vähällä vaivalla. Tapauskohtaisesti on toki hyvä pohtia muidenkin laatuvertailukriteerien käyttöä, esim. käytettävyyden arviointia osana tarjousten vertailua. Varaa riittävät resurssit Pitäisi hankkia uusi HR-järjestelmä. Nykyinen rekrytointijärjestelmä ei palvele tarpeita. Koulutuksia varten pitäisi hankkia verkkokoulutusympäristö. Hankinta saatiin vihdoin tämän vuoden budjettiin ja nyt runnotaan hankinta läpi vaikka väkisin! Tyypillinen tilanne hankinnoissa on, että hankinta valmistellaan ja viedään läpi oman toimen ohella, vaikka samaan aikaan on kiire jokapäiväisten asioiden kanssa. Resurssi- tai osaamisvajeen vuoksi hankinta tehdään usein liian kevyesti (esim. markkinavuoropuhelu tehdään puutteellisesti) ja lopputuloksena voi olla, että hankittava järjestelmä ei olekaan todellisten tarpeiden mukainen tai pöydälle ei saada yhtään relevanttia tarjousta. Varaa siis hankintaan riittävät resurssit ja osta tarvittaessa asiantuntija-apua. Meiltä saat apua tarvittaessa Tuntuuko käsillä oleva järjestelmähankinta haasteelliselta tai omat resurssit liian ohuilta? Me olemme auttaneet lukuisia asiakkaitamme erilaisissa järjestelmähankkeissa ja autamme mielellämme myös teitä onnistumaan! Meillä on kokemusta järjestelmähankinnoista mm. seuraavilla alueilla :
Olemme tehneet hankintoja niin yksittäisille organisaatioille, kuin suurille palvelukeskuksille sekä yksityisellä että julkisella sektorilla. Pienimmän hankinnan kokonaisarvo on jäänyt kymppitonneihin ja suurin hankinta on ollut usean miljoonan euron arvoinen.
Katso lisää asiakkaidemme kokemuksia.
Ota yhteyttä yhteydenottolomakkeella, lähetä sähköpostia tai soita p. 0400733915, niin sovitaan lyhyt palaveri, jossa käymme läpi hankintanne haastekohdat ja annamme vinkkejä hankinnan läpivientiin. Teemme tämän jälkeen halutessanne ehdotuksen asiantuntija-avusta hankkeenne onnistumisen takaamiseksi.  Itsenäisyyspäivän jälkimainingeissa somessa kuohahti. Trafin uusi ajokorttitietopalvelu herätti huolta henkilötietojen päätymisestä vääriin käsiin. Palvelun avulla oli mahdollista vähäisellä vaivalla selvittää julkiseksi määriteltyjen tietojen ohella mm. henkilötunnuksia. Jo ajokorttitietojen saaminen julkisesta palvelusta ilman käyttäjän tunnistamista oli riittävän huono juttu. Henkilötunnusten vuotaminen palvelun kautta on jo aidosti vakavampi paikka ja herätti aiheellisesti kansalaisissa sekä närkästystä että huolta Trafin tietoturva- ja tietosuojaosaamisesta. Käytännössä kaikki sanomalehdet ja uutispalvelut tarttuivat aiheeseen ja kirjoittivat viikon aluksi runsaasti aiheesta. Selvisi, että palvelu oli itse asiassa aiemmin syksyllä vielä heikompi. Eräs käyttäjä oli saanut selville helposti kymmenen tuntemattoman henkilön henkilötunnukset ja muut henkilötiedot, joiden avulla identiteettivarkaus käytännössä tehdään. Tästä lisää YLE:n uutisessa. Katso samalla myös juttu Jarin tapauksesta, johon on linkki ko. uutisessa. Se avaa hyvin henkilötunnuksen vääriin käsiin vuotamisen merkitystä. Trafi joutui some-kohun myötä kaltevalle pinnalle ja päätti sulkea palvelun, kunnes sen tietosuojaongelmat on selvitetty. Samalla kaikki muutkin Trafin julkiset tietopalvelut laitettiin ns. seisontaan (liikennekäytöstä poisto), kunnes Viestintävirasto olisi Liikenne- ja viestintäministeriön toimesta selvittänyt Trafin palveluiden turvallisuuden. Yhden palvelun huonon suunnittelun vuoksi useat Trafin palvelut ovat siis olleet pois käytöstä aiheuttaen ongelmia mm. autokauppiaille. Yhden palvelun huonon suunnittelun vuoksi useat Trafin palvelut ovat olleet pois käytöstä. Jotta asia ei jäisi pelkästään kuohunnaksi, on syytä pysähtyä pohtimaan, mitä voimme oppia Trafin tapauksesta! Trafi perusteli palvelua sillä, että Laki liikenteen palveluista määrää ajokorttitiedot julkisiksi. Tähän antoi jo tietosuojavaltuutettu Reijo Aarnio edellä mainitussa YLEn artikkelissa vastakommentin, että se ei tarkoita, että tietoja voisi käsitellä miten haluaa. Eikä voikaan. Tietosuoja-asetus lähtee ensinnäkin siitä, että henkilötietojen käsittelylle on oltava laillinen peruste (Artikla 6, Käsittelyn lainmukaisuus). Trafin palvelussa tehtävä tietojen julkaisu on yksi henkilötietojen käsittelyn muoto. Tietosuoja-asetus antaa käsittelyn lailliseksi perusteeksi mm. lakisääteisen velvoitteen noudattamisen (Artikla 6, kohta 1 c) ja tähän Trafi nojasikin käsittelynsä. Henkilötietojen käsittelyssä ei voida kuitenkaan tukeutua vain käsittelyperusteeseen ja unohtaa sen jälkeen kaikki muu lainsäädäntö, tietosuoja-asetuksen velvoitteet mukaanlukien. Henkilötietojen käsittelyssä ei voida tukeutua vain käsittelyperusteeseen Tietosuoja-asetuksen yhtenä keskeisistä vaatimuksista on sisäänrakennettu ja oletusarvoinen tietosuoja (Artikla 25). Tämä tarkoittaa käytännössä sitä, että jo palvelua suunniteltaessa on otettava huomioon henkilön yksityisyyden suojan toteutuminen ja suunniteltava mm. palvelun tietoturvaratkaisut tätä tukien. Tietoturvaan ja tietosuojaan liittyviä ratkaisuja ei voida ns. päälleliimata palvelukehityksen lopuksi tai myöhemmin saadun asiakaspalautteen pohjalta. Toki palautteen ja/tai muun jatkuvan riskiarvioinnin pohjalta palvelua sekä sen tietoturvaa voidaan ja on syytäkin edelleen kehittää. Keskeisiä puutteita ja ongelmia Trafin palvelussa olivat ainakin seuraavat:
Palvelun puutteet mahdollistivat mm. täydellisen identiteettivarkauden! Trafin palvelun kohdallakin on syytä palata yhteen asetuksen vaatimukseen, eli tietojen minimointiin. Asetus ja sen vaatimukset sisäänrakennetusta ja oletusarvoisesta tietosuojasta (Artikla 25) sekä yleiset henkilötietojen käsittelyä koskevat periaatteet (Artikla5) lähtevät siitä, että kussakin tilanteessa käsitellään vain sellaista tietoa, jota todella tarvitaan ja vain niin pitkään, kuin on tarvetta. On paikallaan arvioida, ovatko kaikki palvelun tarjoamat tiedot sellaisenaan todella tarpeen esimerkiksi tilanteessa, jossa kuljetuspalvelua tilaava kuluttaja selvittää kuljetuspalvelun suorittavan henkilön ajolupa-asioita. Eikö tämän voisi toteuttaa esimerkiksi seuraavasti?
Tämä on yksi esimerkki, kuinka tietojen minimointia voisi toteuttaa. Nyt Trafi julkaisi palvelussa mm. henkilön koko nimen sekä kaikki ajokorttiluokat ja erikoisluvat. Hakutoiminnon avulla pystyi siis kokeilemalla selvittämään myös henkilötunnuksen. Näiden tietojen perusteella voi muista lähteistä selvittää mm. henkilön kotiosoitteen, puhelinnumeron jne. Tässä kohtaa on toki syytä pohtia myös, onko uuden lain teksti määritelty huonosti tai tulkittu väärin Trafin toimesta, kun päädyttiin kehittämään tietosuojan kannalta kyseenalainen palvelu. Käsitellään vain sellaista tietoa, jota todella tarvitaan! Summa summarum. Mitä opimme?
Me olemme pohtineet näitä asioita yhdessä eri toimialojen asiakkaidemme kanssa hyvin käytännönläheisestä näkökulmasta. Mikäli kaipaatte organisaatiossanne käytännön osaamista ja näkökulmaa tietosuoja-asetuksen selättämiseen, tutustu esimerkiksi koulutustarjontaamme. Katso myös, mitä asiakkaamme ovat kertoneet palveluistamme.  Kun laadin tietosuojaselostetta, mistä minä sen itse asiassa laadinkaan? Siinä kun pitää määritellä henkilörekisterin nimi. Vai pitääkö? Mikä se henkilörekisteri on? Eihän tietosuoja-asetus puhu enää henkilörekistereistä? Näitä kysymyksiä moni saattaa pohtia. Olen törmännyt aika ajoin siihen, että tietosuoja-/rekisteriselostetta laaditaan jostain tietojärjestelmästä, esim. rekrytointijärjestelmästä. Eli henkilörekisteri = rekrytointijärjestelmä. Joskus näin voikin olla ja seloste on tällöin ihan riittävä, jos siinä puhutaan vain rekrytointijärjestelmästä. Käytännössä kuitenkin usein tai lähes aina henkilörekisteriin liittyy myös muita välineitä, joissa ko. henkilötietojen käsittelyyn liittyen joko arkistoidaan, säilytetään tai vähintään väliaikaisesti käsitellään tietoa. Rekrytointiprosessissa tyypillisesti tällainen voisi olla vaikkapa soveltuvuusarvioinnit sisältävä mappiarkisto. Tai ansiovertailut / hakijavertailut, joita tulostetaan exceliin, kenties viedään johtoryhmään esiteltäväksi ja (toivottavasti) jossain vaiheessa joko tuhotaan tai säilytetään hyvin suojattuna. Henkilörekisterihän ei muuten välttämättä sisällä lainkaan tietojärjestelmiä. Myös vaikkapa sähköpostiin tai paperilla vastaanotetut työhakemukset muodostavat henkilörekisterin. Rajanvetoa, missä menee eri rekisterien rajat, ei ole missään laissa tai asetuksessa sanottu, eli sitä pitää pohtia tapauskohtaisesti. Joku voisi ajatella, että soveltuvuusarvioinneista tehtäisiin oma rekisteri. Ja näin voi hyvinkin olla. Siitä pitää sitten tehdä oma seloste. Henkilörekisteri ei välttämättä sisällä lainkaan tietojärjestelmiä Kun määrittelet jotain tiettyä henkilörekisteriä, lähde ajattelemaan henkilötietojen käsittelyn tarkoitusta. Eli mihin tarkoitukseen keräämme henkilötietoja ja miten niitä käsitellään? Ota huomioon koko prosessi:
Tällä ajattelulla saat kiinni, mihin liittyen olitkaan laatimassa sitä rekisteri- tai tietosuojaselostetta. Rekrytoinnin kohdalla rekisterin nimi voisi olla vaikkapa "työnhakijarekisteri", joka sisältää työhakemusten lisäksi soveltuvuusarviointiraportit, haastattelijoiden erikseen laatimat haastattelumuistiot (toivottavasti nämä on laadittu ja tallennettu vain rekryjärjestelmään, jos sellainen on käytössä), tulostetut työhakemukset (toivottavasti tuhotaan heti käytön jälkeen), erikseen laaditut ansiovertailut jne. Määritellään, mihin tarkoitukseen henkilötietoja kerätään ja miten niitä käsitellään Nyt tullaan sitten yhteen oleelliseen muutokseen verrattuna vanhaan lainsäädäntöön. Nykyinen henkilötietolaki vaatii (10 § Rekisteriseloste), että rekisteriselosteen on mm. sisällettävä "kuvaus rekisterin suojauksen periaatteista". Eli kuinka tiedot eri järjestelmissä tai muissa tallennusvälineissä on suojattu. Ja tämä rekisteriseloste on pidettävä jokaisen saatavilla. Tietosuoja-asetus sen sijaan ei enää puhu rekisteriselosteesta (sen enempää kuin tietosuojaselosteestakaan), vaan että käsittelyä koskevat tiedot on toimitettava rekisteröidyille "tiiviisti esitetyssä, läpinäkyvässä, helposti ymmärrettävässä ja saatavilla olevassa muodossa selkeällä ja yksinkertaisella kielellä". Toisekseen, tietosuoja-asetus ei enää vaadi, että edellä kuvattuun informaatioon olisi sisällytettävä tieto rekisterin suojaustoimenpiteistä. Artiklassa 30 taas määritellään "Seloste käsittelytoimista", joka on toimitettava tietyissä tilanteissa tietosuojaviranomaiselle. Tämän selosteen on sisällettävä myös mahdollisuuksien mukaan yleinen kuvaus artikla 32 ("Käsittelyn turvallisuus") kohdassa 1 tarkoitetuista teknisistä ja organisatorisista turvatoimista. Meidän ei tarvitse siis julkisesti kertoa, miten rekisteri on suojattu, mutta tietosuojaviranomaiselle tämä tieto on tarvittaessa annettava. Oletettavasti, jotta viranomainen voi arvioida, kuinka hyvin asetuksen vaatimuksia toteutetaan. Hyvä muutos! Tosin tullaan taas pieneen jippoon asetuksessa, eli asetuksen perusteissa, esim. kohdassa 39 mainitaan muun ohella "Luonnollisille henkilöille olisi tiedotettava henkilötietojen käsittelyyn liittyvistä riskeistä, säännöistä, suojatoimista ja oikeuksista...". Eli onko sitten kuitenkin kerrottava myös suojatoimista julkisesti? Toivottavasti tuleva tietosuojalaki tai vähintään tietosuojaviranomaisen ohjeistus antaa tälle selvyyden. Meidän ei tarvitse julkisesti kertoa, miten rekisteri on suojattu PS. Vielä loppuun on tuotava esille, kun jotkut ovat tarttuneet termeihin "rekisteriseloste" tai "henkilörekisteri", että eihän asetus näistä puhu, vaan siinä puhutaan vain henkilötiedoista ja rekisteröidyn informoinnista. No ei puhutakaan, mutta mielestäni voimme silti käyttää jo vakiintuneita termejä, joilla asiasta arkikielessä puhutaan. Väittipä joku kerran, että pitäisi tehdä vain yksi kuvaus henkilötietojen käsittelystä koko organisaatiossa. Fakta on kuitenkin se, että meillä on käytännössä erilaisia henkilörekistereitä ja niiden käyttötarkoitukset, tietosisällöt ym. vaihtelevat. On nimenomaan asetuksen mukaista selkeyttä tehdä näitä kuvauksia rekisterikohtaisesti. Eli puhutaan vaan reilusti henkilörekisteristä ja rekisteriselosteesta (tai vaihtoehtoisesti tietosuojaselosteesta). Ei kuitenkaan sekoiteta tätä artiklan 30 mukaiseen "Selosteeseen käsittelytoimista", joka on siis tietosuojaviranomaista varten tehtävä dokumentti. Puhutaan vaan reilusti henkilörekisteristä ja rekisteriselosteesta tai tietosuojaselosteesta Joko meni pää pyörälle? Toivottavasti ei!
Mikäli kaipaat selvyyttä asetuksen koukeroihin, osallistu tietosuojakoulutukseemme, niin pääset kärryille, mihin seikkoihin olisi syytä kiinnittää huomiota ja millä toimenpiteillä selätät asetuksen haasteet.  Tietosuoja-asetus lähtee siitä, kuten jo vanha henkilötietolaki, että rekisterinpitäjä saa käsitellä vain tarpeellista henkilötietoa. Tietosuoja-asetuksessa asia on määritelty mm. artiklassa 5 seuraavasti: c) henkilötietojen on oltava asianmukaisia ja olennaisia ja rajoitettuja siihen, mikä on tarpeellista suhteessa niihin tarkoituksiin, joita varten niitä käsitellään (”tietojen minimointi”); Mitä "tietojen minimointi" sitten käytännössä tarkoittaa? Mikä on tarpeellista tietoa? Jotta rekisterinpitäjä voi toteuttaa tietosuoja-asetuksen vaatimuksia, täytyy käsiteltävän tiedon rajoittua vain niihin tietoihin, jotka ko. rekisterin käyttötarkoituksen kannalta ovat olennaisia. Jokaiselle henkilörekisterille on rekisterinpitäjän toimesta määriteltävä aivan ensiksi rekisterin käyttötarkoitus. Henkilötietojen käsittelijä, kuten vaikkapa rekrytointijärjestelmän toimittaja, ei määritä rekisterin käyttötarkoitusta, vaikka järjestelmätoimittaja onkin kehittänyt järjestelmän tiettyä käyttötarkoitusta varten. Rekisterinpitäjä määrittää siis aina rekisterin käyttötarkoituksen. Käyttötarkoitus voi olla vaikkapa asiakastietojen hallinta myynti-tilaus-toimitusprosessissa (asiakasrekisteri) tai työnhakijatietojen hallinta rekrytointiprosessissa (työnhakijarekisteri). Rekisterinpitäjä määrittää aina rekisterin käyttötarkoituksen Kun henkilörekisterille on löydetty lainmukainen käyttötarkoitus, voidaan tarkastella, mitä henkilötietoja rekisteriin voidaan tallentaa. Tämä on se kohta, jossa toteutetaan tietosuoja-asetuksen mukaista tietojen minimointia. Esimerkiksi kattoremontteja tekevän yrityksen on tuskin tarpeellista edes tietää, saati sitten tallentaa omiin järjestelmiinsä (asiakasrekisteriin) tietoa vaikkapa asiakasperheen lasten lukumäärästä, lasten nimistä puhumattakaan. Myyjä voi toki näistä asioista jutustella asiakkaan luona ja usein jutteleekin, synnyttääkseen luottamuksen ja helpottaakseen kaupan tekoa, mutta mihinkään muistiinpanoihin tai järjestelmiin tietoa ei ole syytä kirjata. Sen sijaan toimituksen ja laskutuksen kannalta on olennaista tietää, missä osoitteessa remonttikohde sijaitsee tai kenelle tarjous tehdään ja lasku lähetetään (henkilön nimi). Jopa henkilötunnus voidaan pyytää rahoitushakemusta varten (ja tämä tieto pitää suojata erityisen huolellisesti, mutta se on jo toisen artikkelin aihe). Kattoremontteihin liittyen vielä yksi näkökulma: Moni perustelee asiakastietojen pitkäaikaisella säilytyksellä sitä, että uudella katolla voi olla jopa 25 vuoden takuu ja tietoja joudutaan säilyttämään takuukäsittelyä varten. Nytpä kysynkin, mitä jos ko. talo vaihtaakin omistajaa vuoden päästä? Haetko siihen uuden omistajan tiedot? Niinpä. Takuukäsittelyä varten riittänee, kun järjestelmissänne on tieto, mihin kohteeseen (osoitteeseen) ko. remontti on tehty. Kattoremontteja tarjoavan yrityksen on tuskin tarpeellista tallentaa asiakasrekisteriin tietoa asiakasperheen lasten lukumäärästä Totesimme siis edellä, että osoite on tarpeellinen tieto asiakasrekisterin käyttötarkoituksen toteuttamisessa, joten saamme sen kysyä tässä tapauksessa (ja tällä rekisterinpitäjällä). Mutta tarkoittaako tämä sitä, että osoitetiedon kysyminen on aina muissakin henkilörekistereissä OK? Ei ole, vaan asia pitää ratkaista tapauskohtaisesti. Tarkastellaanpa seuraavaksi rekrytointiprosessia. Työnhaku ja työntekijän valintaprosessi on siirtynyt jo lähes täysin sähköiseen muotoon, myös julkisella sektorilla (vaikka siellä lähetellään myös paljon paperihakemuksia ja päätöksiä kirjepostilla). Olen itse ollut aikoinaan "sähköistämässä" rekrytointiprosesseja ja vuosien varrella olen saanut tehdä rekrytointijärjestelmän toimituksen yli sataan organisaatioon. Aikoinaan läheteltiin vielä jonkin verran perinteisellä kirjepostilla hakijoille tietoa, mm. valintapäätöksestä. Työnantajat eivät juurikaan enää lähetä kirjeitä työntekijöille missään vaiheessa prosessia. Siitä huolimatta minäkin määrittelin lähes aina työhakemuslomakkeeseen hakijan kotiosoitteen. En ole haastanut aiemmin kotiosoitteen kysymisen tarpeellisuutta. Montaa muuta kysymystä kyllä olen saanut haastaa, kuten kysymystä henkilön asevelvollisuuden suorittamisesta tai jopa kysymystä hakijan syntymäpaikkakunnasta (ja kieltäydyin näitä kysymyksiä lisäämästä lomakkeelle). Nyt haastan myös kotiosoitteen tarpeellisuutta! Käytännössä edes työntekijän esimiehen ei ole tarve tietää, missä osoitteessa työntekijä pistää päänsä tyynyyn. Tänä päivänä lähes kaikki viestintä rekrytointiin liittyen tehdään sähköpostitse tai puhelimella. Silti lähes kaikissa työhakemuslomakkeissa kysytään yhä hakijan kotiosoitetta. Eli kotiosoite kysytään tuhansilta tai jopa kymmeniltä tuhansilta työnhakijoilta, vaikka esimies ei tiedä edes lähimmän alaisensa osoitetta. Miksi näin? Jos keksit asiallisen perustelun, mihin tarkoitukseen tarvitsette työnhakijan kotiosoitetta hakuvaiheessa, pitäkää kysymys työhakemuslomakkeella. Ja muistakaa perustella tämä tietosuojaselosteessa. Jos et keksi mitään järkevää perustetta, poistakaa kysymys lomakkeelta (ja huolehtikaa, että myös vanhoista hakemuksista ko. tieto poistetaan). Näin toteutatte asetuksen mukaista tietojen minimointia työnhakijarekisterin kohdalla. Samaa harjoitusta voi sitten jatkaa muiden tietojen kanssa. Jos et keksi mitään järkevää perustetta kotiosoitteen kysymiselle, poistakaa se työhakemuslomakkeelta! Kuten huomaamme, käsittelemme tiedon tarpeellisuutta nimenomaan rekisterikohtaisesti. Henkilön kotiosoite on asiakasrekisterissä OK, mutta työnhakijarekisterissä sitä ei nykypäivänä enää käytännössä tarvita. Näin toteutamme tietosuoja-asetuksen vaatimusta "mikä on tarpeellista suhteessa niihin tarkoituksiin, joita varten niitä käsitellään". Emme siis voi tehdä yleisiä johtopäätöksiä minkään henkilötiedon osalta, vaan asia täytyy aina ratkaista rekisterikohtaisesti tarpeen mukaan. Edetään siis seuraavia portaita pitkin:
Käytyäsi kaikki portaat läpi, pystyt tarkastelemaan kuinka esim. nykyinen järjestelmänne pystyy vastaamaan tietosuoja-asetuksen vaatimuksiin tältä osin. Tai kuinka voitte huolehtia tietojen ja käsittelyn minimoinnista, kun henkilötietoja on tallennettu manuaalisiin rekistereihin (esim. mappiarkistot). Lopuksi on vielä hyvä erottaa kaksi samankaltaista termiä, eli käsiteltävien henkilötietojen minimointi ja henkilötietojen käsittelyn minimointi. Tietojen minimoinnista puhutaan, kun mietitään, mitä tietoja käsitellään ja käsittelyn minimointi taas on sitä, kun rajataan tieto vain tarpeen mukaisen joukon saataville (mm. organisaation sisäiset henkilötietojen käsittelijät eli vaikkapa esimiehet) sekä poistetaan tieto, kun sitä ei enää tarvita. Minkään henkilötiedon osalta ei voida tehdä yleisiä johtopäätöksiä liittyen käsittelytarpeeseen Mikäli sinulla on tarvetta kasvattaa tietosuojaosaamista, osallistu koulutuksiimme. Erittäin hyvää palautetta saaneet, käytännönläheiset tietosuojakoulutuksemme ovat auttaneet jo lukuisia organisaatioita tietosuoja-asetuksen haltuunotossa ja paremman tietosuojan toteutuksessa.
Katso yleinen koulutustarjontamme täältä tai ota yhteyttä, niin järjestetään teille asiakaskohtainen tietosuojakoulutus!  GDPR-kiima alkaa olla kuumimmillaan. Organisaatiot valmistautuvat asetukseen ja tekevät oikeita toimenpiteitä hyvää vauhtia. Käydään koulutuksissa, pistetään järjestelmiä, sopimuksia ja tietosuojaselosteita kuntoon. "Hyvä hyvä! Huusivat lapset", sanoisi entinen peruskoulun opettajani. Keskustelu GDPR:n suhteen pyörii kuitenkin liikaa vain IT-järjestelmien ympärillä. Asetuksen haltuunotossa on nimittäin hyvä muistaa, että järjestelmien kuntoonlaitto on vain yksi osa-alue tietosuojan varmistamisessa. Keskustelu pyörii liikaa vain IT-järjestelmien ympärillä Artiklan 24 mukaisesti: "1. Ottaen huomioon käsittelyn luonne, laajuus, asiayhteys ja tarkoitukset sekä luonnollisten henkilöiden oikeuksiin ja vapauksiin kohdistuvat, todennäköisyydeltään ja vakavuudeltaan vaihtelevat riskit rekisterinpitäjän on toteutettava tarvittavat tekniset ja organisatoriset toimenpiteet, joilla voidaan varmistaa ja osoittaa, että käsittelyssä noudatetaan tätä asetusta. Näitä toimenpiteitä on tarkistettava ja päivitettävä tarvittaessa." Kiinnitä huomio tässä kohtaan "organisatoriset toimenpiteet"! Ne ovat niitä toimenpiteitä, joita tehdään johtamissäännöissä, käytännöissä ja prosesseissa eli käytännössä ihmisten arjessa. Pitää esittää kysymyksiä (esimerkkinä rekrytointiprosessi):
Kiinnitä katse kohtaan "organisatoriset toimenpiteet"! Vaikka meillä olisi kuinka hyvät järjestelmät, joissa tietoturvaratkaisut ovat viimeisen päälle ja olemme varmistaneet sopimuksilla GDPR-velvoitteiden vastuuttamisen myös henkilötietojen käsittelijälle, eli tietojärjestelmän toimittajalle, voi ihminen yhä tehdä virheitä. Olemme saaneet lukea useista tapauksista, joissa henkilötietoja on päätynyt esim. roskalavalle tai excel-taulukoiden kautta Google Drivessa julkiseen jakeluun. Nämä tapaukset johtuvat yleensä inhimillisestä virheestä. Ihminen, joka asiaa hoiti, ei osannut ajatella, mihin hänen toimenpiteensä johtaa. Hän ei ehkä tiennyt, että näin ei saisi toimia. Voi myös käydä vahinkoja. Työharjoittelijalle annetaan tehtäväksi siivota toimiston nurkkia. Ohjeistus oli hieman epäselvä ja hän kantaa vanhat sairauslomatodistus-mapit roskalavalle sellaisenaan, vaikka ensin piti pistää silppuriin ne todistukset. Tietosuoja toteutuu siis lopulta ihmisissä, eikä vain tietojärjestelmissä. Tämän vuoksi GDPR-kiimaa pitäisi olla muuallakin, kuin IT-osastolla. Tietosuoja toteutuu lopulta ihmisissä. Edellisestä tullaankin sujuvasti manuaalisiin rekistereihin. Prosessien ja käytäntöjen lisäksi on nimittäin syytä kiinnittää huomiota myös manuaalisiin rekistereihin. Henkilöstöhallinnossa on usein erilaisia mappiarkistoja esim. työsopimuksille, sairauslomatodistuksille jne. Lisäksi voi olla erilaisia excel-taulukoita, raportteja jne, joissa on valtavasti henkilötietoa, usein myös arkaluontoista. Manuaaliset rekisterit unohtuvat helposti, jos GDPR-työssä kiinnitetään huomiota vain tietojärjestelmiin. Myös monet GDPR-työtä helpottavat palvelut jättävät manuaaliset rekisterit sivurooliin ja keskittyvät lähinnä eri tietojärjestelmien hallintaan. Manuaaliset rekisterit ovat kuitenkin yhtä lailla tietosuoja-asetuksen velvoitteiden piirissä. Näidenkin osalta on syytä kuvata, miten ne on suojattu, kuka niiden tietoja pääsee käsittelemään ja miten vanhentuneet / tarpeettomat tiedot siivotaan pois. Ja taas toimitaan sen mukaisesti, eikä jätetä vain kuvauksen asteelle. Käytännössä tullaan huomaamaan, että manuaalisten rekisterien käsittely on valtavan työlästä ja aletaan ketteröittämään prosesseja sekä miettimään paremmin, onko tätä tietoa todella tarve säilyttää paperimuotoisena vai riittäisikö, että tieto on tallessa tietojärjestelmässä. Ja hyvä niin, näin kehitys kehittyy! Manuaalisten rekisterien suojaus unohtuu helposti, jos keskitytään vain IT-järjestelmiin Mitä sitten pitäisi tehdä, jotta GDPR-työ ei olisi vain IT-osaston asia? Käytännössä vaatii mm. seuraavia toimenpiteitä:
Henkilöstön kouluttaminen on olennainen osa tietosuoja-asetuksen haltuunottoa. Kouluttamiseen on useita erilaisia menetelmiä ja niitä kannattaa hyödyntää monipuolisesti. Henkilöstön kouluttaminen on yksi olennainen osa tietosuoja-asetuksen haltuunottoa Allekirjoittaneella on 18 vuoden kokemus henkilötietojen käsittelystä HR-tietojärjestelmien parissa. Työssäni erilaisten järjestelmien käyttöönotoissa ja järjestelmäkehityksessä olen saanut perehtyä jo vanhaan henkilötietolakiin. Olenkin auttanut vuosien varrella asiakkaitani ymmärtämään, miten henkilötietoja voidaan käsitellä lain mukaisesti. Olen myös kouluttanut tuhansia järjestelmäkäyttäjiä ja näissä koulutuksissa on aina vähintään sivuttu myös tietosuoja-asioita.
Olen ottanut haltuun luonnollisesti myös uuden tietosuoja-asetuksen erityisesti HR-toimintojen näkökulmasta ja koulutan asiakkaitani tietosuoja-asetuksen haltuunotossa käytännönläheisellä otteella CASE-esimerkkien kautta. Ei siis pelkkää kuivaa lakitekstiä, vaan aitoa käytännönläheisyyttä monimutkaisen asian haltuunottoon. Ota yhteyttä, mikäli teillä on tarve ottaa syvempää ja käytännönläheistä näkökulmaa tietosuoja-asetukseen! Osallistu yleisiin koulutuksiin, joiden avulla on helppo ottaa perusteet haltuun:
Huom! Kauppakamarin koulutuksissa jäsenalennus myös Henry ry:n jäsenille! Ilmoita jäsenyystieto ilmoittautumislomakkeella!  Mikä ihmeen ESPD-lomake? ESPD-lomake, eli yhteinen eurooppalainen hankinta-asiakirja, on aiheuttanut kovasti hämmennystä sekä hankintayksiköiden että tarjoajien keskuudessa. Mikä tämä dokumentti oikein on? Milloin ESPD-lomake pitää täyttää? Kuinka se laaditaan? Miten se täytetään? Missä se täytetään? Sehän on vain jotain outoa koodia ja näyttää ihan heprealta? (Itse asiassa se on xml-koodia). Olen hämmästynyt siitä, että esim. Hilman ohjeistus (sehän löytyy täältä) on hyvin sekava ja siinä ei ole annettu yksinkertaisesti tiivistettyä ohjetta, mistä on kysymys. Tämän vuoksi kirjoitin tämän artikkelin ja toivon, että siitä on hyötyä sinulle! Mikä ihmeen ESPD-lomake? Miten se täytetään? Missä se täytetään? ESPD-lomakehan tuli uuden EU-hankintadirektiivin kylkiäisenä keväällä 2016 meidän kaikkien iloksi ja koskee EU-kynnysarvon ylittäviä hankintoja. Kansallisissa- ja pienhankinnoissa ESPD-lomaketta ei siis käytetä. Ns. EU-hankinnoissa sitä on sen sijaan pakko käyttää. Lomakkeen tarkoituksena on helpottaa tarjoajien/ehdokkaiden työtä tarjousten/osallistumishakemusten jättämisen yhteydessä siten, että lomakkeen täyttämällä ja vakuuttamalla siinä kysytyt asiat, ei tarjoukseen tarvitse liittää kaikenlaisia selvityksiä, todistuksia ym. erikseen. Nämä todistukset pyydetään tarvittaessa sitten vain valitulta toimittajalta/toimittajilta. Toisekseen, lomake vakioi tarjoajille asetettavia soveltuvuusvaatimuksia (niiden sanamuotoja ja sisältöjä), joten tarjoajien ei tarvitse käydä suurennuslasin kanssa jokaisen tarjouspyynnön soveltuvuusvaatimuksia, minkälaisia kommervenkkejä sinne on keksitty. Lomakkeeseen tosin hankintayksikkö valitsee osan asioista tarpeen mukaan, joten jokaisessa hankinnassa on käytännössä täytettävä lomake uudestaan. Erityisen hyödyllinen lomake on sellaisille tarjoajille, jotka osallistuvat tarjouskilpailuihin useissa EU-maissa. Hankintayksikköä ESPD-lomake helpottaa mm. standardoimalla tarjoajille asetettavia soveltuvuusvaatimuksia ja huolehtimalla hankintalain pakollisten poissulkemisperusteiden mukaan otosta hankintaan. ESPD-lomake standardoi asioita ja lähtökohtaisesti helpottaa sekä tarjoajan että hankintayksikön työtä! No niin, asiakirja on siis todettu hyödylliseksi, mutta edelleen hämmästelen sitä, kuinka vaikeaksi asia on saatu näyttämään käytännössä. Kun ensimmäiset tarjouspyynnöt ESPD-lomakkeen kera julkaistiin, hankintayksiköt eivät ohjeistaneet millään tavoin tarjoajia ESPD-lomakkeen käytössä. Tarjouspyynnön liitteenä oli xml-muotoinen lomake, joka pyydettiin täyttämään ja lähettämään (mihin? miten?). Siinä sitten kaivinkoneurakoitsija miettii, millä hampailla se lomake pitää avata ja täyttää! Lisäksi, kun menee ESPD-lomakkeen käyttöä varten toteutettuun Täyttö- ja jälleenkäyttöpalveluun, on palvelun ohjeistus vähintäänkin erikoista ja termit sellaisia, että moneen kertaan saa miettiä, mitä asia tarkoittaa, mihin pitää laittaa ruksi ja mihin ei. Lisäksi tällä hetkellä vaikka kieleksi valitsee "suomi", on osa lomakkeen kohdista englanninkielisiä. Ilmeisesti jossain uudistetussa versiossa on unohdettu kääntää uudet/muutetut kohdat. Kaivinkoneurakoitsija miettii, millä hampailla ESPD-lomake pitää avata ja täyttää! Ei siis ihme, että ESPD-lomaketta on hämmästelty ja ihmetelty, miksi sellainen piti luoda. No, miten asiaan saataisiin selvyyttä? Katsotaanpa. Avainasemassa on ESPD-lomakkeen käsittelyä varten luotu Täyttö- ja jälleenkäyttöpalvelu, jossa hankintayksiköt muodostavat lomakkeen, tarjoajat täyttävät sen ja hankintayksiköt sitten tarkastelevat täytettyjä lomakkeita. Tässä lyhyesti kuvattuna, kuinka ESPD-lomake muodostetaan ja miten sitä käytetään:
Näin ESPD-lomake on siis muodostettu (hankintayksikkö), täytetty (tarjoaja) ja tarkastettu (hankintayksikkö). Hankintayksikkö muodostaa, Tarjoaja täyttää ja Hankintayksikkö tarkastelee ESPD-lomaketta Täyttö- ja jälleenkäyttöpalvelussa Mitä muuta pitäisi tietää ESPD-lomakkeesta?
Toivottavasti edellinen kappale avasi lyhykäisyydessään, kuinka ESPD-lomake kulkee hankinnassa ja miten sitä käytetään. Hankintayksiköt joutuvat vielä pohtimaan, minkälaisia kohtia lomakkeeseen pitäisi raksittaa ja miten tarkentavat vaatimukset kuvataan. Nythän ESPD-lomakkeeseen ei voi kirjata esim. liikevaihtovaatimusta, vaan siellä on ainoastaan kohta, jossa tarjoaja vakuuttaa, että täyttää asetetut vaatimukset. Tarjouspyyntöön pitää siis edelleen kuvata ainakin osa soveltuvuusvaatimuksista, mutta lähtökohtaisesti näihin vastaaminen tapahtuu ESPD-lomakkeen kautta. Tässä asia yksinkertaistettuna. Mikäli asia jäi edelleen mietityttämään, ole yhteydessä, niin autan mielelläni!  Yhtään tarjousta ei saatu, vaikka työryhmän kanssa väännettiin tarjouspyyntöä kasaan kolme kuukautta hiki hatussa. Tavattiin toimittajia ja kaikki toimittajat vakuuttivat, kuinka kiinnostava hanke on ja varmasti jättävät tarjouksen. Eivät sitten kuitenkaan jättäneet. Mikä tässä nyt meni pieleen? Realistinen aikataulu on merkittävä tekijä Voin kertoa oman kokemukseni erittäin suuresta hankinnasta, josta osa tarjoajista jättäytyi pois. Valtio hankki uuden rekrytointijärjestelmän muutama vuosi sitten. Kilpailua valmisteltiin suurella innolla ja markkinavuoropuhelua käytiin tarjoajien kanssa vuodenvaihteessa 2012-2013. Olin tuolloin vielä järjestelmätoimittajan palveluksessa ja kävimmekin tapaamassa Hanselin edustajia sekä osallistuimme alustavan tarjouspyynnön kommentointiin. Tarjoamamme järjestelmä olisi täyttänyt lähes kaikki järjestelmälle asetetut toiminnalliset vaatimukset jo tarjouspyyntövaiheessa erittäin hyvin ja tuotekehityksen määrä olisi ollut hyvin kohtuullinen. Myös kustannukset olisivat jääneet varmasti paljon pienemmäksi kilpailun voittaneen Aditron ratkaisusta. Teknisissä reunaehdoissa mm. ylläpitoon liittyen olisi ollut haasteita, mutta ei mitään ylitsepääsemätöntä. Vetäydyimme kuitenkin hankkeesta keväällä 2013, emmekä osallistuneet enää hankkeeseen. Jättäydyimme siis yhdestä suurimmista rekrytointijärjestelmän tarjouskilpailuista pois. Miksi teimme näin hullun ratkaisun? Jättäydyimme yhdestä suurimmista tarjouskilpailuista pois. Hansel piti koko ajan esillä, kuinka tärkeää on, että uusi järjestelmä on valmis ja käytössä jo vuoden 2014 alussa. Kävimme tästä keskustelua ja toimme vahvasti esille, että aikataulu ei ole realistinen, vaan on liian tiukka tämän kaltaisen massiivisen projektin läpiviennille. Uusittiinhan siinä valtion kaikkien yksiköiden käytössä oleva järjestelmä kertarysäyksellä. Lopullinen tarjouspyyntö sitten kertoi, että toteutus piti olla valmis tammikuussa 2014 ja tuotantoon mentäisiin huhtikuussa 2014. Totesimme, että asetettu aikataulu on liian tiukka, meillä oli paljon muitakin projekteja menossa emmekä halunneet lähteä tarjoamaan epärealistisella aikataululla mahdolliset viivästyssanktion uhat niskassa. Emmekä siis jättäneet tarjousta. Lopputuloshan oli lopulta vähemmän yllättävästi se, että uusi järjestelmä otettiin käyttöön vasta 20.4.2015. Siis vuoden myöhässä Hanselin aiemmin ilmoittamasta ehdottomasta aikataulusta! Mikäli aikataulu olisi alunperin laadittu realistisemmin ja siihen olisi annettu edes puolen vuoden lisäaika, olisimme varmasti jättäneet tarjouksen. Uusi järjestelmä otettiin käyttöön vuoden myöhässä alkuperäisestä ehdottomasta aikataulusta. Kirjoitin aikataulutuksen merkityksestä jo aiemmassa blogikirjoituksessa, lukaisepa sekin. Vaatimusmäärittely rajaa pois tarjoajia Myös järjestelmälle asetetut vaatimukset voivat rajata pois hyviäkin tarjoajia. Usein vaatimusluettelosta tehdään toiveiden tynnyri, jonne pudotellaan eri puolilta organisaatiota kerättyjä vaatimuksia sen kummemmin miettimättä A) ovatko ne oikeasti oleellisia vaatimuksia ja B) pystyykö yksikään toimittaja täyttämään vaatimuksia. Tarjouspyyntö voi näin muodostua järjettömän raskaaksi. Vaatimuksia asetettaessa on pysyttävä olennaisuuksissa ja varmistettava, että markkinoilta löytyy riittävästi ratkaisuja, jotka täyttävät vähintäänkin pakolliset vaatimukset. Toiveiden tynnyri pitääkin pilkkoa palasiksi ennen kuin sinne pudotetaan yhtään "vaatimusta". Tämän jälkeen voidaan kartoittaa vaatimuksia sen pohjalta, kuinka asioita käytännön työssä oikeasti haluttaisiin hoitaa. Samanaikaisesti peilataan omia vaatimuksia markkinoiden tarjontaan. Markkinavuoropuhelun toteutuksesta voit lukea lisää aiemmasta kirjoituksestani. Toiveiden tynnyri pitää pilkkoa palasiksi ennen kuin sinne pudotetaan yhtään "vaatimusta" Toiveiden tynnyri -syndrooman lisäksi on tunnistettavissa Suuri hankintayksikkö -syndrooma. Tässä oireyhtymässä isot hankintayksiköt, kuten suuret kaupungit ja sairaanhoitopiirit, eivät osaa ajatella asioita pienempien (ja yleensä lopputuloksen kannalta parempien) järjestelmätoimittajien kannalta. Hankkeista tehdään jo hankekuvauksen ja organisoinnin perusteella aivan liian raskaita suhteessa siihen, mitä ollaan hankkimassa. Viime syksynä keskustelin erään suuren kaupungin kanssa ja he ihmettelivät, miksi heidän HR-järjestelmätietopyyntönsä ei ollut kiinnostanut lainkaan pienempiä toimittajia, vaikka nimenomaan halusivat myös pieniä toimittajia mukaan. No ei se ole mikään ihme, jos hankkeesta on jo valmiiksi tehty tolkuttoman raskas ja hankittavan järjestelmän reunaehdot on määritelty järjettömiksi. Järjestelmän vaatimuksia ei oltu osattu laatia nykyaikaisen näppärän HR-järjestelmän vinkkelistä, vaan väkisin tuli mieleen, että vaatimusluettelon oli laatinut joku vanhan koulukunnan ERP-konsultti. Vähemmän on enemmän Vanha kulunut sanonta "less is more" pätee yhä. Vaatimusten kirjaamisessa on pidettävä kohtuus, mutta toisaalta ne pitää kirjata riittävällä tarkkuudella, jotta voidaan varmistua riittävästä laadusta. Lisäksi sama sääntö koskee hankittavaa järjestelmälaajuutta. Jos samalla tarjouspyynnöllä haetaan CRM-järjestelmää, HR-järjestelmää, työsuhdepolkupyöriä ja johdon assistentin työkenkiä, voit olla varma, että et huku ainakaan tarjousten suureen määrään. Tästäkin olen kirjoittanut aiemmin. Liian tiukat sopimusehdot ovat viimeinen niitti Yleisissä sopimusehdoissa on määritelty valmiiksi kohtuulliset viivästyssanktiot ja vahingonkorvauksen enimmäismäärä. Laitetaan nyt kuitenkin varmuuden vuoksi vielä vähän tiukemmat sanktiot viivästykselle, nelinkertaiset on varmaan vielä ihan OK. Ja pitäähän meidän saada määritellä, ketkä toimittajan henkilöt palvelintilassa käyvät. Toimittajan pitää vähintäänkin hyväksyttää meillä, ketä alihankkijoita käyttävät mihin tahansa osaan palvelutuotantoaan (vaikka sillä ei olisi käytännön kannalta mitään merkitystä). Asiakaspalvelu pitää myös ehdottomasti pelata klo 8-17, saattaahan joku yli-innokas virkamies joskus ylittää työaikansa ja tarvita juuri silloin toimittajan teknisen tuen langanpäähän. Ei sillä ole niin merkitystä, että järjestelmätoimittajat tarjoavat muille asiakkaille tukea klo 8-16. Kuulostaako tutulta? Saattaahan joku yli-innokas virkamies joskus ylittää työaikansa ja tarvita juuri silloin toimittajan teknisen tuen langanpäähän Asiakas joskus ajattelee, että toimittajat ehdottomasti taipuvat kaikkeen mahdolliseen, mitä keksitään vaatia. Näin ei vaan valitettavasti ole. Jos sopimusehdot ( = palvelun tuotannon reunaehdot) menevät toimittajan kannalta kohtuuttomiksi, tekee toimittaja yleensä johtopäätökset ja jättää tarjoamatta. Istu siinä sitten sopimuksen päällä vahtimassa ehtojen täyttymistä, kun ei ole ketään, ketä vahtia! Joskus se on hyvin pienestä kiinni Joskus voi käydä niinkin, että tarjouspyyntö oli sinänsä hyvä, mutta jostain syystä hankintailmoitus Hilmassa on mennyt tarjoajilta ohi. Tähänkin on useita syitä, joista aikataulutus on ainakin helppo hallita. Julkaise siis hankintailmoitus sellaisena ajankohtana, kun toimittajat eivät ole lomalla. Myös hankintailmoituksen otsikointi on tärkeää. Aikoinaan, kun valtio kilpailutti ensimmäistä kertaa Heli-rekrytointijärjestelmää, oli hankintailmoitus otsikoitu jotenkin tyyliin "Valtion sisäisen kierron prosessin tukeminen" (en enää muista tarkkaan, onhan siitä jo kohta 15 vuotta). Sepä meni meillä aikoinaan Skillnetissä ohi ja huomasimme vasta, kun eräs valtion yksikkö sanoi, että ei nyt kannata heille tarjota, kun tuo valtion kilpailutus on menossa. Sitä ennen olimme menestyksekkäästi toimittaneet Artist-rekrytointijärjestelmää useille valtion yksiköille. Tarkista siis vielä kerran ennen hankintailmoituksen julkaisemista, kertooko ilmoituksen otsikko, mitä olet ostamassa! Ja tietysti jos teet huolellisen markkinavuoropuhelun, ovat toimittajat jo valmiiksi hereillä ja odottavat tarjouspyyntöänne. Kertooko hankintailmoituksen otsikko, mitä olet ostamassa? No niin, olen siis kaksi kertaa ollut ulkona valtion rekrytointijärjestelmäkisasta. Pitäisikö jo katsoa peiliin? Ehkä kolmannella kerralla olen mukana, toivottavasti hankintakonsultin roolissa ja silloin syyllinen huonosti valmisteltuun kilpailutukseen löytyykin hyvin läheltä :) Tolkun IT-hankinnat – tolkullisten järjestelmähankintojen puolesta! Blogisarjassa pureudutaan järjestelmähankintojen maailmaan ja annetaan vinkkejä, joita noudattamalla onnistut paremmin järjestelmähankinnoissa. Vinkit sopivat yhtä hyvin niin yksityiselle kuin julkisellekin sektorille organisaation kokoon katsomatta.  Tiedätkö, mihin suuntaan olet menossa? Hyvin tehty markkinavuoropuhelu kirkastaa katseen ja antaa selkeän suunnan hankkeelle. Tarjouspyyntöön liittyvän vaatimusmäärittelyn laatimiseen on erityisesti julkisella sektorilla syytä panostaa kunnolla. Valtavasta työstä huolimatta usein käy niin, että huolella laadittuun tarjouspyyntöön ei saada yhtään vastausta. Yksikään tarjoaja ei jätä tarjousta. Tai jos jättää, saattaa hinta olla posketon tai tarjous ei ole tarjouspyynnön mukainen, jolloin se joudutaan hylkäämään. Tilanne tuntuu turhauttavalta ja aiheuttaa ihmetystä, eikö toimittajia muka kiinnosta hyvä kaupantekomahdollisuus. Eikö toimittajia kiinnosta hyvä kaupantekomahdollisuus? Kun mietitään omia tarpeita ja laaditaan tarpeiden kuvaamiseksi mahdollisimman kattava tarjouspyyntömateriaali, käy joskus niin, että unohdetaan markkinat. Ei tutustuta riittävän huolellisesti markkinoilla oleviin ratkaisuihin, eli millaisessa käytössä ne ovat parhaimmillaan ja mihin tarpeisiin pystyvät parhaiten vastaamaan. Mitä tarpeita taas eivät pysty ratkaisemaan ja mihin tarkoitukseen niitä ei ole tehty. Saattaa olla, että on jopa pyydetty toimittajia esittelemään ratkaisujaan, mutta esittelyt ovat jääneet hyvin yleiselle tasolle ja lisäksi ovat olleet myyjäosapuolen johtamia. Tällöin myyjä toki kertoo kaikki oman ratkaisunsa hyvät puolet, mutta puutteet jäävätkin kertomatta. Asiakaskaan ei ole osannut kysyä oikeita kysymyksiä, joilla ratkaisujen puutteet oltaisiin saatu esille. Asiakas ei ole osannut kysyä oikeita kysymyksiä. Hyvin toteutettu markkinavuoropuhelu antaa oivat eväät omien vaatimusten pohtimiselle. Onko realistista löytää sellaista ratkaisua markkinoilta, joka tyhjentäisi toiveiden tynnyrin? Yleensä ei, vaan vaatimuksista joudutaan tinkimään tai joskus jopa pilkkomaan hankinta useisiin osiin. Liian usein vaatimukset ovat reippaasti ylimitoitettuja tai yritetään hankkia kaikki mahdollinen kerralla. Markkinoilta ei yksinkertaisesti löydy ratkaisuja ja tarjoajia, jotka täyttäisivät kaikki vaatimukset. Joka tapauksessa tilanne on hyvä tunnistaa etukäteen, jotta ei tehdä turhaa tarjouspyyntökierrosta, jonka päätteeksi todetaan, että eipä saatu tarjouksia. Myös se toiveiden tynnyri kannattaa ensi tilassa pilkkoa palasiksi ja ottaa järki käteen. Toiveiden tynnyri kannattaa ensi tilassa pilkkoa palasiksi. Markkinavuoropuhelun ainoa tehtävä ei ole toimittajaehdokkaiden ratkaisuihin tutustuminen, vaan yhtä tärkeää on jo tässä vaiheessa aloittaa tarjoajien sitouttaminen hankkeeseen ja ylipäänsä herättää kiinnostus hanketta kohtaan. On paljon todennäköisempää saada hyviä tarjouksia, kun tarjoajien kanssa on käyty yksityiskohtaisiakin keskusteluja mahdollisesta toteutustavasta, tarjoajan ratkaisun heikkouksista ja vahvuuksista sekä asiakkaan tarpeista ja odotuksista hankkeelle. Ja näiden pohjalta tarjouspyyntö on muokattu realistiseksi. Sekin on hyvä huomata, että markkinavuoropuhelussa ei pidä keskittyä pelkästään itse järjestelmään ja sen toiminnallisuuksiin. Väittäisin nimittäin, että tarjoajat jättäytyvät pois useimmiten muiden reunaehtojen vuoksi, kuten aikatauluvaatimukset, tekniset reunaehdot sekä sopimusehdot sanktioineen. Näistäkin on siis syytä käydä avointa ja laajaa keskustelua! Markkinavuoropuhelussa ei pidä keskittyä pelkästään järjestelmän toiminnallisuuksiin. Tarjoajan on yleensä kohtuullisen helppo luvata tarjousta tehdessään jonkin toiminnallisen vaatimuksen täyttäminen (varsinkin kohtuullisella aikataululla), koska sehän on vain tuotekehitystä vaativaa. Ja meneehän siinä tuotekin samalla eteenpäin. Sen sijaan, jos muissa vaatimuksissa on esitetty (usein jopa epäoleellisia) vaatimuksia vaikkapa toimittajan palvelinympäristölle tai palvelun tuotantotavalle, joiden täyttämiseksi tarjoajan pitäisi muuttaa palveluprosessejaan, nostaa tarjoaja usein tässä kohtaa kädet ylös ja luopuu kisasta. Tai hinnoittelee tarjouksen suolaisesti. Ei kukaan järjissään oleva tarjoaja lähde muokkaamaan prosessejaan yksittäisen asiakkuuden vuoksi. Tämä on erittäin tärkeää ymmärtää ja ottaa huomioon tarjouspyyntöä laadittaessa. Järjissään oleva tarjoaja ei lähde muokkaamaan prosessejaan yksittäisen asiakkuuden vuoksi. Huolellisesti toteutettu markkinavuoropuhelu onkin edellytys koko hankkeen onnistumiselle. Mikäli markkinavuoropuhelu tehdään huonosti, on onnistuminen tuuripeliä. Tolkun IT-hankinnat – tolkullisten järjestelmähankintojen puolesta! Blogisarjassa pureudutaan järjestelmähankintojen maailmaan ja annetaan vinkkejä, joita noudattamalla onnistut paremmin järjestelmähankinnoissa. Vinkit sopivat yhtä hyvin niin yksityiselle kuin julkisellekin sektorille organisaation kokoon katsomatta.  Törmään aika usein tarjouspyyntöihin, joissa samaan kilpailutukseen on paketoitu tolkuton määrä eri järjestelmiä. Samalla tarjouspyynnöllä saatetaan hakea järjestelmiä taloushallintoon, palkanlaskentaan, HR-tietojen hallintaan, henkilöstön kehittämiseen, rekrytointiin, matkalaskujen hallintaan, työvuorosuunnitteluun, projektinhallintaan, laskutukseen ja vaikka mihin. Optiona vielä työsuhdepolkupyörät ja hammashoito (no ei onneksi sentään). Ja kaikki yhteen kiinteään hintaan. Mitä järkeä tässä on? Tai miksi tässä ei olisi järkeä? Optiona työsuhdepolkupyörät ja hammashoito. Sinänsä kuulostaa ensi alkuun hyvältä, että haetaan ratkaisua yhdeltä toimittajalta, joka kerralla pystyisi ratkaisemaan kaikki tarpeet. Vietäisiin läpi vain yksi käyttöönottoprojekti (vaiheittain), toimittajalta tulisi vain yksi lasku ja kun on hankittu näin laaja kokonaisuus, niin totta kai siinä tulee silkkaa säästöä. Lisäksi olisi vain yksi vastuutaho, jota syyttää, jos jokin palanen ei toimi. Näinkö on? Mietitäänpä hetki. Kuinka monelta järjestelmätoimittajalta löytyy kaikki edellä luetellut osa-alueet sellaisessa paketissa, että kaikki osa-alueet täyttävät niille asetetut pakolliset vaatimukset, ovat miellyttäviä käyttää, joustavat asiakkaan tarpeisiin ja tietysti keskustelevat automaattisesti keskenään? Ja vielä siten, että hinta on alhainen? Eipä taida montaa löytyä. Saattaapi käydä niinkin, että yhtään tarjousta ei kolahda postiluukusta. Hyvällä tuurilla tulee tarjous, jossa kaksi tai useampi toimittajaa ovat lyöneet hynttyyt yhteen (siis ko. tarjoukseen) ja tarjoavat joko ryhmittymänä tai alihankintasuhteina koko pakettia. Hinta vaan voi olla vähän suolainen. Saattaapi käydä niin, että yhtään tarjousta ei kolahda postilaatikkoon. Pohditaanpa hetki seuraavia kysymyksiä:
Voidaan edellä olevien kysymysten pohjalta miettiä, onko sopimus rakennettu siten, että siitä on helppo irtisanoa jokin haluttu osio pois? Jos ei, niin joko irtisanotaan koko sopimus, yritetään saada toimittajalta hinnanalennusta tai maksetaan sellaisestakin osa-alueesta, jota ei hyödynnetä lainkaan. Minkä tien valitset? Irtisanotaanko koko sopimus, jos jokin osa-alue halutaan vaihtaa? Tai onko sopimuksen sanktiointi tehty siten, että se on helppo kohdentaa oikeaan paikkaan? Jos esim. jokin yksittäinen osa-alue sakkaa, niin harva toimittaja suostuu sellaisiin sanktioihin, joissa koko järjestelmän maksuista annettaisiin hyvitystä. Etenkin, jos toimitus koostuu usean toimittajan ryhmittymästä tai alihankintasuhteista. En sano, että kokonaisvaltaiset ERP-järjestelmät olisivat täysin kelvottomia ratkaisuja, mutta jos hankinnan kokonaisarvoksi on arvioitu muutama sata tuhatta euroa, on turha kuvitella, että saadaan yhtään kelvollista tai järkevää tarjousta. Jos halutaan (hinta-laatusuhteeltaan) mahdollisimman hyvä ratkaisu eri tarpeisiin, täytyy hankintaa lähteä pilkkomaan pienempiin osiin. Tätä varten on syytä tehdä huolellinen markkinakartoitus / -vuoropuhelu, jolla varmistetaan, mitä osa-alueita eri toimittajilta löytyy ja minkälaisissa kokonaisuuksissa hankinta on järkevää tehdä. Onneksi myös tuleva uusi hankintalaki pakottaa jakamaan hankintaa osiin. Pilkotaan hankinta osiin ja tehdään huolellinen markkinavuoropuhelu. Jos nyt mietit vielä, miten sitten erillisten järjestelmien välillä tieto kulkee, niin ole huoletta! Eri järjestelmät saadaan kytkettyä kyllä oikein toteutetuilla rajapinnoilla yhteen. Ja silloin myös yksittäisten järjestelmien vaihtaminen on helpompaa, kun koko pakettia ei tarvitse räjäyttää auki. Toki tämäkin pitää osata ottaa huomioon jo tarjouspyynnössä ja ratkaisua valittaessa. Ja mielellään hiukan yksityiskohtaisemmalla määrittelyllä, kuin tyyliin "Järjestelmä keskustelee tarvittavilta osin vähintään seuraavien järjestelmien kanssa:...". Jos lähdet hankkimaan valtavaa kokonaisuutta eri järjestelmiä yhdellä tarjouspyynnöllä, on täysin tuuripeliä, minkälaisia tarjouksia saat. Jos lainkaan. Luuletko, että toimittajat odottavat Hilmaa räpläten kieli pitkällä, että juuri sinun tarjouspyyntösi julkaistaan ja taipuvat kaikkeen mahdolliseen, mitä keksit pyytää, jotta saavat tarjota juuri sinulle? Ei, valitettavasti toimittajat(kin) tekevät valintaa, mihin tarjouskilpailuihin on järkevää milloinkin osallistua. Luuletko, että toimittajat odottavat Hilmaa räpläten kieli pitkällä juuri sinun tarjouspyyntöäsi? Tolkun IT-hankinnat – tolkullisten järjestelmähankintojen puolesta! Blogisarjassa pureudutaan järjestelmähankintojen maailmaan ja annetaan vinkkejä, joita noudattamalla onnistut paremmin järjestelmähankinnoissa. Vinkit sopivat yhtä hyvin niin yksityiselle kuin julkisellekin sektorille organisaation kokoon katsomatta.  Miksi järjestelmähankkeissa niin usein aikataulu pettää? Osoittaako syyttävä sormi aina toimittajaa kohti, vai osaatko katsoa myös peiliin? Otapa lyhyt aikalisä ja lukaise ajatuksia sopivan aikataulun merkityksestä hankkeen onnistumiselle. Kuvan lintua ei vahingoitettu tätä kirjoitusta varten. Aikataulutus pettää jo hankintavaiheessa? Liian usein tilanne on se, että järjestelmälle on kova tarve, hankinnalle varattu budjetti painaa vastaan tai jonkin muun erittäin hyvin perustellun syyn vuoksi hankinta viedään läpi mahdollisimman rivakasti. Ja kun kiihdytetään liian kovaa, voi lento loppua kesken ja pahimmassa tapauksessa tulee siinä vähän vahinkoakin. Olen nähnyt lukuisten erityisesti julkisten järjestelmähankintojen menevän pieleen vain sen vuoksi, että hankinnan ja tarjouspyynnön valmistelu ja itse tarjousvaihe vietiin läpi mahdollisimman nopeasti. Koska kiire. Kun kiihdytetään liian rivakasti, voi lento loppua kesken. Haluttiin nopeasti tarjouspyyntö ulos Hilmaan ja tarjoukset pöydälle. Ei ehditty kunnolla perehtyä markkinoilta löytyviin ratkaisuihin ja miettiä omia vaatimuksia tätä kautta realistisiksi. Kaiken lisäksi toimittajille annettiin surkean lyhyt valmistautumisaika tarjouksen laatimiselle, pahimmassa tapauksessa tarjouspyyntö julkaistiin juhannusviikolla ja tarjoukset piti jättää heinäkuun loppuun mennessä. Toimittajan parhaat myyjäthän mielellään keskeyttävät kesälomansa juuri sinun julkaiseman tarjouspyynnön vuoksi? (Sivuhuomautuksena: Ainoa asia, mitä julkisessa hankinnassa kannattaa tehdä juhannusviikolla tai mieluummin heti juhannuksen jälkeen, on hankintapäätöksen lähettäminen silloin, kun riski markkinaoikeuteen päätymiselle on suuri. Toimittajan parhaat asiantuntijat ovat lomalla ja eivät ehkä huomaa koko hankintapäätöstä, jolloin voit päästä kuin koira veräjästä.) Itse tarjousvaiheen lisäksi tarjouspyynnössä saatetaan toimitusajalle asettaa kohtuuttomia vaatimuksia ja samalla viivästyssanktiot sopimuksessa on asetettu varmuuden vuoksi toimittajaa kunnolla kurittaviksi. Fiksut toimittajat vetäytyvät jo tässä vaiheessa hankkeesta, koska eivät halua lähteä hutiloiden valmisteltuun hankkeeseen liian tiukalla aikataululla viivästyssakon uhka niskassaan. Fiksut toimittajat vetäytyvät hankkeesta jo alkuvaiheessa huonon valmistelun vuoksi. Projektillekin on syytä varata väljä aikataulu Mikäli hankintavaihe saatiin vietyä läpi onnistuneesti, ei vielä voida huokaista. Tästähän se työ vasta alkaa. Ja taas usein liian kiireellä. Aikataulut laaditaan ihannetilanteen mukaan, kun kenelläkään ei ole muuta tekemistä tai mitään yllättävää ei tapahdu. Mutta kun tapahtuu! Budjetointi, tilinpäätös, kehityskeskustelut, kuluvan vuoden tavoitteen asetanta. Löytyykö kalenteristasi kolmen-neljän kuukauden rako, jolloin siellä ei olisi jotain joka vuosi toistuvaa isoa rumbaa? Niinpä. Lisäksi erilaisissa järjestelmäkäyttöönotoissa tulee vastaan erilaisia haasteita. HR-järjestelmäprojekteissa jätetään usein varautumatta riittävästi nykyisten tietojen keräämiseen ja sen vaatimaan aikatauluun. Kuvitellaan ehkä, että järjestelmätoimittajalla on jotkin maagiset työkalut, joiden avulla nykyisen henkilöstön tiedot imuroidaan asiakkaan vanhasta järjestelmästä, exceleistä ja mapeista uuteen hienoon HR-järjestelmään. Tosiasia on, että käytännössä aina tietoa joutuu joko keräämään manuaalisesti tai sitten loppukäyttäjät, esim. jokainen työntekijä itse, syöttävät osan tiedoista järjestelmään. Budjetointi, tilinpäätös, kehityskeskustelut, tavoitteen asetanta. Yritäpä siinä löytää sopiva rako käyttöönotolle! Julkaisujärjestelmien käyttöönottoaikataulut kulkevat kokonaan omassa luokassaan. Olen ollut lukuisissa rekrytointijärjestelmähankkeissa mukana, jolloin samaan aikaan sattumalta, tai suunnitellusti, on ollut menossa julkaisujärjestelmän uudistus. Suunnitelma oli, että kun uudet nettisivut valmistuvat, otetaan samalla sitten käyttöön uusi hieno rekryjärjestelmä. Olen oppinut vastaamaan asiakkaalle, että eiköhän jo varauduta plan B:hen, eli otetaan uusi rekryjärjestelmä käyttöön vanhalla sivustolla. Julkaisujärjestelmäprojekti saattoi kyllä teknisesti valmistua suunnitellussa aikataulussa, mutta jostain kumman syystä sisällön tuottaminen sinne vähän viivästyi. Plan B on aina hyvä olla. Siispä, kun olet hankkimassa uutta järjestelmää, riittävän väljä aikataulu on viimeinen, josta voit lähteä tinkimään. Ei ole turhauttavampaa tilannetta, kuin kiireessä viedä hankinta läpi ja huomata, että ei tästä mitään tullutkaan. Sitten käynnistetään hankinta uudelleen, parhaassa tapauksessa toimittajia syytellen, kun eivät kelvottomat edes viitsineet tarjousta tehdä! Tässä kohtaa on siis syytä katsoa peiliin, huokaista, nostaa oikea käsi etusormi ojossa vaakasuoraan ja osoittaa syyllistä. Sen jälkeen kääriä hihat, aloittaa alusta ja valmistella hanke kaikin puolin huolellisemmin. Tolkullisen aikataulun (ja muiden vaatimusten) kanssa. Eivät kelvottomat edes tarjousta tehneet! Tolkun IT-hankinnat – tolkullisten järjestelmähankintojen puolesta! Blogisarjassa pureudutaan järjestelmähankintojen maailmaan ja annetaan vinkkejä, joita noudattamalla onnistut paremmin järjestelmähankinnoissa. Vinkit sopivat yhtä hyvin niin yksityiselle kuin julkisellekin sektorille organisaation kokoon katsomatta.  Ohjelmistoyrittäjät ry tutki vuonna 2013 yhdessä Celkee Oy:n ja Tietotekniikan liitto ry:n kanssa tietojärjestelmien hankintaa. Tutkimuksen mukaan tilaajien mielestä hankinnan kunnollinen resursointi ja valmistelu ovat tärkein tekijä järjestelmähankkeen onnistumiselle. Tämä on helppo allekirjoittaa. Usein käy niin, että kun hankkeelle ei ole osoitettu riittäviä resursseja, koko hanke ei lähde käyntiin. Toimitaan huonoilla järjestelmillä tai ilman järjestelmiä ja halua olisi uudistaa, mutta hanke ei pyörähdä käyntiin, kun kukaan ei ehdi. Vanha totuus kuvaa tätä hyvin, eli juostaan moottoritien laitaa samalla kun autot sujahtavat ohitse, mutta ei ehditä pysähtyä, jotta voitaisiin nousta kyytiin. Ilman riittäviä resursseja hanke ei lähde edes käyntiin. Kun vihdoin sitten kypsytään riittävästi tilanteeseen, lykätään vastuu jollekin ja sanotaan, että nyt täytyy saada tämä asia kuntoon. Ongelmaksi muodostuu silti usein se, että edelleenkään hankkeelle ei ole saatu riittävästi resursseja. Esimerkiksi HR-päällikköraukka joutuu YT-kierrosten puristuksessa vielä hankkimaan uuden HR-järjestelmän (jos nyt saa siihen ylipäänsä rahaa). Tässä kohtaa onkin syytä miettiä, onko talossa sellaista osaamista, jonka avulla koko hanke voidaan viedä läpi? Jos tällaista osaamista löydetään, täytyy näille henkilöille varata riittävästi aikaa hankkeen ajaksi. Ei voida olettaa, että kukaan pystyy muiden töidensä ohella viemään vaativan järjestelmähankkeen läpi. Toisaalta, ei pidä lastata koko projektia myöskään yksille harteille. Hyvä olisi olla backupia esimerkiksi sairastumisten tai muiden tilanteiden varalle, jotta projekti ei jää seisomaan. Mitä osaamista sitten tarvitaan? Kaikista tärkeintä on ymmärtää, mihin tarpeisiin ja mitä ollaan hankkimassa. Nykyisessä pilvipalveluiden maailmassa esim. teknisen osaamisen merkitys ei ole niin suuri. Monia järjestelmähankkeita voidaan viedä läpi jopa täysin ilman tietohallinnon osallistumista. Mikäli tarvitaan rajapintoja tilaajan muihin järjestelmiin (esim. AD tai IDM) ja näiden ylläpito on tietohallinnon vastuulla, tarvitaan toki IT-osastokin mukaan. Tärkeimpänä siis substanssiosaaminen siltä alueelta, mille järjestelmää ollaan hankkimassa, esim. HR:stä, myynnistä, tuotannonohjauksesta, jotta järjestelmälle osataan asettaa oikein mitoitetut vaatimukset ja projektin aikana myös uudistaa ja kuvata prosesseja. Hankintaosaamisesta on toki hyötyä, eikä muutoksenhallinnanosaaminenkaan olisi haitaksi. Sitä tarvitaan koko hankkeen läpiviennissä, mutta erityisesti jalkautuksessa. Hienointa olisi, jos talossa olisi henkilöitä, joilla on sekä osaamista että kokemusta kaikilta em. osa-alueilta. Tärkeintä on ymmärtää, mihin tarpeisiin ja mitä ollaan hankkimassa. Osaamisen ja resurssien lisäksi kaikille järjestelmille pitäisi pystyä osoittamaan ns. omistaja. Henkilö, joka viime kädessä vastaa siitä, että hankkeen tavoitteet toteutuvat, liiketoiminnan tarpeet saadaan täytettyä ja järjestelmä saadaan jalkautettua organisaatioon. Henkilö on usein myös tilaajan projektipäällikkö. Hankkeessa hän on joka tapauksessa avainroolissa. Hänellä pitäisi olla valtaa tehdä tarvittavia pienpäätöksiä projektin aikana, jotta projekti ei turhaan seiso pienen muutospyynnön hyväksynnän vuoksi. Hulluinta on se, jos jokaisesta pienestä muutospyynnöstä joudutaan kysymään lupa ylemmältä taholta. Olen usein katsonut, kun puolen tunnin lisätyöstä on lähtenyt tilaajan päässä hyväksyntäkierros käyntiin. Pelkästään tähän liittyvästä viestinnästä on tullut suurempi kulu ja toimittajan(kin) kannalta olisi ollut järkevintä alun perin tehdä ko. muutostyö veloituksetta. Hankkeen omistajalla pitää olla valta tehdä päätöksiä. Oikeilla resursseilla saat todellakin tolkullisen suunnan koko hankkeelle. Ja muista, että vähemmän on enemmän. Ei ole mitään järkeä haalia jokaiseen määrittelytyöpajaan 10 henkeä eri puolilta organisaatiota. Palaverin ajasta menee puolet siihen, kun kinastellaan täysin merkityksettömistä asioista. Ja ennen palaveria odotetaan kaikki paikalle, sähköpostin luku- ja muista tauoista puhumattakaan. Ei siis tuhlata kaikkien aikaa, vaan otetaan mukaan sellaiset henkilöt, joilla oikeasti on merkitystä (ja osaamista ko. asiaan). Mikäli huomaat, että sisäiset resurssit ovat liian ohuet hankkeelle, selvitä ulkoisten resurssien käyttömahdollisuudet ja hyödynnä niitä. PS. kirjoituksen alussa viitattuun tutkimukseen pääset tutustumaan täällä. Tolkun IT-hankinnat – tolkullisten järjestelmähankintojen puolesta! Blogisarjassa pureudutaan järjestelmähankintojen maailmaan ja annetaan vinkkejä, joita noudattamalla onnistut paremmin järjestelmähankinnoissa. Vinkit sopivat yhtä hyvin niin yksityiselle kuin julkisellekin sektorille organisaation kokoon katsomatta.  Oletko kuullut joskus onnistuneesta järjestelmähankinnasta? No kyllä, onhan niitä onnistuneitakin hankintoja. Paljonkin. Jostain syystä kuitenkin jatkuvasti puhutaan epäonnistuneista hankinnoista, rahan heittämisestä pohjattomaan kaivoon ja niin poispäin. Erityisesti julkisen sektorin hankinnat herättävät tunteita, onhan kyse enemmän tai vähemmän yhteisestä lompakosta, josta raha näihin hankkeisiin kaivetaan (vertauskuvana toimisi kyllä usein säkki, josta kaadetaan). Yksityisen sektorin epäonnistuneet hankkeet eivät yleensä saa niin paljon huomiota, ellei kyse ole esimerkiksi asiakaspalveluun suoraan vaikuttavasta hankkeesta, jossa epäonnistuneen järjestelmäprojektin vuoksi vaikkapa lipunvarausprosessi menee täysin jumiin. Miksi järjestelmähankinnat sitten niin usein epäonnistuvat joko osittain tai kokonaan? Tähän lienee useita syitä ja kaikkeen ei pysty edes ennalta varautumaan, kuten olosuhteiden yllättävään muuttumiseen kesken hankkeen. Kuitenkin, hieman paremmalla valmistautumisella, käyttämällä hieman aikaa koko hankkeen suunnitteluun ja miettimällä, mitä osaamista tarvitaan ja millä tavalla eri vaiheet voitaisiin hallita paremmin, voidaan hankinnan laatua parantaa merkittävästi. Samalla työmäärä ja kustannukset jäävät todennäköisesti pienemmiksi. Epäonnistumisella on myös useita mittareita / tasoja. Jonkun mielestä hanke on onnistunut, jos projekti saatiin aikataulussaan läpi. Toisen mielestä, jos budjetti piti. Kirjoitinkin jo aiemmin järjestelmien vajaakäytöstä. Yksi epäonnistumisen laji sekin. Paremmalla valmistautumisella voidaan hankinnan laatua parantaa merkittävästi. Toimin itse ennen nykyistä työtäni lähes 15 vuotta järjestelmätoimittajan roolissa ja näin lukuisia hankintoja, joissa asiakas oli enemmän tai vähemmän hukassa tekemisessään. Myyntityössä ja toimittajan roolissa hankintaa ja tarjouspyyntöä katsoo hieman eri lasit päässä, kuin asiakas. Asiakkaan pitäisikin osata asettua myös myyjän eli järjestelmätoimittajan asemaan, jotta osaisi viedä hankinnan läpi mahdollisimman hyvin ja realistisesti. Haastehan tietysti on, että harvalla ostajalla on valtavaa (jos yhtään) kokemusta toimittajan roolista. Ja huom! en tarkoita sitä, että ostetaan vain juuri sitä, mitä markkinoilla on valmiina tai että pitäisi mukautua toimittajan asettamiin ehtoihin. Järjestelmähankinnassa, kuten yllättäen aika monessa muussakin tekemisessämme, on kuitenkin lopulta kyse viestinnästä. Miten viestiä oikealla tavalla toimittajille, mitä ollaan tekemässä ja mitä toimittajalta sekä ratkaisulta odotetaan? Hankkeen kaikissa vaiheissa. Asiakkaan pitäisi osata asettua järjestelmätoimittajan asemaan. Täytyy sanoa, että välillä suorastaan vihastuttaa, kun näkee järjestelmähankkeita, joissa ilmiselvästi ei ole mitään tolkkua, eikä ostaja ole tilanteen tasalla. Tämä on muuten mielenkiintoinen sana, tämä ”tolkuttaa”. Joku sivistyssanakirjakin taitaa määritellä sen jankuttamiseksi tai jopa nalkuttamiseksi. Itse pidän sanaa erittäin sopivana silloin, kun jokin hanke yritetään saada raiteilleen asiaperustein. Jos ei kerrasta mene jakeluun, niin pitää tolkuttaa. Tolkuttaminen on paikallaan silloin, kun hanke yritetään saada raiteilleen asiaperustein. Lähdin kirjoittamaan näitä artikkeleita sillä ajatuksella, että pureudun pala kerrallaan järjestelmähankinnan eri vaiheisiin ja erityispiirteisiin sekä miten niihin olisi hyvä varautua. Saatanpa jossakin osassa pureutua johonkin erityisaiheeseen, vaikkapa HR-järjestelmiin. Hankinnalla muuten käsitän tässä yhteydessä koko hankkeen elinkaaren. Hankinta ei ole valmis vielä siinä vaiheessa, kun sopimuksessa on nimi, vaan vasta sitten, kun se on onnistuneesti jalkautettu organisaatioon ja toimintatavat samalla uudistettu. Hankinta on valmis vasta sitten, kun se on onnistuneesti jalkautettu organisaatioon. Tolkku alkaa siitä, kun tunnistat, että jotain voisi tehdä paremmin ja otat asiaksesi tehdä. Pysy siis kuulolla! Tolkun IT-hankinnat – tolkullisten järjestelmähankintojen puolesta! Blogisarjassa pureudutaan järjestelmähankintojen maailmaan ja annetaan vinkkejä, joita noudattamalla onnistut paremmin järjestelmähankinnoissa. Vinkit sopivat yhtä hyvin niin yksityiselle kuin julkisellekin sektorille organisaation kokoon katsomatta.  Kuulin erään asiantuntijaorganisaation HR-järjestelmän käyttöasteesta. Uusi järjestelmä hankittiin pari-kolme vuotta sitten ja sen piti kattaa laajasti työsuhteen elinkaaren hallinta lähtien rekrytoinnista uuden työntekijän tietojen perustamiseen, perehdytykseen, työntekijän osaamisen kehittämiseen ja päättyen lopulta työsuhteen päättämisen toimenpiteisiin. Olin silloin itsekin tarjoamassa asiakkaalle ratkaisua, mutta se rankattiin heti alkumetreillä pois, koska ratkaisussa ei ollut mukana palkanlaskentaa ja asiakas näki ehdottomana, että palkanlaskentaosio pitää olla samalta toimittajalta. Tilanne on tällä hetkellä se, että HR-järjestelmä on käytössä kyllä aktiivisesti palkanlaskennassa ja palkanlaskijat ovat siihen oikein tyytyväisiä. HR-järjestelmää käyttää vain muutama esimies. Paha vaan, että palkanlaskijat ovat lähes ainoa käyttäjäryhmä, joka HR-järjestelmää tällä hetkellä käyttää. Organisaatiossa on lähes 1 000 työntekijää ja järjestelmää käyttää työsuhteen elinkaaren hallintaan ainoastaan muutama esimies. En tietenkään voi ko. organisaation puolesta sanoa, miksi tilanne on tämä, mutta uskaltaisin veikata syyksi yhtä tai useampaa seuraavista:
Kissaa ei uskalleta nostaa pöydälle ja peruuttaa hankkeessa. On jotenkin erikoista, että tänä päivänä kun puhutaan paljon digitalisaatiosta, digiloikasta, tuottavuudesta, ketterästä HR:stä ja muusta organisaation toimintaa lähtökohtaisesti tehostavasta, tehdään samaan aikaan todella huonoja järjestelmähankintoja, jotka tuottavuudeltaan ovat pahimmillaan negatiivisia. Pahinta lienee se, että vaikka projektin aikana huomattaisiin, että ratkaisu ei ehkä olekaan toimiva, vaan suurin osa tavoitteista jää saavuttamatta, kissaa ei uskalleta nostaa pöydälle ja kyseenalaistaa etenemistä. Luonnollista tietenkin, koska jos itse on perusteltu kyseisen järjestelmän hankinta, olisi kovin uskaliasta kritisoida tätä päätöstä. Sekin on hyvä huomata, että vaikka tilanne näyttäisi nyt siltä, että on tehty väärä hankinta eikä tästä tule mitään, ei se välttämättä tarkoita, että projekti pitäisi keskeyttää. Aina voi parantaa suoritusta ja suunnitella esim. jalkautuksen paremmin. Tai tehdä tilanteen uudelleen arvioinnin ja korjata muuten suuntaa. Nostetaan kissa pöydälle, ennen kuin on myöhäistä! Tiedätkö organisaation, jossa järjestelmähanke uhkaa mennä puihin jollakin edelläkuvatulla tai muulla tavalla? Ilmianna itsesi tai tuntemasi organisaatio, niin nostetaan kissa pöydälle, ennen kuin on myöhäistä!
Sekä yksityisen että julkisen sektorin IT-sopimusehdot on uudistettu. Tässä lyhyt yhteenveto ja muutamia huomioita muutoksista.
IT2015 Merkittävimmät uudistukset liittyvät ketterillä menetelmillä tehtäviin toimituksiin, joihin luotiin kokonaan uudet ehdot (IT2015 EKT). Nyt näihin toimituksiin voidaan hyödyntää valmiita sopimusehtoja ja itse sopimusteksteistä saadaan selkeämpiä. Toki aina täytyy katsoa tapauskohtaisesti sopimusehtojen soveltuvuus hankkeeseen ja tarvittaessa tehdä muutoksia / poikkeuksia yleisiin sopimusehtoihin. Toisena kokonaan uutena asiana on tuotu malli eettisten periaatteiden toteuttamiseksi hankkeissa. Tämä malli ei tosin sellaisenaan sovi sopimusliitteeksi, vaan se toimii ensisijaisesti apuna eettisten periaatteiden tuonnissa organisaatioon ja kun organisaatioon on saatu tuotua ja ymmärrettyä nämä periaatteet, ne voidaan tarvittaessa tuoda sopivalla tavalla myös sopimuksiin. Pilvipalveluehtoihin on myös tehty merkittäviä lisäyksiä erityisesti tietoturvaan ja tietojen suojaamiseen liittyen sekä näihin liittyen tietoturvaloukkausten käsittelyyn. Lisäykset täsmentävät periaatteita, joilla tietoja pitää suojata. Erityisesti henkilötietoja sisältävien järjestelmien kohdalla on syytä kiinnittää huomiota, että tietojen suojaus on hoidettu huolella ja että tämä on myös sopimustasolla velvoitettu järjestelmää ylläpitävälle taholle. Edellä mainittujen muutosten lisäksi sopimusehtojen käytettävyyttä on parannettu, mm. ulkoasullisilla muutoksilla sekä mallipohjien tuonnilla docx-muotoon. Tutustu uudistettuihin IT2015-ehtoihin osoitteessa it-ehdot.fi JIT2015 Tärkeimpänä uudistuksena näen vihdoin julkisiin IT-hankintoihin saadut pilvipalveluehdot, eli virallisesti "Erityisehtoja tietoverkon välityksellä toimitettavista palveluista". Kun pilvipalvelut eri aloilla yhä enemmän lyövät läpi ja tähän saakka julkiset hankkijat ovat joko tehneet omat sopimusehdot tai joissakin tapauksissa käyttäneet IT2010-ehtoja, nyt voidaan poimia ehdot suoraan JHS-suosituksista. Pilvipalveluehtojen lisäksi JIT2015 -ehtoihin saatiin IT2015 -ehtojen tapaan sopimusehdot ketterillä menetelmillä toteutettaviin hankkeisiin, joka on erinomainen ja tärkeä uudistus myös julkiselle puolelle. Ketterät menetelmät tulevat jatkossa näyttelemään entistä tärkeämpää roolia järjestelmähankkeissa ja näiden ehtojen myötä uskon, että julkinenkin sektori saa vihdoin ketteristä langanpäistä kiinni toden teolla. Lisäksi merkittävä muutos on, että tilaajan sovellushankinnat on jaettu kahteen osaan, eli avoimella lähdekoodilla tai muulla kuin avoimella lähdekoodilla toimitettaviin sovelluksiin. Tämä muutos selventää ehtojen käyttöä ja sopimuksiin ei tarvita niin paljon ehtojen poikkeamia tai tarkennuksia. Yleisenä muutoksena kaikkiin ehtoihin on, että sopimusehtojen käyttöohjeet löytyvät nyt tapauskohtaisesti kunkin sopimusehdon alusta. Lisäksi eri ehtoihin on tehty enemmän tai vähemmän pieniä muutoksia, joihin on hyvä perehtyä tarkemmin! Tutustu uudistettuihin JIT2015-ehtoihin osoitteessa www.jhs-suositukset.fi/web/guest/jhs/recommendations/166 Miten uusia IT2015 / JIT2015 -ehtoja käytetään?Sopimusehtojen käytön tärkein edellytys on, että ne tunnetaan sisällöltään hyvin ja niitä käytetään oikein. Ei ole mielekästä varmuuden vuoksi liittää kaikkia mahdollisia sopimusehtoja sopimukseen ja sen lisäksi vielä varmuuden vuoksi lisätä sopimukseen samoja asioita. Toisaalta tapauskohtaisesti täytyy tunnistaa, miltä osin sopimusehdot eivät sovi hankkeeseen ja tehdä näihin liittyen tarvittavat täsmennykset. Oikein käytettynä IT2015 / JIT2015 -ehtojen avulla saadaan hyvin selkeitä ja lyhyitä sopimuksia, jonka ansiosta myös sopimusten laadunvarmistus on helppoa. Esimerkiksi yrityskauppojen ja muiden liiketoimintakauppojen yhteydessä tehtävien Due Diligence -selvitysten teko on erittäin helppoa sopimusten osalta, mikäli sopimuksissa on tukeuduttu valmiisiin sopimusehtoihin eikä jokaisessa sopimuksessa ole sovittu erikseen erilaisista ehdoista. Valmiiden sopimusehtojen käyttö on myös osa toiminnan laadunvarmistusta ja niitä onkin hyvä käyttää myös prosessien läpikäynnissä ja kehittämisessä. Lopultahan sopimusehtojen toteutuminen on mahdollista vain, jos organisaatio toimii niiden mukaisesti. Olemme perehtyneet uusiin IT2015- ja JIT2015 -sopimusehtoihin, jonka lisäksi käymme eri hankkeissa aina käytännön tasolla tapauskohtaisesti läpi soveltuvimmat ehdot ja mahdolliset poikkeamistarpeet. Ole yhteydessä, mikäli ehtojen käytöstä herää kysymyksiä! |
Palvelut |
KokemuksiaArtikkelitMeistäYhteys |
"Facilorin tuottama palvelu oli erittäin osaavaa, heillä on hyvä ymmärrys julkisten hankintojen toteuttamisesta ja todella vahva substanssi erityisesti HR-järjestelmien osalta."
Antti Nummiranta - Seure Henkilöstöpalvelut Oy |
Tutustu tietosuojakäytäntöömme: https://www.facilor.fi/tietosuojaseloste.html
© COPYRIGHT FACILOR OY 2020
© COPYRIGHT FACILOR OY 2020