Muutuste juhtimine
Räägime sellest millised muudatused organisatsiooni kui tervikut ja konkreetseid teenuseid või funktsionaalsusi ees ootavad ning kuidas nendega toime tulla. Millised on nendega kaasnevad riskid ning kuidas neid maandada?
Kui eelnevas peatükis peatusime ainult põgusalt sellel, et peale veebikeskkonna avalikustamist on väga olulisel kohal suutlikkus muutustega kaasa minna ning neid korrektselt juhtida siis nüüd toome mõned olulisemad neist välja ning kirjeldame nad lahti.
Muudatused võib jagada nende tekkepõhjuste järgi seadusandlikeks, organisatoorseteks ja vea- ning kasutajapõhisteks.
- Seadusandlikud muutused tulenevad nagu nimigi ütleb seadustest või õigemini nende muudatustest. Nt lisanduvad uued toimingud, mida on võimalik läbi ametkondade sooritada või muutuvad olemasolevate lõivude suurused.
- Organisatoorsed muutused. Nendeks on tavaliselt, kas strateegia ja sellest lähtuva tegevuskava või eesmärkide muutused. Samuti stiiliraamatu loomine/uuendamine või tööprotsesside muutus.
- Vigadest lähtuvad muutused, mis avalduvad ennekõike avalikustamise perioodi järgselt, kuid mitte ainult. Siia alla kuuluvad kõik pärast arendustööde lõppu ja veebikeskkonna avalikustamist avastatud tehnilised, disainilised ja funktsionaalsed möödalaskmised, mis takistavad või mõjutavad loodud rakendusel töötamast viisil, millisena ta oli ette nähtud. Nt nupul vajutades ei avane uus vorm või mõnel veebilehel on abitekstid puudu.
- Kasutajapõhised muutused. Siinkohal võib muutuste põhjused kahte suurde rühma jagada – kasutajate oskus- ja ootuspõhistest vajadustest lähtuvateks muudatusteks.
Oskuspõhised vajadused on seotud peamiselt sellega, kui hästi kasutaja suudab tema jaoks loodud keskkonnas tegutseda ja teenuseid kasutada – kas see on tema jaoks arusaadav, loogilise ülesehitusega ning lihtsalt kasutatav (nt kas ta suudab iseseisvalt hakkama saada või vajab toimingute sooritamiseks klienditeenindaja abi või selgitusi).
Ootuspõhised vajadused on aga juba seotud kasutajate tunnetusliku poolega ja paljuski individuaalne. Igaüks ootab lähtudes oma harjumustest, mugavusest ning vajadustest (nt masskasutaja soovib toimingute sooritamisel võimalikult vähe infot sisestada, spetsialist aga vajab võimalust just vastupidiseks). Kuigi ootuspõhised vajadused on personaalsed võib nende puhul siiski välja tuua trende, millele toetudes e-teenuseid üles ehitada.
Kuigi muutuste käivitamiseks võivad olla eelpool nimetatud põhjused siis haldusorganisatsiooni töölauale jõuavad nad tavaliselt järgnevate tegevustena, mis tuleb jooksvalt suuta e-teenuste keskkonnas või funktsionaalsustes ära lahendada:
- Muudatused e-teenuse aluseks oleva teenuse põhimõtetes. Maanteeameti näitel on selliseks muudatuseks näiteks omanikuvahetuse protsessis täiendava nõutava kinnituse tekkimine või sõiduki kasutajate muutmisel täiendavate andmete küsimine.
Sellised muudatused võivad piirduda vaid ühe lisavälja tekitamisega, mis ei nõua teenuse fundamentaalset ümbertegemist, kuid võivad samas muutuda suuremahulisteks ettevõtmisteks, kus on vaja kogu funktsionaalsus ümber teha. Mõlemal juhul on siiski vajalik nii kasutatavuse spetsialisti (või disaineri) kui ka IT arenduse poolset muudatuse analüüsimist ja realiseerimist.
Riskid: …
Vastumeetmed: Puuduvad. Tegu on üldjuhul vältimatute muudatustega, mis tulenevad, kas seadusandlikest või organisatoorsetest nõuetest. Siinkohal on pigem olulisel kohal muudatuste sisseviimise oskuslik juhtimine, kasutajate piisav teavitus ning tööde ajastamine.
Lahenduse aeg: Tavaliselt piirdub selliste muudatuste parandamine kergemal juhul mõnepäevase analüüsiga, keerulisematel kordadel aga kuni mitu kuud kestva tööga. Juhul, kui muudatuste tõttu tuleb kogu teenus fundamentaalselt ümber mõelda, kas kasutatavuse ja/või IT arhitektuuri seisukohast, tuleb sellest arendusest algatada täiesti uus e-teenuse arendusprojekt.
Vajalikud rollid: Teenuse omanik annab sisendi kanali omanikule, mille põhjal disainer ja kasutatavuse analüütik joonistavad uuendatud pildi. IT analüütik ning arendajad hoolitsevad muudatuse väljatöötamise eest. Üldjuhul nõuab taoline muudatus hoolikat testimist ning muudatused toimuvad vastavalt organisatsiooni avalikustamisplaanile.
- Muudatused funktsionaalsustes kasutatavates parameetrites, sh hindades ja vaikeväärtustes. Näiteks muutub funktsionaalsuses eelistatud kontaktikanal, muutub teenuse eest võetav hind, lisandub juurde mõni vaikeväärtus või kaob üks taotluse esitamisviisidest.
Järjekordselt on tegu muudatustega, mis võivad piirduda vaid ühe parameetri või väärtuse muutmise/lisamise/kaotamisega, mis ei vaja kogu teenuse fundamentaalset ümbertegemist. Sellised muudatused nõuavad kas süsteemi peakasutaja või arendaja väiksemamahulist tööd. Taolised muudatused üldjuhul disaini- ja kasutatavuse töid ei vaja v.a kui muutub suur hulk väärtusi või parameetreid korraga.
Riskid: …
Vastumeetmed: …
Lahenduse aeg: Kergematel juhtudel pole sisuliseks analüüsiks vajadust ning piirdutakse peakasutaja ja arendaja poolsete jooksvate muudatuste sisseviimisega läbi sisuhaldussüsteemi, mis on ühe-kahe päeva töö. Raskematel juhtudel tuleb kaasata ka analüütikut ja disainerit ning muudatuste elluviimise periood võib venida nädala-paarini.
Vajalikud rollid: Teenuse omanikult jõuab sisend kanali omanikule, kes koos vajalike IT spetsialistidega või endale loodud haldusvõimalustega viib muudatused süsteemi sisse. Muudatus nõuab lihtsamat kuni keskmist testimist, muudatused jõustuvad tavaliselt võimalikult kiiresti.
- Teenuste lisandumine, muutumine või kadumine keskkonnast, teenuste ümberstruktureerimine. Näitenatekib senise kolme juhtimisõiguse taotlemise asemele neid 12, lisandub sõiduki andmete detailpäring või liidetakse mõned teenused alajaotuses kokku ühe menüüpunkti alla.
Nõuab tavapäraselt keskkonna sisu ja menüü ümberkorraldusi, et muutunud teenuste hulka või paigutust ära mahutada.
Riskid: …
Vastumeetmed: …
Lahenduse aeg: …
Vajalikud rollid: Juhul, kui muudatused mõjutavad oluliselt 1. või 2. taseme menüüsid, tuleb kasutada kasutatavuse analüütiku ja disaineri abi, muudel juhtudel piisab muudatuste tegemiseks kanali omanikust, kes vastavalt kommunikatsiooniüksuse või teenuse omaniku sisendile töötab välja struktuuri uue, kohandatud versiooni ning realiseerib selle enda kasutuses olevate võimaluste piires või laseb muudatused teha vastava IT alamlõigu eest vastutaval isikul. Muudatused võivad vajada testimist, kui nad on mahukad, muul juhul piisab kiirest kontrollist kanali omaniku poolt.
- Keskkonna disainimuudatused. Näiteks muutub organisatsiooni stiiliraamat ning selle tulemusel keskkonna värvilahendus, kohendada tuleb parema kasutatavuse tulemusel nuppude, tabelite, vormide ja keskkonna teiste osade visuaalset lahendust. Vajalikud rollid: kanali omanik koos kommunikatsiooniüksuse (või teise stiiliraamatu eest vastutajaga) töötab välja uued nõuded. Sealt jõuab töö disaineri ja kasutatavusanalüütiku lauale, kelle piltide põhjal teeeb oma töö ära IT arendus (eriti front end arendaja). Vajab kommunikatsiooniüksuse tuge stiiliraamatu osas ning võib vajada IT operatsioonide eest vastutava isiku tööd. Juhul, kui muudatused on väga suured, tuleb algatada kogu e-teenuse keskkonna ümbertegemise projekt vastavalt käesolevale käsiraamatule. Muudatused vajavad kindlasti põhjalikku ning keskkonna kõiki lehekülgi puudutavat testimist ning viimistlemisperioodi nii IT arenduse kui disaineri poolt.
- Keskkonna sisumuudatused, sh tekstide, veateadete, selgitavate materjalide muudatused. Siia alla kuuluvad ka kõikvõimaliku lisainfo juurdetulek, teenuste tingimuste muudatused ning muu tekstiline materjal. Vajalikud rollid: teenuse omaniku või kommunikatsiooniüksuse käest jõuavad kanali omaniku kätte muudatusvajadused, kes vajalikud kohendused läbi töötab. Kanali omanik viib muudatused ellu üldjuhul ise vastavalt oma haldusvõimalustele ja –võimekusele, suuremahuliste ja keeruliste muudatuste korral teeb muudatused kas veebihalduse koostööpartner või IT haldusorganisatsioon. Taolistest muudatustest peab valdav osa olema tehtav ilma IT sekkumisvajaduseta, selleks peavad vastavad vahendid ja kompetents kanali omaniku juures olemas olema. Kvaliteedi mõttes tuleb vältida halduse laialijagamist kõikidele teenuste omanikele või muudele tugirollidele – sisulised muudatused peavad olema tehtud sarnases disaini, keelestiili ning tehnilises võtmes. Väiksemate muudatuste korral eraldiseisev testimine tarvilik ei ole, suuremate muudatuste korral tulevad lisaks kaasa tavaliselt ka disainimuudatused, mille raames testimine ka läbi viiakse.