ISO/IEC 20000-1, klauzula 8.5.2 — Dizajn i tranzicija usluge

Šta standard zahteva

Planiranje novih ili izmenjenih usluga (8.5.2.1) mora da koristi zahteve usluga određene u 8.2.2 i da uključi ili upućuje na:

• ovlašćenja i odgovornosti za aktivnosti dizajna, izgradnje i tranzicije;
• aktivnosti koje sprovodi organizacija ili druge strane, sa vremenskim okvirima;
• ljudske, tehničke, informacione i finansijske resurse;
• zavisnosti od drugih usluga;
• testiranje potrebno za novu ili izmenjenu uslugu;
• kriterijume prihvatanja usluge;
• planirane ishode isporuke usluge, izražene u merljivim terminima;
• uticaj na SMS, druge usluge, planirane promene, korisnike i druge zainteresovane strane.

Za usluge koje se ukidaju, planiranje dodatno mora da uključi datume ukidanja i aktivnosti arhiviranja, uklanjanja ili prenosa podataka. Za usluge koje se prenose, planiranje dodatno mora da uključi datume prenosa i aktivnosti prenosa podataka, dokumentacije, znanja i komponenti usluge. Konfiguracione stavke pogođene novom ili izmenjenom uslugom moraju biti upravljane kroz upravljanje konfiguracijom.

Dizajn (8.5.2.2): nova ili izmenjena usluga mora biti dizajnirana i dokumentovana tako da ispuni zahteve iz 8.2.2. Dizajn mora da uključi relevantne stavke: ovlašćenja i odgovornosti strana uključenih u isporuku; zahteve za izmenu resursa; zahteve za obrazovanje, obuku i iskustvo; nove ili izmenjene SLA ugovore i druge dogovore; izmene SMS-a (politike, planovi, procesi, procedure, mere, znanje); uticaj na druge usluge; i ažuriranja kataloga usluga.

Izgradnja i tranzicija (8.5.2.3): nova ili izmenjena usluga mora biti izgrađena i testirana kako bi se proverilo da ispunjava zahteve usluga, da je usaglašena sa dokumentovanim dizajnom i da ispunjava dogovorene kriterijume prihvatanja. Ako kriterijumi prihvatanja nisu ispunjeni, organizacija i zainteresovane strane donose odluku o potrebnim merama i o implementaciji. Upravljanje izdanjima i implementacijom koristi se za implementaciju odobrenih novih ili izmenjenih usluga u produkciono okruženje.

Primer

Primer: IT sektor Adria Trade-a uvodi novu uslugu — podršku za samouslužne kase, ranije prepoznatu kao mogući projekat u klauzuli 8.2.2. Planiranje polazi od zahteva definisanih u 8.2.2 i uključuje: ovlašćenja (service delivery menadžer vodi projekat, dobavljač opreme odgovoran za instalaciju), aktivnosti sa rokovima (nabavka u prvom mesecu, pilot instalacija u drugom, testiranje u trećem), potrebne resurse (budžet i jedan dodatni tehnički resurs), zavisnosti (od postojeće POS infrastrukture i mrežne veze), potrebno testiranje (pilot u jednoj prodavnici pre šireg uvođenja), kriterijume prihvatanja (najmanje 95% transakcija uspešno obrađeno bez pomoći osoblja), merljiv planirani ishod (smanjenje prosečnog vremena čekanja na kasi za određeni procenat) i uticaj na postojeće usluge (dodatno opterećenje service deska tokom prvih nedelja).

U fazi dizajna definišu se: ko je odgovoran za svakodnevnu podršku novim uređajima, koja obuka je potrebna zaposlenima u prodavnicama i agentima service deska, novi SLA specifičan za ovu uslugu, izmene u SMS-u (nova procedura za rešavanje tipičnih problema sa samouslužnim kasama), uticaj na uslugu podrške POS sistemu (sa kojom deli deo infrastrukture), i ažuriranje kataloga usluga da uključi novu stavku.

U fazi izgradnje i tranzicije, oprema se instalira i testira u pilot prodavnici. Kad se pokaže da stopa uspešnih transakcija bez asistencije iznosi samo 88%, ispod dogovorenog kriterijuma od 95%, IT sektor i predstavnik prodajnog sektora zajednički odlučuju da se implementacija odloži dok se ne prilagodi softver uređaja, umesto da se nastavi širenje uz poznat nedostatak. Kad se kriterijum kasnije ispuni, odobrena usluga se uvodi u ostale prodavnice kroz proces upravljanja izdanjima i implementacijom.

Šta treba uraditi

• Za svaku novu ili izmenjenu uslugu krenuti od već dokumentovanih zahteva iz 8.2.2, ne planirati odvojeno od onoga što je već utvrđeno.
• Proći kroz svih osam elemenata planiranja — ovlašćenja, aktivnosti sa rokovima, resurse, zavisnosti, potrebno testiranje, kriterijume prihvatanja, merljive planirane ishode i uticaj na SMS i druge strane — kako ništa bitno ne bi ostalo nerazmotreno.
• Za usluge koje se ukidaju ili prenose, dodatno planirati konkretne datume i aktivnosti vezane za podatke, dokumentaciju, znanje i komponente — ovo se lako zaboravi kad je fokus na uvođenju nečeg novog, a ne na ukidanju starog.
• Povezati pogođene konfiguracione stavke sa upravljanjem konfiguracijom (klauzula 8.2.6), umesto da promena ostane nezabeležena u konfiguracionim podacima.
• Formalno dizajnirati uslugu pre nego što se počne sa izgradnjom — odrediti ko je odgovoran, koje resurse i obuku treba obezbediti, koje SLA i dogovore treba ažurirati, i koje izmene SMS-a su potrebne.
• Testirati novu ili izmenjenu uslugu naspram zahteva, dizajna i dogovorenih kriterijuma prihvatanja pre punog uvođenja — po mogućstvu prvo na manjem uzorku (pilot), a ne odjednom svuda.
• Imati jasan proces odlučivanja za slučaj da kriterijumi prihvatanja nisu ispunjeni — unapred dogovoriti ko odlučuje da li se implementacija odlaže, prilagođava ili ipak nastavlja, umesto da se ta odluka donosi u hodu.
• Implementaciju odobrenih usluga sprovoditi kroz proces upravljanja izdanjima i implementacijom, koji se detaljnije obrađuje u narednoj klauzuli — ne uvoditi promene u produkciju mimo tog procesa.
• Po završetku tranzicije, izveštavati zainteresovane strane o tome da li su planirani, merljivi ishodi stvarno ostvareni — ne zaustaviti se na tome da je usluga tehnički uvedena.