Tiekėjų SLA analizė: rodikliai, formulės ir Power BI ataskaita

Tiekėjų SLA analizė parodo, ar tiekėjas iš tikrųjų vykdo tai, ką pažadėjo sutartyje: ar paslauga buvo pasiekiama, ar į incidentus reaguota laiku, ar užsakymai pristatyti nustatytu terminu. Kad analizė būtų patikima, reikia trijų dalykų: aiškiai apibrėžtų rodiklių su formulėmis, sutartų tikslų ir pažeidimų taisyklių, o kartu duomenų, kurie atsinaujina patys ir kuriuos galima peržiūrėti pagal tiekėją, laikotarpį ir prioritetą. Šiame vadove rasite visus tris dalykus ir praktinį planą, kaip tokią ataskaitą sukurti Power BI.

Trumpai

SLA yra pirkėjo ir tiekėjo susitarimas dėl būtiniausios paslaugos kokybės, todėl jo analizė prasideda nuo sutartyje įrašytų rodiklių, o ne nuo nuomonių.
Pagrindiniai rodikliai: pasiekiamumas, reakcijos ir sprendimo laiko laikymasis, MTTR, pristatymas laiku ir užpildymo norma.
Tikslai nustatomi pagal istorinius duomenis, o ataskaitų dažnumas priklauso nuo tiekėjo kritiškumo: kritiniams dažniau, taktiniams rečiau.
Analizė turi atskirti vienkartinį incidentą nuo sisteminės problemos, todėl rezultatus verta lyginti pagal laiką, prioritetą ir priežastį.
Power BI leidžia sujungti apskaitos, Excel ir kitų sistemų duomenis į vieną SLA ataskaitą, kuri atsinaujina automatiškai.

Turinys

Kas yra tiekėjo SLA ir ką jis turi apibrėžti
Kokius tiekėjų SLA rodiklius stebėti
Tikslai, ataskaitinis laikotarpis ir pažeidimų taisyklės
Kaip analizuoti tiekėjų SLA rezultatus
SLA ataskaita Power BI: duomenys, vizualizacijos ir filtrai
Mūsų požiūris
Kaip padedame sukurti tiekėjų SLA ataskaitą
Dažniausi klausimai
Šaltiniai

Kas yra tiekėjo SLA ir ką jis turi apibrėžti

Lietuvoje atliktame tyrime SLA apibūdinamas kaip pirkėjo įmonės ir tiekėjo susitarimas dėl būtiniausios paslaugų kokybės, reikalingos verslo poreikiui patenkinti. Praktikoje tokį susitarimą Lietuvos tiekėjai formuluoja labai konkrečiai: pavyzdžiui, Telia verslo klientams skirtame SLA aprašyme nurodo paslaugos pasiekiamumą, ilgiausią reakcijos laiką ir atsakomybę, jei įsipareigojimai nevykdomi.

Kad SLA būtų galima analizuoti, kiekvienas įsipareigojimas turi turėti keturias dalis:

Išmatuojamą rodiklį, pavyzdžiui, pasiekiamumą procentais arba reakcijos laiką valandomis.
Matavimo laikotarpį: mėnesį, ketvirtį ar savaitę.
Konkrečią ribą, žemiau kurios rezultatas laikomas pažeidimu.
Pasekmes: įspėjimą, paslaugų kreditą, taisomųjų veiksmų planą ar kitą sutartyje numatytą priemonę.

Jei bent vienos dalies trūksta, ataskaita parodys skaičius, bet neatsakys į pagrindinį klausimą: ar tiekėjas vykdė sutartį.

Kokius tiekėjų SLA rodiklius stebėti

Rodiklių rinkinys priklauso nuo to, ką tiekėjas teikia. IT ir ryšio paslaugoms svarbiausi pasiekiamumas ir incidentų valdymas, prekių tiekėjams ir logistikai: pristatymas laiku ir užsakymų įvykdymas. Geras pavyzdys yra Via Lietuva EETS paslaugų kokybės rodiklių priedas: jame tiekėjas vertinamas pagal duomenų perdavimo klaidų dažnį, sistemos pasiekiamumą, duomenų tikslumą, stabilumą, teisės aktų pažeidimus ir klientų pasitenkinimą, o pasiekiamumui nustatytas minimalus 99,2 % ir tikslinis 99,8 % lygis.

Rodiklis	Kaip apskaičiuoti	Kam tinka
Pasiekiamumas	(grynasis paslaugos laikas − neplanuota prastova) / grynasis paslaugos laikas × 100	IT sistemos, ryšys, programinė įranga
Reakcijos laiko laikymasis	incidentai, atitikę reakcijos SLA / visi incidentai × 100	Palaikymo ir priežiūros paslaugos
Sprendimo laiko laikymasis	incidentai, išspręsti per SLA terminą / visi incidentai × 100	Palaikymas, servisas
MTTR (vidutinis atkūrimo laikas)	bendras atkūrimo laikas / incidentų skaičius	Kritinės sistemos
Pristatymas laiku	laiku pristatyti užsakymai / visi užsakymai × 100	Prekių tiekėjai, logistika
Užpildymo norma	pristatytas kiekis / užsakytas kiekis × 100	Prekių tiekimas, sandėlis

Pavyzdys: per 30 dienų mėnesį paslauga turėjo veikti 720 valandų, o neplanuota prastova truko 3 valandas. Pasiekiamumas: (720 − 3) / 720 × 100 = 99,58 %. Jei sutartyje būtų tokios pat ribos kaip Via Lietuva dokumente, tiekėjas viršytų minimalų lygį, bet nepasiektų tikslo. Jei per tą patį mėnesį iš 50 incidentų 46 sulaukė reakcijos laiku, reakcijos laikymasis yra 92 %, o jei visų 50 incidentų atkūrimas truko 150 valandų, MTTR lygus 3 valandoms.

Incidentų rodikliams svarbus prioritetas. Telecentro IT paslaugų teikimo sąlygose prioritetas nustatomas pagal poveikio ir skubumo lygius, o nuo prioriteto priklauso reakcijos ir sprendimo laikas. Todėl ataskaitoje reakcijos laikymąsi visada skaičiuokite atskirai kiekvienam prioritetui: vidurkis gali paslėpti, kad kritiniai incidentai sprendžiami per lėtai.

Tikslai, ataskaitinis laikotarpis ir pažeidimų taisyklės

Rodikliai be tikslų tėra statistika. Nustatydami tikslus, laikykitės kelių principų:

Remkitės istoriniais duomenimis. Jei tiekėjas šiandien pristato laiku 80 % užsakymų, 99 % tikslas nuo pirmo mėnesio bus nuolatinis pažeidimas, o ne valdymo priemonė. Geriau nustatyti realų lygį ir jį kelti etapais.
Pasirinkite dažnumą pagal kritiškumą. Kritiniams tiekėjams verta savaitinės ataskaitos, taktiniams pakanka mėnesinės, o pačios SLA sąlygos kritinėms paslaugoms dažniausiai peržiūrimos kas ketvirtį.
Naudokite rinkoje įprastus orientyrus. Pavyzdžiui, Best Buy tiekėjų tiesioginio vykdymo programoje tikslai yra 99 % pakoreguota užpildymo norma ir 95 % pristatymų laiku.
Apibrėžkite išimtis. Force majeure atvejai ir vėlavimai, kuriuos sukėlė pats užsakovas, turi būti pažymėti duomenyse ir neįskaičiuoti į tiekėjo rezultatą.
Sutarkite eskalavimo seką. Įprasta tvarka: įspėjimas ir pagrindinės priežasties aptarimas, taisomieji veiksmai, vadovybės peržiūra, o kraštutiniu atveju sutarties sąlygų keitimas ar nutraukimas.

Prieš pasirašydami sutartį taip pat patikrinkite, kaip registruojami incidentai, nuo kurio momento skaičiuojamas reakcijos laikas ir ar galėsite gauti duomenis struktūruota forma. Nuo to priklauso, ar SLA ataskaitą bus galima automatizuoti.

Kaip analizuoti tiekėjų SLA rezultatus

FACIS SLA valdymo metodikoje rekomenduojama nuolat renkamus rodiklius derinti su periodinėmis ataskaitomis, kuriose matyti nukrypimai, priežasčių analizė, taisomieji veiksmai ir tendencijos. Tai padeda atskirti vienkartinį incidentą nuo sisteminės problemos. Praktiškai analizę verta atlikti tokia tvarka:

Palyginkite rezultatą su tikslu ir minimalia riba kiekvienam tiekėjui ir rodikliui.
Pažiūrėkite tendenciją bent 6–12 mėnesių: vienas blogas mėnuo ir trys mėnesiai iš eilės su blogėjančiu rezultatu reikalauja skirtingų veiksmų.
Išskaidykite pagal prioritetą, paslaugą ir padalinį. Dažnai problema slypi vienoje paslaugoje ar vienoje lokacijoje.
Ieškokite pasikartojimų: tų pačių priežasčių, savaitės dienų, mėnesio pabaigos piko ar konkretaus produkto.
Įvertinkite verslo poveikį: kiek kainavo prastova, vėluojantys pristatymai ar papildomas darbas.
Užfiksuokite veiksmus: pagrindinę priežastį, atsakingą asmenį, taisomąjį veiksmą ir jo įvykdymo terminą.

Šiaurės Airijos verslo informacijos portalas pabrėžia, kad tiekėjų veiklos peržiūros padeda stebėti KPI ir SLA laikymąsi, laiku pastebėti spragas ir susitarti dėl taisomųjų veiksmų, o jų dažnumas turi atitikti paslaugos ir verslo riziką. Tiekėjų SLA analizė natūraliai susijusi su platesniu pirkimų vaizdu, todėl ją verta sieti su pirkimų ataskaitomis Power BI: taip matysite ne tik paslaugos kokybę, bet ir kiek kiekvienam tiekėjui mokate.

SLA ataskaita Power BI: duomenys, vizualizacijos ir filtrai

SLA dashboard Power BI vertas tiek, kiek patikimi jo duomenys. Todėl kūrimą pradėkite nuo modelio, o ne nuo grafikų.

Duomenų modelis

Minimalų SLA modelį sudaro:

Faktų lentelė su incidentais, užsakymais ar pristatymais: registravimo, reakcijos ir sprendimo laikas, prioritetas, statusas, priežastis.
Tiekėjų lentelė: pavadinimas, kategorija, kritiškumas, sutarties numeris, atsakingas vadybininkas.
SLA ribų lentelė: kiekvienam tiekėjui ir prioritetui minimalus lygis ir tikslas. Ribos laikomos atskirai, kad jas pakeitus nereikėtų perrašyti formulių.
Datų lentelė, kad galėtumėte lyginti mėnesius, ketvirčius ir metus.
Finansiniai duomenys iš apskaitos sistemos, pavyzdžiui, Rivilė ar Finvalda: pirkimų sumos, sąskaitos, kreditinės sąskaitos.

Incidentų duomenys dažnai gyvena Excel ar SharePoint sąrašuose, užsakymų duomenys: apskaitos ar logistikos sistemose. Power BI juos sujungia per tiekėjo kodą, todėl tiekėjų kodai visose sistemose turi būti vienodi. Tai tas pats darbas, kurį aprašome straipsnyje apie KPI ir ataskaitų standartizavimą.

Puslapiai ir vizualizacijos

Apžvalga vadovui: KPI kortelės su kiekvieno rodiklio rezultatu ir tikslu, spalvomis pažymėti pažeidimai, tiekėjų reitingas.
Tendencijos: linijinė diagrama pagal mėnesius su tikslo linija, kad blogėjimas būtų matomas iš karto.
Incidentų detalizacija: lentelė pagal prioritetą su reakcijos ir sprendimo laiku, MTTR, pažeidimų skaičiumi.
Priežasčių analizė: stulpelinė diagrama pagal priežastis ir kategorijas, kad matytumėte, kas kartojasi.
Veiksmų registras: atviri taisomieji veiksmai, atsakingi asmenys ir terminai.

Filtrai, kurių reikia beveik kiekvienoje SLA ataskaitoje: laikotarpis, tiekėjas, tiekėjo kategorija ir kritiškumas, prioritetas, paslauga ar produktas, padalinys. Logistikos tiekėjams papildomai pravers maršrutas ar sandėlis; susijusius rodiklius aptariame transporto sąnaudų analizės ir tiekimo grandinės ataskaitų vadovuose.

Atnaujinimas ir duomenų kokybė

Rankiniu būdu atnaujinama SLA ataskaita greitai pasensta. Power BI paslaugoje galima nustatyti suplanuotą atnaujinimą: Power BI Pro leidžia iki 8, o Premium iki 48 atnaujinimų per dieną. Daugumai tiekėjų SLA ataskaitų pakanka kelių atnaujinimų per dieną, o kritinėms paslaugoms verta svarstyti dažnesnį ciklą. Kaip nustatyti visą procesą, aprašėme automatinio ataskaitų atnaujinimo gide.

Duomenų kokybę tikrinkite dar Power Query etape. Microsoft aprašyti duomenų profiliavimo įrankiai parodo stulpelių statistiką, pasiskirstymą ir eilučių skaičių, todėl greitai pamatysite tuščias reakcijos datas, dublikatus ar neteisingus prioritetus. Prie to pridėkite kelias kontrolines taisykles: sprendimo laikas negali būti ankstesnis už registravimo laiką, kiekvienas incidentas turi turėti tiekėją ir prioritetą, o išimtys turi būti pažymėtos atskiru lauku.

Mūsų požiūris

Dauguma įmonių, su kuriomis dirbame, SLA duomenis jau turi: incidentų sąrašus Excel, užsakymus Rivilė ar Finvalda, sutarčių sąlygas SharePoint. Trūksta ne duomenų, o vieno modelio, kuriame jie susitinka.

Todėl mes pradedame nuo apskaitos duomenų. Kai SLA rezultatai matomi šalia pirkimų sumų, skolų ir sąnaudų, pokalbis su tiekėju tampa konkretus: matote ne tik, kiek kartų jis vėlavo, bet ir kiek tai kainavo jūsų verslui.

Antras principas: ataskaita turi atsinaujinti be žmogaus įsikišimo. Mūsų sprendimai sukurti taip, kad duomenys iš Rivilė ir Finvalda bei kitų šaltinių pasiektų Power BI automatiškai, o finansų vadovas ar pirkimų specialistas laiką skirtų sprendimams, o ne lentelių kopijavimui.

Analitika360

Kaip padedame sukurti tiekėjų SLA ataskaitą

Analitika360 kuria Power BI ataskaitas Rivilė ir Finvalda naudotojams ir integruoja kitus šaltinius: Excel, SharePoint, CRM ar logistikos sistemas. Tiekėjų SLA ataskaita paprastai kuriama kaip individualus projektas, pritaikytas jūsų sutartims, rodikliams ir esamoms IT sistemoms.

Analitika360

Rivilė Basic ir Finvalda Basic: 59 € per mėnesį.
Rivilė PRO ir Finvalda PRO: 89 € per mėnesį.
Individualūs projektai: 70 € per valandą.

Taip pat padedame įsigyti reikalingas Microsoft Power BI Pro ir Premium licencijas. Visas sąlygas rasite verslo analitikos kainų puslapyje, o paruoštų paketų apžvalgą: puslapyje apie Rivilė, Finvalda ir Power BI paketus. Susisiekite su mumis ir aptarkime, kokių SLA rodiklių reikia jūsų įmonei.

Dažniausi klausimai

Kuo skiriasi SLA ir KPI?

SLA yra sutartinis įsipareigojimas su riba ir pasekmėmis, o KPI yra bet koks veiklos rodiklis, kurį stebite. Visi SLA rodikliai yra KPI, bet ne kiekvienas KPI įrašomas į sutartį. Ataskaitoje juos verta rodyti kartu, aiškiai pažymint, kurie turi sutartines pasekmes.

Kuo skiriasi SLA ir KPI?

Kaip dažnai peržiūrėti tiekėjų SLA rezultatus?

Kritiniams tiekėjams rezultatus verta stebėti kas savaitę, taktiniams kas mėnesį. Pačios SLA sąlygos kritinėms paslaugoms dažniausiai peržiūrimos kas ketvirtį, mažiau kritinėms kas pusmetį ar kartą per metus. Automatiškai atsinaujinanti ataskaita leidžia nukrypimus matyti ir tarp peržiūrų.

Ar SLA ataskaitai Power BI reikia specialios incidentų sistemos?

Nebūtinai. Pakanka struktūruoto incidentų ar užsakymų sąrašo su datomis, prioritetu ir tiekėju, kuris gali būti Excel ar SharePoint faile. Svarbiausia, kad laukai būtų pildomi vienodai ir tiekėjų kodai sutaptų su apskaitos sistema.

Kaip elgtis su incidentais, kuriuos sukėlė pats užsakovas?

Tokie atvejai turi būti apibrėžti sutartyje kaip išimtys ir pažymėti duomenyse atskiru lauku. Power BI juos galima išskirti filtru, kad tiekėjo rezultatas būtų skaičiuojamas teisingai. Taip išvengsite ginčų peržiūrų metu.