Terminator w biurze

Nie jestem pewien, czy to świat biznesu zatacza coraz szersze kręgi wokół tematu automatyzacji i robotyzacji biurowej, czy może sam podświadomie wybieram artykuły i wydarzenia, w których temat ten jest coraz mocniej akcentowany.

Jaka by nie była tego przyczyna, w artykułach, prelekcjach i panelach dyskusyjnych zawsze dostrzegam swoistą ekspresową analizę SWOT. Mówimy o silnych stronach i szansach w kontekście budowania wartości w organizacji, produktywności, czy aspektów jakościowych. O słabych stronach mówi się, gdy podejmujemy temat kosztów, ryzyka i zagrożeń. O zagrożeniach najczęściej w kontekście społeczno-gospodarczym.

Ciekawostką jest, że podczas rozmów kuluarowych z osobami, które nie odpowiadają za strategiczne zarządzanie organizacją i jej wynik finansowy, mówi się głównie o zagrożeniach.

Prawda jest taka, że wiele osób zatrudnionych na etacie postrzega automatyzację i RPA bardzo podobnie do tytułowego T800 lub T1000, z dużym akcentem na źródłosłów określenia „terminator”.

Krótko mówiąc - dla tych osób automatyzacja i RPA to koniec!

Tak na marginesie, podobnie postrzega się wiele innych inicjatyw znacząco podnoszących efektywność procesów w firmie.

A jak wygląda praktyka? Czy naprawdę każda automatyzacja jest substytutem FTE i to przy relacji 1 automat zamiast 5 do 20 FTE?

Bądźmy szczerzy, może tak być, a nawet nie raz bywało i nie raz tak będzie.

Wiem, że są badania, które pokazują odwrotny trend, ukierunkowany na zdecydowaną zmianę charakteru pracy i nawet przyrost etatów. Warto jednak wziąć pod uwagę, że są to badania realizowanie w okresie transformacji i wdrożeń. Prawdziwą odpowiedź uzyskamy dopiero na etapie globalnej stabilizacji zautomatyzowanych procesów. Innymi słowy, gdy roboty staną się już naszą zawodową codziennością.

Moim zdaniem jest to jednak niewłaściwy kierunek dyskusji.

Pytanie, które powinno się zadać nie dotyczy relacji automat/RPA vs FTE. Właściwym pytaniem jest raczej: Gdzie są te redukowane FTE na naszej osi czasu? Dziś, jutro, za miesiąc, rok, pięć lat?

Jeżeli spojrzymy na problem w ten sposób i nałożymy naszą odpowiedź na trendy w przyroście naturalnym i rozwoju gospodarczym może się okazać, że automatyzacja jest nie tylko potrzebna, czy opłacalna, ale wręcz konieczna!

Na tym poziomie można przyjąć, że nie taki Terminator straszny, jak go malują.

Żeby nie było zbyt kolorowo, przejdę teraz na inny poziom. Poziom wdrożenia i ryzyka, jakie każdy automat wnosi w nasze procesy wraz z oczywistymi korzyściami.

Od razu dodam, dla jednych oczywiste, dla innych kontrowersyjne stwierdzenie, że źródłem ryzyka w automatyzacjach nie są same automaty. Automat jest tylko nośnikiem. Ryzyko generują ludzie.

Dlaczego?

Ponieważ ludzie programują automaty, podejmują decyzję o ich wdrożeniu, realizują analizy biznesowe i wszystkie czynności przygotowawcze przed wdrożeniem automatów. A mówiąc ściślej, nie zawsze je realizują.

Można wręcz powiedzieć, że często skupiamy się na samym automacie, całkowicie pomijając otoczenie organizacyjne, środowisko procesowe i wszelkie punkty styku automatu z człowiekiem, czyli główne ogniska ryzyka.

Żeby automat nie stał się uśpionym Terminatorem dla procesu trzeba zadać sobie sporo trudu i pytań przed wdrożeniem automatyzacji. Można nawet przyjąć, że development i wdrożenie to przysłowiowa wisienka na torcie i kropka nad „i”.

A co najpierw?

Najpierw czarnowidztwo lub mówiąc łagodniej, zarządzanie ryzykiem.

Jeżeli ktoś nie jest przekonany, to dam prostą ilustrację:

Niech jeden automat zastąpi pracę 10 osób.

Niech jedna osoba realizuje średnio 50 transakcji dziennie z odsetkiem błędu na poziomie 4%.

Jeżeli błędy nie wynikają z niskich kwalifikacji i złej woli pracownika, tylko z samego procesu, jego luk informacyjnych, kiepskiej standaryzacji lub innych czynników, to zastąpienie ludzi automatem da nam wynik 20 błędów dziennie! Czyli 40% całkowitej produktywności jednej osoby w „analogowym” procesie.

A co z błędami wynikającymi z pracy developera?

Co gorsza, skoro już zastąpiliśmy część ludzi automatami, to raczej nie bardzo będzie kim poprawiać te błędy. Zresztą inwestycja w jedno z podstawowych marnotrawstw opisanych w filozofii Lean Management nie wygląda na dobry business case.

Dlatego właśnie analiza ryzyka, w duchu najlepszych praktyk zarządzania projektem, stanowi podstawę w każdej automatyzacji. Podstawę zbyt często pomijaną przez utalentowanych, jednak zbyt optymistycznych developerów narzędzi EUC (End User Computing).

Dobra wiadomość jest taka, że tu specjalnie nie trzeba niczego nowego wymyślać. Wystarczy zdroworozsądkowa adaptacja modelu zarządzania ryzykiem, dajmy na to z PMBOK. Uproszczony model, który będzie pokrywał 5 z 6 punktów:

• Identyfikacja ryzyka
• Analiza jakościowa ryzyka
• Analiza ilościowa ryzyka
• Plan reagowania na ryzyko
• Monitorowanie i kontrolowanie ryzyka

Pominąłem pierwszy punkt, tj. „Planowanie zarządzania ryzykiem”, ponieważ stoję na stanowisku, że to powinno być wpisane standardy każdej organizacji, czy jednostki biznesowej, która wkomponowała automatyzację w swój model ciągłego doskonalenia procesów.

Jest jeszcze jedna dobra wiadomość.

Już z samej analizy ryzyka wyjdzie nam, czy i gdzie musimy poprzedzić automatyzację rewizją, odchudzeniem i standaryzacją procesów. Te punkty będą nieodzowne, aby wyeliminować problemy, które opisałem w ilustracji przypadku 4% błędów.

Jest i mniej radosna nowina, aczkolwiek z całą pewnością nie negatywna.

Jeżeli automat ma pokrywać dużą liczbę transakcji lub procesy krytyczne dla organizacji, wypada sięgnąć głębiej do metodyk zarządzania projektem.

Tu mam na myśli zarządzanie zmianą i konfiguracją.

Ale o tym innym razem.