Czy efektywność robotów zagraża miejscom pracy urzędników? Robotyzacja w samorządzie

Powszechnym problemem jednostek samorządu terytorialnego są braki kadrowe, zwłaszcza wobec ogromnej i stale powiększającej się w ostatnich latach ilości zadań raportowych. Duża część zadań z tego zakresu spełnia kryteria wymagane do robotyzacji. Jeśli czynności te zostaną przekazane do wykonania robotowi, czas urzędników zostanie uwolniony, na zadania, które są bardziej satysfakcjonujące oraz wymagające ludzkiego intelektu. Robot nie zagraża pracy urzędników a wręcz przeciwnie, jest w stanie ich wesprzeć, podnosząc satysfakcję z wykonywanej pracy oraz zajmując się powtarzalnymi i żmudnymi zadaniami. 

Współpraca urzędnika z robotem może przynieść wiele korzyści, usprawniając pracę całego urzędu. Przykładem robotyzacji, która pomogła usprawnić komunikację na linii urząd – mieszkańcy miasta oraz uwolnić urzędników od wykonywania prostych, powtarzających się czynności, było wdrożenie w Gdyni asystenta głosowego – voicebota. Analizuje on mowę i m.in. umawia mieszkańców na wizytę w urzędzie przy konkretnym stanowisku, co powoduje wyeliminowanie kolejek w budynku oraz znaczne skrócenie czasu oczekiwania na połączenie. 

Jak więc przygotować urząd do tego typu wdrożenia? 

Organizacja struktury urzędu na potrzeby robotyzacji procesów - dobre praktyki

Struktura urzędu powinna umożliwiać poświęcanie zagadnieniu robotyzacji części czasu pracy co najmniej dwuosobowego zespołu, który byłby w stanie koordynować prace związane z przygotowaniem procesów do zmiany. Warto w urzędzie powołać pełnomocnika ds. robotyzacji procesów lub udzielić takiego pełnomocnictwa osobie już piastującej podobne stanowisko w urzędzie, razem z przydzielaniem zadań do realizacji (np. zespół SmartCity lub zespół ds. audytu wewnętrznego). 

Do zadań takiego zespołu, pod nadzorem pełnomocnika ds. robotyzacji procesów, powinny należeć m.in.:

• badanie gotowości organizacji do wdrażania robotyzacji poszczególnych zadań;
• opracowanie i rozwijanie strategii wdrażania robotyzacji zadań;
• współtworzenie interdyscyplinarnych zespołów odpowiedzialnych za realizację przekrojowych zadań;
• przygotowywanie kompleksowych analiz i audytu procesów zachodzących w urzędzie, pod kątem możliwości robotyzacji i usprawniania;
• wspieranie innych wydziałów i projektów miejskich przez wdrażanie robotyzacji zadań;
• wspieranie kultury zarządzania miastem opartej na współpracy urzędników i robotów, dzięki dokumentowaniu usprawnień osiągniętych dzięki wdrażaniu robotyzacji.

Jeżeli utworzenie takiego zespołu nie jest możliwe, warto jego najistotniejsze zadania przypisać do poszczególnych jednostek urzędu.

W Urzędzie Miasta Bydgoszczy, zadania związane z audytowaniem istniejących procesów pod kątem możliwości robotyzacji realizuje Zespół Audytu i Kontroli Zarządczej, który we współpracy z poszczególnymi wydziałami UM analizuje i wybiera obszary, którymi efektywnie zajmie się robot. 
 

Infrastruktura IT – istniejąca i wymagana

Robota da się połączyć z infrastrukturą IT urzędu na kilka sposobów, m.in. poprzez:

1. przesyłanie danych od dostawcy do robota zainstalowanego na zewnętrznych serwerach.
2. instalację robota na serwerach dostawcy wewnątrz urzędu, bez konieczności przesyłania wrażliwych danych za pośrednictwem internetu.

W zależności od poziomu skomplikowania robota i obszarów, którymi się zajmuje, możliwa jest kombinacja dwóch powyższych modeli. 

Istotny jest zaś fakt, że wdrożenie robota nie wymaga żadnych drastycznych zmian w dotychczasowej istniejącej infrastrukturze IT urzędu. Być może trzeba będzie dostosować kilka ustawień i zrobić dostęp do systemów dla robota, ale środowisko aplikacyjne, sprzęt i sposób funkcjonowania w większości przypadków może pozostać niezmieniony.

Kluczowe funkcjonalności i wymogi

Biegły - niezależny ekspert

Przy podejmowaniu się robotyzacji, istotna jest rola kompetentnej osoby biegłej w sprawach technicznych. Może to być programista, kierownik projektu lub inna osoba, która zna możliwości rynkowe, technologie oraz, co bardzo istotne, kontekst i środowisko samorządowe. Ekspert to niezależna osoba, w żaden sposób nie związana z dostawcą technologii. Jego rola polega na bezstronnym weryfikowaniu poprawności założeń, specyfikacji i zmapowania robotyzowanego procesu.

Przyszłość systemu – utrzymanie i rozbudowa

Przygotowując specyfikację projektu należy pomyśleć również o tym, jak system będzie wykorzystywany w przyszłości. Należy zrobić analizę, jak podobne robotyzacje w innych organizacjach, np. innych urzędach czy też firmach prywatnych rozwinęły się, na czym polegała ich rozbudowa oraz jak wyglądało ich utrzymanie. Następnie należy sformułować specyfikację tak, żeby aktualny projekt mógł być podstawą, na której będzie można pracować w przyszłości. 

Tworzenie systemów jednorazowego użytku, nie dość, że pochłania ogromne koszta, to jeszcze sprawia, że praca ludzi i energia zużyta do wytworzenia danego oprogramowania nie zostaje w pełni wykorzystana. Oprogramowanie, które nie pozwala na integracje z innymi aplikacjami, nie umożliwia rozbudowy w przyszłości lub jest wykonane z wykorzystaniem technologii, która jest lub niedługo będzie przestarzała, mija się z celem. Czasami lepiej nie robotyzować i poczekać na nową technologię lub właściwszą dokumentację procesów.

Eksport danych z systemu

Aktualne tendencje i oczekiwania mieszkańców jasno pokazują, że wykorzystanie danych publicznych do optymalizacji kosztów oraz poprawiania jakości życia w mieście, to działanie coraz bardziej oczekiwane, a już niedługo wymagane. Zbierane i tworzone przez rozmaite systemy dane, często będą musiały mieć możliwość eksportu, by zasilać informacjami przyszłe projekty.

Jak piszą Leszek Kotulski i Maciej Gnela w publikacji „Zarządzanie danymi w miastach”:
„[...] Warto zwrócić większą uwagę na specyfikację zakresu i sposobu danych w SWZ – dołożenie wymagania wyeksportowania dowolnych danych z reguły nie podnosi kosztu tej aplikacji w chwili jej zamawiania, natomiast stanowi znaczne koszty, gdy zażyczymy sobie tej usługi po jakimś czasie. [...] Zwróćmy uwagę, że koszt modyfikacji systemu nie podlega już ograniczeniom wynikającym z procesu przetargowego, a wprost przeciwnie – jest dyktatem monopolisty. Oznacza to, że każdorazowe rozbudowanie systemu jest całkowicie uzależnione od pierwotnego dostawcy i miasto jest skazane na przyjęcie jego warunków cenowych.”.

Bezpieczeństwo

Operowanie na procesach, zadaniach i danych, do których w codziennej pracy w urzędzie robot będzie miał dostęp, wymaga zapewnienia wysokich standardów bezpieczeństwa. Musi być zgodny z przepisami RODO oraz normami bezpieczeństwa ISO 27 001. 

W ocenie Leszeka Kotulskiego i Macieja Gnela zawartej w publikacji „Zarządzanie danymi w miastach”, podstawowym problemem w budowaniu systemu bezpieczeństwa jest kwestia „najsłabsze go ogniwa”, co oznacza, że całkowite bezpieczeństwo zależy od najgorzej zabezpieczonego miejsca w instytucji. Bardzo często takim „najsłabszym ogniwem” jest człowiek używający powtarzalnych i mało skomplikowanych haseł zabezpieczających.

Kluczowy jest cel integracji danych czy systemów informatycznych, które zawierają w sobie dane osobowe wg. RODO. Jeżeli cel, dla którego zbierano powyższe dane jest zgodny z celem ich wykorzystania w nowo tworzonym rozwiązaniu, nie trzeba ich anonimizować.

Dane dostępne publicznie nie wymagają ochrony RODO, np. dokumenty finansowe związane z publiczną działalnością miasta. Tego typu dane można udostępniać bez obaw dostawcy technologii, dzięki czemu zrobotyzowany proces jest obsługiwany wydajniej i taniej, bez potrzeby integrowania w infrastrukturę IT urzędu. Jeżeli obsługiwane dane wymagają ochrony RODO, wtedy należy rozważyć zlokalizowanie danych w infrastrukturze IT urzędu, by chronione dane były bezpieczne.

Często dostawcy oferują wsparcie w zakresie dostarczania rozwiązań dla infrastruktury IT urzędu, takie jak komputery i serwery, które pozwalają na sprawne działanie robota operującego na wrażliwych danych, bez wystawiania ich na potencjalne zagrożenie przesyłając je do dostawcy za pośrednictwem internetu, ale zapewniając ich obsługę, dzięki czemu codzienne funkcjonowanie robota i obsługa awarii nie wymaga angażowania zasobów urzędowego departamentu IT. 

Wybór dostawcy i tryb zamówienia

Odpowiednia współpraca z dostawcą jest jednym z kluczowych elementów projektu. Warto pamiętać, że zwłaszcza w przypadku rozwiązań informatycznych, należy zakładać długoterminową współpracę z dostawcą, bo poza wdrożeniem i utrzymywaniem platformy, prawdopodobnie trzeba będzie ją dalej rozwijać, a najlepiej żeby pracę kontynuował ten sam wykonawca. 

Koszt wdrożenia a koszt utrzymania

Niska cena wdrożenia produktu nie zawsze okazuje się być najbardziej optymalnym rozwiązaniem, kiedy porównamy koszty wdrożenia (CAPEX) z kosztami utrzymania (OPEX). W ujęciu rocznym, może się okazać, że lepiej zainwestować w rozwiązanie droższe na początku, ale tańsze w utrzymaniu. Biorąc pod uwagę fakt, że wdrażane rozwiązania muszą funkcjonować w urzędzie przez wiele kolejnych lat oraz być rozbudowywane, koszt utrzymania może mieć dużo większe znaczenie, niż koszt początkowego wdrożenia. 

Efektywna ocena ofert

Ocena ofert jest kluczowa w odpowiednim wyborze dostawcy. Nie sposób ocenić ofert porównując dziesiątki stron dokumentacji, dlatego warto stworzyć dokument, w którym wymogi i parametry specyfikacji będą mogły odpowiadać parametrom rozwiązania dostarczanego przez dostawcę. Dzięki takiemu rozwiązaniu po wpisaniu wszystkich parametrów specyfikacji dokumentu, możesz poprosić dostawcę o wprowadzenie obok, w tym samym dokumencie, informacji o parametrach dostarczanego rozwiązania. Kiedy otrzymasz pełny dokument, możesz łatwo sprawdzić zgodność założeń z parametrami produktu, który ma do zaoferowania dostawca, używając formuły sprawdzającej zgodność w arkuszu kalkulacyjnym. 

Umowa, model rozliczeniowy i zobowiązania dostawcy

Forma umowy i forma finansowania ma kolosalne znaczenie. To, co zostanie w niej ujęte oraz to, co nie zostanie w niej ujęte, ma wpływ na to, co finalnie zostanie dostarczone. Należy upewnić się, we współpracy z niezależnym ekspertem, że nasz opis przedmiotu zamówienia jest odpowiednio, czyli jasno i klarownie sformułowany.

Modele rozliczeniowe w których funkcjonują dostawcy we współpracy z samorządem, to najczęściej:

Subskrypcja - robot jako usługa

Najdogodniejszym sposobem finansowania dla samorządu jest subskrypcja, dzięki której samorząd, płacąc niewygórowaną cenę, otrzymuje robota w formie usługi, która jest ciągle obsługiwana oraz aktualizowana i rozbudowywana w razie potrzeby, gdy środowisko obsługi zrobotyzowanego procesu w urzędzie się zmieni, bez dodatkowych kosztów. Ryzyko jest tutaj przeniesione na dostawcę, który najlepiej będzie umiał zarządzać zaistniałą sytuacją.

Jeżeli obsługa danych zadań zostanie przeniesiona na robota, wówczas, w razie jego awarii, dane procesy nie są obsługiwane. Czas reakcji na awarię jest więc kluczowy i w takiej sytuacji, rozwiązanie w którym to dostawca odpowiada za poprawne funkcjonowanie robota zdaje egzamin najlepiej, dzięki czemu robot wraca do pracy tak szybko, jak to możliwe, bez konieczności zlecenia napraw trybem formalnym lub dostosowywania robota do zaistniałych zmian.

Czas i materiał ( ang. Time and material)

Czas i materiał to model rozliczania współpracy z dostawcą, w którym specyfikacja projektu może się zmieniać w trakcie jego wykonywania, a płaci się dostawcy za czas i materiał służące do wytworzenia danego produktu. 

Warto go zastosować w projektach, gdzie na początku trudno sprecyzować dokładnie co ma zostać wykonane, a w efekcie, co ile będzie kosztować. 

W tym modelu ryzyko, że projekt będzie kosztował więcej, niż na początku zakładamy, jest po stronie zamawiającego, bo to on płaci za materiał i czas dostawcy, które, w przypadku podniesienia poziomu trudności, skali, skomplikowania projektu a także uwarunkowań ekonomicznych np. ceny materiału, podwyżek płac itd. mogą diametralnie wzrosnąć zarówno przed, jak i w czasie realizacji projektu. 

Stała cena (ang. Fixed price)

Zamówienie robota, jako usługi wiąże się z szeregiem korzyści, ale ma też pewne wady. Warto tutaj wspomnieć, że, duża część projektów robotyzacji realizowana jest w modelu fixed price. Dzięki współpracy z dostawcą w modelu stałej ceny (ang. Fixed price) jesteśmy w stanie znać pełną cenę projektu, jeszcze przed jego wykonaniem. Minusem takiego rozwiązania, jest to, że dostawca, chcąc zminimalizować ryzyko poniesienia dodatkowych kosztów, w razie, jeśli projekt rozrośnie się, względem niekompletnej specyfikacji początkowej, podnosi finalną cenę całego projektu.

Zamawiający w tej sytuacji nie ponosi odpowiedzialności za to, że wcześniej ustalona specyfikacja okaże się, w toku projektu bardziej kosztowna w realizacji, dzięki czemu po stronie zamawiającego nie ma ryzyka poniesienia dodatkowych kosztów. 

Opracowano we współpracy z firmami ForProgress i Wizlink, oraz na podstawie:

1. The Use of Robotic Process Automation (RPA) as an Element of Smart City Implementation: A Case Study of Electricity Billing Document Management at Bydgoszcz City Hall
   https://www.mdpi.com/1996-1073/14/16/5191/htm
2. Zarządzanie danymi w miastach. Podręcznik dla samorządów
   https://irmir.pl/news/zarzadzanie-danymi-w-miastach-podrecznik-dla-samorzadow/