Veikart for migrering fra monolitt til mikrotjenester: modernisering av bedriftsapper

Michael Labutin

5. april 2025 12 min

Hvis du er her, er sjansen stor for at det monolittiske systemet ditt er i ferd med å bli mer en byrde enn en ressurs. Sakte lanseringssykluser, skaleringshodepine og en rigid arkitektur gjør det vanskeligere å henge med. Jo større appen din blir, desto mer frustrerende blir den. Ny teknologi integreres ikke problemfritt, smidigheten går ned, og påliteligheten begynner å bli dårligere.

Mikrotjenester kan snu opp ned på dette ved å gjøre systemet ditt modulært, øke hastigheten på distribusjonene og la deg skalere akkurat det du trenger når du trenger det. Men her er haken: Migrering handler ikke bare om å dele opp kode. Hvis du ikke planlegger det riktig, kan du ende opp med mer kompleksitet, integrasjonsmareritt og uventede kostnader.

I denne artikkelen går jeg gjennom et veikart fra den virkelige verden for å gå fra monolitt til mikrotjenester. Ikke noe fluff - bare praktiske trinn, dyrekjøpt lærdom fra løsningsarkitektene våreog strategier som faktisk fungerer. La oss dykke ned i det.

Trinn for å migrere fra monolittisk til mikrotjenestearkitektur

Trinn 1: Planlegging av en migrering fra monolitttjenester til mikrotjenester

Jeg har sett mange selskaper som tror mikrotjenester er den magiske løsningen, men som ender opp med mer kompleksitet, ødelagte arbeidsflyter og skyhøye kostnader. Og er det én ting jeg har lært, så er det at det å hoppe rett inn i den tekniske siden uten en solid plan er en rask vei til kaos.

Det er fristende å begynne å rive fra hverandre en monolitt og spinne opp tjenester, men før vi i det hele tatt rører koden, jobber vi sammen med kundene for å kartlegge hvorfor, når og hvordan migreringen skal gjennomføres. På den måten gir hvert steg fremover faktisk verdi.

Sette de riktige målene: Hvorfor migrerer du?

Når kunder kommer til oss for å bytte fra monolitt- til mikrotjenester, spør jeg hva som driver dem til å ta denne beslutningen. Svarene varierer, men som oftest får jeg høre at det er fordi konkurrentene gjør det samme. Og det er ærlig talt ingen god grunn. Å hoppe over til mikrotjenester uten et klart mål fører vanligvis bare til mer hodebry, ikke til faktiske fremskritt.

Så spør deg selv før du tar steget:

Hva håper du å oppnå?
Har du vurdert alternativer til å bruke mikrotjenester?
Hvordan vil du vite om overgangen fungerer?

Hvis du ikke er 100% sikker - ingen grunn til bekymring. Vi hjelper deg med å definere de viktigste måleparameterne og forretningsresultatene på forhånd, slik at hver eneste tekniske beslutning gir resultater.

Mikrotjenester: passer de for alle? Ikke alltid

Mikrotjenester gir modularitet, uavhengig skalering og raskere innovasjon. Men de er ikke noen mirakelkur. Noen virksomheter klarer seg fint med en monolitt, spesielt hvis appen deres er enkel, stabil og ikke endrer seg mye.

Tenk deg en liten ansattportal eller et lagersystem som bare en håndfull personer bruker. Hvis det fungerer bra og ikke trenger stadige oppdateringer, kan det å dele det opp i mikrotjenester bare føre til en masse kompleksitet uten noen reell gevinst.

Derfor lanserer vi ikke mikrotjenester bare for sakens skyld. I stedet ser vi på hva du spesifikt trenger, og om mikrotjenester vil gi reelle fordeler. Hvis de gjør det, er det flott - da går vi for det. Hvis ikke, finner vi en bedre løsning.

Vurdering av monolitten: Vit hva du har med å gjøre

Når vi har bestemt oss for at mikrotjenester er det rette grepet, tar vi gjerne en full helsesjekk av systemet for å se hvordan alt henger sammen. Vi ser etter svake punkter, potensielle avhengighetsproblemer og hvor alle de kritiske dataene befinner seg.

Det er risikabelt å hoppe over dette trinnet. Hvis du ikke vet hva som er under panseret, kan du ved et uhell velte hele systemet som en dominobrikke. Ved å kartlegge hva som fungerer, hva som henger etter og hva som kan gå i stykker, lager vi en smart migreringsplan som tar for seg de mest kritiske områdene først, minimerer risikoen, unngår nedetid og gjør overgangen så smidig som mulig.

Velge riktig migreringsstrategi

Nå har du sikkert skjønt at jeg ikke er tilhenger av å rive ned en hel monolitt over natten. Det er for risikabelt, for forstyrrende og vanligvis ikke verdt stresset. I stedet velger jeg en trinnvis tilnærming som gir deg raske gevinster samtidig som driften holdes stabil.

En av mine favorittstrategier er Strangler Fig-mønsteret, som lar det gamle systemet og de nye mikrotjenestene sameksistere til du er klar for full overlevering.

Branch by Abstraction er praktisk når du må gjøre endringer inne i selve monolitten: Vi legger til et lag, flytter komponenter én etter én og pensjonerer det gamle uten å sprenge ting i luften.

Hvis pålitelighet er avgjørende, kan Parallel Run holde begge systemene i gang og sammenligne resultatene før du setter i gang for fullt.

Og hvis du ikke kan rote med monolitten, kan du bruke Change Data Capture til å spore databaseendringer for å holde mikrotjenestene synkronisert.

Det finnes ikke én beste metode - alt avhenger av oppsettet ditt. Teamet vårt velger også ut hvilke deler som skal migreres først, og fokuserer på de delene som vil ha størst innvirkning. Ta for eksempel et kassesystem for e-handel som håndterer tusenvis av daglige bestillinger, eller en dataanalysemotor som oppdateres kontinuerlig - disse bør migreres tidlig. På den måten ser du de virkelige fordelene raskt, og holder driften i gang.

Tilpasning av team og prosesser

Innføring av mikrotjenester betyr også at du må riste om på måten teamene dine jobber på. I stedet for ett stort team som håndterer en monolitt, foreslår jeg å gå over til mindre, tverrfunksjonelle team der hvert team eier en spesifikk mikrotjeneste. På denne måten blir beslutninger tatt raskere, og alle vet nøyaktig hva de er ansvarlige for.

I tillegg tar ekspertene våre i bruk DevOps-prinsipper og automatisering fra dag én, slik at utrullingen av nye funksjoner går smidig og problemfritt.

"Å gå fra monolitt til mikrotjenester er ikke bare en teknisk justering - det går ut over utviklingshastigheten, systemstabiliteten og muligheten til å skalere. Uten en gjennomtenkt plan kan kostnadene skyte i været, og integrasjoner kan bli en skikkelig hodepine. Hos Innowise gjør vi overgangen smidig og effektiv, slik at du kan holde deg smidig og fokusere på å utvikle virksomheten din."

Dmitry Nazarevich

CTO

Trinn 2: Identifisere og definere mikrotjenester

Når vi har kartlagt migreringsstrategien, er det neste store spørsmålet å finne ut hvordan vi kan dele opp monolitten i mikrotjenester uten å lage rot. Jeg har sett selskaper som enten prøver å frakoble alt på én gang eller bare velger ut tilfeldige moduler. Uansett fører det til bortkastet tid, ødelagte avhengigheter og måneder med frustrerende omarbeiding.

Min tommelfingerregel er å holde det forretningsfokusert. Det betyr at hver mikrotjeneste skal mappe til en reell forretningsfunksjon, ikke bare en tilfeldig kodebit.

Finne naturlige tjenestegrenser

En av de vanligste fallgruvene vi ser, er å dele opp en monolitt i tekniske lag. Det vil si å skille frontend, backend og database i ulike tjenester. Det er en sikker måte å ende opp med tett koblede, overdrevent pratsomme mikrotjenester som ikke skalerer godt. I stedet bruker vi domenedrevet design (DDD) og avgrensede kontekster for å bryte ting ned på en måte som faktisk gir mening.

Ta en e-handelsplattform. I stedet for å dele den opp i en generisk frontend-tjeneste og en backend-tjeneste, deler vi den opp i reelle forretningsfunksjoner som ordrebehandling, lagerstyring, betaling og brukeradministrasjon. Hver tjeneste eier sin egen logikk og sine egne data, og de er løst koblet sammen slik at de kan skaleres uavhengig av hverandre og utvikles uten at alt annet går i stykker.

Prioritering av tjenester for migrering

Jeg er ikke tilhenger av "big bang"-tilnærmingen. Å prøve å migrere alt på én gang er bare å be om problemer. I stedet fokuserer vi på hva vi skal bryte av først ved å se på:

Minimalt med avhengigheter. Mindre sammenfiltrede moduler er lettere å løsne uten å ødelegge alt.
Konsekvenser for virksomheten. Alt som er knyttet til inntekter eller kundeopplevelse, kommer vanligvis først i køen.
Hyppige endringer. Tjenester som oppdateres hele tiden, har størst nytte av mikrotjenestenes fleksibilitet.

Denne tilnærmingen hjelper oss med å oppnå raske gevinster og vise verdien tidlig, noe som gjør det lettere å få støtte fra teamet. I et HR-system kan for eksempel lønnsbehandling være en god mikrotjeneste, siden den håndterer komplekse, regionspesifikke beregninger. Men en statisk bedriftskatalog? Det er sannsynligvis ikke verdt de ekstra kostnadene, og kan forbli i monolitten en stund.

Unngå den distribuerte monolittfellen

Det siste vi ønsker, er å konvertere monolitt til mikrotjenester og likevel ende opp med en haug med tjenester som er for avhengige av hverandre. For å unngå dette må vi

Definer tydelige API-er (REST, gRPC eller hendelsesstyrt), slik at tjenestene kommuniserer problemfritt uten unødvendig frem og tilbake.
Sørg for at hver tjeneste eier sine egne data - ingen delte databaser som skaper flaskehalser.
Hold avhengigheter til et minimum, slik at tjenester kan oppdateres uten at alt annet går i stykker.

Ved å holde tjenestene løst koblet, kan vi oppgradere eller endre dem uten å bekymre oss for å ødelegge alt annet.

Få teamene med på laget

Som jeg sa tidligere, kommer mikrotjenester virkelig til sin rett når hvert team eier tjenesten sin fra start til slutt. Du får raskere tilbakemeldinger, mer ansvarlighet og mye mindre frem og tilbake mellom teamene. Hos Innowise hjelper vi bedrifter med å sette opp teamene sine slik at devs, ops, QA og alle andre kan jobbe sammen på en smidig måte.

Bryt ned monolitten i mikrotjenester, og kom deg gjennom trafikktoppene uten problemer.

Trinn 3: Håndtering av data i mikrotjenester

Etter at vi har delt opp monolitten i mikrotjenester, er det første spørsmålet vanligvis hva vi skal gjøre med dataene? I et monolittisk oppsett er alt knyttet til én stor database, som fungerer til den ikke gjør det lenger. I et mikrotjenesteoppsett blir den delte databasen raskt en flaskehals som bremser alt og gjør det umulig å skalere tjenestene uavhengig av hverandre.

Derfor er jeg tilhenger av en desentralisert datamodell, der hver mikrotjeneste eier sine egne data. Hvis det gjøres riktig, kan hver tjeneste vokse, tilpasse seg og skalere uten å stadig snuble over hverandre.

Dropp den monolittiske databasen

En massiv, alt-i-ett-database kan virke som den enkleste løsningen, men i et mikrotjenesteoppsett blir den fort en flaskehals. Hver tjeneste har ulike behov, og å stappe alt inn i én enkelt database skaper bare hindringer. Skalering blir vanskelig, avhengigheter hoper seg opp, og selv små endringer kan føre til problemer i hele systemet.

Derfor deler vi opp i mindre, tjenestespesifikke tjenester, slik at hver mikrotjeneste:

Kontrollerer sine egne data. Ingen flere konflikter eller utilsiktede endringer fra andre team.
Vekt på egen hånd. Tjenestene trenger ikke å slåss om databasens ressurser.
Kan endres fritt. Oppdatering av én tjeneste risikerer ikke å ødelegge hele systemet.

På denne måten blir alt mer fleksibelt, teamene slipper å tråkke hverandre på tærne, og man unngår flaskehalsen i databasen som bremser alle.

Migrering av data

Flytting av data ut av en monolitt er ikke bare å slå på bryteren. Det er risikabelt å migrere uten videre, så jeg foretrekker en inkrementell tilnærming, der man bryter det ned trinn for trinn.

Vanligvis betyr det å opprette nye tabeller eller databaser for hver mikrotjeneste og holde dem synkronisert med det gamle systemet ved hjelp av CDC (Change Data Capture) eller dobbel skriving. På den måten får hver tjeneste gradvis eierskap til sine egne data - ingen nedetid, ingen ubehagelige overraskelser.

Hold dataene konsistente

I en monolitt har du én stor, delt database og ACID-transaksjoner som sørger for at alt oppdateres (eller feiler) sammen. Men med mikrotjenester håndterer hver tjeneste sine egne data, slik at oppdateringer ikke skjer umiddelbart i hele systemet.

I stedet for direkte oppdateringer snakker tjenestene sammen gjennom asynkrone meldinger. Hvis en bestilling legges inn, sender bestillingstjenesten ut en hendelse, og lagertjenesten lytter for å justere lagerbeholdningen. Dette oppsettet sørger for at alt går som smurt, selv om en tjeneste midlertidig går ned.

Det betyr selvfølgelig at man må håndtere konsistens på en smart måte. Hos Innowise bruker vi idempotente operasjoner for å forhindre duplikater, mekanismer for nye forsøk for å håndtere problemer og dødbokstavkøer for å fange opp feil. På denne måten forblir dataene dine nøyaktige, selv når ting ikke går som planlagt.

Trinn 4: Implementering og integrering

Nå som vi har satt klare grenser for tjenesten og lagt en solid plan for datamigrering, er det på tide å brette opp ermene og omsette strategien til handling. La oss se nærmere på hvordan vi får det til.

Bygg skalerbare, robuste mikrotjenester

Utviklingsteamet vårt bygger mikrotjenester ved hjelp av moderne verktøy som Spring Boot og Node.js, og sørger for at de er bygget for å skalere og håndtere utfordringer i den virkelige verden. For å sørge for at alt går som det skal, bruker vi smarte designmønstre som strømbrytere for å håndtere trafikktopper og grasiøs degradering for å forhindre kaskadefeil. På den måten kan resten av systemet ditt fortsette å kjøre uten problemer, selv om én tjeneste får problemer.

Holder arven i live (inntil videre)

Slå av monolitten din over natten? Det kommer ikke til å skje. I stedet setter vi opp integrasjonslag ved hjelp av RESTful API-er og meldingsmeglere som RabbitMQ eller Apache Kafka for å holde de nye mikrotjenestene og de eksisterende systemene synkronisert. Disse fungerer som broer som gjør at alt kommuniserer problemfritt uten å bryte arbeidsflyten.

Og når det er fornuftig, tar vi også med API-gatewayer for å øke og sikre interaksjoner, noe som garanterer en smidig overgang uten nedetid.

Innføring av containerisering

Vi containeriserer mikrotjenestene dine med Docker, slik at de er raske, fleksible og enkle å administrere. Med Kubernetes som orkestreringsverktøy er det enkelt å skalere opp i travle perioder eller rulle ut oppdateringer på tvers av ulike miljøer. Dette oppsettet gjør alt konsistent, forutsigbart og kostnadseffektivt, slik at IT-operasjonene dine aldri føles som et sjansespill.

Automatisering med CI/CD-rørledninger

Teamet vårt setter opp CI/CD-rørledninger med verktøy som Jenkins, GitLab CI eller CircleCI for å håndtere testing, bygging og distribusjon automatisk. Ingen flere manuelle oppdateringer eller brannøvelser i siste liten. Feil blir fanget opp tidlig, utgivelser går raskere, og systemet forblir bunnsolid.

La oss bygge et feiltolerant økosystem av mikrotjenester for virksomheten din.

Trinn 5: Testing, distribusjon og overvåking

Uten de rette sikkerhetstiltakene kan selv det best utformede systemet støte på flaskehalser, uventede feil eller rett og slett krasje på det verste tidspunktet. Derfor har teamet vårt en tilnærming uten snarveier, der vi automatiserer alt og fanger opp problemer før de forårsaker reelle problemer.

Automatisert testing

Testing er ikke bare det siste trinnet, det er en del av hele prosessen. AQA-teamet vårt bruker automatiserte testpakker i flere lag for å fange opp feil tidlig, slik at ingenting går galt.

Enhetstesting. Hver mikrotjeneste får sin egen sjekk med JUnit, Mocha og PyTest. Hvis noe er galt, oppdager vi det med en gang.
Integrasjonstesting. API-er, avhengigheter og dataflyt må synkroniseres. Ekspertene våre bruker Postman, REST-assured og WireMock for å sørge for at de gjør det.
Kontrakttesting. Mikrotjenester må følge reglene. Med Pact holder vi dem i sjakk og forhindrer at forbindelsene mellom tjenestene brytes.
Ende-til-ende-testing. Vi kjører gjennom virkelige scenarier - fra brukergrensesnittet til backend - ved hjelp av Selenium, Cypress og Playwright. På denne måten fungerer hele systemet som forventet.
Belastnings- og stresstesting. Teamet vårt presser systemet til det ytterste med JMeter, Gatling og Locust for å se hvordan det holder stand under tung trafikk.

Risikofri utplassering

Ingen ønsker at en dårlig lansering skal ødelegge systemet, frustrere brukerne eller redusere inntektene. Derfor sørger teamet vårt for trygge, kontrollerte og tilbakestillingsklare utrullinger ved hjelp av kamptestede strategier.

Canary utgivelser. I stedet for å slå på bryteren for alle på en gang, begynner vi i det små og ruller ut oppdateringer til en liten prosentandel av brukerne først. Hvis alt går bra, fortsetter vi. Hvis noe er galt, fikser ekspertene våre det før noen andre legger merke til det.

La oss si at en detaljhandelsbedrift ønsker å lansere et poengbasert lojalitetsprogram, men at ordresystemet er for komplekst til at det kan endres på en trygg måte. En detaljhandelsbedrift ønsker å lansere et poengbasert lojalitetsprogram, men bestillingssystemet er for komplekst til at det er trygt å endre det. For å være på den sikre siden tester vi det først med en liten gruppe. Hvis alt går bra, ruller vi det ut bredere.

Blå/grønne utplasseringer. Teamet vårt kjører to live-miljøer samtidig:
- Blue (nåværende versjon): den stabile versjonen som er live;
- Grønn (oppdatert versjon): den nye versjonen, testet og klar til bruk.

Når vi er sikre på at den grønne versjonen er solid, bytter vi over trafikken umiddelbart. Hvis noe går galt, bytter vi tilbake til blått. Null nedetid, ingen stress.

En reiseplattform ønsker for eksempel å legge til sanntidspriser, men å rote med det gamle systemet kan ødelegge bookingen. I stedet for å gå all-in, går teamet vårt blågrønt ut og sender en liten gruppe brukere til det nye oppsettet først. Hvis alt går bra, bytter vi alle over. Hvis det går galt, ruller vi tilbake umiddelbart.

Funksjonsflagg og A/B-testing. Noen ganger er det ikke riktig å rulle ut til 100% brukere. Med funksjonsflagg kan vi aktivere eller deaktivere funksjoner dynamisk, slik at vi kan teste i produksjon uten å påvirke alle. Vi bruker også A/B-testing for å sammenligne flere funksjonsversjoner under reelle forhold før vi lanserer en fullversjon.

Se for deg et e-handelsselskap som lanserer en AI-drevet anbefalingsmotor. I stedet for å slå på bryteren for alle, bruker vi Feature Flags til å aktivere den for tilbakevendende kunder først. Hvis engasjementet og salget øker, utvider vi, og hvis ikke slår vi den av umiddelbart.

Samtidig kjører teamet vårt A/B-tester, sammenligner det gamle systemet med det nye og sporer nøkkeltall som handlekurvverdi og konverteringsfrekvens. Disse dataene hjelper oss med å finjustere AI-en før en fullskala lansering.

Proaktiv overvåking og logging i sanntid

Mikrotjenester produserer tonnevis av data, så det er viktig å holde øye med systemtilstanden i sanntid. Teamet vårt setter opp overvåking i flere lag med verktøy som Prometheus, Grafana og New Relic for å spore hastighet, minnebruk og feil. På denne måten kan vi oppdage problemer før de blir en hodepine. Ved hjelp av ELK Stack, Fluentd og andre samler vi også alle loggene (i bunn og grunn det digitale sporet av appene dine) på ett sted, slik at ingenting går oss hus forbi. Og hvis noe går galt, får teknikerne våre automatiske varsler så raskt som mulig.

Sikkerhetskopiering og gjenoppretting av data

La oss være ærlige: Ingen systemer er 100% feilsikre. Maskinvare dør, programvare krasjer og cybertrusler utvikler seg hele tiden. Derfor er databeskyttelse et must. Derfor setter teamet vårt opp automatiserte strategier for sikkerhetskopiering, slik at kritiske data forblir trygge og enkle å gjenopprette.

Automatiske øyeblikksbilder. Vi bruker AWS RDS, Google Cloud SQL og Azure Backup til å ta kontinuerlige øyeblikksbilder av databasen din. Hvis noe går i stykker, kan du umiddelbart rulle tilbake til en stabil versjon med minimal nedetid.
Geo-redundant lagring. Én sikkerhetskopi er ikke nok. Ekspertene våre sprer kopier på ulike datasentre, så selv om ett krasjer eller blir utsatt for et dataangrep, er dataene dine fortsatt trygge og tilgjengelige.
Inkrementell sikkerhetskopiering og punkt-til-tid-gjenoppretting. I stedet for å ta én stor sikkerhetskopi som tar evigheter, bruker vi smarte sikkerhetskopier som bare fanger opp de siste endringene. Og med point-in-time-gjenoppretting kan vi spole tilbake databasen til et hvilket som helst tidspunkt før et problem oppstod, slik at du unngår utilsiktet sletting eller datakorrupsjon.
Gjenoppretting etter en katastrofe. En god plan for katastrofegjenoppretting hindrer små problemer i å utvikle seg til fullstendige kriser. Hvis noe svikter, bytter automatiske failover-systemer til en sikkerhetskopi, slik at virksomheten kan fortsette å fungere uten problemer.

Trinn 6: Iterativ optimalisering og skalering

Migrering fra monolitt til mikrotjenester er ikke bare en engangsoppgradering, de trenger kontinuerlig vedlikehold for å yte sitt beste. Vi er her i det lange løp og garanterer at oppsettet ditt forblir fleksibelt, skalerer problemfritt og håndterer selv de tøffeste belastningene.

Innstilling av ytelse

Teamet vårt holder et øye med hver mikrotjeneste, justerer koden, optimaliserer databasespørringer og utjevner hvordan tjenestene kommuniserer slik at alt går raskt.

Smart skalering

Ved å analysere trafikk- og belastningsmønstre i sanntid justerer spesialistene våre ressursene dynamisk, og sørger for at tjenester med høy etterspørsel får det løftet de trenger uten å bruke for mye penger.

Kontinuerlig forbedring

Systemet ditt må vokse i takt med virksomheten din. Teamet vårt sporer ytelsen i sanntid, lytter til tilbakemeldinger og gjør smarte justeringer for å holde arkitekturen sikker, effektiv og skuddsikker.

Krystallklar dokumentasjon

Etter hvert som vi forbedrer og utvider mikrotjenestene dine, sørger vi for at alt er veldokumentert. På den måten blir fremtidige oppdateringer og migreringer problemfrie, og teamet ditt vet nøyaktig hva som skjer.

Fremtidssikre bedriftsappen din med en smart migrering av mikrotjenester.

Moderniser bedriftsapplikasjonene dine med Innowises løsninger

Migrering fra monolitt til mikrotjenester er et strategisk grep for å oppnå bedre smidighet, skalerbarhet og robusthet. Men hvis du går i gang uten en fornuftig plan, risikerer du nedetid, ødelagte arbeidsflyter og skyhøye kostnader. En smart migrering krever at du har styr på tjenestegrensene, håndterer data på riktig måte og følger beste praksis for sikkerhet og distribusjon.

Hos Innowise hjelper vi bedrifter med å gjennomføre dette skiftet på en trygg måte. Med over 18 år i modernisering av programvare og utvikling, håndterer vi alt fra å vurdere oppsettet ditt og utforme en solid migreringsstrategi til å bygge skalerbare mikrotjenester og forbedre ytelsen. Våre løsningsarkitekter, DevOps-ingeniører og utviklere bruker velprøvde metoder for å redusere risiko og maksimere effekten, slik at vi kan garantere at appens systemer skalerer og utvikler seg i takt med virksomheten.

Del:

Michael Labutin

Leder for ERP-løsninger

Michael kan ERP ut og inn - fra å velge riktig system til å finne ut hvordan det fungerer sammen med resten av den tekniske stakken. Han er den folk henvender seg til når de trenger ERP for å løse reelle driftsproblemer, ikke for å skape nye.

Innholdsfortegnelse

Kontakt oss

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

Navn

Selskap

E-post

Telefon

Melding

Send oss en talemelding

Legg ved dokumenter

Last opp fil

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

Ved å klikke på Send, samtykker du til at Innowise behandler dine personopplysninger i henhold til våre Retningslinjer for personvern for å gi deg relevant informasjon. Ved å oppgi telefonnummeret ditt samtykker du i at vi kan kontakte deg via taleanrop, SMS og meldingsapper. Priser for samtaler, meldinger og data kan gjelde.