5 min lezen

Automatisering van bedrijfsprocessen met Camunda: fouttolerante implementatie van BPM-schema's

BPMN

Bedrijf

Comunda

Spring Boot

In de digitale wereld van vandaag vereisen gestroomlijnde en efficiënte bedrijfsprocessen een concurrentievoordeel. Automatisering is een belangrijke oplossing om dit te bereiken. Volgens Statista is de markt voor business process management (BPM) wordt verwacht om tegen 2025 een omvang van 14,4 miljard dollar te bereiken. De stijgende populariteit van en vraag naar BPM tools zoals Camunda, bekend om zijn flexibiliteit en schaalbaarheid, getuigen van deze trend. Omdat bedrijven op zoek zijn naar betrouwbare tools om hun activiteiten te optimaliseren, komt Camunda naar voren als een voorloper die de weg vrijmaakt voor innovatieve, fouttolerante automatiseringsoplossingen in de industrie.

Wat is Camunda?

Eenvoudig gezegd is Camunda een open-source platform voor workflow- en beslissingsautomatisering dat zakelijke gebruikers en softwareontwikkelaars samenbrengt. Met zijn robuuste set tools en functies biedt Camunda manieren om BPMN (Business Process Model and Notation) workflows te ontwerpen, implementeren en optimaliseren, waardoor bedrijfsactiviteiten soepeler en transparanter worden.

Camunda, Spring Boot & BPMN: de concepten begrijpen

Drie belangrijke spelers hebben het landschap van business process management opnieuw vormgegeven: Camunda, Spring Boot en BPMN. Elk van hen heeft zijn eigen niche gecreëerd en biedt unieke functionaliteiten voor verschillende facetten van procesmanagement. Wanneer ze echter worden gecombineerd, vormen ze een ongeëvenaarde krachtpatser die in staat is een revolutie teweeg te brengen in de bedrijfsvoering van digitale ondernemingen.

Camunda: Dit is niet zomaar een tool in de uitgebreide BPM-toolbox; het is een uitblinker. Camunda is een robuust open-source platform dat gespecialiseerd is in workflow- en beslissingsautomatisering. De primaire doelstelling? De werelden van bedrijfsstrategen en softwareontwikkelaars naadloos met elkaar laten versmelten. Hierdoor zorgt het ervoor dat de conceptualisatie, het ontwerp en de implementatie van bedrijfsprocessen efficiënt, transparant en samenhangend zijn.

Spring Boot: Spring Boot neemt de kracht van het Veerframework en verheft ze. Door het aanbieden van een gestroomlijnde methode om standalone Java te bouwen, is het de go-to geworden voor ontwikkelaars die standaardcode willen minimaliseren en rechtstreeks in het hart van projectspecifieke functionaliteiten willen duiken. Zijn kracht ligt in zijn flexibiliteit en zijn convention-over-configuration benadering, die het idee van slimme standaardwaarden verdedigt. Deze aanpak stelt ontwikkelaars in staat om sneller schaalbare applicaties te bouwen, waardoor tijdige levering en consistente prestaties worden gewaarborgd.

BPMN: Als we BPMN zouden moeten personifiëren, zou het de welsprekende taalkundige van de bedrijfswereld zijn. Als wereldwijd erkende standaard biedt BPMN een visuele woordenschat voor het opstellen van bedrijfsprocessen, waardoor ze gemakkelijk te begrijpen zijn voor een breed scala aan belanghebbenden. Deze universele taal zorgt ervoor dat de technische nuances van een proces kunnen worden ontcijferd door zowel de technisch onderlegde programmeur als de bedrijfsstrateeg.

De synergie van Camunda's automatiseringsmogelijkheden, Spring Boot's ontwikkelgemak en BPMN's gestandaardiseerde notatie biedt bedrijven een dynamische drie-eenheid. Samen zorgen ze ervoor dat BPM-schema's veranderen van louter theoretische constructies op papier in bruikbare implementaties in de praktijk. Het einddoel? Bedrijfsprocessen cultiveren die wendbaar en veerkrachtig zijn en perfect afgestemd zijn op de evoluerende eisen van het hedendaagse digitale ondernemingslandschap.

BPMN-basiscomponenten

Voor degenen die niet bekend zijn met BPMN is het cruciaal om de essentiële componenten te begrijpen. Deze componenten vormen de basis van elk BPMN-diagram.

Evenementen

Deze geven aan dat er iets gebeurt tijdens een proces. Gebeurtenissen kunnen een stroom starten, onderbreken of beëindigen en worden vaak weergegeven als cirkels.

Poorten

Gateways zorgen voor de besluitvorming binnen het proces. Op basis van de voorwaarden sturen ze de stroom van het proces, meestal afgebeeld als diamanten.

Activiteiten

Activiteiten vertegenwoordigen werk dat wordt gedaan. Ze kunnen taken of subprocessen zijn en worden weergegeven als afgeronde rechthoeken.

Objecten verbinden

Deze elementen, waaronder sequentiestromen, berichtenstromen en associaties, illustreren de volgorde van processen en de berichtenstroom.

Zwembanen

Deze categoriseren BPMN-elementen op rol (bijv. manager, accountant) of systeem (bijv. een ERP-systeem).

Artefacten

Deze bieden aanvullende informatie over het proces. Veel voorkomende artefacten zijn dataobjecten, groepen en annotaties.

Voor- en nadelen van Camunda

Zoals elke technologische oplossing brengt Camunda een mix van voordelen en uitdagingen met zich mee. Hier volgt een uitgebreide blik op de voor- en nadelen.

Voordelen:

Flexibele en eenvoudige integratie met Java-toepassingen via Spring Boot.
Een intuïtieve modelleerinterface voor BPMN 2.0.
Biedt gedetailleerde analyses van procesmetriek.

Minpunten:

Kan een steilere leercurve hebben voor niet-technische gebruikers.
Het is een sterk uitgangspunt, maar zie het als slechts de basis - hoewel Camunda een krachtige workflow-engine is, zult u nog steeds verdere softwareontwikkeling nodig hebben.

Stroomlijnen van overbelaste BPMN-diagrammen

Harde realiteit

Camunda is ontworpen om ontwikkelaars en analisten dezelfde taal te laten spreken, maar vaak komt de realiteit tussenbeide.

Microservices falen, gebruikers voeren verkeerde gegevens in, er kan van alles gebeuren. In dit geval wordt het mooie analytische schema verfraaid met verschillende foutafhandelaars, loggers en alternatieve paden. De analist ontwerpt een mooi, beknopt en begrijpelijk schema. Het heeft een paar afgevaardigden en biedt logische paden voor de processtroom onder verschillende omstandigheden. Zo ziet een voorlopig schema eruit wanneer het in handen komt van een ontwikkelaar:

Er zijn echter nadelen. Zo'n schema kan een korte taakbeschrijving bevatten, zoals "controleer de klant", wat verschillende stappen impliceert, besluitvorming gebaseerd op elk resultaat, en het samenvoegen van de afgeleide beslissingen in een enkel resultaat, mogelijk met de daaropvolgende overdracht van dit resultaat naar externe systemen.

Het is duidelijk dat op dit punt foutverwerkers, loggers en technische service-elementen op het schema of in de code verschijnen. Op deze manier wordt één "analytische" taak in de Java-implementatie omvangrijk en complex, of neemt het aantal stappen in het schema toe, elk vergezeld van handlers en alternatieve paden. Het resultaat is dat het schema snel ingewikkeld wordt, moeilijk te ondersteunen en aan te passen is, en het toevoegen van nieuwe functionaliteit kan betekenen dat een groot deel van zowel het schema als de gedelegeerde code geherstructureerd moet worden. In essentie bevat het een enorm aantal identieke elementen.

Hier zie je hoe het vorige schema eruit zou kunnen zien in een echte implementatie:

Het schema is duidelijk uitgebreid en omslachtiger geworden. Maar er zijn voordelen: alle taken zijn atomair geworden en er zijn takken van gedrag ontstaan in het geval van fouten.

Het probleem realiseren

Als we proberen het schema en de bedrijfslogica van de Java-code te scheiden en in te kapselen, kunnen we het volgende doen:

Vermijd het dupliceren van soortgelijke elementen op het schema.
Gebruik een universele en herbruikbare implementatie van delegates in de Java-code.
Optimaliseer en versnel de processtroom.
Vereenvoudig de afhandeling van technische fouten en stel een logica voor procesgedrag vast wanneer ze zich voordoen - bijna zonder tussenkomst van Java-code. Dit zal het debuggen en de handmatige analyse van mislukte processen in een incident aanzienlijk vereenvoudigen.
Het aantal processen dat in incidenten "valt" wanneer zich technische uitzonderingen voordoen, drastisch verminderen.
Leg een stevige basis voor verdere ontwikkeling.

Om het gemakkelijker te maken om met het product te werken, is het beter om het schema in atomaire taken te ontleden, het totale volume van schema-elementen te verminderen, het aantal service-handlers te verminderen, het volume van de Java-code van elke delegate te verminderen en universele delegates te hergebruiken, door indien nodig onmiddellijk refactoring uit te voeren. Dit alles impliceert automatisch het schrijven van unit tests voor alle delegates en de hoofdpaden van het proces.

Ontleding en verstuiving

Als je goed naar de procesapplicatie kijkt en de knooppunten analyseert, zie je veel repetitieve functies: query's naar externe systemen, logging, foutafhandeling, callbacks versturen, enz. Met andere woorden, je moet de procesapplicatie kritisch beoordelen en objecten ervan identificeren die gemakkelijk kunnen worden ingekapseld... Maar waarin? In Java-code? Nee, dat zou onlogisch zijn, want in dit geval zou het schema nauw verbonden zijn met zijn Java implementatie. In deze situatie is het zinvol om procespools te overwegen.

Een procespool is een schema van een apart proces dat zijn eigen context heeft. Het is opmerkelijk dat het handig is om atomaire stukjes functionaliteit van het hoofdproces in zulke pools te stoppen, evenals alle herhalende momenten: het versturen van meldingen, verzoeken naar externe systemen, enz.

Er kunnen veel procespools zijn en het zou logisch zijn om ze thematisch te groeperen. Bijvoorbeeld query's naar een bepaalde microservice, alarmering, het versturen van verschillende notificaties. Interactie tussen zulke pools kan eenvoudig worden opgezet met Camunda messaging. Elke keer dat zo'n pool wordt aangeroepen in de Camunda engine, wordt een bepaald bericht doorgegeven met een conditionele header en het bovenliggende procesnummer voor het retourneren van een antwoord, evenals een set noodzakelijke gegevens voor de werking van deze specifieke kleine pool.

Hier zien we hoe het hoofdproces (onderaan) een bericht stuurt waarop de starter van een andere pool is geabonneerd. Wanneer de gebeurtenis plaatsvindt, start de tweede pool een nieuwe instantie van het proces, doet een verzoek en stuurt een antwoord terug naar het hoofdproces, waarna het succesvol afrondt. Gedurende deze tijd wacht het hoofdproces op het antwoord van de externe pool waarnaar het een verzoek stuurde. Als het bericht arriveert, gaat het proces verder. Als er geen antwoord komt binnen het gespecificeerde tijdsinterval, begrijpt het proces dat de externe berekening niet beschikbaar is of is mislukt en wordt het proces beëindigd.

Wat dit biedt:

Mogelijkheid tot hergebruik van code. Als je dezelfde code meerdere keren moet aanroepen onder verschillende omstandigheden tijdens het proces, kun je gewoon specifieke berichten aanmaken en de bijbehorende atomaire procespools aanroepen;
Inkapseling van het software-implementatieschema van de bedrijfsrepresentatie. Het maakt niet uit hoe het hoofdschema zal worden herontworpen, of welke paden het proces zal nemen. Alle interacties zijn al verplaatst naar aparte kleine processen, wat volledige flexibiliteit geeft: gewoon een verzoek formuleren en wachten op een antwoord.
Het aantal en de waarschijnlijkheid van het vastlopen van het hoofdproces zijn aanzienlijk verminderd. Vóór een dergelijke splitsing bevond het proces zich in een onzekerheid van 4 toestanden:
Het antwoord is aangekomen.
Het antwoord kwam niet omdat de externe microservice crashte.
Het antwoord kwam niet omdat het hoofdproces crashte tijdens het verzenden van het verzoek.
Het antwoord kwam niet omdat een time-out was overschreden.

Met deze verdeling is het proces altijd in een strikt enkele toestand: het antwoord kwam, of het proces wachtte en eindigde. Voor bedrijven maakt het uit hoe het proces precies eindigde: of het een fout was of niet. Maar dit zal een juiste conclusie zijn, geen incident. Dit is belangrijk omdat een proces dat niet vastzit in een incident geen middelen "verbruikt" en fouten gemakkelijk kunnen worden gelogd, statistieken verzameld, waarschuwingen ingesteld en geanalyseerd.

Het maakt niet meer uit wat er gebeurt met de kleine processen. Ze kunnen doen wat ze willen: crashen, uitvoeren... Alleen het resultaat is belangrijk: de reactie van de externe bron. En zelfs dan, niet altijd, omdat het hoofdproces de functionaliteit van externe systemen niet zou moeten garanderen. Het kan bijvoorbeeld zinloos zijn om als proces te wachten op een antwoord van de notificatie microservice, omdat er misschien helemaal geen antwoord komt.
De complexiteit van het hoofdproces wordt sterk verminderd. Complexe logica kan verdeeld worden over aparte kleine pools, die gemakkelijker te debuggen zijn. De clientverificatie zou er bijvoorbeeld zo uit kunnen zien:

Hier kunnen we zien dat in de externe pool meerdere taken tegelijkertijd worden aangeroepen. Laten we dieper op dit punt ingaan.

Parallellisatie van procesberekeningen

Camunda maakt het mogelijk om takken van procesberekeningen gelijktijdig uit te voeren. Voor dit doel is er een speciale gateway genaamd de Parallel Gateway, waarmee de stroom kan worden opgedeeld in parallellen of om meerdere parallelle berekeningen samen te voegen in één stroom. Het is duidelijk dat om de stroom van een proces te versnellen, het voordelig zou zijn om bepaalde taken te delegeren aan parallelle threads. Als de logica onafhankelijk is, kan deze parallel worden uitgevoerd, bijvoorbeeld door gelijktijdig verzoeken te doen aan externe systemen en te wachten op antwoorden van allemaal tegelijk:

Elke keer bij zo'n gateway zijn er overheadkosten verbonden aan het aanmaken van nieuwe threads voor het verdelen van taken en het samenvoegen van de resultaten. Men kan verschillende vergrendelingsuitzonderingen tegenkomen, en natuurlijk is het niet altijd nodig of gerechtvaardigd om altijd op deze manier te handelen, vooral zonder te testen, maar de voordelen zijn duidelijk.

Bij sequentiële uitvoering is de totale uitvoeringstijd gelijk aan de som van de uitvoeringstijden van elke bewerking. Bij parallelle uitvoering daarentegen is dit gelijk aan de uitvoeringstijd van de langste bewerking. Gezien de omstandigheden van niet-onmiddellijke reacties van externe bronnen, pogingen en mislukkingen, is dit verschil verre van onbeduidend. Een ander onbetwistbaar voordeel is de vorm van "vrije pogingen", d.w.z. terwijl het langste verzoek wordt uitgevoerd, hebben de andere taken hypothetisch gezien de mogelijkheid om meerdere keren te falen en te proberen hun acties opnieuw uit te voeren zonder de totale taakuitvoeringstijd te beïnvloeden.

Uitzonderingen en herhalingspogingen

Failliet? Het gebeurt. De out-of-the-box versie van Camunda heeft de mogelijkheid om een mislukte transactie opnieuw te proberen. Met "transactie" bedoelen we Camunda's interne mechanisme voor het uitvoeren van gedelegeerde code. Het begin van een transactie kan bijvoorbeeld de "async before" of "async after" marker zijn op een taak in de modeler. Wanneer de engine deze markering tegenkomt, wordt de informatie vastgelegd in de database en wordt een nieuwe asynchrone thread gestart. Dit is belangrijk. Om dieper te graven, met "transactie" bedoelen we het uitvoeringsgedeelte tussen de aanroepen van de .complete() methode in TaskService, gevolgd door het vastleggen van informatie in de database. Deze transacties zijn, net als andere, atomair.

Als er een technische uitzondering optreedt, d.w.z. een niet-zakelijke fout, bijvoorbeeld delen door nul en een null-controle vergeten, voert de transactie een rollback uit en probeert opnieuw te beginnen. Standaard doet het dit drie keer achter elkaar zonder pauzes. Een poging tot opnieuw proberen begint als er een reguliere uitzondering optreedt, die in de BPMN-wereld een technische uitzondering wordt genoemd en geen BpmnError. Een optredende BpmnError stopt het proces zonder dat er nieuwe pogingen worden ondernomen. Stel je voor hoe dit de veerkracht van het proces vergroot.

Het is zinvol om deze functie te maximaliseren. Daarom worden op elke delegate die een extern systeem aanvraagt, deze markeringen gezet, die het aantal retries en de pauze daartussen specificeren, en in de code van de delegate wordt logica gescheiden voor wanneer het proces beëindigd moet worden en wanneer niet. Het geeft volledige controle over de exception handling en retry mechanismen. Als gevolg hiervan probeert het proces de mislukte taak meerdere keren opnieuw uit te voeren en pas na een reeks mislukkingen produceert het een fout.

De grootste uitdaging is misschien wel de afhandeling van technische uitzonderingen en BPMN-gerelateerde fouten, evenals het ontwerpen van de logica van hun afhandeling voor een continue stroom van het proces. We hebben al enkele fouten besproken met betrekking tot het afhandelen van reacties van externe bronnen toen we het hadden over het verdelen in procespools. We willen je eraan herinneren dat de eigenlijke aanroep werd ingekapseld in een afzonderlijk miniproces en dat het hoofdproces ofwel een antwoord ontving en verder ging, ofwel, vanwege een time-out, de route "Ik heb geen antwoord ontvangen" volgde.

Laten we nu eens kijken naar dat hele kleine proces:

Zie je het frame? Het is een subproces. Het bevat specifieke taken en vangt fouten op die door interne taken worden gegooid. Bovendien kan de job executor op zulke frames een taak aanmaken voor de timer, die de uitvoeringstijd voor alles binnen het subproces instelt.

Hoe werkt het? De uitvoeringsstroom bereikt het subproces, creëert parallelle timerverwerking en wacht ofwel op de voltooiing van wat erin zit of, als de timer eerst afloopt, volgt het de timerroute. Als er tijdens het proces een uitzondering wordt gegooid, die het subproces frame opvangt, zal het proces zijn uitvoering stoppen op de huidige tak en de fouttak volgen.

Het is ook duidelijk dat er een optie is om antwoorddispatches te maken voor kritieke verzoeken. Merk op dat het vastleggen van fouten alleen werkt voor BpmnError met een specifieke code. Daarom is het technisch gezien essentieel om elke uitzondering op te vangen en een BpmnError te gooien met de vereiste code, die werkt voor het ErrorBoundaryEvent.

Foutafhandeling in het hoofdproces werkt op dezelfde manier. Van verschillende taken worden logische eenheden uitgekozen die in een subprocesframe kunnen worden geplaatst, met een luisteraar ingesteld voor een specifieke foutcode. Maar hier zijn twee nuances. De eerste is dat het maken van meerdere identieke takken met foutafhandeling, die alleen verschillen in code, onhandig is. Als de strategie voor foutafhandeling verandert of bijvoorbeeld logging, dan zouden veel delegates op het schema opnieuw ontworpen moeten worden, wat niet wenselijk is. Daarom zou men kunnen overwegen om te kijken naar event-gebaseerde subprocessen.

In de kern is dit een afzonderlijk subproces van de procespool, dat alleen start wanneer een bepaalde gebeurtenis waarop het geabonneerd is, optreedt. Als je bijvoorbeeld zo'n subproces abonneert op de gebeurtenis BpmnError met een code, bijvoorbeeld MyCustomBusinessError, dan wordt de handler geactiveerd wanneer deze gebeurtenis optreedt en na voltooiing wordt het proces correct beëindigd. Ja, het eindigde niet met succes, maar het eindigde correct. In deze subprocessen kun je ook verschillende afhandelingslogica voor dezelfde gebeurtenis implementeren, afhankelijk van externe voorwaarden, bijvoorbeeld optioneel een melding geven over een applicatiefout wanneer het proces een voorwaardelijk punt passeert.

De tweede nuance is veel ingewikkelder. In het echte leven is de levenscyclus van elk proces waarschijnlijk verdeeld in twee bedrijfsfasen: vóór leadgeneratie en erna. Als er een fout optreedt voordat de gegevens zijn geformatteerd tot een lead, kan het proces waarschijnlijk gewoon worden beëindigd met een melding over de ondervonden moeilijkheden. Zodra de lead is gegenereerd, is dit niet meer mogelijk.

We raden ook niet aan om processen te beëindigen als er tijdens het proces wettelijke verplichtingen ontstaan, bijvoorbeeld als er een contract wordt getekend. Hoe gaan we om met dergelijke fouten? Sommige technische fouten, zoals fouten die te maken hebben met het niet beschikbaar zijn van externe services, worden afgehandeld door automatische pogingen binnen een vooraf afgesproken time-out. Maar wat als het proces crasht, de pogingen voorbij zijn, maar de hypothetische externe microservice nog steeds niet beschikbaar is?

Handmatige optimalisatie

We komen nu bij het concept van handmatige resolutie of, ook bekend als, compensaties.

Hoe werkt het? Eventuele fouten worden opgevangen, delegates krijgen de kans om opnieuw te proberen indien nodig, en als ze nog steeds geen geluk hebben, gaat het proces in een foutstatus, maar met de juiste code, bijvoorbeeld COMPENSATION_ERROR. Deze code wordt opgevangen door een ander event-gebaseerd subproces, dat verwerkt, logt, meldt en, wat belangrijk is, niet onverwacht kan falen. Alleen waar het ontworpen is om dat te doen, gooit het een niet-vangbare technische uitzondering en crasht het in een incident.

Waarom op deze manier? Voor monitoring kun je EXCAMAD gebruiken - een extern beheerpaneel voor Camunda, een analogie van Cockpit, met krachtige functies. Processen bij incidenten worden rood gemarkeerd. Deze processen kunnen vanaf het gewenste punt worden aangepast of opnieuw worden gestart. U kunt bijvoorbeeld de benodigde variabele waarde in de context plaatsen en het proces herstarten vanaf het punt direct na het problematische punt. Dit is handig, eenvoudig en maakt handmatige probleemoplossing met minimale inspanning mogelijk.

Automatisering van bedrijfsprocessen met Camunda: voorbeelden uit de praktijk

Camunda staat bekend om zijn open-source platform en gebruiksvriendelijke interface en heeft talloze bedrijven in staat gesteld hun workflows te optimaliseren. Laten we een paar voorbeelden uit de praktijk bekijken.

Bankieren en financiën

Münchener Hypothekenbank eG, een onafhankelijke vastgoedbank ging over op het gebruik van de Camunda workflow engine om interne processen te verbeteren en te automatiseren, met name postverwerking en coördinatie tussen afdelingen voor het aanvragen van leningen. Voorheen was hun systeem rigide, niet flexibel en leidde het tot complexiteit waardoor het aantal fouten toenam.

In hun overgang naar een op Java gebaseerde microservicearchitectuur kozen ze Camunda op basis van interne aanbevelingen en werkten ze nauw samen met WDW Consulting Group. Sommige voordelen die ze onmiddellijk uit Camunda haalden, waren kant-en-klare functies, terwijl andere meer ontwikkeling vereisten. Deze overgang resulteerde in een gecentraliseerde takenlijst die door alle medewerkers wordt gebruikt en bood flexibiliteit om individuele processen te behouden zonder andere te beïnvloeden.

Het meest opvallende resultaat is een aanzienlijke verbetering in de verwerkingssnelheid van leningaanvragen. Dit komt zowel het personeel als de eindklanten ten goede. Als bewijs van het succes zijn andere afdelingen nu op zoek naar Camunda en de bank heeft zelfs meer ontwikkelaars aangenomen om de implementatie verder te ondersteunen.

Verzekering

SV Informatica, een dochteronderneming van SV SparkassenVersicherung, is gespecialiseerd in op maat gemaakte IT-oplossingen voor verzekeringsmaatschappijen. Ze namen Camunda op om verschillende processen over afdelingen heen te automatiseren, wat leidde tot opmerkelijke tijdbesparingen en verbeterde reactietijden voor klanten. Het bedrijf adopteerde Camunda in 2018 als oplossing voor hun zoektocht naar een effectieve tool voor het modelleren van bedrijfsprocessen, met een focus op het verbeteren van processen en het verbeteren van de samenwerking tussen IT en andere afdelingen.

Sinds de implementatie heeft Camunda taken geautomatiseerd zoals het annuleren van polissen van autoverzekeringen en het aanvragen van polisdocumenten. Een opmerkelijke prestatie was de 80% geautomatiseerde verwerking van online stormschademeldingen. Dit bleek vooral waardevol tijdens de overstromingen en stormen van 2021 in Duitsland. Tools zoals Camunda Optimize en Camunda Cockpit vergemakkelijken het bewaken en optimaliseren van processen.

Gastvrijheid

In 2020 zal de SV Groep, dat actief is in Duitsland, Zwitserland en Oostenrijk, lanceerde een disruptief digitaal platform genaamd 'likeMagic' met hulp van Camunda. Dit platform zorgde voor een naadloze gastervaring, van boeken tot uitchecken, met als resultaat onder andere een 95% self-check-in/out rate en een 9 uit 10 gasttevredenheidsscore. De innovatie verminderde de behoefte aan personeel en integreerde platforms zoals Airbnb naadloos. SV Group zag het potentieel en bood 'likeMagic' aan andere horeca-aanbieders aan. Tegen 2023 zijn ze gegroeid van 2 naar meer dan 30 klanten in de DACH-regio, met plannen voor een breder Europees bereik en met als doel 15.000 kamers tegen het einde van het jaar.

Inpakken

Het transformerende potentieel van Camunda ligt niet alleen in de kernfunctionaliteiten, maar ook in het vermogen om bedrijfsactiviteiten op een fundamenteel niveau te herdefiniëren. In combinatie met Spring Boot opent het de deur naar naadloze integraties en verbeterde schaalbaarheid. Om het volledige potentieel van Camunda te kunnen benutten, is het van het grootste belang om de moeren en bouten van BPMN te begrijpen. Naarmate bedrijven evolueren in dit digitale tijdperk, onderscheiden tools zoals Camunda zich door het aanbieden van dynamische oplossingen die kunnen pivoteren en zich kunnen aanpassen aan steeds veranderende behoeften. Het gaat niet alleen om het automatiseren van processen, maar ook om het innoveren van workflows, het verbeteren van de efficiëntie en het behalen van tastbare resultaten die het verschil maken. Omarm de kracht van Camunda en laat uw bedrijf zweven naar nieuwe horizonten.

Dmitry Nazarevich CTO

Datum: 17 jan 2024

Inhoudsopgave

Beoordeel dit artikel:

★★★★★ 4/5

4.8/5 (45 beoordelingen)

Gerelateerde inhoud

Blog

Looker vs Power BI - Een revolutie in de industrie voor kleine afdekkingen

Looker vs Power BI vergelijken: de BI-tool onthullen

Blog

Waarom junior softwareontwikkelaars inhuren voor uw projecten

Blog

De juiste IT nearshoring partner kiezen: tips voor IT adviseuren in Europa

Blog

Waarom uw project waarschijnlijk zal mislukken zonder BA

Waarom uw project waarschijnlijk zal mislukken zonder een BA-specialist

Blog

Waarom IT-projecten mislukken

Contacteer ons

Naam

Bedrijf

E-mail

Telefoon

Bericht Voeg projectgegevens alsjeblieft, duur, technische stapel, IT-professionals nodig en andere relevante informatie toe

Neem een spraakbericht over uw
project op om het ons beter te helpen begrijpen

Voeg indien nodig aanvullende documenten bij

Bestand uploaden

Je kunt maximaal 1 bestand van 2MB bijvoegen. Geldige bestanden: pdf, jpg, jpeg, png

Wij wijzen u erop dat wanneer u op de verzendknop klikt, Innowise uw persoonsgegevens verwerkt in overeenstemming met ons Privacybeleid om u van de juiste informatie te voorzien.

Wat gebeurt er nu?

Na ontvangst en verwerking van uw aanvraag, nemen wij binnenkort contact met u op om uw projectbehoeften in detail te beschrijven en een NDA te ondertekenen om de vertrouwelijkheid van informatie te garanderen.

Na het bestuderen van de vereisten, stellen onze analisten en ontwikkelaars een projectvoorstel met de omvang van de werkzaamheden, teamgrootte, tijd en kosten schattingen.

Wij regelen een ontmoeting met u om het aanbod te bespreken en tot een overeenkomst.

We tekenen een contract en beginnen zo snel mogelijk aan uw project te werken mogelijk.

Automatisering van bedrijfsprocessen met Camunda: fouttolerante implementatie van BPM-schema's

Wat is Camunda?

Camunda, Spring Boot & BPMN: de concepten begrijpen