Het opzetten van een procesarchitectuur een case study

Het opzetten van een procesarchitectuur

een case study

Miriam Wesselink IOW IT Raaphorstlaan 10–A 2245 BG Wassenaar tel 070–3389050 [email protected] www.iow.nl december 2006

Inhoud Inleiding Achtergrond Positionering Aanpak Resultaat Conclusies en aanbevelingen

2 2 2 3 5 8

Inleiding In het kader van mijn certificering als informatiearchitect bij ERIA, het Europees register voor informatie–architecten (www.eria.nl), heb ik een opdracht uitgevoerd, waarvan een deel het opzetten van een procesarchitectuur bij een opdrachtgever betrof. In deze publicatie wil ik u deelgenoot maken van mijn ervaringen daarmee.

Achtergrond De betreffende organisatie is een (geanonimiseerde) commerciële dienstverlener op het gebied van tijdelijke en permanente personele bezetting. De behoefte aan een procesarchitectuur is ontstaan vanwege de komst van een nieuwe, grote bedrijfsapplicatie en een gelijktijdig lopend project ter optimalisatie van werkprocessen. Beide projecten hebben met (aanpassingen aan) werkprocessen, te maken, waardoor er behoefte ontstond aan afstemming en integratie, evenals centrale vastlegging met behulp van een tool. De procesarchitectuur betreft de twee primaire bedrijfsprocessen Sales en HR.

Positionering De procesarchitectuur omvat de volgende zaken A. (bedrijfs)processen in een hiërarchische structuur (wat gebeurt er); B. procedures (hoe doe je het) en werkinstructies (en waarmee); C. het aanvullen van de hiërarchische structuur van de onderwerpen uit A en B met netwerkverbindingen; D. relatering van de onderwerpen uit A en B aan organisatieonderdelen (wie doet het); E. relatering van de onderwerpen uit A en B aan middelen (waarmee doe je het). De procesarchitectuur kan daarom als volgt in het architectuurraamwerk volgens IAF (Integrated Architecture Framework) worden ondergebracht:


2/9

De verbinding van het organisatiedomein met een dun lijntje via het WAT–niveau in het gegevensdomein naar het WAT–niveau in het applicatiedomein, geeft de relatering aan met bedrijfsapplicaties (punt E in de lijst), in de vorm van in te vullen/aan te passen/uit te lezen gegevens. Het gegevensdomein komt hier dus slechts summier te pas.

Aanpak Project M, het project voor de implementatie van de nieuwe bedrijfsapplicatie M, heeft aangepaste procedures en werkinstructies op het gebied van HR en Sales opgeleverd. Project S, het project ter optimalisatie, leverde een overzicht op van processen op vrij hoog niveau in de aandachtsgebieden Recruitment en Sales, evenals een overzicht van dagelijkse taken in diezelfde aandachstgebieden (om te meten wie hoe lang met wat bezig is). Het Universe of Discourse van beide projecten omvat de decentrale vestigingen; het centrale hoofdkantoor maakt er dus geen deel van uit. De aandachtsgebieden en diepgang van de output van beide projecten worden hieronder weergegeven (Recruitment wordt als onderdeel van HR beschouwd):


3/9

In horizontale richting loopt het bedrijfsproces in beide aandachtsgebieden van frontoffice (waar gegevens voor het eerst de organisatie binnenkomen), tot backoffice (het gebied van onder andere de financiële administratie). De backoffice valt buiten de scope. De dagelijkse taken (project S) liggen grotendeels nog steeds in de WAT–laag, maar deels ook in de HOE-laag en soms in de WAARMEE–laag; dat wordt weergegeven door middel van de dunne rode balken. Tevens is te zien dat project S niet het gehele Salesproces afdekt; daar waar de administratieve afhandeling begint, stopt project S. Project M daarentegen houdt zich pas met Sales bezig vanaf het punt waar registratie begint. In het aandachtsgebied HR bemoeit project S zich alleen met het begin van HR: Recruitment. Project M komt hier pas bij de registratieve afhandeling van Recruitment te pas en doorloopt verder het hele HR–traject, met uitzondering van de organisatie van opleidingen en trainingen, aangezien dat centraal, op het hoofdkantoor ligt (wel worden gevolgde opleidingen en trainingen vastgelegd). Deze uitzondering wordt weergegeven door de witte verticale balk. Standaardisatie

Project S heeft alleen geoptimaliseerde werkprocessen opgeleverd, geen procedures en werkinstructies. Dat is in lijn met de projectopdracht evenals met de bedrijfsfilosofie van de organisatie dat elke vestiging een ondernemer is; deze ondernemers maken zelf uit op welke manier ze de doelstellingen gaan halen. Dat gebeurt weliswaar binnen bepaalde grenzen – zo ziet het organogram er bij elke vestiging hetzelfde uit en zijn de jaarlijkse doelstellingen organisatiebreed bepaald – maar hoe het doel bereikt wordt is in wezen vrij. Vanuit die situatie bekeken is het logisch dat het HOE en WAARMEE in het raamwerk van IAF door project S (grotendeels) opengelaten zijn. Die grote vrijheid in hoe het werk gedaan wordt heeft een keerzijde: gebrek aan standaardisatie. Gebrek aan standaardisatie maakt een grote verandering, zoals aangepaste werkprocessen en de invoering van een grote bedrijfsapplicatie, tot een lastige zaak, ongeveer als een vrachtschip dat de bocht omgaat waarbij de losse containers alle kanten uit vliegen. Die al te grote vrijblijvendheid wil de organisatie ombuigen naar een situatie van standaardisatie gecombineerd met vrije invulling, waar mogelijk. Waar werken volgens voorschriften strakker wordt toegepast en waar dat minder noodzakelijk is, is afhankelijk van het onderwerp; zo vragen aangepaste leveringsvoorwaarden en –aansprakelijkheden nauwkeurige, tijdige registratie, en is het vastleggen van een telefonisch contact om de


4/9

banden aan te halen minder aan regels onderhevig. Niet elk onderwerp laat zich echter zo makkelijk indelen als in dit voorbeeld. Het is dus zaak een optimale balans te vinden tussen standaarden en voorschriften enerzijds en flexibiliteit en vrijheid anderzijds, waarbij je goed in het oog moet houden dat al te strakke standaardisatie en voorschriften kunnen leiden tot een inflexibele organisatie. Alsof op het vrachtschip, om de rondvliegende losse containers te voorkomen, alles, inclusief het roer is vastgesnoerd, met als gevolg dat het schip alleen rechtuit kan varen. Procedures

Behalve dat de organisatie heeft besloten meer standaardisatie toe te passen, bleek ook dat na aanpassing van de project–S–processen de bijbehorende procedures werden gemist. Elke vestiging beschikte, in meerdere en mindere mate, over zelf–opgestelde procedures, werkinstructies, checklists en dergelijke, maar deze waren grotendeels niet geldig meer in de nieuwe situatie. Bovendien vond men dat, nu de processen voor alle vestigingen gelijk waren, het logisch zou zijn als dat ook voor de procedures zou gelden. Als spin–off van het S–project zijn alle eigengemaakte procedures en dergelijke geïnventariseerd met als doel daaruit een selectie te maken van procedures die, na aanpassing, bedrijfsbreed worden ingezet. Dat is het punt in de tijd waar we ons nu bevinden. Aanpassing houdt niet alleen in dat de stukken in lijn worden gebracht met de geoptimaliseerde processen, maar ook dat ze worden aangepast aan het M–tijdperk, waarin de nieuwe bedrijfsapplicatie geïmplementeerd zal zijn; project S heeft namelijk alleen naar de bestaande situatie gekeken en niet naar de situatie vanaf de implementatie van M. De M–procedures en –werkinstructies worden aangevuld met S–procedures en –werkinstructies die hun oorsprong vinden in de aangegeven selectie en aangepast zijn aan de geoptimaliseerde processen en de M–situatie. Waar iets al door M–procedures en –werkinstructies wordt beschreven, prevaleren deze. Gaten worden opgevuld met nieuw–opgestelde procedures en werkinstructies.

Resultaat Bij het vastleggen van de procesarchitectuur heb ik de S–processen als startpunt gebruikt. Vanwege het ontbreken van processen in de output van project M, heb ik deze voor HR en het laatste stukje van Sales, uit de procedures van project M afgeleid:

De dagelijkse taken van project S geven een bottom–up–mogelijkheid; deze heb ik gegroepeerd per deelproces. Ook de procedures uit project M zijn bottom–up waar van toepassing in de S– processen ingepast. De S–processen en M–processen zijn verder in een boom– en een netwerkstructuur uitgewerkt in deelprocessen, processtappen, enzovoort. Tot dusver is een procesarchitectuur opgesteld met de M– en S–processen en de M–procedures:


5/9

Het beoogde resultaat is een procesarchitectuur waarin de Sales– en HR–processen van de projecten M en S, in hun aandachtsgebieden Sales en HR, compleet en op het M–tijdperk gericht zijn, en waarvoor een complete verzameling procedures, werkinstructies en andere hulpmiddelen beschikbaar is:


6/9

Als we eenmaal zover zijn, wanneer ook de projecten M en S zijn afgesloten, is het onderscheid 'M' en 'S' verdwenen, waardoor dit plaatsje een beter beeld geeft:

Spin–offs

Het spin–off–project waarbij de bestaande procedures en dergelijke worden geïnventariseerd, is al ter sprake gekomen. Nu de processen en procedures expliciet en zichtbaar worden, krijgt de organisatie er steeds meer gevoel voor waar met standaardisatie en voorschriftmatig werken voordelen te behalen zijn, zonder dat daarbij de voordelen van vrijheid en flexibiliteit teniet worden gedaan. Dit heeft al geleid tot een tweede spin–off, tevens getriggerd door knelpunten die kunnen leiden tot een negatief effect op de DSO (Days of Sales Outstanding, de tijd die ligt tussen het opstellen van een factuur en de betaling van de vordering). Het ligt in de lijn der verwachtingen dat er zo meer spin–offs zullen ontstaan. Tool

De procesarchitectuur wordt vastgelegd in de tool MAVIM. MAVIM noemt zichzelf een SpelregelInformatieSysteem en is laagdrempelig, gebruiksvriendelijk en flexibel. Het is een generieke tool; zoals je met MS–Word een brief, een roman of een jaarverslag kunt maken, kun je met MAVIM een kwaliteitsmanagementsysteem, een handboek Soldaat of een procesarchitectuur maken. Deze vrijheid en flexibiliteit betekenen wel dat je goed moeten nadenken over hoe je e.e.a. vastlegt en hoe je dat ter beschikking stelt. Een voorbeeld van een te nemen besluit: Waar koppel je gerelateerde functionarissen in een hiërarchisch proces – op het laagste niveau? Dan zie je ze niet als je op een hoger niveau staat, terwijl je toch wilt weten dat, bijvoorbeeld, HR–support uitvoerend is in het indiensttredingsproces. Het besluit dat we hiervoor genomen hebben is dat functionarissen worden gekoppeld aan elk proces én elke processtap/activiteit waar ze een functie hebben; dus HR–support zowel bij proces Indiensttreding als bij de activiteit Genereren arbeidsovereenkomst. Waar HR–support allemaal betrokken is wordt getoond in de vorm van matrices, waarbij de processen open– en dichtgeklapt kunnen worden. Die vorm geeft overzicht terwijl toch recht wordt gedaan aan alle koppelingen die er in de werkelijkheid bestaan. Ander voorbeeld: Vanuit M hebben we inmiddels al veel procedures in de vorm van Worddocumenten. Nemen we die procedures in hun huidige vorm op? Dat past meestal niet in de


7/9

processflow; we zouden de proceduretekst dan in stukjes kunnen hakken en elk stukje aan het geëigende proces plakken, maar meestal vereist dat herschrijven. Een andere mogelijkheid is dat de procedure integraal aan het proces op hoog niveau wordt gekoppeld en dat daarvan in de onderliggende onderwerpen vermelding van gemaakt wordt. We hebben voor deze kwestie besloten dat we de bestaande M–procedures in hun huidige vorm opnemen en wel op het geëigende niveau (vrijwel nooit het laagste). Er wordt vanuit andere processen en processtappen via hyperlinks naar verwezen. Voor procedures die nog geschreven worden, wordt voor elke processtap een stukje tekst geschreven. De 'procedurestukken' worden elk aan de relevante processtap/activiteit gekoppeld én aan de 'parentprocedure'; de parentprocedure vormt zo weer een compleet verhaal. Op die manier hebben we alle tekst overal waar het thuishoort, terwijl het toch slechts op één plek wordt vastgelegd en onderhouden. Op termijn worden de bestaande procedures naar de nieuwe vorm omgebouwd.

Conclusies en aanbevelingen Communicatie

(Ook) uit dit project is gebleken dat, als variant op wat de drie belangrijkste punten zijn bij het kopen van een huis (locatie, locatie, locatie), de drie belangrijkste punten bij een project zijn: communicatie, communicatie, communicatie. Het gekke is dat iedereen het hier altijd absoluut mee eens is, maar keer op keer blijken allerlei dingen die niet gaan zoals de bedoeling is, voornamelijk op gebrekkig communicatie teruggevoerd te kunnen worden. En als afgeleide van communicatie: check, check en dubbelcheck! Een plaatje zegt meer dan 1000 woorden

Gebruik bij het weergeven van processen plaatjes. Eén plaatje zegt meer dan duizend woorden. Ik merkte dat direct bij mijn opdrachtgever. Maar zorg wel dat de plaatjes begrijpelijk voor de argeloze lezer zijn. Ga er niet van uit dat de lezer dezelfde kennis en achtergrondinformatie heeft als jij. Integratie van betrokken partijen

Wat daarnaast belangrijk is bij een project zoals dit, waar verschillende partijen bij betrokken zijn, is het tegengaan van het haast onvermijdelijk optredende wij–en–zij–gevoel. Wat daarbij een probaat middel is, is het mixen van mensen uit de verschillende groepen; zorg waar mogelijk ervoor dat werkgroepen zoveel mogelijk uit een mix van partijen bestaan en dat de beschikbare kantoorruimtes worden bevolkt met een 'multiculturele' bezetting. Net als in de maatschappij ontstaat integratie niet met gated communities en aparte wijken voor aparte bevolkingsgroepen, maar door vermenging. Tegenstrijdige belangen

De stelling dat stakeholders belangen kunnen hebben die afwijken van die van de organisatie zelf, bleek ook bij dit project op te gaan. Hoe kan het dat er tegenstrijdige belangen bestaan? Ten eerste zakelijk: wat goed is voor een bepaalde afdeling hoeft nog niet goed te zijn voor de organisatie als geheel. Stel dat het callcenter geweldig groeit vanwege het toenemende aantal klachten; klachten zijn dus kennelijk goed voor het callcenter maar niet voor de organisatie. (Natuurlijk ligt dat wat genuanceerder: als er zoveel klachten komen dat de organisatie tenonder gaat is dat ook niet goed voor het callcenter.) Tevens worden functionarissen afgerekend op het behalen van de KPI's, die daardoor een verkeerde sturing kunnen veroorzaken; denk daarbij aan het voorbeeld van de politie die een bepaald quotum bekeuringen moest halen, wat tot gevolg kon hebben dat ook een keurige dame op leeftijd bekeurd werd vanwege een ontbrekend identiteitsbewijs. Ten tweede persoonlijk: een functionaris kan er persoonlijk belang bij hebben dat een bepaald doel wel of niet gehaald wordt; denk bijvoorbeeld aan mensen die bij een efficiëntere indeling van processen of afdelingen hun baan dreigen kwijt te raken. In voorkomende gevallen waar ik in dit project tegen iets aanliep, heb ik de leidinggevende van de functionaris in kwestie erbij betrokken c.q. het management/de directie van het hogergelegen organisatieonderdeel; dat is dan degene die maar moet zeggen of het linksom of rechtsom moet gaan.


8/9

Grenzen betekenen risico's

Vooral waar processen over de grenzen van organisatorische onderdelen zoals afdelingen gaan, zijn er risico's. Bij dit soort processen weet de linkerhand soms niet wat de rechter doet of veronderstelt het een terwijl het ander gebeurt. In sessies waarbij de aan M aan te passen procedures voor dergelijke processen met betrokkenen uit verschillende afdelingen werden besproken, bleek regelmatig dat mensen van de ene afdeling veronderstelden dat het door hen aangeleverde werk aan de andere afdeling, op een bepaalde manier verder werd behandeld, terwijl dat absoluut niet zo was, wat ongewenste gevolgen kon hebben voor een correct verloop van het proces. En dat ging dan soms al jaren zo. Daarom is het belangrijk dat bij zo'n proces met name de processtappen en activiteiten die op die grenzen liggen tot op het laagste niveau worden beschreven; terugkoppeling van ontvanger naar zender is cruciaal. Overigens gelden deze risico's natuurlijk nog sterker waar processen over grenzen van organisaties gaan, zoals bij ketenintegratie. Vrijheid versus voorschrift

De optimale balans tussen dwingende standaarden en voorschriften enerzijds en flexibiliteit en autonomie anderzijds is vaak lastig te vinden. Dit is iets waar je, zoals deze organisatie heeft gedaan, door voortschrijdend inzicht, gevoel voor moet ontwikkelen. Bekijk problemen en oplossingen van meer dan één kant

Deze aanbeveling kwam met name voort uit de te nemen besluiten bij het vastleggen in de tool: bekijk een oplossing die je overweegt altijd vanuit meer dan een kant. Bijvoorbeeld het koppelen van een functionaris aan zowel een proces als aan processtappen daarbinnen: kijk naar hoe dat eruit ziet vanuit het proces en de processtappen, maar bekijk het ook vanuit de functionaris; daar zie je alle gekoppelde processen, processtappen, activiteiten, enzovoort. Ziet dat er logisch en begrijpelijk uit? Zo nee, kies dan een andere oplossing. En bekijk die uiteraard ook vanuit minstens twee kanten. Omgaan met onzekerheid

Wees kritisch, neem niet alles zomaar aan. Maar schiet daarin niet door. Een bepaalde mate van onzekerheid hoort er nu eenmaal bij. En geen enkel project verloopt geheel volgens plan. Wat helpt om de onzekerheid weg te nemen is gewoon een beetje rondstruinen in alle informatiebronnen die beschikbaar staan (binnen en buiten de organisatie), zoals schijven op het netwerk, handboeken en rapporten in de kast, enzovoort. Zo komt er wel eens kennis tot je die je niet speciaal gezocht hebt (waarvan je niet eens wist dat er kennis over te vergaren was) maar die je een nieuwe blik en nuttige informatie verschaft, ook op zaken waarvoor je geen informatie nodig dacht te hebben. Het WAARMEE beïnvloedt het WAT

Processen liggen in de WAT–laag en lijken onafhankelijk van de HOE– en de WAARMEE-laag; alsof je een bedrijfsapplicatie kunt invoeren zonder dat de processen veranderen. Dat is echter niet zo. De mogelijkheden je hebt om je werk te doen stuurt de inrichting van je bedrijfsproces. Dat gold bij de bedrijfsapplicatie M, ook al is die door de eigen ICT–organisatie ontwikkeld, maar het geldt nog veel sterker bij standaardapplicaties, hoe parametriseerbaar ze ook zijn; denk maar eens aan het invoeren van Oracle Applications of SAP. Technology drives processes. Zorg dat ze er niet omheen kunnen

Zorg voor een vorm en functie van de aangeboden procedures, werkinstructies, enzovoort, die leiden tot het daadwerkelijk door de medewerkers gebruiken van de aangeboden informatie. Zo zou je benodigde formulieren voor bijvoorbeeld het declareren van kosten, alleen bij of via de procedures beschikbaar kunnen stellen. Aha–erlebnis leidt tot vliegwiel

Het vastleggen van de procesarchitectuur maakt zaken expliciet en daardoor zichtbaar. Er worden pijnpunten zichtbaar maar ook, of juist als gevolg daarvan, mogelijkheden voor verbetering. Pas als je weet dat een probleem bestaat kun je hier succesvol iets aan doen; van deze 'aha' wordt de organisatie enthousiast en ontstaat een cascade van initiatieven. Zo is de aha–erlebnis een vliegwiel.


9/9

Het opzetten van een procesarchitectuur een case study

Recommend Documents