Toiminnanohjausratkaisu aikataulussa ja budjetissa

Olen viimeisen 25 vuoden aikana nähnyt noin 100 toiminnanohjauksen uudistusta. Niistä noin 60 % on mennyt aikataulussaan ja budjetissaan läpi. Olen tähän kirjoitukseen koostanut näitä yhdistäviä tekijöitä sekä viimeaikaisia havaintoja pilvestä toteutettaviin toiminnanohjauksen kokonaisuuksiin. Jäljessä mainittuja on yrityksemme toteutuksista viimeisen kahden vuoden ajalta yli 95 %. Ne muodostavat myös toteumaltaan suunniteltua vastaavasta osuudesta yli 90%.

Mikä siis pilvierpeissä on niin ainutlaatuista, että ne vaikuttavat turvallisilta asiakkaille?

Suunnittelu vs. ylisuunnittelu

Jos päätös investoinnista tehdään viikolla yksi ja suunnittelu on tavoitteena tehdä viikoilla 2-8, voi toteutus usein – käyttöönottomenetelmästä tosin riippuen – alkaa vasta tämän jälkeen. Jos suunnittelua jatketaan, viivästyy toteutuksen aikataulu. Kuulostaa varsin simppeliltä ja ennen kaikkea loogiselta, mutta tämä tuntuu jatkuvasti olevan yksi keskeisimmistä aikataulutavoitteen toteutumisen kannalta realisoituvista haasteista. Tulee kyetä erottamaan olennainen ja tärkeä niistä kaikista mahdollisuuksista, joita alati kehittyvä toiminnallisuus tarjoaa. FUB on yleisesti hyväksi havaittu termi, joka tulee sanoista Features, Use, Benefits. Kun ollaan varmoja siitä, että kyseistä toiminnallisuutta tullaan oikeasti ja laaja-alaisesti käyttämään ja se tuottaa organisaatiolle ja käyttäjälle mitattavaa hyötyä, kannattaa se suunnitella toteutettavaksi. Haaveiden tynnyri on loputon. Tarvitaan rohkeutta, ohjausta, johtamista ja päätöksiä.

Korvausinvestointi vs. uuden mahdollistaja

Jos olemassa oleva toiminnanohjausratkaisu on vanhentumassa ja paine korvausinvestointiin syntyy teknologian tuen päättymisestä, saattaa syntyä ajatus korvata olemassa oleva ratkaisu vastaavalla uudella. Nykyaikaiset pilvierpit mahdollistavat prosessien uudistamista ja jopa kokonaan uusia palveluita. Tämä näkökulma kannattaa huomioida investointisuunnittelussa ja takaisinmaksun arvioinnissa vaikuttaen sekä tavoitteeseen, budjettiin että aikatauluun. Onnistunut erp-hanke toimiikin hyvin kiinteänä ja saumattomana osana organisaation uuden strategian jalkautusta.

Toimittajan resurssit vs. asiakkaan resurssit

Me toimittajat syyllistymme usein siihen, että asiakkaan toivomuksesta arvioimme asiakkaan käyttämän ajan epärealistisesti ja alakanttiin. Nyrkkisääntö on, että asiakkaan tulee varata hankkeeseensa yhtä paljon aikaa toimittajan kanssa. Ketterissä menetelmissä usein jopa enemmän.

Mikäli toimittaja kertoo toteuttavansa ratkaisunsa kuudessa kuukaudessa ja 120 henkilötyöpäivässä, tulee asiakkaan resursoida omaa henkilöstöään vastaavasti 20 henkilötyöpäivää / kuukausi. Tämä tasaisen vauhdin taulukko edellyttää asiakkaan yhtä kokopäiväistä hankkeen omistajaa tai kahta puolipäiväistä tai neljää sellaista, jotka tekevät viikon kuukaudessa tai… Keskeistä on yhdessä nähdä käyttöönoton vaatimukset henkilö- ja viikkotasoilla sekä seurata toteumaa ja ohjata tasoilla:

  • suunniteltu
  • toteutunut
  • valmiusaste

Käyttöönotto ja kehitys

Vanhakantaisissa erpeissä piti vesiputousmallin mukaisesti ensin määritellä ja sitten toteuttaa. Toteutus valmistui usein niin myöhään, että yrityksen toiminnan muuttuessa määrittely ei enää vastannut toimintaa. Tämä johti muutoksenhallinnan kierteeseen ja usein myös valitun erpin kyvyttömyyteen vastata muutosten huutoon. Nykyaikaisissa pilvierpeissä keskeisiä etuja ovat mm. versiolukottomuus, toimittajariippumattomuus ja lisäkomponenttien saatavuus päämiehen ekosysteemistä. Versiolukottomuus syntyy ohjelmistosta vastaavan päämiehen jatkuvasta kehitystyöstä, joka näkyy säännöllisinä pilvipäivityksinä. Miltei yhtä keskeistä, kuin on käydä keskustelu asiakkaan toiminnallisista ja teknisistä vaatimuksista, on rinnan näiden kanssa keskustella pilvierpin roadmapista; mitä ratkaisuun tulee ja missä aikataulussa.

Pilvierpin päivityssykli esim. kaksi kertaa vuodessa voi hyvin olla toiminnanohjauksen implementointia ohjaava tekijä. Saatavilla olevaan nykyiseen versioon toteutetaan ketterin menetelmin helposti ja nopeasti suunniteltava toiminnallisuus. Seuraavaan versioon poimitaan ne kehitysideat, joita ei ole toimintaprosessin kannalta kriittisesti tarkasteltuna perusteltua toteuttaa ilman merkittävää liiketoimintahyötyä.

Tätä jatkuvan kehittämisen mallia jatketaan koko pilvierpin elinkaaren ajan. Näin varmistetaan yrityksen kilpailuedun kannalta tärkeä kyky muuttua ja mukautua muuttuvaan toimintaympäristöön, toiminnanohjauksen noudatellessa tätä muutospainetta ja -tarvetta.

Mukautus vs. räätälöinti

”Me emme halua räätälöintejä”, on yksi eniten kuulemistani asiakkaan johdon lausahduksista. ”Haluamme standardin toiminnallisuuden, jotta emme ole yksin valitun ratkaisun kanssa.” Tämä on hyvä ja perusteltu näkökulma, etenkin kun halutaan välttää pilvierppien päivityksissä mahdollisesti esiin tulevat ja räätälöintien sekä integraatioiden ylläpitoon liittyvät haasteet. Samaan aikaan ja samoilta asiakkailta saattaa kuitenkin tulla tarve: ”Toteuttakaa tämä meidän näköiseksemme.” Tällöin toimittajan osaaminen korostuu ja keskeistä on nostaa riskienhallinnan kannalta esiin keskustelu mukauttamisesta vaiko räätälöinnistä. Mukautus tehdään konsultin tai asiakkaan toimesta työnkulkuja ja parametreja hyödyntäen. Tällöin ratkaisu säilyy eheänä. Räätälöinnit vaativat sovelluskehittäjän osaamista ja koodausta / skriptausta ja ne tulee huomioida ennakkoon jokaisen päivityksen yhteydessä.

Yhteenvetona

Ketterissä menetelmissä tyypillisesti lukitaan kaksi kolmesta; aikataulu, budjetti, toiminnallisuus. Jos kaksi lukitaan, kolmas joustaa. Ensin on tehtävä tämä päätös. Seuraavaksi kannattaa katsoa, miten organisaation visio ja strategia ohjaa liiketoimintaa, liiketoiminta-alueita, palvelukehitystä, asiakaskokemusta ja kaikkia keskeisiä prosesseja. Tämä yhdistettynä järjestelmäarkkitehtuuriin luon haaveille syyn. Tekeminen kannattaa palastella. Ensin tehdään se mikä on pakko, muut hoidetaan kehityshankkeina. On tehtävä jatkuvan kehityksen suunnitelma. Parasta jälkeä syntyy aina tekemällä yhdessä.

 

Haluatko päästä näkemään, miltä NetSuite-liiketoiminta-alusta näyttää? NetSuite-demon avulla saat hyvän kuvan, miten järjestelmä sopii teidän yrityksenne tarpeisiin. Pyydä maksuton demo.

Facebooktwitterlinkedin

Arto Ignatius

Senior Business Consultant Arto Ignatius on ollut mukana yli sadan asiakkaan muutoshankkeissa. Työuraan kuuluu yli 20 vuotta erilaisissa myynnin ja johdon tehtävissä. Artolla on kokemusta muun muassa asiakashankinnan, asiakassuhteiden kehittämisen, myynnin johdon, liiketoiminnan kehittämisen, jakelukanavan rakentamisen ja toimitusjohtajan tehtävistä. Arto on toiminut myös Valtioneuvoston verkkoviestinnän johtoryhmässä. Vuodesta 2000 alkaen hän on työskennellyt erilaisten internet-pohjaisten palveluprosessien ja järjestelmien parissa. Viime vuosina työn painopiste on ollut yksityisen sektorin kasvuun tähtäävien organisaatioiden kasvun tukeminen sopivia ratkaisuja tarjoamalla. Työltä ja kolmelta lapselta jäävän vapaa-aikansa Arto viettää elämään ja ilmiöihin perehtyen sekä matkustaen. Arto on entinen triathlonammattiurheilija.

Tuoreimmat blogitekstit

OTA YHTEYTTÄ

Kerro, miten voimme olla avuksi. Jätä yhteystietosi niin palaamme asiaan mahdollisimman pian. Ota ensimmäinen askel jo tänään, älä odota huomiseen.

Accountor Enterprise Solutions Oy käsittelee henkilötietojasi tietosuojaselosteen mukaisesti ja voi olla yhteydessä sinuun esimerkiksi sähköpostitse ja/tai puhelimitse. Tutustu tietosuojaselosteeseen.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

PYSY AJAN TASALLA

TILAA ILMAINEN UUTISKIRJE

Saat yrityksemme tuoreimmat uutiset suoraan sähköpostiisi.