5 min lesing

Automatisering av forretningsprosesser med Camunda: feiltolerant implementering av BPM-ordninger

BPMN

Virksomhet

Comunda

Spring Boot

I dagens digitalt drevne verden krever strømlinjeformede og effektive forretningsprosesser for å opprettholde et konkurransefortrinn. Automatisering fremstår som en viktig løsning for å oppnå dette. Ifølge Statista er markedet for administrasjon av forretningsprosesser (BPM) forventes til å nå en størrelse på 14,4 milliarder amerikanske dollar innen 2025. Den økende populariteten og etterspørselen etter BPM-verktøy som Camunda, kjent for sin fleksibilitet og skalerbarhet, vitner om denne trenden. Etter hvert som bedrifter søker pålitelige verktøy for å optimalisere driften, fremstår Camunda som en forløper som baner vei for innovative, feiltolerante automatiseringsløsninger i bransjen.

Hva er Camunda?

Enkelt forklart er Camunda en åpen kildekode-plattform for arbeidsflyt- og beslutningsautomatisering som bringer forretningsbrukere og programvareutviklere sammen. Camunda tilbyr et robust sett med verktøy og funksjoner som gjør det mulig å designe, implementere og optimalisere BPMN-arbeidsflyter (Business Process Model and Notation), noe som gjør forretningsdriften smidigere og mer transparent.

Camunda, Spring Boot og BPMN: forståelse av konseptene

Tre viktige aktører har endret landskapet for styring av forretningsprosesser: Camunda, Spring Boot og BPMN. Hver av dem har funnet sin egen nisje og tilbyr unike funksjoner som tar for seg ulike aspekter ved prosesshåndtering. Men når de kombineres, blir de til en enestående kraftpakke som er i stand til å revolusjonere den digitale forretningsdriften.

Camunda: Camunda er ikke bare nok et verktøy i den store BPM-verktøykassen, men et verktøy som skiller seg ut. Camunda er en robust plattform med åpen kildekode som spesialiserer seg på automatisering av arbeidsflyt og beslutninger. Det primære målet? Å smelte sammen forretningsstrategenes og programvareutviklernes verdener på en sømløs måte. På den måten sikrer den at konseptualisering, design og implementering av forretningsprosesser er effektive, transparente og sammenhengende.

Spring Boot: Spring Boot tar styrken Av Våren rammeverk og løfter dem. Ved å tilby en strømlinjeformet metode for å bygge frittstående Java har det blitt farten til for utviklere som ønsker å minimere standardtekst kode og dykke rett inn i hjertet av prosjektspesifikke funksjoner. Kraften ligger i fleksibiliteten og tilnærmingen til konvensjon-over-konfigurasjon, som forkjemper ideen om smarte standardinnstillinger. Denne tilnærmingen lar utviklere bygge skalerbare applikasjoner raskere, noe som sikrer rettidig levering og jevn ytelse.

BPMN: Hvis vi skulle personifisere BPMN, ville det være forretningsverdenens veltalende lingvist. BPMN er en globalt anerkjent standard som gir et visuelt vokabular for utforming av forretningsprosesser, noe som gjør dem lett forståelige for et bredt spekter av interessenter. Dette universelle språket sørger for at de tekniske nyansene i en prosess kan dechiffreres av både den teknisk kyndige koderen og forretningsstrategen, noe som fremmer samarbeidsdialoger og mer informerte beslutninger.

Synergien mellom Camundas automatiseringsmuligheter, den enkle utviklingen av Spring Boot og BPMNs standardiserte notasjon gir bedrifter en dynamisk trio. Sammen sørger de for at BPM-planene går fra å være teoretiske konstruksjoner på papiret til praktiske implementeringer i den virkelige verden. Det endelige målet? Å utvikle forretningsprosesser som er smidige, robuste og perfekt tilpasset de skiftende kravene i dagens digitale bedriftslandskap.

Grunnleggende BPMN-komponenter

For de som ikke er kjent med BPMN, er det viktig å forstå de viktigste komponentene. Disse komponentene danner grunnlaget for ethvert BPMN-diagram.

Arrangementer

Disse betegner noe som skjer i løpet av en prosess. Hendelser kan starte, avbryte eller avslutte en flyt, og de representeres ofte som sirkler.

Portaler

Gateways handle decision-making within the process. Based on conditions, they control the flow of the process, usually depicted as diamonds.

Aktiviteter

Aktiviteter representerer arbeid som utføres. De kan være oppgaver eller delprosesser og vises som avrundede rektangler.

Kobling av objekter

Disse elementene, inkludert sekvensflyt, meldingsflyt og assosiasjoner, illustrerer rekkefølgen på prosesser og meldingsflyt.

Svømmebaner

Disse kategoriserer BPMN-elementer enten etter rolle (f.eks. leder, regnskapsfører) eller system (f.eks. et ERP-system).

Gjenstander

Disse gir tilleggsinformasjon om prosessen. Vanlige artefakter inkluderer dataobjekter, grupper og merknader.

Fordeler og ulemper med Camunda

Som med alle teknologiske løsninger har Camunda en blanding av fordeler og utfordringer. Her er en omfattende oversikt over fordeler og ulemper.

Fordeler:

Fleksibel og enkel integrering med Java-applikasjoner gjennom Spring Boot.
Et intuitivt modelleringsgrensesnitt for BPMN 2.0.
Gir detaljerte analyser av prosessmålinger.

Ulemper:

Kan ha en brattere læringskurve for ikke-tekniske brukere.
Det er et godt utgangspunkt, men tenk på det som bare en base - selv om Camunda er en kraftig arbeidsflytmotor, trenger du fortsatt videreutvikling av programvaren.

Effektivisering av overbelastede BPMN-diagrammer

Tøff virkelighet

Camunda er utviklet for å få utviklere og analytikere til å snakke samme språk, men ofte kommer virkeligheten i veien.

Mikrotjenester svikter, brukere taster inn feil data, alt kan skje. I dette tilfellet begynner det vakre analytiske diagrammet å bli pyntet med ulike feilhåndterere, loggere og alternative veier. Analytikeren utformer et vakkert, kortfattet og forståelig skjema. Det har noen få delegater og viser logiske veier for prosessflyten under ulike omstendigheter. Slik ser et foreløpig skjema ut når det kommer i hendene på en utvikler:

Det finnes imidlertid ulemper. En slik ordning kan inneholde en kort oppgavebeskrivelse, for eksempel "sjekk klienten", som innebærer flere trinn, beslutningstaking basert på hvert utfall og sammenstilling av de avledede beslutningene til ett enkelt resultat, eventuelt med påfølgende overføring av dette resultatet til eksterne systemer.

Det er klart at det på dette tidspunktet dukker opp feilhåndterere, loggere og tekniske tjenesteelementer på diagrammet eller i koden. På denne måten blir en "analytisk" oppgave i Java-implementeringen omfangsrik og kompleks, eller antallet trinn i skjemaet øker, og hvert trinn ledsages av håndterere og alternative veier. Resultatet er at skjemaet raskt blir innviklet og vanskelig å videreutvikle og modifisere, og å legge til ny funksjonalitet kan innebære at store deler av både skjemaet og delegatkoden må omstruktureres. I bunn og grunn inneholder den et stort antall identiske elementer.

Slik kan den tidligere ordningen se ut i en reell distribusjon:

Det er klart at opplegget er utvidet og blitt mer tungvint. Men det er fordeler: Alle oppgaver har blitt atomiske, og det har oppstått atferdsgrener i tilfelle feil.

Å innse problemet

Hvis vi prøver å skille og innkapsle opplegget og forretningslogikken i Java-koden, kan vi gjøre følgende:

Unngå å duplisere lignende elementer på skjemaet.
Bruk en universell og gjenbrukbar implementering av delegater i Java-koden.
Optimalisere og akselerere prosessflyten.
Forenkle håndteringen av tekniske feil og etablere en prosessadferdslogikk når de oppstår - nesten uten involvering av Java-kode. Dette vil forenkle feilsøking og manuell analyse av mislykkede prosesser i en hendelse.
Drastisk redusere antall prosesser som "faller" inn i hendelser når det oppstår tekniske unntak.
Legge et solid grunnlag for videre utvikling.

For å gjøre det enklere å jobbe med produktet er det bedre å dele opp systemet i atomære oppgaver, redusere det totale volumet av systemelementer, redusere antall tjenestehåndterere, redusere volumet av Java-kode for hver delegat og gjenbruke universelle delegater og utføre øyeblikkelig refaktorering når det er nødvendig. Alt dette innebærer automatisk skriving av enhetstester for alle delegater og hovedveiene i prosessen.

Nedbrytning og forstøvning

Hvis du ser nøye på prosessapplikasjonen og analyserer nodene, kan du se mange repeterende funksjoner: spørringer til eksterne systemer, logging, feilhåndtering, sending av callbacks osv. Man må med andre ord foreta en kritisk vurdering av prosessapplikasjonen og identifisere objekter i den som enkelt kan kapsles inn... Men i hva? I Java-kode? Nei, det ville være ulogisk, for i dette tilfellet ville opplegget være tett knyttet til Java-implementeringen. I denne situasjonen er det fornuftig å vurdere prosesspooler.

Et prosessbasseng er et skjema for en separat prosess som har sin egen kontekst. Det er verdt å merke seg at det er praktisk å trekke ut atomære deler av funksjonaliteten fra hovedprosessen til slike bassenger, samt alle repeterende øyeblikk: sending av varsler, forespørsler til eksterne systemer osv.

Det kan være mange prosesspooler, og det vil være logisk å gruppere dem tematisk. For eksempel spørringer til en bestemt mikrotjeneste, varsling, sending av ulike notifikasjoner. Interaksjon mellom slike pooler kan enkelt settes opp ved hjelp av Camunda messaging. Hver gang en slik pool anropes i Camunda-motoren, sendes en bestemt melding som inneholder en betinget overskrift og det overordnede prosessnummeret for å returnere et svar, samt et sett med nødvendige data for driften av denne spesifikke lille poolen.

Her ser vi hvordan hovedprosessen (nederst) sender en melding som starteren i en annen pool abonnerer på. Når hendelsen inntreffer, starter det andre bassenget en ny instans av prosessen, sender en forespørsel og sender et svar tilbake til hovedprosessen, som deretter fullfører prosessen. I løpet av denne tiden venter hovedprosessen på svarmeldingen fra det eksterne bassenget som den sendte en forespørsel til. Når meldingen kommer, fortsetter prosessen. Hvis det ikke kommer noe svar innen det angitte tidsintervallet, forstår prosessen at den eksterne beregningen ikke er tilgjengelig eller har mislyktes, og avsluttes.

Hva dette tilbyr:

Mulighet for gjenbruk av kode. Hvis du har behov for å kalle den samme koden flere ganger under ulike forhold i løpet av prosessen, kan du ganske enkelt opprette spesifikke meldinger og kalle de tilsvarende atomiske prosesspoolene;
Innkapsling av programvareimplementeringsskjemaet fra forretningsrepresentasjonen. Det spiller ingen rolle hvordan hovedopplegget vil bli redesignet, eller hvilke veier prosessen vil ta. Alle interaksjoner er allerede flyttet til separate, mindre prosesser, noe som gir full fleksibilitet: Det er bare å formulere en forespørsel og vente på svar.
Antallet og sannsynligheten for at hovedprosessen krasjer er betydelig redusert. Før en slik inndeling var prosessen i en usikkerhet på 4 stater:
Svaret har kommet.
Svaret kom ikke fordi den eksterne mikrotjenesten krasjet.
Svaret kom ikke fordi hovedprosessen krasjet mens forespørselen ble sendt.
Svaret kom ikke fordi en tidsavbruddsperiode ble overskredet.

Med denne inndelingen befinner prosessen seg alltid i en enkelt tilstand: enten kom svaret, eller så ventet prosessen og ble avsluttet. For virksomheten er det viktig hvordan prosessen ble avsluttet: om det var en feil eller ikke. Men dette vil være en riktig konklusjon, ikke en hendelse. Dette er viktig fordi en prosess som ikke sitter fast i en hendelse, ikke "forbruker" ressurser, og det er enkelt å logge feil, samle inn statistikk, sette opp varsler og analysere dem.

Det spiller ikke lenger noen rolle hva som skjer med de mindre prosessene. De kan gjøre hva de vil: krasje, kjøre... Bare resultatet er viktig: svaret fra den eksterne ressursen. Og ikke alltid, for hovedprosessen bør ikke garantere funksjonaliteten til eksterne systemer. Det kan for eksempel være meningsløst at prosessen venter på svar fra mikrotjenesten for varsling, siden den kanskje ikke svarer i det hele tatt.
Kompleksiteten i hovedprosessen reduseres kraftig. Kompleks logikk kan fordeles på separate små pooler, som er enklere å feilsøke. En klientverifisering kan for eksempel se slik ut:

Her kan vi se at i det eksterne bassenget kalles flere oppgaver samtidig. La oss se nærmere på dette punktet.

Parallellisering av prosessberegninger

Camunda tillater samtidig kjøring av grener av prosessberegninger. Til dette formålet finnes det en spesiell gateway kalt Parallel Gateway, som gjør det mulig å dele opp flyten i paralleller eller slå sammen flere parallelle beregninger til én strøm. Det er klart at for å akselerere flyten i en prosess vil det være en fordel å delegere visse oppgaver til parallelle tråder. Hvis logikken er uavhengig, kan den utføres parallelt, for eksempel ved å sende samtidige forespørsler til eksterne systemer og vente på svar fra alle samtidig:

Hver gang ved en slik gateway vil det være overheadkostnader forbundet med å opprette nye tråder for oppgavefordeling og slå sammen resultatene. Man kan støte på ulike unntak i forbindelse med låsing, og det er selvfølgelig ikke alltid nødvendig eller berettiget å alltid handle på denne måten, spesielt ikke uten testing, men fordelene er åpenbare.

Ved sekvensiell kjøring er den totale kjøretiden lik summen av kjøretiden for hver enkelt operasjon. Ved parallell kjøring er den derimot lik kjøretiden for den lengste operasjonen. Denne forskjellen er langt fra ubetydelig med tanke på at eksterne kilder ikke svarer umiddelbart, at det gjøres nye forsøk og at det oppstår feil. En annen ubestridelig fordel er "gratis forsøk", det vil si at mens den lengste forespørselen utføres, kan de andre oppgavene hypotetisk sett mislykkes flere ganger og forsøke å gjøre det på nytt uten at det påvirker den totale kjøretiden.

Unntak og repetisjonsforsøk

Blakk? Det kan skje. Standardversjonen av Camunda har muligheten til å prøve på nytt etter en mislykket transaksjon. Med "transaksjon" mener vi Camundas interne mekanisme for kjøring av delegatkode. Starten på en transaksjon kan for eksempel være markøren "async before" eller "async after" på en oppgave i modellereren. Når motoren støter på denne markøren, overføres informasjonen til databasen og en ny asynkron tråd startes. Dette er viktig. Med "transaksjon" mener vi utførelsesdelen mellom anropene til metoden .complete() i TaskService, etterfulgt av registrering av informasjon i databasen. Disse transaksjonene er, i likhet med andre, atomiske.

Når det oppstår et teknisk unntak, dvs. en feil som ikke er av forretningsmessig art, for eksempel at man dividerer med null og glemmer en nullkontroll, gjør transaksjonen en rollback og prøver å starte på nytt. Som standard gjør den dette tre ganger etter hverandre uten pauser. Et nytt forsøk starter når det oppstår et vanlig unntak, som i BPMN-verdenen kalles et teknisk unntak, ikke en BpmnError. En BpmnError som oppstår, stopper prosessen uten nye forsøk. Forestill deg hvordan dette gjør prosessen mer robust.

Det er fornuftig å maksimere denne funksjonen. Derfor settes disse markørene på hver delegat som forespør et eksternt system, og angir antall forsøk og pausen mellom dem, og i delegatkoden skilles logikken for når prosessen skal avsluttes og når den ikke skal det. Det gir full kontroll over mekanismene for unntakshåndtering og nye forsøk. Resultatet er at prosessen prøver å utføre den mislykkede oppgaven på nytt flere ganger, og først etter en rekke mislykkede forsøk blir det en feilmelding.

Den kanskje største utfordringen er håndteringen av tekniske unntak og BPMN-relaterte feil, samt å designe logikken for håndteringen av disse slik at prosessen flyter kontinuerlig. Vi har allerede diskutert noen feil knyttet til håndtering av svar fra eksterne kilder når vi snakket om inndeling i prosesspooler. Vi vil minne om at selve anropet ble innkapslet i en egen miniprosess, og at hovedprosessen enten mottok et svar og gikk videre eller, på grunn av timeout, fulgte "jeg mottok ikke noe svar"-ruten.

La oss nå se på den lille prosessen:

Ser du rammen? Det er en underprosess. Den inneholder spesifikke oppgaver og fanger opp feil som kastes av interne oppgaver. På slike rammer kan jobbutføreren dessuten opprette en jobb for tidtakeren, som angir kjøretiden for alt inne i underprosessen.

Hvordan fungerer det? Utførelsesflyten når delprosessen, oppretter parallell timerbehandling og venter enten på at det som er inne, skal fullføres, eller, hvis timeren går tom først, følger den timerruten. Hvis det oppstår et unntak under prosessen, som underprosessrammen fanger opp, stopper prosessen kjøringen på den aktuelle grenen og følger feilgrenen.

Det er også tydelig at det er mulig å opprette svarforsendelser for kritiske forespørsler. Vær oppmerksom på at feilfangst bare fungerer for BpmnError med en spesifikk kode. Teknisk sett er det derfor viktig å fange opp ethvert unntak og kaste en BpmnError med den nødvendige koden, som fungerer for ErrorBoundaryEvent.

Feilhåndtering i hovedprosessen fungerer på samme måte. Fra flere oppgaver velges det ut logiske enheter som kan plasseres i en underprosessramme, med en lytter satt opp for en bestemt feilkode. Men det er to nyanser her. Den første er at det er upraktisk å opprette flere identiske grener med feilhåndtering som bare skiller seg fra hverandre i koden. Hvis feilhåndteringsstrategien endres, eller for eksempel logging, må mange delegater i skjemaet redesignes, noe som ikke er ønskelig. Derfor kan man vurdere å se på hendelsesbaserte underprosesser.

I bunn og grunn er dette en separat underprosess i prosesspoolen, som bare starter når en bestemt hendelse den abonnerer på, inntreffer. Hvis du for eksempel abonnerer på en slik underprosess for hendelsen BpmnError med en kode, for eksempel MyCustomBusinessError, utløses behandleren når denne hendelsen inntreffer, og når den er fullført, avsluttes prosessen på riktig måte. Ja, den ble ikke vellykket, men den ble avsluttet på riktig måte. I disse underprosessene kan du også implementere ulik håndteringslogikk for samme hendelse avhengig av eksterne forhold, for eksempel ved å varsle om en applikasjonsfeil når prosessen passerer et betinget punkt.

Den andre nyansen er mye mer komplisert. I det virkelige liv er livssyklusen til hver prosess sannsynligvis delt inn i to faser: før og etter leadgenerering. Hvis det oppstår en feil før dataene formateres til et lead, kan prosessen sannsynligvis bare avsluttes med en melding om problemene. Når leadet er generert, er dette ikke lenger mulig.

Vi anbefaler heller ikke å avslutte prosesser hvis det oppstår juridiske forpliktelser underveis, for eksempel hvis det inngås en kontrakt. Hvordan håndterer vi slike feil? Noen tekniske feil, f.eks. i forbindelse med utilgjengelighet av eksterne tjenester, håndteres med automatiske forsøk innen en forhåndsavtalt tidsavbruddsperiode. Men hva om prosessen krasjet, forsøkene har gått, men den hypotetiske eksterne mikrotjenesten fortsatt er nede?

Manuell optimalisering

Vi kommer til begrepet manuell oppløsning, også kjent som kompensasjon.

Hvordan fungerer det? Eventuelle feil fanges opp, delegatene får mulighet til å prøve på nytt om nødvendig, og hvis lykken fortsatt ikke er med dem, går prosessen inn i en feilstatus, men med riktig kode, for eksempel COMPENSATION_ERROR. Denne koden fanges opp av en annen hendelsesbasert underprosess, som behandler, logger, varsler og, viktigst av alt, ikke kan feile uventet. Bare der den er designet for det, kaster den et teknisk unntak som ikke kan fanges opp, og krasjer i en hendelse.

Hvorfor gjøre det på denne måten? For overvåking kan du bruke EXCAMAD - et eksternt administrasjonspanel for Camunda, en analog til Cockpit, med kraftige funksjoner. Det markerer prosesser i hendelser med rødt. Disse prosessene kan endres eller startes på nytt fra ønsket sted. Du kan for eksempel plassere den nødvendige variabelverdien i konteksten og starte prosessen på nytt fra punktet rett etter det problematiske. Dette er praktisk og enkelt, og gir mulighet for manuell problemløsning med minimal innsats.

Automatisering av forretningsprosesser med Camunda: eksempler fra virkeligheten

Camunda er kjent for sin open source-plattform og sitt brukervennlige grensesnitt, og har gjort det mulig for mange bedrifter å optimalisere arbeidsflyten. La oss se på noen eksempler fra virkeligheten.

Bank og finans

Münchener Hypothekenbank eG, en uavhengig eiendomsbank gikk over til å bruke Camundas arbeidsflytmotor for å forbedre og automatisere interne prosesser, spesielt posthåndtering og koordinering av lånesøknader mellom avdelinger. Tidligere var systemet deres rigid, lite fleksibelt og førte til kompleksitet som økte feilprosenten.

I overgangen til en Java-basert mikrotjenestearkitektur valgte de Camunda basert på interne anbefalinger og i tett samarbeid med WDW Consulting Group. Noen av fordelene de fikk umiddelbart fra Camunda, var hyllevarefunksjoner, mens andre krevde mer utvikling. Overgangen resulterte i en sentralisert oppgaveliste som brukes av alle ansatte, og ga fleksibilitet til å opprettholde individuelle prosesser uten å påvirke andre.

Det mest bemerkelsesverdige resultatet har vært en betydelig forbedring av behandlingshastigheten for lånesøknader. Dette kommer både ansatte og sluttkunder til gode. Et bevis på suksessen er at andre avdelinger nå ønsker å ta i bruk Camunda, og banken har til og med ansatt flere utviklere for å støtte implementeringen.

Forsikring

SV Informatik, et datterselskap av SV SparkassenVersicherung, spesialiserer seg på skreddersydde IT-løsninger for forsikringsselskaper. De har tatt i bruk Camunda for å automatisere ulike prosesser på tvers av avdelinger, noe som har ført til betydelige tidsbesparelser og forbedret responstid overfor kundene. Selskapet tok i bruk Camunda i 2018 som en løsning på deres søken etter et effektivt verktøy for modellering av forretningsprosesser, med fokus på å forbedre prosesser og styrke samarbeidet mellom IT og andre avdelinger.

Siden implementeringen har Camunda automatisert oppgaver som oppsigelser av bilforsikringer og forespørsler om forsikringsdokumenter. En bemerkelsesverdig prestasjon var 80%s automatiserte behandling av online stormskaderapporter. Dette viste seg å være spesielt verdifullt under flommen og uværet i Tyskland i 2021. Verktøy som Camunda Optimize og Camunda Cockpit gjør det enklere å overvåke og optimalisere prosessene.

Gjestfrihet

I 2020 ble SV Group, som opererer i Tyskland, Sveits og Østerrike, lanserte en disruptiv digital plattform kalt "likeMagic" med Camundas hjelp. Denne plattformen ga gjestene en sømløs opplevelse, fra bestilling til utsjekking, med resultater som 95% selvinnsjekking/utsjekking og en tilfredshetsscore på 9 av 10. Innovasjonen reduserte bemanningsbehovet og integrerte plattformer som Airbnb sømløst. SV Group innså potensialet og tilbød "likeMagic" til andre overnattingsbedrifter. Innen 2023 hadde de gått fra 2 til over 30 kunder i DACH-regionen, med planer om å nå bredere ut i Europa og sikte på 15 000 rom innen utgangen av året.

Avslutning

Camundas transformative potensial ligger ikke bare i kjernefunksjonalitetene, men også i evnen til å omdefinere forretningsdriften på et grunnleggende nivå. Kombinert med Spring Boot åpner det for sømløse integrasjoner og økt skalerbarhet. For å kunne utnytte Camundas fulle potensial er det avgjørende å forstå hvordan BPMN fungerer. Etter hvert som virksomheter utvikler seg i denne digitale tidsalderen, skiller verktøy som Camunda seg ut ved å tilby dynamiske løsninger som kan svinge og tilpasse seg stadig skiftende behov. Det handler ikke bare om å automatisere prosesser, men også om å fornye arbeidsflyten, øke effektiviteten og skape konkrete resultater som utgjør en forskjell. Ta i bruk kraften i Camunda, og la virksomheten din løfte seg mot nye horisonter.

Dmitry Nazarevich CTO

Dato: 17. januar 2024

Innholdsfortegnelse

Ranger denne artikkelen:

★★★★★ 4/5

4.8/5 (45 anmeldelser)

Relatert innhold

Blogg

Hvordan velge et ERP-system: utforsk de beste ERP-systemene i 2024

Blogg

Looker vs Power BI - revolusjonerer industrien med små deksler

Sammenligning av Looker og Power BI: avduking av BI-verktøyet

Blogg

Hvorfor ansette junior programvareutviklere til prosjektene dine

Blogg

Valg av riktig IT-nearshoring-partner: tips til IT-konsulenter i Europa

Blogg

Hvorfor prosjektet ditt sannsynligvis vil mislykkes uten BA

Hvorfor prosjektet ditt sannsynligvis vil mislykkes uten en BA-spesialist

Blogg

Hvorfor IT-prosjekter mislykkes

Kontakt oss

Hva skjer videre?

Etter at vi har mottatt og behandlet forespørselen din, vil vi komme tilbake til deg innen kort tid for å beskrive prosjektbehovene dine og undertegne en taushetserklæring for å sikre informasjonens konfidensialitet.

Etter å ha undersøkt kravene, utarbeider våre analytikere og utviklere en prosjektforslag med arbeidsomfang, teamstørrelse, tid og kostnader estimater.

Vi arrangerer et møte med deg for å diskutere tilbudet og komme til en avtale.

Vi signerer en kontrakt og begynner å jobbe med prosjektet ditt så raskt som mulig.

Automatisering av forretningsprosesser med Camunda: feiltolerant implementering av BPM-ordninger

Hva er Camunda?

Camunda, Spring Boot og BPMN: forståelse av konseptene