Powróćmy do klocków typu lego jako do pewnego wzorca porównania dla Webcon. W poprzednim artykule porównywałem budowanie i konstruowanie z klocków do tworzenia procesów w tytułowym narzędziu. Omawialiśmy możliwości, kreatywność, nieograniczoną (prawie) realizację naszych pomysłów – tak aby dostarczyć dla biznesu wymarzony przez niego proces. Mowa o procesie, którego zadaniem jest usprawnienie, przyspieszenie i generalnie zoptymalizowanie go poprzez jego digitalizację.
Dzisiaj też chciałbym pobawić się Lego, jednak w trochę innym wymiarze. Bardziej skupić się na tym, jak możemy połączyć Webcon z innym miejscami, aby otrzymać z nich dane czy też dodatkowe możliwości. To może wpierw: Dlaczego Lego?
Powodów jest kilka. Pierwszym z nich jest dostępność – mamy je w domu i możemy budować z dziećmi w każdej chwili. Możemy również obserwować, jak one je wykorzystują. Drugim powodem jest… znajomość ludzi, którzy potrafią z niego wyczarować niesamowite konstrukcje.
Posiadam klocki Lego dla różnych kategorii wiekowych, jednak wszystkie je można ze sobą połączyć (za wyjątkiem Duplo). Można używać klocków z różnych zestawów czy też serii, łączyć je ze sobą, budować coraz to większe, bardziej niesamowite konstrukcje. Można także przyłączyć do nich klocki innych producentów, oczywiście o ile ich łączenia do siebie pasują. Bardzo podobnie jest w Webcon: możemy do niego podłączyć wiele różnych systemów poprzez wbudowane konektory. Zapewnia nam to możliwość przekazywania danych w trakcie procesu, pobierania ich, reagowania na ich zmianę czy też wykonania weryfikacji w innym systemie. Jednak w porównaniu do klocków innych firm, gdzie muszą nam pasować połączenia, Webcon ma znaczącą przewagę. Pozwala bowiem napisać własne konektory, czy też źródła danych, nawet z bardzo nieszablonowych miejsc. W tym przypadku jedynym ograniczeniem jest nasza wyobraźnia lub zdolności programistyczne
Skoro już nakreśliłem, w jakim obszarze budowania z klocków tym razem będziemy się przemieszczać, to czas na jakąś konkretną budowlę. Zacznę od zaprezentowania przykładowego schematu, gdzie będziemy wykorzystywać różne rodzaje klocków i ich łączenia. Krótka legenda oznaczenia na schemacie:
- Kolorem pomarańczowym oznaczony jest system, do którego będzie/jest stworzona integracja
- Kolorem niebieskim są oznaczone kroki w procesie
- Kwadratowe – kroki użytkownika
- Romb – warunkowe
- Eliptyczne – automatyczny start procesu
- Linie przerywane – wywoływania integracji do systemów zewnętrznych
- Linie ciągłe – przejścia w procesie
Oczywiście jest wiele innych możliwości nie pokazanych na schemacie, z których będziemy mogli korzystać. O nich wspomnę w trakcie opisywania poszczególnych mechanizmów integracyjnych, które możemy sobie wyobrazić w realnym użyciu. Trzeba również mieć na względzie, że czasem najprostsze rozwiązanie połączenia klocków nie będzie optymalne. Należy także pamiętać, że wybór odpowiedniego sposobu komunikacji będzie znacząco wpływał na szybkość działania naszego procesu, ale również na reaktywność dla użytkowników. Zawsze spójrzmy na ilość danych, jakie będziemy potrzebowali odczytać, przetworzyć, przesłać. Warto się również zastanowić, czy konkretne dane są na potrzebne natychmiast, czy możemy je otrzymać z opóźnieniem lub wystarczy raz dziennie je aktualizować. Podobnie jest, gdy mam pomysł na zbudowanie np. tankowca z klocków, gdzie już na etapie planowania musimy przemyśleć, co będzie dobrą podstawą całej konstrukcji lub jak dużo klocków danego typu będziemy potrzebować, jak szeroki ma być tankowiec, etc. Zaplanowanie poszczególnych kroków jest w obu przypadkach kluczowe, aby osiągnąć zamierzony efekt WOW.
Pierwszym naszym połączeniem klocków jest wykorzystanie wbudowanego mechanizmu przeglądania skrzynki pocztowej (Exchange) w Webcon, który co jakiś czas sprawdza, czy pojawiły się nowe maile od kontrahentów, a kiedy taki odnajdzie, zaczytuje go do systemu. W założeniu odczytujemy podstawowe dane z maila, takie jak: adres nadawcy, tytuł maila oraz datę otrzymania. Również na poziomie wczytywania załączników możemy określić, jaki ich rodzaj chcemy obsługiwać (w naszym przypadku zakładamy dokumenty PDF). To tak jak przy budowaniu naszego statku przyjmiemy, że kadłub chcemy mieć tylko w kolorze czerwonym.
Wiemy, że nasz statek będzie potrzebował napędu, więc na etapie budowania kadłub dodaje śruby napędowe oraz mechanizm, który będzie je uruchamiał. Do tego musimy użyć innego rodzaju klocków, dodatkowych, z innego zestawu. Tak samo w naszym procesie – chcąc go jak najbardziej zautomatyzować – użyjemy możliwości odczytania danych (OCR) z przesłanej faktury. Jest to dodatkowa funkcja Webcon, jednak w przypadku faktur bardzo przydatna. Po odczytaniu danych z naszego dokumentu, na którym jest numer zamówienia z naszego systemu, umieszczamy dane na formularzu w aplikacji. Następnie proces automatycznie na podstawie informacji, czy posiada odczytany identyfikator zamówienia, przechodzi do weryfikacji spółki lub przekazuje zadanie do weryfikacji ręcznej dokumentu do określonej w procesie osoby.
System przypisuje spółkę automatycznie do procesowanego dokumentu na podstawie domeny z adresu email. W obu przypadkach wykonujemy weryfikację numeru zamówienia w systemach zewnętrznych. W przypadku Spółki 1 weryfikacja odbędzie się w systemie ERP poprzez wywołanie REST API z ustawionymi odpowiednim filtrami. Dla Spółki 2 użyjemy możliwości rozszerzenia systemu o niestandardowe źródło danych, którego zadaniem będzie przedstawienie danych w formie tabeli, na której będziemy mogli wykonać odpowiednie zapytanie weryfikujące, czy posiadamy w zbiorze wskazany numer zamówienia. Porównując to do naszego przykładu budowy statku, możemy użyć dźwigu, który już mamy zbudowany np. na kółkach jako opcji do ładowania, albo zbudować specjalnie skonstruowany, dopasowany do wielkości naszego okrętu dźwig, który będzie zbiorem różnego typu klocków. Taka dedykowana funkcjonalność dźwigu pozwoli nam np. suwać nim po burtach, gdyby było to koniecznością, jeśli chcielibyśmy np. aby klapy luków załadunkowych otwierały się na boki.
Jak widać na schemacie, w przypadku kiedy nie udaje się zweryfikować naszego zamówienia w systemach zewnętrznych, kolejne zadania są przypisane do odpowiednich pracowników celem poprawienia/sprawdzenia danych, które są na procesie. Po ich weryfikacji lub odnalezieniu zamówienia, przechodzi się do kroku, w którym następuje próba zweryfikowania pozycji zamówienia w stosunku do odczytanych danych z dokumentu. Jednak tutaj wykonuje to pracownik, porównując dane pobrane z ERP/pliku z danymi na dokumencie.
Po weryfikacji następuje sprawdzenie, czy koszty związane z przekazaną fakturą są zabezpieczone w budżecie, czy jednak dla danego zakresu np. działu zostały one przekroczone i powinny trafić do obsługi ręcznej pod kątem zmiany kategorii lub akceptacji odpowiedniej osoby. Schemat jest uproszczony, jednak możliwości dodania dodatkowych kroków są nieograniczone, o ile dane pozwalają jasno zadeklarować ścieżkę postępowania.
Przedostatnim krokiem w naszym schemacie jest przejście do przeglądu danych oraz rozliczenie faktury. Informacja o rozliczeniu faktury oraz jej dalszym losie w ERP nie jest potrzebna natychmiast, ponieważ ważniejsza jest pewność, że zostanie przekazana w odpowiednie miejsce. W tym przypadku wykorzystamy do tego szynę integracyjną, która zapewni nam niezawodność i równocześnie nie zablokuje procesu w przypadku niedostępności innego systemu. Do komunikacji z szyną możemy wykorzystać kilka metod w zależności od wybranego producenta/dostawcy, ponieważ każdy z nich dostarcza inne formy obsługi lub tworzenia elementów szyny. Możemy tutaj wykorzystać rozwiązania komercyjne, gdzie budowanie komunikatów, ich przepływu będziemy mieli od razu w narzędziu, czy też tańszych, w których elementy komunikacji z szyną będziemy musieli napisać sami. Tutaj zawsze jest kwestia porównania nakładu pracy do czasu jaki posiadamy, no i oczywiście finalnie kosztów finansowych
Po przejściu przez krok „Rozliczenie faktury” zostaje wysłana informacja do szyny integracyjnej, a nasz proces przechodzi do kolejnego kroku, w którym oczekuje na informację o zaksięgowaniu faktury. Informacja poprzez szynę trafia do systemu ERP, ale również do bazy danych raportowej o nowych kosztach. Po przetworzeniu i zaksięgowaniu zostaje ponownie wrzucony komunikat, który zawiera informację o zaksięgowaniu i zostaje on przekazany do procesu. Tutaj również nie mamy krytyczności natychmiastowej informacji o przetworzeniu w ERP rozliczenia, ale krytycznym jest pewność zwrócenia danych do procesu.
Po otrzymaniu zaksięgowania faktury proces prawie się kończy. Na sam koniec aplikacja wysyła informację do kontrahenta o zaksięgowaniu jego rozliczenia oraz w jakim czasie zostanie zrealizowany przelew środków. Tutaj również wykorzystujemy wbudowany mechanizm wysyłki mailowej, komunikujący się z serwerem pocztowym. Sam mail jest zbudowany w ramach naszego procesu i zostają w nim przekazane dane, które są zawarte w naszym formularzu.
Jak widać na tym prostym przykładzie, w ramach naszego tworzenia procesu możemy wykorzystać wiele różnych metod integracji z systemami zewnętrznymi. Zaczynając od wywoływania zapytań na bazach danych, odpytywania/wysyłania danych do WebService (REST, SOAP), wywoływania szyn integracyjnych aż na końcu budowaniu własnych dodatkowych komponentów integracyjnych. Dzięki tej elastyczności, która wynika z możliwości podłączenia do innych systemów, nasze procesy mogą stać się świetnymi narzędziami do weryfikacji danych, zarządzania kosztami, sprawdzania stanów magazynowych itp. zależnie od naszej wyobraźni i potrzeb łączenia klocków. Równocześnie zapewniają pełną interaktywność z użytkownikiem, dają mu pełen wgląd w potrzebne dane czy też czynności, które musi wykonać, to też nadal zabezpieczają dostęp do systemów powiązanych przed niepowołanymi do tego osobami.
To tak jak z naszym statkiem. Do jego wymyślenia potrzebowaliśmy uruchomienia wyobraźni. Do budowy musieliśmy użyć różnych rodzajów klocków. Na kadłub wystarczyły zwykłe konstrukcyjne czy z zestawów. Dla mechanizmów otwierających klapy luków czy wejścia do sterówki konieczne były już części z gotowych komponentów lub części z innych zestawów. Aby nasz statek mógł pływać, musimy już użyć klocków technicznych, przekładni itp., które przy połączeniu z baterią dadzą napęd. Aż po nasze niestandardowe, dopasowane do naszych potrzeb rozwiązania wymagające użycia w nietypowy sposób części klocków lub nawet stworzenie własnych np. na drukarce 3D.
Zabawa w utworzenie takiego statku zajmuje nam oczywiście sporo czasu, wymaga poświecenia się i dużej uwagi. Czasem wymaga wielu poprawek czy powrotu do początku tworzenia. Końcowy efekt sprawia nam jednak wiele radości, przyjemności oraz pozwala docenić siebie. Podobnie jest w przypadku budowania procesów w aplikacji. Oczywiście patrzymy tutaj w innych kategoriach użycia, a co za tym idzie również oceny. Niemniej jednak, kiedy dostaniemy informację od Klienta o jego zadowoleniu z usprawnienia jego procesów, czujemy się równie usatysfakcjonowani.
Dla mnie taki feedback jest bardzo ważny i sprawia mi jeszcze większą przyjemność z tego, co robię w pracy na co dzień i jednocześnie motywuje mnie do dalszego budowania i konstruowania coraz to lepszych, większych i bardziej skomplikowanych konstrukcji, gdzie słyszę: „WOW – to tak się da?!”
Hubert Chadaj – Transition Technologies MS
Zapraszamy do odwiedzenia naszego podcastu Odkodowujemy IT i posłuchania odcinka, poświęconego Webcon BPS: