Jak automatyzować procesy w firmie

Transkrypcja: Jak automatyzować procesy w firmie

Dziś moim gościem jest Michał Guzowski. Michał jest właścicielem firmy, która automatyzuje procesy w różnych organizacjach. Opowie nam dzisiaj, jak każdy z nas może wprowadzać automatyzację w firmie, w której pracuje. Michale, dziękuję, że przyjąłeś moje zaproszenie do rozmowy.

Cześć Mateusz, dziękuję również za zaproszenie i witam Cię serdecznie, jak i wszystkich słuchaczy.

To już kolejny raz, kiedy się widzimy, ale może jeszcze raz przybliż swoją osobę i powiedz, jakiego typu procesy do tej pory automatyzowała Twoja firma oraz jakie oszczędności udało się wygenerować.

Jasne. Zasadniczo zajmujemy się automatyzowaniem procesów w średnich i dużych przedsiębiorstwach. Jeśli chodzi o konkretną specyfikę, to działamy praktycznie w każdym możliwym dziale, automatyzujemy procesy HR-owe, logistyczne, księgowe. Nie jesteśmy w żaden sposób ograniczeni, nasze doświadczenia są pod tym względem dość szerokie.

Najczęściej są to procesy, w których dominuje praca manualna, często związana z nadmiarem pracy w Excelu, co jest bardzo powszechne w średnich i dużych organizacjach. Działamy w oparciu o ekosystem Microsoftu, więc siłą rzeczy naszymi klientami są firmy, które już z tego ekosystemu korzystają.

A czy to, że klient musi już korzystać z Microsoftu, to problem, czy może raczej zaleta? Czy to ograniczenie, czy wręcz przeciwnie? Bo skoro firma już inwestuje w ten ekosystem, to pewnie ma też większe możliwości finansowe?

Najczęściej to raczej zaleta, bo firmy, do których wchodzimy, zazwyczaj już są na Microsofcie. Sporadycznie zdarza się, że przenosimy klienta do tego ekosystemu, ale częściej są to organizacje, które już w nim funkcjonują.

A co z tymi oszczędnościami?

Jesteśmy małym consultingiem, nasza marka nie przyciąga klientów samą nazwą. To, co nas wyróżnia, to fakt, że bardzo dbamy o to, aby inwestycja klienta się zwróciła. To nasza główna karta przetargowa.

Mamy nawet wewnętrzną dewizę: staramy się, by klient uzyskał zwrot na poziomie pięciokrotności tego, co w nas zainwestował. Stosujemy do tego odpowiednie frameworki, takie bardzo szybkie sprinty tygodniowe, w trakcie których jesteśmy w stanie dowieźć realną, produkcyjną wersję rozwiązania. Od analizy po wdrożenie.

Na przykład w jednej z dużych firm kawowych, w ciągu 5 dni wygenerowaliśmy oszczędności rzędu 100 tysięcy złotych rocznie. I już mieliśmy na pipeline kolejne wdrożenia o podobnym potencjale zwrotu.

A mógłbyś przybliżyć, jak wygląda taki tydzień sprintu?

Jasne. Pierwszy dzień to głównie analiza. Pracujemy wtedy na frameworku bazującym na frameworku sprzedażowym SPIN. Zakłada on pewną sekwencję pytań i obszarów, o których się rozmawia.

Na tej podstawie tworzymy matrycę potencjalnych korzyści i rozwiązań dla klienta i staramy się wyselekcjonować takie, które da się wdrożyć jak najmniejszym wysiłkiem, a z drugiej strony przełożą się na jak najwyższe wyniki. Mówimy tutaj o tzw. matrycy effort to value. Jak sobie wyobrażamy taką matrycę to ona będzie miała cztery ćwiartki. Jedna z ćwiartek to ta, gdzie mamy największy zwrot przy najmniejszym wysiłku i właśnie takie rozwiązania, czyli low-hanging fruits, bierzemy na tapet.

Jeszcze wrócimy do tych wszystkich skrótów i tabel, a ile osób pracuje nad takim sprintem? Jaka to jest załoga?

Zazwyczaj sprint realizują dwie osoby. Przez pięć dni intensywnie analizujemy sytuację u klienta, robimy taki rekonesans, analizę różnych jego procesów.

I to wystarcza? Klient nie musi się jakoś specjalnie przygotowywać? Będzie w stanie od razu odpowiedzieć na wszystkie pytania?

Często klienci już mają kandydata na pierwsze wdrożenie. My, zadając pytania, staramy się poszerzyć perspektywę, zobaczyć szerszy kontekst, potwierdzić lub zakwestionować założenia klienta.

Przychodzi mi tu do głowy ciekawy case: klient chciał scyfryzować proces podpisywania umów, bo stwierdził, że to pozwoli mu wyskalować firmę. Bo jego ludzie, którzy pracowali na słuchawce i pomagali klientom przechodzić przez formalności, to odblokuje te zasoby, tych pracowników.

Ale gdy zaczęliśmy zadawać pytania i pogłębiać zrozumienie, doszliśmy do innych wniosków. Bo my zawsze staramy się dojść do konkretu, sprowadzić proces do wymiernej wartości finansowej i realnego usprawnienia.

Wyszło na to, że gdybyśmy scyfryzowali ten proces podpisywania umów, to wygenerowałoby to oszczędności rzędu około 60 tysięcy złotych w skali roku. Natomiast w trakcie analizy okazało się, że klient gdzieś założył sobie: a, jakbyśmy przy okazji te podpisy cyfrowe zautomatyzowali, to może to wpłynęłoby też na zmniejszenie liczby porzuconych koszyków zakupowych. I kiedy wyestymowaliśmy, że ta liczba mogłaby spaść o około 30%, to nagle okazało się, że w grę wchodzą oszczędności rzędu ponad 750 tysięcy złotych.

To totalnie odwróciło ten priorytety. Celem naszej współpracy przestało być samo cyfryzowanie podpisów, zaczęliśmy się skupiać na tym, dlaczego klienci porzucają koszyki i jak ten problem rozwiązać.

A taki sprint polega tylko na papierze zrobieniu tych założeń, czy już wtedy coś rzeczywiście wdrażacie?

To jest właśnie nasz wyróżnik, w tym sprincie już coś wdrażamy. Pierwszego dnia faktycznie skupiamy się na analizie, to bardziej praca na papierze. Natomiast drugi, trzeci i czwarty dzień to już intensywna praca konsultantów, którzy już budują, tworzą automatyzacje, integracje, aplikacje, powiadomienia. A piątego dnia wszystko zbieramy do kupy i podsumowujemy wyniki, co udało się już zrobić.

Oczywiście przez cały proces musi być zaangażowana osoba, która jest tzw. process ownerem, żeby udało się to wszystko zamknąć w pięć dni.

OK, brzmi to naprawdę dobrze. Pokazuje też, jak szybko można wdrożyć automatyzację, oczywiście pod warunkiem, że zna się proces. Wejdźmy więc głębiej, żeby nasi słuchacze również mogli coś takiego przeprowadzić. Może niekoniecznie w tydzień, ale jeśli uda im się osiągnąć przyspieszenie lub automatyzację pracy to będzie super.

Powiedz proszę, od czego zacząć automatyzację? Jak w ogóle identyfikować procesy? O co pytać? Jak ocenić, który proces warto automatyzować i jak oszacować, ile na tym zaoszczędzimy?

No właśnie. Tu bardzo często przez ten cały hype na AI i automatyzację, ludzie wychodzą z perspektywy: jakiego narzędzia użyć?. A narzędzie to jedna z ostatnich rzeczy, którymi należy się zajmować.

Pierwszą, niezmiennie od lat, jest odpowiedni audyt. Trzeba zrozumieć, jakie mamy procesy w organizacji. Czy są udokumentowane, czy nie?

Przytoczę tu kolejną historię. Prowadzę studia na Politechnice Warszawskiej, kierunek No-Code Developer i jeden z moich studentów opowiadał sytuację ze swojej pracy. Przyszedł do nich dyrektor i mówi: słuchajcie, my chcemy mieć teraz wszędzie AI! Robimy AI. Chodziło mu o technologię, ale nie bardzo wiedział, co właściwie chce osiągnąć. Więc zespół postanowił zrobić audyt.

Wyszło, że mają 115 procesów w organizacji. Około 40% z nich miało dokumentację, ale z tych 40%, tylko 70% miało dokumentację aktualną. Więc żeby coś usprawniać czy automatyzować, musisz mieć tzw. status bazowy. Od tego punktu zaczynasz mierzyć, analizować i poprawiać. Nie jesteś w stanie poprawiać, jeżeli nie mierzysz, nie jesteś w stanie mierzyć, jeżeli nie wiesz nad czym pracujesz, jeśli nie masz danych. Zaczynamy więc od dokumentacji.

Kiedy ją masz, możesz przejść do analizy effort to value, czyli możemy sobie poumiejscawiać poszczególne pozycje i tutaj z kolei nie chodzi o to, żeby tu być bardzo skrupulatnym. Nawet takie path estimate, który da nam ogólny pogląd, już jest lepszy niż zupełny jego brak. No i kiedy już to sobie zrobimy, to wtedy te elementy, które są tymi low hanging fruits, jedziemy z nimi. Jeden po drugim, bird by bird.

Znając życie w wielu firmach tej dokumentacji po prostu nie ma, albo tak jak mówisz, pewnie jest niepełna. Często informacje są przekazywane ustnie, np. pracownik idzie na emeryturę i przekazuje wszystko młodemu i on wtedy mógłby wprowadzić tę automatyzację. Choć nie ma nic spisanego, ale wie, jak to robić, bo robi to latami. Czy to dobry element, od którego warto zacząć automatyzację w firmie, bo często wszystko dzieje się, że tak powiem, na hura.

Jak najbardziej. Taka osoba, która jest process ownerem, nawet jeśli jest nowa, ale zna proces w jego obecnej formie jest dla nas skarbnicą wiedzy. Musi nam po prostu wytłumaczyć, jak to wszystko działa tu i teraz. Podczas analizy zawsze rozrysowujemy ten proces. Tak czy inaczej, pierwszym krokiem jest udokumentowanie.

OK, a czy mógłbyś nam powiedzieć, co jest w tabeli, o której wspomniałeś? Jakie są kolumny, jakie przykładowe wartości? To da możliwość wyobrażenia sobie, jak to mniej więcej powinno wyglądać?

Zanim jeszcze przejdę do samej tabeli, trzeba zacząć od określenia, jakie benefity, czyli jakie korzyści, chcemy osiągnąć dzięki danemu usprawnieniu. Kiedy jasno sobie zdefiniujemy te korzyści, stają się one podstawą tej pierwszej kolumny w tabeli, czyli miara. Na przykład może to być czas trwania procesu, jeśli zależy nam na tym, żeby realizować go szybciej. Może to być czas zaangażowania, czyli chcemy, żeby pracownicy poświęcali mniej godzin na obsługę danego procesu. Może to być czas przygotowania, jeśli chodzi np. o przygotowanie dokumentów do audytu. Mogą to być koszty utrzymania albo poziom satysfakcji pracowników.

W przypadku średnich i większych firm często pojawia się też temat ESG. To są wytyczne zrównoważonego rozwoju, które obejmują trzy obszary: środowiskowe, społeczne i zarządcze. I te elementy również mogą być traktowane jako korzyści, które chcemy osiągnąć.

Jak już określimy sobie te benefity, to warto je jeszcze doprecyzować, tworząc tzw. KPI, czyli kluczowe wskaźniki wydajności. Jeśli np. mówimy o skróceniu czasu trwania procesu, musimy odpowiedzieć sobie na pytanie: jak to zmierzymy? Co będzie dla nas wyznacznikiem sukcesu?

Możemy przyjąć, że czas trwania to okres od rozpoczęcia procesu do jego pełnego zakończenia i dziś trwa on 20 dni. Przyjmujemy, że naszą wartością estymowaną będzie 5 dni i to staje się naszym punktem odniesienia. Potem możemy mierzyć, jak ten czas się zmienia na kolejnych etapach wdrażania zmian.

Rozumiem, że potem mówisz o różnych miarach: dniach, godzinach, procentach, wartościach pieniężnych, ile jesteśmy w stanie zaoszczędzić. Na końcu mamy tą poprawę w procentach.

Poczekaj, to Cię tu na chwilę zatrzymam. Do tej pory rzeczywiście mówiłem o takich miarach jak czas trwania procesu, liczba godzin czy poziom satysfakcji pracowników. Czasem używa się też NPS, czyli Net Promoter Score. To wszystko są wartości, które z punktu widzenia inżyniera wydają się satysfakcjonujące. Ale prawda jest taka, że żeby doszło do wdrożenia, ktoś musi za nie zapłacić. I zazwyczaj jest to osoba decyzyjna w biznesie, która sprowadza całą analizę do jednej rzeczy: waluty, a to będzie zawsze waluta finansowa.

Trzeba przeliczyć dane usprawnienie na konkretną wartość finansową. I tu wracamy do tego, o czym mówiłem wcześniej. Może się okazać, że coś, co skraca proces o 90 procent, daje finalnie tylko 50 tysięcy złotych oszczędności w skali roku. I dla biznesu taka kwota może być zbyt mała, żeby uznać to za opłacalne.

Czy to przeliczenie, o którym wspomniałeś, musi dotyczyć biznesu? I teraz, jeśli na przykład pracuję w jakiejś firmie i widzę różne możliwości usprawnień, to w zasadzie powinienem pójść do szefa albo menadżera, który sobie to przeliczy i powie mi, co właściwie jest dla niego najkorzystniejsze, prawda?

Tak, ale dopowiem tylko, że wyobrażam sobie, że ktoś nas teraz słucha i myśli: o matko, czyli żeby cokolwiek usprawnić, to muszę iść do szefa i prosić go, żeby wyłożył na to kasę? A szef pewnie się nie zgodzi, bo ja nie mam doświadczenia, więc jak mam je zdobyć? I robi się z tego zamknięte koło. Tutaj trzeba sobie odpowiedzieć na pytanie, czy chcemy to robić w godzinach pracy, czyli za pieniądze firmy, czy traktujemy to jako naukę i robimy to po godzinach albo obok swoich obowiązków. W tym drugim przypadku nie musimy od razu przeliczać korzyści finansowych.

Jeśli chcemy zdobyć doświadczenie, to warto po prostu usprawniać cokolwiek się da. Możemy podejść do koleżanki z działu obok albo kolegi z finansów i zapytać: słuchaj, co cię najbardziej męczy w pracy? I usłyszymy: a wiesz co, w Excelu codziennie przeklejam dane do ERP-a, jak małpa, kilka razy dziennie. Na co odpowiadamy: słuchaj, mogę Ci to zautomatyzować tak, że jednym kliknięciem wszystko się samo przeniesie. Serio? Jakbyś dał radę, to byłoby super. No i ciach.

I w ten sposób płynnie przechodzimy do kolejnego pytania. Jak przekonać pracodawcę albo samego siebie, że czas poświęcony na automatyzację się zwróci? Trochę już o tym mówiliśmy, ale może jeszcze uzupełnijmy. O czym zazwyczaj zapominamy, analizując opłacalność?

Przede wszystkim trzeba zwrócić uwagę, jakiego rzędu są te koszty, które jesteśmy w stanie wygenerować, i jak to się może przełożyć na rozwój firmy. Można to sobie łatwo uporządkować, odpowiadając na szereg prostych pytań.

Po pierwsze, jeśli wdrożymy dane rozwiązanie, to czego będziemy mogli robić więcej? Po drugie, czego będziemy mogli robić mniej? Po trzecie, co się zupełnie zmieni w tym, jak mu to robimy? Po czwarte, co zaczniemy robić? I po piąte, co przestaniemy robić?

Odpowiadając na te pytania, możemy pójść do przełożonego i mówiąc po biznesowemu, po prostu go pitchować. Pitch to forma prezentacji, która ma na celu przekonanie do jakiejś inwestycji. I właśnie w taki sposób warto podejść do rozmowy z kimś, kto może zostać sponsorem takiego wdrożenia.

Myślę, że jeżeli powiemy szefowi, że zrobimy coś po godzinach, to raczej nie będzie się długo zastanawiał. Bo może tylko zyskać. Chyba że czegoś nie widzę?

Po pierwsze, tak. Po drugie, po co mu w ogóle o tym mówić? Jeśli on nie odpowiada za to formalnie i nie musi się w to angażować, to po co ma o tym wiedzieć. I nie chodzi mi żeby robić jakieś shadow IT, nie o to mi chodzi, ale bardziej o to, że czasem lepiej najpierw coś zrobić, a potem pokazać efekty. Wtedy mówimy: słuchaj, zrobiłem coś takiego po godzinach. Co o tym sądzisz? Szefowie bardzo lubią widzieć efekty, zamiast słuchać deklaracji. Bo niestety często bywa tak, że oni słyszeli już 1258 razy: a może bym zrobił. A potem nic z tego nie wychodzi.

A jak ktoś przychodzi i mówi: trzeba zrobić. I zrobiłem. Zobacz, jakie są efekty, to nagle zapala się lampka. I słyszymy: a mógłbyś jeszcze zrobić to tutaj? A może i tam? I już przelicza sobie w głowie, ile może na tym zyskać, że taki Kowalski zacznie coś tam robić po godzinach.

Oczywiście będzie miał nadzieję, że ta gra będzie trwać wiecznie, ale wtedy już można go spokojnie wyprowadzić z błędu: słuchaj ja bym z chęcią zrobił więcej, może da się to jakoś formalnie uwzględnić, dorzucić do moich obowiązków albo ująć to w stanowisku.

No dobrze, to przejdźmy do kolejnego pytania. Dlaczego rozwiązania typu no-code i low-code mogą być lepszym rozwiązaniem niż tradycyjne programowanie? Oczywiście pytanie trochę retoryczne, ale chętnie usłyszę Twoją odpowiedź. I czy samo MVP przy pomocy no-code to już wszystko? Czy można pójść dalej i utrzymywać całe oprogramowanie w tej formie, czy może jednak lepiej będzie napisać program od podstaw?

Nie wiem, jakiej odpowiedzi się spodziewałeś, skoro mówisz, że pytanie jest retoryczne, ale odpowiem jak rasowy konsultant: to zależy. Zależy między innymi od wielkości biznesu. Im większy, tym bardziej może się to skończyć tylko na MVP, z uwagi na różnego rodzaju wewnętrzne wytyczne czy regulacje. W branży finansowej albo prawnej też wygląda to różnie. Ale prawda jest taka, że widziałem i w małych firmach rozwiązania no-code i low-code, które działały produkcyjnie, i w dużych organizacjach, gdzie zostały wdrożone i funkcjonują do dziś. Zresztą my sami wdrażaliśmy w jednym z największych polskich banków całkowicie no-code’owe rozwiązania, które trafiły na produkcję. I przeszły nawet certyfikację KNF-u, więc da się.

Natomiast mamy też przykłady, gdzie zaczynaliśmy od no-code’u. Robiliśmy jakieś POC, MVP, a potem finalnie część rozwiązania była robiona od zera, już w kodzie. Dlaczego czasem lepiej jest robić w kodzie? Na przykład dlatego, że pewne integracje albo rozbudowa rozwiązania opartego o własną platformę, napisaną od podstaw, gdzie mamy pełną kontrolę nad tym, co się gdzie dzieje, bywają po prostu bardziej efektywne. Czasem próba rzeźbienia i przekształcania narzędzia, które nie zostało stworzone do konkretnych zastosowań, nie ma sensu.

Odniosę się tu do swojej technologii. Gdyby ktoś chciał na przykład zrobić z Power Apps silnik do gier, to to nie jest do tego. Ta platforma nie została zaprojektowana do obsługi sesji dla wielu użytkowników jednocześnie, którzy gdzieś tam sobie grają.

Natomiast co do zasady, no-code i low-code mają kilka fundamentalnych korzyści. Przede wszystkim można dzięki nim bardzo szybko wdrożyć rozwiązanie.

Tak się właśnie zastanawiam, czy istnieje jakakolwiek firma, która byłaby w stanie w ciągu pięciu dni wdrożyć coś, korzystając ze standardowego rozwiązania?

No właśnie i wracając do tego to zależy, które padło wcześniej, im mniej mamy czasu, tym bardziej sięgamy po no-code albo low-code. Chcemy coś montować na biegu, z preprodukowanych komponentów. Natomiast jeśli wiemy, że projekt będzie trwał miesiącami, może nawet latami, to wtedy elastyczność kodu może się zwrócić w dalszej perspektywie czasu.

To też zależy od strategii firmy. Jeśli strategia zakłada tworzenie rozwiązań modułowych, trochę jak mikroserwisy, to wtedy no-code świetnie się sprawdza. Ale jeśli firma chce zbudować jedno, wielkie rozwiązanie, które będzie jednocześnie ERP-em, CRM-em i jeszcze czymś więcej, no to wtedy no-code raczej się nie sprawdzi.

A jeśli chodzi o konkretne zalety no-code’u, to na pewno jest to szybkość wdrożenia, która przekłada się na niskie koszty. Koszt popełnienia błędu też jest niższy, bo bardzo szybko możemy pivotować to rozwiązanie. Efekty widać szybciej, co z kolei powoduje, że zaangażowanie biznesu jest powiedziałbym, ochocze. Biznes jest niecierpliwy, chce mieć wyniki na wczoraj. Ta elastyczność, adaptowalność również jest taka bardzo zwinna, zwrotna. To są niewątpliwe korzyści no-code’u i low-code’u.

A powiedz w przypadku no-code i low-code, co z kwestiami regulacyjnymi? Takimi jak RODO, AI Act czy inne przepisy. Jak to jest rozwiązywane w Twojej dziedzinie? Wiem, że niektóre rozwiązania można zainstalować lokalnie na serwerze i działać tylko w jego obrębie. Jak to wygląda na przykładzie Power Apps albo Power BI? Czy można je uruchamiać lokalnie, czy wszystko działa w chmurze?

Faktycznie, regulacje to często argument, dla którego firmy nie wybierają pewnych platform. Zwłaszcza w średnich i dużych przedsiębiorstwach. Weźmy na przykład takie platformy jak Bubble, Make czy Airtable – świetne platformy, ale mają problem z przejściem przez niektóre regulacje, często nawet nie próbują ich przechodzić, bo nie jest to dla nich biznes. Skupiają się na innym segmencie klientów. Dlatego w dużych korporacjach zwyczajnie nie ma dla nich miejsca.

Ja osobiście nie znam żadnej korporacji, która wdrożyła takie rozwiązania, oczywiście nie znam wszystkich korporacji na świecie. Ale współpracuję z firmami takimi jak Tchibo, Carlsberg, Neuca, Dentsu czy Budimex. I tam takich platform nie ma. Ale na przykład Microsoft, to już inna historia. Oni są tak dużym przedsiębiorstwem, że mogą sobie pozwolić na inwestycje, które pozwalają ich rozwiązaniom spełniać wszelkiego rodzaju, nowe pomysły Unii Europejskiej.

Powiedzmy, że już wybraliśmy, co chcemy automatyzować, przeszliśmy analizę, mamy rozwiązanie i co teraz? Bo domyślam się, że na papierze wszystko wygląda super, ale w praktyce może wyjść coś, czego nie przewidzieliśmy. Czy wdrażanie automatyzacji opiera się na iteracji? Pierwsze, drugie podejście nie zawsze musi być przełomowe. Na jakim etapie trzeba po prostu dać za wygraną, a gdzie jeszcze warto szukać lepszych rozwiązań?

To bardzo dobre pytanie, ale niestety nie ma na nie jednej, prostej odpowiedzi. Jeżeli chodzi o iterowanie, to tak jak w projektach IT działających w metodyce agile, tak tym bardziej w no-code i low-code iteracja jest naturalnym procesem. To absolutna podstawa.

Natomiast kiedy powiedzieć stop? Tu niestety znowu muszę odpowiedzieć: to zależy. Od czego? Od konkretnego przypadku. W takich sytuacjach bardzo przydaje się wsparcie zewnętrzne, doświadczony konsultant, który potrafi ocenić, czy dalsze inwestowanie w dane rozwiązanie ma jeszcze sens. Może się okazać, że na tym etapie no-code się już wyczerpał i czas wdrożyć trochę customowego kodu. Warto posługiwać się tu takimi ogólnymi zasadami, jak zasada Pareto, czyli 20 procent nakładu pracy powinno zrealizować nam 80 procent potrzeb i funkcjonalności.

To może z Twojego podwórka, ile automatyzacji nie udało się dowieźć?

Wiesz co, nie skłamię, jeśli powiem, że wszystkie automatyzacje udało się dowieźć. Ale skłamałbym, gdybym powiedział, że wszystkie dowieźliśmy w tej formie, w jakiej zaczynaliśmy. Praktycznie w każdym projekcie coś się zmieniało. Niewiele było takich, które zakończyły się dokładnie zgodnie z początkowym założeniem.

Taka jest specyfika projektów IT. One ewoluują, dochodzą nowe wymagania, pojawia się tzw. koncert życzeń. To jest naturalna tendencja biznesu. Konsultant nie zawsze jest w stanie to skutecznie odeprzeć, bo to bywa rodzajem negocjacji, czasem wręcz przepychanki.

Projekty no-code i low-code przez swoją elastyczność mogą cierpieć, a w zasadzie bardzo często cierpią, na to, że w trakcie ewoluują, ale to jest OK. Na tym polega cała zaleta tych platform, że one na to pozwalają. Dobry, doświadczony konsultant to ktoś, kto wie, kiedy powiedzieć biznesowi: spoko, zrobimy to, a kiedy powinien powiedzieć: nie, moi drodzy, zmieńmy proces a nie próbujmy teraz zmieniać rozwiązania.

To mocno wybrzmiało, że doświadczenie ma tu kluczowe znaczenie. Wiele osób, które dopiero zaczynają automatyzować, nie wie jeszcze, co się da, a co się nie da. I tak chciałem pokazać też, że nie zawsze powinniśmy próbować na siłę iść w stronę, że na pewno się da, ale nie wiemy jak. Może czasami mamy gdzieś jakieś ograniczenia. Nie mówię, że musimy się od razu poddawać, ale też może nie warto poświęcać tyle czasu na coś, co może nie dać nam tego, co byśmy chcieli.

Tutaj wracamy do starej maksymy: czy wiesz, po co robisz to, co robisz? Jeżeli naprawdę chcesz coś usprawnić, to zatrzymaj się i przemyśl to. A jeśli nie masz jeszcze doświadczenia, to najlepiej jest skorzystać z pomocy kogoś bardziej doświadczonego. Albo samemu zostać pomocą dla kogoś innego.

Ale jeżeli celem jest nauka, to ja bym cisnął. Nawet jeśli finalnie okaże się, że pracowaliśmy nad czymś miesiąc i udało się zaoszczędzić godzinę czasu, co realnie się nie zwróci, to i tak cel został osiągnięty. Bo celem była nauka.

Załóżmy, że mamy już przygotowane automatyzacje, mamy na nie plan. Co dalej? Z jakiego narzędzia skorzystać? Bo jeśli ktoś nie ma doświadczenia, to jak rozpoznać ograniczenia na etapie planowania, żeby się potem nie okazało, że to właśnie wybrane narzędzie nie pozwala nam zrealizować celu?

Nie ma platform idealnych. Nie istnieje platforma, która rozwiąże każdy problem. A jeśli nawet takie są, to są już tak stare, że nikt nie chce się ich uczyć, bo nie da się ich rozwijać. Dlatego na początek najlepiej sprawdzić, co już mamy w firmie. Jeżeli firma korzysta z rozwiązań Microsoftu, to zaczynamy od Microsoftu. Jeśli pracujemy na Salesforce, to próbujemy w ramach Salesforce. Nie ma co się kopać z koniem, zawracać kijem Wisły i próbować wdrażać na siłę Power Platform w firmie, która działa na Salesforce. Będziemy tylko mieli więcej przeszkód po drodze niż wsparcia. Także od tego bym zaczynał.

Kiedy już zdecydujemy się na jakąś platformę, warto od razu dowiedzieć się czegoś więcej o jej licencjonowaniu. Każda platforma ma jakąś rozbudowaną politykę licencyjną i może się okazać, że firma, chociaż posiada na przykład Power Platform, to niekoniecznie dysponuje licencjami premium. Może się też zdarzyć, że my, jako użytkownicy, po prostu nie mamy do nich dostępu i jesteśmy ograniczeni do wersji pół darmowych. W takiej sytuacji, jeśli nagle będziemy chcieli kupić licencję premium tylko na nasze potrzeby, organizacja raczej się na to nie zgodzi. Ale może warto zapytać administratora albo kogoś z działu IT, czy taki dostęp już przypadkiem nie jest gdzieś dostępny. Na przykład w ekosystemie Microsoftu funkcjonują środowiska developerskie, które nie wymagają dodatkowego licencjonowania. Mają one pewne ograniczenia, na przykład nie można w nich tworzyć rozwiązań produkcyjnych, ale są wystarczające, żeby się nauczyć, korzystając z pełnego zakresu funkcjonalności premium. Warto więc najpierw poczytać o licencjach i sprawdzić, co możemy zrobić w ramach możliwości, które mamy już w organizacji.

Ja bym jeszcze zwrócił uwagę na jedną rzecz. Uzależnienie się od jednej firmy, od jednego dostawcy, może w dłuższej perspektywie być dużym problemem. Na początku nie zdajemy sobie sprawy, ale później może się okazać, że koszt licencji znacząco wzrośnie i przekroczy realne korzyści.

Poruszasz tu bardzo złożony temat. Po pierwsze, to nie jest problem konsultanta. Jeśli jesteś osobą, która się uczy albo chce coś usprawnić, to nie powinieneś się przejmować tym, co się stanie z cenami licencji za pięć lat. To już zmartwienie zarządu, działu finansowego i osób odpowiedzialnych za strategię firmy.

Ale masz rację, takie sytuacje się zdarzają. Pamiętam przykład z konferencji No Code Days, gdzie Paweł Biel, wiceprezes Amica, opowiadał o tym, jak firma kupiła dużo licencji jednej z firm. Po trzech latach cena wzrosła dwustukrotnie. To kompletnie wywróciło ich model działania. Byli już jednak tak głęboko w tej technologii, że nie mogli się wycofać. Zablokowali wszystkie nowe inwestycje, ale za to, co już mieli, musieli zacząć regularnie płacić.

Z trzeciej strony, jeśli jesteś średnim lub dużym przedsiębiorstwem, to musisz wybrać jakiegoś dużego, stabilnego dostawcę, który będzie się rozwijał. A duzi gracze mają swoje strategie. Zaczynają tanio, żeby przyciągnąć klientów, a potem sukcesywnie podnoszą ceny. I to trzeba wliczyć w koszty.

Jeszcze jedna rzecz, ja osobiście nie wierzę w to, że da się dziś uniknąć vendor locka. Vendor lock to sytuacja, w której jesteśmy uzależnieni od jednego dostawcy. Nawet jeśli instalujemy Windowsa i pracujemy na nim, to już jesteśmy związani z konkretnym ekosystemem. Przejście na Linuxa też nie daje pełnej niezależności. Nie ma dziś czegoś takiego jak całkowita niezależność. Dlatego według mnie nie należy się dziś zastanawiać, jak uniknąć vendor locka, tylko jak zminimalizować jego koszty. Bo on i tak się pojawi.

Jak tak o tym mówiłeś, to pomyślałem, że ja zawsze starałem się korzystać z narzędzi albo sprzętu, który obsługuje oba systemy operacyjne. Żeby potem, jeśli będzie taka potrzeba, łatwiej było przejść.

A jak często musiałeś przechodzić?

Rzadko. Ale jak już to zrobiłem, to byłem zadowolony. Bo nie musiałem się uczyć np. nowej klawiatury, wszystko już miałem opanowane. Prościej było przejść na kolejny system, przynajmniej jedna rzecz odpadła.

To prawda. My, jako ludzie, mamy naturalną tendencję do zabezpieczania się. Ewolucyjnie jesteśmy zaprogramowani, żeby wypatrywać zagrożeń i szykować się na różne scenariusze. Ale pytanie brzmi, jaki jest koszt alternatywny takiego przygotowania?

Mogę przecież wybrać jakąś open source’ową platformę, żeby być niezależnym, tylko czy jej instalacja i konfiguracja nie będą z czasem tak uciążliwe, że to w ogóle przestanie się opłacać? Na takie pytania trzeba sobie umieć szczerze odpowiedzieć.

OK, to teraz wróćmy do naszego podsumowania. Przynajmniej ja tak na to patrzę. Od czego powinny zacząć osoby, które interesują się programowaniem, myślą o przebranżowieniu i chcą zdobyć doświadczenie poprzez tworzenie automatyzacji dla firmy? Takie, które potem można pokazać na rekrutacji. Co powinny zrobić, żeby w ogóle wejść w ten temat, wykorzystując to wszystko, o czym dziś rozmawialiśmy?

Zacząłbym od tego, żeby wybrać albo platformę, do której mamy już dostęp w firmie, albo taką, która nas po prostu ciekawi. I jeśli jest to któraś z platform z topowej dziesiątki trendów, to nie trzeba się zastanawiać, czy iść w tę numer jeden, czy w piątą. To nie ma większego znaczenia, bo te platformy są dziś na takim poziomie, że bardzo szybko się do siebie zbliżają.

Warto po prostu wybrać jedną z nich, znaleźć jakiś realny problem, który można nią rozwiązać, i od razu poszukać społeczności, która zajmuje się daną technologią. Po co? Żeby móc pytać bardziej doświadczone osoby o podejście, o ich sposoby na rozwiązywanie konkretnych problemów.

Każda platforma ma swoją społeczność. Jeśli chodzi o Power Platform, to mamy nawet największą otwartą społeczność w Polsce: Power Platform Polska na Discordzie. Nie ma tam tylko naszej firmy i naszych klientów. Są też nasi konkurenci. To społeczność ponad podziałami, otwarta dla każdego.

Dobrze też poszukać szkoleń, najlepiej takich płatnych, gdzie jest jakaś grupa, w której można się wymieniać doświadczeniami, wiedzą i problemami. Darmowe kursy typu, kliknij tu, kliknij tam, są OK na start, ale niewiele dają, jeśli chodzi o realne zrozumienie. A jeśli mamy budżet szkoleniowy od pracodawcy, warto z niego skorzystać.

A jak chodzi o najczęściej popełniane błędy na etapie analizy albo wdrożenia, czy masz może kilka rad dla osób, które chcą wykonać swoją pierwszą poważną automatyzację?

Powiem szczerze, to nie będzie bardzo precyzyjna rada, po prostu rozmawiajcie z ludźmi w firmie. Nie powiem z kim dokładnie, w jakim dziale, bo to zależy, ale rozmawiajcie. Zapytajcie, czy ktoś ma jakiś problem, który da się rozwiązać. Czy ktoś ma doświadczenie z daną platformą? Czy w firmie są jakieś wytyczne, których trzeba przestrzegać przy tworzeniu rozwiązań?

I jeśli robicie analizę, to nie róbcie jej „na czuja”. Można to zrobić według jakiegoś frameworku. Jest na przykład framework sprzedażowy SPIN, który świetnie się do tego nadaje. SPIN to skrót od czterech rodzajów pytań. Najpierw pytania sytuacyjne, które budują zrozumienie kontekstu. Potem pytania dotyczące problematyki. Następnie mamy kwestie związane z implikacjami i na końcu pytania o oczekiwane zwroty z inwestycji. Jak wpiszecie SPIN framework sprzedażowy, to na pewno znajdziecie prosty schemat pokazujący, w jakiej kolejności zadawać pytania. To naprawdę pomaga uporządkować analizę. Potem, kiedy przechodzimy do wyliczania ROI, można poszukać różnych schematów pokazujących, jak to robić, na co zwracać uwagę, jak określić sobie KPI. Tu polecam moje artykuły na LinkedInie i newsletter, w których opisywałem, jak wyliczać ROI i jak definiować KPI, czym się różnią od OKR-ów, i tak dalej.

No i zacząć je po prostu wdrażać. A od czego zacząć wdrożenia? Dobrze jest mieć już jakąś bazę w postaci szkolenia. Znaleźć takie szkolenie, które pozwala liznąć podstawy. Odradzam szukanie, że tak powiem kolokwialnie, na przypał. Czyli nie wpisujemy w internet: szkolenie Power Apps, bo najczęściej znajdziemy tam te najpopularniejsze, co wcale nie znaczy, że najlepsze. Najpopularniejsze to zwykle najtańsze, a te to często przeklikiwane samouczki, nagrane kursy, bez elementu społeczności.

Tu polecam najlepiej podpytać w swoim otoczeniu, znajomych, kolegów, koleżanki, czy znają kogoś, kto już przeszedł drogę wejścia w tę technologię. Warto zapytać, jaką ta osoba przeszła ścieżkę. Co zrobiła dobrze, co by zrobiła inaczej i czego już by nie powtórzyła.

OK, a jeśli chodzi o wdrożenie, masz tutaj jeszcze jakąś radę?

Tak, to znaczy, jeżeli się uczymy, nie powinniśmy wdrażać niczego produkcyjnie. Powinniśmy zadbać raczej o to, żeby to faktycznie było wdrożone w jakimś środowisku testowym albo developerskim, który jest całkowicie zamknięty na integrację z zewnątrz, po to, żeby nie wyrządzić w firmie szkody. Bo jak coś się wydarzy, to na pewno ktoś się w końcu o tym dowie i będą pretensje. Natomiast jeśli o to zadbamy, to już potem hulaj dusza, piekła nie ma. Warto testować, eksperymentować, bawić się, żeby się nauczyć.

Jeśli jednak myślimy o wdrożeniu produkcyjnym, to tutaj mamy już bardzo solidne wytyczne. Trzeba stworzyć środowiska pośrednie, nie wiem, na ile użycie słowa UAT coś komuś mówi, ale to są środowiska do testowania i sprawdzania, czy dane rozwiązanie rzeczywiście działa i czy można je wypuścić na produkcję. Jeszcze przed UAT-ami mamy środowiska testowe tylko dla developerów, takie wewnętrzne. I tu mamy całą automatyzację wdrożenia. Pamiętam, że w jednym z banków, w którym robiliśmy wdrożenie, obowiązywała odgórna polityka mówiąca, że przy wdrażaniu na produkcję nikt nie ma prawa robić czegokolwiek manualnie w tym środowisku. Wszystko ma być wdrożone automatycznie. Dlaczego? Bo człowiek może przypadkowo coś źle przeklikać, a automat, jak już jest zaprogramowany, zawsze zrobi to tak samo. Więc takie było przykazanie.

No dobrze, to już pytanie prawie na koniec, ale muszę je zadać w dobie obecnej sztucznej inteligencji. Jak będzie wyglądać przyszłość automatyzacji w dobie AI? Czy już teraz wystarczy przedstawić problem i otrzymujemy gotowe rozwiązanie? Jakie narzędzia wydają się najbardziej obiecujące w tym kontekście?

Powiem brutalnie, nikt tego nie wie. A jak ktoś mówi, że wie, to kłamie. Nie wiemy, jak to się potoczy. Przypomnij sobie październik 2022 roku. ChatGPT jako jedna z pierwszych platform AI pojawił się właśnie wtedy. Więc jak wyglądało nasze życie w październiku tamtego roku, a jak wygląda teraz? Czy wtedy bylibyśmy w stanie przewidzieć, co się wydarzy? Może kilka osób coś przewidziało, ale to były ślepe trafy. To jakby ktoś powiedział: zagrałem w Totolotka, wygrałem, to ja Wam powiem jak nazleży grać. No nie, to było szczęście. Przestańmy się oszukiwać, nikt nie miał pojęcia, jak to będzie wyglądać.

Ale to co już możemy zauważyć, że wiele prostych czynności, zarówno analitycznych, jak i kreatywnych, przejmuje AI. Przykładowo, ja piszę newsletter dla subskrybentów, każdy ma cztery sekcje i kilka tysięcy znaków. Kiedyś przygotowanie zajmowało mi dzień, dwa. Teraz? Godzinę. Dlaczego? Bo mam swojego second braina, to taka nowinka ze świata AI. To miejsce, gdzie zbieram wszystkie moje informacje z social mediów, przemyślenia, notatki terapeutyczne, pomysły na posty, wdrożone posty. Wszystko tam trzymam i zintegrowałem to z Claudem, czyli jedną z platform AI.

Pytam: co mógłbym napisać w najbliższej edycji newslettera? On przegląda moje notatki, wybiera coś, kojarzy tematy, mówi: słuchaj, może napisać o tym, bo jeszcze o tym nie pisałeś. I ciach, jazda. Potem proszę: napisz to w moim stylu. On robi 80% roboty. Ja poprawiam, dopisuję i to brzmi jak moje. Jest nie do odróżnienia, że zostało na początku wygenerowane przez AI. To dlatego, że nauczyłem go, jak myślę. To niby AI, ale tak naprawdę bardzo dużo mnie. To dalej w pełni autentyczne. Jak redaktor naczelny, który odpowiada za zawartość czasopisma, treść tworzą inni, ale to on zatwierdza, co się ukaże. I tak samo jest dziś z AI.

Zmienia się nawet to, że dziś możemy przetwarzać znacznie więcej informacji. Naszym zadaniem jest tylko zebrać dane i dostarczyć je AI. Stąd cała ta filozofia second brain, którą też promuję, zbierania jak najwięcej danych do jednego źródła i wykorzystywanie tego źródła.

A jak będzie to wyglądało właśnie pod względem no-codu, low-codu? Myślisz, że będzie można łatwo, stworzyć scenariusz, tylko opowiadając o nim i dostosowując go? Czy to już jest albo czy będzie w niedalekiej przyszłości?

To już jest, to już się dzieje. Są platformy, które pozwalają, to jest taka hype'owana teraz poddziedzina programowania, czyli Vibe coding, gdzie większość pracy to tylko tłumaczenie, a platforma AI tworzy kod. Wiele z nich jest na tyle dobrych, że ten kod, który się wytwarza, jest już naprawdę niezłej jakości. Lepszy niż niejeden junior, czy nawet regular by napisał. Oczywiście, nie zawsze jest to idealne, ale do małych, średnich aplikacji jest to absolutnie wystarczające.

Przy większych systemach, gdzie jest jakiś legacy, gdzie potrzeba naprawdę precyzyjnej customizacji, dalej szybciej i prościej będzie to napisać samemu. Ale to nie oznacza, że prompt, gdybyśmy się bardzo uparli, nie byłby w stanie tego zrobić. Natomiast wydaje mi się, że to, że AI potrafi to robić, wcale nie zwalnia nas z obowiązku rozumienia, co ono robi. Warto, według mnie, nadal uczyć się programować, nawet nie po to, by pisać kod, tylko po to, by umieć właściwie sterować tym AI.

To ja jeszcze dodam może od siebie, bo rozmawiałem na temat rozwoju AI z osobą, która mocno siedzi w temacie. Ona uznała, że mimo ogromnego progresu na początku, ostatnio wszystko zwolniło. Tak jakby nie było już kolejnego skoku, tylko takie dokręcanie śrubek, zamiast zmiana całego otoczenia. Czy myślisz, że faktycznie czuć to? Czy w ogóle to nie jest Twój temat i trudno Ci się wypowiedzieć?

Ja nie jestem ekspertem AI. Jestem takim power userem i hard userem, który bardzo dużo z AI korzysta. Jestem praktykiem, nie teoretykiem, więc nie mam takiej perspektywy, żeby powiedzieć coś znaczącego.

Ja tak średnio raz na kwartał obserwuję znaczny skok własnej efektywności dzięki AI. Może to wynika z tego, że w coraz większej liczbie zastosowań widzę, jak dobrze to działa. Więc tak, ja widzę ten skok, ale na własne potrzeby.

No dobrze, to na koniec, jaką książkę polecisz osobie, która chce zgłębić temat automatyzacji procesów?

Jeżeli ktoś chce zgłębić automatyzowanie procesów, to nie ma tutaj żadnych książek. Robić, wdrażać, nie kombinować. Tylko praktyka, praktyka, praktyka. Na tym się nauczymy najwięcej.

Jak miałbym polecić jakąś książkę, to poleciłbym swojego ulubionego autora: Rozmyślania Marka Aureliusza. Człowiek żył prawie dwa tysiące lat temu, a jego treści dalej są aktualne. Mnie osobiście robią bardzo dużo. Czytając je, widzę, że mimo upływu czasu, mam podobne wątpliwości, rozkminy, spostrzeżenia. Człowiek jako maszyna nie zmienił się aż tak bardzo przez te dwa tysiące lat. Czytając to, studzę swoje przekonanie, że ach, jak ciężko w życiu, jakie mam trudności, jak mi źle. A tam Aureliusz też miał podobne dylematy. Tyle lat temu. On to spisywał nie dla sławy, nie dla pieniędzy. Nie musiał, był cesarzem. Pisał dla siebie i to czuć. To było bardzo autentyczne. I dlatego dalej jest aktualne. Tak że jeśli miałbym coś polecić to właśnie Marka Aureliusza.

To polecamy wszystkim Marka Aureliusza. A powiedz mi, gdzie możemy cię znaleźć w sieci, jeśli ktoś jednak wolałby Ciebie zamiast Marka?

Jestem chyba na każdej platformie. Tylko na LinkedIn jestem jako @MikeGuzowski, a na wszystkich pozostałych: YouTube, Instagram, TikTok, Threads, Facebook, Twitter, czy raczej X, Mastodon, Bluesky, wszędzie jestem jako @HyperactiveMike i tak mnie szukajcie.

Tam mówię nie tyle o automatyzacjach biznesowych, a o takich w produktywności osobistej, w duchu ADHD. Mam dużo ADHD, ale nauczyłem się przekuwać to w siłę, skupiając się na tym, co mi wychodzi dobrze i delegując to, co mi wychodzi źle. Dzięki temu jestem w stanie dowozić.

Myślę, że sporo już dowiozłem w życiu i mam mandat, żeby uczyć tego innych, robię to. Mam społeczność ADHD Do’ers na Discordzie. Jak wpiszecie www.hiperaktywnymike.pl/discord przeniesie was na nasz serwer. Tam zobaczycie, co robimy. Mamy spotkania online w każdy wtorek o 19:00. Mam też newsletter, a wszystkie informacje znajdziecie na www.hiperaktywnymike.pl. Zapraszam do obserwowania, subowania, to mnie napędza. Budujmy swój network. Żyjmy w zadowoleniu, szczęściu i efektywności.

Tak jest. Wszystkich zapraszam do Michała, a ja Tobie bardzo dziękuję za rozmowę i za to, że podzieliłeś się z nami swoimi doświadczeniami.

Dzięki serdecznie Mateusz raz jeszcze za zaproszenie. Fajna rozmowa na antenie i jeszcze fajniejsza pozaanteniu.

Do następnego razu. Dzięki. Cześć.

Dzięki. Cześć.