Matti Grönroos

Baselinen asettaminen

Ulkoistussopimuksia yleensä neuvotellaan tiukasti salassa, monestakin syystä. Neuvotteluvaiheessa saattaa olla vaikeaa hankkia tietoa järjestelmien ylläpitoon ja pyörittämiseen liittyvästä työmäärästä. Siksi laatutavoitteita joudutaan asettamaan sammutetuin lyhdyin ja ne saattavat poiketa realiteeteista huomattavastikin.

Yksi toimintamalli on baselinen asettaminen. Baseline voitaisiin ehkä suomentaa vertailutasoksi. Mallissa lähdetään liikkeelle aitojen prosessien mukaisesti, mutta tavoiteasetanta ei alkuvaiheessa ole sitova, vaan ajan mittaan kerätään tietoa siitä, mille tasolle tavoitteet on realistista asettaa.

Ulkoistushankkeissa on hyvä lähteä siitä olettamasta, että toimittaja on palvelusopimuksiin liittyvissä asioissa yleensä kokeneempi kuin asiakkaansa. Toimittaja ei myöskään yleensä ole hölmö, vaan osaa asettaa hintatason vastaamaan tunnistettuja liiketoiminnallisia riskejä.

Siihen, että laatutavoitteiden asetanta joudutaan tekemään vaillinaisen tiedon pohjalta, saatetaan varautua perälautamenettelyllä: Jos todellisuus osoittaa vaikkapa vuoden–kahden kuluessa, että neuvottelujen aikainen arvaus meni pieleen, päivitetään sopimuksia. Vahinko on jo kuitenkin saattanut sattua. Vaikeiden sopimusneuvottelujen tulostakaan ei ehkä haluttaisi avata. Avaaminen kun saattaa johtaa monen muunkin sopimuksen kohdan avaamiseen.

Jos asiakas neuvotteluvaiheessa vänkää itselleen erinomaista palvelutasoa, mutta ei kykene esittämään tai ei halua esittää faktaa toteutuneesta, toimittaja kompensoi tätä korottamalla hinnaston riskipreemiota. Asiakas saattaa saada haluamansa, mutta ensimmäisen luokan hinnalla.

Baselinen kerääminen on hyväksi havaittu tekniikka, mutta siinäkin on sudenkuoppansa.

Periaate on siis se, että toimitaan sovittu ajanjakso niin kuin tarkoitus toimia. Sitten katsotaan taaksepäin, kuinka kävi ja mitkä olivat saavutetut tulokset. Näiden perusteella sitten kiinnitetään sitovat laatutavoitteet.

Menetelmän sudenkuoppia ovat muun muassa:

Kun tavoitteita asetetaan, on hyvä miettiä, millä tasolla mittausta tehdään. Yleinen virhe on viedä tarkastelu yksittäisten sovellusten tasolle saakka. Tässä on se riski, että sovellusta kohden saattaa syntyä niin vähän laatupoikkeamia, että niistä on mahdotonta tehdä järkevää tilastollista johtopäätelmää. Jos esimerkiksi sovelluksesta tulee kuukaudessa kaksi tikettiä, joista toinen sattuu kerran vuodessa menemään pitkäksi, tuon kuukauden tulos on 50 % ja raportissa kirkkaasti punaisella. Tosiasiassa tilanne todennäköisesti ei ole kriittinen lainkaan, eikä ainakaan sen elefantin tömistelyn arvoista, johon moinen lukema sokeasti tulkittuna helposti johtaa.