Lue
lisää:

Matti Grönroos

Prosessien mitoittaminen – Tee vain sellaisia prosesseja, joihin rahkeesi riittävät

Kun perfektionisti, innokas prosessisuunnittelija ja vasta ITIL Foundation ‑kurssilta tullut junnu laitetaan yhdessä kehittämään firman prosesseja, lopputulos on usein kauhea. Perfektionistin mukana olo toki mahdollistaa sen, että valmista ei tule koskaan.

Varsin usein tehdään hienoja ja komeita kaavioita, mutta unohdetaan kaikkein tärkein periaate: Tee vain sellaisia prosesseja, joihin rahkeesi riittävät.

Rahkeiden riittävyyden ensimmäiseen arvioon riittää usein kerto- ja jakolasku; monimutkaisempaa matematiikkaa ei tarvita.

Sokeasti ITIL-kirjaa lukien tai muuten enempiä ajattelematta on helppoa ajautua ratkaisuihin, joista jo sokea Reetta yhdellä silmällään näkee, että ei toimi.

Ote eräästä takavuosien keskustelusta:

— Tästä eteenpäin jokaisesta insidentistä tehdään problem management.
— Niinkö? Oletko arvioinut keskimääräistä työpanosta per tapaus?
— Olisko neljä tuntia?
— Ja tikettejä on vuodessa montako?
— Noin 300 000.
— Siis 1,2 miljoonaa tuntia per vuosi. Tyypillinen vuosityöaika on 1600 tuntia. Ajattelit siis hommata problem managementia varten 750 henkilöä?
— No eeeennnn...

Prosessien resurssitarvetta (niin aikataulumielessä kuin henkilömielessä) voidaan kohtalaisen helposti arvioida karkeasti kertomalla toisillaan tapausten määrä yhden tapauksen hoitamiseen kuluvalla ajalla. Tätä sitten voidaan lähteä optimoimaan usealla eri tavalla, kuten rajoittamalla tapausten määrää, lyhentämällä yhden tapauksen läpimenoaikaa, vähentämällä prosessiaskelten väliin jäävää luppoaikaa, järjestämällä tehtäviä suoritettaviksi rinnatusten ja niin edelleen.

Palatkaamme äskeiseen ongelmanhallintatapaukseen. Perusvirhe oli se ajatus, että jokaisen häiriön syy oli selvitettävä formaalin ongelmanmäärityksen kautta. Nopealla laskelmalla näemme, että ajatus hyvä mutta business case huono. Koska elämme epätäydellisessä maailmassa, voimme suvaita valtaosan häiriöistä vain toteamalla, että tulipa ratkaistuksi. Suuressa osassa syy on ilmiselvä, eikä edellytä formaalia analyysiä. Vakavimmat voidaan ottaa jatkokäsittelyyn, jos sille nähdään kelvollinen business case.

Esimerkissämme päätettiin suodattaa 100 tiketistä 98 ja jatkokäsitellä kaksi. Tämä suhde voi olla lähellä sitä, mihin usein päädytään. Suodatus voidaan tehdä asettamalla katto henkilöresursseille, jatkokäsiteltävien tikettien määrälle, ongelmanhallinnan enimmäiskustannukselle jne.

Rahkeiden riittävyyttä ja toiminnan järkevyyttä on aihetta arvioida kaikessa työssä aika ajoin. Sellaistakin esimerkiksi on nähty, että asiakkaan ja palvelutoimittajan välisissä seurantakokouksissa on käsitelty joka ainut kuukauden aikana syntynyt tiketti. Hauska toki on tietää, mutta jos tikettejä syntyy muutamakin tuhat vuodessa, tähän asiaan kuluneen työajan määrä on varsin vaikeasti perusteltavissa.

Pitää paikkansa, että tietotekniikka on monimutkaista ja kaikki vaikuttaa kaikkeen. Se ei kuitenkaan ole hyvä syy rakentaa käsittämättömän monimutkaisia prosesseja. Usein käyttäjäkunnalla on taipumus hakea tapoja ohittaa moiset prosessit ja pahimmassa tapauksessa syntyy varjo-IT, joka on virallista prosessia helpommin saavutettavissa. Rotanpesäprosesseja on käytännössä mahdotonta järkevästi mitata, eli rahkeet eivät riitä edes sen arvioimiseen, onko prosessista hyötyä.