5 największych błędów podczas wdrażania automatyzacji - Automation Talks #16

Kolejna odsłona Automation Talks! Mateusz i Sebastian wzięli na tapet 5 podstawowych błędów, z którymi spotykają się podczas wdrażania automatyzacji. Automatyzowanie nie tych procesów, które powinniśmy, brak zaangażowania działu IT czy strategii automatyzacji, to tylko część z wielu błędów. Słuchając ten odcinek, dowiesz się o kilku innych.

Więcej na temat Robotic Process Automation dowiesz się z naszego bloga

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 "#16 5 największych błędów podczas wdrażania automatyzacji" on Spreaker.

Transkrypcja

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

Sebastian Grzesik: Cześć, z tej strony Sebastian Grzesik.

Mateusz Tajak: Witamy Was bardzo serdecznie w szesnastym odcinku podcastu Automation Talks. Dzisiaj bierzemy na tapet temat związany z najczęstszymi błędami, jakie spotykamy we wdrażaniu automatyzacji. Pracując z klientami, dostrzegamy jak wiele jest popełnianych pomyłek logicznych opartych na niewłaściwych założeniach. Te wszystkie gafy sprawiają, że wdrożenie automatyzacji nie kończy się sukcesem. Wręcz przeciwnie, cały proces może się okazać całkiem dużą porażką, której skutkiem będzie zrażenie się do automatyzacji i poczucie, że tego typu działania nie mają sensu, bo są duże, wymagające i skomplikowane. Dlatego też razem z Sebastianem przygotowaliśmy pięć najczęściej spotykanych sytuacji, których powinniśmy unikać w trakcie wdrażania procesów automatyzacji. Ich świadomość pozwoli zwiększyć prawdopodobieństwo odniesienia sukcesu wprowadzenia automatyzacji w organizacji.

Sebastianie, z Twojego doświadczenia, jak duży wpływ na powodzenie projektu informatycznego mają odpowiednio przygotowane założenia?

Sebastian Grzesik: Faktycznie przygotowane wcześniej założenia mają duży wpływ na powodzenie lub niepowodzenie projektu informatycznego. Może nie zdarza się to często, jednak mogę potwierdzić, że jeśli fundamenty inicjatywy zostaną oparte na błędnych założeniach, to projekt może być skazany na porażkę, a entuzjazm ludzi szybko zgaśnie. Kolokwialnie mówiąc, w ten sposób można zawalić projekt. Sądzę, że wnioski, do których doszliśmy w czasie realizacji różnych projektów, mogą być bardzo pouczające dla naszych słuchaczy. Co prawda, nasze konkluzje dla jednych mogą okazać się oczywiste, ale dla innych nie. Na pewno warto je znać i się ich wystrzegać w momencie rozpoczęcia jakiegokolwiek projektu związanego z automatyzacją.

Mateusz Tajak: Zacznijmy zatem od pierwszego elementu, który wyszczególniliśmy w naszych notatkach, a którym chcemy się podzielić. Pozwól, że rozpocznę. Pierwszym błędnym założeniem jest to, że kiedy myślimy o wdrożeniu automatyzacji za pomocą technologii Robotic Process Automation, to wydaje nam się, że po wprowadzeniu tej automatyzacji procesy od razu zaczną działać automatycznie. Jest to błędna konkluzja, bo robotyzacja zazwyczaj tylko wspiera pewne działania, a nie sprawia, że procesy w danej firmie po prostu toczą się automatycznie, bez jakiegokolwiek nadzoru. A bardzo często właśnie takie są oczekiwania naszych klientów, prawda? Wychodzi się z założenia typu: „kupmy Robotic Process Automation, weźmy firmę wdrożeniową do uruchomienia rozwiązania i przygotowania robotów do realizacji procesów, a potem już nie dotykajmy tego rozwiązania i załóżmy, że w firmie wszystko będzie się wydarzać bez błędów, co magicznie doprowadzi do obniżenia kosztów”.

Sebastian Grzesik: Takie podejście porównałbym do sytuacji z czasów pandemii, kiedy wszyscy zastanawiali się nad e-commerce i sposobach wejścia na ten rynek z przekonaniem, że sprzedaż online rozwiąże wszystkie problemy związane z tradycyjną sprzedażą. Oczywiście można pójść do sklepu i kupić oprogramowanie e-commerce jednej z popularniejszych platform (np. Shopify, Shopper, czy Magento), które leży na półce. Jednak zakup platformy niekoniecznie sprawia, że w firmie zwiększy się sprzedaż. A jeśli właśnie obroty się nie poprawiają, to od razu uznaje się, że abo został zakupiony zły produkt, albo niewłaściwa firma uruchomiła oprogramowanie.

Mateusz Tajak: W sumie to dość często zderzamy się z przekonaniem, że wdrożenie systemu spowoduje, że pewne rzeczy będą działy się same. Trafiłem na ciekawy przykład związany z wprowadzeniem bankomatów w Stanach Zjednoczonych. Kiedy w 1970 roku rozpoczęto rozwijanie technologii używanej w bankomatach, wszyscy myśleli, że wprowadzenie tych urządzeń spowoduje brak zapotrzebowania na oddziały bankowe. Zakładano wówczas, że postawienie maszyny sprawi, że ludzie przestaną korzystać z usług kasjera, przez co będzie można zamykać oddziały. Doświadczenie pokazało kompletnie odwrotną sytuację. Wręcz trzeba było otwierać więcej oddziałów w miejscach, gdzie stały bankomaty, bo przy okazji wybierania pieniędzy ludzie chcieli załatwić też inne kwestie, które można zrobić jedynie w oddziale. Dzięki automatyzacji banki zwiększyły ilość klientów. I to jest raczej pożądany skutek — dzięki automatyzacji wzrasta zatrudnienie w danej firmie, a także rośnie ilość klientów. To chyba jest dobry przykład, czyż nie?

Sebastian Grzesik: Właściwie to mam kontrprzykład z własnego doświadczenia. Sam kiedyś byłem ofiarą zbliżonej sytuacji. Zauważmy, że powstaje coraz więcej placówek bankowych, w których można załatwić wiele różnych spraw: wziąć kredyt, otworzyć albo zamknąć konto, czy przeprowadzić mnóstwo innych operacji. Jedyne, czego brakuje to kasy — w oddziałach nie ma gotówki. Dla mnie była to abstrakcyjna sytuacja, zwłaszcza kiedy przychodzę do banku, w którym nie ma tego, co tam powinno być w depozycie, czyli pieniędzy. Odwiedzany przeze mnie oddział nie był zamykany, ale jest doskonałym przykładem zmiany standardów. Teraz mamy wpłatomaty, bankomaty i inne formy typu self-service. Tak, technologia potrafi strasznie namieszać.

Mateusz Tajak: Podsumowując ten punkt, pierwszym dużym błędem przy wdrażaniu automatyzacji jest założenie, że rzeczy zaczną się dziać same, bez naszego udziału. A jaki jest drugi punkt na naszej liście?

Sebastian Grzesik: Tutaj porozmawiamy o nieco szerszym kontekście, bo chciałem pokazać przykład błędu nawiązującego do tego, że wdrażając automatyzację procesów biznesowych, oczekujemy, że te procesy równolegle się naprawią. Jest to podejście, które możemy porównać ze złymi praktykami rozwoju kodu czy sprzedawaniem produktów lub usług w niewłaściwy sposób. Jeśli coś jest sprzedawane źle, to zatrudnienie większej ilości sprzedawców nie pomoże…

Mateusz Tajak: Wtedy firma po prostu ma więcej sprzedawców sprzedających w niewłaściwy sposób.

Sebastian Grzesik: Dokładnie tak. To samo dzieje się w świecie automatyzacji. Samym mechanizmem skalowania nie jesteśmy w stanie osiągnąć lepszego efektu pod kątem biznesowym. Zdecydowanie lepszą praktyką jest rekoncyliacja procesu, ustawienie lub poprawienie go z wykorzystaniem narzędzi, które są aktualnie używane. Dopiero wtedy można go skalować przy pomocy wybranej formy automatyzacji, czy to RPA, czy workflow, czy połączenia obu metod. Niemniej jednak nie możemy zakładać, że automatyzacja jest procesem poprawy. Z jej pomocą coś może działać lepiej, ale tylko wtedy, kiedy sam proces jest dobrze ułożony. Jeśli jesteśmy w sytuacji rozpoczynania projektu automatyzacji, to w pierwszej kolejności powinniśmy zautomatyzować te procesy, które uważamy za relatywnie optymalne. Z kolei głównym motywatorem do działań powinno być przyspieszenie ich wykonania czy chęć zdjęcia odpowiedzialności ich wykonania z osób, które je realizują i dodatkowo poświęcają na nie czas. Jeśli ktoś wprowadza automatyzację, żeby naprawić proces, to może się spotkać z niepowodzeniem. Myślę, że to jest jedno z naszych doświadczeń, które widzimy w realizowanych projektach. Obserwujemy też, że nie opłaca się skalować zepsutych procesów. Opłaca się za to skalować rzeczy, które działają, bo tylko wtedy otrzymujemy efekt compound interest.

Mateusz Tajak: Spotykam się dokładnie z takimi samymi sytuacjami. Trafiłem nawet na stwierdzenie influencera ze świata automatyzacji, który powiedział, że „automatyzowanie chaosu sprawia, że wciąż mamy chaos, tylko działający automatycznie”. Bardzo często spotykam się z takimi sytuacjami w prowadzonych projektach. Klienci często upierają się, że mają odpowiednie procesy do automatyzacji. Jednak kiedy spotykamy się na warsztatach i rozmawiamy o danym procesie, to w trakcie zadawania pytań mających na celu lepsze poznanie i zrozumienie procesu oraz biznesu klienta, okazuje się, że w tym procesie są błędy, które nawet sam klient dostrzega w trakcie rozmowy z nami. Wówczas klient próbuje ten proces usprawniać i zmieniać na papierze, zapominając o tym, że ludzie wykonują go w inny sposób. To jest bardzo duży problem, ponieważ wdrażanie automatyzacji generuje przestrzeń na poprawienie pewnych rzeczy, natomiast klienci bardzo często nie są wówczas świadomi, że automatyzacja jest odwzorowaniem procesów dokładnie w taki sposób, w jaki są one realizowane przez pracowników z tą różnicą, że są przystosowywane do wykonywania przez maszyny. Ważne jest, abyśmy pamiętali, że automatyzacja nie spowoduje, że procesy zaczną działać lepiej. One będą działać bardziej efektywnie tylko w momencie, kiedy mają sens biznesowy. A automatyzacja nie wpływa na sens biznesowy procesu.

Sebastian Grzesik: Dodałbym jeden mały wyjątek od tej reguły. Mam tutaj na myśli sytuacje, w których chcemy obniżyć ilość ludzkich błędów. W takich przypadkach automatyzujemy proces biznesowy, będąc świadomym ilości popełnianych przez ludzi błędów. Jeśli jesteśmy w stanie odpowiednio zautomatyzować proces oraz opisać go regułami i zasadami, to zwiększa się możliwość wyeliminowania pomyłek. Zwłaszcza tych, które są popełniane, kiedy ludzie są zmęczeni albo niedokładnie klikają klawisze na klawiaturze. Myślę, że podany przeze mnie przykład procesu, który chcemy wyskalować zarówno pod względem ilości, jak i poprawy jego jakości, jest wyjątkiem w sytuacjach opisywanych w ramach drugiego najczęstszego błędu popełnionego przy automatyzacji procesów biznesowych. To jest ta gwiazdka, która umożliwia poprawę zarówno rezultatu biznesowego, jak i wyskalowanie procesu w czasie lub częstotliwości.

Mateusz Tajak: Powiedziałbym, że są to jednak dość rzadkie przypadki. Raczej chcemy zautomatyzować procesy, które są w miarę optymalne. Niemniej jednak wspomniałeś istotny element, że automatyzacja nie zawsze musi być realizowana tylko po to, aby osiągnąć korzyści finansowe. Inną zaletą tych działań może być redukcja błędów. To nie jest bezpośrednia korzyść finansowa, jednak również przekłada się na bilans końcowy. Co więcej, wiele rzeczy związanych z automatyzacją możemy traktować jako inwestycję. Przykładem może być fakt, że robot szybciej odpowie na zapytanie klientów, dzięki czemu poprawia się jakość obsługi.

Sebastian Grzesik: I tutaj mówimy zarówno o klientach zewnętrznych, jak i wewnętrznych.

Mateusz Tajak: Dokładnie tak. Roboty mogą szybciej obsługiwać zgłoszenia reklamacyjne, dzięki czemu osoby kupujące w naszych sklepach lub korzystające z naszych usług lepiej odbierają markę. Co za tym idzie, automatyzację można traktować jako inwestycję w pozytywny wizerunek firmy. Podsumowując ten punkt, musimy powiedzieć, że dużym błędem w zrozumieniu automatyzacji jest założenie, że automatyzacja poprawia procesy. Ona może jedynie przyspieszyć i wykonać pewne czynności automatycznie, ale w podobny sposób, w jaki wykonywał je człowiek. Poprawianie procesów jest zupełnie innym tematem, który często jest niezwiązany z technologią.

Przejdę do kolejnego dużego błędu, który sprawia, że projekty związane z automatyzacją się nie udają. Chodzi tutaj o kwestię automatyzowania niewłaściwych rzeczy. Wybór procesu do automatyzacji jest kompetencją wymagającą zestawu wiedzy i doświadczenia, które pozwalają ocenić, czy dany proces jest atrakcyjny dla automatyzacji. Kiedy prosimy klientów o zarysowanie procesów pojawiających się w ich organizacjach, bardzo często spotykamy się z tym, że są nam przedstawiane procesy z myślą o tym, jak robot mógłby je wykonywać. Właśnie takich sytuacji wolimy unikać, bo chcemy, aby użytkownicy biznesowi mówili o procesach, w taki sposób, w jaki oni je wykonują i jak je rozumieją. Pracując z klientami zazwyczaj działamy tak, że rozumiejąc działania robotów i innych dostępnych technologii automatyzacji oraz słuchając o procesach w danej firmie, niemal od razu potrafimy wybrać rzeczy nierentowne z punktu widzenia automatyzacji. Chodzi tutaj o te zadania, które mogą być frustrujące dla pracowników albo takie, które „zjadają” dwa razy w miesiącu jedynie 15 minut pracy. O ile automatyzacja niektórych procesów nie jest kosztowna czy skomplikowana, to już na etapie ich weryfikacji możemy ocenić, czy są one opłacalne i znacząco wpływają na realizację całościowej strategii automatyzacji w firmie. W związku z powyższym automatyzacja właściwych rzeczy oraz świadome podejście do selekcji procesów i obszarów do automatyzacji w firmie, a także do wyboru odpowiedniej technologii do automatyzacji tych obszarów jest kluczowe. Tutaj musimy pamiętać też o tym, że procesy mogą być automatyzowane na różne sposoby, ale z podobnym rezultatem. Jednak szersze spojrzenie może sprawić, że pierwszy wybór niekoniecznie będzie tym najlepszym. Czasem można mieć poczucie, że coś mogło być lepiej zrobione, a jest zrobione gorzej, bo wybrano niewłaściwą technologię. Sebastianie, masz jeszcze inne spostrzeżenia w kwestii automatyzacji niewłaściwych procesów?

Sebastian Grzesik: Zastanawiam się nad przykładem procesów, które warto automatyzować i procesów, których zdecydowanie nie opłaca się automatyzować…

Mateusz Tajak: Mogę podać przykład złego doboru procesu do automatyzacji. Organizacje często zakładają, że Robotic Process Automation zostanie wykorzystany do automatyzacji procesu dokładnie w taki sam sposób, w jaki robi to człowiek. A tak naprawdę robot może to robić inaczej, wykorzystując technologię związaną z integracją danych dostępnych w bazach. Robot może trochę inaczej „pamiętać” pewne elementy, kolumny lub wiersze z Excela, czego człowiek nie jest w stanie zrobić. Dlatego bardzo często źle podchodzimy do automatyzacji. Jeszcze wracając do wyboru procesów do automatyzacji, to często spotykam się z tym że wybierane są procesy, które na początku wymagają interakcji z osobą z zewnątrz, na której nie możemy wymóc realizacji konkretnego procesu. Raczej nie możemy przedstawić klientom procesów i poprosić ich o to, aby postępowali zgodnie z ustalonymi założeniami. Nie powinniśmy też na przykład komunikować osobom z zewnątrz, aby odpowiadali na maila zgodnie z określonym szablonem. Wdrożenie automatyzacji w takich procesach jest bardzo trudne, a klienci bardzo często właśnie je wybierają na początku. Dla nich to też są procesy z back office i wydają się sensownym wyborem. Jednak szczegół związany z interakcją z klientem zewnętrznym wpływa na to, że one wcale nie są tymi najlepszymi do automatyzacji, przynajmniej na początku.

Sebastian Grzesik: A gdybyśmy mieli podać przykład procesu, który jest jednym z częściej wybieranych do automatyzacji i stanowi potencjalną zachętę do robotyzacji z dużymi możliwościami usprawnienia, to które obszary lub działy w organizacji są Twoim zdaniem najlepszymi? Gdzie powinno się rozpocząć jakiekolwiek działania związane z automatyzacją?

Mateusz Tajak: Z mojego doświadczenia wynika, że obszary finansowe, kadrowe i działy logistyki są tymi, które w wielu firmach posiadają odpowiednie procesy do automatyzacji. W tych działach można znaleźć przestrzeń do stworzenia tak zwanego proof of concept z tego względu, że właśnie te obszary w większości firm są bardzo dobrze poukładane. Wynika to z tego, że ludzie pracujący w finansach czy logistyce bardzo często działają według procedur narzuconych na przykład przez ustawodawcę. Oni raczej nie mogą naginać pewnych zasad. Na przykład księgowanie czy wprowadzanie faktur jest bardzo dokładnie opisanym procesem. W związku z powyższym księgowość czy finanse to właśnie te obszary, w których znajdujemy najlepsze do automatyzacji procesy. Poza tym osoby pracujące w tych działach lepiej rozumieją kwestie związane z procesowym podejściem i realizacją pewnych sekwencji zadań. Z takimi osobami bardzo dobrze się pracuje przy automatyzacji, a co za tym idzie w tych działach łatwiej zaadaptować wdrożenie automatyzacji w firmie.

Sebastian Grzesik: Myślę, że możemy przejść do kolejnego elementu naszych lessons learned. Tutaj chciałbym powiedzieć o dwóch podejściach do błędu, z którym często się spotykamy. A mianowicie chodzi tutaj albo o brak zaangażowania działu IT w projekt RPA, albo o brak zaangażowania biznesu w działania działu IT.

Mateusz Tajak: Rozumiem, że chodzi Ci o jedną z dwóch sytuacji. Pierwsza jest wtedy, kiedy inicjatywa związana z Robotic Process Automation wychodzi oddolnie z działu IT. Druga sytuacja ma miejsce wtedy, kiedy dział IT otrzymuje jedynie zlecenie od kadry zarządzającej, aby wdrożyć automatyzację. Czasem występuje jeszcze trzecia sytuacja, kiedy działy biznesowe decydują się na wdrożenie automatyzacji bez zaangażowania zespołu IT…

Sebastian Grzesik: Dokładnie tak. W takich sytuacjach grzech jest ciężki po dwóch  stronach. Jeżeli biznesowa część organizacji widzi straty czasu lub zasobów, o których słyszymy w metodologii lean albo czytamy w artykułach Mateusza, a potem decyduje się na wdrożenie automatyzacji za pomocą rozwiązań IT, to inicjatywa przychodzi ze strony biznesowej. Wówczas chęć wprowadzenia zmian ma zazwyczaj dobre uzasadnienie. Działy biznesowe w firmie zazwyczaj chcą zredukować czas spędzany na zadaniach, poprawić efektywność, zmniejszyć frustrację ludzi związaną z wykonywaniem powtarzalnych zadań, otrzymać lepszy rezultat biznesowy albo zminimalizować niezadowolenie klientów związane z czasem oczekiwania na odpowiedź związaną z reklamacją. W takim przypadku — przy założeniu, że dział biznesowy jest zaawansowany i dojrzały — naturalną drogą jest albo znalezienie partnera, albo samemu spróbować zadziałać w inicjatywach związanych z RPA. Do tego tanga trzeba jednak dwojga, bo raczej działamy w świecie technologii. Jeżeli zatem na odpowiednio wczesnym etapie nie zaangażujemy działu IT lub przynajmniej managera IT, to może się okazać, że projekt po prostu się nie uda. Tutaj powodem niepowodzenia może być coś innego niż fakt, że inicjatywa jest zła albo projekt jest nieodpowiednio zdefiniowany. Przyczyną porażki może wówczas być po prostu zła egzekucja założeń wynikająca z tego, że do projektu nie został zaangażowany dział IT i polegliśmy technicznie. Drugim powodem porażki może być zaangażowanie zespołu IT w  zupełnie niewystarczającym wymiarze czasowym, bo pracownicy są skupieni na innych zadaniach i priorytetach spółki. Możemy też spotkać się z sytuacją, że nawet jeśli zespół IT znajdzie czas na wdrożenie automatyzacji, to i tak jest to go za mało, aby odpowiednio się przygotować i działać efektywnie. Jeśli do tego tanga nie ma dwojga, to projekt po prostu może nie wyjść. Zazwyczaj takie sytuacje się zdarzają wtedy, kiedy IT nie angażuje się w wystarczająco dużym stopniu w projekt, a biznes jest niezadowolony z prowadzonych działań i dochodzi do wniosku, że Business Intelligence jest zły. Tutaj jest też druga strona medalu w momencie, kiedy CTO albo manager IT rozpoczyna inicjatywę w celu zoptymalizowania wszystkiego, co się da. Jak tutaj może pomóc RPA? Tak naprawdę Robotic Process Automation jest dość kompleksowym rozwiązaniem, które może wesprzeć pewne procesy na różnych warstwach. Nie ukrywajmy, że obecnie automatyzacja działa coraz bardziej kompleksowo: albo umożliwia integrację danych, albo łączy różne kropki wraz z Artificial Intelligence i Machine Learning.  Dzięki temu wszystkiemu wydaje się, że RPA jest super rozwiązaniem, które świetnie się wpasowuje w działania organizacji. Widząc same zalety automatyzacji, ktoś z działu IT może wpaść się na pomysł, żeby znaleźć proces do usprawnienia. Jednak wówczas dochodzi do paradoksu, że dział IT zajmuje się wyszukiwaniem procesów biznesowych. I znowu może pojawić się zagrożenie złej egzekucji projektu. Kiedy dział IT podejmuje inicjatywę i zaczyna działać, wykorzystując znajomość technologii albo zatrudniając RPA dewelopera, to proces wdrożenia automatyzacji także najprawdopodobniej się nie powiedzie ze względu na to, że na odpowiednio wczesnym etapie nie zostały zaangażowane osoby z części biznesowej, które potrafiłby wyjaśnić swoje problemy, przedstawiałyby frustracje albo wskazałyby obszary o największym potencjale zysków czy przewag wynikających z automatyzacji. Myślę, że to niedopasowanie zespołu technicznego z biznesowym jest czymś, co bardzo często się spotyka.

Mateusz Tajak: Wydaje mi się też, że ta kwestia jest związana ze specyfiką niektórych rozwiązań dla automatyzacji. Robotic Process Automation jest technologią, która w bardzo ograniczony sposób ingeruje w działania informatyczne, zwłaszcza w mniejszych firmach, gdzie RPA jest traktowane jako pewnego rodzaju usprawnienie i nowinkę w dziale technicznym. Tak naprawdę automatyzację możemy wdrożyć bez udziału osób pracujących w IT. Najprostszym rozwiązaniem może być sytuacja, kiedy pracownik działu finansów kupuje sobie robota, instaluje go na komputerze i działa bez dodatkowej integracji oprogramowania w centralnym środowisku IT w firmie. Tak naprawdę czasem nie jest potrzebne budowanie dużych serwerów. Jedynie trzeba stworzyć robota i samemu zautomatyzować codzienne czynności. W bardziej skomplikowanym środowisku, gdzie mamy robota nienadzorowanego, wciąż potrzebna jest tylko maszyna stworzona i skonfigurowana przez dział IT, ale niekoniecznie wymaga ona specjalistycznych dostępów do baz danych. W tym najprostszym scenariuszu robot potrzebuje jedynie dostępu do systemów w takim samym stopniu, w jakim korzysta z nich człowiek. W związku z powyższym wydaje mi się, że biznes nadal ma możliwość wdrażania automatyzacji bez udziału zespołu IT. Jednak popatrzmy jeszcze na tę sytuację z perspektywy działu technicznego w momencie, kiedy to oni są odpowiedzialni za wdrożenie robotyzacji. Wówczas, jak już wspomniałeś, najczęściej trzeba zatrudnić osobę odpowiedzialną za cały proces, która najpierw powinna przejść szereg szkoleń, a dopiero potem automatyzuje procesy. Jeśli taka osoba nie jest odpowiednio umocowana w organizacji i nie ma pozwolenia na to, aby wymagać od innych pracowników współpracy, zwłaszcza w przypadku, kiedy pracownicy nie czują potrzeby dodatkowych działań, to wdrożenie automatyzacji znowu się nie uda. W wyżej opisanej sytuacji osoba nie będzie w stanie odpowiednio zidentyfikować problemów wymagających działań, tym bardziej że przy takich działaniach są potrzebne zarówno kompetencje analityczne, jak i umiejętności związane z prowadzeniem projektów oraz weryfikowaniem sposobów działania procesów. To wszystko wymaga także współpracy z ludźmi z różnych działów i przekonywanie ich do tego, że automatyzacja będzie realnym wsparciem w codziennej pracy. Stąd bardzo ważne jest to, żeby IT współpracowało z biznesem. Istotne jest również to, żeby z góry, od osób decyzyjnych w organizacji, spływał przykład. No i osoby zaangażowane w RPA muszą być odpowiednio umocowane w organizacji. Ważne jest też to, żeby dział IT rozumiał, czym jest robotyzacja, wspierał jej rozwój oraz wiedział, że całość jest istotna dla biznesu. Z drugiej strony biznes powinien rozumieć, że IT może być ogromnym wsparciem przy wdrażaniu robotyzacji, a nie utrudnieniem (a czasem tak niestety bywa). Tak naprawdę dla części osób technicznych, zwłaszcza administratorów, Robotic Process Automation, jest dość prymitywną technologią w porównaniu do sposobów integracji skomplikowanych baz danych.

Sebastian Grzesik: Albo wyobrażenie o technologii RPA jest dla nich prymitywne. Często zdarza się też tak, że ludzie mają jakieś przekonanie, ale niekoniecznie coś wiedzą na dany temat. Czasem osoby techniczne postrzegają RPA jako zwykły klikacz graficzny…

Mateusz Tajak: Dokładnie tak. A my wiemy, że dzięki RPA można robić wiele rzeczy i wprowadzać zaawansowane automatyzacje. Oczywiście są też projekty automatyzacji, które wymagają zaangażowania IT. Tutaj mówię o wszelkiego rodzaju systemach workflow, które działają na wielu płaszczyznach w organizacji i trochę bardziej przenikają się z IT… Nie wchodząc jednak w szczegóły, podsumujmy ten punkt. Myślę, że dobrą konkluzją dla tej dyskusji jest stwierdzenie, że błędem jest albo nieangażowanie działu IT przez biznes, albo brak zaproszenia do współpracy osób technicznych przez biznes, albo nieodpowiednie umocowanie osób, które podjęły się automatyzacji procesów w organizacji.

Przejdę teraz do ostatniego punktu, który zapisaliśmy na naszej liście. Chodzi tutaj o brak strategii automatyzacji. To się może wydawać dość oczywiste, jednak powtórzymy raz jeszcze, że projekty RPA nie udają się dlatego, że nie mamy odpowiedniej strategii. Taki dokument powinien składać się z wszystkich punktów, o których powiedzieliśmy wcześniej w tym podcaście. Jeśli nie zastanowimy się nad tym, czy w ogóle mamy w firmie procesy do automatyzacji, to popełniamy pierwszy błąd, zakładając, że automatyzacja zrobi wszystko i dzięki niej poprawimy swoje sekwencje działań. Jeśli nie zastanowimy się nad tym, kto będzie odpowiedzialny za automatyzację, to popełnimy błąd w delegowaniu zadań albo do działu IT, albo do działu biznesowego. Jeśli nie będziemy wiedzieć, co powinno zostać zautomatyzowane, to tak naprawdę możemy popełnić błąd związany z tym, że po rozpoczęciu automatyzacji wszystko staje się miałkie. Bardzo często spotykamy się też z tym, że brak strategii utrudnia jej wdrożenie w momencie, kiedy inicjatywa wychodzi oddolnie. Chodzi tutaj o sytuacje, kiedy ktoś w firmie zdecydował się wdrożyć automatyzację, jednak nie jest to wpisane w strategię firmy na szerszą skalę. Wówczas automatyzacja rozpoczyna się od usprawniania pojedynczych zadań w ramach jednego zespołu. Pojawia się tak zwane shadow IT, gdzie ludzie wbrew ogólnym zasadom firmie usprawniają na różne sposoby swoje codzienne czynności. Z drugiej strony w takiej sytuacji nie ma szans na to, aby automatyzacja scalała organizację, weszła w różne obszary firmy i pokazała kompleksowy obraz funkcjonowania firmy. Dzięki strategii automatyzacji możemy zobaczyć, jak działają różne procesy w firmie oraz które z nich można połączyć czy automatyzować z wykorzystaniem odpowiedniej technologii. Tutaj tylko wyjaśnię, że strategię automatyzacji interpretuję jako dobrze zrozumiane przez kadrę zarządzającą w organizacji cele, jakie tak naprawdę powinny zostać osiągnięte za pośrednictwem wdrażanej  automatyzacji. Dobrze wyartykułowana strategia, którą może być chociażby powiedzeniem, że chcemy wdrożyć jednego robota w dziale finansów, jest już pewnego rodzaju świadomym działaniem. Wówczas wiemy, że jest zauważalny potencjał automatyzacji w firmie. Jeśli ta najmniejsza zmiana jest uzasadniona biznesowo, to już wprowadzamy pewną strategię. Najgorzej jest w momencie, kiedy pojawia się myśl: „Wdróżmy RPA! Kupmy robota, a potem dopiero będziemy się zastanawiać, co nim automatyzujemy”.

Sebastian Grzesik: I pojawia się pytanie: „co dalej będzie się działo?”. Czasem jest podejście typu: kupmy, włączmy i poczekajmy…

Mateusz Tajak: I to jest bardzo częsta sytuacja. Zwłaszcza w momentach, kiedy ktoś się zainteresował tematem RPA i innymi technologiami do automatyzacji. Wówczas bez zastanowienia kupuje tego typu rozwiązanie i po prostu zaczyna je uruchamiać… Potem jednak się okazuje, że to, co zostało zrobione, jest niezgodne z compliance i generalnie takich działań nie powinno być. Nawet może się zdarzyć tak, że klienci otrzymają maila od robota, którego treść jest niezgodna ze strategią sprzedaży i komunikacji z klientem. Właśnie przez takie działania projekty związane z robotyzacją kończą się niepowodzeniem. Tak to wygląda z mojej perspektywy.

Sebastian Grzesik: Dodałbym jeszcze jedną ważną rzecz odnośnie strategii. Chodzi o kierunek, w którym organizacja chce iść. Czasem trzeba świadomie stąpnąć i przyznać, że  widzimy niedoskonałości w naszej organizacji. Czasem trzeba otwarcie się przyznać, że w firmie jest wiele systemów legacy, a na integracji danych z tych systemów ludzie spędzają dość dużą ilość mało kreatywnych godzin o bardzo niskiej efektywności. Choć rezultaty tej pracy są w jakimś stopniu ważne dla organizacji, to nadal czas spędzany na tych zadaniach jest niewartościowy. Wówczas potrzebne jest postawienie śmiałej tezy, że tego typu działania powinny być zlikwidowane albo nawet permanentnie usprawnianie  w momencie wprowadzenia nowego systemu, który w przyszłości będzie systemem legacy uwzględnianym we wszystkich procesach w organizacji. Tym jest dla mnie świadoma strategia. Tutaj nie chodzi o myślenie tu i teraz, ale o określenie pewnego kierunku i standardu, za pomocą których tworzymy przewagę konkurencyjną i optymalizujemy koszty operacyjne, koszty pracy czy koszty wytwórcze. Uważam, że to jest ważny element strategii, bez którego trudno wdrożyć jakąkolwiek zmianę w firmie.

Mateusz Tajak: Ogólnie mówiąc, posiadanie strategii związanej z rozwijaniem IT w dzisiejszych czasach jest czymś niezwykle ważnym. Taki dokument może ułatwić zaplanowanie wdrożenia systemów oraz określenie, w jaki sposób te systemy powinny ze sobą współpracować. To jest szczególnie istotne, jeśli firma chce się dobrze rozwijać.

Myślę, że możemy teraz podsumować to, o czym dzisiaj rozmawialiśmy. Pozwolę sobie wymienić jeszcze raz najczęstsze błędy, które sprawiają, że implementacje automatyzacji kończą się porażką. Pierwszy punkt to założenie, że automatyzacja spowoduje, że wszystko nagle zacznie działać samo. Drugi błąd to założenie, że automatyzacja poprawia procesy wewnątrz organizacji. Trzeci — automatyzacja może być wdrażana w niewłaściwych obszarach. Czwarty błąd jest taki, że nie angażujemy w odpowiednim momencie albo działu IT, albo biznesu, w zależności od tego, skąd wychodzi inicjatywa automatyzacji. Ostatni punkt mówi o tym, że nie myślimy nad strategią automatyzacji, tylko rozpoczynamy projekt bez przemyślenia końcowych celów oraz tego, jaka jest wizja firmy na dalszy rozwój.

Drodzy słuchacze i drodzy widzowie, teraz jesteśmy ciekawi Waszych spostrzeżeń. Chcielibyśmy zapytać te osoby, które już miały przyjemność wdrażać automatyzację w firmie, czy rzeczywiście te pięć punktów jest kluczowe i czy któryś błąd zdarzył się u Was. Jeśli tak, to podzielcie się z nami swoimi doświadczeniami. Wówczas postaramy się rozszerzyć ten ranking błędów o dodatkowe elementy.

Dziękujemy za dzisiejsze spotkanie i do usłyszenia w kolejnym odcinku.

Sebastian Grzesik: Dzięki i do usłyszenia!