Jak wyceniać projekty RPA i zarządzać ich budżetem? - Automation Talks #12

W tym odcinku dowiesz się:

• jak podejść do budżetowania i rozliczania projektów RPA
• czym jest POC
• fixed price vs time and material?

Więcej na temat Robotic Process Automation dowiesz się z naszego bloga https://ggsitc.com/pl/blog.

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 "#12 Jak wycenić projekty RPA i zarządzać ich budżetem" on Spreaker.

Transkrypcja

Sebastian Grzesik: Witam wszystkich serdecznie, zwłaszcza Ciebie Mateuszu.

Mateusz Tajak: Cześć! Sebastianie, miło Cię widzieć po drugiej stronie mikrofonu. Witamy was w kolejnym odcinku Automation Talks. Dzisiaj na tapet bierzemy temat, który często pojawia się u osób, które już zdecydowały się na wykorzystywanie Robotic Process Automation w automatyzacji procesów biznesowych albo które są na etapie podjęcia tej ostatecznej decyzji, ale blokuje je bardzo ważny temat pojawiający się w każdym projekcie informatycznym. Chodzi tutaj o kwestię budżetu i odpowiedź na pytanie, ile będzie kosztowała implementacja systemu? Wydaje mi się, że to jest ważny temat w projektach IT, prawda? Spotykasz się z pytaniami związanymi z kosztami?

Sebastian Grzesik: Oczywiście! Myślę, że to naturalne zachowanie wynikające ze wzorców, na podstawie których ludzie podejmują decyzje, zwłaszcza zakupowe. Niezależnie od tego, co kupujemy — choć w projektach IT jest to szczególnie istotne — ważne jest dla nas to, kogo wybieramy do realizacji projektu i jakie zasady współpracy są określane na przykład w kontrakcie. Istotne jest też ustalenie, w jaki sposób podchodzimy do kwestii biznesowej i cenowej. Trzeba pamiętać, że system RPA jest formą inwestycji.

Mateusz Tajak: Dokładnie tak jest. Dzisiaj chcielibyśmy właśnie o tym porozmawiać i podpowiedzieć, w jaki sposób zabudżetować projekt informatyczny, którym jest automatyzacja procesów biznesowych z wykorzystaniem RPA w dłuższej perspektywie. Wyjaśnimy, dlaczego estymacja tego typu projektu jest nieco inna niż przy wdrożeniach podobnych projektów informatycznych. Zastanowimy się też, jak podejść do budżetowania oraz planowania wydatków, kiedy już projekt się rozpoczął, a przed nami jest dłuższa perspektywa działań związanych z automatyzacją. Opowiemy o dwóch modelach rozliczania, nad którymi warto się zastanowić. Zapraszamy Was zatem bardzo serdecznie i przechodzimy do tematu.

[2:42]

Sebastian Grzesik: Prawdopodobnie jednym z najważniejszych pytań, przed którym stoją nasi słuchacze, to te o sposób podejścia do kwestii kosztów. Na początku zadałbym jednak pytanie, czy szacowanie wydatków w ogóle ma sens. Poza tym wydaje mi się, że we wstępnej fazie każdego projektu — nie tylko IT, ale także w kontekście projektów związanych z automatyzacją — warto skonfrontować decyzję z zasobami dostępnymi w organizacji i sprawdzić, czy są one wystarczające do zrealizowania wcześniej określonego celu. Druga kwestia wymagająca zastanowienia, to odpowiedź na pytanie, w jaki sposób możemy podejść do konstruktywnego szacowania budżetu. We współpracy z naszymi klientami bardzo często zaczynamy działania od tych dwóch kroków, choć niekoniecznie jest to proste. Powodów jest wiele, jednak ten najbardziej podstawowy to taki, że projekty związane z automatyzacją i digitalizacją procesów biznesowych w konkretnych obszarach są zmienne. Standardowo spotykamy się tutaj z dwoma podejściami. Warto tutaj zaznaczyć, że w świecie konsumenckim jest ich nieco więcej, natomiast w kręgu zakupu usług IT są dwa standardowe podejścia do przygotowywania kontraktów i budżetów. Mówię tutaj o podejściu time and material oraz o koncepcji fixed price. W jednym i drugim przypadku można założyć pewną przestrzeń na szacunek kosztów, do czego bardzo zachęcamy.

Mateusz Tajak: Rzeczywiście mamy dwa główne podejścia, które już nazwałeś. Warto tutaj podkreślić, że te koncepty dotyczą elementu implementacyjnego: wdrożenia i programowania robotów. Tak naprawdę koszt wdrożenia RPA składa się z kilku elementów, o których zaraz powiem. Natomiast najpierw chciałbym jeszcze dołożyć cegiełkę do tego, co powiedziałeś i zwrócić uwagę na to, że projekty wdrożenia RPA bądź innych podobnych rozwiązań do automatyzacji cechują się tym, że one nie mają końca. Wdrożenie RPA jest ciągłym usprawnianiem procesów, które zachodzą w danej organizacji z wykorzystaniem konkretnej technologii. Bardzo często nasi klienci rozpoczynają program automatyzacji w firmie, natomiast nie zdają sobie sprawy, że ten proces jest inny na przykład od wdrożenia systemu ERP czy BI. Zazwyczaj nie ma jasno określonego momentu, w którym zostanie wyznaczony dzień uruchomienia systemu RPA czy odgórnego narzucenia, że od teraz cała firma zaczyna z niego korzystać.

Sebastian Grzesik: Bardzo podobnie jest w sytuacjach, kiedy mamy wychwycić różnice między projektem a produktem. Jeżeli mamy projekt, to wiemy, że powinniśmy określić jego czas, czyli początek i zakończenie, zakres oraz koszt. Natomiast kiedy mówimy o rozwoju produktu, to zdecydowanie nie powinniśmy mówić o końcu, tylko o procesie nieustannego doskonalenia.

Mateusz Tajak: Podobnie jest ze wdrożeniem lean w firmach produkcyjnych. Słyszałem kiedyś takie zadanie, że „lean się nie wdraża, lean się można stać”. To jest nieustanne poprawianie, identyfikowanie marnotrawstw i wprowadzanie usprawnień. Takie działania nigdy się nie kończą. Ze wdrożeniem automatyzacji jest podobnie. Wróćmy jednak do osoby, która w swojej organizacji chciałaby wprowadzić Robotic Process Automation. Wcześniej wspomniałem, że wdrożenie procesu składa się z dwóch części. Pierwsza z nich to oszacowanie kosztu oprogramowania RPA, co jesteśmy w stanie zaplanować w kontekście rocznych działań za pomocą wyceny jednego z partnerów, np. GGS IT. Natomiast większym problemem jest druga kwestia odnosząca się do oszacowania kosztów związanych z automatyzacją poszczególnych procesów z wykorzystaniem RPA. To jest zdecydowanie bardziej skomplikowane działanie. Aby przygotować rzetelną estymację, trzeba poznać wszystkie procesy. Aby poznać wszystkie procesy, musielibyśmy zrobić czasochłonną i kosztochłonną analizę. Jak zatem podejść do tego tematu, zwłaszcza na początku, kiedy jesteśmy przed fazą wdrożenia proof of concept, która dopiero potwierdzi koncepcję, że Robotic Process Automation ma sens w naszej organizacji?

[8:01]

Sebastian Grzesik: Powiedziałbym, że ścisłe przewidywanie budżetu, jaki powinien być przeznaczony na procesy automatyzacji, jest pewnego rodzaju utopią. Takie działanie jest podobne do przewidywania cen akcji na giełdzie za 6 czy 12 miesięcy. To jest po prostu niemożliwe. Tutaj tylko sprostuję, że te działania są abstrakcyjne nie dlatego, że estymacja jest niewykonalna, ale dlatego, że rozpoczęcie prac przez właścicieli biznesowych nad odpowiednimi szacunkami powoduje odkrycie kołdry, pod którą są widoczne pierwsze usprawnienia i automatyzacje. Jednak im więcej nad nimi pracujemy i budujemy doświadczenia w tym obszarze, tym bardziej otwierają się zupełnie inne zakładki, niż te, które były widoczne przy rozpoczęciu projektu. Z czasem jesteśmy dojrzalsi i podejmujemy inne decyzje. Jeżeli w kontrze do tych zmian pojawia się podpisany wcześniej kontrakt, to wyzwaniem będzie pogodzenie interesów wszystkich stron. W GGS IT staramy się unikać takiego rozwiązania i najczęściej odwodzimy klientów od przewidywania kosztów całkowitych. Wiele lat temu realizowano projekty IT z horyzontem pięciu, siedmiu czy dziesięciu lat. Dzisiaj odchodzimy od długoterminowego planowania, a bardziej skupiamy się na tym, co będzie za dzień, tydzień czy miesiąc, a nie za rok czy za dekadę. Podobnie jest z kontekstem kontraktów IT związanych z automatyzacją. Raczej nie wiemy, co będzie się działo w krótkim horyzoncie czasowym. Lepiej zatem przewidzieć wszystkie zmienne w elastyczny sposób, aby finalnie wspomagały proces automatyzacji, a nie utrudniały go.

Mateusz Tajak: Wspomniałeś o planowaniu w dłuższej perspektywie, więc warto tutaj powiedzieć, że to odnosi się do modelu fixed price, który bardzo często jeszcze funkcjonuje w większości organizacji.

Sebastian Grzesik: Nawet sami jeszcze uczestniczymy w takich kontraktach...

Mateusz Tajak: Ten model bazuje na bardzo oczywistym podejściu, który wcześniej wyjaśniłeś. Chodzi tutaj o to, że jeżeli coś kupujemy, to chcemy wiedzieć, ile cały zakup będzie kosztować. Automatyczną reakcją jest poproszenie o ofertę na wdrożenie robotyzacji i automatyzację określonej liczby procesów w perspektywie roku. Tak naprawdę jeszcze nie wiemy, jak procesy będą automatyzowane, ale już prosimy o przygotowanie oferty. To jest tak zwana oferta fixed price, która wymaga analizy i dokonania pewnych sztywnych założeń.

Sebastian Grzesik: Dodałbym tutaj jeszcze, że najczęściej w ramach ofert fixed price mamy formę dokumentacji, która opisuje, kiedy dany projekt zostanie zrealizowany, w jakim kształcie i harmonogramie oraz z jakim konkretnym rezultatem zostanie zakończony. Najczęściej spotykamy się z tym że do oferty dołączony jest opis funkcjonalny, dokumentacja techniczna i kryteria sukcesu. To wszystko brzmi świetnie w początkowej fazie projektu, bo od razu wiemy, co kupujemy, od kogo, za ile i w jakim horyzoncie czasowym. Jest to sytuacja idealna. Z tego rodzaju kontraktu mogą jednak wynikać trudności, zwłaszcza w momencie, kiedy zmienia się charakter biznesu, uwarunkowania środowiskowe, czy pojawia się nowa regulacja zarządcza lub prawna. To są momenty krytyczne dla takiego rodzaju projektu. Z drugiej strony, jest to projekt bezpieczny i przewidywalny. Jesteśmy w stanie doskonale określić koszt, ramy czasowe oraz finalny rezultat działań.

[12:30]

Mateusz Tajak: Powiedziałeś o jednej, bardzo dużej zalecie, czyli o bezpieczeństwie. Natomiast warto też podkreślić, że w takim podejściu klient ma mniejszy wpływ na to, co zostanie finalnie dostarczone. Najczęściej zamawiamy coś, co na początku jest trudne do wyobrażenia i zdarza się, że w momencie oddania projektu, kiedy ludzie zaczynają pracować na danych narzędziach, zapalają się lampki. Pracownicy dochodzą do wniosku, że pewne rozwiązania mogłyby wyglądać inaczej i wypadałoby je zmienić. Jednak w dokumentacji wszystko było inaczej opisane, co oznacza, że modyfikacje wymagają ponoszenia kolejnych kosztów. To są tak zwane change request’y, które mogą być realizowane w ramach dostarczanych projektów. Na drugim końcu skali mamy podejście time and material, które charakteryzuje się tym, że został jedynie wyznaczony kierunek działań oraz oszacowany budżet, którym możemy dysponować. Jednak niekoniecznie wiemy, co w ramach tego budżetu dokładnie powstanie. Wspólnie z partnerem, z którym zaczynamy działania, planujemy zadania i skupiamy się na tym, żeby w krótkim czasie dostarczyć wartość biznesową dla firmy. Może to być automatyzacja pojedynczego procesu albo nawet tylko jego części. Chodzi o to, aby przekazać go do biznesu i zweryfikować jego działanie, a potem ewentualnie usprawnić. Na tej podstawie można też poprawiać kierunek działań, który został wcześniej wyznaczony. W tym podejściu chodzi o to, aby w krótkich odcinkach czasu upewniać się, czy podążamy właściwą drogą, czy może powinniśmy coś zmienić w naszych dotychczasowych działaniach. Jakie są plusy i minusy takiego podejścia?

Sebastian Grzesik: Pierwszą zaletą jest czas rozpoczęcia takiego projektu. Moment, w którym zaczyna się prace nad developmentem w oparciu o wstępnie rozpoznane środowisko pracy, nie jest bez znaczenia. Żyjemy w czasach dynamicznej i ciągłej zmiany na przykład uwarunkowań prawnych czy biznesowych, co oznacza, że moment startu może mieć niebagatelne znaczenie. Z jednej strony może być przewagą konkurencyjną, a z drugiej może sprawić, że zostaniemy w tyle na tle konkurencji. W modelu time and material start jest niemalże natychmiastowy.

Mateusz Tajak: Porównując do modelu fixed price, przy podejściu time and material nie musimy wykonywać wstępnych analiz, prawda?

Sebastian Grzesik: Analizy i tak są wykonywane w jakimś stopniu, ale nie są one przeprowadzane na tak szczegółowym poziomie, aby określać deliverables i milestones. Wszystkie elementy określone w kontrakcie przez dział prawny czy zakupów są bardzo pożądane, więc analiza jest robiona w każdym przypadku. Jednak niezawsze jest to głęboko sformalizowane. Czasem możemy pójść drogą na skróty, które jest możliwe w podejściu agile.

Mateusz Tajak: W teorii tak to wygląda, natomiast w projektach, z którymi się spotykamy, to nie jest ani czarne, ani białe. Zdecydowanie częściej zdarzają się projekty, które są blokowane. Klient chce jednak już na początku wiedzieć, co zostanie dostarczone w ramach usługi i produktu, który kupuje. Natomiast w trakcie realizowania projektu pojawiają się elementy zwinnego podejścia, czyli zmiany i kompromisy powodujące często nieporozumienia projektowe. To, co staramy się przekazywać klientom, to spotkanie pośrodku. Które koszty potrzebujemy tak naprawdę oszacować, aby nakreślić dłuższą perspektywę związaną z automatyzacją procesów biznesowych? Po pierwsze, potrzebujemy wyestymować koszty oprogramowania i infrastruktury. To jest dość proste zadanie, a wydatki możemy z łatwością oszacować na każdy kolejny rok funkcjonowania, przy odpowiednim założeniu wzrostu potrzeb związanych z automatyzacją. Znaczącymi kosztami są też te związane z samą automatyzacją procesów. To, co my rekomendujemy, to określenie uśrednionego przedziału, który pozwoli wyestymować koszt automatyzacji poszczególnych procesów. Nie chcę wchodzić w szczegóły, ale w tym polu możemy wyznaczyć kilka progów kosztowych, które będą określały poziom skomplikowania danego procesu. Po określeniu odpowiednich progów można je przełożyć na perspektywę roku oraz konkretną ilość procesów, jakie chcielibyśmy zautomatyzować. Dzięki temu zostanie wyznaczony budżet na automatyzację procesów. Możemy wówczas założyć, że automatyzacja jednego procesu zajmie miesiąc. Znając średni koszt automatyzacji procesu, możemy wyznaczyć roczny budżet na działania związane z automatyzacją. Znając roczny budżet na automatyzację, do kolejnego projektu związanego z automatyzacją możemy podejść w sposób zwinny. Wówczas nie musimy robić głębokiej analizy, tylko możemy działać w typowym podejściu i metodyce wdrażania rozwiązań RPA, czyli tworzyć mapy rozwiązań i podchodzić do kolejnych automatyzacji projektowo. Wówczas można dostarczać poszczególne projekty automatyzacji zgodnie z zaplanowanym cyklem i budżetem. Tak naprawdę możemy wówczas rozliczać budżet z perspektywy pojedynczych projektów. Zyskujemy komfort przesuwania budżetu. Jeśli w jednym procesie pojawiły się zaskakujące kwestie wymagające dodatkowych środków, to możemy znaleźć sposób na poświęcenie dodatkowego czasu oraz pieniędzy na przygotowanie analizy i stworzenie dodatkowej dokumentacji.

[19:05]

Sebastian Grzesik: Powiedziałbym, że są tutaj dwie strony barykady. Z jednej strony, przy projektach typu fixed price jedynym poziomem kontroli jest umowa, w której zapisane są wszystkie warunki. Jednak tutaj trzeba przewidzieć wszystko wstecz, aktualnie i w przód. Taka analiza musi być wykonana w konkretnym okresie, który został wyznaczony. Później jedynym poziomem kontroli jest oczekiwanie na dostarczenie wcześniej uzgodnionego rezultatu. Te rezultaty mogą być podzielone na mniejsze części, a umów może być więcej. W takiej sytuacji skala formalizmu rośnie wykładniczo. Z drugiej strony mamy metodę time and material z większymi możliwościami kontroli. Wówczas jesteś w stanie manewrować suwakiem startu projektu czy też budżetem projektu. Zwiększając lub zmniejszając nakłady finansowe oraz regulując moment rozpoczęcia w czasie, pojawia się możliwość kontroli dostarczania rezultatów automatyzacji w ciągu roku oraz weryfikacji ilość funkcjonalności czy działań optymalizacyjnych. Powiedziałbym, że mamy tutaj dwie ewentualności: albo możesz sterować samolotem, albo możesz wsiąść do samolotu rejsowego. To jest dla mnie największa różnica pomiędzy jednym a drugim podejściem. Wybór rozwiązania zależy od potrzeb organizacji.

Mateusz Tajak: Zgadzam się z Tobą w 100%. Natomiast warto wspomnieć o jednym procesie, który warto wycenić i szczegółowo zaplanować. Mówię tutaj o pierwszym procesie, który klienci nazywają proof of concept. Chodzi tutaj o działania potwierdzające koncepcję automatyzacji w danej firmie. To jest proces istotny, głównie z perspektywy zarządu, który patrzy na projekty automatyzacji w kontekście rezultatów. Warto zatem mieć dobrze skalkulowany koszt wdrożenia pierwszej automatyzacji. Dzięki temu będziemy mogli obliczyć ROI oraz zysk, jaki został osiągnięty dzięki automatyzacji. Tak naprawdę dopiero po pilotażowym wdrożeniu zbudżetowanym metodą fixed price, można wprowadzać elementy zwinnego podejścia. Zdajemy sobie sprawę, że nasi klienci niekoniecznie znają się na robotyzacji i nie są w stanie przewidzieć wielu rzeczy, które pojawiają się w trakcie robotyzacji. W związku z powyższym nawet w podejściu fixed price pozwalamy klientom na wprowadzanie zmian. Wierzymy, że takie działanie pomoże zaadoptować pierwsze procesy automatyzacji po to, żeby nauczyć się pracować w zwinnym podejściu w ujęciu długoterminowym. Tak naprawdę zmiana myślenia jest największą wartością dla klienta wykorzystującego robotyzację. Wówczas 100% budżetu może być przeznaczone na automatyzację i development, a nie na analizy, które i tak są wykonywane w trakcie tworzenia robotów i wdrażania automatyzacji.

[23:02]

Sebastian Grzesik: Dokładnie tak.

Mateusz Tajak: Przedstawiliśmy dwa podejścia, z którymi najczęściej się spotykamy. Drodzy słuchacze i czytelnicy, jeśli stoicie przed wyzwaniem zaplanowania budżetu oraz wycenienia działań związanych z robotyzacją w Waszej organizacji, to zapraszamy na bezpłatną konsultację. W ciągu 30-minutowej rozmowy możemy podpowiedzieć, czy dane rozwiązanie będzie najlepszym dla Waszej firmy. Aby umówić się na konsultację, możecie wejść na www.ggsitc.com, gdzie znajdziecie przycisk „bezpłatne konsultacje”. Zachęcamy Was do umówienia się na spotkanie, gdzie w niezobowiązujący sposób możemy rozwiać Wasze watpliwości albo odpowiedzieć na pytania związane z właściwym budżetowaniem i rozliczeniem projektu robotyzacji.

Sebastian Grzesik: W czasie spotkania można też zadawać Mateuszowi inne pytania...

Mateusz Tajak: Choć nie gwarantuję, że na wszystkie odpowiem. W każdym razie dziękuję za dzisiejsze spotkanie. Do usłyszenia w kolejnym odcinku Automation Talks.

Sebastian Grzesik: Cześć!