Gdzie technologia tworzy ryzyko finansowe? Kluczowe obszary dla CFO

O ryzyku technologicznym dowiadujesz się zwykle za późno — wtedy, gdy firma już ponosi jego koszty. System pada w szczycie sprzedaży, klienci zgłaszają, że nie mogą dokończyć zakupu, a rachunek za chmurę rośnie szybciej niż liczba klientów i nikt nie zgłosił tego jako ryzyka, dopóki kwota nie zrobiła się duża. Te skutki bywają nagłe albo narastają miesiącami — widać je zwykle dopiero po fakcie. Są cztery obszary, w których technologia generuje ten koszt najczęściej i każdy z nich wymaga podjęcia decyzji: ograniczyć ryzyko teraz czy świadomie je zaakceptować.

Jak czytać ryzyko technologiczne jako ekspozycję finansową

Ryzyko finansowe wynikające z technologii to w uproszczeniu prawdopodobieństwo, że coś się wydarzy, pomnożone przez skutek. A skutek to rozmiar (ilu klientów lub transakcji dotknie problem) razy czas jego trwania.

Ryzyko = Prawdopodobieństwo × Rozmiar × Czas trwania

Dla CFO punktem odniesienia jest mechanizm przychodu firmy. W e-commerce awaria płatności bezpośrednio zatrzymuje sprzedaż. W modelu subskrypcyjnym niestabilność produktu może zwiększyć liczbę rezygnacji w kolejnych miesiącach. Ocena ekspozycji wymaga więc powiązania kluczowych procesów biznesowych z systemami, od których zależy ich ciągłość.

Interesują Cię finansowe konsekwencje stanu technologii, a nie sam kod. Dlatego od zespołu technicznego potrzebujesz odpowiedzi na trzy pytania:

• jak prawdopodobny jest dany scenariusz,
• jak dużą część biznesu może objąć,
• jak długo potrwa przywrócenie działania.

Zespół techniczny oszacuje prawdopodobieństwo, skalę i czas; Ty — razem z biznesem — przełożysz to na koszt i porównasz go z ceną ograniczenia ryzyka. Dopiero wtedy zdecydujesz, czy firma powinna ryzyko zmniejszyć, czy świadomie je zaakceptować.

Diagram rozkłada ryzyko na trzy elementy, które warto czytać osobno:

• Skala skutku określa, ilu klientów lub transakcji może dotknąć problem. Zależnie od modelu biznesowego może oznaczać utraconą sprzedaż albo wzrost liczby rezygnacji.
• Czas trwania obejmuje okres od wystąpienia problemu do jego wykrycia, a następnie do przywrócenia prawidłowego działania.
• Prawdopodobieństwo ocenia zespół techniczny na podstawie stanu systemu i stosowanych zabezpieczeń, takich jak testy, monitoring czy procedury bezpiecznego wdrażania zmian.

Kolejne rozdziały opisują cztery obszary, w których ta ekspozycja bywa największa: awarie i przestoje, dane, bezpieczeństwo oraz architekturę.

1. Awarie i przestoje: koszt zakłóceń w kluczowych procesach

Jednym z typowych scenariuszy jest przeciążenie aplikacji w okresie wzmożonego ruchu. Wraz ze wzrostem liczby użytkowników wydłuża się czas odpowiedzi, pojawiają się błędy, a kluczowe procesy przestają działać. Źródłem problemu może być również awaria jednego krytycznego systemu. Pozostałe elementy aplikacji mogą działać bez zarzutu, ale z perspektywy użytkownika produkt nie spełnia swojego zadania. Awaria pojedynczego elementu potrafi więc wywołać skutki równe pełnemu przestojowi.

O łącznym koszcie awarii decyduje nie tylko sam incydent, ale też to, jak szybko uda się przywrócić normalne działanie systemu. Jeśli zespół nie ma sprawdzonych procedur na wypadek awarii, nawet niewielka usterka może przerodzić się w długi przestój i realne straty finansowe.

Załóżmy, że ostatni okres wzmożonego ruchu pokazał, że system sobie nie radzi. W takiej sytuacji warto oszacować, ile będzie kosztować wzmocnienie systemu tak, aby lepiej radził sobie z podobnymi przeciążeniami w przyszłości. Taki szacowany koszt warto porównać z potencjalną stratą finansową, którą firma mogłaby ponieść przy kolejnym podobnym incydencie. Dopiero na tej podstawie można podjąć racjonalną decyzję o inwestycji.

Kiedy awarii nie widać na pierwszy rzut oka

Szczególnie kosztowne bywają awarie, których nikt na czas nie zauważa. Strona się ładuje, monitoring infrastruktury nic nie zgłasza, a dodanie produktu do koszyka kończy się błędem i zakup się nie udaje. Dla użytkownika to awaria, choć na panelu stanu serwerów wszystko wygląda prawidłowo. Dopóki nikt nie zgłosi problemu, firma traci przychód. Dlatego trzeba monitorować procesy, na których firma zarabia, a nie tylko metryki techniczne.

Nie każdy element systemu wymaga równie szybkiej reakcji. Usterka addonu używanego przez część klientów może poczekać. Awaria procesu zakupowego albo logowania, bez którego produkt przestaje działać, uderza w firmę od razu. Właśnie takie procesy trzeba monitorować najściślej, żeby ich awarie były wykrywane na bieżąco, a nie dopiero ze zgłoszeń klientów.

Koszt awarii liczy się od jej wystąpienia, nie od wykrycia

Czas trwania incydentu liczy się od jego wystąpienia, a nie wykrycia. Jeśli dowiadujesz się o nim od klienta, możesz nawet nie wiedzieć, od jak dawna firma traci pieniądze.

Na drugą część tego czasu wpływa tempo ustalenia przyczyny awarii. Zespół z dostępem do logów, alertów i historii zmian znajduje ją w kilkanaście minut. Bez tych narzędzi ta sama diagnoza może zająć kilka dni, a straty rosną przez cały ten okres. Z perspektywy finansowej opłaca się więc zadbać o to, żeby nie dowiadywać się o awariach od klientów.

2. Utrata i niespójność danych: koszty, które pojawiają się z opóźnieniem

W przypadku danych problemem nie jest niedostępność systemu. Dane znikają, ulegają uszkodzeniu albo przestają się zgadzać, a skutki pojawiają się później: konieczność ręcznego poprawiania rekordów, błędne decyzje, utrata zaufania klientów albo konsekwencje prawne.

Pierwszy scenariusz dotyczy kopii zapasowych. Kopie mogą powstawać nieregularnie, obejmować tylko część rekordów albo nigdy nie zostać sprawdzone: np. jeśli nikt nie spróbował odtworzyć z nich danych. Awaria bazy danych oznacza wtedy nie tylko przestój, ale też realne ryzyko, że firma nie zdoła odzyskać utraconych informacji i wrócić do normalnego działania.

Drugi scenariusz to niespójność danych: po nieudanym wdrożeniu, migracji albo serii ręcznych korekt system nadal działa, ale liczby przestają się zgadzać. Zespół prostuje je ręcznie, poza systemem. Każda taka poprawka kosztuje czas i zwiększa ryzyko kolejnego błędu.

Osobnym wariantem — bliższym już bezpieczeństwu i kontroli dostępu — jest utrata kontroli nad danymi poza firmą. Przy zmianie dostawcy albo integratora łatwo to przeoczyć: współpraca się kończy, ale dane zostają po stronie byłego partnera. Dopóki nie ma potwierdzenia, że zostały usunięte, istnieje ryzyko wycieku. Jeśli obejmie on dane wrażliwe, firma poniesie koszty reakcji, a utrata zaufania może skłonić część klientów do odejścia do konkurencji.

3. Incydenty bezpieczeństwa: koszty nieautoryzowanego dostępu

Incydent bezpieczeństwa może zacząć się od przejętego konta, ujawnionego klucza dostępu albo nieusuniętej luki w oprogramowaniu. Skutki finansowe pojawiają się, gdy ktoś uzyska dostęp do danych lub funkcji, z których nie powinien korzystać. Firma ponosi wtedy koszty opanowania incydentu, zabezpieczenia systemu i przywrócenia jego normalnego działania. Może też stracić klientów, a w branżach regulowanych — zapłacić karę.

Z perspektywy CFO liczy się skala możliwych konsekwencji: do jakich danych i operacji może uzyskać dostęp osoba nieuprawniona oraz ilu klientów obejmie incydent. Osobno warto ocenić, czy zespół będzie potrafił szybko wykryć naruszenie i ustalić jego przebieg — bo od tego zależy, jak długo potrwa ekspozycja i jak bardzo urośnie rachunek.

Ryzyko rośnie, gdy uprawnienia są zbyt szerokie, klucze i hasła nie są odpowiednio chronione, znane luki pozostają nieusunięte, a system nie rejestruje działań potrzebnych do wykrycia i przeanalizowania incydentu.

Warto więc zapytać zespół, jakiego typu incydent może przynieść firmie największe straty, jak szybko zespół będzie w stanie go wykryć i jakie zabezpieczenia najbardziej ograniczą jego potencjalny koszt.

4. Architektura: koszt utrzymania i blokada skalowania

Tu ryzyko rzadko przybiera formę jednego głośnego incydentu. Częściej rośnie koszt utrzymania i rozwoju: każda kolejna zmiana zajmuje więcej czasu, budżet IT pochłania coraz więcej środków, a przy skalowaniu albo dodawaniu nowej integracji okazuje się, że system wymaga kosztownej przebudowy.

Na architekturę systemu składają się decyzje, których nie da się później tanio zmienić. Błędy często długo pozostają niewidoczne, bo system nadal działa. Ujawniają się dopiero wtedy, gdy każda nowa funkcja wymaga coraz więcej pracy, koszty infrastruktury rosną szybciej niż liczba klientów, a dostosowanie systemu do rosnącej skali biznesu wymaga przebudowy jego dużej części.

Dlatego architektura jest decyzją biznesową, nawet jeśli w firmie traktuje się ją jak sprawę czysto techniczną. A skoro jest decyzją biznesową, CFO powinien wiedzieć, kto ją podejmuje i na jakiej podstawie. Czy przed wyborem konkretnego rozwiązania ktoś w firmie ocenia:

• ile dane rozwiązanie będzie kosztować w utrzymaniu,
• jakie ryzyko się z nim wiąże,
• czy udźwignie plany rozwoju na najbliższe lata.

To samo wydarzenie, inny rachunek

Sposób budowy systemu decyduje o tym, jak drogi okaże się dany incydent. Przykładem może być integracja z zewnętrznym dostawcą. Jeśli jej awaria zatrzymuje cały produkt, skutki obejmują wszystkich klientów. Jeśli integracja jest odizolowana od reszty systemu, pozostałe funkcje nadal działają, a problem dotyka tylko korzystających z niej klientów. Izolacja nie zmniejsza prawdopodobieństwa awarii samej integracji, ale ogranicza jej zasięg i koszt.

Jak ocenić ryzyko, zanim firma poniesie jego koszty

Znasz już cztery obszary, w których technologia tworzy ryzyko finansowe. Teraz trzeba ustalić, które z tych zagrożeń rzeczywiście dotyczą Twojego systemu i jakie straty mogą spowodować. Nie da się tego ocenić wyłącznie na podstawie danych finansowych. Potrzebna jest ocena wykonana przez zespół techniczny.

Przekaż CTO lub liderowi technicznemu checklistę stanu technicznego produktu. Obejmuje ona te same obszary, które omówiliśmy: odporność systemu na awarie, dane, bezpieczeństwo i architekturę. Po wypełnieniu przez zespół techniczny dowiesz się:

• które praktyki techniczne są spełnione, a które nie,
• w których obszarach ryzyko jest najwyższe,
• jakie skutki biznesowe te luki mogą wywołać — na przykład przestój, utratę danych, wyciek albo rosnący koszt utrzymania.

To wystarczy, żebyś ocenił skalę ekspozycji i zdecydował: ograniczyć ryzyko lub świadomie je zaakceptować. Tam, gdzie decydujesz się je ograniczyć, efekt zobaczysz w metrykach pokazujących finansowe skutki stanu technologii: koszcie przestojów, średnim czasie naprawy awarii (MTTR) czy koszcie chmury na klienta.

Jeśli checklista wykaże pojedyncze luki, zespół będzie mógł usunąć je punktowo. Jeśli jednak problemy wynikają z konstrukcji całego systemu — na przykład każda zmiana jest coraz droższa, skalowanie wymaga przebudowy dużej części aplikacji, a koszt utrzymania rośnie szybciej niż biznes — lokalne poprawki nie usuną źródła ryzyka. To moment, w którym warto rozważyć przepisanie systemu.

Podsumowanie

Technologia tworzy ryzyko finansowe przede wszystkim w czterech obszarach: awarie i przestoje, dane, bezpieczeństwo oraz architektura. W każdym z nich liczy się to samo: ilu klientów lub transakcji może dotyczyć problem, jak długo potrwa i ile będzie kosztować.

Największe straty pojawiają się na dwa sposoby. Czasem ekspozycja ujawnia się nagle — w szczycie sprzedaży, przy wdrożeniu albo w dniu incydentu bezpieczeństwa. Częściej jednak narasta miesiącami w ukryciu: w niesprawdzonych kopiach zapasowych, rosnącym koszcie utrzymania albo lukach, o których firma dowiaduje się dopiero wtedy, gdy zaczyna realnie płacić za przestój, utratę danych albo kosztowną przebudowę systemu.