Najpierw zrozum wykonywaną pracę
Samo połączenie aplikacji nie musi poprawiać działania firmy. Najpierw opisz przepływ pracy: co go rozpoczyna, jakich informacji wymaga, jaki wynik oznacza zakończenie i kto wyjaśnia niejasności. Możesz odkryć, że niepotrzebny krok warto usunąć zamiast wykonywać szybciej. Dlatego optymalizacja procesu często poprzedza automatyzację. Jeśli ludzie nie potrafią uzgodnić, kiedy faktura jest zatwierdzona, reguła przesyłająca ją dalej przeniesie spór do innego programu. Ustalenie warunków decyzji może przynieść więcej pożytku niż długa sekwencja działań technicznych. W rozmowie powinny uczestniczyć także osoby, które na co dzień zajmują się brakującymi danymi i nietypowymi sprawami klientów.
Zdarzenie, warunek i działanie
Prosta automatyzacja ma zdarzenie uruchamiające, czasem warunek oraz wykonywaną czynność. Zdarzeniem może być wysłanie formularza. Warunek określa, czy zgłoszenie spełnia wymagania, a czynność zmienia dane albo powiadamia człowieka. Opisz te elementy zwykłym językiem. Na przykład: po otrzymaniu zapotrzebowania na sprzęt sprawdź, czy podano miejsce dostawy, a następnie utwórz zadanie do zatwierdzenia. Taki zapis łatwiej omówić niż diagram pełen nieobjaśnionych oznaczeń. Pomaga również zauważyć brakujące sytuacje. Trzeba przecież ustalić, co stanie się ze zgłoszeniem bez adresu oraz z prośbą dotyczącą rodzaju sprzętu, którego wcześniej nie zamawiano i którego nie ma na standardowej liście.
Przykład z fikcyjnej firmy dostawczej
Fikcyjny dostawca otrzymuje formularze z prośbami o wymianę produktu. Pracownicy przepisują numer klienta do listy zadań i dołączają treść zgłoszenia. Mogą zautomatyzować przepisywanie, pozostawiając decyzję o wymianie człowiekowi. Próba powinna objąć poprawny formularz, brakujące informacje, podwójne wysłanie oraz załącznik, którego nie można otworzyć. Ważne jest nie tylko szybkie pojawienie się zadania. Powinno ono mieć właściwy numer sprawy, a niepewne zgłoszenia muszą trafić do widocznej kolejki przeglądu. Ten przykład opisuje sposób projektowania, a nie faktycznie osiągnięte oszczędności. Dopiero obserwacja pracy pokaże, czy nowy układ pomaga zespołowi oraz jakie problemy nadal wymagają ręcznej obsługi.
Wyjątki są częścią normalnego działania
Dane wejściowe bywają niedoskonałe. Może brakować nazwiska, adres może się zmienić, a docelowy program może być chwilowo niedostępny. Ustal, które problemy zatrzymują działanie i które można poprawić później. Cicha awaria jest szczególnie kłopotliwa: brak zadania może wyglądać jak brak zamówienia. Powiadomienie powinno trafić do osoby, która potrafi zareagować, i zawierać informacje pozwalające rozpoznać sprawę. Unikaj zalewu identycznych ostrzeżeń. Przydatny komunikat wyjaśnia, co się wydarzyło, jakie zmiany wykonano i co należy sprawdzić przed kolejną próbą. Dzięki temu odbiorca otrzymuje konkretny problem do rozwiązania, a nie tylko techniczny opis błędu bez wskazania jego znaczenia dla pracy.
Ponowienie nie może bezmyślnie powielać skutków
Systemy czasem wysyłają tę samą wiadomość ponownie. Jeśli wiadomość tworzy zadanie, nie powinna za każdym razem powodować powstania kolejnego identycznego wpisu. Można temu zapobiegać za pomocą stałego identyfikatora, który pozwala rozpoznać już obsłużone zdarzenie. Nie musisz samodzielnie programować takiego rozwiązania, aby o nie zapytać. Poproś wykonawcę o pokazanie podwójnego zgłoszenia oraz ponowienia po częściowym wykonaniu procesu. Dostępne API umożliwia komunikację, lecz nie rozstrzyga tych reguł biznesowych. Liczy się przewidywalne zachowanie po przerwaniu połączenia oraz możliwość przywrócenia pracy bez przypadkowego ponownego wykonania czynności, które zostały już prawidłowo zakończone w drugim systemie.
Człowiek potrzebuje sensownej kontroli
Przegląd wykonywany przez człowieka przydaje się, gdy informacje są niejednoznaczne lub decyzja ma skutki, których prosta reguła nie oceni. Powinien nastąpić przed istotną czynnością i dostarczać odpowiedni kontekst. Zatwierdzanie niewyjaśnionego wyniku zachęca do bezmyślnego klikania. Zapewnij również możliwość zatrzymania automatyzacji oraz tymczasowy sposób ręcznej obsługi. Zespół powinien wiedzieć, czy zatrzymanie blokuje tylko nowe zadania, czy dotyczy również spraw już rozpoczętych. Wyznaczony opiekun musi mieć dostęp do ustawień i dokumentacji. To szczególnie ważne, kiedy autor rozwiązania zmienia stanowisko lub odchodzi, a pozostali pracownicy muszą dalej samodzielnie utrzymywać ciągłość wykonywania codziennych obowiązków.
Oceń pracę w całym procesie
Uwzględnij czynności, które pozostaną po wdrożeniu: przegląd wyjątków, poprawianie danych, utrzymanie połączeń i tłumaczenie zmian współpracownikom. Przyspieszenie jednego kroku nie skróci całego oczekiwania, jeśli następny etap jest przeciążony. Oprócz szybkości sprawdzaj więc błędne skierowania, podwójne rekordy oraz przeoczone zgłoszenia. W całkowitym koszcie posiadania uwzględnij czas potrzebny do utrzymania poprawnego działania. Wąska, czytelna automatyzacja może być użyteczniejsza niż szerokie rozwiązanie, którego awarie potrafi naprawiać tylko specjalista. Zakres zależy od stabilności procesu oraz konsekwencji pomyłki. Nie każdą czynność warto automatyzować tylko dlatego, że technicznie można połączyć odpowiednie aplikacje.
Jak przeprowadzić pierwszą próbę
Wybierz powtarzalny krok z jasnymi danymi wejściowymi i wynikiem, który łatwo poprawić. Zapisz regułę i poproś osobę wykonującą pracę o wskazanie przypadków, w których mogłaby zawieść. Przygotuj zwykłe zgłoszenia i znane wyjątki. Zanim rozszerzysz użycie, porównaj rzeczywisty wynik z oczekiwanym. Zapisz opiekuna rozwiązania, sposób zatrzymania i miejsce wyświetlania błędów. Po próbie zdecyduj, czy regułę rozbudować, zmienić czy usunąć. Odkrycie, że najpierw należy uprościć proces, również jest wartościowym wynikiem. Wcześniejszy wysiłek włożony w konfigurację nie stanowi sam w sobie powodu, aby utrzymywać rozwiązanie, które nie przynosi oczekiwanej pomocy.
Częste pytania
Czy automatyzacja zawsze wymaga sztucznej inteligencji?
Nie. Wiele przydatnych rozwiązań działa na podstawie jasno ustalonych reguł. Jeśli decyzję można jednoznacznie opisać, taki mechanizm jest czytelny. Bardziej elastyczne technologie wprowadzają dodatkowe pytania o wiarygodność wyniku i potrzebny zakres kontroli.
Czy można automatyzować zmieniający się proces?
Można, ale utrzymanie może kosztować więcej pracy niż przynieść korzyści. Zacznij od stabilnego fragmentu i przeglądaj regułę po zmianach. Tymczasowe ustalenia, które wkrótce mają zostać zastąpione, rzadko są dobrym fundamentem rozbudowanej automatyzacji.
Co zrobić, gdy połączenie przestanie działać?
Błąd powinien być widoczny dla odpowiedzialnej osoby, a system musi zachować informacje potrzebne do bezpiecznego wznowienia. Sprawdź, czy ponowienie nie powtarza już zakończonych działań. Sam restart techniczny nie zawsze jest obojętny dla danych i obsługiwanych spraw.