5 min lesing

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

BPMN

Comunda

Oppsummer artikkelen med AI

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)forventestil å 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 Boottar styrken Av Våren rammeverk og løfter dem. Ved å tilby en strømlinjeformet metode for å bygge frittståendeJavahar 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.

Se hvilke relaterte tjenester vi tilbyr

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 håndterer beslutningstaking i prosessen. Basert på betingelser styrer de flyten i prosessen, vanligvis avbildet som diamanter.

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:

However, there are downsides. Such a scheme might contain a brief task description, like “check the client”, which implies several stages, decision-making based on each outcome, and compiling the derived decisions into a single result, possibly with the subsequent transfer of this result to external systems.

It’s clear that at this point, error handlers, loggers, and technical service elements appear on the diagram or in the code. This way, one “analytical” task in the Java implementation becomes voluminous and complex, or the number of steps on the scheme increases, each being accompanied by handlers and alternative pathways. As a result, the scheme quickly becomes convoluted, difficult for further support and modification, and adding new functionality might entail restructuring a vast area of both the scheme and the delegate code. In essence, it contains a massive number of identical elements.

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.
Simplify the handling of technical errors and establish a process behavior logic when they arise – almost without the involvement of Java code. This will significantly simplify debugging and manual analysis of failed processes that are in an incident.
Drastically reduce the number of processes that “fall” into incidents when technical exceptions arise.
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 (tilbakekall), osv. Med andre ord, man må kritisk vurdere prosessapplikasjonen, identifisere objekter fra den som enkelt kan innkapsles… Men inn i hva? Inn i Java-kode? Nei, det ville vært ulogisk, fordi i dette tilfellet ville skjemaet vært tett knyttet til sin Java-implementering. I denne situasjonen er det fornuftig å vurdere prosess-pooler (process pools).

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 oppdelingen er prosessen alltid i en strengt enkel tilstand: enten kom svaret, eller så ventet prosessen og ble avsluttet. For forretningssiden betyr det noe hvordan prosessen endte: om det var en feil eller ikke. Men dette vil være en riktig avslutning, ikke en hendelse (incident). Dette er viktig fordi en prosess som ikke sitter fast i en hendelse, ikke “forbruker” ressurser, og feil kan enkelt logges, statistikk samles inn, varsler settes opp, og analyseres.

It no longer matters what happens with the minor processes. They can do whatever they want: crash, run… Only the result is important: the response from the external resource. And even then, not always, because the main process shouldn’t guarantee the functionality of external systems. For instance, there might be no sense in the process waiting for a response from the notification microservice since there could be no response at all.
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.

Med sekvensiell kjøring er den totale utførelsestiden lik summen av utførelsestiden for hver operasjon. I kontrast, med parallell kjøring, tilsvarer den utførelsestiden til den lengste operasjonen. Gitt forholdene med ikke-umiddelbare svar fra eksterne kilder, nye forsøk (retries) og feil, er denne forskjellen langt fra ubetydelig. En annen ubestridelig fordel er formen for “gratis nye forsøk”, det vil si at mens den lengste forespørselen utføres, har de andre oppgavene hypotetisk muligheten til å feile flere ganger og forsøke å gjøre handlingene sine på nytt uten å påvirke den totale oppgaveutførelsestiden.

Unntak og repetisjonsforsøk

Ødelagt? Det skjer. Standardversjonen av Camunda har muligheten til å prøve en mislykket transaksjon på nytt. Med “transaksjon” mener vi Camundas interne mekanisme for å utføre delegat-kode. Starten på en transaksjon kan for eksempel være markøren “async before” eller “async after” på en oppgave i modulatoren (modeler). Når motoren støter på denne markøren, lagrer den informasjonen sin i databasen og starter en ny asynkron tråd. Dette er viktig. For å gå dypere: med “transaksjon” mener vi utførelsesdelen mellom kallene til .complete()-metoden i TaskService, etterfulgt av lagring av informasjon i databasen. Disse transaksjonene, som andre, er 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.

Perhaps, the biggest challenge is the handling of technical exceptions and BPMN-related errors, as well as designing the logic of their handling for a continuous flow of the process. We’ve already discussed some errors related to handling responses from external sources when talking about dividing into process pools. We’d like to remind you that the very call was encapsulated into a separate mini-process, and the main one either received a response and proceeded further or, due to a timeout, followed the “I didn’t receive a response” route.

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 adminpanel for Camunda, en analog til Cockpit, med kraftige funksjoner. Det uthever prosesser i hendelser (incidents) i rødt. Disse prosessene kan modifiseres eller startes på nytt fra ønsket punkt. 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, rett frem og muliggjør 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 lanserte SV Group, med virksomhet i Tyskland, Sveits og Østerrike, en banebrytende digital plattform kalt ‘likeMagic’ med Camundas hjelp. Denne plattformen ga en sømløs gjesteopplevelse, fra bestilling til utsjekking, med resultater som inkluderte en 95 % selv-innsjekking/utsjekking-rate og en 9 av 10 poengsum for gjestetilfredshet. Innovasjonen reduserte bemanningsbehovet og integrerte plattformer som Airbnb sømløst. Etter å ha anerkjent potensialet, tilbød SV Group ‘likeMagic’ til andre aktører innen overnattingsbransjen. Innen 2023 hadde de vokst fra 2 til over 30 kunder i DACH-regionen, med planer om en bredere europeisk rekkevidde og et mål om 15 000 rom innen årets slutt.

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)

Kontakt oss

Bestill en samtale eller fyll ut skjemaet nedenfor, så vil vi kontakte deg så snart vi har behandlet forespørselen din.

Navn

Firma

E-post

Telefon

Melding

Send oss en talemelding

Legg ved dokumenter

Last opp fil

Du kan legge ved én fil opptil 2MB. Gyldige filformater: pdf, jpg, jpeg, png.

Ved å klikke Send, samtykker du til at Innowise behandler dine personopplysninger i henhold til vår Personvernerklæring for å gi deg relevant informasjon. Ved å oppgi telefonnummeret ditt, godtar du at vi kan kontakte deg via talesamtaler, SMS og meldingsapper. Samtale-, meldings- og datakostnader kan påløpe.

Du kan også sende oss forespørselen din
til contact@innowise.com

Hva skjer videre?

Når vi har mottatt og behandlet forespørselen din, vil vi kontakte deg for å diskutere prosjektbehovene dine og signere en NDA for å sikre konfidensialitet.

Etter å ha undersøkt dine ønsker, behov og forventninger, vil teamet vårt utarbeide et prosjektforslag med omfang av arbeid, teamstørrelse, tids- og kostnadsestimater.

Vi vil arrangere et møte med deg for å diskutere tilbudet og fastsette detaljene.

Til slutt vil vi signere en kontrakt og starte arbeidet med prosjektet ditt umiddelbart.