Forretningsprocesser

Gennemførelse af aktiviteter er det, der holder virksomheden i gang. Gennemførelsen muliggøres af ressourcer – fx menneskelige ressourcer, råvarer, viden, maskiner, computere, programmel osv. Mange situationer kræver gennemførelse af mange sammenhængende aktiviteter, tit udført af forskellige medarbejdere, og med anvendelse af forskellige IT-systemer.

Det er praktisk at se sammenhængende aktiviteter som en proces (forretningsproces), og enighed om hvordan processer udføres, er vigtigt for at opretholde en forudsigelig produktivitet og undgå fejl, der efterfølgende tager tid at rette.

Tag fx ansættelsen af en ny medarbejder. Arbejdet starter rimeligvis med at fx en afdelingsleder skal have personaleudvidelsen godkendt af ledelsen. Så følger en rekruttering, og til sidst kan en ny medarbejder ansættes. Er det tre adskilte processer (altså hver sin procesbeskrivelse)? Eller slås ansøgning om oprettelse af en ny stilling og selve rekrutteringen (hvis stillingen godkendes) sammen? Det er i bund og grund en smagssag.

Ligesom use cases kan procesbeskrivelsen have et normalt forløb, og efter behov alternative forløb. Fx kan en proces for ansættelse af en ny medarbejder skrives så normalforløbet er at en stilling bliver ledig fordi en ansat siger op. Her kræver processen måske ikke ledelsens godkendelse. Så kan et alternativt forløb i processen beskrive hvordan man ansøger om, og får ledelsens godkendelse til at oprette en ny stilling.

Et proceskatalog med beskrivelser af de væsentlige processer hjælper medarbejderne med at huske hvordan aktiviteterne i processerne skal gennemføres, og hvordan eventuelle maskiner og IT-systemer anvendes korrekt i arbejdet. Proceskataloget hjælper også med oplæring af nye medarbejdere, eller oplæring af medarbejdere, der flytter til nye arbejdsområder.

Proceskataloget kan være noget så enkelt som en mappe med alle procesbeskrivelserne, evt. med et katalogdokument, der blot er en liste over alle processerne. For at gøre procesbeskrivelserne let tilgængelige for alle, kan en side på et intranet linke til processerne. En side i intranettet kan også fungere som proceskatalog. Større virksomheder vælger nogle gange webbaserede proceskataloger, tit med mulighed for at tegne processerne som diagrammer. Det kan være kostbart, og nogle gange mere tidskrævende, end blot at beskrive processerne i fx Word. Det er elegant, når det er lavet ordentligt, men jeg er ikke overbevist om at muligheden for at klikke rundt i procestegninger på intranettet har noget praktisk funktion i virksomhedens daglige arbejde.

Procesbeskrivelsens opbygning

Indledning

Formål	Beskriv kort formålet med processen.
Hyppighed	Beskrive hvor ofte processen anvendes.
Initiativtager	Angiv rollebetegnelse for den aktør, der initierer processen.
Igangsættende hændelse	Beskriv kort den igangsættende hændelse. Det kan være et fast tilbagevendende tidspunkt, eller fx at en (ekstern) aktører henvender sig.
Anvendte systemer	Nævn hvilke systemer, der evt. anvendes i processen – angiv evt. meget kortfattet i hvilken sammenhæng (aktivitet/procestrin), systemerne anvendes.
Væsentlig information	Nævne de væsentlige informationer, der håndteres i processen. Skal kunne genfindes i informationsmodellen.
Procesejer	Angiv navnet på den ansvarlige for processen.
Senest opdateret	Angiv hvornår procesbeskrivelsen senest er revideret.
Ikrafttræden	Angiv evt. hvornår processen træder i kraft.
Ophør	Angiv evt. hvornår processen ophører.

En revisionshistorik vil også være en god ide.

Procestrinene beskrives som en sekvens af aktiviteter (eller procestrin). Det er ikke nogen standard for procesbeskrivelser, men jeg arbejder oftest med følgende retningslinjer:

• Lav gerne diagrammer i skitseform som omdrejningspunkt for diskussioner om hvordan nye processer kan skrues sammen. Men undgå at bruge diagrammer som permanent dokumentation. Diagrammer giver overblik over flows og afhængigheder, men egner sig ikke til formidle detaljer om håndteret information eller brug af IT-systemer.
• Skriv gerne beskrivelserne i Word. Det er nemt og tilgængeligt for alle i virksomheden. Illustrationer og indklippede skærmbilleder muliggør meget præcise instrukser om hvordan en aktiviteter udføres korrekt i et understøttende IT-system.
• Hver aktivitet (procestrin) bør kun involvere et enkelt IT-system (hvilket i virkeligheden svarer til en specifik use case specifikation. Større aktiviteter, der kræver anvendelse af flere systemer, bør splittes op, så de hver især kun anvender et enkelt system.
• I modsætning til use case specifikationer, som skal realiseres til punkt og prikke, er det op til hver enkelt virksomhed at vælge hvor stramt procesbeskrivelser skal følges. Nogle processer er kritiske og bør følges nøje, men i mindre virksomheder er værdien af deres procesbeskrivelser oftest at udbrede kendskab til hvordan forskellige områder fungerer, og der kan være plads til improvisation. Hvis medarbejderne ender med at oftest løse opgaverne anderledes end beskrevet, bør procesbeskrivelserne naturligvis opdateres.

Procestrin

1. –
2. –
3. –

Procestrinene kan grupperes hvis der er dele af processen, der kun udføres undtagelsesvis, eller hvis der er alternative forløb.

Eksempel