”Ylivoimaisesti suurin osa tietotekniikkahankkeista päättyy erilailla kuin piti. Onkin mietittävä, miten sopimuksilla voisi varautua it-hankkeiden ongelmatilanteisiin”, sanoo juttuun haastateltu Pekka Tarkela asianajotoimisto Borenius & Kemppiseltä.

Mutta millainen sopimus on järjestelmän ostajan kannalta hyvä?

Kokemukseen pohjautuen se sisältää ainakin seuraavat, harmittavan usein ylenkatsotut asiat:

1. Mitattava. Kun sopimuksessari on selkeä mittari, jolla onnistumista arvioidaan, sinun on helppo reklamoida. Suurimmasta osasta sopimuksia tämä kuitenkin puuttuu, koska mittareiden miettimiseen ja määrittelyyn ei ole sopimusvaiheessa osattu panostaa.

2. Pilkottu. Vaiheistettu eteneminen takaa kaksi asiaa: Ensinnäkin, kokonaisuudet eivät kasva liian suuriksi hallita ja toiseksi, aikataulussa pysymistä on yksinkertaista seurata. Aito vaiheistus on rakennettu riittävän itsenäisistä osioista, jotta pystyt minkä tahansa vaiheen jälkeen vaikka vaihtamaan toimittajaa ja uusi pystyy jatkamaan siitä, mihin edellinen jäi.

3. Yksinkertaistava. Jotta toimittajaa voisi aidosti vaihtaa kesken hankkeen (toivottavasti näin ei tarvitse tehdä), kunkin osion pitää sisältää yksinkertaisia ydintehtäviä. Jos et yhdessä toimittajan kanssa pysty näitä määrittelemään, otat monimutkaisuusriskin toimittajariskin ohella. Etkä selvästi tiedä, mitä tehtävää varten olet järjestelmää ylipäätään ostamassa ja miten se integroituu liiketoimintaasi.

4. Koeteltu. Hyvä sopimus – siis sopimuksen muoto ja teksti – sisältää aivan vastaavanlaista osaamista kuin hyvä ohjelmistokoodi. Ellet ole koodannut paljon, et voi tehdä erinomaista koodia. Ellet ole tehnyt sopimuksia paljon, et voi tehdä erinomaista sopimusta. Käytä asiantuntijaa, joka työstää kanssasi sopimuksen kuntoon. Niin sinulle standardisopimustaan tyrkyttävä it-toimittajakin on tehnyt – ja voit olla varma, että tuo sopimusmalli on hänelle edullisempi kuin sinulle.

Näissä perusasioissa ei kannata oikaista. Kun perusta on kunnossa, loppu on hankekohtaista määrittelyä ja sopimustekniikkaa.

LINKKI: http://www.tietoviikko.fi/cio/article327469.ece ”Solmi it-palvelusopimus niin, ettet jää toimittajaloukkuun, TiVi 15.9.2009”

9. KÄSKY: Vaadi kehittämisessä vaiheistettua etenemistä osatuloksin, näin vältyt riskeiltä ja säästät rahaa! (Thomas Grandell)

Toiminnanohjaushanke kannattaa toteuttaa vaiheittain. Monivuotisilla jättihankkeilla on tapana paisua, eikä valmistuminen sitten joskus auta luomaan motivaatiota käyttäjille. Pienten askeleiden mallin etu on, että koko ajan tapahtuu ja asioita valmistuu.

Jaan tässä hankkeen päävaiheisiin (todelliset työvaiheet pilkotaan pienempiin osiin) ja käyn läpi tyypillisiä sudenkuoppia.

Vaihe I, nykytila ja tavoitteet: Määritä nykyiset ohjausprosessit. Etsi parannuskohteet. Määrittele tavoitetila. Päätä mittarit. Joskus olen törmännyt organisaatioihin, joissa prosesseja ei ole lainkaan määritelty ja kukin elää talossa tavallaan. Tämä ei ole välttämättä huono asia, vaan mahdollisuus löytää paljon lisätehokkuutta ja samalla järkeistää päivittäistä työtä.

Riski: Et saa aikaan jaettua ymmärrystä siitä, mitä toiminnanohjaus tarkoittaa (katso ensimmäinen käsky). Tällöin hanke nähdään vain it-projektina tai hallinnon työkaluna.

Riski: Et osaa kertoa mitä muutos tarkoittaa kullekin yksikölle. Yksilötasolla jokaisen on ymmärrettävä, mitä se tarkoittaa minulle, mitä minulta odotetaan, miten minua mitataan. Ellei johto osaa vastata alaisten kysymyksiin näin konkreettisella tasolla, johto ei itse ole tarpeeksi perillä hankkeestaan. Seurauksena on pelkoa, joka hidastaa toteutusta ja haittaa käyttöönottoa.

Vaihe II, mitä kannattaa automatisoida: Kattava toiminnanohjaus automatisoi tulevan vuoden suunnittelua, tämän vuoden toteutusta ja seurantaa, sekä tämän ja edellisvuoden raportointia. Käytännössä harva hanke pystyy toteuttamaan kaikkea kerralla. Rajoitteita asettaa sekä aikataulu että käytettävissä oleva budjetti. Siksi kakkosvaiheessa on keskeistä asettaa tehtävät tärkeysjärjestykseen.

Riski: Yrität tehdä kaikki kerralla ja otat vielä toiveita mukaan matkan varrella. Tämä paisuttaa budjettiasi ja aikatauluja sekä hidastaa käyttöönottoa. Jos budjettisi antaa periksi, kaikki voidaan tehdä toki kerralla, mutta se sitoo paljon resursseja pitkäksi aikaa.

Riski: Pienten askeleiden mallikaan ei ole riskitön. Kun toteutat vain muutamia tärkeimpiä tehtäviä, saatat maksaa paljon käsityöstä. Palasista koottu järjestelmä voi edellyttää yllättävän paljon manuaalista hienosäätöä toimiakseen. Tässä on paljon vaihtelua eri toiminnanohjausjärjestelmien teknisten alustojen suhteen.

Vaihe III, tekninen toteutus: Toteutetaan hankkeen tekninen osio. Tämän pitäisi olla noin puolet, korkeintaan seitsemänkymmentä prosenttia hankkeen kokonaisuudesta. Uusien toimintaprosessien suunnittelu ja käyttöönoton varmistaminen vaativat paljon resursseja ja ratkaisevat hankkeen onnistumisen.

Riski: Ostat koko rahalla tekniikkaa. Tai varaat kyllä ensin rahaa myös kulttuurimuutoksen ja käyttöönoton tukemiseen mutta syöt ne rahat matkan varrella teknisten yllätysten tai lisätoiveiden niin vaatiessa. Tämä on tyypillisempää kuin uskotkaan.

Riski: Olet yltiöoptimisti omien avainhenkilöittesi käytettävyyden suhteen. Toiminnanohjaushankkeen läpivienti oman toimen ohella on hyvin rankkaa jos ei mahdotonta. Viimeistään hankkeen venyminen katkaisee selkärangan.

Vaihe IV, käyttöönotto: Uusi toimintamalli ja sitä tukeva järjestelmä otetaan päivittäiseen käyttöön koko organisaatiossa.

Riski: Oma projektipäällikkösi on tyyppinä yhden alueen asiantuntija, ei ihmisten johtaja. Kun tekniikka on kunnossa, hän ilmoitusluontoisesti ojentaa sen käyttäjille. Tämä ei voi toimia. Käyttöönotto on suunniteltava ja se on työtä, joka vaatii budjetistasi aikaa ja rahaa sekä sopivat ihmiset. Tarvitset aktiivista viestintää, asenteisiin vaikuttamista, käyttäjäkoulutusta ja selkeästi organisoidut tukipalvelut. Sekä jonkun, joka näitä aktiivisesti johtaa.

Riski: Johtajana sinun on tuettava erityisesti käyttöönottovaihetta, vaikka se venyisi pitkäksikin. Muutoin ihmiset huomaavat, että asia ei ole tärkeysjärjestyksessäsi korkealla ja alkavat jopa kiertämään järjestelmää ja uusia toimintatapoja. Voit hukata ison osan investointisi hyötyjä siihen, että siirrät oman ajankäyttösi liian aikaisin hankkeesta pois

1. KÄSKY: Varmistu siitä, että toiminnanohjaus ymmärretään samalla tavalla koko organisaatiossa! (Nicklas Lindgren)

Toiminnanohjausta ovat kaikki toimet, kaikilla organisaatiosi tasoilla, joilla asetat tavoitteita, resurssoit ne ja seuraat niiden toteutumista. Kyseessä on johtamisjärjestelmä, ei kasa ohjelmistoja.

Tämä on kuitenkin kaikkea muuta kuin itsestään selvää.

Selvitimme jokin aika sitten eri ammattikorkeakoulujen ja yliopistojen keskuudessa sitä, miten ylin johto, keskijohto ja yksikkötaso ymmärtävät toiminnanohjauksen. Kysyimme, mitkä asiat kuuluvat toiminnanohjauksen piiriin.

Ajatuksemme oli, että eri hierarkiatasoilla olisi eroja. Näin ei ollut, vaan tulos oli paljon mielenkiintoisempi: Lähes kaikki olivat sitä mieltä, että vuorovaikutus Opetusministeriön kanssa on toiminnanohjausta. Siis asiat, jotka kuuluvat hallinnolliselle ylätasolle. Samoin lähes kaikki vastaajat olivat sitä mieltä, että tutkimuksen ja opetuksen ohjaus ei kuulu toiminnanohjauksen alle.

Häkellyttävä tulos! Johtamisjärjestelmällä ja sitä tukevalla toiminnanohjauksellahan on nimenomaan tarkoitus tukea päivittäistä työtä, ydintoimintaa. Eli opetusta ja tutkimusta.

Tästä henkisestä esteestä on päästävä yli aivan ensimmäisenä. Toiminnanohjaushankkeesi voi onnistua vasta, kun kaikki hyväksyvät sen osaksi päivittäistä toimintaansa.

Ymmärrän toki, mistä tulos johtuu. Jo lainkin mukaan korkeakouluissa vallitsee opetuksen ja tutkimuksen vapaus. Tämä henkinen autonomia on tullut niin rakkaaksi, että joissain paikoissa se on synnyttänyt organisaation, jota ei saisi johtaa. Kaikki omaan toimintaan puuttuminen koetaan kielteisenä.

Siksi ensimmäinen urakkasi on selvittää, mistä johtamisessa on kysymys. Sekä tehdä selväksi, että asioihin puuttuminen on paitsi välttämätöntä (kun resursseja on rajoitetusti, niitä pitää käyttää fiksusti) myös suotavaa (johtaminen on palvelufunktio, joka hyödyttää kaikkia).

Ryhdy rakentamaan yhteistä johtamisnäkemystä. Kerro, että aloitat hankkeen toiminnan kehittämiseksi. Sen tavoitteena on järkeistää ja tehostaa työtä. Osana tuota hanketta luodaan toiminnanohjausjärjestelmä. Se sallii edelleen opetuksen ja tutkimuksen vapauden mutta muuttaa päivittäisiä toimintatapoja.

Toiminnanohjaushankkeen menestys ratkeaa kauan ennen kuin aletaan edes puhua tietotekniikasta. Toiminnanohjaus tarvitsee henkisen perustan, se ei ole koskaan tietotekniikkakysymys.

Kyseessä on siis aina jonkinasteinen kulttuurin muutos. Se onnistuu, kun varmistat, että toiminnanohjauksen tarkoitus ja vaikutus ymmärretään koko organisaatiossa samalla tavalla.

Kun omaksut tämän näkökulman, ymmärrät myös, miksi et saa antaa tietotekniikan syödä hankkeen kaikkia resursseja. Kykysi luoda johtamisen kulttuuria ja varmistaa yhteinen näkemys on avain onnistumiseen. Vain siten ihmiset hyväksyvät muutoksen ja tukevat järjestelmän käyttöönottoa. Varaa siksi iso siivu hankebudjetistasi tähän työhön.