5 min læsning

Automatisering af forretningsprocesser med Camunda: Fejltolerant implementering af BPM-ordninger

BPMN

Comunda

I dagens digitalt drevne verden kræver det strømlinede og effektive forretningsprocesser at opretholde en konkurrencemæssig fordel. Automatisering skiller sig ud som en nøgleløsning til at opnå dette. Ifølge Statista er markedet for styring af forretningsprocesser (BPM) forventes til at nå en størrelse på 14,4 milliarder amerikanske dollars i 2025. Den stigende popularitet og efterspørgsel efter BPM-værktøjer som Camunda, der er kendt for sin fleksibilitet og skalerbarhed, vidner om denne tendens. Når virksomheder søger pålidelige værktøjer til at optimere deres drift, fremstår Camunda som en forløber, der baner vejen for innovative, fejltolerante automatiseringsløsninger i branchen.

Hvad er Camunda?

Camunda er ganske enkelt en open source-platform til automatisering af arbejdsgange og beslutninger, som bringer forretningsbrugere og softwareudviklere sammen. Gennem sit robuste sæt af værktøjer og funktioner tilbyder Camunda måder at designe, implementere og optimere BPMN (Business Process Model and Notation) workflows på, hvilket gør forretningsdriften mere jævn og gennemsigtig.

Camunda, Spring Boot & BPMN: forståelse af koncepterne

Tre nøgleaktører har omformet landskabet for styring af forretningsprocesser: Camunda, Spring Boot og BPMN. De har hver især skabt deres egen niche og tilbyder unikke funktioner, der adresserer forskellige aspekter af processtyring. Men når de kombineres, bliver de til et kraftcenter uden sidestykke, der kan revolutionere den digitale virksomhedsdrift.

Camunda: Dette er ikke bare endnu et værktøj i den store BPM-værktøjskasse; det er en ener. Som en robust open source-platform har Camunda specialiseret sig i automatisering af arbejdsgange og beslutninger. Dets primære mål? At smelte forretningsstrategernes og softwareudviklernes verdener sammen uden problemer. På den måde sikrer den, at konceptualisering, design og implementering af forretningsprocesser er effektive, gennemsigtige og sammenhængende.

Spring Støvle: Spring Støvle tager styrkerne i Spring-rammen og løfter dem. Ved at tilbyde en strømlinet metode til at bygge selvstændige Java applikationer, er det blevet det foretrukne valg for udviklere, der ønsker at minimere kedelkode og dykke direkte ned i hjertet af projektspecifikke funktioner. Dens styrke ligger i dens fleksibilitet og dens konvention-over-konfiguration-tilgang, som fremmer ideen om smarte standardindstillinger. Denne tilgang gør det muligt for udviklere at bygge skalerbare applikationer hurtigere, hvilket sikrer rettidig levering og ensartet ydeevne.

BPMN: Hvis vi skulle personificere BPMN, ville det være forretningsverdenens veltalende lingvist. Som en globalt anerkendt standard giver BPMN et visuelt ordforråd til udarbejdelse af forretningsprocesser, hvilket gør dem let forståelige for en bred vifte af interessenter. Dette universelle sprog sikrer, at de tekniske nuancer i en proces kan afkodes af både den teknisk kyndige koder og forretningsstrategen, hvilket fremmer samarbejdsdialoger og mere informeret beslutningstagning.

Synergien mellem Camundas automatiseringsmuligheder, Spring Boot's udviklingsvenlighed og BPMN's standardiserede notation giver virksomheder en dynamisk treenighed. Sammen sikrer de, at BPM-ordninger går fra at være teoretiske konstruktioner på papiret til at blive implementeret i den virkelige verden. Det endelige mål? At skabe forretningsprocesser, der er smidige, modstandsdygtige og perfekt afstemt med de skiftende krav i det moderne digitale virksomhedslandskab.

Se, hvilke relaterede tjenester vi tilbyder

BPMN's grundlæggende komponenter

For dem, der ikke kender BPMN, er det afgørende at forstå de væsentlige komponenter. Disse komponenter udgør grundlaget for ethvert BPMN-diagram.

Begivenheder

De betegner noget, der sker i løbet af en proces. Begivenheder kan starte, afbryde eller afslutte et flow, og de repræsenteres ofte som cirkler.

Gateways

Gateways håndterer beslutningstagning i processen. Baseret på betingelser styrer de processens flow, som regel afbildet som diamanter.

Aktiviteter

Aktiviteter repræsenterer arbejde, der udføres. De kan være opgaver eller delprocesser og vises som afrundede rektangler.

Tilslutning af objekter

Disse elementer, herunder sekvensstrømme, meddelelsesstrømme og associationer, illustrerer rækkefølgen af processer og strømmen af meddelelser.

Svømmebaner

Disse kategoriserer BPMN-elementer enten efter rolle (f.eks. leder, bogholder) eller system (f.eks. et ERP-system).

Artefakter

Disse giver yderligere information om processen. Almindelige artefakter omfatter dataobjekter, grupper og anmærkninger.

Fordele og ulemper ved Camunda

Som med enhver teknologisk løsning giver Camunda en blanding af fordele og udfordringer. Her er et omfattende kig på fordele og ulemper.

Fordele:

Fleksibel og nem integration med Java-applikationer via Spring Boot.
En intuitiv modelleringsgrænseflade til BPMN 2.0.
Giver detaljerede analyser af procesmålinger.

Ulemper:

Kan have en stejlere indlæringskurve for ikke-tekniske brugere.
Det er et stærkt udgangspunkt, men tænk på det som en base - selvom Camunda er en stærk workflow-motor, har du stadig brug for yderligere softwareudvikling.

Effektivisering af overbelastede BPMN-diagrammer

Den barske virkelighed

Camunda er designet til at få udviklere og analytikere til at tale samme sprog, men ofte griber virkeligheden ind.

Microservices fejler, brugere indtaster forkerte data, alt kan ske. I dette tilfælde begynder det smukke analytiske diagram at blive udsmykket med forskellige fejlhåndteringer, loggere og alternative veje. Analytikeren designer et smukt, kortfattet og forståeligt skema. Det har nogle få delegerede og giver logiske veje for procesflowet under forskellige omstændigheder. Sådan ser et foreløbigt skema ud, når det kommer i hænderne på en udvikler:

Der er dog ulemper. En sådan ordning kan indeholde en kort opgavebeskrivelse som "tjek klienten", som indebærer flere faser, beslutningstagning baseret på hvert resultat og kompilering af de afledte beslutninger til et enkelt resultat, muligvis med efterfølgende overførsel af dette resultat til eksterne systemer.

Det er klart, at der på dette tidspunkt dukker fejlhåndteringer, loggere og tekniske serviceelementer op på diagrammet eller i koden. På den måde bliver en "analytisk" opgave i Java-implementeringen omfangsrig og kompleks, eller antallet af trin i skemaet øges, og hvert trin ledsages af handlere og alternative veje. Resultatet er, at skemaet hurtigt bliver indviklet og vanskeligt at understøtte og ændre yderligere, og tilføjelse af ny funktionalitet kan medføre omstrukturering af en stor del af både skemaet og delegatkoden. I bund og grund indeholder det et enormt antal identiske elementer.

Her er, hvordan den tidligere ordning kunne se ud i en virkelig implementering:

Det er klart, at systemet er blevet udvidet og mere besværligt. Men der er fordele: Alle opgaver er blevet atomare, og der er opstået grene af adfærd i tilfælde af fejl.

At indse problemet

Hvis vi forsøger at adskille og indkapsle skemaet og forretningslogikken i Java-koden, kan vi gøre følgende:

Undgå at duplikere lignende elementer på planen.
Brug en universel og genanvendelig implementering af delegater i Java-koden.
Optimer og fremskynd processens flow.
Forenkle håndteringen af tekniske fejl og etablere en logik for procesadfærd, når de opstår - næsten uden inddragelse af Java-kode. Det vil i høj grad forenkle fejlsøgning og manuel analyse af fejlbehæftede processer i en hændelse.
Reducer drastisk antallet af processer, der "falder" i hændelser, når der opstår tekniske undtagelser.
Lægger et solidt fundament for videre udvikling.

For at gøre det lettere at arbejde med produktet er det bedre at nedbryde systemet i atomare opgaver, reducere den samlede mængde af systemelementer, reducere antallet af servicehandlere, reducere mængden af Java-kode for hver delegat og genbruge universelle delegater og foretage øjeblikkelig refaktorering, når det er nødvendigt. Alt dette indebar automatisk at skrive enhedstests for alle delegerede og de vigtigste stier i processen.

Nedbrydning og forstøvning

Hvis man ser nærmere på procesapplikationen og analyserer dens knudepunkter, kan man se mange gentagne funktioner: forespørgsler til eksterne systemer, logning, fejlhåndtering, afsendelse af tilbagekald osv. Med andre ord skal man kritisk vurdere procesapplikationen og identificere objekter fra den, som let kan indkapsles ... Men til hvad? Til Java-kode? Nej, det ville være ulogisk, for i dette tilfælde ville ordningen være tæt knyttet til dens Java-implementering. I denne situation giver det mening at overveje procespuljer.

En procespulje er et skema over en separat proces, der har sin egen kontekst. Det er bemærkelsesværdigt, at det er praktisk at udtrække atomare stykker funktionalitet fra hovedprocessen til sådanne puljer, såvel som alle gentagne øjeblikke: afsendelse af meddelelser, anmodninger til eksterne systemer osv.

Der kan være mange procespuljer, og det ville være logisk at gruppere dem tematisk. For eksempel forespørgsler til en bestemt mikrotjeneste, alarmering, afsendelse af forskellige notifikationer. Interaktion mellem sådanne pools kan nemt sættes op ved hjælp af Camunda messaging. Hver gang en sådan pulje kaldes i Camunda-motoren, sendes en bestemt besked, der indeholder en betinget header og det overordnede procesnummer til returnering af et svar samt et sæt nødvendige data til driften af denne specifikke lille pulje.

Her ser vi, hvordan hovedprocessen (nederst) sender en besked, som starteren af en anden pool abonnerer på. Når hændelsen indtræffer, starter den anden pulje en ny instans af processen, laver en anmodning og sender et svar tilbage til hovedprocessen, hvorefter den afsluttes med succes. I løbet af denne tid venter hovedprocessen på svarhændelsen fra den eksterne pulje, som den sendte en anmodning til. Når beskeden ankommer, fortsætter processen. Hvis der ikke kommer noget svar inden for det angivne tidsinterval, forstår processen, at den eksterne beregning ikke er tilgængelig eller er mislykket, og den afsluttes.

Hvad dette tilbyder:

Mulighed for genbrug af kode. Hvis du har brug for at kalde den samme kode flere gange under forskellige forhold i løbet af processen, kan du blot oprette specifikke beskeder og kalde de tilsvarende atomare procespuljer;
Indkapsling af softwareimplementeringsskemaet fra dets forretningsrepræsentation. Det er ligegyldigt, hvordan hovedskemaet bliver redesignet, eller hvilke veje processen vil tage. Alle interaktioner er allerede flyttet til separate mindre processer, hvilket giver fuld fleksibilitet: Bare lav en anmodning og vent på et svar.
Antallet af og sandsynligheden for nedbrud i hovedprocessen reduceres betydeligt. Før en sådan opdeling var processen i en usikkerhed på 4 tilstande:
Svaret er kommet.
Svaret kom ikke, fordi den eksterne mikrotjeneste gik ned.
Svaret kom ikke, fordi hovedprocessen gik ned, mens den sendte anmodningen.
Svaret kom ikke, fordi en timeout var overskredet.

Med denne opdeling er processen altid i en enkelt tilstand: enten kom svaret, eller også ventede processen og sluttede. For virksomheden er det ikke ligegyldigt, hvordan processen sluttede: om det var en fejl eller ej. Men det vil være en korrekt konklusion, ikke en hændelse. Det er vigtigt, fordi en proces, der ikke sidder fast i en hændelse, ikke "forbruger" ressourcer, og fejl kan nemt logges, statistikker indsamles, alarmer opsættes og analyseres.

Det er ikke længere vigtigt, hvad der sker med de mindre processer. De kan gøre, hvad de vil: gå ned, køre... Kun resultatet er vigtigt: svaret fra den eksterne ressource. Og selv da er det ikke altid, for hovedprocessen skal ikke garantere de eksterne systemers funktionalitet. For eksempel giver det måske ingen mening, at processen venter på et svar fra notifikationsmikroservicen, da der måske slet ikke kommer noget svar.
Hovedprocessens kompleksitet er kraftigt reduceret. Kompleks logik kan fordeles på separate små pools, som er lettere at fejlfinde. For eksempel kan klientverifikation se sådan ud:

Her kan vi se, at der i den eksterne pool kaldes på flere opgaver samtidig. Lad os dykke dybere ned i dette punkt.

Parallelisering af procesberegninger

Camunda giver mulighed for samtidig udførelse af grene af procesberegninger. Til dette formål er der en særlig gateway kaldet Parallel Gateway, som gør det muligt at opdele flowet i paralleller eller at flette flere parallelle beregninger sammen til én strøm. Det er klart, at det ville være en fordel at uddelegere visse opgaver til parallelle tråde for at fremskynde flowet i en proces. Hvis logikken er uafhængig, kan den udføres parallelt, f.eks. ved at lave samtidige anmodninger til eksterne systemer og vente på svar fra dem alle på én gang:

Hver gang der er en sådan gateway, vil der være omkostninger forbundet med at oprette nye tråde til opgavedelingen og flette resultaterne sammen. Man kan støde på forskellige låseundtagelser, og det er selvfølgelig ikke altid nødvendigt eller berettiget altid at handle på denne måde, især ikke uden at teste, men fordelene er tydelige.

Ved sekventiel udførelse er den samlede udførelsestid lig med summen af udførelsestiderne for hver operation. I modsætning hertil er den ved parallel udførelse lig med udførelsestiden for den længste operation. I betragtning af forholdene med ikke øjeblikkelige svar fra eksterne kilder, nye forsøg og fejl er denne forskel langt fra ubetydelig. En anden ubestridelig fordel er "frie forsøg", dvs. at mens den længste anmodning udføres, har de andre opgaver hypotetisk set mulighed for at fejle flere gange og forsøge at gøre deres handlinger om uden at påvirke den samlede opgaveudførelsestid.

Undtagelser og gentagelsesforsøg

Er du flad? Det kan ske. Out-of-the-box-versionen af Camunda har mulighed for at prøve en mislykket transaktion igen. Med "transaktion" mener vi Camundas interne mekanisme til udførelse af delegeret kode. Starten på en transaktion kan f.eks. være markøren "async before" eller "async after" på en opgave i modelleringsværktøjet. Når motoren støder på denne markør, overfører den sine oplysninger til databasen og starter en ny asynkron tråd. Dette er vigtigt. For at dykke dybere ned, mener vi med "transaktion" udførelsesafsnittet mellem kald til .complete()-metoden i TaskService, efterfulgt af registrering af oplysninger i databasen. Disse transaktioner er ligesom andre atomare.

Når der opstår en teknisk undtagelse, dvs. en ikke-forretningsmæssig fejl, som f.eks. at dividere med nul og glemme en null-kontrol, foretager transaktionen en rollback og forsøger at starte forfra. Som standard gør den det tre gange i træk uden pauser. Et nyt forsøg starter, når der opstår en almindelig undtagelse, som i BPMN-verdenen kaldes en teknisk undtagelse, ikke en BpmnError. En opstået BpmnError stopper processen uden nye forsøg. Forestil dig, hvordan dette forbedrer processens modstandsdygtighed.

Det giver mening at maksimere denne funktion. Derfor sættes disse markører på hver delegat, der anmoder om et eksternt system, og angiver antallet af gentagelser og pausen mellem dem, og i delegatkoden adskilles logikken for, hvornår processen skal afsluttes, og hvornår den ikke skal. Det giver fuld kontrol over undtagelseshåndteringen og gentagelsesmekanismerne. Resultatet er, at processen forsøger at gentage den mislykkede opgave flere gange, og først efter en række fejl producerer den en fejl.

Den største udfordring er måske håndteringen af tekniske undtagelser og BPMN-relaterede fejl samt at designe logikken i håndteringen af dem, så processen kan forløbe kontinuerligt. Vi har allerede diskuteret nogle fejl i forbindelse med håndtering af svar fra eksterne kilder, da vi talte om opdeling i procespuljer. Vi vil gerne minde dig om, at selve opkaldet blev indkapslet i en separat miniproces, og den vigtigste enten modtog et svar og fortsatte videre eller, på grund af en timeout, fulgte ruten "Jeg modtog ikke noget svar".

Lad os nu se på den meget lille proces:

Kan du se rammen? Det er en underproces. Den indeholder specifikke opgaver og opsamler fejl fra interne opgaver. På sådanne rammer er jobeksekutoren desuden i stand til at oprette et job til timeren, som indstiller udførelsestiden for alt inden for underprocessen.

Hvordan fungerer det? Kørselsflowet når frem til underprocessen, opretter parallel timerbehandling og venter enten på, at det, der er indeni, bliver afsluttet, eller hvis timeren løber ud først, følger den timerruten. Hvis der opstår en undtagelse under processen, som underprocesrammen fanger, vil processen stoppe sin udførelse på den aktuelle gren og følge fejlgrenen.

Det er også tydeligt, at der er mulighed for at oprette svarforsendelser til kritiske anmodninger. Bemærk, at fejlopfangning kun fungerer for BpmnError med en bestemt kode. Derfor er det teknisk set vigtigt at fange enhver undtagelse og kaste en BpmnError med den påkrævede kode, som fungerer for ErrorBoundaryEvent.

Fejlhåndtering i hovedprocessen fungerer på samme måde. Fra flere opgaver udvælges logiske enheder, som kan placeres i en underprocesramme med en lytter opsat til en specifik fejlkode. Men der er to nuancer her. Den første er, at det er upraktisk at oprette flere identiske grene med fejlhåndtering, som kun adskiller sig i koden. Hvis fejlhåndteringsstrategien ændres eller f.eks. logning, skal mange delegerede i skemaet redesignes, hvilket ikke er ønskeligt. Derfor kan man overveje at se på begivenhedsbaserede underprocesser.

I bund og grund er det en separat underproces i procespuljen, som kun starter, når en bestemt hændelse, som den abonnerer på, indtræffer. Hvis du f.eks. abonnerer på BpmnError-begivenheden med en kode, f.eks. MyCustomBusinessError, vil handleren blive udløst, når denne begivenhed indtræffer, og når den er færdig, vil processen slutte korrekt. Ja, den sluttede ikke som en succes, men den sluttede korrekt. I disse underprocesser kan man også implementere forskellig håndteringslogik for den samme hændelse afhængigt af eksterne forhold, f.eks. kan man vælge at give besked om en applikationsfejl, når processen passerer et betinget punkt.

Den anden nuance er meget mere kompliceret. I det virkelige liv er livscyklussen for hver proces sandsynligvis opdelt i to forretningsfaser: før leadgenerering og efter den. Hvis der opstod en fejl, før dataene blev formateret til et lead, kunne processen sandsynligvis bare afsluttes med en meddelelse om de opståede problemer. Når leadet er genereret, er dette ikke længere muligt.

Vi anbefaler heller ikke at afslutte processer, hvis der opstår juridiske forpligtelser i løbet af processen, f.eks. hvis der underskrives en kontrakt. Hvordan håndterer vi sådanne fejl? Nogle tekniske fejl, f.eks. i forbindelse med eksterne tjenesters utilgængelighed, håndteres med automatiske forsøg inden for en på forhånd aftalt timeout. Men hvad nu, hvis processen er gået ned, der er foretaget flere forsøg, men den hypotetiske eksterne mikrotjeneste stadig er nede?

Manuel optimering

Vi kommer til begrebet manuel løsning eller, også kendt som, kompensation.

Hvordan fungerer det? Eventuelle fejl fanges, de delegerede får mulighed for at prøve igen, hvis det er nødvendigt, og hvis heldet stadig ikke er med dem, går processen i en fejltilstand, men med den relevante kode, for eksempel COMPENSATION_ERROR. Denne kode opfanges af en anden begivenhedsbaseret underproces, som behandler, logger og giver besked, og som vigtigst af alt ikke kan fejle uventet. Kun hvor den er designet til det, kaster den en teknisk undtagelse, der ikke kan opfanges, og går ned i en hændelse.

Hvorfor gøre det på denne måde? Til overvågning kan du bruge EXCAMAD - et eksternt administratorpanel til Camunda, en analog til Cockpit, med kraftfulde funktioner. Det fremhæver processer i hændelser med rødt. Disse processer kan ændres eller genstartes fra det ønskede punkt. Du kan f.eks. placere den nødvendige variabelværdi i konteksten og genstarte processen fra punktet lige efter det problematiske punkt. Det er praktisk, ligetil og giver mulighed for manuel problemløsning med minimal indsats.

Automatisering af forretningsprocesser med Camunda: eksempler fra det virkelige liv

Camunda er kendt for sin open source-platform og brugervenlige grænseflade og har gjort det muligt for mange virksomheder at optimere deres arbejdsgange. Lad os udforske et par eksempler fra det virkelige liv.

Bank og finans

Münchener Hypothekenbank eGEn uafhængig ejendomsbank gik over til at bruge Camundas workflow-motor til at forbedre og automatisere interne processer, især posthåndtering og koordinering af låneansøgninger mellem afdelingerne. Tidligere var deres system stift, manglede fleksibilitet og førte til kompleksitet, der øgede fejlraten.

I deres bevægelse mod en Java-baseret mikroservice-arkitektur valgte de Camunda på baggrund af interne anbefalinger og arbejdede tæt sammen med WDW Consulting Group. Nogle af de fordele, de fik med det samme fra Camunda, var hyldefunktioner, mens andre krævede mere udvikling. Denne overgang resulterede i en centraliseret opgaveliste, der blev brugt af alle medarbejdere, og gav fleksibilitet til at opretholde individuelle processer uden at påvirke andre.

Det mest bemærkelsesværdige resultat har været en betydelig forbedring af behandlingshastigheden for låneansøgninger. Det kommer både medarbejdere og slutkunder til gode. Som et bevis på succesen ønsker andre afdelinger nu at indføre Camunda, og banken har endda ansat flere udviklere til at understøtte implementeringen yderligere.

Forsikring

SV Informatiket datterselskab af SV SparkassenVersicherung, har specialiseret sig i skræddersyede IT-løsninger til forsikringsselskaber. De indarbejdede Camunda for at automatisere forskellige processer på tværs af afdelinger, hvilket førte til bemærkelsesværdige tidsbesparelser og forbedrede svartider for kunderne. Virksomheden indførte Camunda i 2018 som en løsning på deres søgen efter et effektivt værktøj til modellering af forretningsprocesser med fokus på at forbedre processer og styrke samarbejdet mellem IT og andre afdelinger.

Siden implementeringen har Camunda automatiseret opgaver som annullering af motorkøretøjsforsikringer og anmodninger om policedokumenter. En bemærkelsesværdig præstation var den 80% automatiserede behandling af online stormskaderapporter. Det viste sig at være særligt værdifuldt under oversvømmelserne og stormene i Tyskland i 2021. Værktøjer som Camunda Optimize og Camunda Cockpit letter procesovervågning og -optimering.

Gæstfrihed

I 2020 vil SV Groupsom opererer i Tyskland, Schweiz og Østrig, lancerede en disruptiv digital platform kaldet 'likeMagic' med Camundas hjælp. Denne platform gav en problemfri gæsteoplevelse, fra booking til check-out, med resultater som en 95% selv-check-in/out-rate og en gæstelykke-score på 9 ud af 10. Innovationen reducerede personalebehovet og integrerede platforme som Airbnb problemfrit. SV Group anerkendte potentialet og tilbød 'likeMagic' til andre hoteludbydere. I 2023 udvidede de fra 2 til over 30 kunder i DACH-regionen med planer om en bredere europæisk rækkevidde og en målsætning om 15.000 værelser ved årets udgang.

Afslutning

Camundas transformative potentiale ligger ikke kun i dens kernefunktionaliteter, men i dens evne til at omdefinere forretningsdriften på et grundlæggende niveau. Kombineret med Spring Boot åbner det en dør til sømløse integrationer og forbedret skalerbarhed. Forståelse af BPMN er afgørende for at udnytte Camundas fulde potentiale. Når virksomheder udvikler sig i denne digitale tidsalder, skiller værktøjer som Camunda sig ud ved at tilbyde dynamiske løsninger, der kan dreje og tilpasse sig til stadigt skiftende behov. Det handler ikke kun om at automatisere processer, det handler om at innovere arbejdsgange, forbedre effektiviteten og skabe konkrete resultater, der gør en forskel. Omfavn kraften i Camunda, og lad din virksomhed svæve mod nye horisonter.

Dmitry Nazarevich CTO

Dato: 17. januar 2024

Indholdsfortegnelse

Bedøm denne artikel:

★★★★★ 4/5

4.8/5 (45 anmeldelser)

Kontakt os

Book et opkald eller udfyld formularen nedenfor, så vender vi tilbage til dig, når vi har behandlet din anmodning.

Navn

Virksomhed

E-mail

Telefon

Besked

Send os en talebesked

Vedhæft dokumenter

Upload fil

Du kan vedhæfte 1 fil på op til 2 MB. Gyldige filformater: pdf, jpg, jpeg, png.

Ved at klikke på Send accepterer du, at Innowise behandler dine personlige data i henhold til vores Politik for beskyttelse af personlige oplysninger for at give dig relevante oplysninger. Ved at indsende dit telefonnummer accepterer du, at vi kan kontakte dig via taleopkald, sms og beskedapps. Opkalds-, besked- og datatakster kan være gældende.

Du kan også sende os din anmodning
til contact@innowise.com

Hvad sker der nu?

Når vi har modtaget og behandlet din anmodning, vender vi tilbage til dig for at beskrive dine projektbehov og underskriver en NDA for at sikre fortrolighed.

Når vi har undersøgt dine ønsker, behov og forventninger, udarbejder vores team et projektforslag med forslag med arbejdets omfang, teamstørrelse, tids- og omkostningsoverslag.

Vi arrangerer et møde med dig for at diskutere tilbuddet og få detaljerne på plads.

Til sidst underskriver vi en kontrakt og begynder at arbejde på dit projekt med det samme.

Automatisering af forretningsprocesser med Camunda: Fejltolerant implementering af BPM-ordninger

Hvad er Camunda?

Camunda, Spring Boot & BPMN: forståelse af koncepterne

Se, hvilke relaterede tjenester vi tilbyder