5 min read

Automatyzacja procesów biznesowych z Camunda: odporna na błędy implementacja schematów BPM

BPMN

Biznes

Comunda

Spring Boot

W dzisiejszym cyfrowym świecie utrzymanie przewagi konkurencyjnej wymaga usprawnionych i wydajnych procesów biznesowych. Automatyzacja wyróżnia się jako kluczowe rozwiązanie pozwalające to osiągnąć. Według Statista, rynek zarządzania procesami biznesowymi (BPM) jest oczekiwany do 2025 roku osiągnie wartość 14,4 miliarda dolarów. Rosnąca popularność i popyt na narzędzia BPM, takie jak Camunda, znane ze swojej elastyczności i skalowalności, świadczą o tym trendzie. Ponieważ firmy poszukują niezawodnych narzędzi do optymalizacji swoich operacji, Camunda wyłania się jako prekursor, torując drogę dla innowacyjnych, odpornych na awarie rozwiązań automatyzacji 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ęć

Trzech kluczowych graczy zmieniło krajobraz zarządzania procesami biznesowymi: Camunda, Spring Boot i BPMN. Każdy z nich wyrzeźbił swoją niszę, oferując unikalne funkcje, które dotyczą różnych aspektów zarządzania procesami. Jednak w połączeniu, przekształcają się w niezrównaną potęgę, zdolną do zrewolucjonizowania cyfrowych operacji przedsiębiorstwa.

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 Java Aplikacja ta stała się popularna wśród deweloperów chcących zminimalizować ilość standardowego kodu i zanurzyć się w samym sercu funkcjonalności specyficznych dla projektu. Jego siła tkwi w elastyczności i podejściu opartym na konwencjach, które promuje ideę inteligentnych ustawień domyślnych. Takie podejście pozwala programistom szybciej tworzyć skalowalne aplikacje, zapewniając terminowe dostarczanie 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 programowania Spring Boot i znormalizowanej notacji BPMN zapewnia firmom dynamiczną trifectę. Razem zapewniają, że schematy BPM przechodzą od zwykłych teoretycznych konstrukcji na papierze do praktycznych, rzeczywistych wdrożeń. Cel końcowy? Kultywowanie procesów biznesowych, które są zwinne, odporne i doskonale dostosowane do zmieniających się wymagań współczesnego cyfrowego krajobrazu przedsiębiorstwa.

Podstawowe komponenty BPMN

Dla osób niezaznajomionych z BPMN zrozumienie jego podstawowych komponentów ma kluczowe znaczenie. Komponenty te stanowią podstawę 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.

Bramy

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

Kategoryzują one elementy BPMN według roli (np. kierownik, księgowy) lub systemu (np. system ERP).

Artefakty

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

Plusy i minusy Camunda

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

Plusy:

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.

Uświadomienie sobie problemu

Jeśli spróbujemy oddzielić i hermetyzować schemat i logikę biznesową kodu Java, możemy wykonać następujące czynności:

Unikaj powielania podobnych elementów na schemacie.
Użyj uniwersalnej i wielokrotnego użytku implementacji delegatów w kodzie Java.
Optymalizacja i przyspieszenie przepływu procesu.
Uproszczenie obsługi błędów technicznych i ustalenie logiki zachowania procesu w przypadku ich wystąpienia - niemal bez angażowania kodu Java. Znacznie uprości to debugowanie i ręczną analizę nieudanych procesów, które znajdują się w incydencie.
Drastyczne zmniejszenie liczby procesów, które "wpadają" w incydenty, gdy pojawiają się wyjątki techniczne.
Stworzenie solidnych podstaw do dalszego rozwoju.

Aby ułatwić pracę z produktem, lepiej jest rozłożyć schemat na zadania atomowe, zmniejszyć całkowitą objętość elementów schematu, zmniejszyć liczbę programów obsługi usług, zmniejszyć objętość kodu Java każdego delegata i ponownie wykorzystać uniwersalne delegaty, przeprowadzając natychmiastową refaktoryzację 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: przykłady z życia wzięte

Znana ze swojej platformy open-source i przyjaznego dla użytkownika interfejsu, Camunda umożliwiła wielu przedsiębiorstwom optymalizację przepływu pracy. Przyjrzyjmy się kilku przykładom z życia wziętym.

Bankowość i finanse

Münchener Hypothekenbank eGNiezależny bank nieruchomości przeszedł na korzystanie z silnika przepływu pracy Camunda, aby usprawnić i zautomatyzować procesy wewnętrzne, w szczególności obsługę poczty i koordynację wniosków kredytowych między działami. Wcześniej ich system był sztywny, brakowało mu elastyczności i prowadził do złożoności, która zwiększała 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 InformatikSV SparkassenVersicherung, spółka zależna SV SparkassenVersicherung, specjalizuje się w niestandardowych rozwiązaniach IT dla firm ubezpieczeniowych. Firma wdrożyła Camundę w celu automatyzacji różnych procesów w różnych działach, co doprowadziło do znacznych oszczędności czasu i skrócenia czasu reakcji klientów. Firma wdrożyła Camundę w 2018 roku jako rozwiązanie w poszukiwaniu skutecznego narzędzia do modelowania procesów biznesowych, z naciskiem na usprawnienie procesów i poprawę współpracy między działem 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 r. SV Groupdziałająca w Niemczech, Szwajcarii i Austrii, uruchomiła z pomocą Camundy przełomową platformę cyfrową o nazwie "likeMagic". Platforma ta zapewniła płynną obsługę gości, od rezerwacji do wymeldowania, z wynikami obejmującymi wskaźnik samodzielnego zameldowania / wymeldowania 95% i 9 na 10 punktów zadowolenia gości. Innowacja zmniejszyła zapotrzebowanie na personel i płynnie zintegrowała platformy takie jak Airbnb. Dostrzegając jej potencjał, SV Group zaoferowała "likeMagic" innym dostawcom usług hotelarskich. Do 2023 r. liczba klientów wzrosła z 2 do ponad 30 w regionie DACH, z planami szerszego zasięgu w Europie i docelowo 15 000 pokoi do końca roku.

Zakończenie

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.

Dmitry Nazarevich CTO

Data: 17 stycznia 2024 r.

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

Porównanie Looker vs Power BI: odsłona narzędzia BI

Blog

Dlaczego warto zatrudniać młodszych programistów do swoich projektów?

Blog

Wybór odpowiedniego partnera do nearshoringu IT: wskazówki dla konsultantów IT w Europie

Blog

Dlaczego projekt może zakończyć się niepowodzeniem bez BA

Dlaczego projekt bez specjalisty BA może się nie powieść?

Blog

Dlaczego projekty IT kończą się niepowodzeniem

Formularz kontaktowy

Nazwa

Firma

E-mail

Telefon

Wiadomość 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?

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.

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

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

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

Automatyzacja procesów biznesowych z Camunda: odporna na błędy implementacja schematów BPM

Czym jest Camunda?

Camunda, Spring Boot i BPMN: zrozumienie pojęć