Toiminnanohjausjärjestelmän hankinnan perustavanlaatuinen ongelma on se, että tarkennettu määrittely on samalla sopimus, millainen järjestelmä sovitulla rahalla tulee.
Normaali järjestelmäprojekti alkaa yrityksen tekemällä määrittelyllä.
Tämän jälkeen yritys kilpailuttaa ja valitsee järjestelmätoimittajan.
Yritys tekee valitun toimittajan kanssa tarkennetun määrittelyn, jossa sovitaan, millainen järjestelmä toimitetaan.
Jo tässä vaiheessa projekti alkaa syödä kallista aikaa, koska tarkkojen määrittelyjen tekeminen on hankalaa eikä käy ihan hetkessä.
Tarkan määrittelyn suurimpana ongelmana on se, ettei kenenkään mielikuvitus riitä määrittelemään etukäteen kaikkia erilaisia pikkuskenaarioita, piirteitä ja omituisuuksia, mitä yrityksen toimintaan ja järjestelmään liittyy.
Harva IT-sektorin ulkopuolinen asiakasyritys on tarpeeksi kokenut järjestelmän hankkijana, jotta se osaisi mainita kaikki oleelliset operatiiviset asiat. Järjestelmätoimittajat puolestaan eivät yleensä osaa kysyä kaikkia näitä operatiivisia käytäntöjä tarpeeksi tarkalla tasolla, koska ne joko eivät ole erikoistuneet asiakkaansa toimialaan tai toimialaosaamisestaan huolimatta ne eivät huomaa kaikkia asiakkaansa toiminnan erityispiirteitä ja nyansseja.
Usein erikoispiirteet ja yksityiskohdat alkavat tulla esiin vasta järjestelmän ollessa asiakkaalla ensimmäisessä testikäytössä.
Tässä vaiheessa projektia yrityksen kassahanat pitää avata, sillä pienetkin muutostyöt vaativat rahaa.
Käytännössä järjestelmätoimittajat pyrkivät tekemään vain sen mistä on sovittu ja mistä hinta on laskettu. Asiakas taas haluaisi muuttaa kaikenlaista, koska sille alkaa pikkuhiljaa valjeta, ettei järjestelmä toimikaan halutulla tavalla, vaikka se täyttäisikin määrittelyn mukaisen toiminnan. Kun järjestelmään tehdään määrittelystä poikkeavia muutoksia tai lisäyksiä, niin se maksaa yritykselle lisää. Monta kertaa.
Tässä vaiheessa projektia ERP-hankinta alkaa viedä jo liian monen yöunet.
Kun järjestelmän testikäytön seurauksena asiakas haluaa tehdä muutoksia järjestelmään, hän käytännössä pyytää toimittajaa tekemään sopimukseen kuulumatonta työtä. Tämä oikeuttaa järjestelmätoimittajan siirtyvän tuntiperusteiseen laskutukseen, mikä loppupeleissä nostaa asiakkaan järjestelmähankinnan kulut kauas yli budjetoitujen kulujen.
Tarkkojen määrittelyiden sijaan järjestelmän toimittaminen kannattaa tehdä iteroimalla, jolloin asiakasyrityksen ei tarvitse miettiä etukäteen jokaista pientä nyanssia ja yksityiskohtaa, koska se ei siihen kuitenkaan pysty. Ei kukaan pysty, koska erityispiirteet paljastuvat vasta testivaiheessa.