Mokėjimų paslaugų incidentų valdymo sistema
Komanda mato, kuri mokėjimų paslauga sutriko, kokie klientai paveikti ir kas atsakingas už atkūrimą. Po sutrikimo galima patikrinti likusias nebaigtas operacijas.
Mokėjimo paslauga priklauso nuo bankų, tinklų, debesijos ir tapatybės tiekėjų. Sutrikimo planai ne visada parodo, kuriuos klientų veiksmus paveikia konkretaus partnerio problema. Komanda ilgiau aiškinasi sutrikimo apimtį ir atkūrimo galimybes. Prekybininkui sunku paaiškinti neveikiantį atsiskaitymą bei įvertinti, kuriuos užsakymus reikia peržiūrėti.
Kaip veikia sprendimas
- Nustatyti paslaugos priklausomybes ir toleruojamą sutrikimą
- Susieti signalą su paveiktu srautu
- Paskirti incidento sprendėją ir veiksmus
- Atkurti paslaugą pagal išbandytą scenarijų
- Komanda patikrina paveiktų mokėjimų rezultatus ir pašalina atkūrimo bandyme nustatytus trūkumus.
Pagrindinės problemos
- Kritinės tiekėjų priklausomybės nepakankamai matomos
- Paslaugos kontrolės įrodymai nesusieti su incidentu
Sprendimo funkcijos
Paslaugos priklausomybės
Susieja mokėjimo veiksmą su banku, tinklu, debesija ir kitais būtinais komponentais. Du tiekėjai gali priklausyti nuo to paties žemesnio lygio šaltinio.
Veiklos poveikis
Rodo laukiančias operacijas, paveiktus partnerius ir finansinio atsiskaitymo vėlavimą kartu su techniniais signalais.
Incidento valdymas
Saugo sprendimus, atliktus veiksmus, komunikaciją ir eskalavimo terminus pagal incidento pobūdį.
Atkūrimo bandymas
Komanda išbando sutartą atsarginį paslaugos teikėją, jo pajėgumą ir reikalingų duomenų perdavimą. Prieš pakartodama mokėjimus, patikrina jų rezultatą pirminėje sistemoje.
Kontrolės įrodymai
Bandymo trūkumą sieja su atsakingu darbuotoju, pataisymu ir pakartotine patikra. Techninis atsistatymas atskiriamas nuo finansinių išimčių sutvarkymo.
Veiklos kontekstas
- Kritinės tiekėjų priklausomybės nepakankamai matomos
- Mokėjimo paslauga priklauso nuo bankų, tinklų, debesijos ir tapatybės tiekėjų. Sutrikimo planai ne visada parodo, kuriuos klientų veiksmus paveikia konkretaus partnerio problema. Komanda ilgiau aiškinasi sutrikimo apimtį ir atkūrimo galimybes. Prekybininkui sunku paaiškinti neveikiantį atsiskaitymą bei įvertinti, kuriuos užsakymus reikia peržiūrėti.
- Paslaugos kontrolės įrodymai nesusieti su incidentu
- Atkūrimo bandymų, tiekėjų priklausomybių ir incidento veiksmų įrašai saugomi atskirai nuo prižiūrimos paslaugos. Sunku patikrinti, ar nustatyta silpna vieta pašalinta ir ar pakartotas bandymas apėmė paveiktą srautą.
- Mokėjimų patikimumas svarbus prekybininko pardavimams
- Neveikiantis atsiskaitymas gali nutraukti pirkimą net tuomet, kai prekė pasirinkta. Matoma sutrikimo apimtis padeda teikėjui nustatyti paveiktus klientus ir koordinuoti atkūrimą. Prekybininkas gali informuoti pirkėjus pagal patvirtintą situaciją, o po atkūrimo patikrinamos neaiškios operacijos.
Pagrindinės funkcijos
- Paslaugos priklausomybės
- Veiklos poveikis
- Incidento valdymas
- Atkūrimo bandymas
- Kontrolės įrodymai
Pagrindinės integracijos
- Techninė stebėsena ir mokėjimų būsenos
- Komponentų įvykiai ir jų paveiktos operacijos.
- Tiekėjų bei incidentų registrai
- Paslaugų įsipareigojimai, priklausomybės, sprendimai ir bandymų faktai.
Potencialus poveikis (%)
Intervalai rodo orientacinį santykinį rodiklio pokytį pagal aprašytas prielaidas. Rezultatas priklauso nuo pradinės situacijos ir sprendimo naudojimo. Skirtingų rodiklių procentai nesudedami.
Incidento paveiktų operacijų nustatymo laikas
12–36%Mažėja
Pavyzdiniame scenarijuje paveikiama 30-60% rankinio duomenų suvedimo ir perdavimo darbo. Daroma prielaida, kad ši dalis sumažėtų 40-60%. Įmonės duomenimis tikrinama ir paveikiama apimtis, ir pasiektas pokytis.
Matuoti minutes nuo incidento aptikimo iki patikimo paveikto srauto nustatymo.
Laiku nepatikrintų paslaugos atkūrimo spragų skaičius
5–25%Mažėja
Pavyzdiniame scenarijuje paveikiama 20-50% neatliktų veiksmų, kuriuos galima pastebėti pagal užduotis ir terminus. Daroma prielaida, kad ši dalis sumažėtų 25-50%. Įmonės duomenimis tikrinama ir paveikiama apimtis, ir pasiektas pokytis.
Skaičiuoti reikšmingas atkūrimo spragas, kurių sutartas patikros terminas praleistas.
Pateikti sąlyginiai skaičiavimo scenarijai. Prielaidos nepatvirtintos kliento matavimais.
Kada sprendimas aktualus
- Incidento metu matoma techninė klaida, tačiau neaišku, kuriuos klientus ir mokėjimus ji paveikė.
- Sutrikimą šalina kelios komandos, o sprendimai, atsakomybės ir paslaugos atkūrimo patvirtinimai saugomi atskirai.
Įgyvendinimo sąlygos
Veikimo stebėsenai susiejamos mokėjimo paslaugos, jų technologinės priklausomybės ir operacijų būsenos. Atsakingos komandos suderina reagavimą į negautus atsakymus, atkūrimo procedūras ir užstrigusių operacijų sutikrinimą.
Galima tolesnė plėtra
- Kitų kritinių srautų scenarijai ir tiekėjo pakeitimo bandymai pagal realią veiklos priklausomybę.