Czy banki są już gotowe?

HORYZONTY BANKOWOŚCI 2014 • REKOMENDACJA D
Czy banki są już gotowe?
Fot. Accenture Polska
Po roku prac nad wdrożeniem nowej wersji Rekomendacji D
wielu CIO i CSO wciąż nie ma pewności, czy podjęte działania
wystarczą do osiągnięcia całkowitej zgodności z przepisami.
Artur Józefiak
Manager, Accenture Polska
R
ekomendacja D, której celem jest
zapewnienie stabilnego zarządzania
obszarami IT i bezpieczeństwa IT,
została zaktualizowana przez KNF 8 stycznia
2013 r. Banki otrzymały na jej wdrożenie
prawie 24 miesiące. Jednak zważywszy na
stopień skomplikowania oraz na zakres
i skalę wymaganych zmian, czasu nie pozostało zbyt wiele.
W nowej Rekomendacji D znajdziemy
22 zalecenia, które składają się na 195 wymagań szczegółowych, zawierających łącznie
kilkaset drobiazgowych kryteriów zgodności.
Pamiętajmy, że banki muszą wypełnić każde
z tych zaleceń, albo przedstawić wiarygodne uzasadnienie, dlaczego dane kryterium
szczegółowe ich nie dotyczy.
W ciągu półtorarocznych prac z tym
dokumentem w Accenture, najpierw na
etapie jego powstawania, podczas opiniowania wersji roboczej, a obecnie na etapie
jego wdrażania, zebraliśmy wiele ciekawych
obserwacji i doświadczeń. Przede wszystkim dostrzegamy zmianę nastawienia
do obowiązku wdrożenia Rekomendacji D.
Niektóre banki zaczynają postrzegać ją nie
jako obciążenie, ale jako okazję do naprawy
długo niezaadresowanych problemów, upowszechnienia dobrych praktyk w organizacji
lub optymalizacji funkcjonujących mechanizmów. Słowem – okazję do transformacji.
Siły na zamiary
Kluczowe, szczególnie dla zarządów, jest
zrozumienie skali wyzwania, jakim jest
wdrożenie Rekomendacji D. Powinny zapew-
nić wystarczające zasoby ludzkie, finansowe oraz odpowiednio wcześnie rozpocząć
wprowadzanie koniecznych zmian. Już
samo rzetelne zweryfikowanie zgodności
z wymienionymi wcześniej kilkuset kryteriami może pochłonąć nawet kilkadziesiąt
osobodni pracy, szczególnie gdy dodamy
do tego czas potrzebny na przygotowanie
rzetelnej koncepcji zgodności, czyli wyjaśnienia, jak bank interpretuje i spełnia dane
wymagania. Uwzględniając pracochłonność
i koszty wdrożenia niezbędnych zmian
w mechanizmach (procedurach, narzędziach, dokumentach, praktykach), okazuje
się, że w dużej organizacji czas potrzebny do
wdrożenia Rekomendacji D musi być liczony
w tysiącach osobodni i w milionach złotych
wydanych m.in. na zakupy licencji, usług
wdrożeniowych czy doradczych. Dodatkowym istotnym elementem wdrożenia są potencjalne zmiany organizacyjne, które – jak
wiadomo – mogą kosztować wiele wysiłku
i pochłonąć dużo czasu.
Silosowanie wdrożenia
Ponieważ rekomendacja jest podzielona na
cztery główne obszary, naturalnym ruchem
wydaje się przypisanie poszczególnych
fragmentów czterem jednostkom banku:
Zarządzanie IT (rekomendacje 1–5), Rozwój
IT (rekomendacje 6–7), Utrzymanie IT (rekomendacje 8–18), Bezpieczeństwo/Zgodność
(rekomendacje 19–22). Zjawisko to można
nazwać „silosowaniem” wdrożenia, tzn.
przypisywaniem odpowiedzialności za realizację fragmentów Rekomendacji D poszczegól-
70
nym działom organizacji. Najczęściej dzieje
się tak bez uwzględnienia silnych zależności
pomiędzy poszczególnymi częściami oraz bez
odniesienia do całej organizacji.
Takie podejście skutkuje tym, że poszczególne działy spełniają wyodrębniony
zakres wymagań możliwie jak najlepiej,
ale patrząc na niego tylko z własnej perspektywy. W efekcie pomijają zarówno
ryzyka, jak i mechanizmy właściwe dla
innych obszarów. Tymczasem trzeba mieć
świadomość, że istnieje duża współzależność pomiędzy obszarami rekomendacji,
co oznacza, że spełnienie wymagań musi
być konsekwencją funkcjonowania całego
zbioru mechanizmów z różnych obszarów
banku. I co istotne, nie są to tylko obszary IT
i bezpieczeństwa – dla właściwego spełnienia wymagań Rekomendacji D niezbędne jest
wykorzystanie mechanizmów właściwych
dla procesów biznesowych (szczególnie
rekomendacje 3, 4 i 8), kadrowych (rekomendacja 5), logistycznych (rekomendacja
10), finansowo-kontrolingowych, prawnych
i audytu wewnętrznego.
W praktyce liderzy odpowiedzialni za
wdrożenie w skali całego banku często
spotykają się z brakiem wystarczającego
zaangażowania wewnątrz organizacji. Wiele
działów, a w szczególności strona biznesowa
organizacji, uważa że wdrożenie Rekomendacji
D leży w gestii komórek IT i bezpieczeństwa
i nie przykłada większej wagi do prac nad realizacją tego projektu. Należy mieć jednak na
względzie, że nie da się osiągnąć zgodności
w należyty sposób bez zaangażowania biznesu.
miesięcznik finansowy BANK | marzec | 2014
HORYZONTY BANKOWOŚCI 2014
To zdanie podziela również Urząd Komisji
Nadzoru Finansowego, który na podstawie
wyników analizy luki wskazuje, że w jednej
czwartej instytucji bankowych biznes nie
uczestniczy w pracach nad wdrożeniem.
Perspektywa architektoniczna
Warto zwrócić uwagę na to, że KNF, opracowując Rekomendację D, inspirowała się m.in.
metodycznym podejściem do zarządzania
architekturą korporacyjną, a nie wyłącznie
architekturą IT. Jest to wyraźnie widoczne w zapisach, które wiążą perspektywę
biznesową z perspektywą danych, aplikacji
i infrastruktury (m.in. punkty 4.2, 7.1, 7.4,
8.1). Taki punkt widzenia nie jest jeszcze powszechny w bankach, które dopiero adaptują nowe postrzeganie architektury, wykorzystując podejścia przedstawione w metodach
takich, jak TOGAF (The Open Group Architecture Framework) czy Siatka Zachmana.
Perspektywa architektoniczna jest największym wyzwaniem w obszarze danych
– obecnie banki, a szczególnie ich komórki
IT, zwykły postrzegać dane przez pryzmat
systemów, w których informacje są przetwarzane. Natomiast podejście architektoniczne
wyodrębnia dane jako samodzielną warstwę,
podobnie jak aplikacje czy elementy infrastruktury, dla której należy określić zasady
zarządzania, zależności i mierniki, o czym
mówi m.in. rekomendacja 8.
Wykorzystanie perspektywy architektury korporacyjnej do wsparcia wdrożenia
Rekomendacji D to bardzo dobry pomysł. Po
pierwsze, pomoże to spełnić wskazane powyżej oczekiwania rekomendacji i usprawni
spójne wykorzystanie mechanizmów z różnych obszarów banku i różnych warstw
(biznes, dane, aplikacje, infrastruktura). Po
drugie, dojrzała funkcja architektury korporacyjnej znacząco wspomaga współpracę
Biznes – IT (rekomendacja 4) i wspiera
innowacyjność wykorzystującą nowe
technologie jako źródło przewagi konkurencyjnej. Po trzecie, w świecie, w którym
powszechny jest outsourcing i koncepcje
takie, jak XaaS (Everything as a Service) czy
Cloud Computing, zarządzanie architekturą
korporacyjną z uwzględnieniem zależności
pomiędzy biznesem, danymi i technologią
umożliwia sprawne zarządzanie organizacją
i determinuje jej zdolność dostosowania się
do szybko zmieniającego się otoczenia.
Duch rekomendacji
Zalecenia rekomendacji wymagają interpretacji i przeniesienia w realia funkcjonowania danej organizacji. Każdy z banków
z pewnością już od lat stosuje wiele spośród
mechanizmów i rozwiązań, do których odwołuje się KNF. Sztuką dobrego wdrożenia
jest maksymalne ich wykorzystanie. Jednak
trzeba zapewnić ich spójność nie tylko po
to, by dobrze wypaść przed inspektorem
KNF, ale także dlatego, że ich pochopne łączenie lub nieprzemyślane łatanie niezgodności doraźnymi i punktowymi rozwiązaniami może rodzić negatywne skutki. Takie
działania mogą przyczynić się do utrudnienia realizacji istniejących procesów i przysporzenia frustracji pracownikom. Najważniejsze wydaje się uchwycenie ducha
rekomendacji przy minimalnych zmianach
i nakładach pracy. Dlatego rekomendujemy,
by przygotować dla każdego z jej punktów
tzw. koncepcję zgodności – czyli interpretację wyjaśniającą, w jaki sposób i jakimi
mechanizmami (zasadami, procedurami/
praktykami, narzędziami) bank realizuje
dane wymaganie. Opracowanie i uzgodnienie takiej koncepcji powinno być zadaniem
niedużego, interdyscyplinarnego zespołu,
gromadzącego przedstawicieli wszystkich
jednostek zaangażowanych we wdrożenie.
W ten sposób bank uzyska nie tylko spójne
podejście do obsługi, ale także łatwą identyfikację niezbędnych zmian w mechanizmach ze wskazaniem odpowiedzialnych za
te zmiany jednostek. Koncepcja zgodności
może służyć także jako doskonała pomoc
w momencie kontroli regulatora oraz
ułatwia zidentyfikowanie sprzecznych lub
dublujących się mechanizmów.
Najpierw metodyka
Dość częstym zjawiskiem w pracach nad
wdrożeniem rekomendacji jest literalne
traktowanie jej wymagań, bez zrozumienia
szerszego kontekstu i odwołań do całościowego modelu. Takie podejście prowadzi
często do wprowadzania dodatkowych
formalizmów i narzędzi, które – pomimo
że powierzchownie spełniają wymagania
regulacji – w rzeczywistości nie minimalizują
ryzyka związanego z obszarami IT i bezpieczeństwa IT, natomiast skutecznie komplikują funkcjonowanie procesów IT i procesów
biznesowych, upośledzając efektywność
71
organizacji. Remedium na to zagrożenie jest
odwołanie się do celu Rekomendacji D oraz
wykorzystanie standardów i metodyk, które
pomagają zorganizować dany obszar i nim
zarządzać. Część z nich jest dobrze znana
i praktykowana w wielu bankach, np. ITIL,
ISO27001, COBIT, Prince2/PMBOK czy
TOGAF. Ich wykorzystanie jest tym bardziej
uzasadnione, że praktyki te zauważalnie
były inspiracją wielu wymagań zawartych
w zaleceniach KNF.
W tym miejscu należy zwrócić uwagę na
dwie istotne kwestie. Po pierwsze, celem rekomendacji nie jest wymuszanie wdrażania
standardów, takich jak ITIL czy ISO27001
– nie zawsze warto stosować się do pełnego
zakresu tych norm. Warto natomiast potraktować standardy jako punkt odniesienia
do weryfikacji poprawności i kompletności
zastosowanego modelu oraz jako inspirację
odnośnie sposobu realizacji danych wymagań. Po drugie, dla niektórych obszarów
Rekomendacji D (np. Zarządzanie danymi,
Governance, Kontrola dostępu), odpowiednie
metodyki są mało rozpowszechnione. W takich przypadkach warto rozważyć wsparcie
firm specjalizujących się w takich tematach
lub po analizie powszechnie dostępnych
źródeł samodzielnie zbudować uproszczony
model, który nawet jeśli nie będzie doskonały, to będzie uwzględniać specyfikę danej
organizacji i pomoże spełnić oczekiwanie
KNF odnośnie przeprowadzenia analizy.
Jeszcze nie jest za późno na zmiany
Bez wątpienia wdrożenie Rekomendacji D jest
dla banków kosztem. Ale dobrze przeprowadzone może zmienić się w inwestycję,
która zwróci się nie tylko dzięki ograniczeniu ryzyka operacyjnego, ale także dzięki
usprawnieniu i ujednoliceniu w skali całej
organizacji mechanizmów, takich jak procesy, zasady, narzędzia i praktyki. Żeby jednak
osiągnąć taki efekt, potrzebne jest metodyczne podejście i zbudowanie całościowej
wizji zmian.
Choć do końca okresu przewidzianego na
wdrożenie zostało tylko 10 miesięcy, nie jest
jeszcze zbyt późno, by zweryfikować podejście i skorygować działania dostosowawcze,
tak by wyniki wdrożenia oprócz zgodności
– przyniosły też poprawę funkcjonowania
banku, w szczególności w obszarach IT
i bezpieczeństwa. 
www.aleBank.pl