Forretningsanalyseprocesflow: Trin-for-trin-vejledning

Af: Charles Moore Charles Moore
Hours Opdateret

⚡ Smart opsummering

En forretningsanalyseproces guider en forretningsanalytiker fra projektstart til godkendelse af krav, der dækker opdagelse, interessentgennemgang, dokumentanalyse, problemdomæneindramning og struktureret præsentation til projektledere og sponsorer.

  • 🧭 Seks trin: Indsaml projektinformation, identificer interessenter, analyser relevante dokumenter, registrer resultater, formuler problemformuleringen og præsenter krav formelt.
  • 👥 Interessentfokus: En klar dagsorden, specifikke spørgsmål og strukturerede evalueringsmøder holder projektet i gang track og forhindre overraskelser i den sene fase.
  • 📄 Dokumentanalyse: Business cases, procesdiagrammer, politikker og lovgivning gennemgås og valideres, da leverede dokumenter kan være forældede.
  • 🎯 Problemdomæne: Forståelse af berørte forretningsfunktioner, risici, politikker og blokeringsproblemer omdanner rå resultater til et målrettet ændringsforslag.
  • 🛠️ Værktøjer: Jira, Sammenløb, Microsoft Visio, Lucidchart, Jama Connect, og Miro støtte alle faser fra inkasso til godkendelse.
  • ⚠️ Faldgruber: jumping til løsninger, spring overping validering og brug af vagt sprog er fortsat de dyreste fejl i forretningsanalyseprocessen.
Læs mere

Forretningsanalyseprocesflow

Hvad er de trin, der skal følges i forretningsanalyseprocessen?

Følgende er de trin, der er involveret i forretningsanalyseprocessen. Det vil guide dig fra dag 1 forretningsanalyseproces til slutningen af ​​planlægningsfasen.

Trin 1) Indsaml al information om projektet

Det er Forretningsanalytiker ansvar for at indsamle alle detaljer relateret til projektet ved at stille spørgsmål til de personer, der er tilknyttet det (projektleder, projektsponsor, funktionel leder eller virksomhedsejer).

De indsamlede oplysninger bør dække disse emner:

  • Projektets omfang og grænser
  • Aktuelle faktorer, der påvirker organisationen
  • Projektrisiko og begrænsninger
  • Bredere organisatorisk kontekst

Identificér de interessenter, der er aktivt involveret i projektet. Dette er også et godt tidspunkt at gennemføre en Interessenters behovsanalyse.

Når du har indsamlet disse oplysninger, skal du analysere din rolle i projektet og lave en tjekliste, som du som forretningsanalytiker kan inkludere, såsom:

  • Hvilke erfaringer fra tidligere erfaringer kan du anvende i det nuværende projekt?
  • Dokumentation og planlægning kræves for det aktuelle projekt
  • Diskussion af projektets mulige resultater med interessenter
  • Identificér de medlemmer, der er involveret i projektet
  • Arranger et møde med klienten og interessenterne, når der er behov for yderligere input
  • De forventede leverancer og det format, de skal leveres i
  • Eksisterende dokumentation, som du kan gennemgå for at få en bedre forståelse af projektet
  • Metoden (Agile eller vandfald) som vil være mest passende til projektet

Trin 2) Identificer interessenter og opret en RevVis møde

I andet trin skal du oprette en revisionsmøde med projektlederen, interessenter og teammedlemmer. En uklar dagsorden fører ofte til projektfejl.

  • Vær specifik omkring, hvad der forventes af projektet.
  • Involver projektlederen, interessenter og teammedlemmer i mødet og stil spørgsmål relateret til projektet.
  • Hvis du arbejder på et helt nyt projekt, så spørg projektlederen eller en kontaktperson, der har arbejdet inden for det område før.

Trin 3) Analysér alle projektrelevante dokumenter

Dernæst, ordentligt analysere alle projektrelevante dokumenter, såsom:

  • Dokumentation af forretningsprocesser
  • Dokumenter om forretnings- og systemkrav
  • Business cases
  • Diagrammer og flowdiagrammer
  • Projektplaner
  • Organisationsdiagram
  • Strategidokumenter og forretningsplaner
  • Politikker og lovgivning

Afdæk eventuelle oplysninger, der er skjult i forretningskravsdokumentet, og tracmangler i nuværende systemer, processer, procedurer og operationer. Det dokument, du har modtaget, kan være forældet, så valider alle de fakta, du opdager, før du betragter det som endeligt.

Trin 4) Registrer alle de fakta og oplysninger, du opdager

Under research og analyse vil du afdække mange nyttige fakta om projektet, som skal ændres eller implementeres. Registrer alle fund, så de kan gennemgås senere.

  • Forretningskrav, herunder rapporteringskrav
  • Forretningsprocesser og understøttende systemer
  • Funktionelle og ikke-funktionelle krav
  • Problemer og risici, der i øjeblikket påvirker projektet

Trin 5) Forstå problemområdet

På dette tidspunkt har du en solid forståelse af projektet, så du kan identificere problemdomænetDu skal finde ud af:

  • Hvilken forretningsfunktion vil blive påvirket
  • Risici og faktorer, der påvirker virksomheden
  • Politikker og begrænsninger, der påvirker projektet
  • Værdier, der bestemmer projektets vigtighedsgrad
  • Systemer, der i øjeblikket understøtter forretningsaktiviteterne
  • Dokumenter, der opsummerer problemområdet, for eksempel årsrapporten
  • Problemer, der i øjeblikket forhindrer virksomheden i at opnå de ønskede resultater
  • Om den foreslåede ændring gør en forskel for problemområdet

Trin 6) Præsenter forretningskravene

Når du har samlet alle forretningskrav og forstået problemområdet, er næste trin præsentation af forretningskrav til interessenter eller projektlederen. Almindelige præsentationsteknikker omfatter:

  • En tabel eller et regneark
  • Et diagram eller en graf
  • En prototype eller simulering
  • En struktureret tekstskabelon eller struktureret sætning

Ordliste med termer, der giver et hurtigt overblik over forretningsanalytikerprocessen:

  • Formål: Definerer formålet med de forretningsanalyseaktiviteter, der kræves til det foreslåede initiativ
  • Anvendelsesområde: Definerer de leverancer, der er inkluderet og ekskluderet
  • Hovedårsagen: Definerer de grundlæggende årsager til de identificerede problemer
  • Nuværende tilstand: Definerer problemet, der forårsager behovet for forandring
  • Planlagte aktiviteter: Definerer årsagen til aktiviteten, leverancer og leveringsdatoer
  • Plan for interessentengagement: Giver et overblik over processen for interessentengagement
  • Kvalitetsstyring: Beskriver de aktiviteter, der skal sikre kvaliteten af ​​projektleverancer
  • Target Betingelse: Definerer, hvordan de identificerede kritiske problemer vil blive håndteret

RELATEREDE ARTIKLER

Hurtige tips til forretningsanalytiker

  • Stil spørgsmål på møder
  • Vær forberedt før interessentmøde eller gennemgang
  • Vær tilpasningsdygtig til forandringer og nye oplevelser
  • Administrer forventninger
  • Svar på feedback

Fælles leverancer produceret under forretningsanalyseprocessen

Enhver forretningsanalyseproces efterlader et sæt dokumenter, som projektteamet, sponsorer og revisorer kan tractilbage til. At producere disse leverancer konsekvent er det, der gør processen gentagelig på tværs af projekter.

  • Forretningsanalyseplan: Beskriver tilgangen, tidsplanen og planen for interessentengagement for analysearbejdet.
  • Interessentregister: Lister alle interessenter sammen med deres rolle, indflydelse, forventninger og foretrukne kommunikationskanal.
  • Dokument om forretningskrav (BRD): Indfanger de overordnede forretningsbehov, mål og succeskriterier i et sprog, som ikke-tekniske interessenter forstår.
  • Funktionelle og ikke-funktionelle krav: Oversæt BRD'en til systemadfærd, kvalitetsattributter og begrænsninger, som udviklere og testere kan bygge imod.
  • Procesmodeller og brugsscenarier: Vis arbejdsgange i nuværende og fremtidig tilstand ved hjælp af BPMN-diagrammer, UML-use cases eller aktivitetsdiagrammer.
  • Krav Tracevnematrix (RTM): Forbinder ethvert krav med dets kilde, dets designelement og de tests, der verificerer det.
  • Ændringsanmodningslog: Registrerer alle ændringer af omfanget med dens indflydelse, beslutning og godkender, så revisionssporet forbliver intakt.

Disse leverancer bør gemmes i et delt lager, såsom Confluence, SharePoint eller et dedikeret værktøj til kravstyring, så alle teammedlemmer arbejder fra den samme version.

Almindelige fejl, der skal undgås i forretningsanalyseprocessen

Selv erfarne forretningsanalytikere falder i de samme fælder under leveringspres. At være opmærksom på følgende fejl forhindrer de fleste overraskelser i forbindelse med omarbejde og omfang senere i projektet.

  • jumping til en løsning før problemet formuleres: At foreslå et system, værktøj eller en funktion, før den grundlæggende årsag er forstået, fører til dyrt omarbejde og en løsning, der ikke løser det reelle forretningsbehov.
  • Springping validering af interessenter: Registrering af krav uden godkendelse fra de personer, der skal bruge systemet, skaber huller, der først dukker op under brugeraccepttest.
  • Behandling af krav som statiske: Forretningsbehovene ændrer sig under et projekt. En forretningsanalytiker, der ikke vedligeholder kravarkivet, og tracEability-matricen mister hurtigt kontrollen over omfanget.
  • Overdokumentering i stedet for samarbejde: At producere et BRD på 200 sider, som ingen læser, er værre end et kort dokument parret med regelmæssige arbejdssessioner og visuelle modeller.
  • Fokuser kun på den lykkelige vej: Manglende undtagelsestilfælde, fejlhåndtering og ikke-funktionelle krav skubber defekter til produktion og undergraver brugernes tillid.
  • Arbejde i en silo: Analyse af krav uden udviklere, testere og driftsteams overser gennemførlighedsrisici og downstream-begrænsninger, der ville være blevet fanget i en fælles gennemgang.
  • Brug af vagt eller tvetydigt sprog: Ord som "brugervenlig", "hurtig" eller "fleksibel" uden målbare acceptkriterier skaber uenigheder, der kun opstår, når funktionen demonstreres.

Populære værktøjer, der understøtter forretningsanalyseprocessen

Det rigtige værktøjssæt understøtter alle faser af forretningsanalyseprocessen, fra udvælgelse til godkendelse. De fleste teams kombinerer et letvægts backlog-værktøj, et modelleringsværktøj og en dokumentationsplatform.

  • Jira og Azure DevOps: Track-episke historier, brugerhistorier og defekter på tværs af agile leveringsteams og forbind krav til sprintarbejde.
  • Confluence, SharePoint og Notion: Gem forretningsanalyseplanen, mødenotater, beslutninger og BRD'er i et søgbart område, som interessenter kan få adgang til.
  • Microsoft Visio, Lucidchartog draw.io: Tegn BPMN-procesflows, use case-diagrammer og datamodeller, der synliggør arbejdsflows og overdragelser.
  • Jama Connect, IBM DØRE, Modern Requirementsog Visure: Håndter krav i stor skala med baselines, tracbæredygtigheds- og konsekvensanalyse for regulerede projekter.
  • Miro og vægmaleri: Gør det lettere at finde data på afstand, kortlægge brugerens rejsepingog affinitetskortping workshops i realtid.
  • Balsamiq og Figma: Producer lavkvalitets wireframes og højkvalitets prototyper, der validerer foreslåede skærmbilleder med forretningsbrugere, før udviklingen starter.

Små teams starter ofte med Jira, Confluence og LucidchartStørre eller regulerede programmer tilføjer et dedikeret kravstyringsværktøj, når tracGennemførlighed, baselines og revisionsspor bliver obligatoriske.

Ofte Stillede Spørgsmål

AI-copiloter opsummerer interviews, feedback fra interessenter i klyngen, udarbejder brugerhistorier i første omgang og markerer modstridende krav. Forretningsanalytikere bruger AI til at accelerere opdagelse og dokumentation, samtidig med at de holderping prioritering, interessentvurdering og endelig godkendelse i menneskelige hænder.

Ja. GitHub Copilot Chat og GPT-modeller kan omdanne en discovery-disposition til et førsteudkast til BRD med mål, omfang og acceptkriterier. Forretningsanalytikeren validerer forretningstilpasning, redigerer tvetydigt sprog og får interessenternes godkendelse, før teamet forpligter sig til omfanget.

Forretningsanalyse dækker hele projektets livscyklus, herunder strategi, krav og løsningsvurdering. Forretningsprocesanalyse fokuserer specifikt på modellering, måling og forbedring af arbejdsgange i den nuværende tilstand og er en teknik, der anvendes i et bredere forretningsanalyseengagement.

I agile projekter samarbejder forretningsanalytikeren med produktejeren for at forfine backloggen, skriver brugerhistorier med acceptkriterier, deltager i sprintplanlægning og -gennemgange og opdaterer kravarkivet for hvert sprint i stedet for at producere én stor forudgående specifikation.

BABOK er Business Analysis Body of Knowledge, der udgives af IIBA. Den grupperer forretningsanalysearbejde i seks vidensområder – planlægning, elicitering, kravlivscyklus, strategianalyse, kravanalyse og -design samt løsningsevaluering – som former processen.

A-krav TracEability Matrix forbinder hvert krav med dets kilde, dets designelement og de tests, der verificerer det. Det giver teamet bevis for, at intet krav er blevet droppet, og giver dig mulighed for hurtigt at vurdere effekten af ​​en ændringsanmodning.

Logfør alle ændringsanmodninger med dens forretningsmæssige begrundelse og indvirkning på omkostninger, tidsplan og kvalitet. Send den gennem et ændringskontrolpanel eller produktejer for at få en beslutning, opdater kravarkivet og traceffektivitetsmatrix og kommuniker resultatet til alle interessenter.

Brug formatet "Systemet skal..." med et målbart acceptkriterium. Erstat vage udtryk som "hurtig" eller "brugervenlig" med en metrik, en tærskel og en verifikationsmetode. Hvert krav skal knyttes til mindst én testcase i tracevnematrix.

Opsummer dette indlæg med: