Den samlede forretningsanalyse

Det er anbefalelsesværdigt at starte arbejdet med forretningsanalysen ved at udarbejde en procestidslinje. Nedenstående skabelon kan anvendes til både AS IS og TO BE-scenarierne.

Arbejdet med procestidslinjen er en stærk måde at at tage hul på processnakken. Det er det, fordi den intuitiv og meningsfuld for alle - uanset om man er vant til at tænke forretningsmodellering som en disciplin eller ej. Alle kan bidrage i denne snak.

Bemærk, at procestidlinjen altså kan bruges som både AS IS-værktøj og TO BE-værktøj.

Nedenstående skema viser et eksempel på en grundlæggende proces (i de 'røde aktiviteter' har forretningen et stort ansvar, ide 'blå aktiviteter' har primært IT). Eksemplet - her en generisk oversigt over udviklingsprocessen for et givet system i forvaltning) - viser en proces, beskrevet med følgende parametre:

• Aktiviteterne i den samlede proces, listet sekventielt
• Involverede roller i den enkelte procesaktivitet
• Artefakt - forstået som det eller de produkter, en given aktivitet eller fase frembringer
• De formaliserede godkendelser, der er nødvendige i procesforløbet
• Her er tilføjet tænkte eksempler på fejlkilder som en anskueliggørelse af, at man i forbindelse med etablering af fælles overblik over processen med fordel kan synliggøre, hvad der kan gå galt (eller erfaringsmæssigt går galt) i processen. Denne fælles viden er værdifuld i fht fastlæggelsen af den fremtidige løsning. I forlængelser heraf kunne det også give god mening at tilføje en parameter, der hedder noget i retning af 'Skal bevares' - igen for at skabe fælles forståelse af værdierne.

Bemærk, at procesaktiviteterne kan kvalificeres ved mange andre parametre også - det vil afhænge af processen. Fokus for nedenstående proces er de procesaktiviteter, hhv forretningen (systemforvalter) og AU IT tilsammen og i fællesskab gennemfører i en udviklingsopgave. I en ren forretningsproces giver det rigtig god mening at tilføje rækker, der beskriver det, hvis et fakultet eller administrativ enhed har en særlig variant af en procesaktivitet. Man kunne her have en række med labellen 'Alternativ praksis' eller 'Lokale varianter', hvor man eksempelvis (frit opfundet) kan beskrive 'AR: Kvalificering sker hos administrationschef'. En sådan synliggørelse af en alternativ praksis vil kunne bidrage til vurderingen af, hvordan den alternative praksis særligt bidrager til kvalitet eller effektivitet i processen. Og dermed vurderingen af, hvorvidt alternativet i virkelighed ville være værdigt til at bære ind i TO BE-processen for alle.

Hver aktivitet vil være en del-proces, og denne kan brydes yderligere ned. I samme format, hvis det giver bedst mening - men også i verbale beskrivelser i form af user stories og use cases.

Nedenstående skema er lavet helt simpelt - blot i regneark. Det gør arbejdet let - både i opbygningen og i vedligeholdet.

For at få et samlet overblik over en proces, er det væsentligt at få styr på:

• hvilke roller, der har 'berøring med' processen - har en interesse i den - og som processen skal tilgodese
• hvad den enkelte rolle har brug for at kunne gøre - eller få fra processen - for at kunne varetage sin interesse eller sit ansvar 

Interessentoverblikket kortlægger således det fulde overblik over rollerne og deres behov ift processen - og den skaber den liste over user stories, som bør skrives for at belyse den fuldstændigt.

Nedenstående tænkte eksempel er behandling af AU-kreditkortanmodning. 

User stories er små, præcise fortællinger om de værdiskabende aktiviteter, den kommende arbejdsproces består af - fortalt fra den enkelte bidragende brugers perspektiv. Der er derfor væsentligt at have det fulde overblik over de roller, der samlet set er involveret i den enkelte proces. Værktøjet til dette sidste er: Interessentoverblik.

Fordelen ved at fokusere på behov i stedet for det, man tror, man ved om den kommende løsning, er mange:

• de fleste er verdensmestre i deres egne arbejdsopgaver og har gode holdninger til, hvorledes de eksisterende processer kan optimeres og bidrage til både højere kvalitet og effektivitet
• man får et rigtig godt værktøj til at sikre, at man kommer hele vejen rundt om opgaven og får alle rollers behov med i beskrivelsen
• når man kan beskrive og kommunikere sit behov i stedet for at' løse det tekniske' i sin overdragelse til arkitekter og udviklere, kan man overdrage ansvaret for at komme med et eller flere bud på et design af den bedste løsning til den tekniske og UX-mæssige ekspertise. Man mister ikke kontrollen, for man vil blive hørt og involveret i den videre proces.

User stories har et helt specifikt format:

Når man har styr på sine roller (brugertyper) og deres user stories, kan man tage næste skridt og konkretisere sine user stories i use cases.

En use case er en struktureret måde at beskrive brugen af (interaktionen med) et system - ikke selve systemet. Som det fremgår af nedenstående eksempel, som vedrører registrering af data om fag- og forskningsområder, som Danmarks Statistik kræver for hver ph.d.-studerende, er use casens fokus forretningsregler. 

I nedenstående eksempel mangler ikke meget i at gøre kravene testbare. 

Bemærk, at use case skabelonen er fantastisk til at få styr på både AS IS aktiviteterne og - senere - TO BE aktiviteterne. Man må ikke undervurdere den fælles forståelse af AS IS - særligt ikke i en så stor og divers organisation som AU. Når AS IS kan variere på tværs af vores organisation, er det særligt vigtigt at etablere en fælles basis og forståelse af styrker og svagheder ved den eksisterende proces for derfra at kunne tegne den proces og systemunderstøttelse, man har behov for for at nå de forretningsmæssige mål.

Use case skabelon - indeholdende et eksempel:

Læs evt mere om use cases på eksempelvis https://docplayer.dk/11513953-Metodehaandbog-use-cases-kombit.html  (højreklik og åbn linket i ny fane)