Narzędzia GRC: „z pudełka” czy „szyte na miarę”?

Jakie wyzwania czekają firmy decydujące się na tworzenie własnego oprogramowania i dlaczego gotowe, sprawdzone systemy, takie jak AdaptiveGRC, zazwyczaj okazują się bardziej efektywnym i przewidywalnym wyborem? Zapraszamy do historii AutoMech Systems. Historii, podkreślmy, fikcyjnej – choć, z naszego doświadczenia, nieoderwanej od rzeczywistości. Historii, w której wszelkie podobieństwo do prawdziwych postaci i zdarzeń jest czysto przypadkowe… co wcale nie oznacza, że nigdy nie zaistniały.

Umiesz liczyć, licz na siebie

AutoMech Systems to dynamicznie rozwijająca się firma zajmująca się produkcją i dystrybucją części dla przemysłu motoryzacyjnego i maszynowego. Założyciel, pan Marian, budował swoją firmę od podstaw, bazując na zasadzie, którą zawsze powtarza: „Umiesz liczyć, licz na siebie.” Dzięki temu podejściu firma od lat skutecznie konkurowała na rynku.

Jednak nowe wyzwania biznesowe, związane z rosnącą presją logistyki just-in-time, zapewnieniem wysokiej jakości oraz wymaganiami regulacyjnymi i audytowymi, sprawiły, że zarząd AutoMech Systems zaczął rozważać wdrożenie systemu do zarządzania ryzykiem i zgodnością (GRC). Na stole pojawiły się dwa scenariusze: zakup gotowego, sprawdzonego rozwiązania w modelu SaaS lub budowa własnego systemu: wewnętrznie bądź z pomocą software house’u.

Na jednym ze spotkań pojawiła się propozycja: „Nie kupujemy gotowego systemu, zbudujemy własny! Będzie tańszy i dostosowany do naszych potrzeb.” Pan Marian przytaknął, szef IT przekonywał, że to proste zadanie, a dyrektor operacyjny widział w tym ryzyko, ale nie chciał podważać decyzji. Wydawało się, że jest to logiczny wybór, ale czy na pewno?

System GRC: czego tak naprawdę nam potrzeba?

Prace nad systemem ruszyły pełną parą. Szef IT, Tomek, zlecił pierwsze analizy i projektowanie architektury rozwiązania. Wstępne projekty narzędzia wyglądały obiecująco, ale już na pierwszych spotkaniach pojawiły się pytania:

– Kto zdecyduje, jakie funkcje są kluczowe?

– Które funkcje wdrożymy, a które nie, bo nie na wszystkie starczy czasu?

– Czy system ma wspierać kompleksowo audyt oraz zarządzanie ryzykiem i zgodnością?

– Jak będzie wyglądała jego przyszła rozbudowa?

– Jak dokładnie ma wyglądać proces, w którym chcemy pracować w narzędziu? Część zadań systemu GRC wykonywane były dotąd na papierze, część w Excelu i mailowo.

– Duża część zadań i procesów, które miały dziać się w systemie GRC w ogóle dotąd w firmie nie istniały. Firma będzie musiała je wypracować od zera i od razu wdrożyć do narzędzia, a potem, ucząc się na własnych błędach, dopasowywać narzędzie

– Czy może jednak firma powinna wdrożyć w narzędziu procesy, które są sprawdzone na rynku i rekomendowane przez szanowane organizacje branżowe, które zbierają doświadczenia (i błędy) setek i tysięcy firm z rynku, dzięki czemu AutoMech Systems uniknie popełniania tych samych błędów?

– Kto w firmie powinien odpowiadać, za wypracowanie tych procesów, lub też i pozyskanie ich z rynku? Pozyskanie procesów z rynku opóźni wypracowanie własnego narzędzia.

– Czy można skutecznie wdrożyć procesy, których się dotąd nie stosowało w organizacji w ogóle, lub stosowało w uproszczony sposób do narzędzia, które tworzy się od zera, nie mając doświadczenia z zastosowania tych procesów w praktyce?

– Jak uniknąć sytuacji, w której, zderzając się z taką ilością nowych czynników, stworzymy narzędzie, które de facto źle wdrożyło nowe procesy i zadania i tak naprawdę powinno zostać napisane po raz drugi od zera, wdrażając nauki z pierwszej porażki?

– Jakie jest ryzyko takiej sytuacji i jaki będzie koszt biznesowy stworzenia narzędzia drugi raz oraz koszt biznesowy z trzech lat opóźnień wynikających z takiego cyklu?

Każdy dział miał inne oczekiwania. Audytorzy potrzebowali automatycznych raportów (ale co tak naprawdę miało się znaleźć w tych raportach?), compliance chciało integracji z nowymi regulacjami (ale z którego źródła?), a zarząd – intuicyjnych dashboardów, żeby mieć ogląd sytuacji (ale w oparciu o jakie dane?)  Brak jasnej strategii i nadzoru nad rozwojem spowodował, że projekt zaczął dryfować.

!  Po kilku miesiącach zespół IT zdał sobie sprawę, że zamiast jednego spójnego systemu, próbują budować trzy różne aplikacje. Każdy dział chciał czegoś innego, a koszty rosły. Coraz trudniej było pogodzić wymagania w jednym narzędziu, a rozbicie na trzy różne narzędzia spowodowało, że zarząd stracił możliwość kontroli i szerokiej perspektywy na całą spółkę z jednego miejsca i jednego źródła danych. Jakby tego było mało, pojawiały się wciąż nowe oczekiwania i potrzeby, jakie miało zaspokajać nowe narzędzie. Pierwotne założenia stawały się coraz bardziej nieaktualne i nie było nikogo, kto utrzymałby projekt w ryzach.

Błędy, których można było uniknąć

Po ponad 6 miesiącach prac pierwsza wersja systemu była gotowa do testów. Dział audytu szybko zauważył, że niektóre funkcje nie działają tak, jak powinny. Raporty generowały błędy, a użytkownicy skarżyli się na zbyt skomplikowaną nawigację. Dane z poszczególnych działów zostały rozczłonkowane i system, który miał dać firmie spójną wizję całej organizacji pod kątem GRC w jednym miejscu, stał się kolejnym silosem informacyjnym.

Tomek uspokajał: „To normalne, zawsze trzeba coś poprawić, przecież to dopiero pierwsza wersja, teraz użytkownicy będą ją testować, dacie nam uwagi, a my poprawimy….”

Zespół IT AutoMech Systems właśnie przechodził przez etap, który dostawcy gotowych systemów rozwiązali lata temu. Sprawdzone mechanizmy raportowania i UX dostosowany do potrzeb użytkowników? W AutoMech Systems wszystko trzeba było budować i testować od zera, co pochłaniało czas i zasoby.

Silną stroną gotowych rozwiązań jest fakt, że narzędzie jest na żywo testowane nie przez jedną organizację i jej pracowników, ale przez setki czy tysiące organizacji i ich pracowników. Stąd dużo szybciej ujawniają się błędy systemowe, dużo częściej zgłaszane są sugestie poprawek procesów, funkcji i interface’u narzędzia. Dzięki temu każdy kolejny klient dostaje znacznie bardziej dopracowane narzędzie niż jego pierwszy użytkownik. Procesy zaszyte w narzędziu są procesami dopracowanymi i sprawdzonymi przez setki organizacji, z różnych branż i wielkości, różnych kontekstów regulacyjnych.

!  Kolejne miesiące upływały na poprawkach, ale lista błędów zamiast maleć, rosła. Zespół (nieliczny i wciąż pochłonięty tak zwaną bieżączką)  zamiast rozwijać system, spędzał czas na naprawianiu podstawowych funkcji. Każda rozwiązany problem i odpowiedź na pytanie generowały kolejne pytania.

A, właśnie! Bezpieczeństwo

Kolejnym ciosem dla projektu był raport z audytu bezpieczeństwa informacyjnego nowego systemu, który trafił na biurka zarządu AutoMech Systems. Specjaliści ds. cyberbezpieczeństwa wskazali na poważne luki w zabezpieczeniach. Za audyt AutoMech Systems musiał oczywiście, a jakże, zapłacić zewnętrznej, specjalistycznej firmie.

„Brakuje szyfrowania danych, system nie chroni przed nieautoryzowanym dostępem. Co, jeśli ktoś wykradnie wrażliwe informacje?” – pytał jeden z audytorów. System nie spełnia standardów ISO itp wymaganych bądź sugerowanych przez organizacje branżowe czy regulatorów.

Dojrzałe systemy GRC, takie jak AdaptiveGRC, zostały wielokrotnie zweryfikowane przez największe banki i firmy farmaceutyczne, podlegające pod najbardziej wymagające regulacje instytucji nadzorczych. System AutoMech Systems dopiero musiał przejść te testy – i niestety ich nie zdał.

! Firma stanęła przed wyborem: albo opóźnić wdrożenie i zainwestować w poprawki bezpieczeństwa i ponowny audyt , albo uruchomić system z ryzykiem naruszenia danych. Oba scenariusze oznaczały dodatkowe koszty i ryzyka.

Pytania o przyszłość systemu

Rok po rozpoczęciu prac system GRC w końcu działał – przynajmniej częściowo. W końcu nadszedł moment, w którym ktoś musiał pójść do prezesa Mariana i wyjawić mu niewygodną prawdę: Dotychczasowe koszty projektu przekroczyły kilkakrotnie początkowo zakładany budżet jak i wcześniejsze oferty dostawców gotowych rozwiązań. A to jeszcze nie koniec kosztów. System musiał być przecież utrzymywany i rozwijany na przykład w sytuacji zmian regulacyjnych.

– Czy AutoMech Systems ma zasoby, żeby utrzymywać i rozwijać ten system przez kolejne lata?

Zbudowanie systemu to jedno. Utrzymanie go w dłuższej perspektywie to zupełnie inne wyzwanie. System AutoMech Systems wymagał ciągłych nakładów pracy – a nikt nie był pewien, czy firma za kilka lat nadal będzie w stanie w niego inwestować. Tymczasem gotowe rozwiązania, takie jak AdaptiveGRC, zapewnia stałe aktualizacje i rozwój zgodny z nowymi regulacjami.

! Pojawiło się ryzyko, że system przestanie być rozwijany, a firma zostanie z nieaktualnym i niedostosowanym narzędziem.

Miało być taniej…

Jednym z kluczowych argumentów za budową własnego systemu GRC w AutoMech Systems była oszczędność. Tylko że po dwóch latach koszty były znacznie wyższe niż zakładano. Jak to możliwe?

• Ze względu na niedoszacowanie skomplikowania systemu, wdrażanie nieznanych dotąd norm i dobrych praktyk i digitalizowanie procesów, system był kilkakrotnie zmieniany, co wygenerowało wysokie koszty dodatkowe
• Wzrosły koszty wynagrodzenia specjalistów IT, których utrzymanie było droższe niż zakup gotowego systemu.
• Serwery, infrastruktura i utrzymanie pochłaniały więcej zasobów niż przewidziano.
• Każda nowa funkcjonalność wymagała kolejnych nakładów finansowych.
• To z kolei wygenerowało ogromny dług technologiczny.

W AutoMech Systems koszty wymknęły się spod kontroli. Gdyby firma postawiła na AdaptiveGRC, mogłaby przewidzieć wszystkie wydatki z kilkuletnim wyprzedzeniem.

! Po dwóch latach okazało się, że całkowity koszt TCO – czyli łączny koszt posiadania i utrzymania systemu, uwzględniający nie tylko jego stworzenie, ale także rozwój, infrastrukturę, bezpieczeństwo i zasoby ludzkie – przewyższył koszt gotowego rozwiązania. To, co początkowo miało być tańszą opcją, stało się obciążeniem finansowym, które stale rosło.

Tanie skalowanie systemu? Nie w AutoMech Systems

Początkowo system miał obsługiwać tylko audyt. Ale szybko okazało się, że firma potrzebuje także modułu do zarządzania ryzykiem. Tylko że… dodanie nowej funkcji wymagało kolejnej dużej inwestycji. Nowi specjaliści, nowe analizy, nowe testy.

Dla AutoMech Systems każda zmiana oznaczała miesiące pracy i nieprzewidziane wydatki. Korzystając z gotowego rozwiązania AdaptiveGRC, firma po prostu dodałaby do istniejącego systemu gotowe moduły.

! Rozwój systemu okazał się znacznie droższy, bardziej pracochłonny i skomplikowany, niż zakładano.

Miało być szybko, ale…

W teorii budowa własnego systemu miała trwać sześć miesięcy. W praktyce – po dwóch latach w szytym na miarę rozwiązaniu AutoMech Systems nadal brakowało pełnej funkcjonalności.

Gdyby firma zdecydowała się na AdaptiveGRC, system byłby w pełni wdrożony po około dwóch miesiącach. A jego pierwsze moduły już po kilku tygodniach.

! Firma straciła cenny czas, a system nadal nie spełniał wszystkich wymagań, jakie przed nim postawiono.

Czego nas uczy historia AutoMech Systems?

Decyzja o budowie własnego systemu GRC wydawała się dla firmy racjonalna – miała zapewnić większą kontrolę, oszczędności i dostosowanie do unikalnych potrzeb firmy. Jednak rzeczywistość szybko zweryfikowała te założenia.

W trakcie projektu okazało się, że:

• Brak jasnej strategii rozwoju sprawił, że system zaczął rozchodzić się w różnych kierunkach, a potrzeby poszczególnych działów nie były spójne.
• Zespół IT musiał rozwiązywać problemy, z którymi dostawcy gotowych rozwiązań mierzyli się lata temu – i które już dawno wyeliminowali.
• Poważne luki w zabezpieczeniach wymusiły dodatkowe inwestycje i audyty, które znacząco opóźniły wdrożenie.
• Utrzymanie i rozwój systemu stały się kolejnym wyzwaniem – nikt nie był pewien, czy za kilka lat firma nadal będzie miała na to zasoby.
• Koszty wymknęły się spod kontroli – w praktyce okazało się, że zamiast oszczędności, budowa własnego rozwiązania pochłonęła więcej pieniędzy, niż kosztowałoby wdrożenie AdaptiveGRC.
• System nie był elastyczny – każda nowa funkcja wymagała ponownych inwestycji, rekrutacji specjalistów i długotrwałych procesów wdrożeniowych.
• Wdrożenie zajęło znacznie więcej czasu, niż zakładano – gotowe rozwiązanie mogło działać w ciągu kilku tygodni, podczas gdy własne oprogramowanie było rozwijane latami.

Ostatecznie zarząd AutoMech Systems stanął przed trudnym wyborem:

1. Inwestować dalej w rozwój własnego systemu, narażając się na kolejne koszty i niepewność?
2. Przejść na gotowe rozwiązanie, które mogło być wdrożone szybciej i taniej już dwa lata wcześniej?

To pytanie, które zadaje sobie wiele firm. W teorii budowa własnego systemu może wydawać się korzystna, ale w praktyce oznacza ogromne ryzyko, nieprzewidziane koszty i opóźnienia. AdaptiveGRC pozwala tego uniknąć, dając przewidywalność, bezpieczeństwo i sprawdzoną skuteczność.

Czy warto uczyć się na własnych błędach – czy może lepiej skorzystać z doświadczenia tych, którzy już je popełnili, a potem wyciągnęli z nich wnioski?

AdaptiveGRC – gotowe rozwiązanie, które rośnie razem z organizacją

Decyzja o budowie własnego systemu może wydawać się rozsądna – w końcu technologia wydaje się dostępna, a proces pod kontrolą. Jednak w przypadku systemów takich jak GRC, samo stworzenie oprogramowania to zaledwie 20% całego wyzwania.

Prawdziwą wartością jest wiedza – skumulowane doświadczenie z dziesiątek, a nawet setek organizacji, które mierzyły się z podobnymi wyzwaniami. AdaptiveGRC nie tylko oferuje szybkie wdrożenie gotowego rozwiązania, ale przede wszystkim bazuje na wieloletnim know-how zgromadzonym w różnych branżach, skalach działania i kontekstach regulacyjnych. To efekt ciągłego rozwoju prowadzonego wspólnie z praktykami GRC, którzy każdego dnia przesyłają swoje potrzeby, uwagi i pomysły na rozwój produktu.

Ale nasze narzędzie to nie tylko zestaw gotowych funkcjonalności. To także platforma, która daje pełną możliwość dostosowania i rozbudowy – zarówno w warstwie procesowej, jak i technologicznej. W przeciwieństwie do wielu narzędzi klasy enterprise, które oferują szybki start, ale są ograniczone w zakresie customizacji, system ten daje użytkownikom realną elastyczność: możliwość dokładnego odwzorowania specyfiki organizacji, rozwoju funkcji, integracji z istniejącym ekosystemem narzędzi czy rozbudowy o nowe obszary wraz ze wzrostem skali działalności.

To podejście sprawia, że AdaptiveGRC jest wybierane nie tylko jako system „na start”, ale również jako rozwiązanie, które może ewoluować razem z organizacją przez wiele lat. I właśnie to – połączenie gotowości z elastycznością – stanowi fundament jego wartości.

Gotowe? Tak.
Sztywne i ograniczone? Zdecydowanie nie.