Z Jaromirem Pelczarskim, wiceprezesem banku BNP Paribas odpowiedzialnym za operacje i wsparcie, rozmawiamy o podejściu zarządów do projektów informatycznych, ocenie efektywności wydawanych na IT funduszy, aktualnej roli IT, relacjach IT-biznes, różnym podejściu do prowadzenia projektów.
Nadzoruje Pan pion IT w banku. W jaki sposób podejmuje się obecnie decyzję o rozpoczęciu projektu informatycznego?
Po pierwsze, chciałbym podkreślić, że według mnie nie ma dziś czegoś takiego, jak projekt IT. Nie podejmujemy już decyzji o projektach IT. Pojawiają się nowe potrzeby bądź pomysły i za tym idą konieczne inwestycje. W BNP Paribas decyzje o projektach – uwzględniających IT – podejmuje komitet ds. inwestycji – Investment Committee. Jego spotkania odbywają się generalnie raz w miesiącu.
Oczywiście informatyka – podobnie jak każda inna dziedzina biznesu – jest obecna samodzielnie, ale od kilku lat nie podejmujemy decyzji o projektach polegających np. na wymianie macierzy tylko ze względu na nowszą ich generację. Choć są oczywiście projekty, w których lwią część kosztów pochłania infrastruktura. Ostatnio przeprowadzaliśmy fuzję spółki zależnej zajmującej się leasingiem. Za tym szły też zmiany w IT, ale ostateczne decyzje podejmowały piony biznesowe. Teraz rozpoczynamy fuzję z Bankiem Gospodarki Żywnościowej.
Obecnie nie jest nam potrzebny nowy zestaw routerów, macierzy czy serwerów tylko w celu posiadania nowej technologii. Mamy konkretny projekt do zrealizowania, w którym jedne rozwiązania pozwalają osiągnąć coś szybciej, a inne wolniej. Nawet jeśli to IT inicjuje jakiś projekt – np. wymiany systemu Identity Management – to musi zademonstrować korzyści płynące dla całej organizacji, dla rozwoju biznesu np. ludzi z działu Private Banking.
————————————————————————————————————————————-
————————————————————————————————————————————-
Czy w ten sam sposób – korzyści dla biznesu – ocenia się zrealizowane projekty?
Wdrożyliśmy podstawy tzw. Benefit Management. Śledzimy efekty zatwierdzonych przez Investment Committee projektów. Oceniamy ich efekty końcowe. To bardzo pomaga w podejmowaniu kolejnych decyzji. Niekiedy dużo więcej można się bowiem nauczyć, analizując to, co się nie udało. Dlatego tak duży nacisk kładziemy na kontrolę realizowanych i zrealizowanych projektów oraz wyciąganie z nich wniosków na przyszłość. Oceniamy np. przyrost klientów czy wzrost salda w określonym czasie. Wydaje mi się, że obecnie zwrot z inwestycji jest szerszym pojęciem niż prosty cash flow.
Nie zgodzę się z tym, że jedna osoba – CIO, CMO czy CFO – będzie zarządzała budżetem np. na IT. Bo to oznacza, że wie, jak takie decyzje podjąć. Czy CFO powinien mieć kompetencje, które pozwalają mu pomóc podjąć decyzję o wdrożeniu nowego systemu IT? Nie. Potrzebuje wiedzy od osób zajmujących się danym obszarem. Dlatego właśnie w BNP Paribas mamy Investment Committee do prowadzenia takich dyskusji. Wspólnie na tych spotkaniach decydujemy o podjęciu ryzyka związanego z rozpoczęciem jakiegoś projektu, ustaleniu jego kamieni milowych i kontrolowaniu – osiąganych na poszczególnych etapach – efektów.
Jak długo trwa follow-up projektu?
Od 6 do 9 miesięcy po zakończeniu projektu. De facto nie ma już projektów, gdzie break-even point osiągany jest dłużej niż po 18 miesiącach. Czasy się zmieniły, zmieniło się też myślenie o projektach. Coraz częściej stosuje się także zwinną metodologię prowadzenia projektów – agile. W kontekście Benefit Management też chcemy oceniać efekty cząstkowe prowadzonych projektów, na poszczególnych ich etapach.
Obecnie projekty muszą więc być krótkie i w krótkim czasie osiągać zwrot z inwestycji?
Projekt, który trwa dłużej niż 9 miesięcy, to projekt wysokiego ryzyka. Takich rzeczy staramy się unikać. Nawet jeśli jest to gruntowna reorganizacja czy wymiana systemu, który jest głęboko zaszyty w DNA firmy – tych projektów nie da się zamknąć w 9 miesięcy – musimy ustalić punkty kontrolne, które pozwolą nam zmierzyć efekty dotychczasowych prac. Stąd zapewne tak duża popularność agile. Choć kolegom z działu IT mówię, że to nie nowa, wprowadzona 2 lata temu koncepcja, lecz formuła znana nam lokalnie praktycznie od roku 2004. Ponadto agile humanizuje koncepcję związaną z zarządzaniem, pozwala na postrzeganie rzeczywistości w sposób bardziej złożony.
Banki konkurują poprzez kreatywność i szybkość wprowadzania nowych produktów. Bankowość bardziej przypomina dziś obszar FMCG, gdzie na rynek trzeba bardzo szybko wprowadzać nowy towar, który w krótkim czasie przestaje nadawać się do „spożycia”. Nowoczesne narzędzia IT potrafią zaś ułatwić wprowadzenie na rynek nowego produktu szybciej niż konkurencja. Tymczasem, jeśli nie będziemy tego potrafili zrobić, będziemy naśladowcą ,a nie innowatorem.
Nie oznacza to, że z założenia rezygnujemy z przedsięwzięć, które trwają dłużej. Projektem, który nie „mieścił się” w zakładanych 9 miesiącach, była np. zakończona sukcesem modernizacja głównego systemu transakcyjnego w naszym banku – EQUATION. Można to porównać do wymiany silnika w samochodzie. Musieliśmy być pewni, że inne elementy infrastruktury wytrzymają. W takim kontekście zaplanowaliśmy proces testowania, który musiał wykazać, że wszystkie podzespoły funkcjonują z odpowiednią dynamiką. Pochodną takiej złożoności i wielowymiarowości był jednak czas trwania procesu wprowadzenia zmiany – rzadko krótszy niż 12 miesięcy.
Zdecydowaliśmy się jednak na ten projekt, ponieważ było kilka ważnych powodów do przebudowy systemu EQUATION. Nie ma dobrego momentu na wymianę systemu centralnego, a im jest on starszy, tym przecież bardziej „wygrzany”. Nasza wersja miała już ponad 10 lat. W IT to dwie epoki. Jednocześnie osoby, które tworzą wizję rozwoju banku, planując zmiany, napotkały barierę wynikającą z ograniczeń systemu transakcyjnego. Chcieliśmy wyeliminować te ograniczenia. Drugi powód to łatwość rozwoju nowych produktów. Dużo nowych funkcji zostało wprowadzonych do najnowszej wersji.
Projekty, jak powyższy przykład, są jednak traktowane z dużą rezerwą. Zawsze pojawiają się pytania, co to nam da? Do czego potrzebna jest nam nowa platforma? Zanim rozpoczęliśmy wdrożenie nowej wersji EQUATION, obszary komercyjne banku musiały się wypowiedzieć na temat tego projektu, musiały go zaakceptować. Pion IT mógł bowiem usłyszeć z obszaru biznesu – nie jest nam potrzebny nowy system i oferowana przez niego nadmiarowa moc, bo to, co mamy, pozwala nam prowadzić biznes na oczekiwanym poziomie.
W bankowości dużo łatwiej jest jednak umotywować taką zmianę. Banki konkurują bowiem poprzez kreatywność i szybkość wprowadzania nowych produktów. Bankowość bardziej przypomina dziś obszar FMCG, gdzie na rynek trzeba bardzo szybko wprowadzać nowy towar, który w krótkim czasie przestaje nadawać się do „spożycia”. Nowoczesne narzędzia IT potrafią zaś ułatwić wprowadzenie na rynek nowego produktu szybciej niż konkurencja. Tymczasem, jeśli nie będziemy tego potrafili zrobić, będziemy jedynie naśladowcą, a nie innowatorem.
Kto więc inicjuje projekty w największym stopniu angażujące IT? Z analiz niektórych firm wynika, że dysponentami środków na IT są, czy też wkrótce zostaną, CMO lub CFO…
Nie ma projektów IT, więc de facto nie ma też budżetu IT, którym ktoś mógłby dysponować. Choć oczywiście w każdym roku musi być zaplanowany budżet na inwestycje i utrzymanie systemów IT. Mamy też budżet na rozwój oddziałów, ale to obszar handlowy decyduje, gdzie stworzyć nowy oddział, a nie dział odpowiedzialny za inwestycje budowlane. Aby dokonać tego wyboru, bada się dane geomarketingowe, analizuje procesy migracyjne w miastach. Może się okazać, że dzielnica atrakcyjna jeszcze 5, 10, 15 lat temu nie jest już teraz tak dobrym miejscem na otwarcie oddziału. Następnie decyduje się o wynajmie, zakupie lub budowie nowej placówki.
Nie jest nam już potrzebny nowy zestaw routerów, macierzy czy serwerów tylko w celu posiadania nowej technologii. Mamy konkretny projekt do zrealizowania, w którym jedne rozwiązania pozwalają osiągnąć coś szybciej, a inne wolniej. Nawet jeśli to IT inicjuje jakiś projekt – np. wymiany systemu Identity Management – to musi zademonstrować korzyści płynące dla całej organizacji, dla rozwoju biznesu np. ludzi z działu Private Banking.
Podobnie z projektami IT. Dopiero w 2 lub 3 iteracji zastanawiamy się nad budżetem na IT związanym np. z wyposażeniem nowego oddziału w niezbędny sprzęt, czy na zatrudnienie nowych pracowników. To jednak nie poszczególne działy zarządzają tym budżetem. Jego wielkość jest konsekwencją tego, co aktualnie robi bank. Nie zgodzę się więc z tym, że to jedna osoba – CIO, CMO czy CFO – będzie zarządzała budżetem np. na IT. Bo to oznacza, że wie, jak takie decyzje podjąć. Czy CFO powinien mieć kompetencje, które pozwalają mu pomóc podjąć decyzję o wdrożeniu nowego systemu IT? Nie. Potrzebuje wiedzy od osób zajmujących się danym obszarem. Dlatego właśnie w BNP Paribas mamy Investment Committee do prowadzenia takich dyskusji. Wspólnie na tych spotkaniach decydujemy o podjęciu ryzyka związanego z rozpoczęciem jakiegoś projektu, ustaleniu jego kamieni milowych i kontrolowaniu – osiąganych na poszczególnych etapach – efektów.
Jaka jest zatem dziś rola działu IT?
Rolą IT jest sprawianie, aby rzeczy działy się szybciej, łatwiej i bardziej efektywnie kosztowo.
Wspomina Pan, że CFO potrzebuje wiedzy osób zajmujących się danym obszarem. Tymczasem często mówi się, że biznesowi trudno jest się porozumieć z IT? Kto jest, kto powinien być mediatorem w tego typu ewentualnych konfliktach?
Problem jest taki, że IT może nie wie lepiej, ale uważa, że z pewnością wie więcej. Obszar komercyjny zaś uważa, że wie lepiej, bo jest „bliżej klienta”. Tak ujęte relacje między IT a sprzedażą i marketingiem to pytanie o to, kto jest mądrzejszy. Przy takiej polaryzacji stanowisk trudno jest stworzyć jakiś pomost. Wyznaczenie osoby do mediacji oznaczałoby wpuszczenie jej na pole minowe będące linią demarkacyjną IT-biznes. Tymczasem pomiędzy tymi stronami powinna zostać zachowana otwarta komunikacja o potrzebach klienta, która zapewni równowagę, jak w chińskim yin-yang. Czas łączników zresztą odszedł. Zniknęli w ramach optymalizacji etatów…
Osobiście staram się w organizacji wprowadzać model ciągłej dyskusji i wymiany informacji. Choć byłbym hipokrytą, gdybym powiedział, że prowadzi to do spokojnego dialogu. Wierzę jednak w potencjał „kreacyjny” konfliktu, o ile jest to konflikt idei, a nie konflikt personalny. Dobrze zarządzany konflikt sprawia, że produkty powstają w nowej, lepszej formule, a potem są rozwijane. Podejście Kaizen – dążenia do ustawicznego poprawiania procesu zarządzania i produkcji na wszystkich szczeblach – ma największą szansę na sukces. Pochodną tego jest to, że mamy większy poziom akceptacji niedoskonałości.
Wdrożyliśmy podstawy tzw. Benefit Management. Śledzimy efekty zatwierdzonych przez Investment Committee projektów. Oceniamy ich efekty końcowe. To bardzo pomaga w podejmowaniu kolejnych decyzji. Niekiedy dużo więcej można się bowiem nauczyć, analizując to, co się nie udało. Dlatego tak duży nacisk kładziemy na kontrolę realizowanych i zrealizowanych projektów oraz wyciąganie z nich wniosków na przyszłość.
Jak zaczyna się nowy projekt? Czy biznes mówi, co chce, a IT pyta, jak to ma wyglądać?
To efekt wspomnianej dyskusji. W BNP Paribas w pewnym momencie wymagany jest jednak szczegółowy opis projektu. Jest to konieczne m.in. z powodu różnej percepcji projektu ze strony różnych działów. W projektach typu waterfall tworzono skomplikowany opis, następnie budowano i testowano rozwiązanie. Na końcu zaś często okazywało się, że coś nie działa. Wówczas zrzucano winę na siebie nawzajem – wy coś źle zrobiliście, ale tylko dlatego, że wy to wcześniej źle opisaliście. Tymczasem ja wierzę w proces ciągłego udoskonalana Kaizen.
Czy wpisuje się w to zastosowanie metodyk zwinnych, bo efekt można uzyskać szybciej, a na każdym etapie można coś zmienić, ulepszyć? Czy korzystają Państwo z tego typu metod?
W kilku obszarach stosujemy agile. Jestem od lat sympatykiem zwinnych metod prowadzenia projektów. Choć nie uważam, że jest to remedium na każdą, trudną sytuację w banku. Nie wszystko bowiem da się w ten sposób zrobić. Metodologię tę można np. wykorzystać do zarządzania dostawcami ze wszystkich stron świata, a mamy ich zarówno w Polsce, jak i w Dubaju, Rosji i na Filipinach. Agile wykorzystujemy także do tworzenia szybko zmieniających się interfejsów, takich jak front-end klienta. Szybkie zmiany wymusza fakt proponowania klientom kolejnych produktów. Agile jest idealny do takiego „product placement”. Wystawiamy nowy produkt, analizujemy, dodajemy szybko to, czego brakuje. Z drugiej strony agile można porównać do ronda w ruchliwym miejscu miasta. Mamy do zrealizowania 30 sprintów, ale w końcu ktoś musi na rondo wjechać pierwszy. Trzeba szybko zadecydować, kto ma pierwszeństwo, i mieć świadomość podjętej decyzji.
Jakich projektów nie należy więc realizować w modelu agile?
Są to projekty, które mają wielowymiarową strukturę, np. wspomniane wdrożenie nowej wersji głównego systemu transakcyjnego. W naszym przypadku trwał ok. 14 miesięcy. Realizowany wg metodologii agile byłby znacznie droższym, dłuższym i narażonym na większe ryzyko. Według mnie, podobnie trudne i ryzykowne byłoby np. stworzenie zwinnymi metodami prowadzenia projektów nowego modelu samolotu. Tego typu projekt musi być przeprowadzony metodą waterfall z określonymi w czasie kamieniami milowymi. Choć pewne elementy można wykonać wg agile, to jednak ktoś musi składać to w całość.
Staram się w organizacji wprowadzać model ciągłej dyskusji i wymiany informacji. Choć byłbym hipokrytą, gdybym powiedział, że prowadzi to do spokojnego dialogu. Wierzę jednak w potencjał „kreacyjny” konfliktu, o ile jest to konflikt idei, a nie konflikt personalny. Dobrze zarządzany konflikt sprawia, że produkty powstają w nowej, lepszej formule, a potem są rozwijane. Podejście Kaizen – dążenia do ustawicznego poprawiania procesu zarządzania i produkcji – ma największą szansę na sukces. Pochodną tego jest to, że mamy większy poziom akceptacji niedoskonałości.
Kto powinien wskazywać najlepszą strukturę projektu?
Wracając do bankowości, myślę, że tę rolę winni pełnić architekci rozwiązań. Wysłuchanie osoby odpowiadającej za spójne działanie całego ekosystemu IT upraszcza wiele decyzji. Wskazuje ona bowiem na potencjalne ryzyka inwestycji. Mówi np., że na obecnym etapie rozwoju systemu IT w przedsiębiorstwie nie ma sensu wchodzić w dany projekt, w takim podejściu. Architekt otwarcie powinien również mówić o tym, co określony projekt oznacza dla klienta banku, w danym czasie. Żadna z rzeczy, które robimy, nie powinna być robiona dla klienta wewnętrznego, dla osób z banku. Mamy tylko jednego klienta – zewnętrznego, i to on – dzięki naszym staraniom – ma chcieć kupić nasz produkt.
Bardzo mi się spodobało stwierdzenie: “Żadna z rzeczy, które robimy, nie powinna być robiona dla klienta wewnętrznego, dla osób z banku. Mamy tylko jednego klienta – zewnętrznego, i to on – dzięki naszym staraniom – ma chcieć kupić nasz produkt.”. To jest dojrzałe podejście, którego brakuje w wielu, nawet bardzo zaawansowanych organizacjach. Tymczasem zrozumienie, jak ważne jest holistyczne podejście do prowadzonego biznesu pozwala sobie uzmysłowić, że klient i interesariusz projektu nie zawsze oznacza to samo. Jeżeli jesteśmy siecią lodziarni, to produkujemy lody i sprzedajemy je naszym klientom, a w projekcie wprowadzającym system analityczny pozwalający ocenić ryzyko otwarcia nowej lodziarni w określonej lokalizacji klientem projektu jest osoba, która będzie kupowała od nas lody, a nie dyrektor handlowy i jego zespół. W tym przykładzie wszyscy jesteśmy odpowiedzialni za sprzedaż lodów, a uzasadnienie projektowe mówi o optymalizacji kosztów i zwiększeniu sprzedaży, a nie o satysfakcji i wygodzie zespołu zarządzającego siecią dystrybucji.