ProduktutviklingHafsteinn Runarsson · AI Konsulent08 Oct 2026 · 13 min
Forretningsanalyse for AI og programvare: Fra behov til riktig løsning
Forretningsanalyse er arbeidet med å forstå et forretningsbehov, hvem det gjelder, hvordan arbeidet fungerer i dag, og hvilken endring som faktisk vil skape verdi. I AI- og programvareprosjekter brukes analysen til å gjøre et uklart ønske om til et tydelig beslutningsgrunnlag, prioriterte krav og målbare kriterier for en løsning.
Den korte versjonen er enkel: Ikke start med funksjoner eller teknologi. Start med problemet, beslutningen og menneskene som berøres. Da blir det lettere å velge riktig løsning — også når riktig løsning er en prosessendring, en enkel automatisering eller å la være å bygge noe nytt.
Hva er forretningsanalyse?
Forretningsanalyse skaper en dokumentert forbindelse mellom et behov og en mulig endring. Analysen undersøker dagens situasjon, ønsket situasjon, interessenter, begrensninger, risiko og alternative løsninger.
IIBA beskriver forretningsanalyse som å forstå virksomheten, produktet og brukerne, og omsette denne kunnskapen til behov og løsninger. I praksis betyr det å stille presise spørsmål før teamet binder seg til en bestemt løsning.
En god analyse gir vanligvis svar på disse spørsmålene:
- Hvilket problem eller hvilken mulighet arbeider vi med?
- Hvem opplever problemet, og hvem påvirkes av en endring?
- Hvordan utføres arbeidet i dag?
- Hvilket resultat ønsker virksomheten og brukerne?
- Hvilke løsningsalternativer finnes?
- Hvilke krav, regler og begrensninger må løsningen oppfylle?
- Hvordan skal vi vite om endringen virker?
Resultatet er ikke nødvendigvis ett langt dokument. Det kan være en kombinasjon av prosesskart, problemdefinisjon, beslutningslogg, prioriterte krav, brukerhistorier, prototyper og akseptansekriterier.
Forretningsanalyse er ikke det samme som dataanalyse
Forretningsanalyse og dataanalyse overlapper, men de besvarer ulike hovedspørsmål.
- Forretningsanalyse: Hvilket behov skal løses, hvorfor er det viktig, og hvilken endring bør vi velge?
- Dataanalyse: Hva viser dataene om hendelser, mønstre eller mulige utfall?
- Business intelligence: Hvordan kan virksomheten følge utviklingen gjennom rapporter, nøkkeltall og dashbord?
- Kravarbeid: Hva må en valgt løsning gjøre, og hvilke betingelser må den oppfylle?
Data kan være en viktig del av en forretningsanalyse, men tall alene forklarer ikke alltid årsaken til et problem. Intervjuer, observasjon, prosesskartlegging og gjennomgang av regler kan være like viktige.
Dette skillet er særlig nyttig i AI-prosjekter. En modell kan være teknisk imponerende uten å løse et prioritert behov. Forretningsanalysen avgjør først hvilken beslutning eller arbeidsflyt modellen skal støtte.
Hvorfor forretningsanalyse er viktig i AI- og programvareprosjekter
Forretningsanalyse reduserer avstanden mellom det virksomheten ber om, det brukerne trenger, og det utviklingsteamet bygger. Den gjør antakelser synlige før de blir kostbare avhengigheter.
Analysen bidrar særlig med å:
- avgrense problemet før løsningsvalget låses
- samle ulike interessenter rundt samme mål
- skille nødvendige krav fra ønskeliste
- oppdage regler, unntak og avhengigheter i arbeidsflyten
- sammenligne flere løsningsalternativer
- definere hva som skal testes og godkjennes
- knytte leveransen til et resultat som kan følges opp
Uten dette arbeidet kan et team levere funksjoner som virker som spesifisert, men som ikke forbedrer den faktiske arbeidssituasjonen. God analyse beskytter derfor ikke bare budsjett og fremdrift. Den beskytter også brukeropplevelsen og kvaliteten på beslutningen.
En praktisk prosess i sju steg
En nyttig forretningsanalyse går fra behov til testbar beslutning. Prosessen kan tilpasses prosjektets størrelse, men rekkefølgen under fungerer godt for både AI og tradisjonell programvare.
1. Definer behovet og beslutningen
Start med å formulere problemet uten å bake inn en løsning. «Vi trenger en chatbot» er en løsningsidé. «Kunder finner ikke svar på gjentakende spørsmål, og kundeservice bruker mye tid på å lete i flere kunnskapskilder» beskriver et behov som kan undersøkes.
Avklar også hvilken beslutning analysen skal støtte. Skal virksomheten velge om den bør investere? Prioritere mellom alternativer? Avgrense en første leveranse? Forbedre en eksisterende løsning?
En presis problemdefinisjon bør inneholde:
- berørt målgruppe eller arbeidsprosess
- observert situasjon
- ønsket endring
- kjent avgrensning
- åpne antakelser som må undersøkes
2. Kartlegg interessenter og brukere
Identifiser dem som utfører arbeidet, eier resultatet, leverer data, forvalter systemene eller påvirkes av endringen. Ikke begrens kartleggingen til bestilleren.
Snakk med faktiske brukere tidlig. En leder kan beskrive målet, mens brukerne kjenner unntakene, omveiene og informasjonsbehovene i hverdagen. Teknologi-, sikkerhets- og driftsmiljøer kan samtidig avdekke begrensninger som påvirker løsningsvalget.
3. Forstå dagens prosess
Dokumenter hvordan arbeidet faktisk skjer i dag — ikke bare hvordan rutinen sier at det skal skje. Et enkelt prosesskart kan vise trinn, roller, systemer, ventetid, overleveringer og beslutningspunkter.
IIBAs beskrivelse av prosessanalyse fremhever vurdering av effektivitet, måloppnåelse og muligheter for endring. For et digitalt initiativ betyr det at både flaskehalser og variasjoner må bli synlige før teamet designer en ny flyt.
Samle bevis gjennom flere kilder:
- intervjuer og observasjon
- eksisterende data og rapporter
- kundehendelser og tilbakemeldinger
- skjemaer, rutiner og regelverk
- integrasjoner og systembegrensninger
4. Beskriv ønsket resultat
Definer hva som skal være annerledes hvis initiativet lykkes. Målet bør handle om resultatet, ikke bare leveransen.
«Ny søkefunksjon lansert» beskriver en leveranse. «Brukere finner riktig, godkjent informasjon i arbeidsflyten» beskriver et ønsket resultat. Teamet kan deretter velge relevante indikatorer, datakilder og kontrollpunkter.
Skill mellom:
- forretningsmål: effekten virksomheten ønsker
- brukerbehov: oppgaven eller beslutningen brukeren må få støtte til
- løsningsmål: hva løsningen må muliggjøre
- målekriterier: hvordan resultat og kvalitet skal vurderes
5. Vurder flere løsningsalternativer
Sammenlign alternativer før du detaljspesifiserer ett av dem. Ta med manuelle prosessendringer, forbedring av eksisterende verktøy, kjøp, integrasjon og nyutvikling. «Ikke gjør noe nå» er også et reelt sammenligningsgrunnlag.
Vurder hvert alternativ ut fra:
- forventet nytte
- kostnad og kompleksitet
- gjennomføringstid
- risiko og avhengigheter
- brukerbelastning
- data- og integrasjonsbehov
- forvaltning etter lansering
Poenget er ikke å produsere en perfekt beregning. Poenget er å gjøre premissene tydelige nok til at beslutningstakere kan velge bevisst.
6. Prioriter krav og akseptansekriterier
Krav skal forklare hva som må være sant for at løsningen støtter behovet. IIBA fremhever at krav må organiseres, modelleres, verifiseres, valideres og knyttes til løsningsalternativer.
Prioriter krav etter verdi, risiko og avhengighet. Skill mellom:
- funksjonelle krav
- kvalitetskrav som sikkerhet, ytelse og tilgjengelighet
- forretningsregler
- datakrav
- integrasjonskrav
- akseptansekriterier
Spor hvert viktig krav tilbake til et behov. Hvis ingen kan forklare hvilket behov et krav støtter, bør det utfordres.
7. Valider tidlig og følg opp etter lansering
Test forståelsen før full utvikling. Bruk skisser, prototyper, prøveflyter eller små pilotløp til å avdekke misforståelser. Valider både med brukerne og dem som skal drifte eller godkjenne løsningen.
Etter lansering fortsetter analysen. Sammenlign faktisk bruk og resultat med kriteriene som ble definert tidligere. Nye funn kan føre til justering av prosess, opplæring, datagrunnlag eller selve løsningen.
Slik endres analysen når løsningen bruker AI
AI gjør ikke forretningsanalyse mindre viktig. Den legger til spørsmål som må besvares før en modell kan inngå trygt i en arbeidsflyt.
Avklar hvilken oppgave AI skal støtte
Beskriv input, ønsket output og beslutningen rundt outputen. Skal løsningen foreslå, oppsummere, klassifisere, finne informasjon eller utføre en handling? Angi også hva et menneske skal kontrollere.
Undersøk data og kunnskapsgrunnlag
Kartlegg hvor informasjonen kommer fra, hvem som eier den, hvor oppdatert den er, og hvilke tilgangsregler som gjelder. Dårlig eller ufullstendig grunnlag kan ikke repareres med en mer avansert modell.
Definer kvalitet med konkrete eksempler
«Svar godt» er ikke et testbart krav. Lag eksempler på akseptable og uakseptable svar. Vurder faglig korrekthet, relevans, kildebruk, tone, fullstendighet og riktig håndtering av usikkerhet.
Planlegg for feil og menneskelig kontroll
Beskriv hva som skjer når løsningen er usikker, mangler informasjon eller foreslår noe feil. Avklar når brukeren må godkjenne, når saken skal eskaleres, og hvilke handlinger systemet aldri skal utføre automatisk.
Ta med forvaltning fra starten
En AI-løsning trenger eierskap etter lansering. Avklar hvem som følger kvaliteten, oppdaterer kunnskapsgrunnlaget, vurderer avvik og godkjenner endringer.
Nyttige metoder og verktøy
Metoden bør velges ut fra spørsmålet som skal besvares. Et komplekst rammeverk er ikke et mål i seg selv.
Vanlige teknikker er:
- Intervju: avdekker mål, erfaringer, regler og frustrasjoner.
- Observasjon: viser hvordan arbeidet faktisk utføres.
- Workshop: samler perspektiver og avklarer uenighet.
- Prosesskart: visualiserer flyt, roller, beslutninger og avvik.
- Interessentkart: viser ansvar, påvirkning og informasjonsbehov.
- Kundereise eller brukerreise: knytter oppgaver og kontaktpunkter til brukerens mål.
- Fem hvorfor: utforsker mulige rotårsaker bak et synlig symptom.
- Beslutningstabell: gjør regler og kombinasjoner av vilkår tydelige.
- Prototype: gjør abstrakte krav konkrete nok til å testes.
- Prioriteringsliste: viser hva som må, bør eller kan inngå i leveransen.
Verktøyet kan være et dokument, regneark, digital tavle, designsystem eller sakssystem. Velg det formatet teamet faktisk kan forstå, oppdatere og bruke i beslutninger.
Hva gjør en forretningsanalytiker?
En forretningsanalytiker leder eller støtter arbeidet med å avdekke behov, strukturere informasjon, fasilitere avklaringer, beskrive krav og validere løsninger. Rollen fungerer ofte som bro mellom forretning, brukere og tekniske fagmiljøer.
Typiske oppgaver er å:
- planlegge og gjennomføre intervjuer og workshops
- kartlegge prosesser og informasjonsflyt
- analysere problemer, mål og alternativer
- formulere og prioritere krav
- avklare begreper og forretningsregler
- støtte utviklingsteamet med løpende beslutninger
- validere at løsningen møter behovet
Rollen varierer mellom organisasjoner. Noen forretningsanalytikere arbeider tett med strategi, andre med produktteam, krav, prosessforbedring eller implementering.
Forretningsanalytiker, produkteier og prosjektleder
Rollene kan overlappe, men de har ulike hovedansvar.
- Forretningsanalytikeren undersøker behov, prosesser, krav og løsningsalternativer.
- Produkteieren prioriterer produktets retning og rekkefølgen på verdiskapende arbeid.
- Prosjektlederen planlegger og følger opp gjennomføringen innen avtalte rammer.
- Dataanalytikeren undersøker data for å finne mønstre og innsikt.
- Arkitekten eller teknisk leder former tekniske valg og helhet.
I små team kan én person dekke flere funksjoner. Det viktige er at ansvaret er eksplisitt, slik at behov, prioritering, gjennomføring og teknisk kvalitet ikke faller mellom stolene.
Eksempel: Analyse før en AI-assistent
Tenk deg en virksomhet som ønsker en intern AI-assistent for å svare på spørsmål om rutiner.
En svak start er: «Vi bygger en chatbot og kobler den til alle dokumentene.»
En bedre analyse begynner slik:
- Definer hvilke arbeidssituasjoner som skaper mest leting og usikkerhet.
- Finn hvilke brukergrupper som stiller spørsmålene, og hvilke kilder de bruker i dag.
- Kartlegg dokumenteierskap, tilgang, oppdateringsrutiner og motstridende informasjon.
- Velg et avgrenset sett med spørsmål for en første test.
- Beskriv hva svaret må inneholde, hvordan det skal vise grunnlaget, og når assistenten skal avstå.
- Avklar menneskelig kontroll og eskalering.
- Test med realistiske spørsmål før løsningen utvides.
Da blir teknologien et middel for en konkret arbeidsflyt, ikke et mål i seg selv.
Vanlige feil i forretningsanalyse
De vanligste feilene oppstår når teamet hopper over usikkerhet i stedet for å undersøke den.
- Løsningen er bestemt før problemet er forstått. Resultatet blir bekreftelse av en idé, ikke analyse.
- Bare bestilleren blir intervjuet. Viktige brukerbehov og driftskrav kommer for sent.
- Dagens prosess blir kopiert ukritisk. Unødvendige trinn digitaliseres i stedet for å fjernes.
- Krav beskriver funksjoner uten begrunnelse. Teamet mister muligheten til å finne en enklere løsning.
- Alle ønsker får samme prioritet. Første leveranse blir større og vanskeligere å validere.
- AI vurderes bare på en demo. Realistiske feiltilfeller, datakvalitet og forvaltning blir oversett.
- Mål blir definert etter lansering. Teamet mangler et troverdig utgangspunkt for å vurdere effekten.
Slik kommer du i gang
En kort oppstartsworkshop kan gi nok retning til neste analysefase. Samle en beslutningstaker, noen som utfører arbeidet, en teknisk representant og relevante fag- eller driftsroller.
Bruk denne agendaen:
- Formuler problemet i én setning uten å nevne en løsning.
- Beskriv hvem som berøres og hvordan de arbeider i dag.
- List opp hva dere vet, hva dere antar, og hva dere må undersøke.
- Definer ønsket resultat og mulige tegn på forbedring.
- Skisser minst tre alternativer, inkludert prosessendring eller gjenbruk.
- Velg de viktigste spørsmålene for intervjuer, data eller en prototype.
- Avtal hvem som tar beslutningen når svarene foreligger.
Målet med workshopen er ikke å fullføre analysen. Målet er å gjøre usikkerheten synlig og prioritere hvordan den skal reduseres.
Ofte stilte spørsmål
Må man kunne kode for å jobbe med forretningsanalyse?
Nei. Teknisk forståelse kan gjøre det lettere å vurdere alternativer og kommunisere med utviklere, men kjernen er å forstå behov, fasilitere samarbeid, analysere informasjon og formulere tydelige beslutningsgrunnlag.
Hvilke leveranser lager en forretningsanalytiker?
Vanlige leveranser er problemdefinisjon, prosesskart, interessentoversikt, krav, brukerhistorier, akseptansekriterier, beslutningslogg, prototype og plan for måling. Formatet bør tilpasses beslutningen og teamets arbeidsform.
Hvor lang tid tar en forretningsanalyse?
Det avhenger av usikkerhet, risiko, antall interessenter og hvor mye som allerede er kjent. En avgrenset analyse kan gjennomføres raskt, mens et initiativ med flere systemer, regler og brukergrupper krever løpende analyse gjennom hele leveransen.
Når er analysen god nok?
Analysen er god nok når beslutningstakerne forstår behovet, de viktigste alternativene og risikoene, og teamet kan teste en avgrenset løsning med tydelige kriterier. Full sikkerhet er sjelden mulig; målet er å redusere den viktigste usikkerheten før neste beslutning.
Kan AI gjøre forretningsanalysen?
AI kan støtte oppsummering, strukturering, idéutvikling og dokumentarbeid. Den kan ikke alene validere organisasjonens mål, forstå alle lokale unntak eller ta ansvar for beslutningen. Mennesker må kontrollere premisser, kilder og konsekvenser.
Fra uklart ønske til riktig beslutning
God forretningsanalyse gjør et digitalt initiativ enklere å forstå, prioritere og teste. Den skaper et felles språk for ledelse, brukere og utvikling — og holder oppmerksomheten på verdien løsningen skal skape.
Vurderer dere AI eller programvare, men er usikre på hvor dere bør starte? Start en samtale om behovet, alternativene og en fornuftig første avgrensning.