Toisinaan yrityksen tarpeita toiminnanohjaukseen liittyen koostetaan vaatimusmäärittelyiksi, joilla on vakiintunut rooli projektiin valmistautumisessa (kts esim. logistiikan maailman ohjeistus). Konkreettisesti vaatimuksia saatetaan kartoittaa sarjalla työpajoja tai kokouksia, joissa tulevaa toimintaa ideoidaan. Joko ihan omin voimin, tai asiaa fasilitoivan konsultin avustuksella.
Vaatimusmäärittelydokumentti on täynnä hyvää ja relevanttia aineistoa, mutta kokemukseni mukaan harvoin se on täydellinen. Alla kuvattu keskeisiä ongelmia aiheeseen liittyen, perustuen kolmen vuosikymmenen työskentelyyn aiheen parissa.
Vaatimusten rajoittuneisuus
Kokouksiin ei yleensä kutsuta kaikkia, vaan vain joitakin avainhenkilöitä. Kenties vain osa osaston ihmisistä, tai jos osastoja on useammassa lokaatiossa, niin vain yhden, tyypillisesti pääkonttorin väki. Vaatimuksiksi päätyy siten vain tämän porukan tiedot, ei kaikki se muu tietämys, joka organisaatiossa olisi.
Jos taas työpajoihin kutsutaan kaikki, niin tilanne ei ole välttämättä sen parempi. Osa ihmisistä kokee rimakauhua ja kynnystä avata suunsa isomman joukon edessä, joten he ovat hiljaa. Muutenkin toiset ihmiset ovat enemmän äänessä kuin toiset, jopa agressiivisuuteen asti. Osaavien, mutta ehkä hiljaisempien ihmisten ajatukset voivat jäädä jalkoihin.
Tarpeita vai toivomuksia?
Tarpeiksi saatetaan listata kaikki kivat ominaisuudet, joita on joko nykyisissä työkaluissa tai joita on nähtyä muualla tai ihan muuten vain popsahtaa mieleen. Vaikkakin kivoja, nämä eivät välttämättä ole yrityksen liiketoiminnalle mitenkään erityisen tarpeellisia. Yksi oleellisimpia menestystekijöitä on pitää pilottiprojektin laajuus kurissa fokusoimalla oleelliseen, ja nämä sinänsä mahdollisesti kannatettavat ajatukset olisi paras säästää jatkokehitysvaiheisiin.
Liiketoiminnalle tarpeellisella tarkoitan sitä, että kyseinen toiminto joko lisää myyntiä, parantaa asiakaspalvelua, kasvattaa tehokkuutta vähentämällä työtä tai muutoin tuottaa konkreettista hyötyä. Eli tuo jotain viivan alle!
Esimerkki. Jos vaikkapa tuotteen ostohinnan ja ostolaskun välinen hintaero voidaan käsitellä tavalla A tai tavalla B, on vaikea perustella miten kumpikaan tavoista toisi liiketoiminnalle erityistä hyötyä. Kuitenkin voi olla niin, että talousihmiset ovat tottuneet tapaan A, jonka he kirjaavat tarpeeksi. Jolloin jos erp-vaihtoehdossa onkin käytössä tapa B, joka ajaisi saman asian, se karsiutuu turhan takia. Tai ainakin sen pisteytys laskee.
Ristiriitaisia vaatimuksia
Jotkut vaatimukset saattavat olla jo ihan ideatasollakin ristiriidassa toisten vaatimusten kanssa. Saatetaan vaikka haluta yhtä aikaa tietty toiminto automaattiseksi ja samalla joustavaksi tai interaktiiviseksi. Joskus ehkä tämmöinenkin voi onnistua mutta usein ei.
Esimerkiksi tuotantotiimissä on saatettu vaatia, että materiaalin tultua vastaanotetuksi sen pitää näkyä tuotannolle heti, niin että valmistus voi välittömästi käynnistyä kriittisen erän saavuttua. Ja toinen vaatimus, kenties laatuosastolta, että materiaalin pitää käydä läpi tarkastusmenettely ennenkuin sitä voidaan alkaa käyttää. Mahdollisesti vaatimukset on kirjattu hiukan epämääräisesti siten, että ristiriitaa ei ensisilmäyksellä huomaa (vaikkapa kirjattu, että "varastonseuranta reaaliaikainen" ja "laaduntarkastus vastaanotossa"). Vasta tarkemmassa selvityksessä, kun vaatimus on kirjoitettu kokonaisuudessaan auki, piilevä ristiriita ilmenee.
Puuttuvat itsestäänselvyydet
Jotkin toimintatavat ovat niin itsestäänselviä yritykselle, että niitä ei erikseen tajuta kirjata ylös. Myös toimittajan mielestä samat asiat ovat itsestäänselviä. Mutta kummallakin on ihan oma käsityksensä siitä itsestäänselvyydestä, ne eivät ole samat!
On tietenkin turhauttavaa luetella "itsestäänselvyyksiä" vaatimuksiin, mutta tavalla tai toisella ajateltu toimintalogiikka olisi kuitenkin pystyttävä saattamaan toimittajien tietoon. Ei välttämättä vaatimusmäärittelyjen kautta, vaan ehkä demoamalla miten nykyään toimitaan, mikä tekisi nämä "itsestäänselvyydet" näkyviksi. Tämä on oikein järkevä ajatus, mutta on huomattava, että silloinhan nämä asiat puuttuvat niistä vaatimuslistoista. Niissä on silloin lähtökohtaisesti vain osatotuus.
Vaikeat epäsuorat tarpeet
Kun toimintamalleja tyypillisesti järjestelmähankkeissa kehitetään, eli siis muutetaan, heijastuu tämä moneen suuntaan. Ei ole mitenkään selvää, että kukaan osaa ennalta nähdä, mitä nämä kaikki epäsuorat vaikutukset ovat. Jolloin nämä seikat jäävät puuttumaan vaatimusmäärittelystä.
Klassinen esimerkki on perustiedot, kuten vaikkapa nimikerekisteri. On tavanomaista, että toiminnanohjaus tukee monenlaisia erilaisia toimintamalleja, vaikkapa nyt nimikkeen osalta ostamista, valmistamista itse tai siirtoja yrityksen toisesta yksiköstä. Se mitä näistä vaihtoehdoista käytetään, yleensä ylläpidetään kyseisen nimikkeen tietoihin (per yrityksen yksikkö). Mitä mutkikkaampi järjestelmä, sitä enemmän erilaisia indikaattoreita ja ohjaustietoja rekistereissä on, SAP:in nimikerekisterissä niille on yli 100 kenttää (kertaa liiketoimintayksiköiden määrä). Tällaisten säännöstöjen ylläpito voi osoittautua vaikeaksi, eikä sitä tukevaa toimintaprosessia ole tyypillisesti kuvattu vaatimuksiin. Varsinkaan jos vanhassa toimintamallissa vaihtoehtoja ei juuri ollut, tai ne olivat niin triviaaleja, että yksi ihminen aina hallitsi ne. Pahimmillaan jatkossa pitäisi saada iso joukko ihmisiä eri yksiköistä ja eri osastoilta koordinoidusti ja tehokkaasti tekemään sama, huomioiden kaikkien eri ohjaustietojen keskinäiset riippuvuussäännöt.
Yksi yleisimmistä SAP-projektien epäonnistumisen syistä on nimenomaan se, ettei perustietoja ole osattu perustaa oikein. Ristissä olevat ohjaustiedot saavat toimitusketjunkin ristiin. Se yllättää yhtä varmasti kuin ensilumi autoilijat. Tämmöiset vaatimukset tulevat ikäänkuin nurkan takaa epäsuorasti.
Epäsuorat tarpeet ovat kaiken lisäksi erityisen tuoteriippuvaisia, joten yleisesti ottaen ei ole kovin suuria edelletyksiä pystyä hahmottamaan niitä etukäteen kuin hyvin ylätasolla.
Historian kirot
Jos käytössä on vanhoja järjestelmiä, toisinaan niitten uumeniin on koodattu toimintoja, joita kukaan ei nykyään tunne. Järjestelmä vain "mystisesti" osaa tehdä oikeita valintoja tai asioita tietyissä tilanteissa, joita kukaan ei tajua määritellä uudenkin järjestelmän vaatimuksiksi. Pahimmillaan näitä piileviä logiikoita ei nähdä miltään ruudulta tai rekistereistä, vaan ne on toteutettu täysin taustalle. Esimerkiksi surullisenkuuluisalla kovakoodaus-tekniikalla.
Mahdollisesti ihmiset tämän aikanaan rakennetun toiminnon takana ovat vaihtaneet firmaa tai tulleet siivotuiksi YT:eissä tms. Kukaan jäljelle jäänyt ei tiedä mitä systeemi tarkalleen tekee, se on vain musta laatikko joka toimii. Ja perusteellisinkaan toimittajan määrittelijä ei ala kahlaamaan vanhan järjestelmän lähdekoodia läpi.
Lopputulos
Lopputuloksena saadaan siis vaatimuslista, jossa on mukana turhia, ristiriitaisia ja puolueellisia tarpeita, mutta silti siitä puuttuu oleellisia asioita. Puolileikillään monesti todetaan, että paras tai ainoa vaatimuksiin vastaava järjestelmä on yrityksen nykyinen, jos sellainen on. (Jos unohdetaan ne puutteet miksi sitä ollaan vaihtamassa).
Mikään järjestelmä ei ole koskaan niin täydellinen kuin juuri ennen kuin se ollaan vaihtamassa!
Suunnitelmat turhia, suunnittelu tärkeää!
Jos vertailen projektille alussa asetettuja vaatimuksia jälkikäteen tehtyihin "mikä oli lopulta kriittistä onnistumiselle" analyyseihin, niin ne eivät lähimainkaan täsmää. Vaatimuksista puolet oli turhia ja puolet tärkeistä puuttui - noin karkeasti tiivistäen.
Projektille ongelma ovat nimenomaan ne asiat, joita ei aluksi nähty, mutta nousivat kriittisiksi tekemisen edetessä. "Devil is in the details", kuten sanotaan. Niiden takia projekteilla - ja sitä myöten budjeteilla ja aikatauluilla - on tapana paisua matkan aikana. Gartnerin analyysin mukaan yli puolet toiminnanohjausprojekteista epäonnistuu saavuttamaan tavoitteensa. Syitä on toki muitakin kuin vaatimusmäärittelyn sisältö (ja palaan niihin myöhemmissä blogipostauksissa), mutta vaatimusmääritykset ovat kerta kaikkiaan hyvin vaikea laji.
Voisi ehkä summata, että vaatimusmäärittelyt ovat sinänsä hyvä lähtökohta projektille. Tehty suunnittelu auttaa ja kantaa. Mutta sillä alkuperäisellä suunnitelmalla ei koskaan päästä maaliin saakka! Samankaltaisia kokemuksia lienee ollut siellä sotatantereellakin.
