Regulacje przekrojowe w organizacji zarządzanej procesowo
Duży bank jest organizacją z natury złożoną. Podział na piony, departamenty i zespoły pozwala specjalizować kompetencje, przypisywać odpowiedzialność kierowniczą i zarządzać działalnością prowadzoną jednocześnie w wielu obszarach. Sama struktura organizacyjna nie opisuje jednak w pełni sposobu działania banku. Obok niej funkcjonuje architektura procesowa, w której poszczególne czynności są łączone według celu i rezultatu, a nie wyłącznie według tego, w której jednostce organizacyjnej są wykonywane. Jeden proces może więc przebiegać przez kilka departamentów, angażować jednostki należące do różnych linii obrony, wykorzystywać kilka systemów informatycznych i kończyć się decyzją podejmowaną jeszcze w innej części organizacji. Takie podejście ma szczególne znaczenie z perspektywy systemu kontroli wewnętrznej. Rekomendacja H wiąże cele systemu kontroli wewnętrznej z procesami funkcjonującymi w banku, a w odniesieniu do matrycy funkcji kontroli – z procesami istotnymi, kluczowymi mechanizmami kontrolnymi i ich niezależnym monitorowaniem. Odrębnym elementem bankowej praktyki zarządzania procesowego jest przypisywanie odpowiedzialności za całość procesu jego właścicielowi. Model taki opisują również Dobre Praktyki ZBP w zakresie właścicielstwa procesu.
Z perspektywy wdrożeń regulacyjnych jest to rozwiązanie bardzo użyteczne. Jeżeli nowy wymóg wpływa przede wszystkim na jeden istniejący proces, można ustalić zakres potrzebnej zmiany, określić jej wpływ na przebieg procesu, role uczestników, regulacje wewnętrzne i mechanizmy kontrolne, a następnie osadzić odpowiedzialność za dostosowanie w ramach istniejącego właścicielstwa procesowego. Nawet jeżeli wykonanie zmiany wymaga zaangażowania kilku jednostek organizacyjnych, nadal istnieje jeden punkt, z którego można oceniać kompletność oraz spójność rezultatu. Znacznie trudniejsze są regulacje przekrojowe, które nie zmieniają jednego procesu, lecz jednocześnie oddziałują na kilka procesów albo tworzą pomiędzy nimi nowe zależności. W takim przypadku każdy z procesów posiada już własny cel, właściciela, uczestników, dane, regulacje wewnętrzne i mechanizmy kontrolne. Nowy obowiązek nie zastępuje tej architektury, lecz nakłada się na nią i wymaga, aby kilka elementów organizacji zaczęło działać według wspólnej logiki regulacyjnej. To, co z perspektywy przepisu stanowi jeden obowiązek banku, po przełożeniu na rzeczywiste funkcjonowanie instytucji może więc wymagać zmian w kilku procesach pozostających pod odpowiedzialnością różnych właścicieli.
Właśnie w tym miejscu pojawia się problem charakterystyczny dla dużych wdrożeń regulacyjnych. Podział wymogów pomiędzy właścicieli procesów pozwala przypisać odpowiedzialność za poszczególne części zmiany, ale nie odpowiada jeszcze na pytanie o odpowiedzialność za ich wzajemną spójność. Każdy właściciel może prawidłowo dostosować własny proces, a mimo to rezultat kilku takich dostosowań nie musi tworzyć mechanizmu zapewniającego wykonanie obowiązku regulacyjnego przez bank jako całość. Różnice mogą dotyczyć wykorzystywanych danych, definicji, częstotliwości działania, momentu przekazywania informacji, zakresu decyzji albo założeń przyjętych w poszczególnych procesach. Problemem nie jest wówczas niewykonanie przypisanego zadania, lecz brak właściwego zaprojektowania zależności pomiędzy zadaniami wykonanymi prawidłowo. To odróżnia wdrożenie przekrojowe od zwykłego podziału prac wdrożeniowych pomiędzy kilka jednostek. W tym drugim przypadku mamy jeden proces, którego zmiana wymaga współdziałania wielu uczestników. W pierwszym zmieniamy kilka procesów i musimy dodatkowo zapewnić, że po zmianie będą one współdziałały zgodnie z logiką wynikającą z nowej regulacji. Odpowiedzialność właściciela procesu nadal pozostaje podstawowym elementem tej konstrukcji, ale obok niej powstaje odrębne zagadnienie odpowiedzialności za zależności przekraczające granice poszczególnych procesów.
Dobrym aktualnym przykładem takiej sytuacji może być jeden z elementów implementacji CRD VI dotyczący ryzyka środowiskowego, społecznego i z zakresu ładu korporacyjnego, czyli ryzyka ESG. Nie chodzi przy tym o ponowne omawianie nowych wymogów zarządzania tym ryzykiem, lecz o wykorzystanie ich jako przykładu organizacyjnego. Plan dotyczący ryzyka ESG może mieć swoje naturalne miejsce w obszarze zarządzania ryzykiem, jednak jego treść nie może powstać w oderwaniu od strategii banku, planowania działalności, oceny adekwatności kapitału wewnętrznego, zarządzania poszczególnymi rodzajami ryzyka, danych wykorzystywanych przez bank ani procesów biznesowych, w których podejmowane są decyzje wpływające na strukturę ekspozycji. Każdy z tych obszarów może jednocześnie funkcjonować jako odrębny proces posiadający własnego właściciela i własne mechanizmy kontrolne. W takim przypadku pytanie o to, komu należy przypisać „wdrożenie CRD VI”, jest źle postawione. Równie niewystarczające byłoby wskazanie jednego właściciela procesu, który miałby odpowiadać za całość zmiany. Istotą wdrożenia staje się zapewnienie, że kilka procesów zostanie zmienionych zgodnie z jednym rozumieniem wymogu regulacyjnego, a zależności pomiędzy nimi zostaną świadomie zaprojektowane. Dopiero wtedy można mówić o przejściu od wykonania zestawu działań projektowych do rzeczywistego wbudowania nowej regulacji w sposób funkcjonowania banku.
To prowadzi do podstawowego pytania tego artykułu: jak zarządzać zmianą regulacyjną, której nie można przypisać jednemu procesowi, ponieważ jej prawidłowe wdrożenie zależy od spójnego działania kilku procesów mających różnych właścicieli? Odpowiedź wymaga najpierw rozdzielenia dwóch rzeczy, które w projektach regulacyjnych bywają traktowane jako tożsame: wykonania działań przewidzianych w planie wdrożenia oraz osiągnięcia stanu, w którym nowy wymóg rzeczywiście stał się częścią normalnego funkcjonowania banku.
Projekt wdrożeniowy nie jest jeszcze wdrożeniem regulacji
W praktyce duże zmiany regulacyjne są najczęściej organizowane w formule projektu. Jest to rozwiązanie naturalne. Nowa regulacja ma określony termin rozpoczęcia stosowania, wymaga przeprowadzenia analizy luk, zidentyfikowania obszarów wymagających dostosowania, przypisania odpowiedzialności oraz monitorowania postępu prac. Powstaje plan wdrożenia, w którym poszczególne działania otrzymują odpowiedzialnych i terminy, a ich realizacja jest raportowana do komitetu sterującego, zarządu albo innego forum nadzorującego projekt. Taki sposób organizacji pozwala zarządzić dużą liczbą zmian i ograniczyć ryzyko, że któryś z wymogów zostanie pominięty.
Projekt jest jednak wyłącznie sposobem przeprowadzenia organizacji ze stanu obecnego do stanu docelowego. Sam nie jest tym stanem docelowym. To rozróżnienie wydaje się oczywiste, ale właśnie na nim może pojawić się jedna z podstawowych słabości wdrożeń przekrojowych. Projekt mierzy bowiem przede wszystkim wykonanie określonych działań: przygotowanie albo zmianę regulacji wewnętrznej, dostosowanie systemu, przyjęcie metodologii, przeprowadzenie szkolenia, zmianę formularza, ustanowienie mechanizmu kontrolnego czy przygotowanie nowego raportu. Każde z tych działań może zostać prawidłowo wykonane i formalnie zamknięte. Nie przesądza to jeszcze, że bank potrafi od następnego dnia wykonywać nowy obowiązek jako element swojej zwykłej działalności. Różnica staje się szczególnie widoczna wtedy, gdy regulacja oddziałuje na kilka procesów. W projekcie można rozdzielić poszczególne zadania pomiędzy ich właścicieli i otrzymać prawidłowo wypełniony plan działań. Jeden proces zostanie uzupełniony o nowe dane, drugi o dodatkową decyzję, trzeci o nowy sposób raportowania, a czwarty o zmieniony mechanizm kontrolny. Jeżeli jednak prawidłowe wykonanie obowiązku wymaga, aby informacja powstająca w pierwszym procesie uruchamiała działanie drugiego, jego wynik był następnie wykorzystywany w trzecim, a całość znajdowała odzwierciedlenie w czwartym, przedmiotem wdrożenia stają się nie tylko poszczególne działania, lecz również relacje pomiędzy procesami. Tych relacji nie zawsze da się uchwycić poprzez samo monitorowanie realizacji zadań projektowych.
Możliwa jest więc sytuacja pozornie paradoksalna: projekt zostaje zakończony zgodnie z harmonogramem, wszystkie działania mają status wykonanych, a dopiero pierwsze rzeczywiste zastosowanie nowych regulacji pokazuje, że organizacja nie potrafi przeprowadzić obowiązku od początku do końca. Jedna jednostka nie wie, że powinna przekazać informację drugiej. Dwa procesy korzystają z danych aktualizowanych w różnym rytmie. Procedury przypisują odpowiedzialność za poszczególne czynności, ale żadna nie wskazuje, kto ma rozstrzygnąć rozbieżność pomiędzy ich wynikami. Mechanizm kontrolny bada prawidłowość własnego fragmentu procesu, nie pozwalając ustalić, czy cały łańcuch prowadzi do rezultatu wymaganego przez regulację. Nie jest to argument przeciwko projektowemu sposobowi prowadzenia wdrożeń. Bez takiej organizacji zarządzanie zmianą regulacyjną obejmującą wiele jednostek i procesów byłoby znacznie trudniejsze. Problem pojawia się wtedy, gdy logika projektu zaczyna zastępować logikę działania banku. Projekt posiada własną strukturę zarządczą, własny sposób raportowania, osoby odpowiedzialne za poszczególne strumienie prac i często również rozwiązania tymczasowe pozwalające dotrzymać terminu regulacyjnego. Po zakończeniu wdrożenia ta struktura zazwyczaj przestaje istnieć. Jeżeli odpowiedzialności, przepływy informacji i mechanizmy kontroli nie zostały wcześniej przeniesione do procesów docelowych, zamknięcie projektu może oznaczać jednocześnie utratę mechanizmu, który zapewniał spójność zmiany.
Dlatego moment zakończenia projektu regulacyjnego powinien być oceniany inaczej niż moment wykonania ostatniego działania z planu. Stan docelowy powinien oznaczać, że nowy wymóg ma określone miejsce w istniejących procesach banku, wiadomo, jakie zdarzenie uruchamia jego stosowanie, kto wykonuje poszczególne czynności, jakie informacje są pomiędzy procesami przekazywane, kto podejmuje wymagane decyzje, jakie mechanizmy kontrolne zabezpieczają ich prawidłowość oraz w jaki sposób ich działanie będzie później niezależnie monitorowane. Dopiero wtedy odpowiedzialność zostaje przeniesiona z tymczasowej struktury projektu do stałej architektury zarządzania bankiem.
Wdrożenie CRD VI dobrze pokazuje tę różnicę. Jeżeli plan dotyczący ryzyka ESG zostanie opracowany, zatwierdzony i umieszczony w odpowiedniej regulacji wewnętrznej, można uznać za wykonane bardzo ważne działanie wdrożeniowe. Nie oznacza to jednak jeszcze, że wymagania związane z tym planem zostały wbudowane w funkcjonowanie banku. Cele i założenia planu muszą znaleźć odzwierciedlenie tam, gdzie podejmowane są decyzje mające wpływ na profil ryzyka banku, jego strategię, planowanie, ocenę adekwatności kapitału czy strukturę prowadzonej działalności. Jeżeli poszczególne procesy nadal działają według wcześniejszej logiki, nowy dokument może istnieć formalnie obok nich, zamiast rzeczywiście wpływać na sposób prowadzenia działalności. W tym miejscu ujawnia się ograniczenie klasycznej analizy luk. Pozwala ona bardzo dobrze odpowiedzieć na pytanie, czego w banku brakuje w porównaniu z nowym wymogiem, ale nie zawsze pokazuje, jak zmiana jednego elementu wpływa na pozostałe elementy istniejącej architektury procesowej. Jeżeli regulacja wymaga ustanowienia nowego celu, analiza wskaże konieczność jego określenia. Jeżeli konieczne jest nowe raportowanie, wskaże potrzebę jego utworzenia. Jeżeli potrzebny jest mechanizm kontrolny, zostanie on dodany. W regulacji przekrojowej równie ważne jest jednak ustalenie, czy cel, dane wykorzystywane do jego monitorowania, decyzje podejmowane na ich podstawie i mechanizmy kontrolne tworzą razem jeden ciąg działania.
Kryterium ukończenia wdrożenia powinno więc obejmować nie tylko wykonanie poszczególnych działań, lecz również sprawdzenie działania zależności pomiędzy procesami w stanie docelowym. Nie chodzi przy tym wyłącznie o formalne uzgodnienie dokumentów. Regulacje wewnętrzne mogą być ze sobą zgodne, a rzeczywisty przepływ informacji nadal nie działać. Potrzebna jest możliwość przejścia przez konkretny przypadek i sprawdzenia, czy zdarzenie powstające w jednym procesie zostanie prawidłowo rozpoznane, czy uruchomi działanie kolejnego procesu, czy właściwa osoba otrzyma potrzebne informacje i czy rezultat wróci tam, gdzie powinien zostać wykorzystany. Tak rozumiane wdrożenie zmienia również sposób patrzenia na odpowiedzialność. Osoba kierująca projektem może odpowiadać za terminowe wykonanie planu, a właściciele procesów za dostosowanie procesów pozostających w ich gestii. Nadal pozostaje jednak pytanie, kto odpowiada za to, że po zakończeniu projektu kilka zmienionych procesów będzie działało jako jeden mechanizm realizujący przekrojowy obowiązek regulacyjny. Nie da się rozwiązać tego problemu poprzez samo dodanie kolejnego działania do harmonogramu. Wymaga on określenia relacji pomiędzy odpowiedzialnością za zmianę regulacyjną a istniejącym właścicielstwem procesów.
Właściciel procesu rozwiązuje część problemu
Właścicielstwo procesu jest jednym z podstawowych mechanizmów pozwalających dużej organizacji wyjść poza ograniczenia wynikające z jej struktury organizacyjnej. Jeżeli proces przebiega przez kilka jednostek, potrzebna jest perspektywa obejmująca jego całość: od zdarzenia rozpoczynającego proces, przez kolejne czynności i decyzje, aż po rezultat, który ma zostać osiągnięty. Właściciel procesu pozwala tę perspektywę zachować, nawet jeżeli poszczególne elementy procesu pozostają wykonywane przez różne jednostki, znajdujące się w różnych pionach i realizujące odmienne zadania. Z punktu widzenia wdrożeń regulacyjnych jest to naturalny punkt odniesienia. Jeżeli nowy wymóg zmienia sposób realizacji istniejącego procesu, odpowiedzialność za jego dostosowanie powinna zostać osadzona właśnie w tym procesie. Nie byłoby właściwe tworzenie obok normalnej działalności banku trwałego „procesu regulacyjnego”, który przejmowałby wykonywanie obowiązków tylko dlatego, że wynikają one z nowej regulacji. Funkcja prawna może wspierać ustalenie treści i konsekwencji prawnych nowego wymogu oraz jego spójne przełożenie na rozwiązania banku. Funkcja zgodności, poprzez komórkę do spraw zgodności, wykonuje natomiast przypisane jej zadania związane z identyfikacją i oceną ryzyka braku zgodności oraz mechanizmami jego kontroli. Żadna z tych funkcji nie powinna jednak zastępować właścicieli procesów w odpowiedzialności za docelowy sposób ich działania.
Właścicielstwo procesu dobrze odpowiada również logice systemu kontroli wewnętrznej. Jeżeli zmiana regulacyjna wpływa na sposób osiągania celu procesu, może wymagać zmiany mechanizmów kontrolnych, zakresu informacji wykorzystywanych przy podejmowaniu decyzji, odpowiedzialności uczestników procesu albo zasad niezależnego monitorowania. Nie powinny to być elementy dołączane do procesu z zewnątrz wyłącznie na potrzeby projektu wdrożeniowego. Powinny stać się częścią jego normalnego funkcjonowania i być oceniane razem z pozostałymi mechanizmami służącymi zapewnieniu prawidłowej realizacji procesu. Procesowy charakter organizacji nie znosi przy tym niezależności poszczególnych poziomów systemu zarządzania ryzykiem i systemu kontroli wewnętrznej; właścicielstwo procesu nie oznacza przejęcia odpowiedzialności za niezależne zadania wykonywane w drugiej i trzeciej linii obrony.
Ograniczenie właścicielstwa procesowego ujawnia się dopiero wtedy, gdy jeden wymóg regulacyjny nie może zostać sprowadzony do zmiany jednego procesu. Wówczas mechanizm, który bardzo dobrze porządkuje odpowiedzialność w obrębie każdego z procesów, nie daje jeszcze odpowiedzi na pytanie o relacje pomiędzy nimi. Każdy właściciel odpowiada przede wszystkim za rezultat własnego procesu. Nowa regulacja może natomiast wymagać rezultatu, który powstaje dopiero przez współdziałanie kilku procesów i którego żaden z nich samodzielnie nie jest w stanie zapewnić. Nie oznacza to, że nad właścicielami procesów trzeba ustanowić jeszcze jednego, nadrzędnego właściciela wszystkich procesów objętych regulacją. Taka konstrukcja mogłaby prowadzić do rozmycia istniejących odpowiedzialności i stworzenia równoległego modelu zarządzania, funkcjonującego obok architektury procesowej banku. Jeżeli właściciel procesu odpowiada za jego prawidłowe działanie, nie powinien tracić tej odpowiedzialności tylko dlatego, że określona zmiana ma charakter przekrojowy. Potrzebny jest natomiast mechanizm pozwalający zarządzać tym, czego żaden właściciel pojedynczego procesu nie może zapewnić sam: spójnością założeń, przepływem informacji i zależnościami pomiędzy procesami.
W tym miejscu warto odróżnić właścicielstwo procesu od odpowiedzialności za zmianę przekrojową. Pierwsze ma charakter trwały. Po zakończeniu projektu właściciel nadal odpowiada za funkcjonowanie procesu, jego adekwatność, właściwe mechanizmy kontrolne oraz zmiany wymagane w przyszłości. Drugie ma inny przedmiot. Nie polega na przejęciu procesu, lecz na zapewnieniu, że kilka procesów zostanie zmienionych według jednej logiki regulacyjnej i że zostaną zidentyfikowane oraz zaprojektowane zależności pomiędzy nimi. Taka odpowiedzialność nie musi również należeć do funkcji, która jako pierwsza zidentyfikowała nowy obowiązek. Częstym rozwiązaniem jest powierzenie funkcji prawnej albo funkcji zgodności roli koordynacyjnej przy wdrożeniu nowej regulacji. Ma to uzasadnienie: funkcje te posiadają kompetencje pozwalające ustalić treść nowych wymagań, zapewnić spójność ich interpretacji oraz wskazywać ryzyka wynikające z proponowanych rozwiązań. Nie oznacza to jednak, że powinny projektować wszystkie zmiany procesowe, decydować o rozwiązaniach operacyjnych albo później odpowiadać za ich wykonywanie.
W przeciwnym razie łatwo powstaje model, w którym formalnie istnieją właściciele procesów, ale rzeczywiste decyzje dotyczące sposobu ich dostosowania podejmowane są w projekcie regulacyjnym. Po jego zakończeniu odpowiedzialność wraca do właścicieli procesów, którzy przejmują rozwiązania zaprojektowane częściowo poza ich normalnym modelem zarządzania. Taki sposób działania może być konieczny w sytuacji silnej presji terminowej, ale jako model docelowy osłabia właśnie tę zasadę, na której opiera się procesowe zarządzanie bankiem: odpowiedzialność za proces powinna pozostawać tam, gdzie istnieje możliwość rzeczywistego zarządzania jego przebiegiem i rezultatem. Dlatego w przekrojowym wdrożeniu potrzebne są dwa uzupełniające się poziomy odpowiedzialności. Właściciele procesów odpowiadają za to, aby procesy pozostające w ich gestii zostały właściwie dostosowane i po zakończeniu projektu funkcjonowały zgodnie z nowymi wymaganiami. Równolegle potrzebny jest mechanizm zapewniający spójność wdrożenia jako całości, identyfikujący zależności pomiędzy procesami i pozwalający rozstrzygać sytuacje, w których rozwiązanie prawidłowe z perspektywy jednego procesu nie zapewnia właściwego rezultatu na poziomie całego banku.
Przedmiotem tego drugiego poziomu są przede wszystkim zależności. Trzeba ustalić, czy dane powstające w jednym procesie rzeczywiście mogą zostać wykorzystane w drugim, czy stosowane definicje są spójne, czy momenty aktualizacji odpowiadają sobie, czy decyzja jednego właściciela uruchamia właściwe działanie u drugiego oraz czy istnieje mechanizm rozstrzygania sytuacji, w której potrzeby kilku procesów pozostają ze sobą sprzeczne. Sama lista właścicieli procesów objętych zmianą nie daje więc pełnej odpowiedzi na pytanie o odpowiedzialność za wdrożenie przekrojowe. Trzeba zarządzać nie tylko tym, co każdy z właścicieli ma zmienić w swoim procesie, lecz również tym, co musi wydarzyć się pomiędzy procesami, aby wszystkie te zmiany tworzyły jeden działający mechanizm.
CRD VI jako przykład: jeden wymóg, kilka procesów
Plan dotyczący ryzyka ESG dobrze pokazuje, dlaczego przekrojowego wdrożenia nie da się sprowadzić do wskazania jednej jednostki odpowiedzialnej i jednego dokumentu końcowego. Z perspektywy regulacyjnej obowiązek może być opisany stosunkowo zwarto: bank ma posiadać plany dotyczące ryzyka ESG obejmujące mierzalne cele oraz procesy monitorowania i przeciwdziałania ryzykom finansowym wynikającym z czynników ESG w perspektywie krótkiej, średniej i długiej. Z perspektywy organizacyjnej taki plan zaczyna jednak oddziaływać na kilka istniejących procesów, które mają odmienne cele i właścicieli. Pierwszym z nich jest oczywiście proces zarządzania ryzykiem. To tutaj naturalnie lokuje się identyfikacja, ocena i monitorowanie ryzyka ESG oraz jego uwzględnienie w zarządzaniu poszczególnymi kategoriami ryzyka. W tym samym obszarze mogą zostać osadzone mierzalne cele oraz mechanizmy pozwalające oceniać ich realizację. Gdyby jednak wdrożenie zakończyć na dostosowaniu procesu zarządzania ryzykiem, plan miałby przede wszystkim charakter kontrolny i sprawozdawczy. Tymczasem jego znaczenie polega również na tym, że powinien oddziaływać na sposób, w jaki bank planuje swoją działalność w różnych horyzontach czasowych.
Dlatego kolejnym obszarem jest zarządzanie strategiczne. Jeżeli bank identyfikuje długoterminowe ryzyko wynikające z określonej struktury ekspozycji albo zakłada zmianę sposobu finansowania wybranych sektorów, trudno traktować te założenia wyłącznie jako element planu przygotowanego przez obszar ryzyka. Powinny one pozostawać spójne z kierunkami rozwoju działalności, strukturą portfela i założeniami dotyczącymi sposobu osiągania celów biznesowych. Jeżeli strategia zakłada wzrost w obszarze, którego ekspozycja jest jednocześnie ograniczana przez przyjęty plan dotyczący ryzyka ESG, problemem nie jest tylko niespójność dwóch dokumentów. Problemem jest brak uzgodnienia pomiędzy dwoma procesami decyzyjnymi. Podobna zależność powstaje pomiędzy planem a planowaniem finansowym. Cele dotyczące struktury portfela, ograniczania określonych ekspozycji albo zwiększania finansowania innych rodzajów działalności mogą wpływać na prognozowane przychody, wykorzystanie kapitału, koszty finansowania oraz oczekiwaną rentowność. Jeżeli proces zarządzania ryzykiem przyjmuje określoną ścieżkę dostosowania, a plan finansowy nadal odzwierciedla wcześniejszy model działalności, oba procesy mogą być prowadzone prawidłowo z perspektywy własnych metodologii, a mimo to opierać się na wzajemnie sprzecznych założeniach.
Jeszcze inna relacja dotyczy procesu oceny adekwatności kapitału wewnętrznego. Czynniki ESG mogą oddziaływać na istniejące rodzaje ryzyka i wpływać na sposób ich oceny w różnych horyzontach czasowych. Jeżeli plan dotyczący ryzyka ESG zakłada określoną zmianę profilu działalności albo wskazuje ryzyka wymagające ograniczania, konsekwencje tych założeń powinny zostać odpowiednio uwzględnione także w ocenie kapitału potrzebnego do pokrywania ryzyka. Z drugiej strony wyniki tej oceny mogą wpływać na realność założeń przyjętych w planie i wymagać ich ponownego zweryfikowania. Do tego dochodzą procesy biznesowe. Ostateczna struktura ekspozycji banku nie zmienia się poprzez aktualizację planu, strategii czy metodologii ryzyka. Zmienia się dlatego, że w procesach kredytowych, inwestycyjnych i produktowych podejmowane są konkretne decyzje. Jeżeli określony cel ma rzeczywiście wpływać na profil ryzyka banku, musi zostać przełożony na sposób podejmowania tych decyzji, w tym odpowiednie kryteria, limity, wymagane informacje albo zasady eskalacji. Bez takiego przełożenia plan może prawidłowo opisywać oczekiwaną zmianę portfela, ale nie będzie posiadał mechanizmu pozwalającego tę zmianę osiągnąć.
Każdy z tych procesów może jednocześnie być zarządzany prawidłowo. Właściciel procesu zarządzania ryzykiem może zapewnić właściwą metodologię. Właściciel procesu strategicznego może doprowadzić do przyjęcia spójnych założeń strategicznych. Planowanie finansowe może korzystać z poprawnych danych, a proces kredytowy z właściwie ustanowionych polityk i limitów. Przekrojowy charakter wymogu ujawnia się dopiero wtedy, gdy trzeba ustalić, czy wszystkie te elementy odnoszą się do tego samego obrazu przyszłej działalności banku i czy zmiana w jednym z nich jest odpowiednio przenoszona do pozostałych. Szczególnego znaczenia nabierają przy tym dane. Procesy mogą formalnie posługiwać się podobnymi pojęciami, a mimo to korzystać z różnych źródeł, zakresów i momentów aktualizacji informacji. Jednostka ryzyka może oceniać ekspozycje według jednego zestawu klasyfikacji, planowanie finansowe według innego, a biznes według jeszcze innego sposobu segmentacji klientów i produktów. Dopóki każdy proces realizuje własny cel, różnice te mogą być uzasadnione. W momencie, w którym jedna regulacja wymaga przełożenia wyniku jednego procesu na działania podejmowane w drugim, różnice metodologiczne zaczynają mieć znaczenie dla zgodności całego wdrożenia.
Problem nie jest przy tym specyficzny dla ESG. Plan dotyczący ryzyka ESG jest dobrym przykładem dlatego, że szczególnie wyraźnie pokazuje zależność pomiędzy procesami mającymi odmienny charakter. W innych wdrożeniach punktem styku mogą być dane klienta, klasyfikacja produktu, informacja o dostawcy technologii, wynik modelu albo określone zdarzenie operacyjne. Za każdym razem logika jest podobna: obowiązek regulacyjny wymaga, aby informacja powstająca w jednym procesie została wykorzystana w innym, choć wcześniej procesy te nie były projektowane z myślą o takim połączeniu. Dlatego przy przekrojowym wdrożeniu nie wystarczy ustalić, które procesy wymagają zmiany. Trzeba również zidentyfikować zależności regulacyjne pomiędzy nimi. Jeżeli jeden proces dostarcza danych drugiemu, trzeba ustalić ich zakres, częstotliwość aktualizacji i odpowiedzialność za jakość. Jeżeli wynik jednego procesu powinien wpływać na decyzje w innym, trzeba określić moment i sposób tego wpływu. Jeżeli dwa procesy wykorzystują wspólne pojęcie regulacyjne, trzeba zapewnić spójność jego rozumienia albo świadomie opisać dopuszczalne różnice. Jeżeli zmiana decyzji w jednym procesie powinna powodować ponowną ocenę w innym, taki mechanizm również musi zostać zaprojektowany.
W tym przykładzie szczególnie dobrze widać także różnicę pomiędzy dokumentem a procesem. Plan może być formalnie kompletny, zawierać wszystkie wymagane elementy i zostać zatwierdzony przez właściwy organ. Jeżeli jednak procesy strategiczne, finansowe, ryzyka i biznesowe nie wykorzystują go jako wspólnego punktu odniesienia, dokument pozostanie przede wszystkim opisem oczekiwanego stanu. Regulacja zostanie wdrożona formalnie, ale niekoniecznie zostanie wbudowana w sposób funkcjonowania banku. Właśnie dlatego przy przekrojowych zmianach najtrudniejsze okazują się często nie same działania wdrożeniowe, lecz zależności pomiędzy nimi.
Najtrudniejsze są zależności, nie zadania
Typowy plan wdrożenia regulacyjnego dobrze radzi sobie z przypisywaniem odpowiedzialności za konkretne działania. Można wskazać, kto ma zmienić politykę, kto przygotować metodologię, kto dostosować system informatyczny, kto opracować nowe raportowanie, a kto ustanowić albo zmienić mechanizm kontrolny. Każde z tych działań może mieć odpowiedzialnego, termin, kryterium zakończenia i status raportowany w ramach projektu. Taki sposób zarządzania jest potrzebny, ponieważ pozwala sprowadzić złożoną zmianę regulacyjną do zestawu prac, których wykonanie można rzeczywiście kontrolować. Znacznie trudniej zarządzać tym, co znajduje się pomiędzy poszczególnymi działaniami. Jeżeli nowa metodologia wykorzystuje dane dostarczane przez inny proces, samo zakończenie prac nad metodologią nie przesądza jeszcze, że dane będą dostępne w wymaganym zakresie i czasie. Jeżeli wynik oceny ryzyka powinien wpływać na planowanie finansowe, zmiana obu procesów nie wystarcza, jeżeli nie został określony sposób przekazywania wyniku pomiędzy nimi. Jeżeli nowy cel ma znajdować odzwierciedlenie w decyzjach biznesowych, nie wystarczy przyjąć go w jednym dokumencie i odrębnie zmienić politykę biznesową. Trzeba zapewnić, że oba elementy pozostają ze sobą powiązane w rzeczywistym przebiegu procesów.
W projekcie wdrożeniowym zależność taka może nie mieć własnego odpowiedzialnego. Jedno zadanie kończy się przekazaniem określonego produktu, a drugie zaczyna od wykorzystania informacji, która powinna z niego wynikać. Każdy z właścicieli może uznać swoją część za wykonaną, mimo że nikt nie sprawdził, czy punkt przekazania został rzeczywiście zaprojektowany. Luka nie powstaje wówczas wewnątrz któregoś z procesów, lecz na ich styku. Jest szczególnie trudna do wykrycia dlatego, że z perspektywy każdego procesu z osobna wszystko może wyglądać prawidłowo. Przekrojowe wdrożenie wymaga więc szerszego spojrzenia na plan działań. Oprócz pytań o to, co należy zmienić i kto za tę zmianę odpowiada, trzeba konsekwentnie ustalać, od czego dane działanie zależy oraz na jakie inne elementy organizacji będzie wpływał jego rezultat. W praktyce oznacza to identyfikowanie nie tylko poszczególnych zadań, lecz również wejść i wyjść procesów, danych przekazywanych pomiędzy nimi, decyzji uruchamiających dalsze działania oraz punktów, w których rozbieżność pomiędzy procesami powinna zostać wykryta i rozstrzygnięta.
W przypadku planów dotyczących ryzyka ESG można to zobaczyć na kilku poziomach jednocześnie. Jeżeli proces zarządzania ryzykiem przyjmuje określony mierzalny cel dotyczący profilu ekspozycji, jego realizacja może zależeć od decyzji podejmowanych w procesach biznesowych. Jeżeli osiągnięcie celu wymaga zmiany struktury portfela, konsekwencje powinny zostać uwzględnione w planowaniu finansowym. Jeżeli zmienia się założony profil działalności, może to wpływać na strategię oraz ocenę adekwatności kapitału wewnętrznego. Każdy z tych procesów otrzymuje więc określone informacje z innych procesów, a jednocześnie sam generuje wyniki, które mogą wymagać ponownej oceny wcześniej przyjętych założeń. Taki układ jest trudniejszy niż zwykłe następstwo czynności. Nie mamy bowiem do czynienia z linią, w której proces A przekazuje wynik do procesu B, a ten następnie do procesu C. W wielu regulacjach przekrojowych zależności mają charakter zwrotny. Wynik procesu zarządzania ryzykiem wpływa na planowanie, ale przyjęty plan finansowy może z kolei pokazać, że określona ścieżka ograniczania ryzyka jest niewykonalna w założonym tempie. Strategia wyznacza kierunek działalności, ale aktualizacja oceny ryzyka może wymagać ponownego zweryfikowania części założeń strategicznych. Dane wykorzystywane w jednym procesie mogą zostać zakwestionowane w innym, a zmiana metodologii może wpływać na decyzje podjęte wcześniej.
Dlatego nie wystarczy zaprojektować samo przekazanie informacji. Trzeba również określić, co powinno wydarzyć się wtedy, gdy informacja przekazana pomiędzy procesami zmienia wcześniejsze założenia albo ujawnia ich niespójność. Jeżeli proces zarządzania ryzykiem wskazuje, że realizacja określonego celu odbiega od planu, trzeba wiedzieć, czy informacja ta wyłącznie pojawi się w raporcie, czy również uruchomi ponowną ocenę założeń strategicznych albo finansowych. Jeżeli plan finansowy wskazuje, że oczekiwana zmiana struktury portfela nie nastąpi, konieczne jest określenie, kto oceni konsekwencje dla planu dotyczącego ryzyka ESG i jakie dalsze działania powinny z tej oceny wynikać. W tym miejscu szczególnego znaczenia nabiera rozróżnienie pomiędzy przekazaniem informacji a rzeczywistym powiązaniem procesów. Pierwsze można zapewnić stosunkowo łatwo poprzez raport, komunikat, funkcjonalność systemową albo obowiązek proceduralny. Drugie wymaga ustalenia, jak wynik jednego procesu wpływa na decyzje podejmowane w drugim oraz kiedy konieczne jest ponowne uruchomienie wcześniejszego etapu. W regulacji przekrojowej właśnie ta warstwa często decyduje o tym, czy bank rzeczywiście wykonuje nowy obowiązek jako całość, czy jedynie wymienia informacje pomiędzy procesami, które nadal funkcjonują według własnej, odrębnej logiki.
Zależności mogą mieć również charakter pojęciowy. Regulacja posługuje się określoną kategorią, którą następnie kilka procesów musi zastosować do własnych potrzeb. Każdy z nich może potrzebować innego poziomu szczegółowości albo innej agregacji danych, ale podstawowe znaczenie regulacyjnego pojęcia powinno pozostać spójne. Jeżeli proces ryzyka, planowanie finansowe i biznes używają tej samej nazwy dla różnych zbiorów ekspozycji, problem może ujawnić się dopiero wtedy, gdy wyniki mają zostać porównane albo wykorzystane w jednym planie. Formalnie wszystkie jednostki mogą raportować ten sam wskaźnik, podczas gdy faktycznie opisują inne zjawiska. Podobny problem dotyczy horyzontów czasowych. Regulacje przekrojowe coraz częściej wymagają spojrzenia jednocześnie w perspektywie krótkiej, średniej i długiej. Poszczególne procesy bankowe nie muszą być jednak projektowane według tych samych cykli. Strategia może być aktualizowana w innym rytmie niż plan finansowy, ocena kapitału wewnętrznego w innym niż bieżące zarządzanie limitami, a dane biznesowe mogą być dostępne z jeszcze inną częstotliwością. Wdrożenie polegające wyłącznie na dodaniu nowego wymogu do każdego z tych procesów nie zapewni ich spójności, jeżeli nie zostanie ustalone, jak odmienne cykle mają ze sobą współpracować.
Z punktu widzenia zarządzania projektem jest to kłopotliwe, ponieważ zależność znacznie trudniej zamknąć niż pojedyncze zadanie. Można potwierdzić przyjęcie polityki, uruchomienie funkcjonalności systemowej albo zatwierdzenie metodologii. Trudniej oznaczyć jako wykonane zapewnienie trwałej spójności danych albo zdolność kilku procesów do reagowania na wzajemne zmiany. Tego rodzaju elementy wymagają nie tylko przygotowania rozwiązania, lecz również sprawdzenia jego działania w konkretnych scenariuszach. Dlatego w przekrojowym wdrożeniu szczególnego znaczenia nabiera testowanie stanu docelowego. Nie powinno ono ograniczać się do sprawdzenia, czy poszczególne rozwiązania zostały wdrożone zgodnie z wymaganiami. Warto przejść przez zdarzenie, które wymaga współdziałania kilku procesów, i sprawdzić, czy informacje faktycznie przepływają pomiędzy nimi, czy uczestnicy rozumieją swoje role, czy wynik jednego procesu powoduje właściwą reakcję w drugim oraz czy ewentualna rozbieżność ma określony sposób rozstrzygnięcia. Takie sprawdzenie może ujawnić problemy, których nie pokaże ani analiza dokumentacji, ani status poszczególnych działań projektowych.
Nie oznacza to konieczności tworzenia odrębnego testu dla każdej możliwej sytuacji. Wystarczające może być wybranie kilku kluczowych scenariuszy pokazujących najbardziej istotne zależności. Celem nie jest ponowne wykonanie całego wdrożenia, lecz potwierdzenie, że połączenia pomiędzy procesami funkcjonują tak, jak zostały zaprojektowane. Wtedy status projektu zaczyna odzwierciedlać nie tylko stopień wykonania prac, lecz również rzeczywistą gotowość organizacji do działania po rozpoczęciu stosowania nowych wymogów. Przy regulacji przekrojowej nie wystarczy bowiem wiedzieć, że każdy element został zbudowany. Trzeba sprawdzić, czy elementy zostały połączone w sposób pozwalający bankowi wykonywać obowiązek jako całość. W tym sensie najtrudniejszym rezultatem takiego wdrożenia nie jest kolejna procedura, metodologia czy zmiana systemowa, lecz trwała spójność zależności pomiędzy procesami, które po zakończeniu projektu mają funkcjonować już bez jego dodatkowej struktury koordynacyjnej.
Zmiana regulacyjna musi zostać osadzona w systemie kontroli wewnętrznej
Jeżeli przekrojowe wdrożenie ma rzeczywiście zakończyć się wbudowaniem nowego wymogu w normalne funkcjonowanie banku, nie może zatrzymać się na zmianie przebiegu procesów i regulacji wewnętrznych. Kolejnym krokiem powinno być ustalenie, jakie znaczenie nowa regulacja ma dla systemu kontroli wewnętrznej. W banku proces nie jest bowiem wyłącznie sekwencją czynności prowadzących do określonego rezultatu. W procesach funkcjonują mechanizmy kontrolne służące zapewnieniu realizacji celów systemu kontroli wewnętrznej, a ich przestrzeganie podlega odpowiedniemu monitorowaniu. Rekomendacja H właśnie w ten sposób łączy architekturę procesową banku z funkcją kontroli oraz matrycą funkcji kontroli. Ma to istotne konsekwencje dla wdrożeń regulacyjnych. Jeżeli nowy wymóg wpływa na proces istotny, nie wystarczy ustalić, że właściciel procesu zmienił jego przebieg albo uzupełnił właściwą regulację wewnętrzną. Trzeba również odpowiedzieć na pytanie, czy dotychczasowe mechanizmy kontrolne nadal są wystarczające, czy pojawiło się nowe ryzyko braku zgodności wymagające dodatkowego zabezpieczenia oraz w jaki sposób będzie można stwierdzić, że przyjęte rozwiązanie rzeczywiście działa. Dopiero na tym poziomie zmiana regulacyjna przestaje być elementem projektu i staje się częścią stałego systemu kontroli banku.
W prostym przypadku przełożenie nowego wymogu na funkcję kontroli może być stosunkowo łatwe. Zmienia się jedna czynność w procesie, ustanawia odpowiedni mechanizm kontrolny, wskazuje osobę odpowiedzialną za jego stosowanie oraz sposób niezależnego monitorowania. W regulacji przekrojowej problem jest bardziej złożony, ponieważ ryzyko nie musi znajdować się wewnątrz jednego procesu. Może wynikać właśnie z niespójności pomiędzy kilkoma procesami, z braku przekazania informacji albo z sytuacji, w której zmiana dokonana w jednym procesie nie uruchamia działania wymaganego w drugim. W takim przypadku mechanizm kontrolny zaprojektowany wyłącznie na poziomie pojedynczego procesu może być prawidłowy, a mimo to nie zabezpieczać najważniejszego ryzyka regulacyjnego. Właściciel procesu może kontrolować kompletność danych otrzymanych na wejściu, prawidłowość wykonywanych czynności i jakość rezultatu. Jeżeli jednak proces otrzymał dane oparte na założeniach niespójnych z innym procesem albo nie został poinformowany o zmianie, która powinna wpłynąć na jego działanie, kontrola wewnątrz procesu może nie wykryć problemu. Z jej perspektywy wszystkie czynności zostały wykonane prawidłowo.
Na przykładzie planów dotyczących ryzyka ESG można wyobrazić sobie sytuację, w której proces zarządzania ryzykiem prawidłowo monitoruje realizację przyjętego celu, proces planowania finansowego prawidłowo kontroluje zgodność wykonania z planem, a proces strategiczny prawidłowo raportuje realizację strategii. Każdy z tych procesów posiada własne mechanizmy kontrolne. Jeżeli jednak wykorzystują one różne założenia dotyczące oczekiwanej zmiany portfela albo zmiana przyjęta w jednym z nich nie powoduje odpowiedniej aktualizacji pozostałych, problem może pozostać niewidoczny dla mechanizmów kontrolnych funkcjonujących oddzielnie w każdym procesie. To oznacza, że przy regulacjach przekrojowych przedmiotem kontroli powinny stać się także punkty styku pomiędzy procesami. Nie musi to zawsze oznaczać ustanawiania odrębnego mechanizmu kontrolnego dla każdej zależności. Czasem wystarczające będzie rozszerzenie istniejącego mechanizmu o sprawdzenie zgodności z informacją pochodzącą z innego procesu, ustanowienie obowiązku uzgodnienia określonych założeń albo wprowadzenie kontroli uruchamianej wtedy, gdy jeden z procesów zmienia parametr mający znaczenie dla pozostałych. Ważne jest natomiast, aby ryzyko wynikające z zależności zostało świadomie zidentyfikowane i nie pozostawało poza zakresem kontroli tylko dlatego, że nie mieści się w granicach jednego procesu.
W tym miejscu matryca funkcji kontroli może pełnić rolę znacznie ważniejszą niż dokument odzwierciedlający istniejące mechanizmy kontrolne. Przy odpowiednim wykorzystaniu pozwala sprawdzić, czy nowy wymóg regulacyjny został rzeczywiście osadzony w systemie kontroli wewnętrznej. Jeżeli zmiana wpływa na proces uznany przez bank za istotny oraz prowadzi do zmiany kluczowych mechanizmów kontrolnych lub sposobu ich niezależnego monitorowania, powinna znaleźć odpowiednie odzwierciedlenie również w matrycy funkcji kontroli. W takim przypadku można prześledzić, jakie cele systemu kontroli wewnętrznej są z nią związane, jakie mechanizmy mają zapewniać ich realizację, kto odpowiada za ich stosowanie, a następnie w jaki sposób przestrzeganie tych mechanizmów jest niezależnie monitorowane. W regulacji przekrojowej trzeba do tego dodać pytanie, czy mechanizmy te obejmują również kluczowe zależności pomiędzy procesami. Takie podejście pozwala uniknąć sytuacji, w której projekt wdrożeniowy tworzy własny, tymczasowy system kontroli. W czasie projektu postęp jest zwykle monitorowany bardzo dokładnie. Odbywają się regularne spotkania, istnieje centralna lista działań, zależności są omawiane na forum projektowym, a problemy trafiają do osób posiadających mandat do ich rozstrzygnięcia. Paradoksalnie właśnie po formalnym zakończeniu projektu część tych zabezpieczeń może zniknąć. Jeżeli nie zostały przeniesione do stałych procesów, mechanizmów kontrolnych i zasad ich monitorowania, organizacja traci elementy, które podczas wdrożenia kompensowały niedoskonałości modelu docelowego.
Dlatego jednym z najważniejszych pytań przed zamknięciem przekrojowego wdrożenia powinno być to, co zastąpi strukturę projektu następnego dnia po jego zakończeniu. Trzeba wiedzieć, kto będzie zarządzał zależnościami pomiędzy procesami, jeżeli zmienią się dane, metodologia albo założenia, który mechanizm kontrolny ma wykryć, że jeden proces przestał działać zgodnie z założeniami przyjętymi przez drugi oraz w jaki sposób informacja o takiej rozbieżności trafi do właściwych właścicieli procesów. Jeżeli odpowiedzią nadal pozostaje osoba kierująca zakończonym projektem albo robocze forum utworzone wyłącznie na czas wdrożenia, stan docelowy nie został jeszcze w pełni zaprojektowany. Osadzenie zmiany w systemie kontroli wewnętrznej ma również znaczenie dla odpowiedzialności poszczególnych linii obrony. Na wszystkich trzech poziomach systemu zarządzania ryzykiem i systemu kontroli wewnętrznej pracownicy, odpowiednio do przypisanych im zadań, stosują mechanizmy kontrolne albo niezależnie monitorują ich przestrzeganie. W pierwszej linii funkcjonuje również monitorowanie poziome, natomiast druga linia wykonuje m.in. monitorowanie pionowe przestrzegania mechanizmów kontrolnych stosowanych w pierwszej linii. Projekt regulacyjny nie powinien prowadzić do sytuacji, w której funkcja zgodności po zakończeniu wdrożenia pozostaje operacyjnym łącznikiem pomiędzy procesami tylko dlatego, że zależności tych nie przeniesiono do docelowego modelu działania.
Odrębną rolę zachowuje audyt wewnętrzny, którego zadaniem jest niezależne badanie adekwatności i skuteczności systemu zarządzania ryzykiem i systemu kontroli wewnętrznej w całej działalności banku, a nie bieżąca koordynacja wdrożenia regulacyjnego.
Szczególnie istotne jest tutaj odróżnienie kontroli wykonania wdrożenia od kontroli wykonywania regulacji po wdrożeniu. Pierwsza odpowiada na pytanie, czy wykonano zaplanowane działania i czy bank osiągnął założony stan docelowy. Druga powinna funkcjonować już w normalnej architekturze systemu kontroli wewnętrznej i odpowiadać na pytanie, czy obowiązek jest rzeczywiście realizowany w działalności banku. Zakończenie pierwszej bez ustanowienia drugiej pozostawia regulację zależną od pamięci osób uczestniczących w projekcie zamiast od trwałych mechanizmów organizacyjnych. W ten sposób matryca funkcji kontroli może stać się jednym z punktów, w których sprawdzana jest trwałość wdrożenia. Jeżeli nowa regulacja została przeanalizowana prawnie, zadania projektowe wykonano, procesy zmieniono, ale nie można wskazać, jakie mechanizmy mają zapewniać dalszą realizację obowiązku oraz jak ich działanie będzie monitorowane, projekt zatrzymał się przed ostatnim etapem. Bank posiada rozwiązanie wdrożeniowe, ale nie w pełni włączył zmianę do swojego systemu kontroli wewnętrznej.
Kto odpowiada za spójność zmiany przekrojowej?
Przekrojowe wdrożenie regulacyjne nie podważa zasady właścicielstwa procesów. Przeciwnie, bez niej trudno byłoby zbudować trwały stan docelowy. Jeżeli nowy wymóg wpływa na proces kredytowy, planowanie finansowe, zarządzanie ryzykiem czy proces strategiczny, każdy z tych procesów powinien zostać dostosowany przez osoby odpowiedzialne za jego funkcjonowanie. Właściciele procesów pozostają więc odpowiedzialni za zmiany dotyczące ich procesów zarówno podczas projektu, jak i po jego zakończeniu. Problem polega na tym, że żaden z nich nie ma naturalnie pełnej odpowiedzialności za rezultat powstający dopiero ze współdziałania kilku procesów. Nie rozwiązuje tego także wskazanie jednostki, która odpowiada za interpretację regulacji. Funkcja prawna może zapewnić spójne rozumienie nowych przepisów, wskazać zakres obowiązku i oceniać prawne aspekty przyjmowanych rozwiązań. Funkcja zgodności może z kolei identyfikować i oceniać ryzyko braku zgodności oraz wykonywać pozostałe zadania przewidziane w systemie kontroli wewnętrznej. Żadna z tych funkcji nie powinna jednak tylko z tego powodu przejmować odpowiedzialności za zmianę procesów należących do pierwszej linii ani stawać się trwałym pośrednikiem pomiędzy ich właścicielami.
W praktyce trzeba więc rozdzielić co najmniej trzy rodzaje odpowiedzialności. Pierwsza dotyczy spójnego rozumienia wymogu regulacyjnego. Druga obejmuje dostosowanie poszczególnych procesów i pozostaje przy ich właścicielach. Trzecia odnosi się do spójności zmiany pomiędzy procesami. To właśnie ta ostatnia odpowiedzialność jest najtrudniejsza do umiejscowienia, ponieważ jej przedmiotem nie jest konkretny proces, lecz zależności pomiędzy kilkoma procesami. Odpowiedzialności za spójność zmiany nie należy jednak rozumieć jako ustanowienia nowego właściciela stojącego ponad właścicielami procesów. Taka osoba nie powinna przejmować ich kompetencji ani zatwierdzać wszystkich rozwiązań procesowych. Potrzebny jest raczej mechanizm zapewniający, że decyzje podejmowane przez poszczególnych właścicieli pozostają zgodne z jednym modelem wdrożenia, a zależności, których nie można rozwiązać wewnątrz jednego procesu, zostały rozpoznane i świadomie ukształtowane. W przypadku rozbieżności musi również istnieć możliwość doprowadzenia do ich rozstrzygnięcia na poziomie posiadającym odpowiedni mandat.
W zależności od skali i znaczenia regulacji funkcję tę może pełnić osoba kierująca wdrożeniem, wyznaczony sponsor zmiany albo odpowiednie forum skupiające właścicieli procesów i funkcje uczestniczące w zmianie. Forma ma mniejsze znaczenie niż zakres wykonywanych zadań. Jeżeli forum ogranicza się do zbierania informacji o statusie poszczególnych działań, nadal mamy jedynie mechanizm zarządzania projektem. Jeżeli natomiast identyfikuje i ocenia zależności pomiędzy procesami, rozstrzyga rozbieżności dotyczące wspólnych założeń, wskazuje brakujące punkty styku i sprawdza kompletność stanu docelowego, zaczyna rzeczywiście odpowiadać na przekrojowy charakter zmiany. Taki mechanizm jest potrzebny szczególnie tam, gdzie właściciele procesów podejmują decyzje prawidłowe z perspektywy własnych obszarów, ale trudne do pogodzenia na poziomie całego banku. Proces zarządzania ryzykiem może potrzebować danych o określonej szczegółowości i częstotliwości, podczas gdy planowanie finansowe zostało zaprojektowane według innego cyklu. Właściciel jednego procesu może oczekiwać automatycznego przekazywania informacji, podczas gdy drugi uznaje, że ich przygotowanie wymaga dodatkowej oceny. Każde z tych stanowisk może być uzasadnione. Przekrojowe wdrożenie wymaga jednak podjęcia decyzji, jak oba procesy mają ze sobą współpracować.
Odpowiedzialność za spójność zmiany powinna obejmować również identyfikowanie sytuacji, w których regulacja wymaga wspólnego rozstrzygnięcia kilku właścicieli procesów, a nie jedynie przekazania informacji pomiędzy nimi. Nie każdą zależność można bowiem rozwiązać poprzez procedurę określającą wejście i wyjście z procesu. Czasem trzeba uzgodnić jedną metodologię, wspólną klasyfikację albo sposób postępowania, który następnie będzie wykorzystywany w kilku procesach. W takich przypadkach brak wskazania sposobu podejmowania wspólnej decyzji może prowadzić do utrzymywania równoległych rozwiązań, z których każde jest poprawne lokalnie, ale niespójne z pozostałymi. Ten sam problem nie znika po zakończeniu wdrożenia. Jeżeli po kilku miesiącach jeden proces zmieni metodologię, dane wykorzystywane przez drugi przestaną być wystarczające albo realizacja określonego celu zacznie odbiegać od założeń wspólnych dla kilku procesów, bank powinien wiedzieć, kto uruchamia ponowną ocenę zależności. Nie jest wystarczające założenie, że każdy właściciel procesu sam zauważy wpływ własnej zmiany na wszystkie pozostałe procesy. W dojrzałej organizacji model docelowy powinien określać także sposób zarządzania zmianami wtórnymi, które powstaną już po zakończeniu właściwego projektu regulacyjnego.
Właśnie dlatego szczególnie ważny jest moment przekazania odpowiedzialności ze struktury projektowej do stałego modelu zarządzania. Podczas wdrożenia osoba kierująca projektem może zapewniać przepływ informacji, organizować uzgodnienia i eskalować problemy. Po zakończeniu projektu taka rola może zniknąć. Jeżeli jednak regulacja tworzy trwałe zależności pomiędzy procesami, trzeba z góry ustalić, kto będzie nimi zarządzał później. Czasem wystarczające będzie wpisanie odpowiednich obowiązków do odpowiedzialności istniejących właścicieli procesów i wskazanie mechanizmu wzajemnego uzgadniania zmian. W innych przypadkach potrzebne może być istniejące albo właściwie umocowane stałe forum zarządcze. Nie powinno się natomiast utrzymywać sztucznej struktury tylko dlatego, że była użyteczna w czasie wdrożenia. Wynika to również z odpowiedzialności zarządu za zaprojektowanie, wprowadzenie i zapewnienie działania systemu zarządzania ryzykiem i systemu kontroli wewnętrznej. Zarząd nie powinien oczywiście rozstrzygać każdej zależności pomiędzy procesami ani przejmować roli właścicieli procesów. Powinien jednak zapewnić model, w którym wiadomo, jak zarządza się zmianami przekrojowymi, w jaki sposób rozstrzygane są spory pomiędzy właścicielami oraz na jaki poziom trafiają kwestie, których nie można rozwiązać w istniejącej strukturze odpowiedzialności. Brak takiego modelu sprawia, że najbardziej złożone zależności są rozwiązywane doraźnie, zwykle dopiero wtedy, gdy zaczynają utrudniać działanie konkretnego procesu.
Nie oznacza to również, że każda regulacja wymaga ustanowienia odrębnego mechanizmu zarządzania przekrojowego. Jeżeli zmiana dotyczy jednego procesu albo zależności pomiędzy procesami są już obsługiwane przez istniejący model zarządzania, tworzenie dodatkowej struktury byłoby niepotrzebne. Kluczowe jest wcześniejsze rozpoznanie charakteru zmiany. Dopiero jeżeli analiza pokaże, że realizacja jednego wymogu zależy od trwałego współdziałania kilku procesów, pojawia się potrzeba świadomego zaprojektowania odpowiedzialności za tę współzależność. Pytanie o „właściciela wdrożenia” okazuje się więc zbyt uproszczone. Przy zmianie przekrojowej nie chodzi o znalezienie jednej osoby, która przejmie odpowiedzialność za wszystko. Chodzi o takie rozłożenie odpowiedzialności, aby właściciele zachowali odpowiedzialność za swoje procesy, funkcje prawna i zgodności wykonywały właściwe im zadania, a jednocześnie istniał mechanizm zapewniający spójność tam, gdzie regulacja przecina granice kilku procesów. Dopiero wtedy model wdrożeniowy odpowiada rzeczywistemu sposobowi funkcjonowania dużego banku.
Zakończenie. Wdrożenie kończy się wtedy, gdy projekt przestaje być potrzebny
Duże wdrożenia regulacyjne zwykle zaczynają się od przepisu, ale ich powodzenie zależy ostatecznie od sposobu funkcjonowania organizacji. Ustawodawca może określić obowiązek banku, termin jego wykonania i oczekiwany rezultat. Nie określi jednak, w którym procesie banku ma powstać potrzebna informacja, który właściciel procesu powinien ją wykorzystać, w jaki sposób rezultat jednego procesu ma wpłynąć na drugi ani jaki mechanizm kontrolny powinien wykryć niespójność pomiędzy nimi. To właśnie translacja jednego obowiązku prawnego na architekturę dużej instytucji stanowi właściwą treść wdrożenia. Nie oznacza to, że problemem jest sama złożoność banku. Podział na jednostki organizacyjne, procesy i właścicieli procesów jest warunkiem zarządzania instytucją prowadzącą różnorodną działalność, podlegającą jednocześnie wielu reżimom regulacyjnym. Właścicielstwo procesów pozwala przy tym przejść ponad granicami struktury organizacyjnej i przypisać odpowiedzialność za rezultat działań wykonywanych w kilku jednostkach. Trudność pojawia się dopiero wtedy, gdy nowy obowiązek przekracza nie tylko granice jednostek organizacyjnych, lecz również granice kilku istniejących procesów.
W takim przypadku podzielenie wymogów pomiędzy właścicieli procesów jest konieczne, ale nie wystarcza. Każdy właściciel może prawidłowo wykonać swoją część zmiany, a bank nadal może nie osiągnąć rezultatu wymaganego przez regulację. Powodem nie musi być niewłaściwe zaprojektowanie któregokolwiek procesu. Źródłem problemu może być brak spójności ich założeń, niedziałający przepływ informacji, różne definicje lub horyzonty czasowe, brak reakcji jednego procesu na zmianę w drugim albo niewskazanie sposobu rozstrzygnięcia rozbieżności pomiędzy właścicielami. Dlatego przy wdrożeniu przekrojowym analiza wpływu regulacji powinna obejmować nie tylko listę procesów wymagających zmiany, lecz także mapę zależności pomiędzy nimi. Trzeba ustalić, jakie informacje przepływają pomiędzy procesami, gdzie powstają, kto odpowiada za ich jakość, jakie decyzje mają uruchamiać, które założenia muszą być wspólne oraz jakie zmiany powinny powodować ponowną ocenę wcześniejszych rozstrzygnięć. Dopiero wtedy można zobaczyć obowiązek regulacyjny nie jako zbiór zadań przydzielonych kilku właścicielom, lecz jako mechanizm, który po zakończeniu projektu ma działać w całym banku.
Przykład planów dotyczących ryzyka ESG w CRD VI dobrze ilustruje tę różnicę. Sam plan może mieć naturalne miejsce w obszarze zarządzania ryzykiem i posiadać jasno określoną odpowiedzialność procesową. Jeżeli jednak zawarte w nim cele i założenia mają rzeczywiście kształtować profil ryzyka banku w różnych horyzontach czasowych, muszą oddziaływać na strategię, planowanie finansowe, ocenę adekwatności kapitału wewnętrznego i procesy biznesowe wpływające na strukturę ekspozycji. Wdrożenie nie kończy się więc w momencie zatwierdzenia planu. Kończy się wtedy, gdy procesy, które mają go realizować, zostały dostosowane, ich zależności zostały zaprojektowane, a organizacja potrafi reagować również na późniejsze zmiany założeń. Podobnie należy patrzeć na rolę projektu regulacyjnego. Projekt jest potrzebny do przeprowadzenia zmiany, ponieważ zapewnia czasową strukturę koordynacji ponad istniejącymi granicami organizacyjnymi i procesowymi. Pozwala zebrać właścicieli procesów, uzgodnić interpretację regulacji, wskazać zależności, monitorować wykonanie działań i eskalować problemy. Jego sukcesu nie powinno się jednak mierzyć wyłącznie liczbą zamkniętych zadań. Najważniejszym rezultatem projektu powinien być stan, w którym mechanizmy zapewniające zgodność mogą dalej funkcjonować bez dodatkowej struktury powołanej na potrzeby wdrożenia.
Z tego powodu szczególnie ważny jest sposób zamykania projektu. Jeżeli po jego zakończeniu nadal potrzebna jest osoba, która ręcznie łączy kilka procesów, przypomina o przekazywaniu informacji, uzgadnia rozbieżności albo pilnuje wykonania obowiązku, warto zadać pytanie, czy rzeczywiście osiągnięto stan docelowy. Tymczasowe mechanizmy koordynacyjne mogą być niezbędne podczas wdrożenia, ale nie powinny maskować braku trwałego rozwiązania w architekturze procesowej banku. Ta sama perspektywa powinna zostać przełożona na system kontroli wewnętrznej. Nowy obowiązek nie jest trwale wdrożony tylko dlatego, że opisano go w procedurze i przypisano do odpowiedniego procesu. Trzeba jeszcze ustalić, jakie mechanizmy kontrolne zapewniają jego prawidłowe wykonywanie i w jaki sposób ich przestrzeganie będzie monitorowane. Przy regulacjach przekrojowych szczególnego znaczenia nabierają przy tym punkty styku pomiędzy procesami, ponieważ właśnie tam może powstawać ryzyko niewidoczne dla mechanizmów kontrolnych badających każdy proces osobno.
Nie chodzi przy tym o tworzenie dla każdej nowej regulacji dodatkowej warstwy zarządzania ani nowego trwałego komitetu. Dojrzała organizacja powinna raczej umieć rozpoznać, czy istniejące procesy i mechanizmy zarządcze są w stanie objąć nową zależność. Jeżeli tak, zmiana powinna zostać w nie włączona. Jeżeli nie, potrzebne jest uzupełnienie architektury w miejscu, w którym pojawiła się luka. Regulacja przekrojowa nie powinna prowadzić do budowania równoległego modelu funkcjonującego obok właściwej działalności instytucji. Właśnie dlatego nie ma jednej funkcji, której można przypisać odpowiedzialność za każde przekrojowe wdrożenie. Funkcja prawna może zapewniać spójność interpretacji przepisów, funkcja zgodności wykonywać właściwe jej zadania dotyczące ryzyka braku zgodności, a właściciele procesów odpowiadać za dostosowanie i późniejsze działanie swoich procesów. Równocześnie potrzebny jest mechanizm zapewniający spójność zmiany tam, gdzie jej wykonanie zależy od kilku właścicieli. Jego forma może być różna w zależności od charakteru regulacji i architektury konkretnego banku, ale odpowiedzialność za tę spójność nie może pozostać jedynie domyślnym rezultatem współpracy zainteresowanych jednostek.
W tym sensie przekrojowe wdrożenie regulacyjne jest przede wszystkim testem dojrzałości zarządzania bankiem. Stosunkowo łatwo jest zidentyfikować nowy przepis, przygotować analizę luk i podzielić działania pomiędzy jednostki. Znacznie trudniej sprawić, aby po wykonaniu wszystkich tych działań bank funkcjonował jako jedna organizacja, a nie jako zbiór prawidłowo dostosowanych procesów, pomiędzy którymi pozostają niezaprojektowane zależności. Dlatego o powodzeniu dużego wdrożenia nie przesądza liczba wykonanych zadań ani nawet kompletność zmienionych procedur. Decyduje o nim to, czy nowy obowiązek został przełożony na trwały sposób działania procesów, ich właścicieli, mechanizmów kontrolnych oraz zależności pomiędzy nimi. Projekt można zamknąć wtedy, gdy wszystkie zaplanowane prace zostały wykonane. Regulacja jest jednak naprawdę wdrożona dopiero wtedy, gdy bank potrafi ją wykonywać bez projektu.