90,4 % av selskapene som bruker lavkode rapporterte økt utviklerproduktivitet. Mange selskaper ønsker å gi utviklerne sine muligheten til å lage løsninger raskt for å digitalisere og automatisere. Men noen ganger blir løsninger sittende fast i en PoC/MVP-fase av ulike årsaker.
Det er da du blant annet spør deg selv om du burde ha valgt en lavkodeplattform med administrasjon. For å oppnå et godt implementeringsprosjekt bør du også vurdere hvilke krav som er riktige og hva du bør digitalisere og automatisere.
Power Apps som et eksempel
Microsoft Power Apps er et godt eksempel på nettopp en slik "testplass". Microsoft beskriver Power Apps som en måte å raskt bygge forretningsapper som er koblet til data og tjenester, noe som gjør at mange kan gå fra idé til arbeidsflyt raskt. Lavkode er rett og slett raskt å komme i gang med, og vi i Multisoft sier vanligvis at vi er 5–20 ganger raskere.
Og når du er midt i en daglig rutine med flaskehalser, manuelle oppgaver og "vi burde virkelig automatisere dette"-lister, er det ofte akkurat den typen hastighet du trenger.
Men i store selskaper skjer det noe forutsigbart når testen faktisk fungerer: PoC-en sprer seg. Flere team ønsker å automatisere, og unntak og avvik øker. Data og integrasjoner vokser. Og plutselig er det ikke lenger en PoC, men en systemstøtte som folk lener seg på for å få jobben gjort.
Da er ikke lenger spørsmålet om du kan automatisere, men om det du har bygget kan administreres uten å bli en belastning.
Ving som eksempel
En Commercial Analytics & Automation Specialist hos reiseselskapet Ving (Nordic Leisure Travel Group) kjenner godt igjen utviklingen som mange organisasjoner går gjennom akkurat nå. Verktøy innen low-code og no-code gjør at flere enn før kan bygge egne løsninger i virksomheten. Terskelen for å skape noe som fungerer, har blitt betydelig lavere.
"I dag kan i prinsippet hvem som helst bygge nesten hva som helst i et low-code-verktøy, så lenge interessen er der."
Det innebærer at flere ideer kan testes raskere, og at initiativer kan oppstå direkte i virksomheten. Men ifølge ham ligger utfordringen ikke lenger i å lage selve applikasjonen.
"Utfordringen ligger i skalerbarheten, driftssikkerheten, sikkerheten, kostnadene og videreutviklingen. Alt det som blir vanskelig når forvaltning mangler."
Ving bruker i dag en Softadmin-plattform som er skreddersydd etter deres behov. Plattformen har tilført 33 nye systemegenskaper, men det hindrer ikke flere eksperimenter og tester, både i og utenfor plattformen.
Når pilotprosjektet begynner å bli forretningskritisk
Det er et tydelig vippepunkt der du merker at løsningen begynner å oppføre seg som et "ekte system". Ofte føles disse som små irritasjoner i starten, men de har vanligvis det samme til felles: Du har gått fra eksperiment til drift, uten at livssyklusen har tatt igjen det tapte.
Her er noen typiske signaler:
- Flere brukere enn planlagt og plutselig mange som "må" kunne jobbe, selv om noe går galt.
- Endringer tar lengre tid enn de burde , fordi hver justering påvirker flere deler.
- Personlige avhengigheter sniker seg inn: "Spør X, det var han som bygde den."
- Integrasjoner og data blir den vanskelige delen , ikke selve grensesnittet.
- Mange lignende apper begynner å dukke opp, med lignende logikk, men forskjellige eiere.
Dette er ikke en fiasko. Det er snarere en erkjennelse av at du har funnet én eller flere prosesser som er viktige nok til å adresseres, men som nå må behandles som et system, ikke et eksperiment.
Den skjulte kostnaden: automatiseringsgjeld og personlige avhengigheter
En PoC bygges ofte med én prioritet: Rask verdi. Men etter hvert som den vokser, kan det som var "rimelige snarveier" bli en form for gjeld. Det merkes når du trenger å endre noe og oppdager at alt passer sammen på uventede måter.
Forrester har sammenlignet teknisk gjeld med "død med tusen kutt", ikke én stor katastrofe, men mange små avgjørelser som individuelt føles defensive, men som samlet sett blir dyre og risikable.
Denne mekanikken gjenkjennes også i lavkodemiljøer når løsninger blir forretningskritiske: Hver lille spesialregel, hver raske tilkobling, hvert "vi dokumenterer det senere" blir renter du betaler i endringstakt og stabilitet.
Personavhengighet er ofte det neste slaget. I begynnelsen er det normalt at en person har det store bildet. I en kritisk situasjon er det en sårbarhet. Hvis du merker at du unngår endringer fordi "bare X tør å røre ved den", er du allerede forbi PoC-stadiet.
Når systemkartet tar over: data, integrasjoner og sporbarhet
I store organisasjoner er det sjelden "appen" som er den vanskelige delen. Utfordringen er å få den til å fungere i systemlandskapet.
Det blir vanligvis klart når løsningen må fullføres:
- Hent og skriv data på tvers av flere systemer.
- Administrer masterdata på en konsekvent måte.
- Sørg for sporbarhet (hvem gjorde hva, når og hvorfor).
- Fjern tillatelser på flere nivåer.
Her er du i praksis i et klassisk systemproblem. Det er ofte i denne fasen at du legger merke til at du ikke lenger bygger et grensesnitt, men et rammeverk, et integrasjonsmønster og en opererbar flyt.
Og samtidig kan "appspradling" snike seg inn: flere team bygger varianter av det samme. Det kan føles innovativt, men uten struktur blir det vanskelig å vite hva som er standard, hva som er lokalt, og hvilke løsninger som faktisk er trygge å skalere.
Eller "skyggeautomatisering": Når ansatte eller team bygger sine egne automatiseringsflyter uten felles standarder, ender man lett opp med en "skygge" av automatisering som ingen egentlig eier.
Fra Excel til Power Apps til systemstøtte
Noen bruker Excel, noen har tatt steget til for eksempel Power Apps, og noen ønsker å ta det neste steget. Mange organisasjoner føler seg trygge på å se dette som en modningsreise:
- Først: Identifiser og bevis verdien.
- Deretter: Standardiser og lag felles byggeklosser.
- Til slutt: Industrialiser det som har blitt viktig.
Det er her "neste steg" kommer inn. Ikke som en sammenligning som sier at Power Apps er feil, men som en logisk fortsettelse: Når en løsning skal leve i flere år, tåle endringer, håndtere flere integrasjoner og ha tydelig styring, da trenger man ofte en plattform, arbeidsmetode og leverandør som er bygget for nettopp det.
I Multisofts verden er det ofte dette Softadmin® blir relevant: Når du ønsker å opprettholde tempo og smidighet, men ønsker å gå fra "vi har en fungerende app" til "vi har en systemstøtte som kan eies, driftes og utvikles langsiktig". En lavkodeplattform som du ikke trenger å bygge og vedlikeholde selv.
En enkel tommelfingerregel: Når er det på tide å ta neste steg?
Hvis du ønsker pragmatisk beslutningsstøtte (uten å gjøre det til en større undersøkelse), kan du starte med tre spørsmål:
- Hvor dyrt er nedetid? (og hvor raskt trenger du å kunne gjenopprette?)
- Hvor ofte må du endre prosessen? (og hvor mye testing/utgivelse krever det?)
- Hvor mange avhengigheter har du? (integrasjoner, data, tillatelser og rapportering)
Hvis svaret er "dette er viktig, hyppig og sammenhengende", er du sjelden igjen i PoC-land lenger.
All ære til Microsoft, men …
Mange ser Multisoft og Softadmin® som et naturlig neste steg når en løsning må bli mer langsiktig håndterbar. Power Apps fungerer ofte bra for raske pilotprosjekter, avdelingsverktøy og løsninger som er tett på Microsoft 365, men når man begynner å skalere opp, kan lisenser og premiumfunksjoner raskt drive opp kostnadene. Mange ønsker da å finne et alternativ som fortsatt er tett på Microsoft-verdenen (Multisoft er en partner av Microsoft), men hvor kostnadsbildet ikke primært er knyttet til lisenser per bruker eller app.
Power Apps er ofte den sterkeste plattformen i Microsofts eget økosystem. Når du trenger å koble sammen flere systemer utenfor dette området, eller når du trenger å holde flere apper, versjoner og samsvarskrav samlet, kan styring og tilsyn bli en utfordring.
Det blir spesielt tydelig når arbeidsflyter vokser i kompleksitet og begynner å involvere mennesker, flere systemer og prosesser som går over en lengre periode, at en flytbasert tilnærming ikke alltid er nok hele veien.
I denne fasen blir integrasjoner og skalerbarhet ofte avgjørende. Å kunne koble sammen både eldre systemer og moderne verktøy som forretningsprosesser er avhengige av blir sentralt, og etter hvert som virksomheten din vokser, trenger du en plattform som kan håndtere store mengder data, høy belastning og langvarige prosesser på en stabil måte.
Like viktig er det at samsvar og styring er på plass fra starten av, med rollebaserte tillatelser som gjør det klart hvem som får se hva og gjøre hva, og at det kan administreres over tid.
