Wdrażanie automatyzacji w firmie to proces pełen potencjalnych pułapek, a znajomość najczęstszych przyczyn porażek może uchronić przed kosztownymi błędami. W odcinku szczegółowo omówiono siedem krytycznych czynników, które często prowadzą do niepowodzeń: automatyzację nieodpowiednich lub chaotycznych procesów, brak zaangażowania zespołu, zbyt duży zakres na początek, niewystarczającą analizę procesów biznesowych, nieokreślenie mierzalnych celów, zaniedbanie szkoleń pracowników oraz brak bieżącego nadzoru nad wdrożonym rozwiązaniem. Prezentowane przykłady z rzeczywistych projektów pokazują, jak małe zaniedbania mogą przekształcić się w poważne problemy, a jednocześnie dostarczają praktycznych wskazówek, jak skutecznie planować i realizować projekty automatyzacji w organizacji.
Cześć, tu automatyk inżynier Marcin Karwowski z eraIT. Na tym kanale pokazuję, w jaki sposób narzędzia Microsoft 365 mogą wspierać pracę twoją i twojej firmy. W dzisiejszym odcinku powiem ci o siedmiu powodach porażek projektowych, czyli co się musi wydarzyć, aby twoje wdrożenie zakończyło się klapą, aby twoje wdrożenie automatyzacji zakończyło się niepowodzeniem.
Tu będzie recepta właśnie do tego, albo anty-recepta do tego, żeby tych porażek nie popełniać. Błędy, o których będę dzisiaj mówił, pochodzą z naszych wdrożeń, z wdrożeń naszych klientów, więc tym bardziej zachęcam cię do tego, aby obejrzeć ten materiał i zobaczyć, jakich błędów można uniknąć, jakich błędów nie popełniać, aby wdrożenia nie kończyły się porażką. Czyli co zrobić, żeby osiągnąć sukces wdrożeniowy? Zapraszam cię.
Pierwszy powód porażki projektowej to automatyzacja złego procesu. Co to w praktyce oznacza? Zły proces to jest proces, który nie powinien być w tym momencie automatyzowany, nie jest w zasadzie procesem. Nie możemy... Możemy robić wszystko, ale nie powinniśmy automatyzować chaosu, czyli myśleć w ten sposób, że zautomatyzowanie procesu, że wdrożenie automatyzacji zapewni nam procesowe działanie.
Musimy najpierw ten proces w firmie określić, musimy go wdrożyć, a automatyzacja jest narzędziem do realizacji danego procesu, a nie procesem samym w sobie. Więc dopóki nie masz rozpisanego procesu, dopóki nie jest on w jakiś sposób uporządkowany, nie będzie można go zautomatyzować, albo automatyzacja zakończy się po prostu niepowodzeniem.
Innymi słowy mówiąc, tutaj przykład z życia wzięty: brak zasad akceptacji faktur spowoduje, że uruchomimy narzędzie do akceptacji faktur, uruchomimy obieg dokumentów, który będzie właśnie te faktury kosztowe zatwierdzał. I co? I nie będzie on działał, bo nie są określone zasady, według których powinny być te akceptacje w twojej firmie wykonywane. Kto robi pierwszy krok? Kto weryfikuje dane w aplikacji? Kto przesyła ją i uruchamia w ogóle sam workflow, który prześle do kolejnych osób do zatwierdzenia daną fakturę? No i jakie to mają być osoby? Jeżeli tych zasad w twojej firmie nie ma, nie można tego procesu zautomatyzować. No, albo można robić wszystko, tylko zakończy się to po prostu niepowodzeniem.
Automatyzacja zbyt skomplikowanego procesu... Słuchajcie, jest tak: przykład jednoczesnego uruchomienia. Mam takich klientów, którzy mówią: "Dobrze, dobrze, panie Marcinie, my chcemy mieć obieg faktur, bazę faktur, od razu budżetowanie, od razu realizację budżetu, od razu korekty budżetu, wszystko chcemy zrobić na raz. Aha, i niech to wszystko w ogóle trafia do księgowości." To jest proszenie się o porażkę, to jest proszenie się o to, aby nic z tego nie wyszło.
Ja rekomendują, i tak i tak najczęściej postępujemy w naszych wdrożeniach, że OK, możemy to wszystko zrobić, co jest tutaj napisane, tylko róbmy to krok po kroku. Te kroki mogą być stawiane dość szybko, czyli nawet miesiąc po miesiącu czy tydzień po tygodniu, natomiast stabilizujemy jedno rozwiązanie, uruchamiamy kolejne, uruchamiamy kolejne. Oczywiście bardzo dobrą praktyką jest opisanie tego wszystkiego, co tutaj widać, zrobienie planu wdrożenia, ale realizacja tego planu etapami. Takie podejście daje szansę na to, że wdrożenie zakończy się sukcesem, więc do tego cię serdecznie namawiam.
Automatyzacja zbyt skomplikowanego procesu może zakończyć się niepowodzeniem. Automatyzacja niepotrzebnego procesu... Słuchajcie, to to jest ciekawe. W wielu firmach, zaryzykowałbym stwierdzenie, że we wszystkich firmach, ale nie będę tego mówił, powiem: w wielu firmach, w większości firm, wszyscy chcą automatyzować raportowanie automatyczne. Handlowcy mówią: "Żebyśmy mieli automatyczne raporty, to byśmy sprzedawali." Kupcy mówią: "Żebyśmy mieli automatyczne raporty, to byśmy kupowali w super cenach." A później co? A później robimy taki mechanizm przy wdrożeniu właśnie tych aplikacji raportowych, że możemy zobaczyć, kto otwierał dany raport, czy w ogóle ktoś go otwierał.
Mieliśmy takie wdrożenia, w których raportów było kilkadziesiąt, nawet blisko 100. No i większość z nich niejednokrotnie nie była w ogóle przez nikogo otwierana, a zwłaszcza przez tych, którzy najgłośniej krzyczeli, że tych raportów potrzebują. Oni dostawali te raporty, oni mogli z nich skorzystać i co? I nic. Nie otwierali ich ani razu, albo otwierali go tylko raz przy pierwszym uruchomieniu aplikacji i tyle. I więcej tego nie otwierali. I to jest porażka.
Ja i moja firma nie lubimy wdrażać dla samego wdrożenia. My kochamy procesy, które są używane przez naszych klientów, które są potrzebne dla naszych klientów, które rozwijają biznes naszych klientów, i to nam sprawia wielką frajdę. Więc automatyzacja niepotrzebnego procesu, to jest właśnie w ramach tego punktu automatyzacja złego procesu, czyli wybieramy nie ten proces, który trzeba do automatyzacji.
Drugi powód porażki projektowej to brak zaangażowania. Można by sobie pomyśleć: "No ale jak to brak zaangażowania? Przecież wszyscy, którzy chcą wdrażać automatyzację, będą zaangażowani w ten proces. Firma płaci, to ludzie na pewno znajdą czas, aby te czynności realizować." No i guzik prawda.
Wielokrotnie okazuje się, że użytkownicy, którzy będą mieli korzystać z tej automatyzacji, nie mają czasu, nie mają na to czasu. Tutaj mam taki przykład: wdrożenie automatycznego systemu raportowania bez konsultacji z działem sprzedaży. Zdarza się tak, słuchajcie, zdarza się tak, że szef mówi: "Dobra, musimy zautomatyzować raportowanie sprzedaży, ma być to tak, tak i tak." A okazuje się, że użytkownicy korzystają zupełnie z czegoś innego i nie potrzebują tego, co my zrobiliśmy, bo korzystają z innych narzędzi i nie chcą dalej angażować się, dalej patrzeć na te raporty, bo są im najzwyczajniej w świecie niepotrzebne. Nikt ich w firmie nie zapytał o to, jak to ma być zrealizowane, więc to powoduje właśnie, że ten brak zaangażowania występuje.
Brak zaangażowania występuje również w sytuacji, kiedy użytkownicy, przyszli użytkownicy, nie wiedzą, do czego ten proces jest potrzebny. Mieliśmy, słuchajcie, takie wdrożenie, w którym szef wymyślił sobie, że baza faktur musi być, automat w tym zakresie musi być, ale nic nie powiedział pracownikom. Myśmy nie do końca jakby podejrzewali nawet, że pracownicy niczego nie będą wiedzieć. Zrobiliśmy tą bazę zgodnie z założeniami, zgodnie z ofertą, zgodnie z analizą. Szef powiedział, że to nie jest de facto dla niego, tylko dla jego pracowników, a pracownicy mówią: "Hej, ale my w ogóle tego nie potrzebujemy! My korzystamy z innego rozwiązania." Jakkolwiek to zabawnie brzmi, takie sytuacje, słuchajcie, w życiu się zdarzają. To jest autentyczna nasza sytuacja, którą mieliśmy.
Trudności w obsłudze to jest kolejny powód braku zaangażowania. Użytkownicy niejednokrotnie wystraszą się nowego procesu, nowych narzędzi i mogą dojść do wniosku, że nie chcą w ogóle używać tego nowego narzędzia. Mam tutaj taki przykład: aplikacja do obsługi wniosków urlopowych, no i ona była tak skomplikowana, że nie chcieli jej w ogóle używać, że woleli używać dotychczasowego rozwiązania, czyli pisać wnioski urlopowe na papierze i chodzić i prosić o te wnioski.
No, tutaj też czasem wychodzi taki brak konsekwencji u menedżerów, brak konsekwencji u właścicieli firm, którzy z jednej strony wdrażają te automatyzacje, a z drugiej strony nie są w stanie przekonać i pociągnąć za tym wdrożeniem ludzi, którzy są w firmie. No i to powoduje, że niektóre automatyzacje się nie przyjmują. Brak zaangażowania, ludzie muszą mieć czas na zaangażowanie się w ten proces i nie możemy, słuchajcie, o tym absolutnie zapominać.
Punkt trzeci mówi o tym, że za duży projekt bierzemy na początek. Mówiłem już o tym w punkcie pierwszym, ale tu opowiem o innych sytuacjach, o robieniu czegoś "przy okazji".
Słuchajcie, to jest nagminna myśl różnych właścicieli firm: "Dobra, robimy tą aplikację." Robimy aplikacje - i to jest nasz przykład, który jest przykładem z życia wziętym - robimy aplikację do obiegu dokumentów, obiegu faktur kosztowych konkretnie. "Słuchajcie, to przy okazji zróbmy jeszcze umowy. Zróbmy jeszcze obieg dokumentacji technicznej. No i jeszcze tam w ogóle wszystkie dokumenty naraz! W ogóle automatyzujmy to wszystko przy okazji, no bo już jak jedno automatyzujemy to automatyzujmy przy okazji jeszcze jakieś rzeczy."
Trzeba to zaplanować, trzeba to przemyśleć i trzeba to robić w sposób uporządkowany. Bo słuchajcie, automatyzacje są świetne, automatyzacje pomagają w pracy, ale automatyzacje nie wybaczają błędów. Jeżeli będziemy działali w chaosie, jeżeli będziemy automatyzowali, będziemy mieli dużo, dużo większy chaos niż był wcześniej, przed tym całym wdrożeniem.
"Wykorzystajmy pieniądze, przecież to ten sam obszar" - i tutaj, słuchajcie, próba takiego wykorzystania budżetu. No bo jak robimy HR, no to pakujmy wszystko do tego HR-u. Nieważne, że rozmawialiśmy tylko o wnioskach urlopowych, dołóżmy wszystko, co można, tak aby w ramach tego projektu wycisnąć z niego jak najwięcej i wpakować w niego jak najwięcej, i dołóżmy i rekrutację, onboarding, i wnioski urlopowe, i oceny pracownicze - wszystko róbmy naraz. To znowu proszenie się o porażkę, to znowu proszenie się o trudności projektowe.
"Przy okazji" i "w międzyczasie" to są ulubione moje takie frazy, które jak usłyszę, no to po prostu uśmiecham się od ucha do ucha. Nie da się robić czegoś w międzyczasie, nie da się robić czegoś przy okazji. No albo skupiamy się na wdrożeniu CRM i w następnych krokach będziemy automatyzować jego procesy, albo tego nie zrobimy w ogóle, czyli nie możemy i wdrażać systemu, i od razu budować automatyzacji, wszystko naraz, w jednym momencie, bo nam się to wszystko rozsypie, bo nam się to wszystko rozwali. Za duży projekt na początek to jest trzeci powód porażek projektowych.
No i teraz, słuchajcie, brak analizy procesu. W jednym z poprzednich filmów mówię właśnie o tym, o analizie procesów, mówię o tym, że zanim zautomatyzujemy proces, dobrze by było go przeanalizować, dobrze by było go uporządkować. No bo jeżeli, słuchajcie, a tak się wielokrotnie zdarza, że nie macie, moi klienci nie mają wiedzy takiej o praktycznym działaniu danego procesu, czyli automatyzacja na przykład procesu zakupowego, takiego, który wydaje się, że jest, ale w praktyce działa on zupełnie, absolutnie inaczej, to nie da się go zautomatyzować. No bo przy pierwszej transakcji wyjdą wszystkie niedoskonałości. Więc trzeba ten proces przeanalizować, trzeba ten proces opisać, trzeba zrobić to wszystko, o czym mówię w jednym z poprzednich filmów, właśnie żeby móc ten proces uruchomić, właśnie po to, żeby go prawidłowo wdrożyć.
Pominięcie szczegółów - czasem się zdarzają takie rzeczy, że ktoś przy obiegu dokumentów nie pomyśli o korektach, że ktoś nie pomyśli o mechanizmie podzielonej płatności, że ktoś zapomni o fakturach walutowych. Zdarza się i tak, tych faktur walutowych w niektórych firmach jest niewiele i po prostu na etapie analizy, na etapie rozmowy o tym, jak ma działać obieg dokumentów, nikt nie mówi, że mają być waluty, a z walutami wiąże się tam kilka różnych jeszcze ciekawych funkcjonalności, o których trzeba wiedzieć, żeby to mogło zadziałać.
Brak analizy procesu może spowodować również pominięcie niektórych osób, które są kluczowe dla tego procesu, albo być może nie są mega kluczowe, ale bez nich ten proces się nie wydarzy, i kropka. Więc automatyzacja obiegu umów, to mam taki przykład, bez uwzględnienia procesu akceptacji przez prawników... Prawdopodobnie pomyśli każdy z was o tym, że umowa powinna być przez prawników zaakceptowana, że umowa powinna być przez prawników przejrzana, ale jeżeli nie, no to co może być, że my pracując na zewnątrz, skupimy się na pracownikach, przygotujemy cały obieg właśnie w oparciu o pracowników. No i zapomnimy o prawnikach. Sorry, Magda, moja najlepsza prawniczko! I co? Może się tak zdarzyć. Więc brak analizy procesu może spowodować porażkę.
Dochodzimy do punktu piątego: brak mierzalnych celów dla wdrażanego i dla uruchamianego procesu. Słuchajcie, bardzo częsta historia: "Chcemy przyspieszyć." Ile to trwa dzisiaj? Ile ma trwać po wdrożeniu? Jeżeli nie ustalimy sobie takich informacji, nie ustalimy sobie takich KPI, to co? To każdy będzie mógł powiedzieć: "Kurczę, myślałem, że będzie szybciej." A jak szybciej ma być? "No nie wiem, ale szybciej." OK, trudno z tym dyskutować, no bo poczucie każdy może mieć własne.
Więc zachęcam do tego, aby określać w miarę precyzyjnie: baza faktur, obieg dokumentów - jaką ma mieć wydajność? Jak szybko te dokumenty mają krążyć? Co ma być celem? Celem być może jest to, aby te dokumenty nie ginęły; celem być może jest to, aby szybciej trafiały do księgowości. Różne cele takiego procesu, warto dwa słowa o nich zamienić i je po prostu uwspólnić. Być może automatyzacja ma ułatwić pracę bez poprawy konkretnych metryk, warto by było nad tymi metrykami się zastanowić i określić sobie właśnie, jaki jest cel uruchomienia danej aplikacji.
"Wdrażamy, bo konkurencja ma, bez żadnych własnych celów biznesowych." To jest, słuchajcie, super rzecz, tak: "Zobaczyliśmy u sąsiada, że ma zieloną trawę, więc dobra, sypiemy i my ten nawóz, no bo u nas musi być też zielona." Bzdura absolutna! Nie ma sensu wdrażać tylko dlatego, bo coś ma konkurencja, bo czegoś używa konkurencja. Warto się zastanowić, co dzięki temu wdrożeniu możemy osiągnąć, i wtedy rzeczywiście to wdrożenie realizować.
Także brak mierzalnych celów to też może być porażka projektowa, może być to porażka na poziomie takiego mentalu sponsora projektu, mentalu osoby, która zdecydowała się wyłożyć środki na takie wdrożenie. No bo na końcu pomyśli sobie: "Kurczę, to ja zapłaciłem x, y, z za to wdrożenie, a efekty są mizerne." Tylko pytanie, czy komuś powiedziałeś, jakie mają być efekty, i czy ten ktoś wziął to pod uwagę, projektując automatyzację, projektując aplikację. Ja tego nie wiem, ale ty, jak będziesz następnym razem zamawiał daną usługę, to warto, abyś powiedział, jaki jest konkretny cel, do czego ty w tym wdrożeniu dążysz.
Szósty punkt: zaniedbanie szkoleń i wsparcia. Często użytkownicy nie mają tyle czasu, ile by wymagane było, żeby mieli, bo robią to w międzyczasie, mówiłem o tym wcześniej, bo robią to między wykonywaniem swoich bieżących działań. No i tu, jeżeli tych szkoleń nie ma, to pojawia się brak wiedzy, a jeżeli pojawia się brak wiedzy, no to zdarzają nam się różnego rodzaju wpadki.
Czy to ustawiamy i chcemy mieć automatyczne jakieś alerty o zdarzeniach, ale nikt nie powiedział, jak je ustawić, czy to robimy sobie system do raportowania i nikt nie pokazał, jak generować własne raporty, i użytkownicy nie wiedzą, że można w ogóle własne raporty generować, i robią tylko te, które są w ramach wdrożenia przygotowane, czy to robimy automatyzację procesów administracyjnych, ale w ogóle zapominamy o tym, że mogą przychodzić nowi pracownicy - jak ich wdrożyć do tych rozwiązań? I tak dalej, i tak dalej.
Szkolenia i wsparcie, ale wsparcie rozumiane w taki sposób, że zaraz po uruchomieniu aplikacji firma, która wdraża, firma, która wykonuje tę automatyzację czy też aplikację, pomaga w rozwiązaniu takich błędów, które się pojawiają, no zawsze. Nie można, przynajmniej bardzo trudno jest przetestować aplikacje tak na wskroś, żeby żadne się błędy nie pojawiły już po uruchomieniu. One się pojawiają i teraz firma, która wdraża, firma, która projektuje, powinna stać na straży, stać na warcie, i jak tylko się błędy pojawią, od razu szybciutko je rozwiązywać, usuwać, naprawiać tak, aby można było komfortowo korzystać z danej aplikacji, danej automatyzacji. Pamiętajcie o szkoleniach i wsparciu w realizowanych przez was projektach.
W punkcie siódmym, słuchajcie, mamy coś takiego: "Zautomatyzuj i zapomnij". Tutaj najważniejszym elementem jest aktualizacja, regularna aktualizacja procesu, sprawdzanie, czy ten proces jest OK, czy proces automatyczny pokrywa cały proces biznesowy, czy coś się w tym procesie biznesowym nie zmieniło i potrzebujemy teraz jakiejś pewnego rodzaju aktualizacji, czy też mamy tu niepełne wykorzystanie, możemy mieć stare kryteria, zmieniły nam się okoliczności biznesowe, trzeba dodać kilka jeszcze kryteriów do naszych raportów, kilka warunków do naszych raportów, innych czynności i nie ma komu tego zrobić, nie ma komu o tym pomyśleć, nie ma komu tego zgłosić do wykonawcy, że właśnie pojawiły się nowe okoliczności i nie możemy w pełni wykorzystać naszej automatyzacji, naszej aplikacji.
Rotacja pracowników, nieaktualizowane reguły w procesie akceptacji mimo zmian organizacyjnych. Słuchajcie, to jest coś, co zdarza nam się dość często. Był sobie pracownik, nie ma pracownika, a wszystkie reguły śmigają po staremu i dzwonią do nas pracownicy, dzwonią do nas operatorzy systemu i mówią: "Hej, ale do Janka nie przychodzi powiadomienie o akceptacji faktury. Możecie sprawdzić, co się dzieje?" Możemy. Nikt go nie wprowadził do aplikacji, nikt go nie wprowadził do workflow'u. Ten workflow jest realizowany po staremu. I co? I przykro, aplikacja przestaje działać. Pół biedy, jeżeli zgłosi się to na serwis i my to naprawimy, ale zdarza się tak, że tego nikt nie poprawi, a pracownicy dziwią się, że ta automatyzacja przestała działać.
To są z grubsza, w mojej ocenie, jedne z ważniejszych - z całą pewnością - siedmiu punktów, które mogą doprowadzić do porażki w procesie automatyzacji, w procesie wdrażania aplikacji, czyli:
To są ważne rzeczy. Zapiszcie, zapamiętajcie i nie popełniajcie tych błędów w swoich wdrożeniach. Dajcie znać w komentarzu, co wy na to. Dajcie znać, jakie wy popełniliście błędy wdrożeniowe. Jeżeli ten materiał był OK, dajcie lajka, dajcie suba i niech się ta wiedza niesie w przestrzeni internetowej.
Ja za dzisiejszy odcinek serdecznie dziękuję. Jeżeli chcielibyście skorzystać z jakichś konsultacji, z jakichś automatyzacji, z jakichś wdrożeń, przede wszystkim w Microsoft 365, ale nie tylko, wiecie gdzie mnie znaleźć. Zachęcam serdecznie do kontaktu. Marcin Karwowski, automatyk inżynier z eraIT.
.png)
