Teknillisen korkeakoulun matkahallintajärjestelmän ... - TML - TKK
Teknillisen korkeakoulun matkahallintajärjestelmän ... - TML - TKK
Teknillisen korkeakoulun matkahallintajärjestelmän ... - TML - TKK
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
tävyys on heikko ja ohjeistus on olematonta. Järjestelmien käytettävyyttä ei kuitenkaan<br />
paranneta, vaikka heikko käytettävyys olisikin tiedossa. Järjestelmiin saatetaan tehdä<br />
marginaalisia muutoksia, mutta todellinen kehitys vaatisi järjestelmän uudelleen suunnittelua<br />
ja rakentamista. Uusia järjestelmiä tuleekin käyttöön kaiken aikaa ja samalla<br />
vanhoja järjestelmiä poistetaan käytöstä.<br />
Esimerkiksi kelvollinen WWWTopi korvattiin Webtopilla, jonka käytettävyys<br />
oli selvästi edeltänyttä järjestelmää heikompi. Webtopista kuitenkin luovuttiin muutaman<br />
vuoden päästä ja tilalle hankittiin WebOodi. Olisi varmasti ollut taloudellisesti<br />
kannattavampaa ja käyttäjien kannalta miellyttävämpää, että järjestelmän käytettävyyttä<br />
olisi testattu asiantuntevasti, ennen kuin se otettiin käyttöön laajasti.<br />
Monet järjestelmät otetaankin käyttöön portaittain. Esimerkiksi Travel on otettu<br />
käyttöön ensiksi muutamalla osastolla ja sitten laajennettu koko <strong>TKK</strong>:n käyttöön. Samalla<br />
tavalla Noppakin lanseerattiin käyttöön. "Pilotoinnissa varmistettiin, että Noppaportaali<br />
on teknisesti valmis tuotantokäyttöön" [18]. Olisiko tarpeellista, että tuossa pilotointivaiheessa<br />
kiinnitettäisiin käytettävyyteen, sekä järjestelmän tarkoitusperään huomiota?<br />
Vaikuttaa siltä, että järjestelmät otetaan suoraan käyttöön pilotoinnin jälkeen,<br />
vaikka käyttäjät eivät olisi siihen tyytyväisiä. Mikäli järjestelmä on käytettävyydeltään<br />
heikko, se tulisi hylätä tai sitä tulisi kehittää vastaamaan tarpeita. Kehityksessä pelkkä<br />
ulkoasun muokkaus ei riitä, mikäli tarkoitusperät eivät vastaa käyttäjän mallia tai käyttäjätarpeita<br />
ei ole kunnolla huomioitu.<br />
Yleinen linja taitaa olla se, että järjestelmiä kehitetään vain niiltä osin, mikä on<br />
tarpeeksi halpaa. Tällainen tyyli ei käytännössä ratkaise kovinkaan monia ongelmia, jolloin<br />
seurauksena on epäkäytännöllisten järjestelmien verkko. Ongelmat kumuloituvat<br />
järjestelmämäärien kasvaessa, sillä tällöin pitää esimerkiksi muistaa enemmän salasanoja.<br />
Järjestelmiä ei kehitetä, mutta niiden käyttäjiä kyllä. Teknillinen korkeakoulu tarjoaa<br />
tuon tuostakin koulutustilaisuuksia, joilla ilmeisesti kuvitellaan ratkaisevan järjestelmien<br />
käyttöön liittyvät ongelmat. Todellisuudessa käyttäjät eivät kuitenkaan ole kiinnostuneita<br />
käyttämään työaikaansa kouluttautumiseen, sillä koulutustilaisuudet todettiin hyvin<br />
hyödyttömiksi.<br />
Mikäli kilpailutetaan järjestelmiä vain hinnan perusteella, lähtökohtana on se, että<br />
pyritään tekemään mahdollisimman halpa järjestelmä. Tämä taas käytännössä tarkoittaa<br />
sitä, että pyritään käyttämään mahdollisimman vähän resursseja suunnitteluun, toteuttamiseen<br />
ja testaamiseen, mikä tietenkin näkyy heikompana laatuna. Kilpailutuksessa<br />
tulisikin arvioida järjestelmiä ennemmin laadun, kuin hinnan kannalta.<br />
Järjestelmien kehittäminen käyttäjälähtöisesti vaatii syvällisen analyysin järjestelmän<br />
käyttökontekstista. Tämä taas vaatii panostusta ja resursseja. Samoin käyttöliittymän<br />
suunnitteluun tulee panostaa, mikäli siitä halutaan helppokäyttöinen. Useat käytettävyysmenetelmät<br />
ovat melkoisen raskaita ja niistä ei välttämättä saada irti niin paljon<br />
kuin voisi olettaa, mutta jos menetelmiä soveltaa ja yrittää keventää liiaksi, voivat tulokset<br />
jäädä hyvin laihoiksi. Käytettävyystutkimus tulisi myös tehdä tarpeeksi ajoissa, sillä<br />
valmiiseen ja jo käyttöön otettuun järjestelmään on vaikeaa tehdä muutoksia varsinkin,<br />
jos tarvittavat muutokset koskettavat isompaa kokonaisuutta.<br />
Tutkimuksessa huomattiin, että merkittävimmät muutokset matkahallintajärjestelmään<br />
eivät ole kovin hankalia, mutta vaativat muutoksia laajalta osalta järjestelmää.<br />
Mikäli käyttäjätarpeet olisi huomioitu paremmin jo järjestelmän suunnitteluvaiheessa,<br />
olisi esimerkiksi tämän raportin parannusehdotukset voitu lisätä jo ennen järjestelmän<br />
käyttöönottoa. On kuitenkin syytä huomata, että vasta kun järjestelmiä testataan niiden<br />
84