Na co zwrócić uwagę rozpoczynając projekt RPA? - Automation Talk #9

W tym odcinku dowiesz się, jakie sa modele wdrażania robotyzacji w organizacji:

1. Aspekt źródła zasobów
   1. wewnetrzne
   2. zewnetrzne
   3. hybrydowo
2. Przynalerzność COE
   1. Biznes
   2. IT
   3. Shared services
3. Umiejscowienie COE w organizacji
   1. centralne
   2. w departamentach
   3. mieszane
4. Stanowiska w projecie RPA
   1. Analityk biznesowey
   2. Developer RPA
   3. Utrzymanie i administracja
   4. Citizen developerzy

Posłuchajcie, zmotywujcie i wyciągnijcie z tej rozmowy to, co dla Was teraz najlepsze.

🎧 Zapraszamy na Spotify, Apple Podcasts, Google Podcasts, Spreaker. Enjoy!

Listen to "#9 Na co zwrócić uwagę rozpoczynając projekt RPA" on Spreaker.

Transkrypcja

Sebastian Grzesik: Cześć, nazywam się Sebastian Grzesik.

Mateusz Tajak: Cześć, z tej strony Mateusz Tajak.

Sebastian Grzesik: Dzisiaj chcielibyśmy z Wami porozmawiać o domenie zyskującej na popularności, czyli Robotyzacji Procesów Biznesowych (ang. Robotic Process Automation, RPA).  **Chcielibyśmy podzielić się naszymi doświadczeniami oraz porozmawiać o tym, w jaki sposób można rozpocząć swoją przygodę z Robotic Process Automation z perspektywy organizacji oraz z punktu widzenia zorganizowania tego procesu wewnątrz firmy. Chcielibyśmy też nawiązać do RPA w kontekście Centrum Doskonalenia Robotyzacji (ang. Center of Excellence, CoE) **oraz umiejscowienia tej jednostki w organizacji. Co najważniejsze, chcielibyśmy porozmawiać o projektach RPA, rolach, jakie w nich występują oraz o tym, jak dzisiaj zmienia się rynek Robotyzacji Procesów Biznesowych.

Mateusz Tajak: Dokładnie tak! Wielu klientów chce wejść w projekt RPA, bo o tych procesach dużo się mówi. Jednak kiedy przychodzi do konkretów, to na początku trzeba podjąć kilka ważnych decyzji, które będą wpływały na rozwój projektu w firmie. Spotykamy się u klientów z sytuacjami, że podjęcie tych decyzji jest bardzo trudne. W związku z tym dzisiaj chcielibyśmy przybliżyć obszary, o których wspomniał Sebastian — są one bardzo istotne, aby dobrze zdefiniować cele RPA w organizacji oraz zastanowić się, jak RPA w ogóle powinno być umiejscowione w firmie. Naszym dzisiejszym celem jest zatem podzielenie się spostrzeżeniami w tym obszarze, które zyskaliśmy na podstawie projektów prowadzonych u naszych klientów.

Sebastian Grzesik: Nadając właściwy kontekst naszej rozmowie, chciałem powiedzieć, że rynek RPA bardzo dynamicznie rośnie. O tym, dlaczego tak się dzieje, pewnie jeszcze powiemy, ale już warto podkreślić, że rok 2020 zapewnił hipersoniczne przyspieszenie tej branży. To przyspieszenie jest wyrażone w miliardach dolarów. Jeżeli dzisiaj popatrzymy na wielkość rynku dla biznesu RPA, to mówi się o 2 miliardach dolarów tylko w 2021 roku. Do 2029 lub 2030 roku może on wzrosnąć sześciokrotnie, a nawet siedmiokrotnie. Jest to niebywała dynamika.... Może od tego zacznijmy naszą rozmowę. Dlaczego uważasz, że dzisiaj Robotic Process Automation to przyszłość średnich i małych organizacji?

Mateusz Tajak: Rzeczywiście tak jest, że kiedy posłucha się firm konsultingowych np. z wielkiej czwórki czy firm badawczych, jak Gartner czy Forrester, to wszystkie statystyki wskazują, że RPA pojawia się coraz częściej i coraz więcej firm z niego korzysta. Tak naprawdę to jest determinantą wzrostu — firmy po prostu inwestują w RPA, wdrażają i automatyzują wszystkie możliwe procesy. Dzieje się tak z kilku przyczyn. Już w tej chwili mamy ograniczony rynek pracowników. W tym momencie bardzo ciężko jest pozyskać ludzi, którzy mogą realizować dla nas zadania. To jest pierwszy element wpływający na obecną sytuację. Po drugie, wdrożenia RPA są coraz bardziej dostępne i łatwiejsze, niemal w zasięgu ręki dla większości organizacji, w których zautomatyzowane procesy mogą przynieść korzyść. Po trzecie, wiedza na temat sposobu wdrażania procesów jest coraz bardziej dostępna. Zwiększa się ilość firm, partnerów i producentów oprogramowania RPA, które pozwalają na automatyzację procesów. O ile wiedzy rzeczywiście jest sporo, to większym problemem jest zaimplementowanie tej wiedzy w praktykę i przełożenie jej na organizację. Tak naprawdę wyzwaniem jest to, aby RPA został wpisany w strategię organizacji, a nie był jedynie wdrażany w pojedynczych silosach czy komórkach w danej firmy. Trzeba pamiętać, że automatyzacja jest elementem szerszego spojrzenia na to, jak są realizowane procesy w firmie. Zazwyczaj to nie jest kwestia tego, jak funkcjonuje jeden mały dział.

Sebastian Grzesik: Próbując Cię sparafrazować, to mówisz o tym, że rośnie świadomość oraz o tym, że brakuje rąk do pracy, bo faktycznie mamy dzisiaj do czynienia z rynkiem pracownika, a nie pracodawcy. Dodałbym tutaj jeszcze — szczególnie z perspektywy pracodawcy — koszty pracy (ang. labour cost), które rosną wykładniczo. Nawiązując do Twojej wypowiedzi, firmy rozumieją coraz lepiej korzyści z edukacji i widzą sens w optymalizacji i automatyzacji. I te możliwości są wykorzystywane. Manualne elementy, które pracownicy wykonują na komputerze, takie jak budowanie diagramu, tworzenie raportu czy przenoszenie danych pomiędzy dokumentami stają się bezcelowe. Czas i koszt tej pracy jest bardzo wysoki, natomiast jej wartość może być istotna, ale nie na tyle istotna, aby w pełni rekompensować koszty. Co za tym idzie, jednym z najłatwiejszych sposobów maksymalna optymalizacja. Kiedyś budowano karoce w formie rzemieślniczej, a dzisiaj Tesla wykorzystuje optymalizacje procesów budowlanych związanych z płytą podłogową czy innymi elementami technicznymi w procesie produkcji. Chodzi o to, aby w tym procesie był minimalny wpływ człowieka, a maksymalny wpływ maszyny, czego konsekwencją są minimalne koszty.

Mateusz Tajak: Jednym z powodów, przez które firmy decydują się wdrożyć RPA, jest redukcja kosztów operacyjnych. Wiadomo, że im mniejsze są te koszty, tym firma ma większą możliwość bycia konkurencyjnym na rynku, a przez to pozyskiwać więcej klientów i szybciej rosnąć. Tych argumentów za wprowadzeniem RPA jest naprawdę dużo.

Sebastian Grzesik: Właśnie chciałem zadać Ci pytanie w tym wątku. Jeśli już zrozumiemy wewnątrz organizacji, że chcemy RPA, bo wiemy, że jest to dla nas droga do przyspieszonego rozwoju, do ograniczania kosztów, do redukcji lub optymalizacji, to co dalej? Jak można podejść do tej domeny, aby zrobić to dobrze?

Mateusz Tajak: Tutaj zazwyczaj pojawiają się pierwsze wyzwania. Właśnie wtedy, kiedy wiemy, że chcemy wdrożyć RPA, dojrzeliśmy do tego w organizacji. Załóżmy, że jesteśmy osobami w firmie, która zdecydowały się zostać liderami projektu i wziąć na barki wdrożenie RPA. Jeśli taka osoba jest dość mocno umocowana w organizacji, to mamy połowę sukcesu. Wtedy mamy wpływ na szerszą perspektywę w organizacji. Natomiast jeśli jest to osoba niżej umocowana, to powinniśmy przejść wyżej i zaangażować osoby bardziej decyzyjne, które będą mieć wpływ na projekt. Jednak to jest temat na osobny odcinek.

Wracając do meritum, jeśli zdecydowaliśmy się na wdrożenie takiego rozwiązania, jak RPA, mamy osobę prowadzącą, mamy zaangażowany zespół wspierający projekt organizacyjnie, mamy środki finansowe, to mierzymy się z kilkoma wyzwaniami. Pierwszym jest wykonawca. Możemy na rynku poszukać firmy, która wdroży RPA. Jednak zanim to nastąpi, trzeba dobrze znać procesy i odpowiednio zaplanować wszystkie działania, zwłaszcza z biznesowego punktu widzenia. Pierwszym aspektem, które powinniśmy rozważyć, to pytanie: czy w naszej firmie chcemy budować własne kompetencje związane z RPA i samemu wdrażać rozwiązanie, czy chcemy wykorzystać firmę zewnętrzną, a może chcemy rozwiązać to wszystko hybrydowo. To jest bardzo ważna kwestia do rozważenia na samym początku, ponieważ ta decyzja determinuje, jak będzie wyglądać cały projekt. Jeśli zdecydujemy się na wewnętrzne rozwijanie zasobów, to — po pierwsze — musimy znaleźć kogoś, kogo zatrudnimy jako RPA lead, czyli osobę, która przejmie proces wdrożenia RPA lub zaangażuje się w bardzo dużym stopniu w całe zadanie. Plusem tego podejścia jest to, że taka osoba będzie miała ogromną wiedzę na temat procesu w firmie, większy dostęp do osób w firmie potrzebnych do identyfikacji procesów oraz możliwości do szerzenia kultury automatyzacji w organizacji. Takie właśnie są plusy w podejściu wdrażania RPA wewnętrznymi zasobami. Natomiast jest to dość drogie rozwiązanie upfront, bo musimy założyć, że przez jakiś czas osoba oddelegowana do tego zadania będzie wykonywała pracę, która nie przynosi efektów. W tym momencie będzie się uczyć, mapować procesy i wykonywać inne podobne czynności.

Sebastian Grzesik: Dobrze rozumiem, że taka osoba — RPA lead — na początku budowania działów czy inicjatyw związanych z RPA jest zaangażowana w bardzo dużym stopniu w  pracę analityczną?

Mateusz Tajak: Dokładnie tak. W każdym dużym projekcie czy działaniach związanych z przebudową w firmie, to na początku osoba rozpoczynająca pracę pełni wiele różnych funkcji: od analityka i osoby patrzącej na projekt od strony biznesowej, przez kogoś, kto musi zrozumieć technologię, a także znaleźć i zatrudnić zasoby techniczne. Co za tym idzie, taka osoba musi przyjąć na siebie wszystkie funkcje, które w docelowym Center of Excellence muszą się pojawić, realizować je, a dopiero potem oddelegowywać. I to są powody, dlaczego rozpoczęcie projektu zajmuje tak dużo czasu i na początku jest duża bariera wejścia, zwłaszcza jeśli w firmie nie ma kultury posiadania procesów w różnych obszarach.

Sebastian Grzesik: Jak można podejść do tematu inaczej? Są inne drogi niż ta zaczynająca się od pospolitego, wewnętrznego ruszenia?

Mateusz Tajak: Oczywiście! Drugim sposobem jest zatrudnienie firmy zewnętrznej. Po podjęciu decyzji, że chcemy realizować projekt automatyzacji procesów w firmie z wykorzystaniem RPA, można poszukać na rynku firm specjalizujących się we wdrażaniu takich rozwiązań. Przy wyborze należy jednak zwrócić uwagę na kilka aspektów: czy ma to być firma techniczna umiejąca wdrażać wcześniej przygotowane procesy, czy ma to być firma, która posiada też kompetencje konsultingowe i jest w stanie nie tylko wdrożyć rozwiązanie, ale też poprowadzić nas za rękę w procesie analitycznym. Trzeba się zastanowić, czy potrzebujemy pomocy w identyfikacji procesów, które możemy zautomatyzować i doradzeniu odpowiedniego kierunku działań, a także podpowiedzieć, jakich technologii powinniśmy używać, a nawet doradzić, czy robotyzacja rzeczywiście jest dla nas najlepszych podejściem do automatyzacji procesów w firmie. Często jest tak, że robotyzacja jest jedną z koncepcji na automatyzację w organizacji, natomiast nie zawsze jest to najlepsze rozwiązanie. Doświadczona firma jest w stanie powiedzieć, w którym kierunku powinniśmy pójść. Zatrudnienie firmy zewnętrznej jest zatem drugim podejściem. Tutaj również mamy plusy i minusy. Próg wejścia jest zdecydowanie mniejszy — szybciej widzimy rezultaty. Firma zewnętrzna przeszła już proces wdrażania robotyzacji z innymi organizacjami i ma doświadczenie, więc jest w stanie szybciej prowadzić nas za rękę przez proces wdrażania pierwszej automatyzacji w naszej firmie. Z tej perspektywy zdecydowanie szybciej zauważymy pierwsze rezultaty, Minusem jest jednak to, że firma zewnętrzna jest spoza organizacji i może nie mieć dostępu do pewnych kwestii. Zawsze mamy pośrednika kontaktującego się z podwykonawcą, a firma zewnętrzna nie zawsze jest w stanie zauważyć wszystkie istotne kwestie biznesowe w danej organizacji. Wynika to z tego, że osoby, które wdrażają rozwiązania, nie są na co dzień obecne w firmie, nie są włączone w bieżącą komunikację i niekoniecznie mają dostęp do wszystkich procesów. Tak to wygląda z tej perspektywy.

Sebastian Grzesik: Czy jest jeszcze jakieś podejście, które, Twoim zdaniem, mogłoby być pomocne lub pogodzić jedno i drugie? Z naszego wspólnego doświadczenia wynika, że jest takie rozwiązanie. Są modele pośrednie.

Mateusz Tajak: Zadałeś pytanie z tezą: „czy jest trzecie podejście”? Oczywiście, że jest i chodzi tutaj o podejście hybrydowe. Takie podejście jest oczywiste w wielu obszarach, nie tylko IT. Chodzi tutaj o to, że decydujemy oddelegować część kompetencji firmie zewnętrznej, a część kompetencji rozwijamy wewnętrznie. Jeśli chodzi o RPA, to podział zazwyczaj odbywa się w taki sposób, że wewnętrznie pozostawiona jest warstwa analityczna, czyli ta, która jest blisko biznesu. Do firmy zewnętrznej jest oddelegowywany development. Oznacza to, że „u siebie” zostawiamy kompetencje analityczne pozwalające na budowanie map procesów i całą dokumentację potrzebną deweloperowi, na podstawie której można zacząć programować robota bądź inne rozwiązanie RPA. Wiele firm podchodzi do tematu w ten sposób. Benefity są tutaj takie, że jesteśmy w stanie być bardzo blisko biznesu, bo analitycy pracują w naszej firmie. Natomiast nie musimy budować drogich kompetencji związanych z developmentem i tworzeniem robotów. Te zadania możemy oddelegować do firmy, która się specjalizuje w tej dziedzinie. Z jednej strony, takie podejście  obniża koszty wejścia w robotyzację, ponieważ najcięższa praca analityczna, wymagająca najwięcej wiedzy i doświadczenia, zostanie wykonana wewnętrznymi zasobami, które są tańsze niż firma zewnętrzna. Z drugiej strony, mamy pewność, że firma, z którą współpracujemy, ma kompetencje techniczne, które są łatwiejsze do zweryfikowania niż kompetencje konsultingowe. To jest trzeci model, który jest najczęściej wybierany przez średniej wielkości organizacje, które uważają, że jeszcze są zbyt małe na to, żeby budować wewnętrzne Center of Excellence, a jednocześnie chcą posiadać kompetencje do tego, aby zarządzać automatyzacją i mieć na nią realny wpływ.

Sebastian Grzesik: Użyłeś magicznego sformułowania Center of Excellence… Jak moglibyśmy rozwinąć ten termin? Myślę, że dla większości firm, które nas słuchają, nie jest to pierwszy przypadek, kiedy jest wdrażana technologia, domena albo standard. Wówczas przychodzą do organizacji innowatorzy czy championi, którzy mówią, że „to jest sposób na osiągnięcie sukcesu w Twojej organizacji”. Powiedziałeś o Center of Excellence i zastanawiam się, w jaki sposób można podejść do tego zagadnienia, aby wszystko było dobrze i skutecznie zrobione. Domena RPA, jak z resztą wiele innych domen w świecie IT, jest na skraju — ona nie jest czysto technologiczna, ani analityczno-biznesowa. Potrzeba bardzo właściwego wyważenia: w jednej organizacji będzie to bliżej IT, w drugiej organizacji będzie to bliżej kierunku finansowego lub departamentu księgowości… Chciałbym to lepiej zrozumieć. Widzimy po naszych klientach i z naszych wspólnych doświadczeń wiemy, że umiejscowienie Center of Excellence na mapie w strukturze organizacyjnej firmy jest pewnym wyzwaniem.

Mateusz Tajak: Tłumacząc, czym jest Center of Excellence, można powiedzieć, że jest to Centrum Doskonalenia, które można wdrożyć w organizacji. Jest to komórka posiadająca kompetencje do tego, aby zarządzać robotyzacją, propagować ją i budować kulturę automatyzacji wśród różnych działów, funkcji czy osób w organizacji. Jeśli zdecydowaliśmy się wdrożyć RPA w podejściu budowania wewnętrznych kompetencji bądź wykorzystania wcześniej omawianego podejścia hybrydowego (gdzie częściowo wykorzystujemy partnera zewnętrznego) w pewnym stopniu decydujemy się na budowanie Center of Excellence — osobnej komórki w firmie bądź cross-funkcjonalnego działu w organizacji, która pozwala nam propagować i promować RPA oraz wdrażać kolejne procesy. Tutaj rzeczywiście wspomniałeś o dylemacie, gdzie taka komórka może być umiejscowiona. Zastanawiając się nad tym, powiedziałeś też, że RPA jest czymś na pograniczu biznesu i technologii. W sumie widać podobieństwo do systemów ERP. Z jednej strony jest biznes, który nie jest w stanie wdrożyć rozwiązania bez IT. Z drugiej strony mamy IT, które bez rozumienia biznesu, prawdopodobnie źle wdroży ERP. Z RPA jest dokładnie tak samo. Chociaż zaryzykowałbym stwierdzenie, że ERP jest jednak bliżej biznesu, a IT pełni tutaj funkcję wspierającą. Natomiast nie możemy zapominać o tym, że jest to technologia informatyczna.

Wracając do naszego tematu, to załóżmy, że Center of Excellence może podlegać pod dział IT (dyrektora IT, CIO lub inną strukturę związaną z informatyką w organizacji). Takie rozwiązanie ma jednak plusy i minusy, o których może kiedyś powiemy w osobnych odcinkach. Natomiast wymieniając szybko główne aspekty, to jeśli decydujemy się budować kompetencje CoE w IT, to trzeba pamiętać, że w wielu organizacjach dział IT jest traktowany jako koszt. Co za tym idzie, koszty wdrożenia RPA będą bardzo wysokie, ale nie będą traktowane jako inwestycja w oszczędność czasu. Te może być pierwszy minus, zwłaszcza jeśli podejdziemy do tematu w budżetowy sposób. Z drugiej strony, dzięki zbudowaniu CoE w ramach działu IT łatwiejsze będzie wdrożenie RPA od strony technicznej. Dział IT wesprze cały proces od strony technologicznej i będzie lepiej rozumieć RPA jako oprogramowanie w stacku technologicznym, jaki w firmie się pojawia. Będzie to dawało większe możliwości integracji z innymi rozwiązaniami pojawiającymi się w firmie. Wracając do minusów, będzie mniejsze zrozumienie biznesu. Oznacza to tyle, że będzie mniejsza chęć do identyfikowania kolejnych procesów do automatyzacji, ponieważ CoE najprawdopodobniej zamknie się w bańce IT i nie będzie miało celu związanego z tym, aby automatyzacja dawała realność wartość biznesową.

Sebastian Grzesik: Jeżeli nie IT, to jakie są inne opcje?

Mateusz Tajak: Jeśli nie IT, to biznes. Struktura RPA może na przykład podlegać bezpośrednio pod dyrektora finansowego. Dzięki temu zdecydowanie łatwiej jest zarządzać budżetem projektu czy weryfikować rentowność robotyzacji. Z drugiej strony są pewne ograniczenia związane z komunikacją z IT. W takim podejściu IT jest bardzo często blokerem, który traktuje RPA jako kolejny system czy platformę, która musi być utrzymywana przez zespół. Istnieje wówczas zagrożenie, że RPA będzie mniej wspierane od strony technologicznej. Natomiast z całościowego punktu widzenia uważam, że lepsze podejście jest wtedy, kiedy komórka automatyzacji raportuje bezpośrednio do biznesu. Moja opinia jest też poparta obserwacjami z firm, w których wdrażaliśmy RPA lub mamy tam kontakt i słyszymy historie związane z tym zagadnieniem. Jest też trzecia opcja, dostępna dla dużych organizacji, które posiadają własny shared service. Wtedy ta komórka może być zlokalizowana właśnie w shared service, dlatego że tam znajduje się najwięcej procesów typu back office. Co więcej, w tych oddziałach procesy są dojrzałe, dobrze **zarządzanie i udokumentowane, więc relatywnie prosto jest wdrożyć robotyzację właśnie w shared service. Minusem jest jednak to, że shared service jest czasem oderwane od firmy. Bardzo często jest to spółka-córka, która realizuje swoje cele. W sumie sama nazwa na to wskazuje. Co za tym idzie, automatyzacji będą wówczas podlegać tylko procesy back office i nigdy nie będzie skupienia na kluczowych działaniach, które tworzą dany biznes. Przykładem może być e-commerce, gdzie główne działania takie, jak obsługa klienta czy zamówień, znajdują się w głównej firmie, natomiast wszystkie działania back office są w shared service. I wtedy automatyzujemy to, co jest w shared service, a nie to, co jest w głównej spółce.

Sebastian Grzesik: Powiedziałeś, że model hybrydowy albo wręcz ten bliżej biznesu jest bardziej skuteczny. Rozumiem, że w tych po prostu łatwiej obliczyć ROI, tak? Jeżeli komórka zajmująca się automatyzacją czy Center of Excellence jest umiejscowione blisko danego departamentu, to naturalne jest to, że próbuje się liczyć się wpływ takiego działu na obniżenie kosztów, optymalizację kosztów pracy, ilości FTE czy też całych procesów biznesowych. W końcu chodzi o to, że większość departamentów biznesowych ma pewne procesy, które są lepiej lub gorzej realizowane. Jeżeli trzeba je zmapować, a potem nauczyć bota wykonywać wszystkie czynności, to często robi się też rekoncyliację. Wówczas poszczególne działy: księgowości, finansów czy obsługi klienta, nagle zaczynają się zastanawiać czy procesy są realizowane w sposób możliwie optymalny, możliwie najtaniej i możliwie najlepiej dla klienta. Wydaje mi się, że to ma sens, zwłaszcza na początku drogi. Konstrukty implementacyjne Robotic Process Automation inaczej wyglądają w momencie, kiedy jest dojrzałym tworem optymalizacyjnym w dużej organizacji. Zupełnie odmienne podejście jest wtedy, kiedy zastanawiamy się, jak skutecznie zaadaptować kulturę automatyzacji w dziale lub całej organizacji.

Mateusz Tajak: Zdecydowanie tak. Jak już rozmawiamy o adaptacji, to warto spojrzeć na aspekt umiejscowienia kompetencji w organizacji, jednak już nie od strony komórki, ale w kontekście tego, jak automatyzacja będzie promowana w firmie. Mogę sobie wyobrazić (a nawet powiedzieć przykład ze swojego podwórka) sytuację, że w firmie jest dział zajmujący się automatyzacją oraz dział operacyjny. Celem osoby pracującej w automatyzacji jest chodzić po firmie i szukać procesów, które powinny zostać zautomatyzowane i pomagać ludziom te procesy automatyzować. Z drugiej strony natomiast mamy kogoś, kto na co dzień jest zawalony pracą, procesami i setką maili do napisania. Kiedy osoba z działu automatyzacji przychodzi do osoby z działu operacyjnego i mówi: „Hej, może coś byśmy tutaj zautomatyzowali?”, a ta druga osoba odpowiada: „Dobra, przyjdź jutro, bo dzisiaj mam ważną ofertę do wysłania”. I tak naprawdę tutaj czasem się kończy współpraca. To może być jednak z przyczyn, dlaczego te projekty się nie udają.

Sebastian Grzesik: Przypomniała mi się anegdota o Jeffie Bezzosie, który był na wczesnym etapie rozwoju Amazona i pakował paczki. Kiedyś było tak, że miliarderzy pracowali na najniższych stanowiskach, na których teraz zatrudniają pracowników. Podobno była taka sytuacja, kiedy Jeff Bezos klęczy i pakuje paczki, a obok niego jest pracownica, która również pakowała paczki i Jeff mówi do niej: „Jenny, mam świetny pomysł! Żeby szybciej i lepiej pakować paczki, to powinniśmy mieć klęczniki, dzięki którym będzie nam wygodniej”. Ona odpowiada: „Nie, musimy mieć stół do pakowania i stół do przygotowywania paczek, a nie klęczniki”. Myślę, że często zachodzą sytuacje, o której mówisz, zwłaszcza kiedy przychodzisz wtedy z wędką, a nie inną rybą.

Mateusz Tajak: Nie ma się co dziwić ani jednej, ani drugiej stronie. Każdy ma swoje własne cele do zrealizowania. Teraz powinniśmy się zastanowić, czy kompetencje posiadane przez daną osobę pasują do Center of Excellence. W końcu ta komórka po coś istnieje. Zastanowiłbym się tutaj jeszcze nad tym, jak sprawić, aby w każdym departamencie mieć lidera. Chodzi o to, żeby osoba pracująca w Center of Excellence w każdym departamencie miała osobę, która jest w stanie wspierać robotyzację, wyszukiwać procesy do automatyzacji i dostarczać je do CoE. Tak naprawdę nikt nie zna lepiej realizowanych procesów, niż osoby pracujące w poszczególnych departamentach. Często praktyka jest taka, że w poszczególnych departamentach wyszukuje się osobę, która dość dobrze rozumie Excele i potrafi myśleć procesowo. Taką osobę szkoli się na tak zwanego Citizen Developer, czyli kogoś, kto rozumie, czym jest robotyzacja i jest w stanie rozpoznać obszary nadające się do procesu wdrożenia robotyzacji. Wtedy pojawia się rozproszone i cross-funkcjonalne Center of Excellence. Dana osoba pracuje na przykład w dziale finansów, ale organizacyjnie ma też funkcję w Center of Excellence. Dzięki temu możemy sprawić, że automatyzacja będzie się budowała oddolnie. Koleżanki i koledzy z działu finansów będą widzieć, że taka osoba ułatwia sobie pracę dzięki robotom albo sama jest w stanie sobie utworzyć automatyzację. Pozostali pracownicy to zauważą i z czasem zostanie zbudowana kultura automatyzacji w firmie. Oczywiście nie wydarzy to się z dnia na dzień, ani z tygodnia na tydzień. To jest długi proces. Podobnie jak wdrożenie robotyzacji — to też jest proces, który według mnie się nie kończy. Raczej jest to proces nieustannego ulepszania. Trzeba się tutaj zastanowić, czy chcemy na całej organizacji nałożyć czapkę w postaci Center of Excellence, czy budować w organizacji osobne silosy, które będą się tym zajmowały. Natomiast to nie jest najważniejsze pytanie, na które musimy na początku odpowiadać, ale warto je mieć z tyłu głowy. Poza tym, należy się zastanowić nad tym, która opcja będzie lepiej pasować do kultury organizacyjnej firmy. Mamy przecież takie kultury organizacyjne, w których szef powie, że „tak jest i tak musi być” i wtedy centralne Center of Excellence się sprawdzi. Jednak są też kultury organizacyjne, które są bardziej oporne na zmiany i wtedy warto zastanowić się, jak oddolnie pchać robotyzację do przodu.

Sebastian Grzesik: Jakbyś miał wymienić role albo czapki ról ludzi, którzy często pojawiają się na projekcie RPA, to jakbyś je nazwał? Wiem, że to trudne, bo często na początku role są współdzielone dla jednej osoby. Czy pełnione funkcje są podobne jak przy innych projektach IT, jak na przykład custom development? Czy widzisz tutaj różnice?

Mateusz Tajak: Jest jednak trochę inne podejście. Wdrożenia RPA są troszkę oderwane od custom development. Wdrożenia automatyzacji procesów są krótsze w porównaniu z wprowadzeniem funkcjonalności w oprogramowaniu tworzonym pod indywidualnego klienta. Jeśli natomiast chodzi o role, to warto być ich świadomym w kontekście wdrażania RPA. Pierwszą najważniejszą rolą, którą według mnie powinniśmy albo w organizacji mieć, albo zweryfikować czy nasz potencjalny dostawca ma, to są analitycy biznesowi.

Sebastian Grzesik: Słyszałem porównanie, że analitycy są jak górnicy. W sumie są nazywani process mining analyst, więc oni są górnikami czy odkrywcami niedoskonałości i elementów związanych z potencjalną stratą dla organizacji.

Mateusz Tajak: Nawet jest osobna działka klas oprogramowania związanego z task czy process mining. Rzeczywiście są to osoby, które znają organizację, są w niej umocowani, rozumieją procesowe podejście, potrafią robić mapy procesów i znają notację BPMN. Z drugiej strony rozumieją też, czym jest RPA i jak działa oprogramowanie, ale nie na warstwie technicznej, a na warstwie logicznej. Dzięki powyższym kompetencjom, osoby mogą szybko znajdować procesy, przygotowywać dokumentację, budować tak zwane mapy „as is”, czyli mapy opisujące obecny wygląd danego procesu oraz mapy „to be”, czyli tematy, które są już przetłumaczone na język robota, które deweloper będzie mógł potem zaprogramować. Taka osoba jest zatem niezwykle cenna z punktu widzenia sukcesu wdrożenia RPA w organizacji. Kolejną rolą jest deweloper RPA, czyli ktoś, kto jest w stanie zaprogramować działającego i realizującego wcześniej wyznaczone procesy robota. Oczywiście bardzo często jest tak, że te role są łączone ze sobą. Kiedy jesteśmy na początku drogi, to nie stać nas na zatrudnienie i analityka, i dewelopera, i jeszcze kilku osób pełniących inne role. Bardzo często jest jedna osoba wszechstronna, która wraz z rozwojem będzie w stanie bardzo szybko awansować i pójść albo w stronę senior developera, albo w stronę architekta rozwiązań, albo w stronę analityka.

Sebastian Grzesik: Czuję, że tutaj mamy zbieżność ze światem software development, ponieważ RPA developer to może być osobne stanowisko. Obok niego, równolegle, może być ktoś, kto zajmuje się administracją i tą częścią serwerową. Często jest to osoba odpowiedzialna za tak zwane operations. W niektórych firmach nazywa się to infrastrukturą, w innych operations, w jeszcze innych po prostu DevOps. Natomiast bardzo często zdarza się tak, że stanowiska dewelopera również ewoluuje i pełni funkcję tak zwanego full-stacka, czyli jest deweloperem, który jednocześnie opiekuje się infrastrukturą. W bardzo dużych organizacjach te role są odpowiednio oddzielone od siebie po to, aby utrzymanie i administracja były tylko komórką wspomagającą wprowadzenie w życie całej farmy robotów.

Mateusz Tajak: Zrobiłeś przepiękny most po kolejną funkcję, o której chciałem opowiedzieć, czyli utrzymanie i administracja. Jest to rola dla kogoś, kogo nazwałbym Junior RPA Developer, czyli osoby, która wie, jak tworzyć roboty, ale nie jest na tyle doświadczona, aby móc tworzyć zaawansowane, logiczne struktury robotów. Taka osoba zazwyczaj zaczyna od utrzymywania robotów, obsługiwania wyjątków i błędów pojawiających się w robotach. Dodatkowo zarządza orkiestracją robota, czyli planowaniem jego zadania. Z czasem pracownik nabiera doświadczenia i jest w stanie budować konkretne roboty oraz stać się RPA Deweloperem. Znowu, ta funkcja na początku bardzo często jest łączona z rolą RPA Developer, czyli osoby pracującej jako analityk, deweloper oraz ktoś, kto się zajmuje utrzymaniem. Tak naprawdę dopiero z czasem te funkcje są delegowane. Jeśli chodzi o kolejne role i tego, jak powinno wyglądać ich seniority, to jest to temat dość obszerny, najlepiej na osobny podcast. Na pewno wrócimy do tego tematu. Natomiast jest jeszcze jedna bardzo ważna rola w organizacji, o której mówią wszyscy producenci rozwiązań RPA, czyli funkcja Citizen Developer. W świecie hiper automatyzacji bardzo dużo mówi się o tym, żeby demokratyzować dostęp do automatyzacji. Oznacza to tyle, żeby pozwolić każdemu pracownikowi organizacji zostać deweloperem i tworzyć automatyzacje. Citizen Developer  jest zatem twórcą automatyzacji, który pracuje na przykład na stanowisku księgowego, ale ma podstawowe szkolenie i jest w stanie tworzyć proste automatyzacje, które będą działać na jego komputerze. I to jest już taki idealny świat...

Sebastian Grzesik: No właśnie. Jak bardzo on jest idealny?

Mateusz Tajak: Tak, to jest bardzo idealny świat, w którym pracownicy sami tworzą automatyzacje. Sporo o tym mówi UIPath w stwierdzeniu, że „robot jest dla każdego pracownika”. Chodzi tutaj o to, aby każdy pracownik był przeszkolony, potrafił tworzyć automatyzacje czy chociaż dostrzegać obszary do automatyzacji. Natomiast jest to bardzo trudne zadanie, aby zbudować takie mocne centrum kompetencyjne w firmie.

Sebastian Grzesik: Brzmi to utopijnie. Jeśli mam wyłożyć kawę na ławę, to dla mnie brzmi to dość nierealnie.

Mateusz Tajak: Właśnie dlatego podkreślam, że jest to idealny świat, który wymaga lat pracy nad tym, aby organizacja stała się idealnym centrum rozwoju automatyzacji. Ale wymieniłem cztery obszary, na które powinniśmy zwrócić uwagę. Podsumowując, pozwolę jeszcze raz je wymienić. Chodzi tutaj o to, że kiedy już zdecydujemy się na automatyzację, to powinniśmy sobie odpowiedzieć na pytanie, czy chcemy ją wdrażać z firmą zewnętrzną, budować wewnętrzne kompetencje, a może najlepiej wybrać hybrydę, w której częściowo będziemy budować kompetencje wewnętrznie, ale też będziemy korzystać z firmy zewnętrznej. Po drugie, powinniśmy sobie powiedzieć, jak automatyzacja powinna być umiejscowiona w naszej firmie: czy powinna podlegać pod dział IT, pod biznes, pod shared service, a może też jest jeszcze jakiś inny sposób, który będzie dopasowany do naszej specyficznej organizacji. Kolejną niezwykle ważną rzeczą jest zweryfikowanie, czy centrum kompetencji — jeśli się na takie zdecydujemy — ma być umiejscowione centralnie, czy ma się znajdować w każdym departamencie, czy ma być tryb mieszany, gdzie mamy centralne centrum kompetencji od całościowej automatyzacji, ale w każdym departamencie jest zespół wspierający procesy automatyzacji. Ta decyzja może jest nieco mniej istotna na początkowym etapie, ale warto, aby mieć ją z tyłu głowy i zastanowić się nad tą kwestią. Jeśli z kolei zastanawiamy się nad konkretnymi stanowiskami i tym, kogo zatrudnić w pierwszej kolejności, to, przy założeniu, że zostanie zatrudniony RPA Developer odpowiedzialny za wszystko, to jednak powinniśmy znaleźć osobę, która będzie skierowana nieco bardziej na aspekt biznesowy. Ważne też, żeby była, można powiedzieć, proxy między naszą firmą a firmą, która będzie dostarczać robotyzację. W dalszej kolejności powinniśmy się skupić na deweloperze, który będzie w stanie wdrożyć automatyzację oraz na kimś od zarządzania i utrzymania automatyzacji. Może to być osoba pełniąca funkcję Junior RPA Deweloper, który w przyszłości z tego stanowiska awansuje na RPA Dewelopera z zadaniem rozwijania poszczególnych rozwiązań. Jeśli się uda dojść do — jak to nazwałeś — utopijnego świata, to możemy szukać Citizen Deweloperów, którzy będa propagować automatyzację w całej organizacji.

Sebastian Grzesik: Bardzo dziękuję za to podsumowanie. Wszystkim pasjonatom automatyzacji życzymy wielu sukcesów, bo tam sky is the limit. Trzymamy kciuki, za wszystkie projekty RPA, które dzieją się gdzieś na świecie. I do usłyszenia w następnym odcinku.

Mateusz Tajak: Dodam jeszcze, że jeżeli mielibyście jakieś pytania, to możecie się z nami swobodnie skontaktować, ocenić nasz podcast albo udostępnić — pomoże nam to docierać do kolejnych osób. Również dziękuję za rozmowę. Życzę Wam wszystkiego dobrego i do zobaczenia w kolejnym odcinku.

Sebastian Grzesik: Dzięki! Cześć.