Hyväksy

Käyttämällä tätä sivustoa hyväksyt evästeiden käytön

Lue lisää evästeistä

Tiedon pihtauksesta yhteiseen ymmärrykseen ja tekemiseen

(22.3.2017 Blogi)

He who rejects change is the architect of decay. The only human institution which rejects progress is the cemetery. - Harold Wilson

Kenelle ja miten järjestelmä myydään?

Kysymys voi kuulostaa tyhmältä, mutta kun asiaa tarkastellaan järjestelmähankkeen onnistumisen kannalta, vastaus ei välttämättä ole niin ilmeinen. Kaupallisessa mielessä ostopäätöksen tekee yrityksen johto laittamalla nimet paperiin, mutta tämä on hankkeen onnistumisen kannalta sama kuin olisi maratonilla ensimmäisessä mutkassa ensimmäisenä.

Järjestelmän käyttöönoton ja käytön onnistumisen kannalta oleellista on myydä järjestelmä ja erityisesti uudet toimintatavat ja roolit koko organisaatiolle. Oleelliset kysymykset onnistumisen kannalta alkavat sanalla ”miksi”. Liian usein projektissa keskitytään vain miten-alkuisiin kysymyksiin. Jos miksi-kysymyksiä ja niiden vastauksia ei käydä huolella läpi, muodostuu kullekin oma käsityksensä hankkeen tavoitteista ja syistä. Toisaalta miksi-kysymyksiin on helpompi vastata, jos hankkeen tavoitteet ovat selkeät ja ymmärrys nykytilasta on riittävän syvä.

Jos tavoitteiksi on asetettu esimerkiksi toimituskyvyn ja laadun parantaminen sekä tehokkuuden parantaminen, on niitä konkretisoitava mittareilla ja alatavoitteilla. Hankkeen tavoitteiden ja mittareiden onnistunut asettaminen vaatii nykyisen tilanteen syvällistä ymmärrystä ja ymmärryksen tukemista mitatulla tiedolla. Ympäripyöreät tavoitteet paljastavat tilanteen tuntemuksen heikon tason ja taas toisaalta tarkat mitattavissa olevat mittarit ilman päteviä perusteita vaikuttavat näennäisiltä. Valitettavan usein nykytilanne paljastuu vasta järjestelmähankkeen aikana ja totuus osoittautuu tarua ihmeellisemmäksi.

Muutos? Ei kiitos.

Aito muutos lähtee ymmärryksestä. Ilman ymmärrystä ei voi olla aitoa sitoutumista. Ymmärryksen tavoittelu myös korostaa ihmisten huomioimista ja kunnioitusta ihmisinä eikä vain resurssina tai koneen osana. Projektin kuluessa käy helposti niin, että asiantuntijoiden tekeminen ja keskustelu pyörivät lähinnä teknisissä yksityiskohdissa, jolloin hukataan niin sanottu iso kuva. Asiakkaan edustaja miettii vain omaa työtään ja konsultti pyrkii ratkaisemaan tämän yksittäisen tarpeen ymmärtämättä kokonaiskuvaa. Koko hankkeen tavoitteet – ne usein hyvin ympäripyöreästi kuvatut ja hankalasti mitattavissa olevat – eivät heijastu päivittäisessä projektityössä. Loppukäyttäjiltä – ja toisinaan myös avainhenkilöiltä – saattaa puuttua kunnollinen käsitys hankkeen taustoista ja ajureista. Ja vaikka tavoitteet olisivatkin selkeät, ne unohdetaan kommunikoida tai niitä ei osata kommunikoida ymmärrettävästi ihmisille.

ERP-järjestelmätoimittajan rooli on perinteisesti ollut toimittaa asiakkaan prosesseihin sovitettu valmisohjelmisto. Käyttöönottoprojektin aikana järjestelmävaatimukset saattavat vahvasti henkilöityä, mikä aiheuttaa taisteluasemien rakentamista, poteroissa lymyilyä ja avoimen dialogin heikentymistä. Taustalla vaikuttaa usein oman asiantuntijuuden romuttumisen ja koko työnkuvan muuttumisen pelko, kun tuttu ja turvallinen tapa ja järjestelmä tehdä työtä muuttuvat. Jos henkilö ei ymmärrä muutoksen syitä ja isoa kuvaa, on muutosta omalla kohdalla vaikea hyväksyä. Minulle paras ja meille paras kun eivät välttämättä kulje käsi kädessä.

Valitettavan vähän kummallakaan puolella huomioidaan muutoksen suuruutta, saati osataan sitä johtaa. Ristiriitatilanteissa kaivaudutaan molemmin puolin taisteluasemiin ja huudellaan sieltä rooliin kuuluvia tyhjiä fraaseja. Aidon kumppanuuden puuttuessa nojataan sopimusteksteihin ja unohdetaan mikä olisi oikeasti molemmin puolin järkevää. Kumppanuus tietysti vaatii luottamusta. Luottamuksen rakentaminen on vaikeaa, jos epäselvien tavoitteiden ja toimintatapojen vuoksi ei tiedä milloin soudetaan ja milloin huovataan?

Mikä sitten neuvoksi? Olisiko helpointa tehdä niin kuin aina ennenkin?

Käymme yhdessä ain, käymme aina rinnakkain

Keskeistä on yhteinen suunta ja toimintatavat. Paino tässä nimenomaan on näiden yhdistelmällä ja tasapainolla. Ymmärrystä hankkeen tavoitteista ja syistä edistää esitetyn tiedon, prosessien ja toimintatapojen selkeys ja avoimuus. Poikkeukset ovat pahasta ja yksinkertaisuus on kaunista. Mitä enemmän on poikkeuksia, sitä enemmän tarvitaan selittämistä, dialogia ja dokumentaatiota. Toiminnanohjausjärjestelmien käyttöönotot yleensä tukevat yhtenäisten toimintatapojen löytämistä, mutta ilman yhteistä maalia päädytään tilkkutäkkiratkaisuun, jossa yksittäiset kohdat prosesseista toimivat, mutta kokonaisuus on rampa. 

Toisinaan poikkeamat johtuvat siitä, että prosesseja ei ymmärretä kuin erillisinä toimintoina ja vaatimuksia sujuvaan prosessivaiheiden kytkeytymiseen ei tunnisteta. Poikkeama tietyssä prosessivaiheessa voi tuntua kyseisessä vaiheessa perustellulta, mutta kokonaisuuden ja kokonaisprosessin kannalta se on monesti haitallinen. Vähintäänkin siinä mielessä, että se vaatii erityistoimenpiteitä, koulutusta, hiljaisen tiedon siirtämistä ja mahdollisesti ohjelmamuutoksia toimiakseen. Työnvakioinnilla eli standardoinnilla pyritään havaitsemaan ja ehkäisemään poikkeamia, jotka aiheuttavat erityistoimenpiteitä. Samalla kun tiedetään mitä, miten ja miksi jokin asia tehdään, havaitaan helpommin, jos asiat eivät etenekään standardin eli oletustemme mukaisesti.

 

Työn vakioinnin tulisi ulottua niin asiakkaan kuin toimittajankin prosesseihin. Liian usein me järjestelmätoimittajan asiantuntijatkin sorrumme räätälöimään toimintatapojamme projekteittain, jolloin menetetään oppimismahdollisuuksia lukuisten poikkeamien vuoksi. Näin emme näe metsää puilta. Standardoinnista puhuttaessa on aina riskinä, että se ymmärretään toimintaa jäykistävänä. Standardoinnin vastaparina pitää olla kehittäminen. Parhaimmillaan se on jatkuvaa parantamista eli järjestelmällistä oppimista. Oppiminen toki vaatii uusia ideoita, mutta niiden toimivuuden testauksen tulee olla hallittua. Jos muutat kaikkea, et enää tiedä mikä muutos vaikutti myönteisesti ja mikä kielteisesti.

Samaa luonnollista oppimistapaa olisi hyvä noudattaa organisaation muutoksen johtamisessa ja kulttuurin muutoksessa. Ihmiset eivät helposti pysty ymmärtämään suuria muutoksia ja niiden perusteita (huom. Yhteinen suunta!). Norsu tulee syödä pala kerrallaan. Mitä aiemmin ihmiset saadaan mukaan dialogiin muutoksista, sitä paremmat mahdollisuudet heillä on omaksua uudet toimintatavat ja työkalut. Tähän ei riitä perinteiset yksittäiset mekaaniset koulutukset. Oppiminen ja ymmärrys syntyvät tekemisen kautta, mitä ei voi korvata tietoa kaatamalla. Säästöt koulutuksessa maksetaan tehojen menetyksenä ja sähläämisenä järjestelmän käytön aikana. Oppimista tukevia keinoja ovat ideoiden testaus kokeilemalla ja yhdessä oppien. Tämä vaatii molemmin puolista luottamusta ja heittäytymistä unohtamatta kuitenkaan hankkeen tavoitteita. Projektinhallinnan näkökulmasta kokeilujen tulee olla läpinäkyviä, jotta vaikutukset projektin aikatauluun, kustannuksiin ja laajuuteen voidaan pitää hallinnassa. Liian tiukat projektisuunnitelmat ja -sopimukset voivat estää kokeilukulttuuria sitomalla liikaa käsiä ja syventämällä eri osapuolten poteroita. Täydellistä projektisuunnitelmaa tärkeämpää ovat prosessit, joilla muutoksia suunnitelmaan voidaan käsitellä. On utopistista ajatella, että projektin suunnitteluvaiheessa ymmärrettäisiin prosessien nykytilan ja toiminnanohjausjärjestelmän yhteensopivuus. Näin ollen palaamme jälleen yhteisen suunnan määrittämisen, ylläpitämisen ja kommunikoinnin tärkeyteen hyödyntämällä yhteisiä toimintatapoja.

Pysähdy hetkeksi miettimään: Onko teidän hankkeellanne ihan oikeasti yhteiset tavoitteet ja toimintatavat?

Kirjoittaja: Mikko Kaataja, Microsoft Dynamics 365 -asiantuntija

Ota yhteyttä ja pyydä lisätietoja