ISO/IEC 20000-1, klauzula 8.5.1 — Upravljanje promenama

Šta standard zahteva

Politika upravljanja promenama (8.5.1.1) mora biti uspostavljena i dokumentovana, i mora da definiše:

• komponente usluga i druge stavke koje su pod kontrolom upravljanja promenama;
• kategorije promena, uključujući hitnu promenu, i kako se njima upravlja;
• kriterijume za određivanje promena koje mogu imati veliki uticaj na korisnike ili usluge.

Pokretanje promene (8.5.1.2): zahtevi za promenu, uključujući predloge za dodavanje, uklanjanje ili prenos usluga, moraju biti evidentirani i klasifikovani. Organizacija mora da koristi proces dizajna i tranzicije usluge (klauzula 8.5.2) za: nove usluge sa potencijalno velikim uticajem na korisnike ili druge usluge; izmene usluga sa potencijalno velikim uticajem; kategorije promena koje politika određuje da idu kroz taj proces; uklanjanje usluge; i prenos usluge između organizacije i korisnika ili druge strane u bilo kom pravcu. Procena, odobravanje, planiranje i pregled novih ili izmenjenih usluga u okviru 8.5.2 upravlja se kroz aktivnosti upravljanja promenama iz 8.5.1.3 — kao i svi ostali zahtevi za promenu koji ne idu kroz 8.5.2.

Aktivnosti upravljanja promenama (8.5.1.3): organizacija i zainteresovane strane donose odluke o odobrenju i prioritetu zahteva za promenu, uzimajući u obzir rizike, poslovnu korist, izvodljivost i finansijski uticaj, kao i potencijalni uticaj promene na:

• postojeće usluge;
• korisnike, krajnje korisnike i druge zainteresovane strane;
• politike i planove koje zahteva ovaj standard;
• kapacitet, dostupnost usluge, kontinuitet usluge i informacionu bezbednost;
• druge zahteve za promenu, izdanja i planove implementacije.

Odobrene promene moraju biti pripremljene, verifikovane i, gde je moguće, testirane. Predloženi datumi implementacije i drugi detalji moraju biti komunicirani zainteresovanim stranama. Aktivnosti za poništavanje ili ispravljanje neuspešne promene moraju biti planirane i, gde je moguće, testirane. Neuspešne promene moraju biti istražene, a dogovorene mere preduzete. Organizacija mora da pregleda promene radi ocene njihove efektivnosti i preduzme mere dogovorene sa zainteresovanim stranama. U planiranim intervalima, evidencije zahteva za promenu analiziraju se radi otkrivanja trendova, a rezultati i zaključci se beleže i pregledaju radi prepoznavanja prilika za unapređenje.

Primer

Primer: IT sektor Adria Trade-a planira nadogradnju softvera na svim POS terminalima. Politika upravljanja promenama već jasno definiše da su POS softver, ERP konfiguracija i mrežna oprema pod kontrolom promena, da postoje tri kategorije promena (standardna, normalna i hitna), i da se promena koja utiče na više od pet prodavnica odjednom automatski smatra promenom sa velikim uticajem. Kad se zahtev za nadogradnju evidentira, klasifikuje se kao promena sa velikim uticajem (utiče na svih 40 prodavnica), pa ide kroz temeljniji proces dizajna i tranzicije usluge iz 8.5.2. IT sektor i predstavnik prodajnog sektora zajednički odlučuju o odobrenju, razmatrajući rizik od ispada tokom nadogradnje, poslovnu korist (nove funkcije kase), izvodljivost i trošak, kao i uticaj na postojeći kapacitet i na već zakazane promene te nedelje. Odobrena nadogradnja se prvo testira u jednoj prodavnici, datum implementacije za ostale se unapred najavljuje rukovodiocima prodavnica, a unapred je pripremljen i testiran plan povratka na prethodnu verziju. Kad se na jednoj od prodavnica nadogradnja pokaže neuspešnom (kase počinju da se zamrzavaju), odmah se sprovodi plan povratka, uzrok se istražuje, a dogovorena mera (ispravka pre ponovnog pokušaja) se sprovodi pre nastavka rasporeda na ostale lokacije. Mesec dana kasnije IT sektor proverava da li je nadogradnja stvarno rešila prvobitni problem. Kvartalno se svi zahtevi za promenu analiziraju zajedno — na primer, kad se uoči da promene planirane petkom popodne češće ne uspevaju, to postaje konkretna prilika za unapređenje procesa zakazivanja.

Za hitne promene — na primer, bezbednosnu zakrpu koja mora da se primeni odmah — politika predviđa skraćenu proceduru odobravanja, ali promena se i dalje evidentira i naknadno pregleda na isti način kao i svaka druga.

Šta treba uraditi

• Napisati i dokumentovati politiku upravljanja promenama koja jasno navodi šta je pod kontrolom promena, koje kategorije promena postoje (uključujući hitnu), i po kom kriterijumu se promena smatra potencijalno velikog uticaja.
• Evidentirati i klasifikovati svaki zahtev za promenu, uključujući predloge za dodavanje, uklanjanje ili prenos čitavih usluga, ne samo tehničke izmene.
• Usmeriti nove ili izmenjene usluge sa potencijalno velikim uticajem kroz temeljniji proces dizajna i tranzicije (klauzula 8.5.2), a sve ostale zahteve kroz standardne aktivnosti upravljanja promenama.
• Uključiti relevantne zainteresovane strane, ne samo IT tim, u odlučivanje o odobrenju i prioritetu — poslovni predstavnik često vidi uticaj koji tehnički tim ne vidi.
• Pre odobrenja razmotriti sve navedene uticaje — na postojeće usluge, korisnike, kapacitet, dostupnost, kontinuitet, bezbednost i druge planirane promene — ne samo tehničku izvodljivost.
• Pripremiti i, gde je moguće, testirati promenu pre implementacije, i unapred komunicirati datum i detalje implementacije zainteresovanim stranama.
• Unapred pripremiti i testirati plan za poništavanje ili ispravljanje promene — ne improvizovati rollback tek kad promena krene po zlu.
• Svaku neuspešnu promenu istražiti i sprovesti dogovorene mere, umesto da se samo pokuša ponovo bez razumevanja šta je pošlo po zlu.
• Posle implementacije proveriti da li je promena stvarno postigla očekivani efekat, ne samo da li je tehnički sprovedena.
• Periodično analizirati sve zahteve za promenu zajedno radi otkrivanja obrazaca — pojedinačna promena retko otkriva ono što postane vidljivo tek kad se pogleda više njih zajedno.