Från “proof of concept” till förvaltning i verkligheten

Niclas Andersson

Niclas Andersson

Niclas Andersson är affärsutvecklare på Multisoft med lång erfarenhet av att driva digitalisering i komplexa organisationer. Han hjälper företag att identifiera affärsbehov och omsätta dem till systemlösningar som effektiviserar verksamhetsflöden, skapar struktur och stärker kundrelationer. Med fokus på affärsnytta, användarnära lösningar och förändringsledning som framgångsfaktor, är Niclas en strategisk partner i att realisera värdet av Multisofts plattform, både tekniskt och organisatoriskt.

2026-03-09
8 min

När stora organisationer vill testa automation börjar de ofta i ett verktyg som råkar ligga nära till hands. Ibland är det Power Apps, ibland något annat. Poängen är sällan produkten i sig, poängen är att sänka tröskeln för att prova: Få ut något snabbt, se om det fungerar i verkligheten och lära sig vad som faktiskt behöver automatiseras.

90,4 % av företagen som använder low-code rapporterade ökad utvecklarproduktivitet. Många företag vill ge sina utvecklare möjlighet att skapa lösningar snabbt för att kunna digitalisera och automatisera. Men ibland fastnar lösningar i ett PoC/MVP-stadie av olika anledningar.

Det är bland annat då du frågar dig om du borde valt en low-code-plattform med förvaltning. För att få till ett bra införandeprojekt bör du också fundera på vilka krav som är rätt och vad ni bör digitalisera och automatisera.

Power Apps som exempel

Microsoft Power Apps är ett bra exempel på just en sådan “testbädd”. Microsoft beskriver Power Apps som ett sätt att snabbt bygga verksamhetsappar som kopplas till data och tjänster, vilket gör att många kan gå från idé till fungerande flöde snabbt. Low-code är just snabbt att få upp på banan och vi på Multisoft brukar säga att vi är 5-20 gånger snabbare.

Och när man står mitt i en vardag med flaskhalsar, manuella moment och “vi borde verkligen automatisera det här”-listor är det ofta precis den typen av fart man behöver.

Men i stora bolag händer något förutsägbart när testet faktiskt fungerar: PoC:en får spridning. Fler team vill automatisera och undantag och avvikelser blir fler. Data och integrationer växer. Och plötsligt är det inte längre en PoC, utan ett systemstöd som människor lutar sig mot för att få jobbet gjort.

Då blir frågan inte längre om ni kan automatisera, utan om det ni har byggt går att förvalta utan att bli en bromskloss.

Ving som exempel

En Commercial Analytics & Automation Specialist på resebolaget Ving (Nordic Leisure Travel Group) känner väl igen utvecklingen som många organisationer går igenom just nu. Verktyg inom low-code och no-code gör att fler än tidigare kan bygga egna lösningar i verksamheten. Tröskeln för att skapa något fungerande har blivit betydligt lägre.

“I dag kan i princip vem som helst bygga nästan vad som helst i ett low-code-verktyg, så länge intresset finns.”

Det innebär att fler idéer kan testas snabbare och att initiativ kan uppstå direkt i verksamheten. Men enligt honom ligger utmaningen inte längre i att skapa själva applikationen.

“Utmaningen ligger i skalbarheten, driftsäkerheten, säkerheten, kostnaderna och vidareutvecklingen. Allt det som blir svårt när förvaltning saknas.”

Ving använder idag en Softadmin-plattform som har skräddarsytts efter deras behov. Plattformen har adderat 33 nya systemförmågor, men det hindrar inte fler experiment och tester, både i och utanför plattformen.

När piloten börjar bli affärskritisk

Det finns en tydlig brytpunkt där ni märker att lösningen börjar bete sig som ett ”riktigt system”. Ofta känns det först som små irritationsmoment, men de brukar hänga ihop med samma sak: Ni har gått från experiment till drift, utan att livscykeln hunnit i kapp.

Här är några typiska signaler:

  • Fler användare än planerat och plötsligt många som “måste” kunna jobba, även om något strular.
  • Ändringar tar längre tid än de borde, eftersom varje justering påverkar fler delar.
  • Personberoenden smyger sig in: ”Fråga X, hen byggde den där”.
  • Integrationer och data blir det svåra, inte själva gränssnittet.
  • Många liknande appar börjar dyka upp, med snarlik logik men olika ägare.

Det här är inte ett misslyckande. Det är snarare ett kvitto på att ni hittat en eller flera processer som är viktig nog att ta sig ann, men som nu behöver behandlas som ett system, inte ett experiment.

Den dolda kostnaden: automatiseringsskuld och personberoenden

En PoC byggs ofta med en prioritering: Snabbt värde. Men när den växer kan det som var “rimliga genvägar” bli en form av skuld. Det märks när ni behöver ändra något och upptäcker att allt sitter ihop på oväntade sätt.

Forrester har liknat teknisk skuld vid “death by a thousand cuts”, inte en stor katastrof, utan många små beslut som var för sig känns defensiva men som sammantaget blir dyrt och riskfyllt.

Den mekaniken känns igen även i low-code-miljöer när lösningar blir verksamhetskritiska: Varje liten specialregel, varje snabb koppling, varje “vi dokumenterar sen” blir ränta ni betalar i förändringstakt och stabilitet.

Personberoendet är ofta nästa smäll. I början är det normalt att en person har helhetsbilden. I skarpt läge är det en sårbarhet. Om ni märker att ni undviker förändringar för att det “bara är X som vågar röra den där” är ni redan förbi PoC-stadiet.

När systemkartan tar över: data, integrationer och spårbarhet

I stora organisationer är det sällan “appen” som är den svåra delen. Utmaningen är att få den att fungera i systemlandskapet.

Det brukar bli tydligt när lösningen behöver klara:

  • Hämta och skriva data i flera system.
  • Hantera masterdata på ett konsekvent sätt.
  • Ge spårbarhet (vem gjorde vad, när och varför).
  • Klara behörigheter på flera nivåer.

Här är ni i praktiken inne i ett klassiskt systemproblem. Det är ofta i den här fasen man märker att man inte längre bygger ett gränssnitt, utan ett regelverk, ett integrationsmönster och ett driftbart flöde.

Och samtidigt kan “app sprawl” smyga in: flera team bygger varianter av samma sak. Det kan kännas innovativt, men utan struktur blir det svårt att veta vad som är standard, vad som är lokalt, och vilka lösningar som faktiskt är säkra att skala.

Eller ”shadow automation”: När medarbetare eller team bygger egna automationsflöden utan gemensamma standarder får du lätt en “skugga” av automation som ingen riktigt äger.

Från Excel till Power Apps till systemstöd

Vissa sitter i Excel, vissa har tagit steget till exempelvis Power Apps och vissa vill ta nästa steg. Många organisationer mår bra av att se det här som en mognadsresa:

  1. Först: Identifiera och bevisa värdet.
  2. Sedan: Standardisera och skapa gemensamma byggblock.
  3. Till sist: Industrialisera det som blivit viktigt.

 

Det är här “nästa steg” kommer in. Inte som en jämförelse som säger att Power Apps är fel, utan som en logisk fortsättning: När en lösning ska leva i flera år, tåla förändring, klara fler integrationer och ha en tydlig förvaltning, då behöver ni ofta en plattform, arbetssätt och leverantör som är byggt för just det.

I Multisofts värld är det ofta då Softadmin® blir relevant: När ni vill behålla tempot och smidigheten, men vill flytta från “vi har en fungerande app” till “vi har ett systemstöd som går att äga, drifta och utveckla långsiktigt”. En low-code-plattform som du slipper bygga och ta hand om själv.

En enkel tumregel: När är det dags att ta nästa steg?

Om du vill ha ett pragmatiskt beslutstöd (utan att göra det till en stor utredning), kan du utgå från tre frågor:

  • Hur dyrt blir ett driftstopp? (och hur snabbt måste ni kunna återställa?)
  • Hur ofta måste ni ändra processen? (och hur mycket test/release kräver det?)
  • Hur många beroenden har ni? (integrationer, data, behörigheter och rapportering)

Om svaret är “det här är viktigt, ofta och ihopkopplat” så är ni sällan kvar i PoC-land längre.

All ära till Microsoft, men…

Många ser Multisoft och Softadmin® som ett naturligt nästa steg när en lösning behöver bli mer långsiktigt förvaltningsbar. Power Apps fungerar ofta bra för snabba piloter, avdelningsverktyg och lösningar som ligger nära Microsoft 365, men när ni börjar skala upp kan licenser och premiumfunktioner snabbt driva kostnad. Då vill många hitta ett alternativ som fortsatt ligger nära Microsoftvärlden (Multisoft är partner till Microsoft), men där kostnadsbilden inte i första hand är kopplad till licenser per användare eller app.

Power Apps ofta som starkast i Microsofts eget ekosystem. När ni behöver koppla ihop flera system utanför den sfären, eller när ni ska hålla ihop många appar, versioner och efterlevnadskrav, kan styrning och överblick bli en utmaning.

Det blir extra tydligt när arbetsflödena växer i komplexitet och börjar involvera människor, flera system och processer som löper över längre tid, då räcker inte alltid ett flödesbaserat upplägg hela vägen.

I den här fasen blir integrationer och skalbarhet ofta avgörande. Att kunna koppla ihop både äldre system och moderna verktyg som affärsprocesserna är beroende av blir centralt, och när verksamheten växer behöver ni en plattform som hanterar stora datamängder, hög belastning och långvariga processer på ett stabilt sätt.

Lika viktigt är att efterlevnad och styrning sitter från början, med rollbaserade behörigheter som gör det tydligt vem som får se vad och göra vad, och som går att förvalta över tid.

Kontaktuppgifter

Vill du veta mer om våra lösningar? Hör av dig till oss!

Kontakta oss

Relaterade inlägg

Läs fler blogginlägg och guider i vår kunskapsbank.

Man och leende kvinna pratar vid dator
Blogg
2 april 2026

Workflow automation: vad det är, exempel och fördelar

Workflow automation är ett sätt att automatisera ett arbetsflöde från början till slut,...
Två kollegor sitter vid en dator och tittar på varandra
Blogg
10 mars 2026

Vad är ett automatiseringsverktyg och hur väljer du rätt?

Ett automatiseringsverktyg är en mjukvara som tar över repetitiva uppgifter, kopplar iho...
Kvinna sitter och ler under möte
Blogg
17 februari 2026

Så tar du Enterprise AI från pilot till drift i dina processer

AI beskrivs ofta som ett teknikval, modell, plattform eller en “smart” funktion. Men i s...