Prosessflyt for forretningsanalyse: trinn for trinn veiledning

Hva er trinnene å følge i forretningsanalyseprosessen?

Følgende er trinnene som er involvert i forretningsanalyseprosessen. Den vil veilede deg fra dag 1 forretningsanalyseprosessen til slutten av planleggingsfasen.

Trinn 1) Samle all informasjon om prosjektet

Det er Forretningsanalytiker ansvar for å samle alle detaljer knyttet til prosjektet ved å stille spørsmål til personene som er tilknyttet det (prosjektleder, prosjektsponsor, funksjonell leder eller bedriftseier).

Informasjonen som samles inn bør dekke disse emnene:

• Prosjektets omfang og grenser
• Nåværende faktorer som påvirker organisasjonen
• Prosjektrisiko og begrensninger
• Bredere organisatorisk kontekst

Identifiser interessentene som er aktivt involvert i prosjektet. Dette er også et godt tidspunkt å gjennomføre en Analyse av interessentenes behov.

Etter å ha samlet denne informasjonen, analyser din rolle i prosjektet og lag en sjekkliste som du som forretningsanalytiker kan inkludere, for eksempel:

• Hvilke lærdommer fra tidligere erfaringer kan du bruke i det nåværende prosjektet?
• Dokumentasjon og planlegging som kreves for det aktuelle prosjektet
• Diskutere mulige resultater av prosjektet med interessenter
• Identifiser medlemmene som er involvert i prosjektet
• Avtal et møte med klienten og interessentene når det er behov for ytterligere innspill
• Forventede leveranser og formatet de kreves i
• Eksisterende dokumentasjon du kan gjennomgå for å få en bedre forståelse av prosjektet
• Metodikken (Smidig eller Foss) som vil være mest passende for prosjektet

Trinn 2) Identifiser interessenter og opprett en Revvisningsmøte

I det andre trinnet, sett opp en revisjonsmøte med prosjektleder, interessenter og teammedlemmer. En uklar agenda fører ofte til at prosjektet mislykkes.

• Vær spesifikk om hva som forventes av prosjektet.
• Involver prosjektleder, interessenter og teammedlemmer i møtet og still spørsmål knyttet til prosjektet.
• Hvis du jobber med et helt nytt prosjekt, spør prosjektlederen eller en kontaktperson som har jobbet innen det feltet før.

Trinn 3) Analyser alle prosjektrelevante dokumenter

Neste, ordentlig analysere alle prosjektrelevante dokumenter, som for eksempel:

• Dokumentasjon av forretningsprosesser
• Dokumenter for forretnings- og systemkrav
• Forretningssaker
• Diagrammer og flytdiagrammer
• Prosjektplaner
• Organisasjonskart
• Strategidokumenter og forretningsplaner
• Retningslinjer og lovverk

Avdekk all informasjon som er skjult i forretningskravdokumentet og trace mangler i gjeldende systemer, prosesser, prosedyrer og drift. Dokumentet du har mottatt kan være utdatert, så valider alle fakta du oppdager før du behandler det som endelig.

Trinn 4) Registrer alle fakta og informasjon du oppdager

Under forskning og analyse vil du avdekke mange nyttige fakta om prosjektet som må endres eller implementeres. Registrer alle funn slik at de kan gjennomgås senere.

• Forretningskrav inkludert rapporteringskrav
• Forretningsprosesser og støttesystemer
• Funksjonelle og ikke-funksjonelle krav
• Problemstillinger og risikoer som for tiden påvirker prosjektet

Trinn 5) Forstå problemdomenet

På dette tidspunktet har du en solid forståelse av prosjektet, slik at du kan identifisere problemdomenetDu må finne ut av dette:

• Hvilken forretningsfunksjon vil bli påvirket
• Risikoer og faktorer som påvirker virksomheten
• Retningslinjer og begrensninger som påvirker prosjektet
• Verdier som bestemmer prosjektets viktighetsnivå
• Systemer som for tiden støtter forretningsaktivitetene
• Dokumenter som oppsummerer problemområdet, for eksempel årsrapporten
• Problemer som for tiden hindrer virksomheten i å oppnå de ønskede resultatene
• Om den foreslåtte endringen utgjør en forskjell for problemområdet

Trinn 6) Presenter forretningskravene

Når du har samlet alle forretningskrav og forstått problemområdet, er neste trinn presentere forretningskravene til interessenter eller prosjektlederen. Vanlige presentasjonsteknikker inkluderer:

• En tabell eller et regneark
• Et diagram eller en graf
• En prototype eller simulering
• En strukturert tekstmal eller strukturert setning

Ordliste som gir en rask oversikt over forretningsanalytikerprosessen:

• Formål: Definerer formålet med forretningsanalyseaktivitetene som kreves for det foreslåtte initiativet
• Omfang: Definerer leveransene som er inkludert og ekskludert
• Opprinnelig årsak: Definerer de underliggende årsakene til de identifiserte problemene
• Nåværende tilstand: Definerer problemet som forårsaker behovet for endring
• Planlagte aktiviteter: Definerer årsaken til aktiviteten, leveranser og leveringsdatoer
• Plan for interessentengagement: Gir en oversikt over prosessen med interessentengagement
• Kvalitetsstyring: Beskriver aktivitetene som skal sikre kvaliteten på prosjektleveransene
• Target Betingelse: Definerer hvordan de kritiske problemene som er identifisert skal håndteres

Raske tips for forretningsanalytiker

• Still spørsmål på møter
• Vær forberedt før interessentmøte eller gjennomgang
• Vær tilpasningsdyktig til endringer og nye opplevelser
• Administrer forventningene
• Svar på tilbakemelding

Vanlige leveranser produsert under forretningsanalyseprosessen

Hver forretningsanalyseprosess etterlater et sett med dokumenter som prosjektteamet, sponsorer og revisorer kan tractilbake til. Det at disse leveransene produseres konsekvent er det som gjør prosessen repeterbar på tvers av prosjekter.

• Plan for forretningsanalyse: Beskriver tilnærmingen, tidslinjen og planen for interessentengagement for analysearbeidet.
• Interessentregister: Lister opp alle interessenter sammen med deres rolle, innflytelse, forventninger og foretrukne kommunikasjonskanaler.
• Dokumentasjon for forretningskrav (BRD): Fanger opp forretningsbehov, mål og suksesskriteriene på overordnet nivå i et språk som ikke-tekniske interessenter forstår.
• Funksjonelle og ikke-funksjonelle krav: Oversett BRD-en til systematferd, kvalitetsattributter og begrensninger som utviklere og testere kan bygge mot.
• Prosessmodeller og brukstilfeller: Vis arbeidsflyter i nåværende og fremtidig tilstand ved hjelp av BPMN-diagrammer, UML-brukstilfeller eller aktivitetsdiagrammer.
• Krav Tracevnematrise (RTM): Knytt alle krav til kilden, designelementet og testene som bekrefter det.
• Logg for endringsforespørsler: Registrerer alle endringer i omfanget med innvirkning, beslutning og godkjenner, slik at revisjonssporet forblir intakt.

Disse leveransene bør lagres i et delt arkiv, for eksempel Confluence, SharePoint eller et dedikert verktøy for kravhåndtering, slik at alle teammedlemmer jobber fra samme versjon.

Vanlige feil å unngå i forretningsanalyseprosessen

Selv erfarne forretningsanalytikere faller i de samme fellene under leveringspress. Å være oppmerksom på følgende feil forhindrer de fleste omarbeidinger og overraskelser knyttet til omfang senere i prosjektet.

• jumping til en løsning før problemet formuleres: Å foreslå et system, verktøy eller en funksjon før den underliggende årsaken er forstått, fører til kostbart omarbeid og en løsning som ikke løser det reelle forretningsbehovet.
• Hoppping interessentvalidering: Registrering av krav uten godkjenning fra personene som skal bruke systemet skaper hull som bare dukker opp under brukeraksepttesting.
• Behandling av krav som statiske: Forretningsbehovene endrer seg under et prosjekt. En forretningsanalytiker som ikke vedlikeholder kravarkivet og tracevnematrisen mister snart kontroll over omfanget.
• Overdokumentering i stedet for samarbeid: Å produsere en BRD på 200 sider som ingen leser er verre enn et kort dokument kombinert med vanlige arbeidsøkter og visuelle modeller.
• Fokuserer kun på den lykkelige veien: Manglende unntakstilfeller, feilhåndtering og ikke-funksjonelle krav presser feil til produksjon og svekker tilliten hos brukerne.
• Arbeid i en silo: Å analysere krav uten utviklere, testere og driftsteam overser gjennomførbarhetsrisikoer og nedstrøms begrensninger som ville blitt fanget opp i en felles gjennomgang.
• Bruk av vagt eller tvetydig språk: Ord som «brukervennlig», «rask» eller «fleksibel» uten målbare akseptkriterier skaper uenigheter som bare dukker opp når funksjonen demonstreres.

Populære verktøy som støtter forretningsanalyseprosessen

Det riktige verktøysettet støtter alle faser av forretningsanalyseprosessen, fra innhenting til godkjenning. De fleste team kombinerer et lett verktøy for ordrebeholdning, et modelleringsverktøy og en dokumentasjonsplattform.

• Jira og Azure DevOps: Track-eposer, brukerhistorier og defekter på tvers av agile leveringsteam og koble krav til sprintarbeid.
• Confluence, SharePoint og Notion: Lagre forretningsanalyseplanen, møtenotater, beslutninger og BRD-er på et søkbart område som interessenter har tilgang til.
• Microsoft Visio, Lucidchart, og draw.io: Tegn BPMN-prosessflyter, brukstilfellediagrammer og datamodeller som synliggjør arbeidsflyter og overleveringer.
• Jama Connect, IBM DØRER, Modern Requirementsog Visure: Håndter krav i stor skala med grunnlinjer, tracbærekrafts- og konsekvensanalyse for regulerte prosjekter.
• Miro og veggmaleri: Legge til rette for ekstern oppdagelse, brukerreisekartping, og affinitetskartping workshops i sanntid.
• Balsamiq og Figma: Produser lavkvalitets wireframes og høykvalitets prototyper som validerer foreslåtte skjermbilder med forretningsbrukere før utviklingen starter.

Små team starter ofte med Jira, Confluence og LucidchartStørre eller regulerte programmer legger til et dedikert verktøy for kravhåndtering når traceffektivitet, grunnlinjer og revisjonsspor blir obligatoriske.

Spørsmål og svar