Wyobraź sobie: umowa z dostawcą chmury wynegocjowana, podpis zaplanowany na najbliższy poniedziałek, prawnicy zadowoleni. W czwartek ktoś na spotkaniu rzuca pytanie o zgłoszenie do KNF. Czternastu dni już nie ma.
Termin to jednak nie jest najciekawszy problem w tej historii. Bo nawet kiedy zdążysz, zostają dwa pytania trudniejsze: czy zgłaszasz to, co trzeba, i czy plik przejdzie walidację.
Dlaczego instytucje, które mają wszystkie dane u siebie, mimo to składają raporty z błędami? Pokażę trzy miejsca, w których to najczęściej pęka. Wszystkie trzy znamy z pracy z klientami, którzy przeszli przez to przed Tobą.
Czym są SPR-PF-19 i SPR-PF-20
Zacznijmy od porządku w pojęciach, bo te dwa numery bardzo łatwo pomylić.
SPR-PF-19 dotyczy nowych albo zmienionych ustaleń umownych ICT. Podpisujesz nową umowę dla funkcji krytycznej lub istotnej albo aneks zmieniający ustalenia już obowiązujące.
SPR-PF-20 dotyczy reklasyfikacji, czyli sytuacji, w której usługa świadczona od dawna staje się krytyczna lub istotna. Umowa zostaje ta sama. Zmienia się to, jak ważna jest dla Twojej działalności. Jedno je łączy: to raportowanie zdarzeniowe, czyli po ludzku obowiązek powstaje w momencie zdarzenia, a nie na koniec kwartału. Nikt Cię o nim nie powiadomi i nikt nie wyśle wezwania.
Przy SPR-PF-19 zgłoszenie trafia do KNF minimum dwa tygodnie przed planowaną datą podpisania ustaleń umownych, czyli termin liczysz wstecz od podpisu, a nie od dziś.
Wyzwanie 1: reklasyfikacji nikt nie zauważy, jeśli nikt nie pilnuje funkcji
SPR-PF-19 ma sprzymierzeńca: umowę. Umowa ma termin, właściciela i kalendarz, więc jest szansa, że ktoś o niej pomyśli. SPR-PF-20 nie ma nic. Nie powstaje żaden nowy dokument, nikt niczego nie podpisuje. Usługa po prostu z dnia na dzień staje się istotna, a jedyne, co się zmienia, to Twoja własna ocena.
I tu wchodzi liczba, która najlepiej pokazuje skalę problemu. Kiedy porównujemy rejestry, z którymi do nas przychodzą klienci, rozrzut jest zdumiewający: bardzo podobne do siebie podmioty mają opisanych od dziesięciu do nawet sześćdziesięciu czy osiemdziesięciu funkcji biznesowych. Oficjalnej listy funkcji nie ma, więc instytucja ma tu niemal pełną swobodę – i każda korzysta z niej inaczej.
Zobacz, co z tego wynika praktycznie. Jeśli masz opisanych dziesięć funkcji na wysokim poziomie ogólności, reklasyfikacja jest niewidoczna – nie ma nawet czego przeklasyfikować, bo „obsługa klienta” jest krytyczna od zawsze i będzie krytyczna zawsze. Zmiana statusu, którą powinieneś zgłosić na SPR-PF-20, dzieje się poniżej poziomu Twojego opisu.
Do tego dochodzi drugi kłopot, który w rozmowach z klientami wraca najczęściej: dostawcy próbują sami orzekać o swojej krytyczności. Prosisz o dane o łańcuchu dostaw, a w odpowiedzi słyszysz, że dostawca nie wspiera funkcji krytycznych, więc nie musi nic podawać. Nie może tak powiedzieć. Krytyczność funkcji definiuje instytucja finansowa na podstawie własnych procesów, nie dostawca – i dostawcę trzeba wykazać w rejestrze także wtedy, gdy funkcji krytycznych nie wspiera.
Wyjście: funkcje opisane na tyle szczegółowo, żeby zmiana ich statusu była w ogóle zauważalna, i z przypisanym właścicielem, który tę zmianę zgłosi.
Wyzwanie 2: instrukcja zmienia się w trakcie
Znasz to uczucie, gdy składasz mebel z instrukcji, a w połowie ktoś podmienia stronę? Śruba, która miała zostać luzem, teraz musi być dokręcona. Otwór opisany jako obowiązkowy trzeba zostawić pusty. Mebel ostatecznie stoi, ale nie dlatego, że instrukcja była dobra – dlatego, że ktoś jej pilnował za Ciebie.
Tak wygląda praca ręczna nad danymi do raportów. Trzy przykłady z tego samego zbioru danych o umowach ICT, z którego powstają SPR-PF-19 i SPR-PF-20 – każdy z nich rozstrzygaliśmy razem z klientami.
Pierwszy: publikacja odpowiedzi na najczęstsze pytania przestawiła kolumny. Część pól, które wcześniej miały zostać puste, trzeba wypełnić. Część odwrotnie. Doszły nowe zasady wyboru z list rozwijanych. Pierwsze pytanie, które wtedy słyszeliśmy od klientów, brzmiało prosto: która wersja obowiązuje?
Drugi: sprzeczność wprost między dwoma dokumentami. W jednej z sekcji rejestru standard techniczny każe zostawić puste pole z kodem odbiorcy podzleconych usług dla dostawcy pierwszego rzędu, a odpowiedzi na pytania mówią, że ta wartość nie może być pusta w żadnym przypadku. Ktoś musi zdecydować, która wersja wygrywa – i ponieść konsekwencje, jeśli wybierze źle. Tę jedną decyzję nasz zespół produktowy podjął za klientów, tak żeby ich dane przeszły walidację.
Trzeci, najbardziej pouczający: pole obowiązkowe, które musi zostać puste. Obowiązek raportowania umów wygasłych zniknął z finalnej wersji standardu, ale kolumna z przyczyną rozwiązania umowy została i nadal jest oznaczona jako obowiązkowa. Wyjaśnienie brzmi: zostaw ją pustą, zawsze.
Warto powiedzieć to uczciwie, bo to zmienia sposób myślenia o całym problemie. Reguły walidacyjne KNF nie stały się łatwiejsze ani trudniejsze. One się zmieniają – a odpowiedzialność za dane zostaje po Twojej stronie, niezależnie od tego, ile razy zmieniła się instrukcja od czasu, gdy zaczynałeś wypełniać.
Wyzwanie 3: dane są, ale zależności trzymasz w głowie
Trzecie miejsce, w którym to pęka, jest najtrudniejsze do zauważenia, bo wszystko wygląda w porządku. Dane są. Kompletne. Tylko powiązania między nimi istnieją wyłącznie w Twojej głowie.
Wyobraź sobie kartotekę na fiszkach. Sześćdziesiąt funkcji biznesowych, do nich umowy, do nich podwykonawcy, a wszystko opisane kodami alfanumerycznymi. Każda fiszka poprawna. Ale która umowa wspiera którą funkcję i co się stanie, jeśli ta jedna funkcja zmieni status – to już nie stoi nigdzie zapisane.
To nie jest nasza opinia o arkuszach kalkulacyjnych. Po ćwiczeniu próbnym z rejestrem informacji wyszły błędy jakości danych, a europejskie organy nadzoru doszły do wniosku, że utrzymywanie rejestru w Excelu nie spełnia wymogów DORA – właśnie dlatego, że nie pokazuje zależności między danymi, więc nie pozwala realnie zarządzać ryzykiem ICT. Zapowiedziały, że nie będą dalej rozwijać pliku z ćwiczenia próbnego, a znalezienie właściwego narzędzia zostaje po stronie instytucji.
Jest jeszcze jeden szczegół, który łatwo przeoczyć: arkusz opublikowany później w ramach modelu danych służy do zbierania danych, nie do raportowania. To dwie różne rzeczy. Zebranie danych masz za sobą, kiedy plik jest wypełniony. Raport dopiero się z niego wytwarza – i to jest ten moment, w którym kody muszą być poprawne, formaty zgodne, a walidacja przechodzić.
Wyjście: jedno źródło danych, w którym powiązania są zapisane, a nie zapamiętane. Klienci, którzy przeszli z arkusza do aplikacji, mówią nam o tym samym: nie chodzi o to, że jest szybciej. Chodzi o to, że pracują w środowisku, które rozumieją, na nazwach usług, a nie na kodach. Jeśli chcesz zobaczyć, jak wygląda droga od umowy do gotowego pliku, mamy na to trzydziestosześciosekundowe nagranie z aplikacji, bez cięć i bez przyspieszania.
Powtórzmy jeszcze raz
- SPR-PF-20 nie ma dokumentu, który by o nim przypomniał. Jeśli funkcje są opisane zbyt ogólnie, reklasyfikacja dzieje się poniżej poziomu widoczności.
- Instrukcja zmienia się w trakcie. Kolumny się przestawiają, dokumenty sobie przeczą, a odpowiedzialność za dane zostaje przy Tobie.
- Zależności trzymane w głowie nie są dokumentacją. Dane mogą być kompletne, a raport i tak nie przejdzie walidacji.
Trzy pytania na ten tydzień
Nie musisz nic wdrażać, żeby sprawdzić, jak stoisz. Odpowiedz sobie na trzy pytania:
- Ile funkcji biznesowych macie faktycznie opisanych – i czy zmiana statusu którejkolwiek z nich byłaby dla kogoś zauważalna?
- Kto u Was zauważy, że usługa świadczona od trzech lat właśnie stała się istotna?
- Skąd pochodziły dane do ostatniego raportu: z rejestru czy z arkusza przygotowanego obok niego?
Jeśli zawahałeś się przy którymkolwiek, to jest właśnie ta jedna rzecz, którą warto zrobić w tym tygodniu.
