Mariusz Pultyn (CTO): Witam wszystkich serdecznie na naszym webinarze. Dzisiaj będziemy mówić o automatyzacji procesów z punktu widzenia zespołów IT i biznesu i o tym, czy automatyzacja jest zagrożeniem czy wsparciem dla zespołów IT. Razem ze mną jest dzisiaj Bartek Pietras.
Bartek Pietras (Head of IT): Dzień dobry.
Mariusz Pultyn: Na dzisiejszym webinarze będziemy mówić o relacji biznesu i IT, o tym, jak ona jest kluczowa dla tego, żeby projekty robotyzacyjne osiągały swoje cele i kończyły się sukcesem. Webinar nie będzie bardzo techniczny, chociaż sporo o technologii będziemy mówić. Przede wszystkim będzie się skupiał na tym, jak odnaleźć się w takim układzie biznes-IT i jak skutecznie wdrażać robotyzację.
Powiemy też sporo o tym, że do tego dwubiegunowego układu często dołączamy trzecią część, czyli dostawcę. Czyli kogoś, kto robi robotyzację w modelu outsourcingowym. My jesteśmy taką firmą, więc siłą rzeczy mamy w tym największe doświadczenie.
Dlaczego w ogóle mówimy o robotyzacji w kontekście IT? Wydaje się, że współczesne platformy robotyczne, które są low code albo no code, dają taką obietnicę, że osoby bez wykształcenia informatycznego mogą sobie same tworzyć roboty.
Bartek Pietras: To prawda, że te platformy poszły w taką stronę, że właściwie są low code, bo no code to pewnie nie. Praca z nimi jest przyjemna i tak producenci platform je sprzedają, i jest w tym dużo prawdy. Natomiast trzeba pamiętać, że te platformy to oprogramowanie jak każde inne, często skomplikowane w kontekście instalacji, ilości komponentów i tak dalej. Ono musi gdzieś działać, więc pierwsza rzecz, która przychodzi do głowy, to, że musimy mu zapewnić infrastrukturę. Te maszyny pod spodem, te komponenty muszą być patchowane, zarządzane, a wreszcie odpowiednio przygotowane pod względem bezpieczeństwa.
Te platformy, skoro są oprogramowaniem, też wymagają pracy, patchowania i aktualizacji. Same roboty też są oprogramowaniem. Mimo że piszemy czy tworzymy je w oparciu o narzędzia, które bardzo pomagają, żeby to było low code, to jednak ostatecznie to jest oprogramowanie. Jako oprogramowanie muszą spełniać development life cycle, czyli musimy się tym zająć. To jest taki sam temat jak przy każdym innym oprogramowaniu. Czyli musimy mieć zapewnioną np. kontrolę wersji. Trzeba wiedzieć, co i gdzie jest zainstalowane.
Mariusz Pultyn: Często mam takie sygnały, że dobrą alternatywą do automatyzacji są np. makra w Excelu. Wówczas pojawia się pierwsza najważniejsza rzecz, że te makra w Excelu rozprzestrzeniają się – przepraszam za kontekst – trochę jak wirus w organizacji.
Bartek Pietras: Tak, one żyją własnym życiem.
Mariusz Pultyn: W sytuacji, w której chcemy zmienić cokolwiek, bo sytuacja jest dynamiczna, a procesy i aplikacje się zmieniają, to często największym, najtrudniejszym dylematem jest to, skąd wziąć to makro w tej wersji, która rzeczywiście jest aktualnie obowiązująca. Jak rozumiem, w przypadku robotów musimy mieć system kontroli wersji, żeby tu i teraz każdy, kto chce zmienić cokolwiek w kodzie, mógł pobrać z jakiegoś repozytorium takiego robota, mimo że nawet pod spodem nie widać kodu. Natomiast one są fizycznie przechowywane.
Bartek Pietras: Tak, roboty się serializują do jakiegoś kodu. One są przyjemne w momencie, gdy je tworzymy, często w postaci diagramu albo uproszczonego pseudokodu, ale na koniec to i tak jest jakiś kod.
Wchodzimy w kilka tematów. Mamy change management, ale jeszcze wcześniej mamy środowiska. Najczęściej powinniśmy nie kodować na produkcji. Wiem, że mając makra możemy je tworzyć i uruchamiać, jak chcemy. Ale to jest software, powinniśmy mieć zapewnioną separację środowisk.
Mariusz Pultyn: Tu dosyć istotne jest to, że jeżeli te makra – jak już czepiamy się trochę tych makr – działają na jednym komputerze na wybranym zbiorze danych, to może zasięg tego makra nie jest tak bardzo kluczowy. Natomiast roboty z definicji powinny działać na najbardziej core’owych systemach, bo [te systemy] są zwykle najbardziej podatne na to, żeby je robotyzować, bo są stare, nieczęsto zmieniane, więc my dotykamy robotami czasami takich rzeczy jak księgowania, dane…
Bartek Pietras: Poważnych spraw.
Mariusz Pultyn: Tak, więc kodowanie w systemie produkcyjnym w konsekwencji może oznaczać, że stracimy po prostu pieniądze.
Bartek Pietras: Ja nie chcę słyszeć o tym (śmiech). Nie ma takiego tematu.
Następna rzecz, to jest to, o czym już trochę mówiłem. Mamy zmiany, ten software żyje. Roboty „żyją” z różnych powodów. „Żyją”, czyli musimy wykonać na nich zmiany, dlatego, że zmienia się proces biznesowy lub aplikacja, na której pracują, czy wreszcie – często nie bierzemy tego pod uwagę – platforma. Te platformy są zazwyczaj wstecznie kompatybilne. To jest fajnie zorganizowane, ale np. pojawia się feature, który dla nas jest istotny, i może powinniśmy go jednak w robocie użyć i skorzystać z jakiejś nowej rzeczy.
Ta zmiana to kolejny etap. Musimy zrobić review kodu czy robota. W pewnym momencie musimy po prostu zapewnić taką separację. To znaczy, że ktoś pisze robota, ktoś inny go sprawdza, a jeszcze ktoś inny go wdraża. Chodzi o nasze bezpieczeństwo. Musimy to robić profesjonalnie.
Mariusz Pultyn: Mówimy o korporacjach, dużych firmach, może czasami nawet i małych firmach, ale w tych firmach zwykle każde oprogramowanie podlega takiemu cyklowi. Nie ma żadnego dobrego powodu, dla którego robot, który będzie wykonywał automatycznie rzeczy w systemach, miałby temu nie podlegać.
Bartek Pietras: Tu dochodzimy do kolejnego etapu, którym są testy. Roboty musimy testować developersko. W klasycznym cyklu robot powinien zostać odebrany przez Klienta.
Ostatni temat to utrzymanie robotów. To pokazuje, że to jest oprogramowanie, być może tworzone w trochę inny sposób, umiejscowione w kontekście innej pracy, ale oprogramowanie.
Mariusz Pultyn: W najbardziej klasycznym przykładzie oprogramowanie buduje coś w rodzaju Centre of Excellence.
Bartek Pietras: Jest ileś ról, które muszą być obsadzone w takim Centre of Excellence. Bardzo podobnych do ról, które są w klasycznym software house. Będę używał polskich nazw, tak jest pewnie prościej.
Mamy analityków. Ktoś musi ten proces zrozumieć, opisać go w sposób biznesowy. Potrzebujemy inżynierów integracji z aplikacją, żeby zintegrować się z aplikacjami klienta.
Mariusz Pultyn: Jaka jest rola analityków? Tu pewnie jest przestrzeń do tego, żeby ludzie mieli trochę dzielone role. Najczęściej moglibyśmy powiedzieć, żeby analitykami były te osoby, które te procesy wykonują. Tylko tu jest ograniczenie, że specjalista od swojego procesu niekoniecznie będzie specjalistą od kolejnego procesu. Te osoby można pewnie przeszkolić do tego.
Bartek Pietras: One nabiorą doświadczenia po pewnym czasie.
Mariusz Pultyn: Ale na samym końcu potrzebny jest ktoś, kto tłumaczy logikę procesu na to, jak powinien być skonstruowany robot.
Bartek Pietras: Trzeba ocenić potencjał robotyzacji. Nie każdy proces nadaje się do tego, żeby go zautomatyzować. Doświadczenie pozwala znaleźć takie miejsca, w których można przerwać proces, czyli rozdzielić część robotyczną od manualnej. Proces nie musi być zrobiony end-to-end przez [robota]. Możemy go sobie ciekawie przearanżować i mieć część robotyczną i część manualną i zmieniać to.
Wracając do ról, mamy już inżyniera. Potrzebujemy kogoś, kto te roboty pisze, reviewuje, testuje. Chociaż pewnie jeszcze porozmawiamy o testach automatycznych, bo w pewnej skali to jest bardzo trudne do ogarnięcia, gdybyśmy mieli sobie poradzić z tym, żeby ręcznie testować roboty.
Potrzebujemy wreszcie kogoś – i tu bardziej wchodzimy w IT – jak architekta od platformy.
Mariusz Pultyn: Do tej pory mówiliśmy o rolach, które można zrekrutować pośród ludzi, którzy są gdzieś blisko back office’u. Oczywiście, po pewnym przeszkoleniu – mówiliśmy o platformach low code/no code – osoby, które były osobami biznesowymi, mogą, po pierwsze, nabyć biegłości w tym, by analizować więcej niż swój proces. Po drugie, mogą zacząć kodować roboty. To jest zupełnie w zasięgu ludzi, którzy nie mają wykształcenia informatycznego. My takich ludzi u nas nazywamy Pasterzami Robotów. Ale ciągle poruszamy się w kręgu ludzi, którzy nie są IT, nie mają backgroundu IT. Można sobie spokojnie wyobrazić, że nawet lepiej do ról analityczno-koderskich, jeśli chodzi o roboty, rekrutować ludzi, którzy nie mają wykształcenia informatycznego.
Ale gdybyśmy mieli tylko te osoby, to jest przepis na katastrofę. Pod tym wszystkim są twarde maszyny i twardy proces inżynierski.
Bartek Pietras: Tak, u nas mamy taki podział. Jest komórka, która nazywa się IT Excellence. To są doświadczenie inżynierowie z różnych dziedzin, sieciowych, infrastrukturalnych, ale także developerskich.
Mariusz Pultyn: W tym bazodanowych, bo elementem każdej pracowni jest baza danych.
Bartek Pietras: Tak jest. Od tego w mojej opinii nie da się uciec. Można próbować i to jest super, bo nabieramy pewnego doświadczenia. Rola Pasterza czy developera, nomenklatura może jest nieistotna, jest do obsadzenia przez osobę [bez wykształcenia informatycznego], nawet [tak jest] lepiej czasami. Developerzy są kształceni i mają manierę często do wyszukiwania zupełnie nowych, bardzo ciekawych rozwiązań.
W przypadku naszej dużej skali i wymienności Pasterzy trzeba też jeszcze utrzymywać roboty. Nie tylko utrzymywać w kontekście oprogramowania i modyfikowania go, ale też trzeba odbierać ich pracę, zapewnić, kiedy mają pracować, a kiedy nie. Wiem, że są narzędzia, schedulery, które do tego służą, ale czasami trzeba zareagować. Roboty wykonują też pracę ad hoc albo coś się zmienia w biznesie, więc ktoś powinien być odpowiedzialny.
Jeśli chcemy, żeby osoba odpowiedzialna dała radę pracować wydajnie i bezpiecznie na wielu robotach, te roboty muszą być standardowe. Muszą mieć element standardu, a to znowu stoi w sprzeczności…
Mariusz Pultyn: … z radosną twórczością developerów.
Bartek Pietras: IT Excellence to są więc inżynierowie odpowiedzialni za platformę i wszystkie jej komponenty, za standardy.
Mariusz Pultyn: Za prawidłowość. To jest chyba właśnie taki aspekt, że ok, mamy ukryte utrzymanie. Mamy komponenty zainstalowane na maszynach, one są bezpieczne i utrzymywane. Ale ktoś musi wyjaśnić nietechnicznym osobom to wszystko, co powiedziałeś wcześniej. Co to jest system kontroli wersji, jak pobrać aktualną wersję, jak ją przeprowadzić przez środowiska, jak ten kawałek kodu najczęściej jest częścią pewnego frameworku.
Kod robota, ta biznesowa wartość w środku, jest zwykle jak mały orzeszek, a wokół [niego jest] wielka skorupa, która dotyczy standardów logowania, obsługi wyjątków, tego wszystkiego, co musi być napisane przez ludzi, którzy na co dzień stykają się z twardym oprogramowaniem. To też ktoś musi zrobić.
Bartek Pietras: Te wszystkie najbardziej znane, popularne, najlepsze platformy, oczywiście, też dają w to duży wkład, dają pewne standardy. Z naszej perspektywy one są bardzo ważne, ale niewystarczające. Chcieliśmy je rozbudować o pewne [elementy] mocniej wchodzące w development life cycle i software development life cycle, bo z naszej obserwacji tam tego jest czasami może trochę za mało. Ale gdyby wprowadzić miały to osoby, które nie mają tego backgroundu, wykształcenia, to byłaby zbyt duża komplikacja. To jest taka hybryda ułatwiająca ludziom pracę.
Bartek Pietras: Zacznijmy od wynajmowanego Centre of Excellence, bo to jest bliższe (śmiech). Zaleta jest jedna, największa. Z punktu widzenia klienta ma on zdecydowaną większość spraw – mógłbym powiedzieć wszystko, ale zostawiam sobie taki margines – z głowy. Zbudowanie tego, przygotowanie standardów i tak dalej, to wszystko jest poza nim. Wada jest taka jak z każdym dostawcą zewnętrznym, trzeba to robić „mądrze”, z punktu widzenia organizacji musimy mieć zapewnione SLA. Musimy się nad nim dobrze zastanowić.
Mariusz Pultyn: Przede wszystkim wadą może jest bardziej to, że nie jest tak łatwo znaleźć firmę, której można zaufać. Musimy mieć świadomość, że takiej firmie trzeba założyć pewne SLA, jakiś governance. Trzeba zadbać o to, żeby jej reputacja była właściwa, trzeba mieć przekonanie wewnętrzne. Jeżeli ktoś się na tym nie zna, to nie jest tak łatwo ocenić, czy jakaś organizacja jest godna zaufania czy nie.
Bartek Pietras: Szczególnie, że chcemy jej powierzyć często ważne procesy w firmie, które nie zawsze są core’owe, ale są istotne.
Mariusz Pultyn: I to jest trudny moment. Ale to może w takim razie jak tak ciężko wybrać, tak ciężko znaleźć zaufaną firmę, to może zrobić to samemu? Jakie tutaj są najważniejsze zalety albo wady?
Bartek Pietras: To zacznę od zalet. Zaleta jest taka, że wszystko mamy pod kontrolą. Wszystko jest u nas, niczego nie musimy outsourcować. Czy to jest zaleta? To zależy. Pewnie wiele osób zajmującymi się finansami musiałoby się wypowiedzieć, czy to jest zawsze zaleta.
Wada jest taka, że musimy sami zbudować to wszystko, o czym mówiłem. Jeśli chcemy to robić bezpiecznie i dobrze, to musimy to zbudować. To wymaga czasu i nakładów.
Zaletą jest, że przy bardzo dużej skali to jest pomysł warty wzięcia pod uwagę. Tylko pytanie, czy już teraz na dzień dobry my mamy taką [skalę], bo to jest inwestycja finansowa i ważona czasem. Czy chcemy to robić? To zaczyna się składać przy dużej skali. Czy chcemy wynająć czy chcemy kupić?
Mariusz Pultyn: To jest klasyczne [pytanie]. Od pewnego momentu rzeczywiście przy skali opłaca się mieć coś własnego. Natomiast moja obserwacja też jest taka, że nawet jak skala jest duża, czasami organizacja niekoniecznie chce, tak strategicznie, uważać robotyzację jako swoją core’ową działalność.
Nawet jeżeli rzeczy są duże, można je outsourcować. Wielkie organizacje outsourcują np. całe swoje sieci sprzedaży nawet, a zajmują się biznesem, czyli np. kreowaniem produktu. Tu też jest klasyczny dylemat: czy czasami nie warto, nawet jeżeli coś jest duże, oddać tego, bo nie chcemy się tym zajmować? Jednak utrzymanie Centre of Excellence i tego zestawu kompetencji nie jest łatwe, szczególnie jeśli ktoś nie jest specjalistą w tej dziedzinie i nie chce się w niej specjalizować.
Bartek Pietras: Żeby się nim stać, potrzeba czasu, a poza tym też pieniędzy.
Mariusz Pultyn: Nietrudno pewnie wyczuć, że zmierzamy do tego, że outsourcing jest jakąś opcją. Z drugiej strony jest pytanie, które IT może sobie zadaje:
Bartek Pietras: W teaserze już trochę o tym rozmawialiśmy. To nie jest tak do końca. Oczywiście, że taka obawa może wystąpić. Pytanie tylko, czy to jest core’owa działalność IT. Czy to jest coś, co faktycznie chciałbym robić? Dlaczego to jest dla mnie obawa?
Wiemy z doświadczeń naszych i z rynku, jak wyglądają backlogi, jak wygląda ta sytuacja. Backlogi są przepełnione i zadania automatyzujące nie są wybierane w pierwszej kolejności. One tam czekają, jedyna rzecz, jaka się dzieje, to, że ludzie, którzy chcieliby to zrobić, mogą się frustrować.
Mariusz Pultyn: Mamy tę swoją historię przed Digital Teammates. Pamiętamy, na których miejscach w backlogach były zadania typu cost optimisation. Zawsze na górze były te rzeczy, które dla biznesu są najistotniejsze, czyli te, które, mówiąc brutalnie, przynoszą przychód. Rzeczy, które przynoszą przychód, zwykle mają mnożniki wielokrotnie wyższe niż takie, które przynoszą jakieś efektywności kosztowe, bo efektywności kosztowe, niestety, na samym końcu się sprowadzają do tego, czy generalnie człowiek jest tańszy czy droższy niż maszyna. To są bardzo nieprzyjemne rzeczy.
Biznes i nawet IT niekoniecznie chcą po nie sięgać, bo więcej takiej pochwały, przyjemnego poklepywania po plecach ze strony biznesu dostaje się za zrobienie zadań, które są dla nich najważniejsze. Rzadko w organizacjach, w których my też funkcjonowaliśmy, back office, optymalizacje kosztowe są najbardziej kluczowym obszarem działalności. Tak po ludzku nie jest to najbardziej przyjemne poświęcać się rzeczom, które są po prostu nieciekawe.
Bartek Pietras: Mamy też taki aspekt, że oczywiście, jest to dokładanie dodatkowego modelu i inżyniersko jestem temu bliski. Lepiej by było to zrobić inaczej. Być może przez IT stworzyć cały interfejs, przygotować do apki. Z jakiegoś powodu to się nie stało. Pewnie się nie stanie.
Z drugiej strony potencjał robotyzacyjny jest w wielu miejscach, możemy zrobotyzować czy zautomatyzować część, następnie te systemy się zmieniają. IT może sobie, tak nieładnie mówiąc, trochę kupić czas. To znaczy zadowolić biznes, a jednocześnie realizować to, w czym jest najlepsze i co sprawia przyjemność.
Mariusz Pultyn: Zbliżamy się do końca naszego webinaru. Mówiliśmy trochę o tym, dlaczego IT nie musi się bać, ale generalnie strach jest bardzo silną emocją.
Bartek Pietras: Korzyści są takie, że to może być zadowolony biznes, który pozwala realizować core’owe zadania, najważniejsze dla danej organizacji. Ciekawy przykład, o którym powiedziałeś, outsourcing sprzedaży, to dzieje się nawet do tego stopnia. Pozwala ludziom w IT realizować się w technologiach i zadaniach, które lubią.
Mariusz Pultyn: Nie ukrywajmy, kompetencje robotyczne dla IT to nie jest taka pierwsza liga, mówiąc wprost.
Bartek Pietras: To są bardzo specyficzne kompetencje.
Mariusz Pultyn: To nie jest coś, co dramatycznie zwiększałoby a) wartość na rynku pracy, bo o to zwykle chodzi, b) czyste zadowolenie z codziennej pracy, bo poza tymi aspektami, o których mówiłeś, czyli zbudowaniem procesu i Centre of Excellence, co jest interesującym zadaniem. Rozumiem, że dla ludzi IT zbudowanie takiego zespołu może być satysfakcją. Ale już dalej wnikanie w meandry czysto robotyczne to są powtarzalne rzeczy.
Bartek Pietras: I mocno biznesowe, procesy operacyjne…
Mariusz Pultyn: Jesteś [wtedy] bliżej operacjom niż IT, w związku z tym IT się nie może wyszaleć. Tam każde odstępstwo od schematu jest trochę karane. Im bardziej developer chciałby sobie dopisać kawałek kodu, tym droższe jest to z punktu widzenia utrzymania, więc generalnie będziemy go od tego odwodzić, a on będzie wtedy sfrustrowany, że nie może się realizować. W sytuacji, w której jest to na zewnątrz, to rozbudowa normalnych produktów informatycznych daje satysfakcję, można nauczyć się nowego frameworka, można się z niego doszkolić, zrobić ciekawe rzeczy, a nie niskopoziomowe interfejsy.
Bartek Pietras: Wprowadzenie robotyzacji to wprowadzenie kolejnego bytu, klasy systemu do naszych systemów. Natomiast to, co zaczęliśmy od tych makr, [automatyzacja] wprowadza pewien porządek. Zrobienie tego według tych zasad, o których rozmawialiśmy, powoduje, że mamy nowy byt, ale on jest stąd dotąd i tu się zawierają wszystkie automatyzacje. A nie właśnie, że potem zrobimy jakąś białą księgę i okazuje się, że każdy departament ma swoje własne automaty opisane w makrach, które są dobre, ale jak ich użycie przekracza pewną skalę, to stają się problemem.
Mariusz Pultyn: Podsumowałbym to w taki sposób: ewidentnie w procesach automatyzacji IT pełni kluczową rolę. Mówiłem o tym w zaproszeniu. Naprawdę tutaj prawda nie leży pośrodku. Projekt robotyzacyjny jest projektem informatycznym i oczywiście na samym końcu tego procesu jest analiza i kodowanie, które mogą być robione przez osoby, które nie są IT.
Natomiast cała reszta rzeczy musi absolutnie zostać poddana reżimom inżynierskim. To muszą być rzeczy, które są robione przez doświadczone, w pełni poświęcone temu zespoły IT. To jest bardzo istotny rozdział. Jeżeli chcemy robić to wewnętrznie, to absolutnie musimy nasze IT zaangażować do tego procesu od początku i sprawić, żeby IT było jak najbardziej kluczową częścią tego procesu.
Natomiast nawet jeśli chcemy to robić w modelu outsourcingowym, to również IT jest istotne, bo IT w każdej organizacji jest przede wszystkim odpowiedzialne za to, żeby systemy działały. To przeświadczenie, że systemy działają, trzeba zbudować. Jeżeli to jest outsourcowane, to z tym większą nieufnością takie organizacje są przyjmowane. Potrzeba podwójnie zapewnić spokój, żeby IT mogło w pełni odpowiedzialnie odpowiadać zarówno za te rzeczy, które samo dostarcza, jak i za rzeczy dostarczane przez zewnętrznych dostawców.
Reasumując, z jednej strony IT jest w tym wszystkim kluczowe. Z drugiej strony ze wszystkich tych powodów, o których powiedzieliśmy, wiele korzyści może odnieść z tego, żeby ten proces po prostu wprowadzić na zewnątrz.
Bartek Pietras: Podzieliłbym to na dwie części i zaczął od tego, co na pewno nie jest wyzwaniem podczas wdrożenia, czyli sprawy techniczne. Mamy dwa podejścia: podejście w pełnym outsourcingu lub podejście, nazwijmy to, on-premise. Moje doświadczenie jest takie, że w obu nie ma technicznych przeszkód. Tam nie ma wyzwań technicznych. Po pierwsze jest bardzo dobra dokumentacja. Po drugie w obu modelach, a przy outsourcingu pełnym większość rzeczy to w ogóle nie jest temat dla IT klienta. On-premise to także jest nasze wsparcie plus bardzo dobra dokumentacja, zachowane standardy bezpieczeństwa i tak dalej.
Największym wyzwaniem, moim zdaniem, jest podjęcie tej decyzji – zgodzenia się na boty, na outsourcing. To wyzwanie możemy mitygować, wybierając najbezpieczniejsze platformy, te najbardziej popularne – one są popularne nie dlatego, że są popularne, tylko dlatego, że są dobre – i korzystając z usług firm, które wzbudzają zaufanie.
Druga rzecz to ten moment, kiedy mamy decyzję, czyli transparentność. My niczego nie ukrywamy, wszystkie nasze standardy są dostępne, z klientem ustalamy wymagania bezpieczeństwa, parametry różnych połączeń i tak dalej, już nie wchodząc w technikalia. To są wymagania klienta. Zdarza się tak, że mamy regulatora, który mówi: „tak trzeba, tak nie można”. To się zmienia, to żyje, wtedy to realizujemy.
Mariusz Pultyn: Z mojego punktu widzenia też najtrudniejszy jest moment decyzji. Po pierwsze, czy wziąć to na siebie ze wszystkimi konsekwencjami? A drugi to moment decyzji, czy oddać to komuś.
Mariusz Pultyn: Zachęcałbym, żeby puścić im nasz webinar (śmiech). Przede wszystkim w tych dwóch modelach, o których mówiliśmy, nie jest łatwo przekonać IT do tego, żeby wzięło to na siebie samodzielnie, i ja bym do tego nie namawiał.
W modelu jak przekonać IT, żeby się tym nie zajmować, to argumenty powiedzieliśmy. Robotyzacja robiona przez nasze wewnętrzne IT nie jest atrakcyjna. Jeżeli tylko możemy znaleźć kogoś, kto się może tym zająć, to może rzeczywiście jeden zestaw problemów zdjąć z głowy IT. Myślę, że to jest najbardziej istotny argument.
Naprawdę IT w każdej organizacji przede wszystkim dba o to, żeby systemy działały. Jeżeli tylko będzie dobre przekonanie, że jakąś część problemów ktoś weźmie na siebie i to nie będzie już moje zmartwienie, to ujmujemy trochę obowiązków, pozwalamy skupić się na tematach, w których IT specjalizuje się. Z mojego punktu widzenia, kogoś, kto też kiedyś kierował IT w dużej firmie, to jest bardzo istotny argument, że nie dodamy żadnych nowych problemów, ale odejmujemy te, które są na stole.
Jak dużą inwestycją czasową itd. jest stworzenie lub przeszkolenie swojego zespołu IT, by móc wdrożyć automatyzację do firmy?
Bartek Pietras: To trochę wybrzmiało. To jest zbudowanie zespołu Centre of Excellence w danej technologii swojej organizacji. Oczywiście, można tych ludzi zrekrutować z rynku. To jest jak budowanie zespołu. To jest inwestycja. Czasowo? To zależy. To liczone jest raczej w miesiącach niż w dniach albo tygodniach, bo to jest technologia. To jest inwestycja czasowa i wręcz finansowa, trochę z długoterminowym planem. Trzeba się nad tym zastanowić. Tak jak trochę rozmawialiśmy, po pierwsze mamy trochę do zautomatyzowania, jesteśmy dużą instytucją, mamy sporo. Ale w jakimś momencie zrobimy to. I teraz co dalej?
Specyfika pracy jest wtedy zupełnie inna. Zbudowanie sobie standardów, platformy i tak dalej to zadania na ten pierwszy [etap], ale już je mam. Potem zaczynam to robotyzować i w pewnym momencie to też już mamy. I co dalej? To jest jednak dziedzina dość specyficzna, mimo że wykorzystuje wiele pojęć z klasycznej informatyki i technologii. W pewnym momencie budując sobie centrum kompetencji wewnętrznie trzeba mieć pomysł, co będziemy z tym robić dalej. To też ważny aspekt przy podejmowaniu takiej decyzji.
Mariusz Pultyn: To właśnie aspekt, o którym powiedziałeś. Każdy potencjał robotyczny kiedyś się kończy w organizacji. Trzeba mieć przekonanie, że jak on się skończy, ten zespół, który zbudujemy niemałym wysiłkiem i jakimś kosztem czasowym czy pieniężnym, będzie miał w swojej przyszłości jasną wizję tego, gdzie się ma rozwijać albo w jakim momencie ma się przekształcić w coś innego. To jest też decyzja, którą podejmuje się na początku, i tę wizję trzeba mieć na początku, a nie myśleć o tym, jak już robotyzacja się rozpędziła, zrekrutowaliśmy wielki team, a nagle okazuje się, że potencjał jest niewystarczająco duży i zostajemy z ludźmi.
To jest naprawdę istotny aspekt i też zachęcamy do tego, żeby myśleć o tym, żeby zaczynając budować zespół Centre of Excellence, myśleć o tym, co jest długofalowym, długoterminowym celem i wizją takiego zespołu, bo na takie pytania wcześniej czy później życie samo odpowie.
To było ostatnie pytanie. Widzę, że nie mamy więcej. Jesteśmy delikatnie po czasie, ale mam nadzieję, że warto było spędzić z nami ten czas. Bardzo dziękuję wszystkim za udział w webinarze. Zachęcam do tego, żeby być z nami w przyszłości. Dziękuję bardzo.
Bartek Pietras: Dziękuję.
Mariusz Pultyn: Do zobaczenia.
Transkrypcja została zredagowana pod względem długości i jasności.
Obejrzyj nagranie webinaru.
