Lue lisää: |
Matti Grönroos
Keskustelu käytettävyystavoitteista ajautuu hakoteille, jos ajatellaan palveluita yhtenä isona massana, jossa kaikkia käsitellään samalla tavoin. Jos kuljetaan kriittisimmän mukaan, kokonaisuudesta voi tulla todella kallis, ja jos kuljetaan keskiarvon mukaan, kriittiset liiketoiminnot saattavat vaarantua.
Järjestelmien kriittisyyskään ei aina ole vakio, vaan se saattaa muuttua kausivaihtelujen mukana. Yhden koon sukkahousut eivät siis nytkään toimi.
Palvelutasotavoitteiden asettaminen on aika tarkkaa hommaa. Toisaalta liian korkeaa tai matalaa palvelutasoa ei pitäisi sallia, mutta toisaalta jos tavoitteet asetetaan jokaiselle palvelulle erikseen, lopputulos on yleensä vallaton sekasotku.
Usein ratkaisu on luokitella palvelut muutamaan (3–4) kriittisyysluokkaan ja asettaa käytettävyysvaatimukset luokkakohtaisesti. Tämä on yleensä riittävä kompromissi kriittisyyden ja mallin yksinkertaisuuden välillä. Luokitus ei saisi olla staattinen, vaan sitä pitäisi kyetä säätämään muutosten tai kausivaihteluiden yhteydessä.
Usein vallitsee myös se näköharha, että kriittisyys tarkoittaa automaattisesti myös tarvetta laajaan palveluaikaan. Tämä ei välttämättä pidä paikkansa. Esimerkiksi tilaustenkäsittelyjärjestelmä saattaa hyvinkin olla erittäin kriittinen silloin, kun tilaustenkäsittelijät ovat töissä, mutta muulloin sen käytettävyydellä ei juuri ole väliä. Tai toisin päin: Internetissä kuluttajia palveleva verkkokauppa saattaa aamuyöllä tuottaa verraten pienen osan vuorokauden liikevaihdosta, mutta sen toistuva pois päältä oleminen vaikuttaa nopeasti verkkokaupan maineeseen.
Luokituksia asetettaessa on muistettava, että järjestelmät ovat yleensä osa arvoketjua ja ketju on enintään niin vahva kuin on sen sen heikoin lenkki. Siksi jos ketjussa on kriittinen järjestelmä, kaikkien ketjun lenkkien tulee olla kriittisiä. Tässä tulee ottaa huomioon järjestelmien kerrostuneisuus: Jos esimerkiksi tiedonhallintajärjestelmä palvelee useita järjestelmiä, sen kriittisyyden tulee olla kriittisimmän järjestelmän mukainen.
Kaaviossa punainen väri edustaa kriittisintä tasoa. Paradoksihan on, että jos vähemmän kriittiset järjestelmät B–E menettävät tiedonhallintajärjestelmänsä, tilanne pitää hoitaa kriittisenä.
Jos järjestelmiä on vähänkään suurempi määrä, on aihetta suunnitella se, että kaikilla toimintaan liittyvillä tahoilla on ajantasainen näkemys kunkin järjestelmän kriittisyysluokasta. Konfiguraatiotietokanta saattaa olla oiva paikka tällaisen tiedon ylläpitämiseksi sillä edellytyksellä, että konfiguraationhallinnan prosessi toimii ja että se ulottuu kaikille tahoille.
Käytettävyysluokittelu on asiallista lisätä myös käyttäjille osoitettavaan dokumentaatioon odotusten hallinnan nimissä.