Processen: verschil tussen versies

Regel 43: Regel 43:
  
  
[[Bestand:Figuur 5.1.png|omkaderd|gecentreerd|''Veranderen behoeft Ontwerpen, Ontwikkelen en borgen'']]
+
[[Bestand:Figuur 5.1.png|omkaderd|gecentreerd|''Figuur 1: Veranderen behoeft Ontwerpen, Ontwikkelen en borgen'']]
  
  
Regel 50: Regel 50:
 
* ontwikkelen betreft de ‘groene’: benadering, die van de lerende organisatie;
 
* ontwikkelen betreft de ‘groene’: benadering, die van de lerende organisatie;
 
* de ‘rode’ benadering benadrukt de aandacht voor mens.  
 
* de ‘rode’ benadering benadrukt de aandacht voor mens.  
 +
  
 
Voor de inrichting van een optimale bedrijfsvoering is het hele palet nodig: BPM op een fundament van architectuur, met de juiste methodieken en technieken en de ontwikkeling van organisatie en medewerkers in al haar facetten.  
 
Voor de inrichting van een optimale bedrijfsvoering is het hele palet nodig: BPM op een fundament van architectuur, met de juiste methodieken en technieken en de ontwikkeling van organisatie en medewerkers in al haar facetten.  
Regel 87: Regel 88:
  
  
[[Bestand:Figuur 5.2.png|omkaderd|gecentreerd|''Raamwerk NORA'']]
+
[[Bestand:Figuur 5.2.png|omkaderd|gecentreerd|''Figuur 2: Raamwerk NORA'']]
  
  
Regel 102: Regel 103:
  
  
[[Bestand:Figuur 5.3.png|omkaderd|gecentreerd|''Proces als een verbindend architectuurelement'']]
+
[[Bestand:Figuur 5.3.png|omkaderd|gecentreerd|''Figuur 3: Proces als een verbindend architectuurelement'']]
  
  
Regel 115: Regel 116:
 
Afgeleid van de genoemde strategische principes kun je meer specifieke principes voor de processen vaststellen:
 
Afgeleid van de genoemde strategische principes kun je meer specifieke principes voor de processen vaststellen:
  
<small>''* Wij labelen alle processen volgens een strakke procesgranulariteit.'' Zodat we weten of een proces een keten (proces met andere partijen) omvat, een bedrijfsproces is (van klant tot klant) een werkproces is (dat netjes binnen een bedrijfsfunctie blijft), een (processtap of) activiteit (eenheid van tijd, plaats en handelen) of een handeling. Zie figuur 5.3 en tabel 5.1.
+
<small>''* Wij labelen alle processen volgens een strakke procesgranulariteit.'' Zodat we weten of een proces een keten (proces met andere partijen) omvat, een bedrijfsproces is (van klant tot klant) een werkproces is (dat netjes binnen een bedrijfsfunctie blijft), een (processtap of) activiteit (eenheid van tijd, plaats en handelen) of een handeling. Zie figuur 3 en tabel 1.
 
   
 
   
  
''* Wij richten onze bedrijfsprocessen als volgt in: ontkoppeling van contactkanalen (multichannel voor in- en outputmanagement) en enkelvoudige processen (single process) voor het productiedeel.'' Onafhankelijk van hoe het verzoek tot het leveren van een dienst tot stand komt (e-mail, brief, webform, app), het produceren van de dienst is daar onafhankelijk van. Zie figuur 5.7. Dit is overeenkomstig het onderkennen van contactkanalen en processen als separate elementen.
+
''* Wij richten onze bedrijfsprocessen als volgt in: ontkoppeling van contactkanalen (multichannel voor in- en outputmanagement) en enkelvoudige processen (single process) voor het productiedeel.'' Onafhankelijk van hoe het verzoek tot het leveren van een dienst tot stand komt (e-mail, brief, webform, app), het produceren van de dienst is daar onafhankelijk van. Zie figuur 7. Dit is overeenkomstig het onderkennen van contactkanalen en processen als separate elementen.
  
  
''* Wij onderkennen een aantal archetypen bedrijfsprocessen met een bepaald patroon waaraan al bepaalde typen bedrijfsprocessen moeten voldoen.'' Als we processen meer in detail uitwerken (in Business Process Management Notation - BPMN) dan moeten ze voldoen aan een aantal voorgedefinieerde patronen. Voorbeelden van archetypen processen: leveren dienst op basis van verzoek, handhaving, fraude onderzoek, inwinnen gegevens, enzovoort. Dit voorkomt dat er onnodige wildgroei ontstaat in procesmodellen. Zie voor een patroon figuur 5.6.
+
''* Wij onderkennen een aantal archetypen bedrijfsprocessen met een bepaald patroon waaraan al bepaalde typen bedrijfsprocessen moeten voldoen.'' Als we processen meer in detail uitwerken (in Business Process Management Notation - BPMN) dan moeten ze voldoen aan een aantal voorgedefinieerde patronen. Voorbeelden van archetypen processen: leveren dienst op basis van verzoek, handhaving, fraude onderzoek, inwinnen gegevens, enzovoort. Dit voorkomt dat er onnodige wildgroei ontstaat in procesmodellen. Zie voor een patroon figuur 6.
  
  
Regel 141: Regel 142:
  
  
[[Bestand:Figuur 5.4.png|omkaderd|gecentreerd|''Procesmodel CORA 3.0 (procesatlas)'']]
+
[[Bestand:Figuur 5.4.png|omkaderd|gecentreerd|''Figuur 4: Procesmodel CORA 3.0 (procesatlas)'']]
  
  
Regel 183: Regel 184:
  
  
[[Bestand:Figuur 5.5.png|omkaderd|gecentreerd|''Verschillende views voor verschillende Stakeholders'']]
+
[[Bestand:Figuur 5.5.png|omkaderd|gecentreerd|''Figuur 5: Verschillende views voor verschillende Stakeholders'']]
  
  
Regel 206: Regel 207:
  
  
[[Bestand:Figuur 5.6.png|omkaderd|gecentreerd|''Patroon Verstrekken Product en Dienst (conform Gemma)'']]
+
[[Bestand:Figuur 5.6.png|omkaderd|gecentreerd|''Figuur 6: Patroon Verstrekken Product en Dienst (conform Gemma)'']]
  
  
Regel 253: Regel 254:
  
  
[[Bestand:Figuur 5.7.png|omkaderd|gecentreerd|''Multi Chanel - Single Proces'']]
+
[[Bestand:Figuur 5.7.png|omkaderd|gecentreerd|''Figuur 7: Multi Chanel - Single Proces'']]
  
  
Regel 275: Regel 276:
  
  
[[Bestand:Figuur 5.8.png|omkaderd|gecentreerd|''Besturingspyramide'']]
+
[[Bestand:Figuur 5.8.png|omkaderd|gecentreerd|''Figuur 8: Besturingspyramide'']]
  
  
Regel 397: Regel 398:
  
  
[[Bestand:Figuur 5.9.png|omkaderd|gecentreerd|''Bedrijfsproces Afhandelen Declaratie'']]
+
[[Bestand:Figuur 5.9.png|omkaderd|gecentreerd|''Figuur 9: Bedrijfsproces Afhandelen Declaratie'']]
  
  
  
  
[[Bestand:Figuur 5.10.png|omkaderd|gecentreerd|''Werkproces Verwerken Declaratie (Happy Flow')'']]
+
[[Bestand:Figuur 5.10.png|omkaderd|gecentreerd|''Figuur 10: Werkproces Verwerken Declaratie (Happy Flow')'']]
  
  
 
Voor het werkproces is alleen de view gegeven voor de zogenaamde ‘happy flow’, zonder uitval en afkeuringen en ook zonder escalaties, bijvoorbeeld op overschrijdingen van de doorlooptijd.
 
Voor het werkproces is alleen de view gegeven voor de zogenaamde ‘happy flow’, zonder uitval en afkeuringen en ook zonder escalaties, bijvoorbeeld op overschrijdingen van de doorlooptijd.
  
Technieken, methodieken en tooling
 
  
Technieken
+
 
 +
====Technieken, methodieken en tooling=====
 +
 
 +
 
 +
'''Technieken'''
 +
 
 
De afgelopen 10 jaar zijn er enorme stappen gemaakt op het gebied van methodieken, technieken en gereedschappen als het gaat om ontwerp en inrichting van processen. Eindelijk hebben we een open standaard, een specificatietaal, om processen mee te beschrijven: de open standaard BPMN®, inmiddels met versie 2.0. In figuur 5.10 is al een voorbeeld van gegeven.
 
De afgelopen 10 jaar zijn er enorme stappen gemaakt op het gebied van methodieken, technieken en gereedschappen als het gaat om ontwerp en inrichting van processen. Eindelijk hebben we een open standaard, een specificatietaal, om processen mee te beschrijven: de open standaard BPMN®, inmiddels met versie 2.0. In figuur 5.10 is al een voorbeeld van gegeven.
  
Regel 418: Regel 423:
  
  
[[Bestand:Figuur 5.11.png|omkaderd|gecentreerd|''Drie ontwerpdomeinen met hun eigen specificatietalen'']]
+
[[Bestand:Figuur 5.11.png|omkaderd|gecentreerd|''Figuur 11: Drie ontwerpdomeinen met hun eigen specificatietalen'']]
  
  
Regel 426: Regel 431:
  
 
In Nederland is Prince2 als methodiek voor projectmanagement vrij algemeen geaccepteerd. In de projectuitvoering wordt bij projecten met een belangrijke informatiecomponent steeds vaker agile gewerkt (bijvoorbeeld volgens SCRUM). Kenmerkend aan een SCRUM-aanpak is dat alle projectleden ‘dicht op elkaar’ het project uitvoeren. De relatie met Prince2 als projectmanagement methodiek is dan als volgt: besturing van het project; alsmede start, initiatie en afsluiting vinden plaats conform Prince2; de uitvoering van de verschillende in het project onderkende brokstukken volgens SCRUM.  
 
In Nederland is Prince2 als methodiek voor projectmanagement vrij algemeen geaccepteerd. In de projectuitvoering wordt bij projecten met een belangrijke informatiecomponent steeds vaker agile gewerkt (bijvoorbeeld volgens SCRUM). Kenmerkend aan een SCRUM-aanpak is dat alle projectleden ‘dicht op elkaar’ het project uitvoeren. De relatie met Prince2 als projectmanagement methodiek is dan als volgt: besturing van het project; alsmede start, initiatie en afsluiting vinden plaats conform Prince2; de uitvoering van de verschillende in het project onderkende brokstukken volgens SCRUM.  
 +
  
 
'''Tooling'''
 
'''Tooling'''
Regel 453: Regel 459:
  
  
[[Bestand:Figuur 5.12.png|omkaderd|gecentreerd|''Proces Maturity'']]
+
[[Bestand:Figuur 5.12.png|omkaderd|gecentreerd|''Figuur 12: Proces Maturity'']]
  
  
Regel 480: Regel 486:
  
  
 +
[[Bestand:Figuur 5.13.png|omkaderd|gecentreerd|''Figuur 13: Klant - Proces - Product'']]
  
 
EFFE TOT HIER GEKOMEN
 
EFFE TOT HIER GEKOMEN

Versie van 19 nov 2019 om 20:14

Binnen het focusgebied Processen wordt de methodiek Business Process Management (BPM) behandeld en wordt de verbinding gelegd met de CORA-processen.


Business Process Management (BPM)

Onder Business Process Management wordt verstaan: “Het zorgen voor een optimale bedrijfsvoering van een organisatie”. CORA zet als referentie-architectuur het vertrekpunt voor verandering. Met BPM ga je die verandering daadwerkelijk handen en voeten geven: hoe moet die verandering richting de gewenste situatie ingezet worden? Hoe pak je dat aan, welke activiteiten zijn daar voor nodig, welke best practices en hulpmiddelen kun je daarvoor gebruiken?

De enige vaste factor in een organisatie is verandering. Maar veranderen is lastig. Dat geldt voor het individu en - opgeteld - al helemaal voor een organisatie. Vaak is een verander-voorstel niet goed doordacht (wat is de visie; wat is het beleid), wordt de voorgestelde verandering slecht gecommuniceerd en wordt het ad hoc ingezet. Medewerkers en management snappen het waarom niet en zien ze de voordelen onvoldoende. Vaak zie je ook dat het wiel elke keer opnieuw uitgevonden wordt: de organisatie heeft weinig lering getrokken uit eerdere ervaringen; met als gevolg dat men terug valt in oude fouten.

Om succesvol te kunnen veranderen en hiermee dus ook een optimale bedrijfsvoering te krijgen en te houden is het noodzakelijk om vanuit drie verschillende benaderingen naar BPM te kijken: ontwerpen, ontwikkelen en borgen.


Doelgroep

Steeds meer woningcorporaties raken bekend met BPM omdat ze er van gehoord hebben of omdat ze er zelf mee bezig zijn. Het doel van dit onderdeel is om een overzicht te geven op het gebied van BPM: een BPM-visie. Je kunt het zien als een ‘primer’. Als de ‘primer’ droog is, kan de lak eroverheen. Dit betekent wel dat voor een groot deel het beschrevene niet-branche specifiek is. Voor een deel overigens wel.

De doelgroep is breed: bestuurders, architecten, procesontwerpers en business analisten binnen de woningcorporaties.

Op deze pagina zal de ontwerpbenadering de meeste aandacht krijgen. Dat wil echter niet zeggen dat het ontwikkelen en borgen van minder belang is. Neen, ze kunnen niet zonder elkaar. Wel is het zo, dat het handig is, dat het ontwerpen een beetje voorloopt op het ontwikkelen. Met een paar uitgewerkte procesplaatjes weet je tenminste waarover je kunt en wilt communiceren en in welke richting de verandering zal gaan bewegen.

Zoals u zult zien, is BPM een belangrijke en brede discipline. Het loont de moeite om een aparte BPM-functie bij een woningcorporatie in te richten.


Ontwerpen, ontwikkelen en borgen in samenhang

A. Ontwerpen

  • Om niet op ad hoc basis te gaan veranderen, in projecten die elkaar eerder tegenwerken dan elkaar versterken, is een doordacht plan nodig: een bedrijfs- en informatieplan (BIP), gevoed door een visie en een duidelijke ondernemingsstrategie.
  • Een dergelijk plan moet gebaseerd zijn op een goed fundament, een (woningcorporatie) architectuur, die weer gebaseerd kan zijn op een gemeenschappelijke architectuur voor de sector (de CORA). In de architectuur staat waar we naar toe willen: “begin met het eind in gedachten”. Voor een optimale bedrijfsvoering is een goede procesarchitectuur leidend. Een goed raamwerk om de architectuur langs te ordenen is noodzakelijk. In essentie is architectuur ook ontwerpen, zij het op hoofdlijnen en met het accent op samenhang.
  • Het dienstverleningsconcept, de bedrijfsvoering (processen, besturing, KPI’s, rollen, functies, AO/IC) en de noodzakelijke informatievoorziening worden vervolgens uitgewerkt in zowel communiceerbare en realiseerbare architectuurplaten.


B. Ontwikkelen

  • De voorgestelde veranderingen voor een nieuwe bedrijfsvoering zullen door de betrokkenen mensen gemaakt, begrepen, gewild, uitgevoerd en gemanaged moeten worden.
  • Ontwikkelen van kennis, gedrag en vaardigheden van iedereen binnen de organisatie is nodig.
  • Dit geldt op het niveau van organisatie, afdeling/team en individu en voor bestuurder, manager en medewerker.
  • Veranderen is mensenwerk, mensen moeten de noodzaak zien, de bereidheid hebben en natuurlijk ook het vermogen hebben om te veranderen.


C. Borgen

  • Veranderen is niet iets eenmalig. Veranderen moet van een tijdelijke gebeurtenis naar een continue gaan. Het is erg frustrerend om elke keer te moeten beginnen met een schoon blad. Dat schiet niet op.
  • Voor het borgen van de ontwerpen en het kunnen veranderen zelf zijn afspraken nodig over eigenaarschap van processen en producten. Denk hierbij aan de inrichting van een Vraag- en Aanbodorganisatie voor informatievoorziening (Demand/Supply): Het eigenaarschap van de procesinrichting zit in de vraag-organisatie en er zijn een aantal taken en functies nodig om dit proces vanuit de IT-aanbodorganisatie goed te ondersteunen.
  • Om van verandering meer een continuüm te maken, is ook aandacht nodig voor de ontwikkeling van het vakgebied methodieken, technieken en gereedschap-pen. Kennis en ervaring opdoen met bepaalde werkvormen hoort hier ook bij. Als steeds opnieuw bedacht en uitgelegd moet worden hoe je het beste een bepaald team samenstelt, een project doet, met welke taal bepaalde modellen beschreven worden, hoe je eisen/wensen (requirements) achterhaalt en be-schrijft, hoe er getest gaat worden, dan komt er van het veranderen zelf weinig terecht. Veranderen moet in zekere mate op iets vanzelfsprekends gaan lijken.


In onderstaande figuur zijn de drie benaderingen (ontwerpen, ontwikkelen en borgen) om succesvol te kunnen veranderen samengevoegd en voorzien van karakteristieken. BPM neemt hier een centrale positie in.


Figuur 1: Veranderen behoeft Ontwerpen, Ontwikkelen en borgen


De figuur beschrijft kleuren naar de theorie van De Caluwé (zie ref. 7):

  • ontwerpen betreft de ‘blauwe’ benadering;
  • ontwikkelen betreft de ‘groene’: benadering, die van de lerende organisatie;
  • de ‘rode’ benadering benadrukt de aandacht voor mens.


Voor de inrichting van een optimale bedrijfsvoering is het hele palet nodig: BPM op een fundament van architectuur, met de juiste methodieken en technieken en de ontwikkeling van organisatie en medewerkers in al haar facetten.

Het ontwerpen kun je beschouwen als Business Process Modeling. Het ontwikkelen, implementeren en borgen als Business Process Management.


Opbouw van de methodiek

Voor BPM worden achtereenvolgens de volgende onderwerpen behandeld:

• Ontwerpbenadering
   - Proces-architectuur (met principes, modellen/views)
   - Patronen en best practices (zaakgerichte architectuur, Straight Through Processing)
   - Besturen, verantwoorden en risicobeheersing
   - Ontwerpen van processen
   - Technieken, Methodieken en tools
   - Informatievoorziening
• Ontwikkelbenadering
   - Procesvolwassenheid
   - Strategische keuzes
   - Het verander- en leerproces
• Borgen van de verandering
   - Borgen en bestendigen van de ontwikkeling
   - Borgen en bestendigen van ontwerpen
• Architectuurconcepten processen en informatievoorziening. 


Ontwerpbenadering

Procesarchitectuur

De inrichting van efficiënte en effectieve processen begint bij het opzetten van het fundament: de architectuur. “Werken onder Architectuur is het vakgebied dat - gegeven de strategische keuzes van het topmanagement - zorgt voor een integrale en samenhangende bedrijfsinrichting.“ Ze doet dat aan de hand van principes en afgeleide uitgangspunten, modellen, richtlijnen en standaarden. Een kortere omschrijving is dan ook “Architectuur = principes, beleid en modellen”.

In de procesarchitectuur worden principes vastgelegd waaraan processen moeten voldoen: “wij doen dat hier zo!”. Vervolgens worden modellen uitgewerkt waarvan views (architectuurplaatjes) gemaakt kunnen worden: Verschillende views voor verschillende betrokkenen (stakeholders) die ook andere belangen hebben. Voor de ordening van de principes, de methodieken en de modellen wordt in de CORA het ‘gekantelde’ NORA 9-vlaks raamwerk (zie ref. 2) gebruikt. Daarin is te zien dat processen de ‘hoe-invalshoek’ van de bedrijfsarchitectuur is.


Figuur 2: Raamwerk NORA


Principes

In de CORA staan een aantal strategische principes. De volgende drie zijn richtinggevend voor de inrichting van de processen bij woningcorporaties:

  • “De doelstellingen van de woningcorporatie en de inrichting van de bedrijfsvoering bepalen de inrichting van de informatievoorziening en de inzet van IT (principe 1)”;
  • “Bij veranderingen wordt gestuurd op de integrale samenhang (principe 3)”;
  • “Processen worden ontworpen vanuit de toegevoegde waarde die zij bieden bij het leveren van producten en diensten aan (interne of externe) klanten (principe 4)”.

Er zijn meerdere ‘haakjes’ van deze strategische principes naar BPM te leggen.

  • In principe 1 staat dat de bedrijfsvoering de inrichting van de informatievoorziening en IT bepaalt. BPM is de kern van de bedrijfsvoering.
  • In principe 3 staat dat bij veranderingen integraal moet worden gekeken. Dat is architectuur eigen: samenhang en integraliteit. Processen blijken een goede kapstok te zijn om andere aspecten aan op te hangen. In figuur 5.3 is aangegeven hoe verschillende relaties liggen tussen processen en andere elementen in de vlakken van het architectuurraamwerk. Het proces is de lijm tussen aan de ene kant de producten en diensten (die aan de externe of interne klant geleverd worden) en aan de andere kant de organisatie en informatievoorziening.


Figuur 3: Proces als een verbindend architectuurelement


  • De noodzakelijk integraliteit zoals beschreven in principe 3 komt naast de architectuur ook terug in de andere aspecten zoals beschreven in het palette van figuur 5.1: de aspecten voor ontwikkeling en borging;
  • Principe 4 heeft het over toegevoegde waarde bieden. Dat is de kern van procesgericht denken. Onder een proces wordt verstaan: “Een proces is een geordende reeks van (in)direct waarde toevoegende handelingen en oordelen door een mens of machine gericht op een bekend resultaat.” Zie ook het begrippenkader in CORA 3.0 bijlage 11.
  • Een stapje verder komen we bij de kern van principe 4: kijken naar processen op een ‘end-2-end’ manier (van klant tot klant). Niet meer per afdeling taakgericht, maar procesgericht over de organisatie heen. Dit betekent voor een organisatie meestal een grote verandering, leidend tot het ‘kantelen’ van de organisatie (d.w.z. primair sturen op procesketens en niet meer op afdelingen). Dit heeft grote gevolgen voor de noodzakelijke kennis en kundigheid van de betrokken mensen. Daarnaast zijn er grote gevolgen voor de opzet van de informatievoorziening en een andere inrichting van de besturing van het bedrijf: managementstijl, proceseigenaarschap, zaakgericht werken (casemanagement), managementinformatie enzovoorts


Afgeleide principes voor processen

Afgeleid van de genoemde strategische principes kun je meer specifieke principes voor de processen vaststellen:

* Wij labelen alle processen volgens een strakke procesgranulariteit. Zodat we weten of een proces een keten (proces met andere partijen) omvat, een bedrijfsproces is (van klant tot klant) een werkproces is (dat netjes binnen een bedrijfsfunctie blijft), een (processtap of) activiteit (eenheid van tijd, plaats en handelen) of een handeling. Zie figuur 3 en tabel 1.


* Wij richten onze bedrijfsprocessen als volgt in: ontkoppeling van contactkanalen (multichannel voor in- en outputmanagement) en enkelvoudige processen (single process) voor het productiedeel. Onafhankelijk van hoe het verzoek tot het leveren van een dienst tot stand komt (e-mail, brief, webform, app), het produceren van de dienst is daar onafhankelijk van. Zie figuur 7. Dit is overeenkomstig het onderkennen van contactkanalen en processen als separate elementen.


* Wij onderkennen een aantal archetypen bedrijfsprocessen met een bepaald patroon waaraan al bepaalde typen bedrijfsprocessen moeten voldoen. Als we processen meer in detail uitwerken (in Business Process Management Notation - BPMN) dan moeten ze voldoen aan een aantal voorgedefinieerde patronen. Voorbeelden van archetypen processen: leveren dienst op basis van verzoek, handhaving, fraude onderzoek, inwinnen gegevens, enzovoort. Dit voorkomt dat er onnodige wildgroei ontstaat in procesmodellen. Zie voor een patroon figuur 6.


* Wij stellen prestatie-indicatoren (PI) vast voor alle processen. Zonder PI’s worden processen niet in productie genomen, aangezien we dan geen informatie hebben over het al dan niet goed verlopen van de procesgang. Zie Tabel 5.3.


* Wij registreren op minimaal werkprocesniveau (en maximaal processtapniveau) de procesgegevens. Input, output, uitvoerder, doorlooptijden, enzovoort. Zodat we de efficiëntie kunnen meten en kunnen afzetten tegen de PI’s.

Het is de kunst om met een beperkt aantal principes de belangrijkste richting en keuzes vast te leggen. Deze zijn altijd algemeen geldend, dus niet dienst-, systeem- of projectspecifiek. Dan komen we namelijk bij het programma van eisen (requirements) dat wel dienst-, systeem- of projectspecifiek kan zijn.

Het goed doorléven van deze principes is belangrijk. Ze moeten een eigenaar kennen. En principes komen niet zomaar uit de lucht vallen: principes dragen bij aan het realiseren van een doel of van een hoger liggend strategisch principe. Bij het begin van elk project (in een Project Start Architectuur) moet de lijst principes afgevinkt worden: Gaan/kunnen we hier aan voldoen of moeten we afwijken (of zelfs formeel ontheffing aanvragen) en voor hoelang dan? Reserveren we geld voor herstel of inpassing op een later moment?

Principes kunnen worden verhelderd door er plaatjes bij te tekenen. Dan komen we bij de modellen en views.


Modellen en Views

Een belangrijke plaat voor BPM is het zogenaamde processenlandschap of processenatlas (procesarchitectuur). Hierin staan alle processen die van belang zijn voor de woningcorporatie. In eerste instantie de primaire processen. Daarnaast de (be)sturende en ondersteunende processen. Hiermee wordt in één oogopslag duidelijk wat het bestaansrecht van de woningcorporatie is: welke processen zijn er nodig om de producten en diensten te leveren en op welke manier komen die tot stand?


Figuur 4: Procesmodel CORA 3.0 (procesatlas)


De genoemde processen hierboven hebben de grootte van een bedrijfsproces. Een goed begrip krijgen van de grootte van processen is belangrijk. Hieronder staat een tabel met een beschrijving van de procesgranulariteit (zie ref. 8).


Niveau Toelichting Voorbeeld
'Ketenproces' Een geordende reeks services die door verschillende organisaties aan elkaar worden geleverd met als doel om via één organisatie een (combinatie van) dienst(en) te leveren aan een klant.

Ketenproces staat hier tussen quoten om te benadrukken dat hier het interactieperspectief voorop staat (interactie tussen de betrokken partijen in de keten). Bij de andere procesniveaus hieronder is dat het decompositieperspectief.

Wonen-keten

Bouw-keten

Bedrijfsproces Een bedrijfsproces is een geordende reeks werkprocessen die binnen één organisatie wordt uitgevoerd met als doel om een (combinatie van) dienst(en) te leveren aan een burger, bedrijf of andere organisatie.

Hier begint het proces (en dus niet bij de keten). Dit is het end-2-end proces (van klant tot klant).

Verhuren eenheden
Werkproces Een werkproces is een geordende reeks van processtappen die binnen één bedrijfsfunctie (wat samen kan vallen met een organisatorische eenheid) binnen een organisatie wordt uitgevoerd met als doel een specifieke bijdrage (prestatie) te leveren aan een dienst die uiteindelijk zal worden geleverd aan een burger, bedrijf of andere organisatie.

Werkprocessen hebben vaak een hoog herbruikbaar gehalte; denk aan Onderhouden Relatie

Aanbieden woning
Processtap Een geordende reeks handelingen die ononderbroken wordt uitgevoerd door één mens of machine.

Dit noemt men ook: eenheid van tijd, plaats en handelen; en komt in systeemontwerp overeen met een (basic) Use Case.

Uitnodigen gegadigden (prospects)
Handeling Kleinst mogelijke eenheid van werk, uitgevoerd door één persoon of machine. Controleren duur inschrijving


De procesarchitect onderkent de processen tot en met het werkproces; de procesontwerper specificeert werkprocessen minimaal tot processtappen en indien nodig tot en met de handelingen (werkinstructies).

Een grote valkuil binnen architectuur en procesontwerp is om in één plaatje te veel te willen vertellen: alle procesniveaus in een plaatje of een plaatje voor alle doelgroepen. Daarom wordt het begrip view geïntroduceerd; zie Figuur 5.5. Op basis van één model kunnen meerdere views gemaakt worden voor meerdere doelgroepen of betrokkenen (stakeholders). Ideaal is dat de plaatjes een balans hebben in aan de ene kant communiceerbaarheid (kan ik ze eenvoudig uitleggen) en aan de andere kant realiseerbaarheid (zijn ze ook daadwerkelijk te realiseren). Het gevaar van zogenaamde jip-en-janneke plaatjes is dat het wel communiceert, maar niet helpt bij het realiseren van iets.


Figuur 5: Verschillende views voor verschillende Stakeholders


Zo zal voor de bestuurder een overall view van de processen, zoals getoond in de processenatlas voldoende zijn. De controller daarentegen wil de processen verder uitgewerkt zien met rollen en functies (voor de functiescheiding). De IT-ontwerper zal de automatiseringsgraad van de processen willen zien en alle beslissingen waarop gerouteerd moet worden.

Patronen en best practices

Zaakgerichte procesarchitectuur

Binnen veel ontwerpdisciplines is het gebruik van patronen gebruikelijk. Een patroon is een vorm met bepaalde kenmerken, passend bij de eigenschappen van het op te lossen vraagstuk. Zo zijn binnen Vereniging Nederlandse Gemeenten (conform GEMMA) patronen op architectuurniveau onderkend voor bijvoorbeeld het leveren van producten en diensten. Aan dit patroon is ook het werken met zaaktypen gekoppeld. “Een zaak is een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een gedefinieerd resultaat, waarvan de kwaliteit en de doorlooptijd bewaakt moet worden”.

Zaken kunnen worden bestuurd, bewaakt en beheerd in een zaaksysteem. Belangrijke concepten die bij een zaak horen zijn:

  • Subject (wie doet wat; klant of medewerker);
  • In welke Rol;
  • De Zaak heeft betrekking op een (bestuurd) Object: Kavel, Woning, Bezwaar, Persoon, Installatie, enzovoort;
  • En bevindt zich in een bepaalde Status;
  • Soms gekoppeld aan een Besluit;
  • Met een (bijhorend) Document.

Zo worden alle aanvragen van klanten beheerd in een zaakdossier waarin op elk moment de status van de aanvraag wordt bijgehouden. De verwerking wordt uitgevoerd met applicaties.


Figuur 6: Patroon Verstrekken Product en Dienst (conform Gemma)


Voor de werkprocessen Intake, Behandelen, Besluiten en Leveren kunnen ook weer patronen worden onderkend. Uiteindelijke zien we de patronen op drie niveaus terug.

Niveau Domein Wat Voorbeeld
1 Architectuur

(ontwerp)

Archetype bedrijfsprocessen met zelfde ‘hoogover’ patroon werkprocessen Verstrekken Vergunning/ Subsidie

Voor beide geldt ‘hoogover’ eenzelfde procespatroon.

2 Proces

ontwerp

Uitwerking van die werkprocessen voor een bepaald bedrijfsproces. Dit levert het niveau tot en met processtappen Verstrekken Vergunning.

Met de uitgewerkte werkprocessen.

3 Zaaktype

ontwerp

De processtappen in het werkproces zijn - indien nodig - verder gespecificeerd voor een bepaald Zaaktype. Verstrekken Omgevingsvergunning Bouw.

De processtappen zijn waar nodig gespecificeerd met zaaktype specifieke zaken.


In een zaaksysteem kunnen de documenten worden opgenomen die bij het behandelen van zo’n zaak horen. Dat hoeft echter niet. Het kan ook een apart Document Management Systeem (de min of meer ongestructureerde documenten) en/ of een Record Management Systeem zijn (gestructureerde documenten). Of vanuit het verleden pratend: de dossiermap. Een zaak heeft altijd een zaakcoördinator. Deze bestuurt en bewaakt het proces (van klant tot klant). In een echte procesgeoriënteerde organisatie bepaalt de proceseigenaar zowel hoe het proces eruit ziet (ontwikkeling en implementatie) als de aansturing van het proces met mensen en middelen. De proceseigenaar is dan dus verantwoordelijk voor de opzet, de implementatie, de werking en het resultaat van het proces.

In Focusgebied 'Zaakgericht werken' wordt het zaakgericht werken (met zaaktypes) verder toegelicht en uitgewerkt.


Straight Through Processing (STP)

Administratieve fabrieken als verzekeraars en banken hebben veel zaken die volledig geautomatiseerd (straight through processing — STP) afgehandeld kunnen worden. Dat is nodig bij grote volumes. In sommige gevallen (noodzakelijke gegevens blijken niet aanwezig, bij bepaalde risico’s is altijd een menselijke beslissing noodzakelijk) kunnen zaken ‘uitvallen’ en wordt door een medeweker ingegrepen.


Figuur 7: Multi Chanel - Single Proces


In bovenstaande figuur is dit schematisch weergegeven. Een brief, een webform of een telefoontje komt binnen (bij inputmanagement). Daar wordt een ‘foto’ gemaakt voor opslag in een digitaal archief (bewijs van input). Het bericht wordt zoveel mogelijk elektronisch verwerkbaar gemaakt (digitaliseren) en aangeboden aan een besturingslaag; dan wordt ook een elektronisch zaakdossier aangemaakt. Het medium is van de input afgehaald. Hierdoor kan er één mediumvrij onafhankelijk proces gaan lopen (single process). De besturingslaag roept verschillende geautomatiseerde applicatiefuncties aan. In geval van ‘uitval’ wordt de zaak als work(flow)item gezet en neemt een medewerker het over. In geval van contact met de klant of derden wordt het dossier bijgewerkt. Daarna wordt het weer aan de besturingslaag aangeboden en outputmanagement zorgt voor het mediumrijk maken van de communicatie met de klant; in de vorm van een brief of e-mail of anders (dit is weer ‘multi- channel’). Ook daar wordt weer een ‘foto’ van vastgelegd.

Alhoewel de meeste processen bij woningcorporaties niet echt STP zijn (denk aan dagelijks onderhoud, verhuren woning, enzovoort), is het verstandig om voor de meer administratieve processen (verwerken betalingen, verwerken aanmeldingen bezichtigingen) deze patronen en architectuurdomeinen wel te onderkennen en te hanteren.

Besturen, verantwoorden en risicobeheersing

Procesgericht werken, maar eigenlijk elke organisatieverandering, begint met de vraag waarop en hoe wil je sturing geven aan de organisatie en haar resultaten. Aandacht voor de besturing (‘governance’) van woningcorporaties, staat - meer dan ooit - in de belangstelling. Het is de kunst om processen de kapstok te laten zijn; hierop te meten en te sturen, zo transparant mogelijk.

De besturing van een bedrijf (corporate governance) is de verantwoordelijkheid en de activiteit van het ondernemingsbestuur en het management, en heeft tot doel :

  • Strategische richting te geven aan het functioneren en de ontwikkeling van de organisatie;
  • Zeker te stellen dat de gewenste doelen worden bereikt;
  • Dat de risico’s afdoende worden beperkt;
  • Dat de middelen van de onderneming op een verantwoorde manier worden ingezet.


Het besturen (en verantwoorden) zal op verschillende niveaus moeten worden ingevuld: op strategisch, tactisch en operationeel niveau. Dit wordt in de besturingspiramide tot uitdrukking gebracht.


Figuur 8: Besturingspyramide


De scheiding tussen strategische en tactische en operationele sturing is gangbaar. Hier is nog een vierde laag toegevoegd: uitvoering. Operationeel is nog steeds aansturing (denk aan dagelijkse of wekelijkse werkorder planning) en uitvoering is de daadwerkelijke uitvoering. In tabel 5.3 is bij wijze van voorbeeld voor een woningcorporatie aangegeven waar op gestuurd kan worden: Succes Factoren (SF) met mogelijke prestatie-indicatoren (PI) voor de verschillende besturingsniveaus.

Niveau Succes Factoren (SF) Prestatie-indicatoren (PI)
Strategisch • Mate van samenwerking met ketenpartners


• Verhouding huur / koop

• Verhouding verhuur DAEB/Niet DAEB

• HRM-beleid

• Innovatie woonconcepten

• Investeringskeuzes nieuwbouw en renovatie

• Financieringsstrategie vastgoed

• Milieu: CO2 uitstoot huurhuizen


• Gebruik duurzame bouwmaterialen

• Verdeling huurbestand over sociale klassen

• Aantal omzettingen huur naar koop


Tactisch • Mantelcontracten met projectontwikkelaars, onderhoudsbedrijven


• Onderhoudscontracten met aannemers en installateurs

• Samenstelling personeel en professionalisering


• Onderhoudskosten per woning


• Exploitatiekosten per woning

• Mutatiegraad

• Leegstand

• Staat van onderhoud woningvoorraad

• Rentekosten op vreemd vermogen

• Mate voldoen aan mantel overeenkomsten

• Budgetuitputting ontwikkeling nieuwbouw

Operationeel • Besturing onderhoudsopdrachten en ontwikkelopdrachten


• Inzet van eigen mensen

• Signalering noodzakelijk onderhoud

• Signalering milieumeldingen

• Doorlooptijd serviceverzoeken


• Doorlooptijd mutatie-onderhoud

• Bestedingen onderhoud

• Rechtmatigheid toewijzing woningen



Het kunnen werken met een dergelijke besturingspiramide stelt ook bijzondere eisen aan de informatievoorziening. Business Intelligence (genereren management informatie) is het vakgebied van het verzamelen en bewerken van data om goed te kunnen sturen, met management rapportages en dashboards. Het betreft zowel productdata (bijvoorbeeld aantal en type klachten; cartotheek van het bezit) als procesdata (bijvoorbeeld doorlooptijd proces)[1].

Processen worden zo ingericht dat ook de risico’s kunnen worden beheerst. Het gaat daarbij om risico’s op alle niveaus van de processen: zowel beslissingen op investeringsniveau (strategisch) als het declareren van bonnetjes (uitvoerend). Of dat goed werkt, heeft voor een groot deel te maken met de cultuur binnen het bedrijf, maar kan ook in zekere mate geformaliseerd en afgedwongen worden: controle bij aanvang van het proces (met een ‘slot’) en achteraf (met een ‘camera’). Risicobeheersing bestaat uit het analyseren van risico’s (impact x kans) en het bepalen van maatregelen (key controls): bijvoorbeeld vier-ogen of zelfs zes-ogen functiescheiding; controle op dubbel invoeren enzovoorts

Ontwerpen van processen

Op basis van de proces-architectuur wordt het procesontwerp nader uitgewerkt. Het ontwerpen van processen is een echte vakdiscipline. Eigenlijk bestaan er geen eenvoudige processen. Een schets met een paar blokjes met wat pijltjes ertussen volstaat in ieder geval niet. Hieronder staat een pragmatische aanpak om processen tot op procesontwerp niveau goed te beschrijven.

1. De dienst De te leveren dienst is het verstrekpunt, niet het proces. Dat is namelijk het ‘hoe’. Start met het identificeren en het specificeren van de te leveren dienst (het ‘wat’). Processen realiseren diensten!

Het specificeren van de dienst kan met behulp van een sjabloon voor de betreffende dienst (bijvoorbeeld ‘verhuur woning’) in te vullen.

2. De eisen (requirements) Vervolgens worden de eisen (requirements) voor de dienst geformaliseerd. Ga bij binnen de organisatie langs en haal een lijst op van 10-20 eisen. “De woning mag pas verhuurd worden als de deze is vrijgegeven door…”; “De doorlooptijd van aanmelding tot contract is … weken…”; “De verhuurder moet…”
3. Het proces (her)ontwerp Werk de werkprocessen uit tot en met processtap niveau (eventueel handelingsniveau). Koppel hieraan de rollen. De werkprocessen moeten verwijzen naar de werkprocessen zoals deze zijn onderkend in de (proces)architectuur (patronen).

Beschrijf de noodzakelijke informatie (input) om de processtap goed te kunnen uitvoeren en het resultaat (output) van de stap. Zorg voor een simpel procesontwerp. Voorkom combinaties van beslissingen (‘wiebertjes’) maar zet deze in een (beslissings)processtap met daaronder een beslissingstabel. Management en medewerkers kunnen goed omgaan met beslissingstabellen. Gebruik LEAN en andere proceshygiëne bevorderende methodieken om een goed ontwerp te krijgen; bijvoorbeeld fout-, escalatie- en interuptafhandeling in aparte views onderbrengen om de hoofd of happy flow views niet te ingewikkeld te maken. Alle eisen (requirements) moeten ‘traceerbaar’ zijn naar de elementen in het procesmodel; Stel het procesontwerp het liefst op in BPMN.

4. De communicatie uitingen Koppel de communicatie uitingen (verklaring, terugmeldingen, etc.) uit de dienstbeschrijving aan de processen.
5. De administratieve organisatie (AO) Maak relatietabellen tussen de onderkende rollen per processtap en (personele) functies en specificeer deze verder met zaken als procuratie en andere eigenschappen van het bestuurde object in het proces.
6. De interne controle (IC) Maak op het niveau van werkproces een beschrijving van de risico’s, de inschatting en de maatregelen.

Geef helder aan waar de maatregelen in het proces zitten.


Voorbeeld

Om een idee te krijgen hoe een procesontwerp er uit kan zien, staat hieronder in figuur 5.9 en figuur 5.10 een voorbeeld van een declaratieproces. De procesarchitect heeft vijf werkprocessen onderkend voor het bedrijfsproces (in ArchiMate). De procesontwerper heeft vervolgens het werkproces ‘Verwerken Declaratie’ verder uitgewerkt (in BPMN).


Figuur 9: Bedrijfsproces Afhandelen Declaratie



Figuur 10: Werkproces Verwerken Declaratie (Happy Flow')


Voor het werkproces is alleen de view gegeven voor de zogenaamde ‘happy flow’, zonder uitval en afkeuringen en ook zonder escalaties, bijvoorbeeld op overschrijdingen van de doorlooptijd.


Technieken, methodieken en tooling=

Technieken

De afgelopen 10 jaar zijn er enorme stappen gemaakt op het gebied van methodieken, technieken en gereedschappen als het gaat om ontwerp en inrichting van processen. Eindelijk hebben we een open standaard, een specificatietaal, om processen mee te beschrijven: de open standaard BPMN®, inmiddels met versie 2.0. In figuur 5.10 is al een voorbeeld van gegeven.

Voor het beschrijven van architectuur is de ontwerptaal ArchiMate® beschikbaar. Aangezien het procesontwerp rust op het fundament van architectuur is het belangrijk dat er een verwijzing tussen deze twee ontwerpdomeinen kan worden gelegd. Als men voor systeemontwerp nog een slagje dieper moet ontwerpen, dan stapt men over op de ontwerptaal UML®.

In figuur 5.11 is aangegeven hoe de verschillende ontwerpdomeinen zich tot elkaar verhouden. De genoemde specificatietalen waarin processen worden gedefinieerd, zijn open standaarden.


Figuur 11: Drie ontwerpdomeinen met hun eigen specificatietalen


Methodieken

Op het gebied van procesverbetering hebben methodieken als LEAN (al dan niet in combinatie met Six Sigma) al lang geleden hun intrede gedaan en veel opgeleverd.

In Nederland is Prince2 als methodiek voor projectmanagement vrij algemeen geaccepteerd. In de projectuitvoering wordt bij projecten met een belangrijke informatiecomponent steeds vaker agile gewerkt (bijvoorbeeld volgens SCRUM). Kenmerkend aan een SCRUM-aanpak is dat alle projectleden ‘dicht op elkaar’ het project uitvoeren. De relatie met Prince2 als projectmanagement methodiek is dan als volgt: besturing van het project; alsmede start, initiatie en afsluiting vinden plaats conform Prince2; de uitvoering van de verschillende in het project onderkende brokstukken volgens SCRUM.


Tooling

Er zijn steeds meer relatief goedkope tools die de boven genoemde specificatietalen goed ondersteunen. Belangrijk is een tool te kiezen die alle standaarden ondersteunt en die werkt met een bibliotheek waarin de elementen kunnen worden opgeslagen.

BPM is geen technisch ding; het gaat over een manier van ontwerpen, gebruik van standaarden, de invulling van de loop om processen beter te maken en inderdaad ook een technische ondersteuning door zoiets als een BPM-Suite.


Informatievoorziening

Elke stap in het proces creëert (of zou dat moeten doen) meerwaarde. Die meerwaarde is bijvoorbeeld het realiseren van een ‘mooi gerenoveerde woning’. Daarnaast wordt meerwaarde in een proces ook meestal administratief vastgelegd via informatieverwerking. De processen worden ondersteund door het beschikbaar zijn van informatiefuncties om de informatieverwerking mogelijk te maken. Informatiefuncties worden ingevuld door IT-applicaties. In een moderne applicatieomgeving worden deze informatiefuncties ingevuld door applicatieservices; applicatieservices worden gebruikt ter ondersteuning van de procesuitvoering.

Als applicatieservices aangeroepen moeten kunnen worden door andere applicaties dan is een expliciete (gepubliceerde) applicatieservice interface noodzakelijk. Deze kan dan ook in andere processen worden aangeroepen. In subparagraaf 5.1.5 ‘Architectuurconcepten voor processen en informatievoorziening’ staat een architectuurview waarin verschillende elementen rondom services, processen en applicaties aan elkaar geknoopt zijn. De berichten kunnen via een zogenaamde Enterprise Service Bus lopen, die een aantal (infrastructurele) informatiefuncties voor haar rekening neemt: autorisatie, transformatie van gegevens, routering, logging en dergelijke. Een Service Oriented Architecture (SOA-benadering) werkt prima samen met BPM.

Het is belangrijk op te merken dat in analogie met BPM, SOA geen technisch begrip is. SOA is een architectuurstijl en gaat over manier van ontwerpen, het gebruik van standaarden en afspraken voor de inrichting van een gebied (architectuurdomein), bijvoorbeeld de IT-infrastructuur, maar ook een Shared Service Center voor administratieve verwerking.

Ontwikkelbenadering

Het veranderen van processen gaat altijd gepaard met een verandering voor de betrokken medewerkers. Dat geldt zowel voor de man of vrouw op de werkvloer als voor het management. Of het nu taken zijn die anders uitgevoerd moeten worden, taakverbreding of juist taakverenging, een andere manier van omgaan met de klantcontacten —medewerkers voelen en merken de verandering. De ervaring leert dat procesverbetering niet een kwestie is van éénmalig een slag maken. Of dat nu is om klantgerichter te werken of een interne verbetering door te voeren, dit soort veranderingen vraagt om een permanent andere houding en gedrag van iedereen binnen de organisatie. Niet het proces eenmalig anders inrichten en uitvoeren, maar een besef dat procesverbetering en klantgerichtheid continu onderdeel is van alle dagelijkse werkzaamheden binnen de organisatie. Hoe stuur je zo’n verandering? Hoe bepaal je nu wat nodig is voor de eigen organisatie om de gewenste ontwikkeling in te zetten?


Procesvolwassenheid

Een goed beeld hebben van de mate van procesgerichtheid van de huidige organisatie en van de gewenste organisatie is een eerste stap. Dit helpt om inzicht te krijgen in de ambitie en mogelijkheden (streven we naar hetzelfde) en een gedeelde overtuiging van de bijbehorende veranderaanpak. In onderstaand Procesgericht Organiseren Maturity (POM) model wordt de essentie van de verschillende volwassenheidsniveaus beschreven (zie ook ref. 6).


Figuur 12: Proces Maturity


Een dergelijk model helpt een beeld te krijgen van de organisatie (huidig en gewenst), een gedachte-uitwisseling op gang te brengen en verbetermogelijkheden te identificeren. Hierbij wordt o.a. gekeken naar:

  • In welke mate heeft de organisatie inzicht in haar processen en wordt ze daarop gestuurd?
  • Hoe sterk is de focus op toegevoegde waarde voor de klant?
  • Is de organisatie ingericht op basis van processen?
  • (Hoe) is proceseigenaarschap belegd? Proceseigenaarschap – met name over bedrijfs-onderdelen heen - is een lastig fenomeen, dit wordt verder op uitgelegd.
  • Zijn processen leidend voor de inrichting van de IT-voorzieningen?

Voor elk niveau worden praktische handvatten gegeven om stappen richting het gewenste niveau te zetten of om nog steviger in het bestaande niveau te zitten. Om bijvoorbeeld van niveau 2 ‘structurerend’ naar niveau 3 ‘borgend’ te komen, is de uitdaging om van een projectmatige en afdelingsgerichte benadering van procesverbetering te groeien naar een situatie waarin bij het denken in en werken aan processen steevast de behoefte van de verschillende betrokkenen (in eerste instantie de klant, maar ook andere partijen als toezichthouders, aandeelhouders, leveranciers) als uitgangspunt genomen wordt. Maar ook de behoefte van medewerkers en managers werkt hierin door.

Procesgericht werken betekent dat medewerkers en managers zich bewust moeten zijn dat dit niet alleen de uitvoering van het werk verandert, maar ook de manier waarop je met je werk omgaat. Ruimte voor het bedenken, delen en implementeren van nieuwe ideeën om beter in de behoefte van de klant te voorzien moet gestimuleerd worden. Dit wordt met een mooi woord ook wel ‘empowerment’ genoemd. Extreem doorgedacht kun je zeggen: het management bepaalt niet meer wat goed is voor de organisatie, de medewerker bedenkt wat goed is voor de klant (en daarmee de organisatie). Processen worden niet beschreven om te dicteren, maar juist om de medewerker zelfstandig in staat te stellen de juiste acties, afwegingen en handelingen te kunnen laten nemen met een goed begrip van het gehele klant-tot-klant proces (zie ook ref. 9).

Gezien de ontwikkeling in de sector zou voor woningcorporaties een streven gezet kunnen worden om binnen een jaar op minimaal niveau 2 te komen en dan binnen twee a drie jaar door te groeien naar niveau 4. Om dit te realiseren zou dan een gericht stappenplan uitgewerkt moeten worden. Aangezien dit woningcorporatie specifiek is, wordt een dergelijk stappenplan hier niet uitgewerkt.


Strategische keuzes

Het hoger management van een woningcorporatie zal veel strategische keuzes moeten maken: Waar leggen we het accent bij komende veranderingen? Wat is nodig en haalbaar ‘to stay in the game’ of zelfs ‘to win the game’? Treacy en Wiersema (zie ref. 10) hebben hier een denkmodel voor aangereikt, hieronder in een aangepaste vorm gepresenteerd. Een organisatie kan zijn focus leggen op

  • Producten (product leadership);
  • Klant (customer intimacy);
  • Bedrijfsproces (operational excellence);
  • Of combinaties van hiervan.


Figuur 13: Klant - Proces - Product

EFFE TOT HIER GEKOMEN



Logo CORA.jpg
  1. Een nieuwe ontwikkeling is het verzamelen van allerlei data (“big data”) rondom social media (twitterberichten over een woningcorporatie) om hierop adequaat te kunnen reageren.