Tämä teksti on tarkoitettu hallituksille ja henkilöille, jotka allekirjoittavat järjestelmähankinnan: virastossa sekretarzille (kunnan- tai piirikunnansihteeri) ja skarbnikille (kunnan talousjohtaja), kunnallisen yhtiön toimitusjohtajalle, talousjohtajalle, yrityksen omistajalle. Myös IT-päällikölle, joka valmistelee kilpailutusta tai tarjouspyyntöä ja haluaa tietää, mihin hallituksen tulisi kiinnittää huomiota ennen asiakirjojen hyväksymistä.
Miksi tämä ongelma syntyy
Suurin osa toimittajaongelmista juontuu tilaajan puolelta, ja jo kauan ennen allekirjoitusta. Ei pahasta tahdosta: hankinnan valmistelu on työtä, johon organisaatiossa harvoin on aikaa ja osaamista, ja toimittajat auttavat siinä mielellään. He tuovat mukanaan valmiit kuvaukset, esittelyt ja hinnoittelut. Tuloksena tilaaja ostaa sen, mitä toimittaja osaa myydä, ei sitä, mitä se tarvitsee. Ongelmana on myös se, että hankintapäätökset jäävät hyvin usein asiasisällöstä vastaavien yksiköiden käsiin, ja IT toimii vain turvallisuuden vartijana. Standardien ja pitkän aikavälin IT-strategian puuttuminen johtaa siihen, että organisaatio tekee hankintoja, jotka eivät aina sovi kehykseen, jonka tarkoitus on hallita riskejä.
Näen samat virheet virastoissa ja yrityksissä. Niitä erottaa hankintamenettely, ei itse mekanismi.
Kaksitoista virhettä
- Vaatimukset kirjoitettu yhden toimittajan tarjouksen tai esittelyn pohjalta. Se rajoittaa kilpailua ja lukitsee riippuvuuden jo ennen toimittajan valintaa. Käsittelen tätä laajemmin tekstissä toimittajariippuvuudesta SWZ:ssä (SWZ, Puolan hankintalain mukainen tarjouspyyntöasiakirja).
- Liiketoiminnasta vastaavan omistajan puuttuminen. Projektilla on muodollisesti vastuuhenkilö, mutta kukaan hallituksen mandaatilla varustettu ei päätä, miten prosessien tulee toimia.
- Vastaanottokriteerien ja testiskenaarioiden puuttuminen ennen allekirjoitusta. Vastaanotosta tulee tulkintariita sen sijaan, että tarkistettaisiin, täyttääkö projektin tuotos käyttöönoton onnistumisen kriteerit.
- Tietämättömyys nykytilasta. Ostatte uutta järjestelmää tietämättä, mitkä nykyiset sopimukset, lisenssit ja toiminnot menevät sen kanssa päällekkäin.
- Unohdetut integraatiot. Minkä järjestelmien kanssa uuden järjestelmän pitää vaihtaa tietoa, mihin suuntiin, mitkä järjestelmät ovat ensisijaisia, mitä tietoja, mitä formaatteja käyttäen, ja tietääkö toimittaja tästä sekä takaako se tarvittavien mekanismien toimittamisen ja ottaa vastuun niiden jatkuvasta toiminnasta.
- Datamigraatio kuvattu yhdellä lauseella. Ilman sopimusta siitä, mitkä tiedot, miltä ajanjaksolta, kuka ne puhdistaa ja kuka tarkistaa lopputuloksen.
- Vaatimukset toimintolistana prosessikuvausten sijaan. Jokainen toimittaja vastaa "kyllä" kysymykseen toiminnosta. Kysymykseen siitä, miten se hoitaa teidän konkreettisen tapauksenne, vastaukset vaihtelevat.
- Aloitushinnan vertailu kokonaiskustannuksen sijaan. Lisenssi on vasta alku. Ylläpidosta, muutoksista ja integraatioista maksetaan vuosia. Tästä mekanismista kirjoitan tekstissä kokonaisomistuskustannuksesta (TCO) ja sammakon keittämisestä.
- Laajuuden muutosten sääntöjen puuttuminen. Ei ole selvää, kuka esittää muutoksen, kuka hinnoittelee sen ja kuka hyväksyy sen.
- Sopimus ilman irtautumisehtoja. Ei sovittu tietojen viennistä, dokumentaatiosta eikä ylläpidon siirtämisestä toiselle toimijalle. Riskienhallintakeinot puuttuvat.
- Ylläpitosopimus hyväksytty toimittajan valmiin mallin mukaisena. Palvelutasot, reagointiajat ja muutosten hinnat määrittää tällöin yksi osapuoli.
- Päätös lykätty viime hetkeen. Kun lakisääteinen määräaika tai vanhan järjestelmän tuen loppuminen on lähellä, tarjousten vertailulle tai neuvotteluille ei enää ole tilaa.
Virheet yhdestä kolmeen ovat juurisyitä. Jos poistatte ne, suurin osa muista tulee näkyviin valmisteluvaiheessa eikä vasta toteutuksessa.
Valtuustolle, hallintoneuvostolle tai keskushallinnolle tärkeintä on, onko toimittajan valintapäätökselle dokumentoitu perustelu. Yllä olevat kaksitoista kohtaa muodostavat samalla listan kysymyksiä, jotka kannattaa esittää ennen kuin hallitus hyväksyy hankinta-asiakirjat.
Esimerkki käytännöstä
Yksi asiakkaistamme sai ERP-järjestelmän toimittajalta tiedon, että kumppanitietoja voidaan ilman ongelmia vaihtaa käyttöönotettavan kirjeenvaihdon hallintajärjestelmän (EZD, sähköinen asiakirjojen- ja asiankäsittelyjärjestelmä / e-Doręczenia, Puolan sähköinen asiointipalvelu) kanssa. Kirjeenvaihdon hallintajärjestelmä säilyttää yleensä kaikkien kumppaneiden tiedot, ei vain niiden, joiden kanssa syntyy liiketoimintatapahtumia eli joista tulee asiakkaita tai toimittajia. Uuden kumppanin tietojen elinkaari alkaa yksinkertaisesti useimmiten paljon aikaisemmin kuin liiketoimintatapahtumat.
Käyttöönoton aikana kävi ilmi, että ERP-toimittajan puolella API-rajapinnan mukauttaminen kaksisuuntaiseen kumppanitietojen vaihtoon maksoi 80 % koko sen projektin arvosta, jossa toteutettiin kuluasiakirjojen käsittely integroituna KSeF:ään (KSeF, Puolan kansallinen sähköisen laskutuksen järjestelmä), OCR:ään, WIES:iin, GUS:iin (Puolan tilastokeskus) ja lopulta talous- ja kirjanpitojärjestelmään vietäviin tietoihin. Tämä yksi integraatio, jota ei alussa käyty tarkasti läpi toimittajan kanssa, käytännössä kaksinkertaisti projektin kustannukset.
Milloin tarvitaan riippumaton neuvonantaja
Jos teillä on kokenut tiimi, joka on jo valmistellut useita samankaltaisia hankintoja, tämä lista toimii tarkistuslistana. Riippumaton näkemys on hyödyllinen, kun hankinta on organisaation mittakaavassa suuri, kun vaatimukset ovat syntyneet yhteydenpidossa yhden toimittajan kanssa, kun päätös pitää pystyä perustelemaan tarkastukselle, valtuustolle tai pääkonttorille, tai kun kukaan tilaajan puolella ei tunne näitä järjestelmiä sisältäpäin.
Voin lukea asiakirjat läpi ennen kilpailutuksen julkaisemista tai tarjouspyynnön lähettämistä, laatia vaatimukset ja testiskenaariot tai arvioida jo jätetyt tarjoukset. Virastoissa lähtökohta näyttää hieman erilaiselta, ja kuvaan sen sivulla paikallishallinnon yksiköille (JST).