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. |
Arkisto
February 2021
Kategoria
All
|