Haldusprotsessi mudel
Haldusprotsessi on võimalik üles ehitada mitmel moel, kuid autorite jaoks on välja kujunenud soovituslik mudel, mille toimimine on kinnitust leidnud mitmete organisatsioonide nii keskmiste kui ka suurte arendusprojektide najal. Mudel on skaleeritav ning toimib nii juhul, kui haldusorganisatsioon koosneb paarist või paarikümnest ametikohast.
Mudeli võtmekohaks on kogu haldustegevuse suunamine läbi kanali omaniku juures oleva üldise meiliaadressi ning kogu haldusprotsessis isikustamise vältimine. See tähendab, et tellija jaoks ei ole vahet, kas konkreetse töö teeb ära organisatsioonisisene töötaja või väline koostööpartner, tema informeerib oma vajadustest ühtmoodi kanali omanikku või tema juures olevat arendusspetsialisti. Samamoodi ei tohi haldusorganisatsiooni täideviiv osa (webmasterid, IT spetsialistid, disainerid jt) saada otseselt tööülesandeid tellijatelt, vaid alati läbi kanali omaniku filtri. Juhul, kui seda filtrit mitte kasutada, siis kaob aja jooksul kõikide väikeste muudatuste tulemusel ära kanali ühtne nägu ning kanali omanik ei suuda e-teenustest maksimumi välja võtta. Haldustöös peab olema tagatud täpselt samasugune kvaliteet ja stiililine ühtsus nagu arendustöö käigus.
Kanali omaniku roll on ka kõiki haldustöid prioritiseerida. On inimlik, et iga omaniku jaoks tundub tema valdkonda puudutav muudatus kõige olulisem ja kiirem, kuid kanali omanik vastutab selle eest, et tema käsutada olev haldusorganisatsioon teeks igal ajahetkel kõige olulisemaid töid. Siin tuleb välja ka ühise tellimuste kanali (ühise meiliaadressi) peamine eelis – kõik tööd, millega haldajad tegelevad, on olemas ühises tööde nimekirjas, millest on kanali omanikul hea ülevaade.
Juhul, kui tööd liiguvad spetsialistide vahel otse, siis puudub kanali omanikul igasugune arusaam sellest, kas haldusorganisatsioon tegeleb õigete töödega ning kui koormatud erinevad ametikohad tegelikult on. Ülevaade ja kontroll on need, mida antud mudel eelkõige pakub.
Protsessi lühidalt kirjeldades – ükskõik millised organisatsioonisisesed tellijad, aga peamiselt teenuste omanikud ja kommunikatsioonispetsialistid saadavad oma muudatussoovid ja vajadused kõik ühele meiliaadressile. Selle aadressi taga olev kanali omaniku arendusspetsialist suhtleb kõikide tellijatega, täpsustab ülesannet ning vajadusel lepib kokku parema / kiirema lahenduse töö elluviimiseks.
Kanali omaniku poolt lepitakse kokku ka tellimuse täitmiseks sobiv aeg, arvestades teisi töid ning erinevate osapoolte hõivatust. Kanali omanik peab siinkohal tellimusse võimalikult sisuliselt sisse vaatama ning pakkuma välja võimalikult hea lahenduse nii kanali kui tellija vaates.
Kanali omanikust algavad erinevad tööahelad sõltuvalt töö iseloomust ja keerukusest. Juhul, kui haldustöö on niivõrd suur, et nõuab täiesti uue arendusprojekti algatamist, siis kanali omanik käivitab kokkuleppele tellijaga vastava arendusprotsessi. Kui tegemist on muudatusega, mille jaoks ei ole tarvis muud kui webmasteri tööd, siis prioritiseerib kanali omanik vastava töö ning see läheb webmasteri tööde järjekorda sobivale kohale. Kuna webmasteri töölaual on töid väga erineva kaaluga, siis lihtsalt ajalises järjekorras tööde tegemine tavaliselt head tulemust ei anna.
Kui töö on keerukam, aga kanali haldajate poolt endiselt ilma IT abita tehtav, siis suunab kanali omanik töö kõigepealt kasutatavuse spetsialisti ja disaineri kätte, sealt vajadusel keeletoimetajale ning lõpuks webmasteri kätte. Töö, mis nõuab peamiselt IT panustamist, peab üldjuhul liikuma läbi IT projektijuhi, kes selle töö juba suunab edasi vajalikule analüütikule, arendajale või administraatorile. Kanali omanikule on väga hea, kui ta ei pea samamoodi IT-s suhtlema paljude erinevate inimestega, vaid IT-s on samuti üks selge vastutaja, kes hoolitseb kõikide kanali omaniku poolt tulevate tellimuste täideviimise eest.
Protsesside osas on võimalikud ka kombineerimisvariandid, kus töö on küll haldusorganisatsiooni poolt tehtav, aga nõuab nii disaineri, keeletoimetaja kui IT spetsialistide panust. Sellisel juhul jääb põhiprintsiip samaks – kanali omanik hoolitseb disaini/sisu/webmasteri ahela toimimise eest ning IT projektijuht oma valdkonna realiseerimise eest.
Üldjuhul tuleb töökorraldus sisse seada nii, et tööd saavad tehtud hiljemalt 3 tööpäeva jooksul. Kiirema reageerimisvõime korral on asutuses liigseid ressursse ning samas ei ole 3 tööpäeva nii pikk aeg, et tellija ei suudaks muudatusvajaduse korral oma tegevust pikemalt ette planeerida.
Tavaliselt on muudatused pikaajalised ning 3 päeva varem sellest kanali haldajatele teada anda on igati õigustatud ootus. On siiski olemas ka erandid, kus on mõistlik luua kiirem töömudel – näiteks uudiste ja pressiteadete korral on otstarbekas sõlmida eraldiseisvad kokkulepped nende kiiremaks ülespanemiseks. Sellisel juhul toimub info liikumine endiselt läbi ühise meiliaadressi, kuid on teada, et nende tööde puhul ei kasutata enam ülekinnitamist ja arutelu, vaid tegemist on piisavalt standardsete töödega, et need toimuksid ära juba väljakujunenud kiirprotsessi kaudu.