SLA za poslovni sistem: kaj naj vsebuje pogodba

Zakaj poslovni sistem potrebuje SLA#

Poslovni informacijski sistem po uvedbi v produkcijsko okolje ne preneha zahtevati pozornosti. Uporabniki sčasoma naletijo na napake, obremenitev sistema se spreminja glede na sezono ali rast poslovanja, integracije z drugimi sistemi pa se posodabljajo neodvisno od naročnika. Vprašanje zato ni, ali bo prišlo do motnje v delovanju, temveč kako hitro in po kakšnem dogovorjenem postopku bo organizacija nanjo odgovorila. SLA, dogovor o ravni storitev, je pogodbeni okvir, ki to vprašanje reši vnaprej, še preden do motnje sploh pride.

Brez SLA pogodbe se odzivnost dogovarja od primera do primera. Naročnik pogosto ne ve, koga poklicati, izvajalec ne ve, katera napaka ima prednost pred drugo, izpad pa se lahko podaljša zgolj zato, ker ni jasno, kdo mora ukrepati naslednji. Tovrstna negotovost stane največ takrat, ko sistem podpira ključen poslovni proces in vsaka ura izpada neposredno vpliva na delo uporabnikov, strank ali zaposlenih, ki so od sistema odvisni.

SLA pogodba določi razrede napak, način prijave, odgovornosti na obeh straneh in postopek eskalacije, če se dogovorjen rok ne izpolni. Enako velja za javni sektor, kjer informacijski sistemi in portali pogosto zahtevajo dokumentiran postopek podpore, kot za zasebna podjetja, ki vzdržujejo lastne poslovne aplikacije, portale ali SaaS platforme. Vsebina SLA se med panogami razlikuje, struktura pogodbe pa ostaja v osnovi enaka.

Razredi napak in prednostna obravnava#

Prvi korak pri sestavi SLA pogodbe je uskladitev razredov napak. Ne pomenijo vse motnje enake stopnje nujnosti, zato mora pogodba jasno opredeliti, katera situacija sodi v kateri razred in kaj to pomeni za nadaljnjo obravnavo. Brez te delitve se vsaka prijava obravnava enako, kar v praksi pomeni, da manjša kozmetična napaka čaka v isti vrsti kot popoln izpad sistema, kar podaljša odziv tam, kjer je hitrost dejansko pomembna.

• Razred 1 – izpad: sistem ali njegov ključni del ne deluje; obravnava ima najvišjo prednost, odzivni čas je dogovorjen v pogodbi o podpori.
• Razred 2 – motnja: sistem deluje, posamezna funkcija pa ne; obravnava poteka po prednosti, določeni v pogodbi.
• Razred 3 – napaka: manjša napaka brez vpliva na poslovanje; uvrsti se v naslednjo redno objavo.
• Razred 4 – zahteva: sprememba ali nadgradnja sistema; obseg se oceni, termin pa se uskladi z naročnikom.

#

Delitev na štiri razrede omogoča, da se omejena kapaciteta podpore usmeri tja, kjer je učinek največji. Izpad ključnega sistema se obravnava takoj, medtem ko se zahteva za novo funkcionalnost umesti v redni razvojni tok. Naročnik s tem dobi predvidljivost, saj ve, kaj lahko pričakuje pri posamezni vrsti prijave, izvajalec pa dobi jasno merilo, po katerem razporeja delo ekipe med odpravo napak in razvojem.

Univerzalnih odzivnih časov v urah vnaprej ne objavljamo, ker so odvisni od kritičnosti sistema, panoge in dogovora z naročnikom. Odzivni čas za posamezen razred se določi pri sklepanju SLA pogodbe in postane njen sestavni del, ne splošna obljuba. To pomeni, da vsak sistem dobi odzivne čase, prilagojene lastni zahtevnosti, namesto ene formule, ki ne upošteva razlik med preprostim in kritičnim sistemom.

Kaj mora pogodba jasno opredeliti#

Poleg razredov napak mora SLA pogodba pokriti še vrsto drugih elementov, ki jih je treba določiti pred podpisom, ne šele med prvim izpadom. Gre za vprašanja, ki delujejo administrativno, dokler se dejansko ne zgodijo – takrat pa odločajo, ali podpora teče gladko ali povzroča dodatno negotovost. Spodaj so točke, ki jih velja preveriti pri vsaki SLA pogodbi, ne glede na velikost sistema ali panogo naročnika.

• Način prijave napake in kontaktna točka, prek katere naročnik sporoči motnjo.
• Postopek eskalacije, če se odzivni čas ali dogovor iz pogodbe ne izpolni.
• Odgovornosti na strani naročnika in na strani izvajalca za posamezno fazo obravnave.
• Ločitev razvojnega, testnega in produkcijskega okolja ter pravila za prehod sprememb med njimi.
• Način poročanja o odpravljenih napakah in stanju odprtih prijav.
• Obseg rednega vzdrževanja: tehnične in varnostne posodobitve, ne le odprava napak.

#

Vsak od teh elementov vpliva na to, kako hitro in pregledno teče vsakodnevno delo po podpisu pogodbe. Če način prijave ni jasen, se motnja pogosto sporoči po naključnem kanalu in obravnava se zamakne, čeprav je bila napaka mogoče odpravljiva v nekaj minutah. Če odgovornosti niso razdeljene, se lahko zgodi, da prijava čaka na odziv, ker nihče na strani izvajalca ni prepričan, da mora ukrepati prav on.

Za naročnika to pomeni, da je vredno vztrajati pri konkretni vsebini SLA pogodbe, ne pri splošnih formulacijah tipa „redna podpora“ ali „hiter odziv“. Konkreten dogovor o prijavi, eskalaciji in poročanju je tisto, kar SLA loči od običajne pogodbe o storitvah, in tisto, kar v praksi določa, kako se bo podpora dejansko obnesla v prvem tednu po prvem resnem izpadu.

Ločena okolja in postopek uvajanja sprememb#

Del SLA, ki se pogosto spregleda, je ureditev razvojnega, testnega in produkcijskega okolja. Razvojno okolje služi za sprotno delo na kodi, testno za preverjanje sprememb pred objavo, produkcijsko pa je okolje, v katerem sistem dejansko uporabljajo naročnikovi uporabniki. Ločitev teh treh okolij zmanjša tveganje, da nepreverjena sprememba pristane neposredno pri končnem uporabniku, še preden je kdo preveril, da deluje tako, kot je bilo predvideno.

V testnem okolju se ne uporabljajo pravi osebni podatki. To je pomembno predvsem za sisteme, ki obdelujejo podatke uporabnikov, strank ali zaposlenih, saj testiranje s pravimi podatki odpira nepotrebno tveganje za zasebnost, ne glede na to, kako skrbno je okolje sicer zavarovano. SLA pogodba mora to pravilo izrecno navesti, ne pustiti ga kot nezapisano prakso, ki se je vsak novi član ekipe uči šele naknadno.

Vsaka sprememba, ne glede na to, ali gre za odpravo napake ali za novo funkcionalnost, gre skozi pregled in testiranje, preden se objavi v produkcijskem okolju. To velja tudi za manjše popravke, ker se prav majhne, na videz neškodljive spremembe najpogosteje izkažejo za vzrok nepričakovanih napak. SLA pogodba naj ta postopek opiše, tako da je jasno, kdo spremembo pregleda in kdo jo potrdi za objavo v produkcijo.

Prevzem obstoječega sistema v vzdrževanje#

SLA pogodba pogosto ne nastane hkrati z novim sistemom, temveč takrat, ko naročnik želi urediti podporo za sistem, ki že obstaja in do zdaj ni imel formalnega dogovora o vzdrževanju. V tem primeru prevzem vzdrževanja zahteva predhoden pregled izvorne kode, arhitekture, infrastrukture in podatkov, saj brez tega pregleda ni mogoče realno oceniti, koliko dela in katere razrede odzivnosti sistem dejansko potrebuje.

Enako velja za sistem, ki je bil zapuščen nedokončan – morda ga je razvijala druga ekipa, projekt pa se je ustavil pred zaključkom. Prevzem takega sistema v vzdrževanje se začne s pregledom obstoječega stanja, ne s predpostavko, da je dokumentacija popolna ali da koda ustreza pričakovanjem. Šele na podlagi tega pregleda se lahko določi realen obseg SLA in razredov, ki jim sistem dejansko ustreza.

Za naročnika to pomeni, da prevzem obstoječega sistema ni enostaven administrativen korak, temveč začetna faza projekta. Čas, namenjen pregledu, se pozneje povrne skozi realnejšo oceno SLA razredov in manj presenečenj po podpisu pogodbe. Sistem, ki je bil ustrezno pregledan pred prevzemom, je tudi lažje vzdrževati na dolgi rok, ker so tveganja znana že od prvega dne sodelovanja.

Lastništvo kode, podatkov in dokumentacije#

SLA pogodba mora nedvoumno urediti lastništvo izvorne kode in podatkov. Izvorna koda in podatki so last naročnika, ne izvajalca podpore. To načelo je treba zapisati izrecno, ne predpostaviti, ker se prav vprašanje lastništva najpogosteje izkaže za sporno, če pogodba o vzdrževanju kdaj preneha ali se izvajalec zamenja, naročnik pa se znajde brez dostopa do lastnega sistema.

• Izvorna koda ostane last naročnika skozi celotno obdobje sodelovanja.
• Podatki, ki jih sistem obdeluje, ostanejo last naročnika.
• Dokumentacija sistema je del primopredaje, ne ločena storitev, za katero je treba dodatno prositi.
• Dostopi in gesla se ob primopredaji predajo naročniku, ne zadržijo pri izvajalcu.
• Naročnik ima ob vsakem trenutku dostop do lastnega sistema, ne glede na to, kdo trenutno izvaja podporo.

#

Ta pravila so pomembna predvsem takrat, ko naročnik razmišlja o menjavi izvajalca podpore ali o prevzemu vzdrževanja nazaj v lastno ekipo. Če so dokumentacija, dostopi in gesla urejeni od začetka, je prehod hiter in brez nepotrebnih zapletov. Če niso, postane menjava izvajalca dolgotrajen in tvegan proces, ker mora nov izvajalec sistem najprej razvozlati brez ustreznih informacij, kar podaljša izpade prav v obdobju, ko naročnik podporo najbolj potrebuje.

Zapisana pravila o lastništvu in primopredaji zato niso formalnost, temveč zaščita naročnika. Omogočajo, da SLA pogodba ostane orodje za urejeno sodelovanje, ne sredstvo, ki naročnika veže na enega izvajalca zaradi pomanjkanja dokumentacije ali dostopa do lastnega sistema. Naročnik lahko kadarkoli preveri stanje sistema ali zamenja izvajalca, ne da bi za to potreboval njegovo soglasje.

Testiranje in QA v okviru SLA#

Vzdrževanje sistema ne pomeni le odpravljanja prijavljenih napak, temveč tudi preverjanje, da popravek ne povzroči novih. SLA pogodba naj zato opredeli, kakšen postopek testiranja spremlja vsako spremembo, preden ta pride do produkcijskega okolja, in kdo je odgovoren za to, da je testiranje dejansko izvedeno pred vsako objavo.

Testiranje obsega pripravljene testne scenarije, ročno in avtomatizirano testiranje – vključno z orodji, kot sta Playwright in Cypress – ter testiranje API-jev in regresijsko testiranje, ki preveri, ali sprememba ni pokvarila obstoječe funkcionalnosti. Avtomatizirani testi so lahko vključeni v CI/CD proces, tako da se izvedejo ob vsaki spremembi kode, ne le pred večjimi objavami, kar hitro odkrije napake, preden dosežejo produkcijsko okolje.

Pred objavo pomembnejših sprememb je smiselno tudi prevzemno testiranje po vnaprej dogovorjenih merilih, kjer naročnik potrdi, da sprememba dela tako, kot je bilo dogovorjeno. Pri sistemih, kjer je zanesljivost ključna, lahko QA izvaja ekipa, ločena od razvojne ekipe, kar zmanjša tveganje, da razvijalec spregleda lastno napako, ker jo preverja z isto perspektivo, s katero jo je tudi ustvaril.

Za naročnika to pomeni, da SLA ni le obljuba hitrega odziva, temveč tudi zaveza h kakovosti popravkov. Sistem, ki se vzdržuje brez rednega testiranja, sicer morda deluje hitreje popravljen, a z večjim tveganjem za nove napake, kar je na dolgi rok dražje in bolj moteče kot dosleden postopek testiranja pred vsako objavo.

Kdo izvaja podporo#

SLA pogodba je toliko vredna, kolikor je vredna ekipa, ki stoji za njo. Za vzdrževanje in podporo poslovnih sistemov Epix sestavlja projektne ekipe iz lastnih strokovnjakov in specialistične partnerske mreže, odvisno od tega, katere vloge posamezen sistem zahteva – od preprostega vzdrževanja do zahtevnejših varnostnih in infrastrukturnih nalog.

• senior inženirji in solution architecti za sisteme z zahtevnejšo arhitekturo
• backend in frontend razvijalci za tekoče popravke in nadgradnje
• DevOps in cloud inženirji za infrastrukturo, na kateri sistem teče
• strokovnjaki za kibernetsko varnost za varnostne posodobitve in odziv na incidente
• QA in test automation inženirji za preverjanje sprememb pred objavo
• projektni vodje, ki usklajujejo SLA obveznosti in poročanje naročniku

#

Znotraj Epixa in njegove specialistične partnerske mreže so na voljo tudi certificirani profili za oblak, varnost in infrastrukturo – med drugim s področja AWS, Microsoft Azure, Google Cloud, Kubernetes in kibernetske varnosti – ter delivery struktura, usklajena s standardi ISO 9001, ISO 20000/20001, ISO 27001 in ISO 27701. Ti certifikati in standardi veljajo za Epix in njegovo partnersko mrežo kot celoto, ne za posameznega člana ekipe ali za Epix Group d.o.o. samostojno.

Pri večjih projektih Epix določi projektnega vodjo, odgovornosti posameznih ekip, roke ter način komunikacije in poročanja, tako da naročnik ve, kdo je odgovoren za posamezen del vzdrževanja. Pri manjših sistemih je lahko ekipa manjša, vendar struktura odgovornosti ostaja enaka: jasno je, kdo prijavo prevzame, kdo jo rešuje in kdo jo potrdi kot zaključeno.

Kako se določi obseg in cena SLA#

Cene SLA podpore na tem mestu namenoma ne navajamo, ker je vedno odvisna od obsega, ki ga posamezen poslovni sistem dejansko zahteva – pavšalna številka bi bila zavajajoča za sistem, ki komaj potrebuje osnovno spremljanje, in za sistem, ki povezuje več internih aplikacij. Namesto ene številke je zato smiselno razumeti, kateri dejavniki ta obseg oblikujejo, saj isti dejavniki določajo oceno cene katerekoli SLA pogodbe, ne glede na panogo ali velikost naročnika.

• obseg funkcionalnosti sistema in število uporabniških vlog
• koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• zahteve glede varnosti, revizijske sledi in skladnosti, na primer v javnem sektorju
• obseg testiranja in ali je potreben neodvisen QA
• raven podpore po uvedbi in dogovorjeni odzivni časi po razredih napak

#

Ti dejavniki skupaj določijo, koliko ur podpore, katere vloge in kakšno infrastrukturo posamezen SLA dejansko zahteva. Sistem z eno preprosto integracijo in nizko kritičnostjo potrebuje bistveno manjši obseg podpore kot sistem, ki povezuje več internih aplikacij in mora izpolnjevati zahteve reguliranega okolja, kjer je vsaka motnja lahko poslovno ali skladnostno tvegana.

Cena se zato določi šele po pregledu zahtev, obsega in tehnične zahtevnosti projekta. Pred tem je smiselna krajša analiza, ki obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno – to velja tako za nov sistem kot za prevzem obstoječega v vzdrževanje, kjer analiza dodatno vključuje pregled kode, arhitekture in podatkov.

Kako začeti sodelovanje#

Priprava SLA pogodbe se pri Epixu začne s pregledom sistema, ki ga je treba vzdrževati – ne glede na to, ali gre za nov sistem, ki šele prehaja v produkcijo, ali za obstoječi sistem, ki je do zdaj deloval brez formalnega dogovora o podpori. Ta pregled je izhodišče za vse nadaljnje korake.

Na podlagi pregleda arhitekture, infrastrukture in podatkov Epix predlaga razrede napak, ustrezne odzivne čase in obseg rednega vzdrževanja, prilagojene konkretnemu sistemu. Naročnik pri tem ohrani lastništvo kode, podatkov in dostopov skozi celotno obdobje sodelovanja, dokumentacija pa je del primopredaje od prvega dne, ne dodatna storitev, za katero je treba pozneje prositi.

Rezultat je SLA pogodba, ki jasno določa, kaj se zgodi ob izpadu, motnji, manjši napaki ali zahtevi po nadgradnji – in kdo je za posamezen korak odgovoren. To je osnova, na kateri lahko poslovni sistem deluje predvidljivo, ne glede na to, kako zahtevne so posamezne situacije, ki jih vsakodnevno delo prinese.