Zostaw swoje dane kontaktowe, a my wyślemy Ci nasz przegląd e-mailem
Wyrażam zgodę na przetwarzanie moich danych osobowych w celu przesyłania spersonalizowanych materiałów marketingowych zgodnie z Regulaminem. Politykę Prywatności. Potwierdzając zgłoszenie, użytkownik wyraża zgodę na otrzymywanie materiałów marketingowych
Dziękuję!

Formularz został pomyślnie przesłany.
Więcej informacji można znaleźć w skrzynce pocztowej.

Innowise jest międzynarodową firmą tworzącą oprogramowanie w pełnym cyklu założona w 2007 roku. Jesteśmy zespołem ponad 1600 specjalistów IT tworzących oprogramowanie dla innych profesjonalistów na całym świecie. profesjonalistów na całym świecie.
O nas
Innowise jest międzynarodową firmą tworzącą oprogramowanie w pełnym cyklu założona w 2007 roku. Jesteśmy zespołem ponad 1600 specjalistów IT tworzących oprogramowanie dla innych profesjonalistów na całym świecie. profesjonalistów na całym świecie.

Automatyzacja procesów biznesowych z Camunda: bezawaryjna implementacja schematów BPM

W dzisiejszym cyfrowym świecie, utrzymanie konkurencyjności wymaga usprawnionych i efektywnych procesów biznesowych. Automatyzacja wyróżnia się jako kluczowe rozwiązanie w dążeniu do tego celu. Według Statista, rynek zarządzania procesami biznesowymi (BPM) ma osiągnąć wartość 14,4 miliarda dolarów amerykańskich do 2025 roku. Rosnąca popularność i zapotrzebowanie na narzędzia BPM, takie jak Camunda, znana ze swojej elastyczności i skalowalności, świadczy o tym trendzie. W miarę jak firmy szukają niezawodnych narzędzi do optymalizacji swoich działań, Camunda wyłania się na czoło, torując drogę dla innowacyjnych, bezawaryjnych rozwiązań automatyzacyjnych w branży.

Czym jest Camunda?

Mówiąc najprościej, Camunda to platforma open-source do automatyzacji przepływu pracy i decyzji, która łączy użytkowników biznesowych i twórców oprogramowania. Dzięki solidnemu zestawowi narzędzi i funkcji Camunda oferuje sposoby projektowania, wdrażania i optymalizacji przepływów pracy BPMN (Business Process Model and Notation), dzięki czemu operacje biznesowe są płynniejsze i bardziej przejrzyste.

Camunda, Spring Boot i BPMN: zrozumienie pojęć

Trzy kluczowe elementy zrewolucjonizowały zarządzanie procesami biznesowymi: Camunda, Spring Boot i BPMN. Każdy z nich wypracował swoje miejsce, oferując unikalne funkcjonalności, które adresują różne aspekty zarządzania procesami. Jednak w połączeniu stają się one niepowstrzymaną siłą, zdolną do zrewolucjonizowania cyfrowych operacji przedsiębiorstw.

Camunda: To nie jest tylko kolejne narzędzie w ogromnym zestawie narzędzi BPM; to wyróżniający się produkt. Jako solidna platforma open-source, Camunda specjalizuje się w automatyzacji przepływu pracy i decyzji. Jej główny cel? Płynne połączenie świata strategów biznesowych i twórców oprogramowania. W ten sposób zapewnia, że konceptualizacja, projektowanie i wdrażanie procesów biznesowych są wydajne, przejrzyste i spójne.

Spring Boot: Spring Boot wykorzystuje mocne strony frameworka Spring i podnosi je na wyższy poziom. Oferując usprawnioną metodę tworzenia samodzielnych aplikacji Java stał się ulubieńcem programistów, którzy chcą zminimalizować kod szablonowy i skupić się bezpośrednio na specyficznych funkcjonalnościach projektu. Jego siła tkwi w elastyczności i podejściu konwencji ponad konfiguracją, które propaguje inteligentne ustawienia domyślne. To podejście pozwala programistom na szybsze budowanie skalowalnych aplikacji, zapewniając terminową dostawę i spójną wydajność.

BPMN: Gdybyśmy mieli spersonifikować BPMN, byłby to elokwentny lingwista świata biznesu. Jako uznany na całym świecie standard, BPMN zapewnia wizualne słownictwo do tworzenia procesów biznesowych, dzięki czemu są one łatwo zrozumiałe dla szerokiego grona interesariuszy. Ten uniwersalny język zapewnia, że techniczne niuanse procesu są możliwe do rozszyfrowania zarówno przez obeznanego z technologią programistę, jak i stratega biznesowego, sprzyjając dialogowi opartemu na współpracy i podejmowaniu bardziej świadomych decyzji.

Synergia możliwości automatyzacji Camunda, łatwości rozwoju Spring Boot i standaryzowanej notacji BPMN oferuje firmom dynamiczne rozwiązanie. Razem te narzędzia gwarantują, że schematy BPM przechodzą z teoretycznych konstrukcji na papierze do rzeczywistych, wykonalnych wdrożeń. Ostateczny cel? Stworzenie procesów biznesowych, które są elastyczne, odporne i idealnie dopasowane do zmieniających się wymagań współczesnych cyfrowych przedsiębiorstw.

Podstawowe komponenty BPMN

Dla tych, którzy nie znają BPMN, zrozumienie jego podstawowych komponentów jest kluczowe. Te elementy stanowią fundament każdego diagramu BPMN.

Wydarzenia

Oznaczają one coś, co dzieje się podczas procesu. Zdarzenia mogą rozpoczynać, przerywać lub kończyć przepływ i często są reprezentowane jako okręgi.

Bramki

Bramki obsługują podejmowanie decyzji w ramach procesu. W oparciu o warunki kontrolują przepływ procesu, zwykle przedstawianego jako diamenty.

Działania

Działania reprezentują wykonywaną pracę. Mogą to być zadania lub podprocesy i są wyświetlane jako zaokrąglone prostokąty.

Łączenie obiektów

Elementy te, w tym przepływy sekwencji, przepływy komunikatów i asocjacje, ilustrują sekwencję procesów i przepływ komunikatów.

Swimlanes

Klasyfikują elementy BPMN według ról (np. menedżer, księgowy) lub systemów (np. system ERP).

Artefakty

Oferują one dodatkowe informacje o procesie. Typowe artefakty obejmują obiekty danych, grupy i adnotacje.

Zalety i wady Camunda

Jak każde rozwiązanie technologiczne, Camunda niesie ze sobą szereg zalet i wyzwań. Oto kompleksowe spojrzenie na jej zalety i wady.

Zalety:

  • Elastyczna i łatwa integracja z aplikacjami Java poprzez Spring Boot.
  • Intuicyjny interfejs modelera dla BPMN 2.0.
  • Zapewnia szczegółową analizę metryk procesów.

Wady:

  • Może mieć bardziej stromą krzywą uczenia się dla użytkowników nietechnicznych.
  • Jest to mocny punkt wyjścia, ale należy pamiętać, że to tylko podstawa - Camunda jest potężnym silnikiem workflow, ale nadal będziesz potrzebować dalszego rozwoju oprogramowania.

Usprawnienie przeciążonych diagramów BPMN

Surowa rzeczywistość

Camunda została zaprojektowana tak, aby programiści i analitycy mówili tym samym językiem, ale często rzeczywistość interweniuje. 

Mikroserwisy zawodzą, użytkownicy wprowadzają nieprawidłowe dane, wszystko może się zdarzyć. W takim przypadku piękny diagram analityczny zaczyna być upiększany różnymi modułami obsługi błędów, rejestratorami i alternatywnymi ścieżkami. Analityk projektuje piękny, zwięzły i zrozumiały schemat. Ma on kilku delegatów i zapewnia logiczne ścieżki dla przepływu procesu w różnych okolicznościach. Tak wygląda tymczasowy schemat, gdy trafia w ręce dewelopera:

Ma to jednak swoje wady. Taki schemat może zawierać krótki opis zadania, taki jak "sprawdź klienta", który implikuje kilka etapów, podejmowanie decyzji w oparciu o każdy wynik i kompilowanie pochodnych decyzji w jeden wynik, ewentualnie z późniejszym przekazaniem tego wyniku do systemów zewnętrznych.

Oczywiste jest, że w tym momencie na schemacie lub w kodzie pojawiają się moduły obsługi błędów, rejestratory i elementy obsługi technicznej. W ten sposób jedno zadanie "analityczne" w implementacji Java staje się obszerne i złożone lub liczba kroków na schemacie wzrasta, a każdemu z nich towarzyszą programy obsługi i alternatywne ścieżki. W rezultacie schemat szybko staje się zagmatwany, trudny do dalszego wsparcia i modyfikacji, a dodanie nowej funkcjonalności może wiązać się z restrukturyzacją ogromnego obszaru zarówno schematu, jak i kodu delegata. Zasadniczo zawiera on ogromną liczbę identycznych elementów.

Oto jak poprzedni schemat może wyglądać w rzeczywistym wdrożeniu: 

Oczywiście schemat został rozszerzony i stał się bardziej kłopotliwy. Są jednak zalety: wszystkie zadania stały się atomowe i pojawiły się gałęzie zachowań w przypadku błędów.

Zrozumienie problemu

Jeśli spróbujemy oddzielić i enkapsulować schemat oraz logikę biznesową kodu Java, możemy zrobić następujące rzeczy:

  • Uniknąć powielania podobnych elementów w schemacie.
  • Użyć uniwersalnej i wielokrotnego użytku implementacji delegatów w kodzie Java.
  • Zoptymalizować i przyspieszyć przepływ procesu.
  • Uprościć obsługę błędów technicznych i ustanowić logikę zachowania procesu, gdy te się pojawiają – prawie bez udziału kodu Java. Znacznie uprości to debugowanie i ręczną analizę nieudanych procesów, które wpadają w incydenty.
  • Drastycznie zmniejszyć liczbę procesów, które "wpadają" w incydenty, gdy pojawiają się wyjątki techniczne.
  • Stworzyć solidną podstawę do dalszego rozwoju.

Aby ułatwić pracę z produktem, lepiej zdekomponować schemat na zadania atomowe, zmniejszyć całkowitą liczbę elementów schematu, zmniejszyć liczbę obsługiwanych usług, zredukować objętość kodu Java w każdym delegacie oraz ponownie wykorzystywać uniwersalnych delegatów, prowadząc natychmiastowy refaktoring w razie potrzeby. Wszystko to automatycznie implikuje pisanie testów jednostkowych dla wszystkich delegatów i głównych ścieżek procesu.

Rozkład i atomizacja

Jeśli przyjrzeć się bliżej aplikacji procesowej i przeanalizować jej węzły, można zauważyć wiele powtarzających się funkcji: zapytania do systemów zewnętrznych, logowanie, obsługa błędów, wysyłanie wywołań zwrotnych itp. Innymi słowy, należy krytycznie ocenić aplikację procesową, zidentyfikować z niej obiekty, które można łatwo enkapsulować... Ale w co? W kod Java? Nie, to byłoby nielogiczne, ponieważ w tym przypadku schemat byłby ściśle powiązany z jego implementacją w Javie. W tej sytuacji warto rozważyć pule procesów.

Pula procesów to schemat oddzielnego procesu, który będzie miał swój własny kontekst. Warto zauważyć, że wygodnie jest wyodrębnić atomowe fragmenty funkcjonalności z głównego procesu do takich pul, a także wszystkie powtarzalne momenty: wysyłanie powiadomień, żądań do systemów zewnętrznych itp.

Może istnieć wiele pul procesów i logiczne byłoby pogrupowanie ich tematycznie. Na przykład zapytania do konkretnego mikroserwisu, alertowanie, wysyłanie różnych powiadomień. Interakcje między takimi pulami można łatwo skonfigurować za pomocą komunikatów Camunda. Za każdym razem, gdy taka pula jest wywoływana w silniku Camunda, przekazywana jest pewna wiadomość zawierająca nagłówek warunkowy i numer procesu nadrzędnego do zwrócenia odpowiedzi, a także zestaw danych niezbędnych do działania tej konkretnej małej puli.

Tutaj widzimy, jak główny proces (na dole) wysyła wiadomość, do której subskrybowany jest starter innej puli. Po wystąpieniu zdarzenia druga pula uruchamia nową instancję procesu, wysyła żądanie i wysyła odpowiedź z powrotem do głównego procesu, po czym pomyślnie kończy działanie. W tym czasie proces główny oczekuje na zdarzenie odpowiedzi z puli zewnętrznej, do której wysłał żądanie. Gdy wiadomość nadejdzie, proces jest kontynuowany. Jeśli nie ma odpowiedzi w określonym przedziale czasu, proces rozumie, że obliczenia zewnętrzne są niedostępne lub nie powiodły się, i kończy działanie.

Co to oferuje:

  • Możliwość ponownego wykorzystania kodu. Jeśli zachodzi potrzeba wywołania tego samego kodu kilka razy w różnych warunkach w całym procesie, można po prostu utworzyć określone komunikaty i wywołać odpowiednie pule procesów atomowych;
  • Hermetyzacja schematu implementacji oprogramowania od jego reprezentacji biznesowej. Nie ma znaczenia, w jaki sposób główny schemat zostanie przeprojektowany, ani jakie ścieżki przyjmie proces. Wszystkie interakcje zostały już przeniesione do oddzielnych mniejszych procesów, co zapewnia pełną elastyczność: wystarczy utworzyć żądanie i czekać na odpowiedź.
  • Liczba i prawdopodobieństwo awarii głównego procesu zostały znacznie zmniejszone. Przed takim podziałem proces znajdował się w niepewności 4 stanów:
  •  Odpowiedź nadeszła.
  •  Odpowiedź nie nadeszła, ponieważ zewnętrzna mikrousługa uległa awarii.
  •  Odpowiedź nie nadeszła, ponieważ główny proces uległ awarii podczas wysyłania żądania.
  •  Odpowiedź nie nadeszła z powodu przekroczenia limitu czasu.

Przy takim podziale proces jest zawsze w ściśle określonym stanie: odpowiedź albo nadeszła, albo proces czekał i zakończył się. Dla biznesu ma znaczenie, jak dokładnie zakończył się proces: czy był to błąd, czy nie. Ale będzie to właściwy wniosek, a nie incydent. Jest to ważne, ponieważ proces, który nie utknął w incydencie, nie "zużywa" zasobów, a błędy można łatwo rejestrować, gromadzić statystyki, konfigurować alerty i analizować.

  • Nie ma już znaczenia, co dzieje się z pomniejszymi procesami. Mogą robić co chcą: zawieszać się, uruchamiać... Ważny jest tylko wynik: odpowiedź z zewnętrznego zasobu. I nawet wtedy nie zawsze, ponieważ główny proces nie powinien gwarantować funkcjonalności systemów zewnętrznych. Na przykład, nie ma sensu, aby proces czekał na odpowiedź z mikrousługi powiadomień, ponieważ może ona w ogóle nie nadejść. 
  • Złożoność głównego procesu jest znacznie zmniejszona. Złożona logika może być dystrybuowana pomiędzy oddzielnymi małymi pulami, które są łatwiejsze do debugowania. Na przykład, weryfikacja klienta może wyglądać mniej więcej tak:

Tutaj widzimy, że w puli zewnętrznej wiele zadań jest wywoływanych jednocześnie. Zagłębmy się bardziej w ten punkt.

Zrównoleglenie obliczeń procesowych

Camunda pozwala na współbieżne wykonywanie gałęzi obliczeń procesowych. W tym celu istnieje specjalna brama o nazwie Parallel Gateway, za pomocą której można podzielić przepływ na równoległe lub połączyć wiele równoległych obliczeń w jeden strumień. Oczywiste jest, że aby przyspieszyć przepływ procesu, korzystne byłoby delegowanie niektórych zadań do równoległych wątków. Jeśli logika jest niezależna, może być wykonywana równolegle, na przykład wysyłając jednoczesne żądania do systemów zewnętrznych i oczekując na odpowiedzi od wszystkich z nich jednocześnie:

Za każdym razem przy takiej bramie pojawią się koszty ogólne związane z tworzeniem nowych wątków do podziału zadań i scalaniem wyników. Można napotkać różne wyjątki blokowania i oczywiście nie zawsze jest konieczne lub uzasadnione, aby zawsze działać w ten sposób, zwłaszcza bez testowania, ale korzyści są oczywiste.

W przypadku wykonywania sekwencyjnego, całkowity czas wykonania jest równy sumie czasów wykonania każdej operacji. Natomiast w przypadku wykonywania równoległego jest on równy czasowi wykonania najdłuższej operacji. Biorąc pod uwagę warunki braku natychmiastowych odpowiedzi ze źródeł zewnętrznych, ponownych prób i awarii, różnica ta jest daleka od nieistotnej. Kolejną niezaprzeczalną zaletą jest forma "darmowych ponowień", tj. podczas gdy wykonywane jest najdłuższe żądanie, inne zadania hipotetycznie mają możliwość kilkukrotnego niepowodzenia i próby ponownego wykonania swoich działań bez wpływu na ogólny czas wykonania zadania.

Wyjątki i próby powtórzenia

Spłukany? To się zdarza. Gotowa wersja Camundy ma możliwość ponowienia nieudanej transakcji. Przez "transakcję" rozumiemy wewnętrzny mechanizm Camundy do wykonywania kodu delegata. Początkiem transakcji może być na przykład znacznik "async before" lub "async after" na zadaniu w modelerze. Gdy silnik napotka ten znacznik, zatwierdza informacje w bazie danych i rozpoczyna nowy wątek asynchroniczny. To ważne. Aby zagłębić się głębiej, przez "transakcję" rozumiemy sekcję wykonania między wywołaniami metody .complete() w TaskService, po której następuje zapisanie informacji w bazie danych. Te transakcje, podobnie jak inne, są atomowe.

Gdy wystąpi wyjątek techniczny, tj. jakikolwiek błąd niebiznesowy, na przykład dzielenie przez zero i zapomnienie o sprawdzeniu wartości null, transakcja wykonuje wycofanie i próbuje rozpocząć od nowa. Domyślnie robi to trzy razy z rzędu bez żadnych przerw. Próba ponowienia rozpoczyna się, gdy pojawi się zwykły wyjątek, który w świecie BPMN nazywany jest wyjątkiem technicznym, a nie BpmnError. Pojawiający się BpmnError zatrzymuje proces bez żadnych prób ponowienia. Wyobraź sobie, jak zwiększa to odporność procesu.

Sensowne jest zmaksymalizowanie tej funkcji. Dlatego w każdym delegacie, który żąda zewnętrznego systemu, ustawiane są te znaczniki, określające liczbę ponownych prób i przerwę między nimi, a w kodzie delegata oddzielona jest logika określająca, kiedy proces powinien zostać zakończony, a kiedy nie. Daje to pełną kontrolę nad mechanizmami obsługi wyjątków i ponawiania prób. W rezultacie proces próbuje kilkakrotnie powtórzyć nieudane zadanie i dopiero po serii niepowodzeń generuje błąd.

Być może największym wyzwaniem jest obsługa wyjątków technicznych i błędów związanych z BPMN, a także zaprojektowanie logiki ich obsługi dla ciągłego przepływu procesu. O błędach związanych z obsługą odpowiedzi z zewnętrznych źródeł mówiliśmy już przy okazji podziału na pule procesów. Przypominamy, że samo wywołanie było hermetyzowane w osobnym mini-procesie, a główny albo otrzymywał odpowiedź i kontynuował, albo, z powodu przekroczenia limitu czasu, podążał ścieżką "nie otrzymałem odpowiedzi".

Przyjrzyjmy się teraz temu bardzo małemu procesowi:

Czy widzisz ramkę? To podproces. Zawiera określone zadania i przechwytuje błędy wyrzucane przez zadania wewnętrzne. Co więcej, na takich ramkach executor zadań jest w stanie utworzyć zadanie dla timera, który ustawia czas wykonania dla wszystkiego wewnątrz podprocesu.

Jak to działa? Przepływ wykonania dociera do podprocesu, tworzy równoległe przetwarzanie timera i czeka albo na zakończenie tego, co jest w środku, albo, jeśli timer skończy się pierwszy, będzie podążał ścieżką timera. Jeśli podczas procesu zostanie rzucony wyjątek, który przechwyci ramka podprocesu, proces zatrzyma swoje wykonanie na bieżącej gałęzi i podąży za gałęzią błędu.

Oczywiste jest również, że istnieje opcja tworzenia wysyłek odpowiedzi dla żądań krytycznych. Należy pamiętać, że przechwytywanie błędów działa tylko dla BpmnError z określonym kodem. Dlatego z technicznego punktu widzenia ważne jest, aby wychwycić każdy wyjątek i rzucić BpmnError z wymaganym kodem, który działa dla ErrorBoundaryEvent.

Obsługa błędów w głównym procesie działa podobnie. Z kilku zadań wyodrębniane są jednostki logiczne, które można umieścić w ramce podprocesu, z listenerem skonfigurowanym dla określonego kodu błędu. Są tu jednak dwa niuanse. Pierwszym jest to, że tworzenie wielu identycznych gałęzi z obsługą błędów, różniących się jedynie kodem, jest niewygodne. Jeśli zmieni się strategia obsługi błędów lub, na przykład, logowanie, wówczas wiele delegatów w schemacie musiałoby zostać przeprojektowanych, co nie jest pożądane. Dlatego też można rozważyć rozważenie podprocesów opartych na zdarzeniach.

Zasadniczo jest to oddzielny podproces puli procesów, który uruchamia się tylko wtedy, gdy wystąpi określone zdarzenie, do którego został zasubskrybowany. Na przykład, jeśli zasubskrybujesz taki podproces do zdarzenia BpmnError z kodem, powiedzmy, MyCustomBusinessError, to gdy to zdarzenie wystąpi, procedura obsługi zostanie uruchomiona, a po jej zakończeniu proces zakończy się poprawnie. Tak, nie zakończył się sukcesem, ale zakończył się poprawnie. W tych podprocesach można również zaimplementować różną logikę obsługi dla tego samego zdarzenia w zależności od warunków zewnętrznych, na przykład opcjonalnie powiadamiając o błędzie aplikacji, gdy proces przekroczy punkt warunkowy.

Drugi niuans jest znacznie bardziej skomplikowany. W prawdziwym życiu cykl życia każdego procesu jest prawdopodobnie podzielony na dwa etapy biznesowe: przed generowaniem leadów i po nim. Jeśli błąd wystąpił przed sformatowaniem danych w leada, proces można było prawdopodobnie po prostu zakończyć, powiadamiając o napotkanych trudnościach. Po wygenerowaniu leada nie jest to już możliwe.

Nie zalecamy również kończenia procesów, jeśli w ich trakcie powstają zobowiązania prawne, na przykład w przypadku podpisania umowy. Jak radzimy sobie z takimi błędami? Niektóre błędy techniczne, takie jak te związane z niedostępnością usług zewnętrznych, są obsługiwane przez automatyczne ponawianie prób w ramach wcześniej uzgodnionego limitu czasu. Ale co, jeśli proces się zawiesił, minęły próby, ale hipotetyczna zewnętrzna mikrousługa nadal nie działa? 

Optymalizacja ręczna

Dochodzimy do koncepcji ręcznego rozwiązywania lub, znanej również jako, kompensacji.

Jak to działa? Wszelkie błędy są wychwytywane, delegaci mają możliwość ponowienia próby, jeśli to konieczne, a jeśli szczęście nadal im nie sprzyja, proces przechodzi w stan błędu, ale z odpowiednim kodem, na przykład COMPENSATION_ERROR. Kod ten jest przechwytywany przez inny podproces oparty na zdarzeniach, który przetwarza, rejestruje, powiadamia i co ważne, nie może nieoczekiwanie zawieść. Tylko tam, gdzie został zaprojektowany, rzuca niemożliwy do przechwycenia wyjątek techniczny i ulega awarii.

Dlaczego warto to zrobić w ten sposób? Do monitorowania można użyć EXCAMAD - zewnętrznego panelu administracyjnego dla Camunda, analogicznego do Cockpit, z zaawansowanymi funkcjami. Podświetla on procesy w incydentach na czerwono. Procesy te można modyfikować lub uruchamiać ponownie z wybranego punktu. Na przykład, można umieścić niezbędną wartość zmiennej w kontekście i ponownie uruchomić proces od punktu znajdującego się zaraz po problematycznym. Jest to wygodne, proste i pozwala na ręczne rozwiązywanie problemów przy minimalnym wysiłku.

Automatyzacja procesów biznesowych z Camunda: rzeczywiste przykłady

Camunda, znana ze swojej platformy open-source i przyjaznego interfejsu, umożliwiła wielu przedsiębiorstwom optymalizację ich przepływów pracy. Przejdźmy do kilku przykładów z życia.

Bankowość i finanse

Münchener Hypothekenbank eG, niezależny bank hipoteczny, przeszedł na korzystanie z silnika przepływów pracy Camunda, aby poprawić i zautomatyzować wewnętrzne procesy, w szczególności obsługę korespondencji i koordynację wniosków o kredyty między działami. Wcześniej ich system był sztywny, brakowało mu elastyczności, co prowadziło do złożoności, które zwiększały wskaźniki błędów.

Przechodząc na architekturę mikrousług opartą na Javie, firma wybrała Camundę na podstawie wewnętrznych rekomendacji i ściśle współpracowała z WDW Consulting Group. Niektóre korzyści uzyskane natychmiast dzięki Camunda były gotowymi funkcjami, podczas gdy inne wymagały dalszego rozwoju. To przejście zaowocowało scentralizowaną listą zadań używaną przez wszystkich pracowników i zapewniło elastyczność w utrzymywaniu poszczególnych procesów bez wpływu na inne.

Najbardziej zauważalnym rezultatem była znaczna poprawa szybkości przetwarzania wniosków kredytowych. Jest to korzystne zarówno dla pracowników, jak i klientów końcowych. Jako świadectwo sukcesu, inne działy chcą teraz przyjąć Camundę, a bank zatrudnił nawet więcej programistów, aby dalej wspierać jej wdrożenie.

Ubezpieczenie

SV Informatik, spółka zależna SV SparkassenVersicherung, specjalizuje się w dostosowanych rozwiązaniach IT dla firm ubezpieczeniowych. Wdrożyli Camundę, aby zautomatyzować różne procesy w działach, co doprowadziło do znacznych oszczędności czasowych i poprawy czasów reakcji na potrzeby klientów. Firma przyjęła Camundę w 2018 roku jako rozwiązanie w poszukiwaniu skutecznego narzędzia do modelowania procesów biznesowych, koncentrując się na poprawie procesów i zwiększeniu współpracy między IT a innymi działami.

Od momentu wdrożenia, Camunda zautomatyzowała takie zadania jak anulowanie polisy ubezpieczenia komunikacyjnego i wnioski o wydanie dokumentów polisy. Godnym uwagi osiągnięciem było zautomatyzowane przetwarzanie zgłoszeń szkód burzowych online przez 80%. Okazało się to szczególnie cenne podczas powodzi i burz w Niemczech w 2021 roku. Narzędzia takie jak Camunda Optimize i Camunda Cockpit ułatwiają monitorowanie i optymalizację procesów.

Gościnność

W 2020 roku grupa SV, działająca w Niemczech, Szwajcarii i Austrii, uruchomiła rewolucyjną platformę cyfrową o nazwie „likeMagic” przy wsparciu Camundy. Platforma ta zapewniała płynne doświadczenie gościa, od rezerwacji po wymeldowanie, z wynikami obejmującymi 95% wskaźnik samodzielnego meldowania się/wymeldowania oraz ocenę szczęścia gości na poziomie 9 na 10. Innowacja ta zmniejszyła potrzeby kadrowe i bezproblemowo zintegrowała takie platformy jak Airbnb. Doceniając jej potencjał, grupa SV zaoferowała „likeMagic” innym dostawcom usług hotelarskich. Do 2023 roku rozszerzyli swoją działalność z 2 do ponad 30 klientów w regionie DACH, planując szerszy zasięg europejski i celując w 15 000 pokoi do końca roku.

Podsumowanie

Potencjał transformacyjny Camundy leży nie tylko w jej podstawowych funkcjach, ale także w jej zdolności do redefiniowania operacji biznesowych na fundamentalnym poziomie. W połączeniu z Spring Boot otwiera drzwi do płynnej integracji i zwiększonej skalowalności. Zrozumienie zasad BPMN ma kluczowe znaczenie dla wykorzystania pełnego potencjału Camundy. Ponieważ firmy ewoluują w erze cyfrowej, narzędzia takie jak Camunda wyróżniają się, oferując dynamiczne rozwiązania, które mogą się obracać i dostosowywać do stale zmieniających się potrzeb. Nie chodzi tylko o automatyzację procesów, ale o innowacyjne przepływy pracy, zwiększanie wydajności i osiąganie wymiernych rezultatów, które robią różnicę. Wykorzystaj moc Camunda i pozwól swojej firmie wznieść się na nowe horyzonty.

Spis treści

Oceń ten artykuł:

4/5

4.8/5 (45 opinii)

Powiązane treści

Blog
Looker vs Power BI - Rewolucja w branży małych osłon
Blog
Dlaczego projekt może zakończyć się niepowodzeniem bez BA
Blog
Dlaczego projekty IT kończą się niepowodzeniem

Skontaktuj się z nami

    Prosimy o podanie szczegółów projektu, czasu trwania, stosu technologicznego, potrzebnych specjalistów IT i innych istotnych informacji.
    Nagraj wiadomość głosową na temat
    projekt, który pomoże nam lepiej go zrozumieć
    W razie potrzeby dołącz dodatkowe dokumenty
    Prześlij plik

    Można załączyć maksymalnie 1 plik o łącznej wielkości 2 MB. Ważne pliki: pdf, jpg, jpeg, png

    Informujemy, że po kliknięciu przycisku Wyślij Innowise będzie przetwarzać Twoje dane osobowe zgodnie z naszą Polityką prywatności w celu dostarczenia Ci odpowiednich informacji.

    Co będzie dalej?

    1

    Po otrzymaniu i przetworzeniu Twojego zgłoszenia skontaktujemy się z Tobą wkrótce, aby wyszczególnić potrzeby projektu i podpisać umowę o zachowaniu poufności, aby zapewnić poufność informacji.

    2

    Po przeanalizowaniu wymagań, nasi analitycy i programiści opracowują projekt z zakresem prac, wielkością zespołu, czasem i kosztami szacunki.

    3

    Umówimy się z Tobą na spotkanie, aby omówić ofertę i dojść do porozumienia porozumienia.

    4

    Podpisujemy umowę i rozpoczynamy pracę nad projektem tak szybko, jak to możliwe.

    Dziękuję!

    Wiadomość została wysłana.
    Przetworzymy Twoją prośbę i skontaktujemy się z Tobą tak szybko, jak to możliwe.

    Dziękuję!

    Wiadomość została wysłana.
    Przetworzymy Twoją prośbę i skontaktujemy się z Tobą tak szybko, jak to możliwe.

    strzałka