Serwis korzysta z plików cookies.
        LOGOWANIE  /  REJESTRACJA      

Projektowy Everest

Wywiad z Andrzejem Łachem i Michałem Kopytem, menedżerami odpowiedzialnymi za program Everest -  transformację procesów i architektury IT w PZU SA

27 wrzesień 2015 roku

Bardzo Panom dziękuję za możliwość dzisiejszego spotkania. Porozmawiajmy o programie „Everest”, za który odpowiadacie. Czy moglibyście go na początku pokrótce scharakteryzować: Określić jego zakres, budżet, harmonogram, wykorzystywane zasoby?

Andrzej Łach: Podstawowym celem Everest jest transformacja modelu działania w każdym wymiarze: procesowym, produktowym, także ludzkim, połączona oczywiście ze zmianą IT, czyli wdrożeniem systemu polisowego dla ubezpieczeń majątkowych.  

W 2011 roku jako organizacja zrozumieliśmy (z punktu widzenia biznesowego – produktów, sprzedaży, obsługi jak i back-office), że po kilku latach realizowania szeregu intensywnych projektów „doszliśmy do ściany” i w tym momencie dalsze zmiany oparte na architekturze systemowej, którą wtedy mieliśmy, przynoszą coraz mniejszą wartość za coraz większe koszty – inwestowanie w nią straciło sens. Stwierdziliśmy, że aby się „otrząsnąć” z ograniczeń niemrawego molocha i zamienić w gracza dużego ale zwinnego, potrzebujemy zasadniczej transformacji.

Po pierwsze - kwestia klientocentryczności, czyli poradzenia sobie z tym, że nasza informacja o kliencie była rozproszona i niskiej jakości, procesy sprzedażowo-obsługowe bywały dziurawe a nasz główny kanał sprzedaży – agenci – działał off-line, bez aktualnej wiedzy o tym co się dzieje ze sprawami klienta.

Odbijało się to na jakości sprzedaży oraz obsługi klienta. Zdarzały się bowiem sytuacje, że nasz agent nie wiedział podstawowych rzeczy o sprawach klienta – np. czy zmienił on adres, czy sprzedał samochód –  jeżeli klient sam nie pojawił się a agenta i o tym nie powiedział. Agent nierzadko musiał wyjaśniać na infolinii źle policzone zniżki bonus-malus klienta, a my nie byliśmy w stanie automatycznie przygotować oferty, gdy klient miał ubezpieczenie pakietowe samochodu z OC i Autocasco – tym też musiał się zająć agent.

Po drugie – aspekt wielokanałowości, którą staraliśmy się rozwijać. Dla klienta nie powinna mieć znaczenia kwestia, czy pójdzie do agenta, czy do oddziału, których jest kilkaset w Polsce, czy zadzwoni na infolinię albo wyśle maila– to przecież jedno PZU. Tymczasem nasze procesy były na tyle fragmentaryczne, że każdy z kanałów kontaktu widział tylko część klienckiej układanki i dowiadywał się o wielu zdarzeniach z wielodniowym opóźnieniem.

Po trzecie - byliśmy organizacją, która, jeżeli chodzi o elastyczność zmian w ofercie  produktowej, często goniła rynek, i to z zadyszką. Nasz czas time to market dla średniej wielkości zmian produktowych był liczony nie w tygodniach, ani miesiącach, ale w kwartałach. W produktach masowych staraliśmy się mieć po roku trzy czwarte tego, co konkurencja wprowadziła wcześniej. Inwestowaliśmy dużo wysiłku, aby mieć akceptowalnej jakości dane analityczne do monitoringu produktów czy budowania taryfikacji – trzeba je było łączyć z różnych niespójnych źródeł, usuwać duble i uzupełniać luki w danych. Pewnego rodzaju informacji, dostępnej w biznesie direct, w ogóle nie mieliśmy – np. danych o różnych wersjach ofert dla klienta, czy o ofertach które nie zamieniły się w polisy.

Po czwarte - pomimo przeprowadzonych centralizacji, ciągle jeszcze mieliśmy pracochłonne procesy back-office i przez to byliśmy mało efektywni. Funkcjonowaliśmy jako organizacja, w której setki osób zajmowały się zatykaniem dziur procesowych, kontrolowaniem i archiwizacją milionów stron dokumentów czy przepisywaniem danych pomiędzy systemami. Automatyzacja nawet podstawowych procesów – takich jak płatności i prowizje – była ograniczona. Przez ułomności systemów klient mógł mieć w tym samym momencie niedopłatę za OC i nadpłatę za Autocasco dla jednego pojazdu ubezpieczonego na jednej polisie, a agent mógł mieć wstrzymaną wypłatę prowizji za wiele polis, jeśli jego wpłata różniła się chociaż o 1 grosz.

Efekt był taki, że z perspektywy procesowo-systemowej ponosiliśmy koszty jak za Mercedesa, a rzeczywistość była bliższa kilkunastoletniej Dacii. 

No dobrze, mamy genezę…

Michał Kopyt: Tylko jeszcze może podsumujmy, bo – jak mówiłeś – mieliśmy cztery główne cele, które nadal realizujemy.

AŁ: Klientocentryczność, związana z nią wielokanałowość, elastyczność produktowa oraz efektywność – procesowa, a także kosztowa, w zakresie nie tylko procesowym, ale i w obszarze kosztów IT.

MK: Tylko z tą efektywnością kosztową w IT łączyło się nie tylko to, że mamy być tańsi, ale również to, że potencjalny rozwój narzędzi i procesów, które wdrożymy, ma być mniej kosztowny, ale i bardziej rynkowy. Mieliśmy być otwarci na szeroko rozumiany digital, czyli wchodzenie w kanały elektroniczne i wspieranie naszych agentów tymi kanałami, i generalnie potrzebowaliśmy back office’u połączonego z nowym front officem, który będzie lepiej wspierał w tej części technologicznej działania procesowe, ponieważ byliśmy bardzo rozczłonkowani: mieliśmy dosyć stary, dwudziestoparoletni system korowy, obudowany różnymi systemikami i procesami. Chcieliśmy z tego zrobić jedną nową działającą maszynkę, i taką nam się udało znaleźć na rynku w momencie, kiedy zaczynaliśmy projekt.

AŁ: Jak to się zaczęło? Najpierw zrobiliśmy kilkumiesięczne ćwiczenie koncepcyjne od strony biznesowej, wspólnie z architekturą IT – aby określić co chcemy konkretnie osiągnąć, mając na początek dość wysokopoziomowe cele. To nie był poziom ogólnikowych haseł na kilku slajdach, ale dwieście-trzysta slajdów, które pokazywały konkretne zmiany procesowo-produktowe i architektoniczne, które zamieszaliśmy zrealizować. To ćwiczenie zdefiniowało nasze ambicje poprzez opis docelowego modelu operacyjnego ubezpieczeń majątkowych.

MK: Rzeczywiście, rzetelne stworzenie docelowego modelu operacyjnego było bardzo istotne – ustawiło ramy programu. Gdybyśmy mieli komuś coś polecać przy rozpoczynaniu tego typu programu – kilkusetosobowego, wieloletniego – to jest rzeczywiście uzgodnienie się wewnętrzne i przemyślenie przez te kilka miesięcy, w tym z poziomu zarządu, tego, co my mamy w najbliższych trzech – czterech latach wdrożyć. I te cele potem już projekt i interesariusze dekomponują na  mniejsze działania. Dla nas to, że zaczęliśmy z rozsądnie przemyślanym modelem i że z niego wynikało dalsze działanie, było bardzo ważne i  do tej pory procentuje.

Jakie właściwie były oczekiwania sponsora projektu? Na ile one były skonkretyzowane na samym początku?

MK: Moim zdaniem były na tyle konkretne, że zespół projektowy, który częściowo stworzyliśmy, a częściowo wzięliśmy z istniejącej organizacji, od samego początku, od momentu, kiedy go ułożyliśmy właśnie w tym docelowym modelu operacyjnym, wiedział, w którą stronę mamy podążać. Wiedzieliśmy, jaka jest wola naszego sponsorshipu, czyli tak naprawdę Andrzeja Klesyka i osób z zarządu, które odpowiadały za projekt, i mieliśmy na tyle dobrą komunikację i wsparcie z ich strony w tym pierwszym etapie projektu, że do tej pory nam to mocno procentuje. Nie wyobrażam sobie rozpoczęcia programu bez tak silnego wsparcia na początku i określenia tych czterech głównych celów.

AŁ: W praktyce nasz poziom konkretu był poziomem opisu docelowego modelu operacyjnego, przy opracowaniu którego, jak to często w firmach przy takich okazjach bywa, pomagali konsultanci. Przy czym konsultanci pełnili rolę bardziej akuszerów pomysłów, które wcześniej dość długo dojrzewały w głowach menedżerów PZU. Dzięki temu w sposób ustrukturyzowany - spójny i pełny – zebraliśmy dużo pomysłów od middle- i top-managementu organizacji, zderzyliśmy z najlepszymi praktykami z Polski i zagranicznymi, oraz zdefiniowaliśmy dopasowany do naszych potrzeb model operacyjny. Pozwoliło to unikać ewentualnych niespójności np. gdyby dwa obszary biznesowe promowały wzajemnie sprzeczne pomysły.

Spróbujmy osadzić to jakoś w czasie.

AŁ: Druga połowa 2011 roku – to było opracowanie docelowego modelu operacyjnego. Od tego momentu zaczął się cały formalny proces przetargowy, który zakończył się podpisaniem kontraktu w czerwcu 2012 r. Można powiedzieć, że proces przygotowania oraz przetargowy trwał rok - od trzeciego kwartału 2011 do drugiego kwartału 2012 r.

MK: Przy czym ważne jest to, że po określeniu modelu my dobieraliśmy rozwiązania już pod kątem tego, co chcemy robić, i bardzo mocno patrzyliśmy na systemy i na to, co ze sobą przynoszą dostawcy tych systemów, czyli firmy wdrażające dla nas. To znaczy na ile to, co będziemy sobie kupowali i jak „zsetapujemy” program, pasuje do PZU 2.0. Mocno zastanawialiśmy się nad tym, co chcemy oceniać, co jest dla nas najważniejsze, i mając te priorytety, mając cele, dostosowaliśmy się do takiego, a nie innego modelu pracy. Stąd na przykład wziął się agile w PZU, który bardzo nam pomaga w tym, żeby dowieźć ten program, stąd się wzięło duże zaangażowanie członków zarządu, którzy wiedzieli, że od początku i kupują, i setupują to, co za dwa – trzy lata będą chcieli żeby było wdrożone. Uważam, że bardzo ważne jest, by sposób prowadzenia przetargów był profesjonalny, przemyślany i dostosowany do  oczekiwanego sposobu pracy i celów projektu, to równie ważne jak późniejsze zarządzanie operacyjne.

AŁ: Od samego początku było wiadomo, że Everest to maraton, a nie sprint -  że to nie jest inicjatywa krótko- czy nawet średnio-, tylko długoterminowa. Everest oczywiście ma skutki uboczne także w krótkim czy średnim terminie. Wiadomo - każdy z nas, managerów, patrzy na wynik kwartału czy roku, dbając o premię swoją oraz swoich ludzi - więc ma naturalny odruch skupiania się na sprawach przynoszących rezultaty tu i teraz.  Wdrażając transformację Everest trzeba było natomiast włożyć dużo wysiłku i fokusu w coś, co zaprocentuje za dwa, może za trzy lata. Bardzo ważne było to, co podkreślił Michał - że praktycznie od samego początku w ten projekt zaangażował się prawie cały Zarząd, począwszy od prezesa Andrzeja Klesyka, przez Członków Zarządu odpowiedzialnych za sprzedaż, produkty, front-office, back-office, finanse, likwidację szkód oraz oczywiście IT.

MK: Całe PZU S.A. tak naprawdę, , głównie dlatego że rzeczywiście mieliśmy mocne burning platform. To, co sobie mówiliśmy,  time to market, „klient 360”, to wszystko były czynniki, które nam blokowały rozwój biznesu.. Powiedzieliśmy sobie, jako firma, że jeśli nie zrobimy odcięcia w tym miejscu, nie przeskoczymy trzy kroki do przodu i nie będziemy działali na równi z konkurencją lub jej nie prześcigniemy, to polegniemy za dwa, trzy lata. I musimy to zrobić. Niektórzy mówili, że przy naszej skali przeprowadzenie tego w tym czasie, który sobie założyliśmy, jest niemożliwe, inni – że to szalone, a okazało się, że jeżeli jest mocne przekonanie w biznesie, że on tego potrzebuje, w szczególności na początku projektu, to można góry przenosić.

AŁ: Myślę, że warto się też podzielić pewnymi spostrzeżeniami odnośnie samego procesu wyboru rozwiązania IT. Jak już wiedzieliśmy co chcemy osiągnąć, mając określony model operacyjny na średnim poziomie szczegółu, weszliśmy w proces ofertowy. Nie chcieliśmy przy tym wpaść w pułapkę, w której oceniamy rzeczywistość tylko i wyłącznie na podstawie setek stron dokumentów, załączników i zestawień, w oderwaniu od samych rozwiązań IT i firm które je oferowały. Bardzo dużo poświęciliśmy czasu (zaczynając w fazie, gdy było jeszcze kilku konkurentów) na to, żeby poznać oferowane rozwiązania oraz dostawców – ich podejście, kulturę, zdolności realizacyjne – poprzez warsztaty, prezentacje, wizyty referencyjne. Później zawęziliśmy proces do dwóch dostawców, którzy byli na krótkiej liście, trzymając trzeciego dostawcę on-hold, na wypadek gdyby jeden z głównych oferentów zrezygnował. Weszliśmy w kilkunastotygodniowy proces, w którym dużo zainwestowaliśmy w bardziej szczegółowe poznanie systemów i procesów wspieranych przez nie, równocześnie pomagając dostawcom znacznie lepiej zrozumieć specyfikę PZU. Było to o tyle fajne, że zobaczenie co jest dostępne na rynku pomogło nam zachować pragmatyzm i dostosować oczekiwania do realnie dostępnych ofert.

MK: My w trakcie tego procesu poznawania dostawców i słuchania ich klientów (fizycznie wybraliśmy się do kilku z nich żeby zebrać feedback) zmienialiśmy to, o czym mówił też Andrzej – staraliśmy się zebrać trochę praktyk rynkowych, nie tylko z Polski, i dostosować nasze wymagania na przetarg, sposób prowadzenia przetargu i projektu nie do tego PZU sprzed lat, tylko do tego, jak to dzisiaj powinno wyglądać, żeby  dowieźć projekt. To bardzo ważne, żelazna zasada ‘inspect and adapt’ która jest podstawą Agile, przyświecała nam już wówczas.

Metoda realizacji projektu, jak na podmiot taki jak PZU, wydaje się dość innowacyjna. Co miało wpływ na wybór podejścia agile’owego w tym projekcie, czy też – jak pan Michał go określa – programie? Faktycznie, zastanawiam się, czy „Everest” nie jest programem.

MK: My tak to traktujemy. To jest program z wieloma projektami, które się zmieniają się w czasie ale stanowią nierozerwalną całość.

Trzymajmy się zatem tego, że „Everest” jest programem. Dlaczego agile?

AŁ: Dodam, że to również była kwestia wyboru. Zainwestowaliśmy – co jest rzadkością, a w naszym procesie było to kluczowe – w to, żeby dostawcy pokazali nam rozwiązania nie tak, jak zwykle przychodzą i je marketingowo sprzedają, tylko aby pokazali elementy dostosowane do nas. Poprosiliśmy aby zrobili zmiany na przykładzie naszych rzeczywistych produktów i procesów - oni w pierwszym odruchu powiedzieli: „Hola, hola! Takich rzeczy w normalnym procesie sprzedażowym nie robimy - oczekujecie za dużo: zbyt duży wysiłek i koszt”. Podjęliśmy więc decyzję, że część tego dodatkowego kosztu dostawców pokryjemy – oczywiście przy zachowaniu warunku, że ten kto wygra, odliczy zwrot swoich kosztów od oferty cenowej.

To był bardzo ważny element naszego podejścia – wejście na poziom realizacyjny pomogło nam zrozumieć możliwości i ograniczenia narzędzia, oraz poznać silne i słabe strony współpracy z dostawcami. Można powiedzieć, że były to pierwsze przebłyski agile już w procesie wyboru systemu – różnica w podejściu pomiędzy opartym o czasochłonne tworzenie i dokumentowanie koncepcji, a dopiero później budowanie rozwiązania, a opartym o interakcję i szybkie wypracowywanie konkretnych elementów rozwiązania.

MK: To dosyć skomplikowana historia, ale myślę, że te dwie rzeczy się zbiegły. Z jednej strony całkiem dobra kadra PZU, która po tych kilku latach reorganizacyjnych projektów była właśnie w tym punkcie, w którym zrobiliśmy już sporo ciekawych rzeczy zarówno po stronie IT, jak i po stronie biznesowej, i mieliśmy dobrą kulturę dobrej współpracy wewnętrznej i wytwarzania rozwiązań (czasami w bardzo krótkich okresach czasu). Byliśmy gotowi na to, żeby mniej się kontraktować wewnętrznie, a bardziej współpracować, co jest niezbędne przy agile’u od strony klienta. Z drugiej strony trafiliśmy na dostawcę, który miał doświadczenie w prowadzeniu dużych programów w agile’u, na Guidewire. Wykazaliśmy też gotowość i chęć zmiany. Widzieliśmy już agile’a, mieliśmy jakieś próbki wewnętrzne na mniejszych projektach i świadomość ram czasowych projektu. Wiedzieliśmy, że może on się zmieniać przez te trzy lata, więc potrzebujemy dobrego timeboxowania, czyli dowożenia konkretnych celów biznesowych, ale niekoniecznie w tych funkcjonalnościach, które znamy w roku 2011, tylko w takich, jakie w 2013 r. będą najlepsze, i jednocześnie mamy zespół wewnętrzny, który potrafi tym dobrze zarządzić. Te rzeczy się zgrały. Plus dostawca, który powiedział: „OK, idziemy na ryzyko podpisania z wami kontraktu, w którym wy w jakimś stopniu decydujecie o zakresie, za takie, a nie inne pieniądze”. I to nam świetnie zadziałało, tzn. enablement, możliwości ludzi, którzy poza tym, że mieli już doświadczenie w dużych programach, to jeszcze weszli na wyższy poziom, bo ten program był trochę trudniejszy niż poprzednie. Jednocześnie - duża dawka wiedzy o tym, jak się działa w agile’u od strony dostawcy i potem dwóch – trzech coachów, których sobie wzięliśmy - to było super do budowania podstaw. Dla nas pierwsze wydanie projektu, które najczęściej jest najbardziej stresujące – te momenty, kiedy się robi system, przygotowuje się go, wdraża – to był może nie  fun, bo tej wielkości programy łatwe nie są,  ale niesamowite doświadczenie tego jak można działać dostarczając trudne rzeczy i nie wypalając zespołu psychicznie. Ja to wspominam jako chyba najfajniejszy rok mojego życia zawodowego. Niewiarygodne!

AŁ: To też jest moja refleksja post factum - gdy zaczynaliśmy program Everesta, miałem  osiemnaście lat doświadczenia w realizacji mniejszych lub większych projektów: w PZU i wcześniej w innych instytucjach - a ja się wtedy pierwszy raz zetknąłem z agile w praktyce. Jednocześnie uświadomiłem sobie, że ta organizacja robiła już projekty w części zgodne z duchem agile, ale nie nazywające tego w ten sposób.

Przykładowo - projekt, który realizowałem przed Everest - trudny koncepcyjnie, z bardzo twardo ustawionym, nieprzesuwalnym deadline. Naturalne dla nas było, aby posadzić wszystkich (tych z biznesu i tych z IT) w jednym pomieszczeniu, podzielić na mniejsze zespoły zajmujące się konkretnymi procesami, zapewniać transparentność w komunikacji, dać trudne wyzwania ale też dużą decyzyjność przy tworzeniu rozwiązań i zapewnić maksymalne wsparcie decyzyjne. Ludzie momentalnie się przekonali, że przy takim podejściu, gdy mówią o problemie, to nie dostają po głowie, tylko mogą liczyć na pomocną dłoń. Dodatkowo, ponieważ niektóre terminy projektu były szalone, nie dało się wszystkiego zrobić szczegółowo, po kolei, to trzeba było to rozłożyć na mniejsze fragmenty. Przyjęliśmy więc model działania, który nazywaliśmy „na cebulkę” - pracy etapami, z pokazaniem kolejnego fragmentu rozwiązania co cztery–sześć tygodni. Okazało się potem, że to są wszystko elementy podejścia agile, chociaż  nazywaliśmy to inaczej.

MK: Jest w tym jedna bardzo ważna rzecz. Mamy taką teorię, o której ostatnio parę razy rozmawialiśmy w różnych gronach, że agile pozwala bardzo szybko uruchomić duże momentum projektu, czyli tę falę, w której spora masa ludzi (im większy program, tym ona jest większa), bardzo szybko uruchamia się i zaczyna dowozić konkretne rzeczy; nie teoretyzuje, nie zastanawia się nad ryzykami i nad tym, co się może wydarzyć za dwa i pół roku, jak to wdrożymy, tylko robi coś, pokazuje swoim odbiorcom, koryguje itd. Momenty, kiedy pokazywaliśmy pierwsze kawałki systemów, funkcjonalności, procesów, w zasadzie po trzech miesiącach projektu, a może nawet szybciej, to było niesamowite doświadczenie. Mieliśmy ponad stu interesariuszy PZU, bo tak wyglądają nasze product shows, oglądających kawałki działającego systemu i mówiących (szczerze) ludziom, którzy to wykonali, że to niesamowite, takie szybkie pokazanie namacalnego efektu. Interesariusze po takiej dawce chcieli wiedzieć, co będzie dalej, chcieli wspomóc rozwinięcie czegoś namacalnego – a nie sterty dokumentów. To się tak nakręca. Różnica między pierwszymi sprintami agile’a a fazą analizy w projekcie waterfallowym jest nieprawdopodobna. Odpada niskie momentum waterfall, gdzie myślimy o tym, co jeszcze może nie zadziałać, jakie jest ryzyko itp., – w agile’u to się nakręca i trzeba to momentum utrzymać, co jest pewnie naszym głównym zadaniem w tej chwili.

AŁ: Dla mnie takim szokiem na samym początku projektu była sytuacja, kiedy nasz pracownik PZU, który zaledwie kilka tygodni wcześniej szkoląc się pierwszy raz widział nowy system polisowy na oczy, nie żaden ekspert od dostawcy, stawał przed gromadą kilkudziesięciu osób z PZU opowiadając z zaangażowaniem na Product Show o przygotowanych rozwiązaniach. I dla naszych ludzi było to przekonujące - mieli przed sobą kogoś wiarygodnego, o którym myśleli: „To jest nasz człowiek. Jeżeli on do nas mówi, to nie jest dostawca, który może ukrywać drugie dno, tylko swój człowiek, który opowiada bez lukru o realnych rzeczach i rozwiązaniach”. To zupełnie inaczej ustawiało dyskusję - nie było odruchu, że gdy ktoś z PZU ma inne zdanie, to zaczyna sztorcować dostawcę. Nie można było powiedzieć: „Dostawco, co ty wiesz o biznesie, to ja mam rację”, ponieważ to była dyskusja pomiędzy dwoma ekspertami z PZU, a nie klasyczny model PZU kontra dostawca.

„Everest” jest prawdopodobnie największym przedsięwzięciem informatycznym ostatnich lat w tej części Europy, który ma w porywach do pięciuset uczestników...

MK: Aczkolwiek… jakby policzyć całą organizację, to pewnie więcej, ponieważ jest dużo osób zaangażowanych, ale niezwiązanych bezpośrednio z projektem. Pięćset osób to „full time”…

W jaki sposób ten projekt albo program był właściwie zorganizowany? Chodzi mi o to, kto miał uprawnienia decyzyjne w tym przedsięwzięciu?

MK: Miał i nadal ma, ponieważ nadal jedziemy tym samym torem. Na początku, ucząc się agile’a, staraliśmy się doprowadzić do stanu, w którym zamiast jednego wielkiego tankowca – programu, który nie jest mało sterowalny,  będą mniejsze części. I te części stawały coraz mniejsze w miarę zwiększania możliwości naszych ludzi. Podzieliliśmy całe przedsięwzięcie na takie łódeczki, które są bardziej zwinne i lepiej manewrują w trudnej sytuacji, bo – jak wiadomo – programy tej wielkości są niełatwe i uzależnione od wielu czynników. Decyzyjność, poprzez takie ustawianie działań naszych teamów, rzeczywiście schodziła coraz niżej i w tej chwili jesteśmy w sytuacji, w której mamy 34 zespoły agile’owe i związaną z nimi obudówkę logistyczno-programową. W każdym z zespołów mamy osobę, która decyduje o zakresie tego, co jest dowożone, mamy nad nimi obszarowego product ownera, głównych interesariuszy i członka zarządu, który wie, co się dzieje w danym kawałku biznesu, nad którym pracują te mniejsze teamy. I dopóki mamy jasno określone cele i wiemy, że są one albo takie, jak na początku programu, albo wiemy, w którą stronę się zmieniają, jest to strasznie skuteczna metoda pracy, ponieważ szybkość przekazywania informacji w górę i w dół, którą staramy się zapewniać, sprawia, że ci ludzie na dole nie mają tak długiego procesu zastanawiania się nad tym, co trzeba wdrożyć, i czy rzeczywiście to, czego się dowiedzieliśmy, ma sens. Czasami się mylimy i musimy coś przerobić, ale fakt, że jesteśmy w stanie skręcić tą naszą armadą w ciągu dni, a nie miesięcy, jest niesamowitą wartością dodaną. Wymaga to wytworzenia odpowiedniej kadry wewnątrz. Nam się udało i mam nadzieję, że będziemy z tego korzystali w przyszłości.

AŁ: Rozwijając ten program, posiłkowaliśmy się rekrutacją zewnętrzną, czyli ekspertami z innych firm, których kilkuletnie umowy terminowe oferowane przez PZU satysfakcjonowały. Dla ludzi, którzy pracują projektowo, takie umowy są dosyć naturalne. Przy czym, szczególnie od strony biznesu, nie dałoby się  przetransformować PZU, angażując wyłącznie osoby spoza PZU. Zatem po stronie biznesowej trzy czwarte osób zaangażowanych do  projektu to eksperci z wewnątrz PZU. Część z nich to osoby z wieloletnim doświadczeniem w PZU – można by powiedzieć, że z piętnem „molocha”. Bardzo szybko okazało się, że także pracownicy z długim stażem w PZU doceniają to, że wraz z większą odpowiedzialnością  mają większy wpływ na sprawy realizacyjne. Decyzyjność jest jak widać dużym źródłem energii i satysfakcji, ponieważ ludzie chcą mieć praktyczny, realny wpływ na to co tworzą.

MK: Takie działanie wymaga silnego leadershipu, co u nasna szczęście ma miejsce. Te sceny z początku projektu, ale również teraz, gdy ktoś, kto był przed rozpoczęciem „Everestu” np. kierownikiem liniowym (załóżmy, że gdzieś w operacjach), a teraz staje przed zarządem i opowiada, jaka funkcjonalność czy jaki kawałek biznesu jest zmieniany i jak on poprawi działanie PZU, i dostaje dobry feedback, są nieocenione. Ci ludzie tworzą bowiem dobre rzeczy. I wiadomo, że taki człowiek będzie się starał lepiej dowieźć to, co zaplanował, mając pewność, że informacja o tym szybko dotrze do samej góry. Bez pośredników (osób, które musiałaby to opisać, przekazać swojemu przełożonemu, tenże musiałby dopisać swój kawałek, żeby było, że on to zrobił, przekazać do góry i tak cztery stopnie do zarządu) szybciej też do niego dotrze informacja zwrotna na temat tego, co stworzył. Zatem bezpośredni kontakt między ludźmi, którzy napędzają program, z prezesem Klesykiem na czele, i tymi, którzy tymi małymi łódkami zarządzają, jest kwestią absolutnie kluczową. U nas to zadziałało i za każdym razem, jak sobie przez chwilę odpuszczaliśmy te interakcje, tworzyły się  problemy. Staramy się teraz utrzymywać ten poziom bliskości, rozmowy face to face pomiędzy ludźmi dowożącymi (na najniższym poziomie), a tymi, którzy decydują o tym, w którą stronę mamy sterować.

Można powiedzieć, że silny sponsorship to bardzo ważny klucz.

AŁ: Tak, to jedno. W modelu działania agile mamy też szereg kluczowych ról – jedną z nich jest Product owner. Musi on dopilnować tego, żeby dane rozwiązanie produktowe lub procesowe np. ubezpieczenie komunikacyjne, odpowiadało wymaganiom kilku menedżerów, zarządzających sprzedażą i obsługą klienta masowego. Ten sam produkt częściowo jest wykorzystywany w biznesie korporacyjnym – stąd macierzowa relacja z menedżerami biznesowymi.

Product owner odpowiadający za procesy i funkcjonalności sprzedaży także ma duże wyzwanie związane z macierzowością swoich relacji z dyrektorami odpowiedzialnymi za poszczególne kanały: agenci wyłączni, multiagencji, oddziały, Contact Center, etc. Zatem to musi być manager na wysokim poziomie, o bardzo rozległych kompetencjach, żeby z jednej strony merytorycznie to objąć, a z drugiej – nie dać się zwariować w momencie, gdy każdy z tych dyrektorów będzie wymagał czegoś innego, ponieważ mają różne priorytety i cele.

MK: Ale dlatego właśnie też organizacja musi być skoncentrowana na tym, żeby te interesy celowały w tą, a nie inną stronę. To niezmiernie ważne.

AŁ:. Kolejną istotną rzeczą dotyczącą organizacji i ról jest taka, że w każdym naszym zespole, przekazywaliśmy zarządzanie dwóm osobom. I podobnie jak na poziomie programu jest dwóch kierowników: jeden IT, drugi biznesowy – tak w każdym obszarze: produktów, sprzedaży, wznowień, obsługi, płatności, prowizji itp. też jest para liderów: biznes + IT. Obie te osoby mają ustawione dokładnie te same cele i KPI, przy czym jeden skupia się bardziej na aspektach produktowo-procesowych a drugi na aspektach IT. Te role częściowo się nachodzą, ale dzięki temu podejściu minimalizujemy ewentualne nieporozumienia na linii biznes – IT.

Kiedy usłyszałem, że jest dwóch dyrektorów odpowiedzialnych za „Everest”, to stwierdziłem, że to chyba niemożliwe i pewnie każdy z was ma jakiś inny obszar odpowiedzialności. W szkołach biznesowych, na wydziałach zarządzania uczymy, że zarządzanie powinno być w miarę możliwości indywidualne…

MK: Tylko pytanie, czy to się zgrywa z modelem pracy, który również jest powiązany z agile’em, bo mimo wszystko, tak jak teraz na to patrzę, cały setup naszego programu jest oparty o zespoły. Od tej najmniejszej komórki, o której mówimy, dwóch ludzi, biznes – IT, którzy tworzą ten podstawowy zespół i budują coś poniżej, do tych kilkuosobowych komórek scrumowych, my na każdym poziomie stawiamy na maksymalny teamwork i tak budujemy, rozwijamy, „szyjemy” wręcz sami naszych ludzi, żeby oni czuli, że jako grupa dołożą znacznie więcej, niż każdy z nich osobno. My jesteśmy tak różni – zewsząd to słyszymy – że jakby każdy z nas prowadził to przedsięwzięcie osobno, to pewnie po drodze wynikłoby z tego mnóstwo problemów, których byśmy nie zauważyli, już nie wchodząc w szczegóły. Uważam, że jako team, obudowany jeszcze zespołem, który jest pod nami, obok nas, częściowo też nad nami, potrafimy się na tyle dograć, zsynchronizować i użyć naszych mocnych cech, trochę ubijając te słabsze, że jesteśmy o wiele lepsi niż jedna osoba, i to nam zadziałało w tysiącach sytuacji. Mamy już sprawdzone na próbce kilkuletniego programu, że to ma sens.

A czy Panowie macie takie same kwalifikacje formalne? Jakie kierunki studiów kończyliście?

AŁ: W naszym przypadku jest trochę niestandardowo - ja jako menedżer biznesowy jestem z wykształcenia inżynierem elektronikiem.

MK: A człowiek od IT z wykształcenia jest filologiem angielskim.

AŁ: Po drodze, zanim zacząłem sześć lat temu pracę w PZU, byłem konsultantem procesowo-wdrożeniowym, miałem też dwuletni „epizod” pełnienia funkcji dyrektora IT.

MK: Ja bardziej pracowałem jako konsultant biznesowy, ale również jako konsultant IT, a później kierowałem głównie projektami po stronie IT. Miałem też epizody, kiedy byłem kierownikiem biznesowym różnego rodzaju przedsięwzięć.

AŁ: Zatem dość dobrze uzupełniamy się - ja mam dobrą orientację w tym, jak świat wygląda z perspektywy IT. Michał z kolei ma dobre rozumienie tego, jak się z biznesem rozmawia o celach biznesowych, o modelach procesowych etc. Oczywiście pewne rzeczy robimy i dogadujemy wspólnie, wiadomo – co dwie głowy, to nie jedna. Rzecz jasna dzielimy się poszczególnymi tematami, czasami ten podział jest dosyć oczywisty, a czasem bardzo umowny.

MK: Co więcej, jako część zespołu kilku PM-ów, którzy zarządzają tym programem, my rzeczywiście jesteśmy bardziej podzieleni na te dwie części (IT i Biznes), ale nasi ludzie, których rekrutowaliśmy wyłącznie do biznesu lub do IT, są już wymieszani kompetencjami. Czyli mamy razem z nami jeszcze pięciu naszych bezpośrednich współpracowników (nazywają nas siedmioma krasnoludami:), którzy zaczynali od stanowiska managera IT lub managera biznesowego jakiegoś obszaru projektu, a w tej chwili mają pod sobą liniowo organizację, która jest połączona zarówno IT, jak i biznesem.

AŁ: Mamy też naturalną specyfikę odpowiedzialności w obrębie liderów danego obszaru. Jest więc lider biznesowy, który często jest również Product ownerem - macierzowo w stosunku do dyrektorów biznesowych. Lider IT czasami bywa Scrum masterem, ale częściej koordynuje prace kilku Scrum masterów. Sposób działania tandemu biznes-IT jest taki, że identyfikacja problemów i szukanie rozwiązań jest wspólne, ponieważ żeby wykryć i dobrze zdiagnozować problem, trzeba się zastanowić, jakie są jego źródła i jakie on ma skutki. Z reguły źródła bywają w IT, a skutki widać w biznesie, ale bywa też odwrotnie. Jeżeli więc rozmawiamy o rozwiązaniach, to z reguły jest coś, co wymaga skoordynowanego działania zarówno po stronie IT, jak i po stronie biznesowej. Nasi liderzy są tak nastawieni, że przychodzą kompleksowo z problemami, ryzykami i ich rozwiązaniami. Często te uzgodnienia to kompromis, wymagający ustępstw obu stron np. „biznes zaakceptuje gorszą efektywność przez trzy miesiące, a IT w tym czasie wdroży usprawnienie uzgodnione oraz przetestowane z biznesem, które zmieni docelowy proces”.  

MK: Ale plusem takiego działania jest to, że obie strony w dość szybkim tempie się „douczają” tego, jak się działa po drugiej stronie, czyli na przykład product owner biznesowy zaczyna doceniać to, jak istotny jest architekt rozwiązania, który powie mu, w jakich systemach jakie funkcjonalności wdrożyć, bo dzięki temu można zbudować lepszy proces, i w drugą stronę – architekt, słuchając product ownera, wie lepiej, w jaki sposób użyć systemów, bo ma lepszy input, czyli wie, w jaki sposób biznes chce realizować te rozwiązania.

AŁ: Jeden i drugi rozumie całość, rozumie „po co”, razem dyskutują, uzgadniają, jak coś zrobić, by osiągnąć dany cel biznesowy. Jest to zasadnicze usprawnienie i przyśpieszenie komunikacji, dzięki której można osiągnąć rezultat i poznać sposób dojścia do niego.

MK: I my chyba mieliśmy dużo szczęścia – mogliśmy stworzyć taką organizację zamiast wpasowywać się w istniejące w PZU struktury.

Co zrobilibyście inaczej, gdybyście mogli cofnąć się w czasie?

AŁ: Mamy obszary biznesowe, gdzie jasność, klarowność wizji biznesowej jest od samego początku. Są też obszary, gdzie było trochę za dużo dystansu, stania z boku. W tych miejscach  jako organizacja zderzyliśmy się z niestabilnością wizji i zmiennością wymagań – co powoduje, że angażujemy tam więcej wysiłku i czasami przerabiamy już zrealizowane rozwiązania. Ten problem jest związany ze zderzeniem perspektywy krótko i długoterminowej. Zabrakło czasu na to, żeby wystarczająco dokładnie uzgodnić rozwiązania długoterminowe. Czasami była to też kwestia ograniczonych zasobów - z jednej strony ciśnienie: „To jest kluczowy, strategiczny, wieloletni program”, a z drugiej: „Wynik kwartalny, wynik kwartalny”. Na szczęście agile pomaga  w takich sytuacjach, ponieważ zapewnia większą reaktywność na zmiany.

MK: No tak, tylko, jak to się mówi: Hindsight is a beautiful thing. A my mamy jedną rzecz w „Evereście”, z której ja jestem dumny i jakiej będę pilnował do końca pracy w dowolnej korporacji. Uciekam tutaj od pytania, ale uważam, że warto o tym powiedzieć. Na każdym kroku wbijamy naszym ludziom do głowy, jest to częścią agile’a, ale również kultury pracy, którą uruchomiliśmy, zasadę inspect and adapt, czyli bardzo szybko patrzymy na to, co nam nie wychodzi, i dostosowujemy się w trakcie działania. I dlatego, jeżeli mieliśmy się zastanowić, co byśmy zrobili inaczej, to mamy tych rzeczy pewnie mnóstwo, ale z 80% pomysłów na poprawę ich  już wdrożyliśmy w życie i chyba to sprawia, że nam dobrze idzie to nasze przedsięwzięcie. To jest dla mnie najważniejsza zasada, jaką się kierujemy w „Evereście”.

Ładna puenta.

MK: I prawdziwa. W momencie, kiedy ludzie powiedzą sobie wewnętrznie, że „błędy to piękne „chwile”, bo mimo wszystko się na nich uczymy (a natura ludzka ma wbudowaną potrzebę rozwoju i uczenia się), to jest życie na projekcie staje się lepsze i ciekawsze.

Bardzo dziękuję

 

Rozmawiał Dariusz Wieczorek

 

Andrzej Łach

Dyrektor Biura Operacji Majątkowych. W PZU SA od 2009 roku - jest odpowiedzialny za optymalizację i automatyzację procesów oraz centralizację obsługi agentów. Od 2012 roku współzarządza programem Everest - całościową transformacją procesów agenckich oraz front- i back-office, powiązaną z wdrożeniem nowego systemu polisowego.

Wcześniej, w Aviva, był zaangażowany w uruchomienie kanału sprzedaży direct. Pracował także w konsultingu, realizując projekty w bankowości i ubezpieczeniach.

 

Michał Kopyt

Dyrektor ds. Transformacji IT Absolwent Uniwersytetu Warszawskiego, Project Manager z zawodu i zamiłowania, od ponad 6 lat entuzjasta i propagator „being Agile”, praktycznie wdrażający metodyki zwinne w warunkach dużych korporacyjnych programów transformacji – od kilkudziesięciu do kilkuset osób. Jego pasją i jednocześnie zawodem jest tworzenie niezwykłych zespołów ze zwykłych ludzi.

Doświadczenie zbierał na projektach w Polsce i Europie, w sektorach Telco, Bankowym oraz FMCG.

Obecnie całkowicie zaangażowany w projekt Everest, największy program prowadzony w ramach grupy PZU, będący jednocześnie motorem zmiany sposobu pracy i myślenia o biznesie – prowadzony w całości w metodyce Agile. Wierzy w możliwości wydobywania przewagi konkurencyjnej na trudnym rynku dzięki odpowiedniemu zarządzaniu zasobami ludzkimi.

 

Artykuł publikowany w magazynie „Zarządzanie Projektami” Nr 2(9)/2015

Logo w stopce
KONTAKT

Portal zarzadzanieprojektami.org, Gdański Park Naukowo-Technologiczny
ul. Trzy Lipy 3, 80-172 Gdańsk
E-mail: biuro@e-zp.org
tel.: (+48) 501 794 318
Copyright © 2016. Wszystkie prawa zastrzeżone.
Projekt i wykonanie Interaktywna PIQUA