B4 FORRETNINGSPROCESSER OG ARBEJDSGANGE / WORKFLOWS
Formål
Aktiviteten sigter mod at dokumentere de forretningsprocesser og arbejdsgange organisationen opererer med.
På EA niveau drejer det sig om at identificere de mest kritiske processer; der hvor it-indsatsen skal fokuseres og om muligt forbedres.
På løsningsniveau drejer det sig om at konkretisere til mere operationelle arbejdsgange (workflows), hvor det mere detaljeret vises hvordan de enkelte aktører i samarbejde løser en række opgaver i trin. Dette tjener ikke mindst til at sikre at arbejdsdelingen mellem forskellige aktører (organisatoriske enheder) afdækkes og forankres. Dette kan også medføre ønsker, der føder ind i designet af systemunderstøttelsen af arbejdsgangene.
Input
Input fås primært fra interviews og workshops med forretningen samt fra aktiviteterne B1. Forretningsobjekter, B2. Organisation, B3. Forretningsservices samt når det kommer til workflows fra B5. Forretningsregler og B6 Use cases. de to sidstnævnte foregår ofte i parallel med arbejdet med workflows.
It-chef og applikationsarkitekter kan deltage for at bidrage med viden om mulghederne for it-understøttelse.
Output
På EA niveau udvikles en højniveau forretningsmodel for organisationen – den hele, eller dele deraf. Output kan omfatte:
- Procesmodel – Beskriver de enkelte processer og aktiviter i disse, og ikke mindst illustrerer flowet af disse. Flowet illustreres typisk grafisk.
- Proces-evaluering – Evaluering af forretningsprocessers vigtighed, hold op imod hvor effektivt de understøttes af it, og hvor stor en indsats dette kræves (kritikalitet, effektivitet og udgifter – ”hvor vigtigt er det, hvor godt virker det, og hvad koster det?”).
Der laves desuden eller eller flere af disse mapninger til oversigter fra de B1 Forretningsobjekter og B2 Organisation og lokationer (som regel er blot én tilstrækkeligt)
- Proces-forretningsobjekt map – Beskriver hvilke processer der genererer og bruger hvilke informationer (forretningsobjekter). Man kan også mappe processer imod de informationsobjekter der identificeres i C1, men det kan vise sig at blive meget detaljeret.
- Proces-lokationsmap – Beskriver hvilke processer der afvikles hvor.
- Proces-organisationsmap – Beskriver hvilke organisationer der udfører hvilke processer.
På løsningsniveau udvikles
- Arbejdsgangsbeskrivelser (workflows) – Disse kan dokumenteres i klassik svømmebane diagrammeringsstil, der beskriver aktiviteters flow og hvilke aktører (organisatoriske enheder) der foretager hvad, hvornår.
- Forretningsregler tilknyttet arbejdsgange (workflows) – Disse kan tage udgangspunkt i mere overordnede forretningsregler fra B5 Forretningsregler, og relaterer disse til konkrete arbejdsgange.
Metode
Input fra de ande aktiviteter inden for forretning samt interview/workshop med forretningssiden.
På EA niveau:
Procesmodellen bør udvikles af erfarne proces-modellører. Man vil kunne bruge diverse gængse proces-modelleringsmetoder, fx BPMN eller UML. Det er vigtigt at holde sig på et relativt højt niveau – en organisation vil typisk have 10-15 hovedprocesser og 7-10 supportprocesser.
De er målet at planlægge it-understøttelsen for forretningsprocesserne fremover, så man bør fokusere på de processer, der fremadrettet skal udføres – herunder også nogle der ikke udføres eller kun delvist udføres i dag. Processer der afskaffes behøver omvendt ikke it-understøttelse fremover. Man kan dog modellere både de nuværende (as-is) og de fremtidige (to-be) processer, men så er vi over i retning af business process re-engineering, hvilket ikke er fokus med OIO Enterprise Arkitektur.
Evalueringen af processerne er vigtig for designet af den fremtidige applikationsarkitektur. Man må søge at få prioriteret processernes vigtighed og den effektivitet brugerne oplever (altså hvor godt supporten for arbejdsopgaverne i de enkelte processer er), sammenholdt med ”best-in-class”. Her er brugerne (forretningssiden) de rigtige at spørge. Samtidig prøver man at få kvantificeret hvor meget it-indsats man samlet set putter ind i de applikationer der understøtter en given proces. Det vil normalt være it-afdelingen der kommer med estimater på it-indsats.
De beskrevne mapninger foretages bedst ved at EA arkitekten laver et oplæg, og reviewer det med it- og forretningssiden. Som nævnt er én af de tre mapninger typisk nok. Nogle gange er det proces-forretningsobjekt der giver mest mening, andre gange proces-lokation/organisation – det afhænger lidt af vinklen på EA indsastsen.
På løsningsprojektniveau:
Arbejdsgange / workflows er en detaljering af Use cases, hvor man mere detaljeret viser hvordan opgaverne løses, og af hvem. Bemærk, at også dokumentation af arbejdsgange /workflow primært skal være de fremtidige – hvordan brugerne forestiller sig at arbejde med de nye systemer. Der kan være faser af workflows, svarende til faser i implementeringen af den fremtidige arkitektur. Man kan dog godt forestille sig at man tegner de nuværende workflows op først, som en hjælp til at designe de fremtidige.
Der er ikke en en-til-en sammenhæng mellem et workflow og en Use case. Et workflow kan (helt eller delvist) beskrive flere Use cases, og en Use case kan være beskrevet i flere workflows. Workflows og forretningsregler udarbejdes bedst i sammenhæng – sådan at forretningsregler, der er bred enighed om, kommer til at diktere hvordan nogle workflows kommer til at forme sig, og at de naturlige workflows der fremkommer, kommer til at introducere nye forretningsregler.
Som i Use case arbejdet er det en god ide at følge en fremgangsmåde som nedenstående:
- Den ansvarlige arkitekt lister (typisk med udgangspunkt i Use cases) de workflows han/hun mener skal beskrives, og laver et første udkast til disse, samt til tilhørende forretningsregler.
- Fokus i et workflow er ikke mindst de steder hvor kontrol skifter fra én aktør til en anden. Dette vil typisk medføre krav til en integration imellem applikationer, eller til en funktionalitet i en applikation (herunder også sikkerhedskrav). Det er dog vigtig at være opmærksom på at en kontrol-overgang ikke nødvendigvis er systemunderstøttet – men man kan stadig betragte de aftaler der indgås i workflowene som en del af en enterprise arkitektur.
- De modificerede workflows/forretningsregler sendes ud til aktørerne, og der afholdes en workshop med alle aktører samlet, hvor nogle de uoverensstemmelser der er bringes op og søges løst. Dette enten ved at arbejdsgangen ændres, eller ved at den underliggende systemunderstøttelse modificeres.
- Efter 1:1 reviewrunden må arkitekten søge at tilpasse workflowene/forretningsreglerne så de kan dække aktørernes ønsker bedst muligt. Dette er ikke altid muligt – nye systemer betyder ofte nye arbejdsgange, hvor ansvar for opgaver ændres.
- De skitserede workflows/forretningsregler reviewes enkeltvis med de aktører der indgår.
- Use cases og workflows er en dialogmekanisme, hvor aktørerne udtrykker sig i brugertermer, der så ”oversættes” til teknologikrav – ikke mindst til applikationsarkitekturen. Dette stiller store krav til den faciliterende arkitekt, at vedkommende skal kunne forstå begge verdener. Udviklingen af navnlig workflows vil ofte foregå i parallel med applikations- og informations-arkitektur designet.
- Som diagrammeringsteknik vil ”svømmebaner” ofte være en god ide. Man kan benytte sig af UML aktivitydiagram, UML state diagram, BPMN (Business Process Modelling Notation), eller andre gængse workflow diagrammeringsformer.
Gode råd
På EA niveaue er proceskortlægningen en yderst essentiel aktivitet og bør tjene som referenceramme i en række af de øvrige aktiviteter. Man kan kun vanskeligt gå fra forretningsstrategier til applikations- og teknologivalg, uden at sikre at it-understøttelsen af forretningsprocesserne er tænkt ind.
På løsningsniveau er det essentielt, at de arkitekter der faciliterer opgaven med at modellere og dokumentere workflows, er i stand til at sætte sig i brugernes sted, og ikke tænker i teknologi, men i behov. Som ansvarlig for en Use case leverance bør man kun til en vis grad bruge sin teknologiske viden til at komme med arbejdsgange-forslag, men derimod i høj grad lytte til brugernes behov og ideer.
Workflows er både anvendelige internt, og som materiale i en kravspecifikation.