(streszczenie referatu na konferencji zorganizowanej 30 stycznia 2025 przez pureconferences.pl).
Wprowadzenie
Narzędzia zwane low-code oraz no-code znane są od czasów komputerów zwanych biurkowymi (np. narzędzie Clarion, 1986 rok), takim narzędziem jest był arkusz kalkulacyjny VisiCalk a potem Lotus 123 (1979). Szybo się okazało, że tak zwany biznes po prostu przenosi do tych narzędzi to co i jak robi “na papierze” bez zastanawiania się czy to ma sens. Dzisiaj to zjawisko nazywamy “eksceloza” i nie przypadkiem ma to słowo charakter pejoratywny.
Aplikacja
Powyższy diagram można w różnych formach spotkać u wielu autorów . To tak zwana architektura SOA: ang. Service Oriented Architecture, czyli Architektura Zorientowana na Usługi, i nie jest to architektura oprogramowana a architektura organizacji. Diagram pokazuje to co dzisiaj nazywamy “Architektura Korporacyjna” (ang. Enterprise Architecture) albo “Target Operating Model” .
Do czego nam ta architektura? Projektowanie tak zwanych robotów programowych to nic innego jak projektowanie aplikacji/usług, które one potem realizują, lub koordynują. Roboty automatyczną komunikację miedzy aplikacjami na trzecim poziomie. Takie roboty to najczęściej skrypty integracyjne: pobierają i zapisują dane z serwerów wg. ustalonych reguł. Bywa, że dane te są dodatkowo przetwarzane. Jeżeli jest to tylko przenoszenie danych, roboty te mogą być “budowane” jako usługi aplikacji integrowanych (patrz artykuł Integracja ERP oraz Czym jest webhook).
Kluczem do projektowania robotyzacji nie jest analiza tych aplikacji a analiza procesów biznesowych (warstwa 1 na powyższym diagramie) bo tam jest kontekst.
Modele procesów biznesowych czyli dokument i procedura
Kluczem do “robotyzacji procesów biznesowych” są modele tych procesów. Poprawnie opracowane modele procesów pokazują dokumenty, aktywności i procedury (zadanie na modelu procesów w BPMN to nazwa procedury, patrz artykuł Procesy a procedury). Planowanie robotyzacji polega na:
- analizie i opracowaniu sformalizowanych modeli procesów bizneowych,
- wskazaniu i testowanie miejsc możliwych do automatyzacji: to są miejsca dla których wykażemy, że nie istnieją w nich wyjątki,
- opracujemy scenariusze, przetestujemy je na modelach, przekażemy do implementacji.
Kluczowe błędy robotyzacji
Podstawą i celem istnienia “systemów informatycznych” jest przetwarzanie danych niosących informacje: komputer nie przetwarza informacji tylko dane wg. ustalonych reguł . Przetwarzanie informacji jest cechą ludzi i ich mózgów .
Dlatego planowanie robotyzacji wymaga opracowania wspólnej dla całej organizacji ontologii, czyli wspólnego spójnego słownika pojęć. Powodem jest to, że formularze (ich nazwy, nazwy pół i ich wartości) oraz reguły ich przetwarzania, to słowa. Słowa te wszędzie muszą oznaczać to samo albo żadna integracja i robotyzacja nie będzie możliwa do efektywnego przeprowadzenia.
Podsumowanie
Po prawej stronie przywoływana na początku referatu “Architektura Korporacyjna” (ang. Enterprise Architecture) zwana także “Target Operating Model” . Nasze żywe, istniejące organizacje to ta najniższa warstwa. To co jest nam potrzebne do planowania wszelkich wdrożeń to warstwa środkowa: procesowy i informacyjny model organizacji. To tu można znaleźć obszar do automatyzacji, przetestować pomysł (proof of concept), opracować jego ostateczną postać, i dopiero zlecić implementację.
Bardzo ważną rzeczą jest prowadzenie etapu analizy i projektowania po swojej stronie (zbudowanie kompetencji w firmie lub ich wynajęcie), by uniknąć uzależnienia od dostawców systemów. Posiadanie praw majątkowych do dokumentacji metod, scenariuszy i algorytmów robotyzacji-automatyzacji, daje z automatu prawa do kodu, i jest kluczowe dla zarządzania własnym know-how.
