KTBnet

Punkt kontrolny bota przy wznowieniu

Wyobraź sobie, że pracujesz nad projektem. Określasz swój cel, prawdopodobnie zapisujesz, co należy zrobić, a następnie skreślasz każdą z tych czynności…

Opis wyzwania

Wyobraź sobie, że pracujesz nad projektem. Określasz swój cel, prawdopodobnie zapisujesz, co należy zrobić, a następnie skreślasz każdą z tych czynności, gdy je po kolei wykonujesz. Ten projekt prawdopodobnie zajmie trochę czasu – musisz spać, a trudno jest się skupić i być produktywnym przez cały dzień, prawda? Ponadto są rozpraszacze. Więc kiedy wracasz do pracy nad projektem (zwłaszcza po jakimś czasie) i chcesz kontynuować, od czego zaczynasz? W moim przypadku – wziąłbym tę kartkę papieru i sprawdził, co już zostało zrobione i co należy zrobić dalej, aby określić, na jakim etapie jest obecnie proces ukończenia projektu.

Teraz, gdy bot pracuje nad ukończeniem procesu, mogą wystąpić nieoczekiwane przerwy, takie jak problemy z siecią itp. W przypadku prostych automatyzacji zwykle można go ponownie uruchomić i po prostu zacząć od początku procesu. Jednak czasami są czynności, których nie można powtórzyć po ich ukończeniu – co wtedy? Wtedy bot powinien zerknąć na swoją kartkę papieru.

Odpowiedź

Podczas identyfikacji ostatnio zautomatyzowanego procesu użytkownicy biznesowi poprosili, aby niektóre transakcje SAP były wykonywane tylko raz dla danego zestawu parametrów. Dodatkowe żądania obejmowały zapisywanie przez bota danych wytworzonych podczas przetwarzania do plików Excel opartych na MS Teams, zawierających dane wejściowe dla różnych etapów procesu. Ze względu na wymagania bot musi sprawdzić swój stan przed rozpoczęciem przetwarzania. Wynikowa procedura, w uproszczonej formie, jest pokazana na poniższym diagramie BPMN:

Uproszczona procedura samodostosowania

Zauważ, że możemy określić łącznie 6 stanów początkowych bota, każdy z nich poprzedzony jest warunkiem węzła sprawdzającego warunek przejścia – jeśli dany warunek jest spełniony, bot pomija odpowiedni etap:

Stany w procedurze uruchamiania

Co więcej, po bliższym przyjrzeniu się, możemy zajrzeć głębiej i zobaczyć, że zakładając, że bot zaczyna od stanu 1, szczęśliwa ścieżka całkowicie pomija stan 2 i przechodzi bezpośrednio do stanu 3. W przypadku niepowodzenia części procesu Generowanie Dokumentów, bot wznawia stan 2, który wymaga wprowadzenia danych przez użytkownika poza wykonaniem bota – numer dokumentu może być już wygenerowany, ale nie podany w pliku, co skutkuje niepowodzeniem:

Rozszerzone stany

Wnioski

W zależności od złożoności zautomatyzowanego procesu, określenie stanów bota podczas wykonywania może być trudne. Liczba punktów kontrolnych zwiększa bezpieczeństwo przetwarzania danych, jednak kosztem ciągłego zapisywania i przesyłania danych, co zmniejsza wydajność wykonania. Ryzyko można zarządzać, stosując różne sposoby zachowania stanu bota. Excel jest przyjaznym dla użytkownika, ale czasochłonnym rozwiązaniem. Z drugiej strony, jeśli proces wymaga komunikacji i opóźnionych danych wejściowych od użytkowników końcowych lub jest podatny na wielokrotne wznawianie, rozwiązanie to pomaga oszczędzać zasoby.

Michał Lutoborski
Konsultant Power Platform | KTBnet

Weteran rozwiązań CRM z doświadczeniem RPA i BPM, oddany projektowaniu, optymalizacji i wdrażaniu procesów biznesowych. Entuzjasta Power Platform i Cloud.

Optymistyczny ekstrawertyk wierzący w sukces poprzez ciągłe samodoskonalenie, rozwijając pasję i zainteresowania. Gotowy na nowe wyzwania.