Tämä teksti on tarkoitettu johtoryhmille ja henkilöille, jotka allekirjoittavat järjestelmähankinnan: kunnan tai piirikunnan sekretarzille (sekretarz) ja skarbnikille (treasurer), kunnallisen yhtiön (spółka komunalna) toimitusjohtajalle, talousjohtajalle sekä yrityksen omistajalle. Myös IT-päällikölle, joka valmistelee kilpailutusta tai tarjouspyyntöä ja haluaa tietää, mihin johdon tulisi kiinnittää huomiota ennen asiakirjojen hyväksymistä.
Miksi tämä ongelma syntyy
Suurin osa toimittajaongelmista juontuu tilaajan puolelta, ja se tapahtuu kauan ennen sopimuksen allekirjoittamista. Kyse ei ole pahasta tahdosta: hankinnan valmistelu on työtä, johon organisaatiolla on harvoin aikaa ja osaamista, ja toimittajat auttavat siinä mielellään. Ne tuovat valmiit kuvaukset, esittelyt ja tarjoukset. Lopputuloksena tilaaja ostaa sen, mitä toimittaja osaa myydä, ei sitä, mitä se todella 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:n rooliksi jää ainoastaan tietoturvan vartiointi. Standardien ja pitkän aikavälin IT-strategian puuttuminen johtaa siihen, että organisaatio tekee hankintoja, jotka eivät aina sovi kehikkoon, jonka tehtävänä on riskien hallinta.
Näen samat virheet sekä virastoissa että yrityksissä. Niitä erottaa hankintamenettely, ei itse mekanismi.
Kaksitoista virhettä
- Vaatimukset on kirjoitettu yhden toimittajan tarjouksen tai esittelyn pohjalta. Tämä rajoittaa kilpailua ja vakiinnuttaa riippuvuuden jo ennen kuin olette edes valinneet toteuttajan. Olen käsitellyt tätä laajemmin tekstissä toimittajariippuvuudesta tarjouspyynnössä (SWZ).
- Liiketoiminnan omistajan puuttuminen. Projektilla on muodollisesti vetäjä, mutta kukaan, jolla on johdon mandaatti, ei päätä, miten prosessien tulee toimia.
- Vastaanottokriteerien ja testiskenaarioiden puuttuminen ennen allekirjoitusta. Vastaanotosta tulee kiista tulkinnasta sen sijaan, että tarkistettaisiin, täyttääkö projektin tuotos käyttöönoton onnistumiskriteerit.
- Tietämättömyys siitä, mitä jo on olemassa. Ostatte uuden järjestelmän 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 tulee vaihtaa tietoa, mihin suuntiin, millä järjestelmillä on ylempi rooli, mitä tietoja, missä muodoissa, sekä tietääkö toimittaja tästä ja vakuuttaako se toimittavansa tarvittavat mekanismit ja ottavansa vastuun niiden toiminnan jatkuvuudesta.
- Datan migraatio kuvattuna yhdellä lauseella. Ilman sopimusta siitä, mitkä tiedot, miltä ajanjaksolta, kuka ne puhdistaa ja kuka tarkistaa lopputuloksen.
- Vaatimukset toimintoluettelona prosessikuvausten sijaan. Jokainen toimittaja vastaa kysymykseen toiminnosta "kyllä". Kysymykseen siitä, miten se hoitaa teidän konkreettisen tapauksenne, vastaukset vaihtelevat.
- Aloitushinnan vertailu kokonaiskustannusten sijaan. Lisenssi on vasta alkua. Ylläpidosta, muutoksista ja integraatioista maksetaan vuosia. Tästä mekanismista kirjoitan tekstissä kokonaiskustannuksista (TCO) ja sammakon keittämisestä.
- Laajuuden muutossääntöjen puuttuminen. Ei tiedetä, kuka ilmoittaa muutoksesta, kuka hinnoittelee sen ja kuka hyväksyy sen.
- Sopimus ilman irtautumisehtoja. Ei ole määräyksiä datan viennistä, dokumentaatiosta eikä ylläpidon siirtämisestä toiselle toimijalle. Riskien hallintakeinot puuttuvat.
- Ylläpitosopimus hyväksytty toimittajan mallipohjalta. Tällöin yksi osapuoli määrittää palvelutasot, reagointiajat ja muutosten kustannukset.
- Päätöksen lykkääminen viime hetkeen ennen määräaikaa. Kun lakisääteinen määräaika tai vanhan järjestelmän tuen päättyminen lähestyy, tarjousten vertailulle ja neuvotteluille ei enää jää 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 se, onko toimittajan valintapäätöksellä dokumentoitu perustelu. Yllä olevat kaksitoista kohtaa muodostavat samalla listan kysymyksiä, jotka kannattaa esittää, ennen kuin johto hyväksyy hankinta-asiakirjat.
Esimerkki käytännöstä
Eräs asiakkaistamme sai ERP-järjestelmän toimittajalta tiedon, että kumppanitietojen vaihtaminen käyttöönotettavan kirjeenvaihdon hallintajärjestelmän (EZD, Puolan asiakirjahallintajärjestelmä, ja e-Doręczenia, Puolan sähköinen tiedoksianto) kanssa onnistuu ongelmitta. Kirjeenvaihdon hallintajärjestelmä tallentaa yleensä kaikkien kumppaneiden tiedot, ei ainoastaan niiden, joiden kohdalla syntyy liiketapahtumia eli joista tulee asiakkaita tai toimittajia. Uuden kumppanin tietojen elinkaari alkaa yksinkertaisesti useimmiten paljon ennen kuin liiketapahtumia syntyy.
Käyttöönoton aikana kävi ilmi, että ERP-järjestelmän toimittajan puolella API-rajapinnan mukauttaminen kumppanitietojen kaksisuuntaiseen vaihtoon maksoi 80 % koko sen projektin arvosta, jossa otettiin käyttöön kuluasiakirjojen käsittelyjärjestelmä integroituna KSeF:iin (Puolan sähköinen laskutusjärjestelmä), OCR:ään, VIES-järjestelmään, GUS:iin (Puolan tilastovirasto) ja lopuksi talous- ja kirjanpitojärjestelmään vietäviin tietoihin. Tämä yksi integraatio, jota ei käyty aluksi 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 vastaavia hankintoja, tämä lista toimii tarkistuslistana. Riippumaton näkökulma on hyödyllinen, kun hankinta on organisaation mittakaavassa suuri, kun vaatimukset on laadittu yhteistyössä yhden toimittajan kanssa, kun päätös on puolustettava tarkastukselle, valtuustolle tai keskushallinnolle, 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 tarjoukset, jotka on jo jätetty. Virastoissa lähtökohta näyttää hieman erilaiselta, kuvaan sen sivulla paikallishallinnon yksiköille (JST).