NORV
LT / EN Kontaktai

PAVYZDŽIAI

Kaip tai veikia praktikoje — dvylika pavyzdžių.

Konsultacijų aprašymai dažnai lieka bendri. Šiuose pavyzdžiuose matyti konkrečiai: nuo kokios situacijos pradedama, kas daroma ir pagal ką vertinama, ar suveikė.

Aptarkime jūsų atvejį

AI IR AUTOMATIZACIJA

AI agentai realiuose procesuose

Toliau pateikti pavyzdžiai iliustruoja, kaip atrodo tipinis darbas kiekvienoje srityje: situacija, sprendimo eiga ir tai, kas realiai matuojama. Tai apibendrinti scenarijai, parengti pagal praktikoje pasitaikančius atvejus, o ne konkrečių klientų aprašymai — klientų pavadinimai, duomenys ir rodikliai neviešinami. Jūsų situacijos skaičiai priklausys nuo apimties, sistemų ir komandos brandos.

01 · IT PASLAUGOS

Incidentų srauto rūšiavimas AI agentu

Situacija

Aptarnavimo komanda gauna kelis šimtus užklausų per savaitę. Kiekvienai pirmiausia skiriama kelios minutės rūšiavimui: kam priklauso, koks prioritetas, ar tai jau žinoma problema.

Ką darome

Agentas perskaito užklausą, surenka kontekstą iš stebėsenos ir ankstesnių panašių incidentų, pasiūlo kategoriją, prioritetą ir pirmuosius sprendimo žingsnius. Priskyrimą patvirtina žmogus — agentas nesiunčia nieko klientui savarankiškai.

Kas pamatuojama

Pirminio atsako laikas, teisingai priskirtų užklausų dalis, laikas iki sprendimo ir kiek užklausų išsprendžiama pirmame lygyje.

02 · GAMYBA

Tiekėjų dokumentų duomenų ištraukimas

Situacija

Sąskaitos ir sutartys iš dešimčių tiekėjų tvarkomos rankiniu būdu: duomenys perrašomi į apskaitą, neatitikimai pastebimi tik mėnesio pabaigoje.

Ką darome

Agentas ištraukia laukus iš dokumento, palygina su užsakymu ir sutartimi, pažymi neatitikimus. Iki sutartos sumos ribos įrašas keliauja automatiškai; virš jos — būtinas žmogaus patvirtinimas.

Kas pamatuojama

Vieno dokumento apdorojimo laikas, rankinio taisymo dažnis ir kiek neatitikimų pastebima prieš apmokėjimą, o ne po jo.

03 · ENTERPRISE IT

Žinių asistentas virš vidinės dokumentacijos

Situacija

Veiksmų aprašai, konfigūracijos ir sprendimų istorija išsibarstę po kelias sistemas. Naujas inžinierius pirmus mėnesius klausia kolegų, o tai atima laiką abiem.

Ką darome

Agentas atsako tik pagal vidinę dokumentaciją ir kaskart nurodo šaltinį. Jei atsakymo dokumentuose nėra, jis tai pasako, o ne spėja — nes klaidingas atsakymas apie produkcinę sistemą kainuoja brangiau nei jokio atsakymo.

Kas pamatuojama

Pakartotinių klausimų komandai skaičius, naujo darbuotojo įsidirbimo trukmė ir kiek atvejų išsprendžiama neeskaluojant.

04 · IT PASLAUGOS

Stebėsenos signalų koreliacija

Situacija

Stebėsena siunčia šimtus įspėjimų per parą. Dauguma jų — to paties gedimo atgarsiai, todėl komanda pripranta jų nepaisyti.

Ką darome

Agentas grupuoja susijusius signalus pagal laiką ir priklausomybes, pasiūlo tikėtiną pirminę priežastį ir sukuria vieną incidentą vietoj dvidešimties atskirų.

Kas pamatuojama

Įspėjimų kiekis budinčiam inžinieriui, klaidingų signalų dalis ir laikas nuo pirmo signalo iki nustatytos priežasties.

IT PASLAUGŲ VALDYMAS

Kai kasdienė paslauga tampa prognozuojama

05 · MAŽMENINĖ PREKYBA

Pasikartojantys incidentai su miglota priežastimi

Situacija

Tas pats gedimas kartojasi kas kelias savaites. Kiekvieną kartą jis pašalinamas greitai, todėl atrodo suvaldytas — bet niekas netiria, kodėl grįžta.

Ką darome

Atskiriame incidentų valdymą nuo problemų valdymo: incidentas atkuria paslaugą, problema ieško priežasties. Įvedame priežasčių analizę pasikartojantiems atvejams ir kiekvienam priskiriame savininką su terminu.

Kas pamatuojama

Pakartotinių incidentų dalis nuo visų, laikas iki priežasties nustatymo ir kiek problemų uždaroma su pašalinta priežastimi.

06 · VIEŠASIS SEKTORIUS

SLA, kurie nesusiję su verslo pasekme

Situacija

Sutartyje yra SLA rinkinys, rodikliai skaičiuojami, ataskaitos siunčiamos. Tačiau pažeidus ribą niekas nesikeičia, nes neaišku, kas ir ką turi daryti.

Ką darome

Susiejame kiekvieną rodiklį su paslaugos svarba verslui, aprašome eskalavimo tvarką ir priskiriame savininkus. Rodikliai, kurių niekas nenaudoja sprendimams, pašalinami — jie tik triukšmas ataskaitoje.

Kas pamatuojama

SLA laikymasis pagal paslaugos kritiškumą, eskalavimo suveikimo laikas ir kiek sprendimų realiai priimta remiantis rodikliais.

07 · TELEKOMUNIKACIJOS

Eskalavimas, priklausantis nuo konkrečių žmonių

Situacija

Kritinius incidentus faktiškai valdo du inžinieriai. Kai jų nėra, reagavimas ne darbo metu tampa atsitiktinis.

Ką darome

Aprašome eskalavimo kelius pagal incidentų klases, sudarome budėjimo grafiką su aiškiomis atsakomybėmis ir parengiame veiksmų aprašus dažniausiems scenarijams, kad juos galėtų vykdyti ne tik autorius.

Kas pamatuojama

Reagavimo laikas ne darbo valandomis, incidentų dalis, išspręsta be eskalavimo trečiam lygiui, ir priklausomybė nuo vieno žmogaus.

INFRASTRUKTŪRA

Sprendimai, kuriuos galima pagrįsti

08 · BANKININKYSTĖ

Kritinės infrastruktūros migracija į naują duomenų centrą

Situacija

Kritinės sistemos veikia sename duomenų centre. Migracija atidedama, nes niekas nedrįsta prisiimti prastovos rizikos.

Ką darome

Sudarome inventorių ir priklausomybių žemėlapį, suskaidome migraciją į etapus pagal kritiškumą, kiekvienam etapui parengiame atgalinio kelio planą ir prieš tai patikriname atkūrimą testinėje aplinkoje.

Kas pamatuojama

Faktinė prastova pagal etapą, incidentų skaičius per pirmas savaites po migracijos ir ar atgalinio kelio planas buvo reikalingas.

09 · IT PASLAUGOS

Debesijos kaštai, viršijantys planą

Situacija

Po migracijos mėnesinė sąskaita pastebimai didesnė nei skaičiuota. Sistemos veikia, bet kaštai neprognozuojami.

Ką darome

Peržiūrime, kas iš tikrųjų veikia visą parą, kokios saugyklos klasės naudojamos, kur duomenų srautai kertą zonų ribas ir kurie resursai liko po testų. Architektūra pritaikoma debesijos modeliui, o ne perkeliama nepakeista.

Kas pamatuojama

Mėnesio kaštai pagal paslaugą, kaštai vienam naudotojui arba operacijai ir kiek sutaupoma be poveikio našumui.

10 · REGULIUOJAMA APLINKA

Atsarginės kopijos be patikrinto atkūrimo

Situacija

Backup ataskaitos rodo sėkmę kiekvieną naktį. Tačiau realaus atkūrimo niekas nebandė, todėl atkūrimo trukmė yra prielaida, ne skaičius.

Ką darome

Atliekame atkūrimo testus kritinėms sistemoms, matuojame realų atkūrimo laiką ir duomenų praradimo ribą, patikriname priklausomybes nuo kitų sistemų — nes sistema retai atsistato viena.

Kas pamatuojama

Realūs RTO ir RPO skaičiai vietoj prielaidų, atotrūkis nuo verslo lūkesčio ir kiek sistemų neatsistatė iš pirmo karto.

IT VALDYMAS IR VERSLAS

Kai IT auga kartu su įmone

11 · GAMYBA

Tiekėjai, kurių niekas nevaldo

Situacija

Įmonė dirba su keliais IT tiekėjais. Sutartys pratęsiamos automatiškai, dalis paslaugų dubliuojasi, o bendros IT išlaidos niekur nesuvestos.

Ką darome

Sudarome sutarčių ir paslaugų inventorių, randame dubliavimus ir nebenaudojamas licencijas, peržiūrime atsakomybių ribas tarp tiekėjų ir pasiruošiame deryboms su konkrečiais argumentais.

Kas pamatuojama

Metinės IT išlaidos, tiekėjų ir sutarčių skaičius bei kiek paslaugų turi aiškų savininką įmonės viduje.

12 · AUGANTI ĮMONĖ

IT branda, atsilikusi nuo įmonės augimo

Situacija

Tai, kas veikė turint dvidešimt darbuotojų, ties šimtu jau girgžda: prieigos suteikiamos laiškais, įrenginiai nesuskaičiuoti, o išeinančių darbuotojų paskyros lieka aktyvios.

Ką darome

Sutvarkome prieigų suteikimo ir panaikinimo procesą, aprašome įrenginių politiką, atliekame licencijų auditą ir automatizuojame darbuotojo atėjimo bei išėjimo eigą.

Kas pamatuojama

Naujo darbuotojo paruošimo laikas, likusių aktyvių paskyrų skaičius po išėjimo ir licencijų panaudojimas.

DUK

Klausimai apie šiuos pavyzdžius

Ar tai realių klientų projektai?

Ne. Tai apibendrinti scenarijai, iliustruojantys tipinę darbo eigą ir tai, kas matuojama. Konkrečių klientų pavadinimai, duomenys ir rodikliai neviešinami — konfidencialumas yra dalis darbo. Aptariant jūsų situaciją kalbame apie konkrečius skaičius, ne apie apibendrinimus.

Kiek trunka toks darbas?

Fiksuotos apimties vertinimas paprastai užtrunka kelias savaites. Vienos darbo eigos automatizavimo pilotas — nuo kelių savaičių iki poros mėnesių. Infrastruktūros migracija priklauso nuo priklausomybių skaičiaus ir dažniausiai skaidoma į etapus.

Ar galima pradėti nuo vieno pavyzdžio?

Taip, ir dažniausiai taip verta. Vienas užbaigtas procesas duoda ir rezultatą, ir pagrindą spręsti dėl plėtros — daug pigiau nei plati programa, pradėta nuo prielaidų.

Kaip pasirenkama, nuo ko pradėti?

Pagal poveikį ir riziką: kas kainuoja daugiausiai laiko arba kelia didžiausią riziką šiandien. Pirmas pokalbis dažniausiai tai ir išgrynina, net jei iš pradžių atrodė, kad problema kitur.

SUSIJUSIOS PASLAUGOS

Nuo pavyzdžio prie paslaugos

Kiekvienas pavyzdys kyla iš konkrečios srities. Štai kur apie ją skaityti plačiau.

IT paslaugų valdymas (ITSM)

Incidentų ir problemų valdymas, SLA, eskalavimo keliai ir aiški atsakomybė.

Skaityti apie ITSM

AI agentai ir automatizacija

Vienas realus procesas nuo bandymo iki gamybos, su žmogaus kontrole ir matavimu.

Skaityti apie AI agentus

IT infrastruktūra ir debesija

Auditas ir kryptis: virtualizacija, saugyklos, kopijos, tinklai ir saugumas.

Skaityti apie infrastruktūrą

Dalinis IT vadovas

Funkcija be etato: kasdienis valdymas, tiekėjai, biudžetas ir perdavimas komandai.

Skaityti apie IT vadovo paslaugą

PRADĖKIME

Kuris pavyzdys panašiausias į jūsų situaciją?

Jei kuris nors iš jų atrodo pažįstamas, pirmas pokalbis bus konkretus — apie jūsų skaičius, ne apie bendrus principus.

Parašykite el. laišką

info@norv.lt