Op weg naar een stabiele dienstverlening

(1)

Plaats, Datum Auteur

Best, 25 mei 2012 André Heyms

Project Procesverbetering DM

Op weg naar een stabiele dienstverlening

(2)

Versie, Datum 1.0, 04 juni 2012

Projectnaam Procesverbetering DM

Document type Afstudeerscriptie

Auteur André Heyms

Opleiding ICT & Business

Fontys Hogescholen ICT te Eindhoven Minor ICT Management & Security

Studentnummer 2120499

PCN nummer 199544

Afstudeerorganisatie Rabobank Nederland

Afdeling Document Management (Groep ICT/ Beheer & Exploitatie)

Adres De Maas 11

5684 PL Best

Begeleider Johan Bom

Functie Kwaliteitscoördinator

Docentbegeleider Rob van Stratum

Periode 06-02-2012 t/m 06-07-2012

Voor gezien door bedrijfsbegeleider: Datum:

____________________________________

© Rabobank Nederland, 2012

Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie of op welke andere wijze dan daaronder mede begrepen gehele of gedeeltelijke bewerking van het werk, zonde r voorafgaande toestemming van Rabobank Nederland.

No part of this publication may be reproduced in any form by print, photo print, microfilm or any other means without written permission by Rabobank Nederland.

(3)

Voorwoord

6 februari 2012 ben ik gestart met mijn afstudeeropdracht bij Rabobank Nederland. De maanden zijn echt voorbij gevolgen aangezien ik nu al het laatste hoofdstuk typ. Ik ben de afstudeerstage gestart vanuit mijn opleiding Bedrijfskundige Informatica die ik aan de Fontys Hogescholen te Eindhoven volg. De afstudeerstage heeft plaats gevonden binnen Rabobank Nederland en dan specifiek binnen de afdeling Document Management die in Best gevestigd is. Binnen deze afdeling worden grote

pakketten documenten verwerkt waarbinnen het opmaken en verzenden van allerlei klantgerichte correspondentie centraal staat.

Aangezien de dienstverlening meer en meer naar de digitale kant verschuift ontstaan er steeds meer fouten. Dit komt doordat een fysiek document gemakkelijker te controleren is dan bijvoorbeeld een digitale e-mail die automatisch verzonden wordt. Mijn afstudeeropdracht is gericht op het onderzoeken van deze digitale omgeving en uiteindelijk een advies te leveren waarin de risico’s inzichtelijk zijn en aanbevelingen gedaan worden om de dienstverlening minder foutgevoelig en stabieler te maken. Ik heb voor de organisatie Rabobank gekozen aangezien dit me een interessante organisatie leek en ik graag binnen een grote organisatie wilde afstuderen. Dit laatste omdat er veel mogelijkheden liggen in een grote organisatie en ik graag eens wilde meemaken hoe een opdracht in een grote complexe organisatie als deze verloopt. De opdracht zelf leek me daarnaast ook zeer goed aan te sluiten bij de Bedrijfskundige Informatica opleiding aangezien ik het interessant vind om processen in kaart te brengen en hier vervolgens verbetervoorstellen voor aan te dragen.

Ik wil deze gelegenheid ook graag gebruiken om de nodige betrokkenen te bedanken. Allereerst wil ik Johan Bom mijn bedrijfsbegeleider vanuit Rabobank Nederland bedanken voor zijn uitstekende begeleiding en de tijd die hij voor mij vrij heeft gemaakt. Ook wil ik Rob van Stratum als mijn docentbegeleider van uit Fontys Hogescholen bedanken voor de goede begeleiding, feedback en de altijd snelle reacties. Tevens wil ik alle medewerkers die bij het project betrokken waren bedanken voor hun tijd en inzet, zonder hun zouden deze resultaten nooit behaald zijn. Als laatste wil ik mijn vriendin bedanken voor de steun en het reviewen van mijn scriptie.

André Heyms Best, juni 2012

(4)

Inhoudsopgave

Samenvatting 4 Summary 5 Verklarende woordenlijst 6 1. Inleiding 8 2. Het bedrijf 9 2.1 Rabobank 9 2.2 Geschiedenis 10 2.3 Vestigingen 10 3. De opdracht 11 3.1 Beginsituatie 11 3.2 Doelstelling 12 3.3 Voordelen 12 3.4 De opdracht 12 3.5 Uitvoering 14 3.6 Wijzigingen 15 4. Huidige situatie 16 4.1 Aanpak 16 4.2 Uitwerkingen 16 4.3 Bevindingen 18 4.4 Volwassenheid 19 5. Procesanalyse 20 5.1 Aanpak 20 5.2 Uitwerking 21 6. Gewenste situatie 24 6.1 Volwassenheid 24 6.2 Verbeteringen 25 7. Oplossingen 26 7.1 Aanpak 26 7.2 De oplossingen 26 8. Logging en monitoring 28 8.1 Requirements 28 8.2 Logging architectuur 28

8.3 Logging per stap 29

8.4 Integriteit logging 30 8.5 Alternatieven 30 9. Advies en implementatie 31 10. Conclusies en aanbevelingen 34 Evaluatie 35 Literatuurlijst 36 Bijlagen 38

(5)

4

Op weg naar een stabiele dienstverlening

Samenvatting

De auteur van dit document, afstudeerder André Heyms heeft vanuit zijn opleiding Bedrijfskundige Informatica aan Fontys Hogescholen Eindhoven zijn afstudeeropdracht binnen Rabobank Nederland uitgevoerd. De afstudeerstage heeft plaats gevonden binnen de afdeling Document Management van Rabobank Nederland. Deze afdeling heeft eigen klanten binnen Rabobank en levert diensten op het gebied van opmaken, verzenden, archiveren en digitaliseren van documenten.

Klanten kunnen binnen de dienstverlening grote bestanden met data aanleveren die vervolgens binnen de afdeling opgemaakt en verzonden worden via post, e-mail en fax. Ook is het mogelijk deze

documenten te archiveren. De afgelopen tijd ziet de afdeling een groei van de digitale dienstverlening, zoals e-mail en archieven. Echter is de controle hierop veel lastiger dan bij een fysiek document. Doordat deze controle veel lastiger is, ontstaan er de laatste tijd veel fouten waardoor Service Level Agreements (SLA’s) met klanten niet behaald worden. De taak van de afstudeerder was om de risico’s inzichtelijk te maken, vervolgens te kijken hoe fouten voorkomen kunnen worden en als zich deze toch voordoen deze te detecteren.

Allereerst is de afstudeerder gestart met het in kaart brengen van de huidige situatie, om te achterhalen hoe deze situatie verloopt en te achterhalen waar knelpunten zitten. Vervolgens is een procesanalyse uitgevoerd m.b.v. de methode Process Failure Mode and Effect Analysis (PFMEA), waarbij per processtap de risico’s in kaart gebracht werden. Wat speciaal is aan deze methode is dat de risico’s niet alleen op ernst en kans beoordeeld worden maar ook op de kans op detectie hiervan. De procesanalyse is daarnaast vooral in groepssessies uitgewerkt om risico’s vanuit verschillende invalshoeken op te nemen. Tevens is er per risico besloten of er acties gewenst waren en indien deze gewenst waren zijn deze opgesteld.

Nadat de risico’s en knelpunten helder waren, is een gewenste situatie geschetst waarin een verbeteringsslag is toegepast, met onder andere een monitoringsysteem waardoor het proces inzichtelijk wordt. Om deze gewenste situatie te behalen zijn er oplossingen inclusief alternatieven opgesteld en zijn deze beoordeeld met voor- en nadelen. Vervolgens zijn in een advies de meest geschikte oplossingen gekozen en is op basis van deze oplossingen een implementatieplan opgesteld. Alle onderdelen zijn iedere twee weken teruggekoppeld aan de betrokken om op een zelfde lijn te blijven.

Als conclusie is naar voren gekomen dat er totaal geen inzicht in het proces is waardoor het niet mogelijk is fouten zelf te detecteren en of goed onderzoek te kunnen doen na opgetreden incidenten. Een aanbeveling is dan ook om als eerste controle te krijgen over het proces door logging en

monitoring van het systeem in te richten waarbij het gehele proces inzichtelijk wordt gemaakt. Naast deze bevinding is naar voren gekomen dat klanten niet volgens een standaard wijze data aanleveren maar allemaal hun eigen formaat en structuur hanteren die vervolgens binnen de afdeling omgezet moet worden naar het strandaard formaat. Daarnaast valt het op dat het pakket wat bedoelt is voor het opmaken van de documenten ook gebruikt wordt voor hele andere zaken, zoals het omzetten van deze verschillende formaten en structuren. De aanbevelingen hierbij zijn dan ook om de structuren terug te dringen door bijvoorbeeld verschillende tarieven te hanteren en een speciale omgeving op te zetten die onder andere de omzetting van de formaten en structuren verzorgt, zodat het opmaak pakket alleen gebruikt wordt waarvoor deze bedoelt is.

Na het doorvoeren van de aanbevelingen is er inzicht mogelijk in het proces, zal de complexiteit van het systeem afnemen, een strakkere controle toegepast worden, zal testen meer fouten afvangen, zal de documentatie weer bruikbaar zijn en zullen de gevonden risico’s verkleind zijn. Hierdoor zal de dienstverlening stabieler worden en zal het aantal fouten met impact op de klant afnemen.

(6)

5 Summary

The student André Heyms completed his internship at Rabobank Nederland for his study Business & ICT at Fontys University of Applied Sciences Eindhoven. The internship is performed at the

Document Management department of Rabobank Nederland which is located in Best. Rabobank delivers financial services and Rabobank Nederland offers support to this organization. So also the Document Management department offers support to this organization and provides services in the field of formatting, sending, archiving and digitalization of documents.

Customers deliver large data files to this Document Management department. The data is formatted within this department and is sent by post, e-mail, fax and/or will be archived. Currently, there has been a shift from the physical output to the digital output and this transition causes errors. This is due to the fact that controlling the physical output is a lot easier than controlling the digital output which is processed automatically. Due to these errors, the Service Level Agreements (SLA) with the customers are not always achieved. The assignment of the student has been to investigate all important risks in the process, think trough solutions of how these risks can be avoided and if the risks might occur how they can be detected.

First, the current situation has been mapped to get insight in the current process and potential

bottlenecks. Second, a process analysis had been performed to map all important risks in the process. This is done with the method Process Failure Mode and Effect Analysis (PFMEA), which aims to identify all risks per part of the process. Where other methods only assess the risks on impact and frequency, this method assesses on detection too. To get the best results and to be able to map the risks from different perspectives, the analysis is performed in group sessions. Per risk it was determined if action was required and if so what kind of action was needed.

Next, a desired situation had been pictured to scale or remove the important risks or to eliminate the bottlenecks. For example as point of improvement, the process is monitored so the department has a clear insight into the process. To make this desired situation reality, solutions are developed to eliminate the bottlenecks and scale the risks. The solutions were prepared with alternatives and of course with pros and cons to make the best decision. The best alternatives are included in an advise for the department. Also an implementation plan is created to implement these solutions. All parts of the graduation paper are discussed with the project team every two weeks to make sure the whole team was on the same wavelength.

The conclusion of the research is that there is no insight into the process, so it is not clear what exactly happens in the process. Also, is it difficult to do research after incidents, because there is no

information available. To make this all possible it is advised to implement a monitoring system to monitors the whole process. This system will provide a clear insight into the process, so the process can be managed. Another problem is the variation of delivering formats and structures. Almost every customer delivers the data in his own format and structure. So Document Management must convert all this data to a standard format. This all is done in the formatting software while this software is not suitable to do this type of processing. To solve this problems the advice is to split this proceedings and place the convert tasks to a special environment. So the formatting software is only used for the referred tasks and will be much less complex than before.

After implementing the solutions it is possible to have clear insight into the process and the complexity of the process will decrease. Also there are tighter controls, the tests will catch more errors, the documentation is usable again and the risks are reduced. So the service of Document Management will be more stable and fewer mistakes will be made.

(7)

6 Verklarende woordenlijst

In dit hoofdstuk worden alle begrippen, afkortingen, afdelingen of andere woorden waarbij een verklaring gewenst is omschreven.

Begrip/ woord Afkorting Verklaring

Beheer & Exploitatie B&E Afdeling binnen Groep ICT, waar de afdeling Document Management onder valt.

Cliënt - De (eind)klant van lokale banken.

Coöperatie - Vennootschap vorm, waarbij een groep samenwerkt en de bedrijfsactiviteiten aansluiten bij de belangen van de leden.

Data Flow Diagram DFD Tekentechniek om processtromen in kaart te brengen.

Document - Losstaand opgemaakt document, bijvoorbeeld een brief.

Document Management DM Afdeling binnen B&E waar de afstudeerstage heeft plaatsgevonden.

Document Management XML DMX Interne extensie die gebruikt wordt in het software pakket PrintNet voor leveringen.

Document Management XML – statistieken

DMX-stat Bestand waarin tellingen, tijden en andere gegevens

van leveringen, documenten en recepten zijn opgenomen voor de doorbelasting en rapportages richting de klant.

Extensible Markup Language XML Een standaard structuur om gegevens op te slaan en uit te wisselen tussen verschillende systemen en bedrijven.

Groep ICT Afdeling binnen Rabobank Nederland

Juistheid - SLA begrip waarin vast gesteld wordt hoeveel procent er juist verwerkt dient te worden. Waarbij het gaat om de juiste informatie, afbeeldingen en bijlagen maar ook dat het juiste document bij de juiste cliënt terecht komt.

Klant/ opdrachtgever - De klanten van Document Management. Dit kunnen lokale banken zijn, maar ook onderdelen van Rabobank Nederland.

Outputkanaal - Kanaal vanuit waar documenten verzonden worden naar Cliënten, dit kan dus bijvoorbeeld een e-mail omgeving zijn.

Printbare Bijlagen - Documenten die aan producten toegevoegd kunnen worden, bijvoorbeeld standaard voorwaarden bij een offerte.

PrintManager - Eigen programmatuur voor het opmaken van

documenten. Dit is de oude Mainframe omgeving en zal uit gefaseerd worden.

PrintNet - Software pakket van GMC, geleverd door Océ waarin documenten opgemaakt worden. Dit is een Windows omgeving.

Process Failure Mode and Effect Analysis

PFMEA Methode die gebruikt wordt om het proces te

analyseren en de risico’s in kaart te brengen. Binnen de methode staan ernst, kans en detectie centraal.

Product - Verzameling van documenten die bij elkaar behoren en bestemd zijn voor één cliënt, bijvoorbeeld een offerte met een begeleidende brief en de voorwaarden.

(8)

7

Quick Wins - Verbeteringen die veel opleveren en weinig inspanning kosten om in te voeren.

Rabobank Groep - Internationale financiële dienstverlener en verzameling van onder anderen Lokale Rabobanken, Rabobank Nederland, Rabobank Internationaal en

dochterondernemingen.

Rabobank Nederland - Centrale organisatie die in dienst staat van de lokale Rabobanken, de groepsonderdelen en tevens onderdeel van Rabobank Groep.

Recept - Document die specifiek voor een outputkanaal bedoelt is, dus een document die bestemd is voor bijvoorbeeld e-mail.

Resources - Bijvoorbeeld afbeeldingen, handtekeningen, lettertypes, etc. die aan documenten toegevoegd kunnen worden.

Service Level Agrement SLA Contract met een klant waarin afspraken over een dienst vastgelegd zijn.

Service Levels SL Afspraken die vastgelegd zijn in SLA’s met klanten.

Stuurinformatie - Informatie over documenten, zoals meta data, het recept, etc. om als stuurinformatie te dienen voor de vervolg stappen in het proces.

Tijdigheid - SLA begrip waarin vast gesteld wordt hoeveel procent tijdig verwerkt dient te worden. Waarbij het gaat om het volgens afspraak op tijd uitleveren van

documenten.

TNO - Interne extensie die gebruikt wordt in het software

pakket PrintNet voor opgemaakte documenten.

Volledigheid - SLA begrip waarin vast gesteld wordt hoeveel procent volledig verwerkt dient te worden. Waarbij het gaat om de volledigheid van de levering en de volledigheid van alle documenten.

Workarounds - Omzeiling van een beperking of probleem in een systeem.

(9)

8 1. Inleiding

Waarom zijn er zoveel incidenten in onze dienstverlening? Dat is de vraag die binnen de afdeling Document Management veel mensen bezig houd. Dit omdat er veel grote incidenten plaats hebben gevonden in de afgelopen jaren welke voor de nodige problemen hebben gezorgd. Er zijn verschillende kleine onderzoeken gestart om te kijken waar de oorzaak ligt en om hier oplossingen voor te zoeken. Echter zijn deze onderzoeken vaak vroegtijdig gestaakt i.v.m. urgentie van andere zaken en het tijdgebrek van de medewerkers. Om nu toch boven tafel te krijgen waar de grote problemen en risico’s zitten en hoe deze verholpen kunnen worden is een afstudeerder aangetrokken.

Het probleem binnen de organisatie is dat er veel fouten ontstaan en deze vaak niet ontdekt worden. Daarnaast ontdekken klanten vaak deze fouten en niet de afdeling zelf. Het onderzoek van de afstudeerder richt zich dan ook op waar deze fouten door ontstaan, waar de risico’s in het proces liggen en hoe fouten gedetecteerd kunnen worden.

Afdeling Document Management is een onderdeel van Rabobank Nederland. Rabobank Nederland is de ondersteunende dienstverlener aan alle lokale Rabobanken die bij iedereen bekent zijn. Afdeling Document Management is vooral gericht op het verwerken van

documenten, zoals het opmaken en printen van documenten. De verwerkingen worden steeds vaker digitaal afgehandeld, zoals verzending via e-mail. Het onderzoek richt zich dan ook op deze digitale verwerking.

In dit afstudeerverslag is de gehele aanpak van de afstudeerder en de resultaten van het onderzoek opgenomen. Hieronder een overzicht hoe het verslag is opgebouwd.

Hoofdstuk 2: Algemene informatie over de organisatie en de afdeling.

Hoofdstuk 3: Uitgebreide omschrijving van de afgebakende opdracht.

Hoofdstuk 4: Uitgewerkte huidige situatie, waarin duidelijk wordt hoe het

onderzochte proces verloopt en waar zich knelpunten bevinden.

Hoofdstuk 5: Uitgewerkte procesanalyse, waarin de risico’s van het proces naar

voren komen en welke acties hier ondernomen dienen te worden.

Hoofdstuk 6: Geschetste gewenste situatie van het proces.

Hoofdstuk 7: Geformuleerde oplossingen en bijbehorende alternatieven.

Hoofdstuk 8: Verdere toelichting over de specifieke oplossing logging &

monitoring.

Hoofdstuk 9: Toelichting over het advies en het implementatieplan.

Hoofdstuk 10: Conclusies en aanbevelingen.

In de bijlagen is het Project Initiation Documentopgenomen, de checklists vanuit het Tien

(10)

9 2. Het bedrijf

In dit hoofdstuk wordt de afstudeerorganisatie behandeld. Hierbij komt aan bod hoe de organisatie is opgebouwd, daarnaast wordt de afdeling waar de afstudeerstage heeft plaats gevonden verder uitgelicht en zullen de

bedrijfsactiviteiten van deze afdeling behandeld worden.

2.1 Rabobank

Rabobank Groep is een internationale financiële dienstverlener op coöperatieve grondslag. Binnen Rabobank Groep onderscheiden we bijvoorbeeld Lokale Rabobanken, Rabobank Nederland, Rabobank Internationaal en dochterondernemingen. Hierbij bestaan de lokale Rabobank vestigingen uit 139 zelfstandige coöperaties die hun eigen bankvergunning van De Nederlandsche Bank bezitten. Deze lokale Rabobanken zijn de bekende banken waar iedereen terecht kan voor bijvoorbeeld betaalrekeningen, spaarrekeningen en hypotheken.

Rabobank Nederland

Rabobank Nederland is de centrale organisatie binnen Rabobank Groep die in dienst staat van de lokale Rabobanken en de groepsonderdelen. Rabobank Nederland ondersteunt en adviseert de lokale Rabobanken. Zo worden er taken vervuld op het gebied van financiën,

personeelsbeleid, ICT en ontwikkelt Rabobank Nederland bijvoorbeeld nieuwe financiële diensten. Daarnaast fungeert Rabobank Nederland als huisbankier voor de lokale Rabobanken en voert het toezicht uit op het beheer en de administratie van de lokale coöperaties.

Groep ICT

Rabobank Nederland heeft een breed scala aan aandachtsgebieden en één daarvan is Groep ICT. Groep ICT verzorgt de ICT van de lokale Rabobanken maar het levert bijvoorbeeld ook diensten aan de dochterondernemingen en deze lokale Rabobanken. Binnen Groep ICT valt de afdeling Beheer en Exploitatie (B&E) en hier weer onder valt de afdeling Document

Management (zie figuur 1: ‘Organogram Groep ICT’). Binnen deze laatste afdeling heeft de afstudeerder zijn afstudeerproject uitgevoerd.

(11)

10

Document Management

Afdeling Document Management is anders ingericht dan andere afdelingen binnen Groep ICT. Document Management staat namelijk direct in contact met klanten om Service Levels af te sluiten of zaken te realiseren voor hun klanten. Daarnaast beschikt Document Management over een productiefabriek (printzaal en passenfabriek).

Binnen de afdeling Document Management valt 95% van alle product hoeveelheden onder SLA’s (Service Level Agreements) met klanten. SLA’s zijn contracten die tussen klant en leverancier wordt opgesteld om afspraken vast te leggen. Klanten van Document Management zijn bijvoorbeeld interne afdelingen als Groep ICT en Betalen & Sparen, maar ook lokale Rabobanken en dochterondernemingen als Achmea/ Interpolis en Robeco.

Zoals in figuur 2.1 ‘Organogram Groep ICT’ weergegeven is, onderscheiden we onder Document Management een aantal onderdelen. De eerste is ‘Service- & Projectmanagement’ (in de afbeelding ‘SM/PM/BA’ genoemd) waaronder Service Management, Project

Management en Business Analisten vallen. Daarnaast bestaat Document Management uit de het onderdeel ‘Life Cycle Management’ (in de afbeelding ‘LCM/PrM/CM’ genoemd) en onderscheiden we hier Product Management, Contract Management en Beheer &

Ontwikkeling onder. Als laatste vallen de printzaal en de passenfabriek onder het onderdeel ‘Productie’.

2.2 Geschiedenis

Rabobank heeft een grote geschiedenis, waarbij het allemaal begonnen is in 1864 toen een Duitse burgemeester een boerenleenbank oprichten. Hierna ontstonden eind jaren tachtig en begin jaren negentig vele Nederlandse boerenleenbanken op coöperatieve basis. Na vele fusies tussen deze coöperaties fuseerden in 1972 de Coöperatieve Centrale Raiffeisen-Bank en de

Coöperatieve Centrale Boerenleenbank tot Coöperatieve Centrale

Raiffeisen-Boerenleenbank, met als roepnaam Rabobank. Vanaf 1980 wordt alleen nog maar de naam

Rabobank gebruikt. Rabobank heeft nog vele overnames en fusies gerealiseerd (zoals: Robeco en Interpolis) waardoor Rabobank nu één van de grootste financiële dienstverleners van Nederland is. Hierbij heeft Rabobank ongeveer 32% van het marktaandeel hypotheken, 39% marktaandeel sparen en 42% markaandeel handel, industrie en dienstverlening in handen binnen Nederland.

2.3 Vestigingen

Rabobank bestaat uit 139 zelfstandige coöperaties die samen 892 vestigingen en 2.956 geldautomaten verdeelt over het gehele land vertegenwoordigen. Daarnaast zijn er ruim 700 buitenlandse vestigingen en heeft Rabobank ruim 1,8 miljoen leden. Het totaal aantal werknemers van Rabobank Groep bedraagt bijna 60.000 fte.

Rabobank Nederland heeft verschillende vestigingen binnen Nederland. De twee grootste vestigingen van Rabobank Nederland bevinden zich in Utrecht en Eindhoven. Daarnaast zijn er ook vestigingen in Best, Boxtel, Zeist en Tilburg. Rabobank Nederland telt binnen deze vestigingen ongeveer 6.600 fte. De afdeling Document Management bevindt zich op locatie Best en omvat ongeveer 130 medewerkers.

Meer informatie over de afdeling Document Management is opgenomen in bijlage II. ‘Bijlage – Het bedrijf’. Hier zijn de bedrijfsactiviteiten, een organogram en de cultuur van de afdeling opgenomen.

(12)

11 3. De opdracht

Binnen dit hoofdstuk wordt de afstudeeropdracht beschreven. Hierin wordt allereerst de beginsituatie geschetst met daarin het probleem en wat hier de gevolgen van zijn. Vervolgens is in dit hoofdstuk het doel van het project en het verwachte eindresultaat opgenomen. Als laatste is de opdracht beschreven, wordt uitgelegd hoe de

uitvoering hiervan is gepland en welke wijzigingen er tijdens de opdracht hebben plaats gevonden.

3.1 Beginsituatie

Binnen de huidige situatie levert de afdeling Document Management diensten op het gebied van Document Management aan haar klanten in de vorm van scandiensten, document generatie diensten, archiveringsdiensten en printdiensten. Binnen dit project is het onderdeel document generatie van belang. Hierbij worden documenten voor klanten gegenereerd en zal het proces starten zodra de klant ruwe data aanlevert. Na de aanlevering wordt de ruwe data binnen Document Management uit elkaar gehaald, gecontroleerd, omgezet en opgemaakt. Na deze stappen zijn er uit de ruwe data vele verschillende documenten ontstaan en kunnen deze naar de cliënt of terug naar de klant verzonden worden. Deze documenten kunnen op vele verschillende manieren worden verzonden. Zo is er de mogelijkheid deze documenten af te drukken en vervolgens via de post te verzenden, maar is er ook de mogelijkheid om er PDF bestanden van te maken en deze vervolgens via e-mail of fax te verzenden.

Waar vroeger vrijwel alles fysiek werd verwerkt gaat dit steeds meer naar de digitale omgeving en dit brengt problemen met zich mee. Zo kan een brief binnen de fysieke omgeving nog worden teruggeroepen of tegengehouden, maar een digitaal document is ook daadwerkelijk verzonden als deze verzonden is. Hierdoor komt het voor dat er fouten ontstaan die niet meer tegen gehouden kunnen worden. Door deze fouten worden binnen Document Management niet altijd de SLA’s met de klanten gehaald op het gebied van Juistheid¹,

Volledigheid² en Tijdigheid³. Naast dat er fouten ontstaan worden deze vaak niet door de

afdeling Document Management zelf ontdekt, maar horen zij dit vaak via hun klanten. Als deze fouten zo snel mogelijk zelf ontdekt zouden worden kan er ook direct ingegrepen worden en komen Service Levels waarschijnlijk niet in gevaar. De detectie hiervan verloopt echter moeizaam doordat het proces slecht gelogd en gemonitord wordt en is hierdoor een tijdrovend karwei om te achterhalen waar de oorzaak van fouten ligt.

Om aan te geven hoe groot dit probleem is hebben in 2011 28 grotere incidenten plaats gevonden die het behalen van de SLA’s in gevaar brachten. Hiervan hadden 5 incidenten direct gevolgen op het niet behalen van SLA’s op het gebied van juistheid. Een voorbeeld hiervan is dat e-mail berichten van ruim 1.800 klanten bij verkeerde klanten terecht kwamen.

¹ Juistheid is de mate waarin documenten of leveringen juist uitgeleverd worden, zoals de juiste inhoud, afbeelding of bijlagen.

² Volledigheid is de mate waarin documenten of leveringen volledig uitgeleverd worden, zoals de volledige levering, alle bijlagen of afbeeldingen.

(13)

12 3.2 Doelstelling

De doelstelling van het project is om een duidelijk beeld te vormen hoe fouten gereduceerd kunnen worden en hoe het mogelijk wordt deze zelf te detecteren. Hierbij wil Document Management antwoord op de volgende vragen:

1. Op welke wijze kan Document Management ervoor zorgen dat de dienstverlening Juist,

Volledig en Tijdig richting de klanten wordt geleverd binnen het ‘Document Generatie

proces’?

2. Hoe kan Document Management zelf detecteren wanneer een verstoring optreedt binnen het ‘Document Generatie proces’?

Het gewenste eindresultaat levert een duidelijk beeld op hoe de Service Levels (beter) gerealiseerd kunnen worden na de invoering van de aanbevelingen. Het zal tevens duidelijk zijn waar risico’s zitten en hoe deze risico’s verkleind kunnen worden. Hiernaast zal het op grote lijnen helder zijn hoe het meten en monitoren van het proces kan verlopen.

3.3 Voordelen

Het project levert een aantal voordelen op voor de afdeling Document Management, namelijk:

 Tevreden klanten en een kosten besparing (na de invoering), doordat:

o Er minder fouten worden gemaakt;

o Fouten eerder ontdekt worden en er snel ingegrepen kan worden.

 Processtroom van het ‘Document Generatie proces’ is in kaart gebracht en weer

up-to-date;

 Openstaande ‘problems’ worden onderzocht/opgepakt binnen dit project;

 Levert een bijdragen aan de doelstelling ‘Continuïteit en Stabiliteit’.

3.4 De opdracht

Hierboven werd het ‘Document Generatie proces’ al globaal beschreven. Binnen het ‘Document Generatie proces’ vallen twee soorten omgevingen, namelijk deze ‘Batch’ omgeving en de ‘On Demand’ omgeving. Binnen de ‘Batch’ omgeving wordt een tijd

afgesproken wanneer het proces start en wordt er één ruw data bestand aangeleverd waar vele documenten uit voortvloeien. Deze documenten kunnen vervolgens richting de klant, een tussenpersoon of naar de cliënt gezonden worden. Binnen de ‘On Demand’ omgeving wordt het proces direct getriggerd wanneer een klant iets aanlevert. Tevens wordt er maar één bestand aangeleverd en de klant zelf krijgt vervolgens ook maar één bestand terug. Het generatie stuk binnen deze omgevingen verlopen ongeveer het zelfde, maar de input en output verloopt anders. Hierdoor wordt binnen dit project eerst de ‘Batch’ omgeving onderzocht en kunnen later (buiten dit project) de leerpunten hieruit toegepast worden binnen de ‘On Demand’ omgeving.

Binnen dit project wordt dus het Document Generatie proces en dan specifiek de ‘Batch’ omgeving in kaart gebracht en geanalyseerd. Hierbij is het van belang om te kijken waar de risico’s binnen het proces zitten en hoe deze verholpen of verkleind kunnen worden. De analyse wordt uitgevoerd met behulp van de ‘Process Failure Mode and Effect Analysis’ (PFMEA) waarmee gekeken kan worden waar faalkansen zitten en vervolgens wat voor risico dit met zich mee brengt. Na deze procesanalyse wordt een gewenste situatie van het proces geschetst waarin de risico’s verkleind of zelfs weggenomen zullen zijn. Hierdoor zullen er minder fouten gemaakt worden binnen het proces en zal de impact minder groot zijn als deze toch gemaakt worden.

(14)

13

Hieronder weergegeven welke onderdelen binnen dit deel van het project vallen. 1. Huidige situatie

2. Procesanalyse

 Knelpunten/ risico’s  Oplossingen/ actieplan 3. Vernieuwde situatie

4. Meten en monitoren proces

Naast het verbeteren van het proces wordt, zoals punt 4 al zegt, onderzoek gedaan naar het meten en monitoren van het proces. Dit om het ontdekken van fouten binnen het proces gemakkelijker en beter mogelijk te maken. Binnen dit deel worden de volgende vragen beantwoord:

 Hoe wordt er zo optimaal mogelijk een logging database opgezet?  Welke logniveaus zijn er en welke richting is het beste van toepassing?  In welk (standaard) formaat kunnen/moeten de verschillende componenten log

gegevens ontsluiten?

 Wat zijn de mogelijkheden om gelogde informatie te ontsluiten?  Hoe kan data-integriteit gewaarborgd worden?

Uitsluitingen

Aangezien de afstudeerder beperkte tijd heeft, is niet alles mee genomen binnen dit project. Zo wordt er:

 Niet naar de fysieke omgeving gekeken;

 Niet naar andere processen gekeken buiten het proces ‘Document Generatie’ om;  Niet naar de ‘On Demand’ omgeving gekeken;

 Geen proof-of-concept ingericht;  Niets geprogrammeerd;

 Niets geïmplementeerd.

Mijlpalen

Binnen deze onderdelen van het project zijn een aantal mijlpalen gedefinieerd. Dit zijn in chronologische volgorde:

 Start van het project (Kick-off meting);  Huidige situatie;

 Resultaat procesanalyse;  Meten en monitoring proces;  Advies en implementatieplan.

Voortgang

Tijdens het project wordt wekelijks de voortgang van het project besproken binnen een voortgangsgesprek tussen afstudeerder en stagebegeleider. Daarnaast vindt iedere twee weken een voortgangsbespreking plaats binnen de projectgroep om de bevindingen, de status van het project en de gemaakte afspraken door te nemen.

Ook worden de bovenstaande mijlpalen gepresenteerd binnen het MT van Document Management.

(15)

14

Oplevering

Het project levert een drietal documenten op, namelijk:  Een onderzoeksrapport

Binnen het onderzoekrapport wordt het gehele onderzoek opgenomen inclusief alle bevindingen die in het onderzoek naar voren zijn gekomen;

 Een adviesrapport

Binnen het adviesrapport wordt advies gegeven over de te nemen acties;  Een implementatieplan

Binnen het implementatieplan wordt aangegeven hoe de te nemen acties het best geïmplementeerd kunnen worden binnen de afdeling Document Management.

3.5 Uitvoering

Het project wordt volgens het Tien Stappen Plan uitgevoerd, waarin de oriëntatiefase,

Onderzoeks- en oplossingsfase en invoeringsfase centraal staan. Naast de fasering uit dit plan is de aanpak als volgt:

 Huidige situatie in kaart brengen (m.b.v. Data Flow Diagrams (DFD));

 Procesanalyse uitvoeren (m.b.v. PFMEA);

 Nieuwe procesgang ontwerpen;

 Onderzoeken hoe het proces gemeten en gemonitord kan worden.

Huidige situatie

De huidige documentatie die binnen Document Management beschikbaar is zal als basis dienen om het huidige proces in kaart te brengen. Deze huidige documentatie bestaat uit een functioneel ontwerp uit 2009 (Huijben 2009) en een aantal losse documenten die het laatst in 2011 zijn gewijzigd (Miert 2011, Huijben 2011, Kaspers 2011). Naast deze documentatie wordt er gebruik gemaakt van interviews en worden de procestekeningen doorgesproken met betrokkenen. De huidige situatie wordt uitgewerkt in DFD’s. Bij de uitwerking van de huidige situatie zal er in eerste instantie op een wat hoger niveau gekeken worden naar het proces en zal er niet diep ingegaan worden op details. Dit betekent in DFD termen dat er een context diagram, een DFD1 en voor de primaire deelprocessen verschillende DFD2’s gerealiseerd zullen worden.

Procesanalyse en nieuwe procesgang

Hierboven werd al aangegeven dat de procesanalyse uitgevoerd wordt met behulp van de methode ‘PFMEA’. Deze methoden is geschikt om binnen processen de risico’s in kaart te brengen en te achterhalen hoe groot het risico is. Deze methode onderkent een tiental stappen, waarin het proces beoordeelt wordt op verschillende onderdelen, aan deze onderdelen cijfers worden toegekend en aan de hand van deze cijfers het risicocijfer berekend wordt. Als laatste worden acties opgesteld om de risico’s te verkleinen en worden de nieuwe risicocijfers berekend. Aan de hand van deze analyse en de overige bevindingen zal de nieuwe procesgang ontworpen worden.

Meten en monitoren

Binnen het onderzoek naar het meten en monitoren van het ‘Document Generatie proces (batch)’ worden de vragen beantwoord die in het vorige hoofdstuk (3.4 De opdracht) behandeld werden. Binnen dit onderzoek wordt eerst informatie ingewonnen bij de

betrokkenen en worden de mogelijkheden besproken met Senior Ontwikkelaars. Vervolgens wordt er onderzoek gedaan naar de mogelijkheden en worden de vragen beantwoord.

(16)

15 3.6 Wijzigingen

In dit deelhoofdstuk wordt aangegeven wat er in de afstudeerperiode aan de opdracht is gewijzigd en waarom.

Procesanalyse tijdrovend

Tijdens de start van de procesanalyse bleek al snel dat de methode PFMEA een zeer

tijdrovende methode is. Aangezien de betrokkenen een beperkte tijd voor dit project hebben was dit een probleem. Hierdoor is er besloten om het meest risicovolle deel van het proces te analyseren volgens de methode en de rest met een soort Quickscan te doorlopen op grote risico’s. De grote risico’s die uit de Quickscan komen zullen alsnog volgens de methode uitgewerkt worden indien dit van toegevoegde waarde is. Er is gekozen om dan ook vooral de focus te leggen op de eerste helft van het proces. Argumenten voor de keuze van deze eerste fase van het proces zijn:

 Als er binnen de begin fase iets fout gaat, loopt vaak het gehele proces fout en oorzaken van latere fouten liggen vaak in deze fase;

 Binnen deze eerste fase gaan de meeste zaken fout;

 Het is te veel werk om de methode voor ieder outputkanaal uit te voeren. Daarnaast is het outputkanaal met de meeste fouten al een project op zich aangezien dit de

printzaal betreft;

 De ondersteunende processen zijn niet belangrijk genoeg om te analyseren volgens de methode en sommige zullen in de toekomst anders verlopen, doordat PrintManager uit gefaseerd is dit jaar en deze processen in PrintNet worden geïntegreerd.

Huiswerk

Naast het verminderen van de uit te voeren analyse zal er ook met huiswerk gewerkt worden. De student zal een opzet maken van ieder proces, waarin hij de faalkansen, gevolgen en oorzaken formuleert. Vervolgens zal deze aangevuld worden door een Product Manager en een Tactisch Functioneel Beheerder/ Ontwikkelaar. Deze resultaten worden samen gevoegd door de student en met de groep doorgesproken. Op deze wijze zal er veel tijd bespaard worden met de sessies en zal de analyse efficiënter verlopen.

Dit alles is in overeenstemming met de projectgroep en de begeleider gewijzigd.

Planning

Gaandeweg dat de procesanalyse vorderde werd het probleem dat groepssessies met de betrokkenen moeilijk in te plannen waren geconstateerd. Dit had als redenen:

 Drukte projectgroep;

 Thuiswerk dagen van projectgroep;

 Afwezigheid betrokkenen i.v.m. ziekteverzuim en vakantie;  Grote incidenten, waardoor sessies niet door konden gaan.

Om deze problemen te verhelpen zijn een aantal maatregelen genomen, namelijk:  Het toevoegen van een extra medeweker aan de projectgroep;

 In overeenstemming met de projectgroep een heel dagdeel reserveren voor een sessie om een grote slag te maken.

Ondanks deze maatregelen is de procesanalyse een viertal weken uitgelopen. Door het onderdeel logging en monitoring eerder op te pakken heeft dit niet tot zeer grote problemen geleid.

(17)

16 4. Huidige situatie

In dit hoofdstuk is de huidige situatie van het proces opgenomen. Om te achterhalen waar de fouten vandaan komen en om een goede analyse uit te kunnen voeren is eerst de huidige situatie in kaart gebracht. In deze huidige situatie is een beeld gecreëerd hoe het proces verloopt en

daarnaast zijn de knelpunten in de huidige situatie geïnventariseerd, zodat onder andere op basis hiervan de gewenste situatie ontworpen kan worden.

4.1 Aanpak

Om er zeker van te zijn dat er geen dubbel werk gedaan werd is allereerst gekeken naar de beschikbare documentatie. De beschikbare documentatie bestond uit een Functioneel Ontwerp uit 2009 (Huijben 2009) en een viertal aanvullende documenten uit 2010/2011 (Miert 2011, Huijben 2011, Kaspers 2011). Wat binnen deze documentatie opvalt is dat de gebruikte schema’s niet overeen komen binnen de verschillende documenten. Het gebruik van schema’s binnen de verschillende documenten is dus inconsistent en het is niet duidelijk welk schema nu daadwerkelijk de juiste is. Tevens werd duidelijk dat de documentatie sterk verouderd was en niet de werkelijkheid weerspiegelde.

Om een goed beeld te krijgen van de huidige situatie is de student in gesprek gegaan met verschillende partijen, namelijk: Product Managers, Tactisch Functioneel Beheerders en Ontwikkelaars. Aan de hand van deze gesprekken zijn de procestekeningen verder uitgewerkt en aangepast, zodat deze overeen komen met de huidige situatie. Ook is er een beschrijving toegevoegd waarin het doel, de input, de output en de werking van het (deel)proces

beschreven wordt.

Er is gekozen om de het procesmodel DFD te gebruiken om de processen visueel weer te geven. De argumenten voor deze keuze zijn:

 De huidige documentatie maakt gebruik van DFD’s, waardoor de modellen direct gebruikt kunnen worden;

 Het is een goed model om processtromen weer te geven op verschillende niveaus;  Betrokken medewerkers bij het project hebben kennis van het procesmodel;  De procesmodellen sluiten aan op de methode voor de procesanalyse.

4.2 Uitwerkingen

Hieronder is in figuur 4.1 ‘Vereenvoudigde procestekening’ een vereenvoudigde

procestekening van het Document Generatie proces Batch weergegeven. In deze tekening is alleen het primaire proces opgenomen en zijn niet de ondersteunende processen mee genomen. Ondersteunende processen zijn bijvoorbeeld de doorbelasting, het synchroniseren van de database en het wegschrijven van verwerkingsgegevens. In bijlagen III. ‘Bijlage –

Procesbeschrijving en – modellen’ zijn de uitgewerkte procestekeningen inclusief beschrijving opgenomen.

Ontvangen Data

Converteren

Data Opmaken Data

Converteren Documenten (bv. PDF) Verzenden Documenten (bv. E-mail) Klant Klant, Tussen-persoon of Cliënt Verwerken Documenten (bv. Afdrukken) Ontvangen Data Converteren Data (naar standaard formaat) Opmaken Data Converteren Documenten (bv. PDF) Verzenden Documenten (bv. E-mail) Klant Klant, Tussen-persoon of Cliënt Verwerken Documenten (bv. Afdrukken) Selecteren opgemaakte batches

(18)

17

In figuur 4.1 ‘Vereenvoudigde procestekening’ is te zien dat de klant allereerst ruwe data naar de afdeling Document Management verstuurd. Deze ruwe data kan verschillende structuren hebben, zoals XML, ARI, Line-data en S3.28 (verschillende formaten om data te

communiceren). Na het ontvangen van deze data wordt deze geconverteerd, zodat alle data op de zelfde wijze gestructureerd is en bruikbaar is binnen de applicatie. De data wordt

vervolgens opgemaakt in de specifieke sjablonen en wordt gereed gemeld voor distributie. Binnen het distributie deel wordt onderscheid gemaakt tussen recepten. Een recept is het gewenste outputkanaal en onderscheid zich in printen, e-mail, fax en archief. Voor elk recept wordt een specifiek proces gestart waarin de opgemaakte documenten omgezet worden naar bijvoorbeeld PDF en verzonden worden naar het gewenste outputkanaal. Bij het recept e-mail worden de documenten bijvoorbeeld verzonden naar de e-mail server waar deze direct naar de cliënt toegezonden worden.

Binnen het proces worden verschillende databases geraadpleegd en/of gevuld. In tabel 4.1 ‘Overzicht databases’ zijn deze weergegeven. Zo is te zien wat de functie van de database is en waarvoor deze geraadpleegd en waarmee deze gevuld wordt.

Database Beschrijving Proces raadpleegt Proces vult

GLOBA Banken tabel met

informatie over de lokale banken

 Informatie over lokale banken

-

HANDTEKENINGEN -DB

Database met digitale handtekeningen

 Handtekeningen -

PROD-DB Productendatabase waarin

product instellingen zijn opgenomen

 Product informatie -

INSTEL-DB Instellingendatabase

waarin instellingen per product zijn opgenomen en o.a. de SLA

instellingen

 Instellingen informatie -

PROCESS-DB Process database waarin

het proces leveringen, documenten en recepten bijhoud om deze goed te kunnen verwerken  Selecteren van recepten  Stuurinformatie  Leveringsgegevens  Documentgegevens  Receptgegevens  Status informatie

TNO-SPOOL Spool waarin opgemaakte

documenten, gereed voor distributie naar het outputkanaal, worden opgenomen  Opgemaakte documenten  Opgemaakte e-mail  Opgemaakte documenten  Opgemaakte e-mail RESOURCES/ PRINTBAREBIJLAGEN

Database voor resources (afbeeldingen, lettertypes, etc.) en printbarebijlagen

 Resources

 Printbarebijlagen  Resource

Tabel 4.1 Overzicht databases Printnet

Het Document Generatie proces Batch wordt grotendeels uitgevoerd in het software pakket PrintNet van GMC dat geleverd wordt door Océ. Dit is een pakket waarin in eerste instantie documenten opgemaakt kunnen worden. Echter is het mogelijk om binnen dit pakket zaken te programmeren, waardoor er extra functionaliteiten binnen dit pakket aangebracht zijn. Zo zijn er tal van conversies gebouwd en zijn er vele workarounds gebouwd om de functionaliteit van het standaardpakket uit te breiden of te verbeteren.

(19)

18 4.3 Bevindingen

Tijdens het analyseren van de huidige situatie zijn naast de huidige werkwijze en het up-to-date brengen van de documentatie ook een aantal verbetermogelijkheden in het proces naar voren gekomen. Deze bevindingen zijn meegenomen in het onderzoek om later aan te kaarten en een voorstel te doen deze te verbeteren of op te lossen. De bevindingen zijn tevens

doorgesproken met medewerkers binnen Document Management om er zeker van te zijn dat deze bevindingen juist geconstateerd zijn.

Een aantal bevindingen die door de student gedaan zijn:

1. Verschillende aanlever formaten en structuren

Er worden vier verschillende formaten ruwe data aangeleverd waarbinnen bijna iedere klant ook nog eens een andere structuur hanteert. Als gevolg is er voor bijna iedere klant een conversie gebouwd om de data om te zetten naar een standaard formaat en structuur. Om de dienstverlening zo standaard mogelijk te laten verlopen is deze conversie uiteraard niet gewenst of het liefst zo generiek mogelijk.

2. Meetpunten om SLA’s te meten

Het meten van SLA’s gebeurt op basis van een tweetal telling bestanden. Echter wordt het eerste telling bestand pas na het opmaken van de documenten en niet direct bij het ontvangst van de data aangemaakt en wordt de tweede telling al voor dat de

documenten daadwerkelijke uitgeleverd worden aangemaakt. Hierdoor is het niet mogelijk te controleren of alle binnen gekomen leveringen volledig verwerkt en uitgeleverd zijn aangezien hier niet op gemeten wordt.

3. Meetpunt doorbelasting

De doorbelasting richting de klant wordt berekend op het zelfde eerste telling bestand als in het punt hierboven. Door gebruik te maken van het eerste telling bestand worden zaken misschien doorbelast die niet uitgeleverd worden. Daarnaast wordt er nooit gecontroleerd of deze tellingen wel kloppen, waardoor er nooit zeker gezegd kan worden of het juiste doorbelast wordt.

4. Alleen het gewenste pad wordt getest

Bij het testen van nieuwe functionaliteiten of wijzigingen in de software wordt alleen het gewenste pad getest en niet wat er allemaal fout kan gaan. Hierdoor ontstaan er regelmatig incidenten waardoor SLA’s niet gehaald worden. Daarnaast wordt er nooit een risicoanalyse uitgevoerd voordat zaken ontwikkeld of getest worden, waardoor niet duidelijk is waar de grote risico’s zitten en hier eventueel op getest kan worden.

5. Documentatie niet up-to-date

De huidige documentatie is sterk verouderd en niet meer up-to-date. De oorzaak hiervan is dat ontwikkelaars andere zaken gebouwd hebben dan wat daadwerkelijk op papier staat i.v.m. technische beperkingen. Echter zijn deze zaken nooit aangepast in de documentatie van het proces. Daarnaast komen de schema’s binnen de

verschillende documenten niet overeen, waardoor niet duidelijk is welke situatie nu het dichtste bij de werkelijkheid ligt.

In de bijlagen VII. ‘Bijlage - Bevindingen’ is een uitgebreide beschrijving van deze bevindingen en zijn aanvullende bevindingen opgenomen.

(20)

19 4.4 Volwassenheid

Om de volwassenheid van dit proces te beoordelen is het ‘Capability Maturity Model

Integration’ (CMMI) gebruikt. Dit om te kijken waar de organisatie nu staat met het proces en waar ze later in de gewenste situatie graag naar toe zouden willen. Met behulp van dit model kan bepaald worden welke acties gewenst zijn om het gewenste niveau te behalen.

Het CMMI model bestaat uit vijf niveaus waarin niveau één het laagste niveau is en niveau vijf het hoogste. Niveau één kenmerkt zich doordat de processen ad hoc verlopen. Niveau vijf kenmerkt zich door continue verbetering van de processen. Een overzicht van al deze niveaus is opgenomen in figuur 4.2 ‘CMMI’. Op diverse fronten acteert Document Management op niveau één, waarbinnen problemen bijvoorbeeld pas opgelost worden wanneer deze zich aandienen. Daarnaast zijn er ook argumenten om het proces als level twee te classificeren aangezien er bijvoorbeeld oplossingen gezocht worden aan de hand van ervaringen. Een classificatie niveau 3 is tevens mogelijk aangezien projecten opgepakt worden door een speciale Project Management afdeling en volgens bijvoorbeeld de Prince2 methode doorlopen worden.

Eén ding is duidelijk en dat is dat niveau één en twee te laag zijn voor de ambities van

afdeling. Zo is de digitale dienstverlening razendsnel waardoor snel fouten ontstaan. Wanneer er goed gedocumenteerd wordt en er preventief gehandeld wordt zal deze dienstverlening goed verlopen. Als dit echter niet gebeurd zal bij een nog grotere groei het aantal fouten toenemen en zal het moeilijker worden de diensten onder controle te krijgen. In hoofdstuk 6 ‘Gewenste situatie’ zal het gewenste niveau aangegeven worden.

Figuur 4.2 CMMI

(21)

20 5. Procesanalyse

In dit hoofdstuk wordt de procesanalyse beschreven. Om helder te krijgen waar de risico’s binnen het proces liggen is er een procesanalyse uitgevoerd. Zo is helder waar

Document Management risico loopt en kan zij hier maatregelen voor treffen. In dit hoofdstuk is de aanpak

hiervan opgenomen en zijn de uitwerkingen hiervan opgenomen waarin een aantal risico’s en acties naar voren komen.

5.1 Aanpak

Er zijn vele methoden om risico’s te achter halen. Binnen dit project is de keuze gemaakt om de methode PFMEA te gebruiken. De methode is specifiek bedoelt om processen te

analyseren en te kijken waar zich faalkansen voordoen. Waar normale risicoanalyses alleen beoordelen op ernst en kans, beoordeeld deze methode tevens op de detectie van de risico’s, wat dan ook goed binnen dit project valt.

De methode is gekozen om de volgende redenen:  Specifiek geschikt om processen te analyseren;

 Specifiek geschikt om faalkansen/risico’s in kaart te brengen;

 De faalkansen worden op drie gebieden beoordeeld, namelijk ernst, kans en detectie;  Veel informatie over de methode beschikbaar, waaronder een tien stappen plan. Allereerst is onderzoek gedaan hoe de methode in elkaar steekt en wat voor stappen er ondernomen dienen te worden. De methode bestaat origineel uit tien stappen. Binnen dit project zijn er een aantal stappen gebundeld om de analyse soepeler en sneller te laten verlopen. Dit bundelen is toegepast omdat het eenvoudiger is om de faalkansen direct uit te werken, zodat deze niet steeds opnieuw geïntroduceerd hoeven te worden in vervolg bijeenkomsten.

We onderkennen de volgende stappen: 1. Voorbereiding

2. Faalkansen inventariseren en uitwerken a. Brainstormen mogelijke faalkansen; b. Gevolg van de faalkansen formuleren; c. Beoordelen effect faalkans;

d. Inventariseren mogelijke oorzaken; e. Beoordelen mogelijke oorzaken op kans; f. Vast stellen detectie van de mogelijke oorzaken; g. Beoordelen detectie;

h. Berekenen risicocijfer;

i. Voorlopig bepalen of er een actie gewenst is. 3. Faalkansen op het proces plaatsen

a. Koppelen faalkansen (en eventueel oorzaken) aan het proces; b. Definitief bepalen of er een actie gewenst is.

4. Acties bepalen

a. Bepalen welke acties benodigd zijn. 5. Herberekenen risicocijfers.

(22)

21

In de eerste stap ‘Voorbereiding’ is alle voorbereiding voor de analyse getroffen. In de stap hier op volgend ‘Faalkansen inventariseren en uitwerken’ is gebruik gemaakt van een worksheet waarin de uitkomst van alle stappen opgenomen is. Een voorbeeld van een

uitgewerkte worksheet is in bijlage IV. ‘Bijlage – Risico’s procesanalyse’ opgenomen. Tevens de scoringstabellen waarmee de cijfers ernst, kans en detectie bepaald zijn, zijn opgenomen in bijlage V. ‘Bijlage – Scoringstabellen procesanalyse’.

De methode dient daarnaast uitgevoerd te worden doormiddel van groepssessies, dit om een zo breed mogelijk veld aan risico’s te inventariseren. De student heeft hiervoor een aantal technische personen ‘Tactisch Functioneel Beheerders’ en een ‘Ontwikkelaar’ geselecteerd en om een wat groter overview te creëren een tweetal ‘Product Managers’ die niet vanuit de techniek denken. Zo kan de analyse vanuit verschillende perspectieven benaderd worden en zal dit tot het beste resultaat leiden.

Aangezien het een tijdrovende methode is heeft de student in overleg met de projectgroep besloten om de projectgroep taken te geven. Dit wil zeggen dat zij in duo’s het nodige aan voorwerk doen. In dit voorwerk verzorgt de student allereerst een eerste opzet en invulling van de worksheets en worden deze vervolgens aangevuld door de duo’s. Deze uitgewerkte

worksheets worden vervolgens later in groepssessies besproken. Door deze resultaten te bespreken ontstaan discussies en wordt het beste resultaat behaald.

5.2 Uitwerking

Tijdens de procesanalyse zijn een aantal risicogebieden naar voren gekomen. In figuur 5.1 ‘Risicogebieden’ hieronder zijn deze risicogebieden opgenomen. In dit figuur is te zien dat vooral in de voorste helft van het proces veel risico’s aanwezig zijn en hier acties gewenst zijn.

Ontvangen Data

Converteren

Data Opmaken Data

Converteren Documenten (bv. PDF) Verzenden Documenten (bv. E-mail) Klant Verwerken Documenten (bv. Afdrukken) Ontvangen Data Converteren Data (naar standaard formaat) Opmaken Data Converteren Documenten (bv. PDF) Verzenden Documenten (bv. E-mail) Klant Klant, Tussen-persoon of Cliënt Verwerken Documenten (bv. Afdrukken) Selecteren opgemaakte batches Veel risico’s Aantal risico’s Figuur 5.1 Risicogebieden

Naast de risicogebieden in het primaire proces vallen er ook veel risico’s in de doorbelasting van de leveringen. Deze is echter niet uitgewerkt volgens de methode aangezien dit een ondersteunende processtap betreft en duidelijk is dat hier risico’s liggen.

(23)

22

Risico’s

Binnen risicogebieden met veel risico’s hebben van de 141 risico’s 54 risico’s een risicocijfer hoger dan 100. Dit wil zeggen dat er naar 38% van alle risico’s gekeken dient te worden of hier een actie gewenst is of juist niet. Al de risico’s die naar voren zijn gekomen in de analyse zijn opgenomen in bijlage IV. ‘Bijlage – Risico’s procesanalyse’. Voorbeelden van deze risico’s zijn bijvoorbeeld:

 Risico’s aan de zijde van de klant, zoals het aanleveren van foutieve inhoud of het te laat aanleveren van data. Dit kan als gevolg hebben dat documenten met foutieve inhoud bij cliënten terecht komen of zelfs helemaal niet uitgeleverd worden. In het totaal zijn 9 risico’s direct aan de klant te koppelen.

 Risico’s binnen afdeling Document Management zijn bijvoorbeeld:

o Data wordt overschreven, waardoor een gehele levering verloren gaat; o Doorlaten van foutieve data, waardoor de data foutief of helemaal niet

verwerkt wordt;

o Foute afbeelding wordt toegevoegd aan de documenten, waardoor deze afbeelding bij de cliënt terecht komt;

o Leveringen worden dubbel verwerkt, waardoor cliënten documenten dubbel ontvangen.

Acties

Bij ieder risico waar een actie gewenst is, zijn acties opgesteld om de ernst, kans of detectie van het risico te verkleinen. Van de 54 risico’s met een risicocijfer hoger dan 100 zijn bij 38 risico’s acties gewenst. De overige risico’s liggen bij de klant, zijn niet groot genoeg of zijn te moeilijk op te lossen.

Er zijn verschillende soorten acties mogelijk, zoals in figuur 5.2 ‘Soorten acties’ weergegeven. Zo kan er preventief gehandeld worden waarbij het risico vooraf verkleind wordt, maar kunnen risico’s ook gedetecteerd worden wanneer deze optreden, kan de schade verminderd worden door een repressieve maatregel of kan het herstel vereenvoudigd of mogelijk gemaakt worden met een correctieve maatregel. Binnen dit project is gekozen om vooral preventieve en detectieve maatregelen op te stellen om de risico’s te voorkomen en als zich deze toch

voordoen de risico’s te detecteren.

(24)

23

De acties zijn in groepssessies met de projectgroep bedacht en opgesteld en zijn opgenomen in bijlage VI. ‘Bijlage – Acties procesanalyse’. Een aantal geformuleerde acties zijn

bijvoorbeeld:

 De controle die binnengekomen data controleert moet meer afvangen, zodat minimaal de vereiste velden die binnen de afdeling benodigd zijn gecontroleerd worden.  Er moet beter getest worden door bijvoorbeeld duidelijkere testprocedures op te

stellen en een risicoanalyse vooraf uit te voeren, zodat minimaal de risicovolste acties getest kunnen worden.

 Terugdringen van beheerder autorisaties, zodat applicatief beheerders niet zomaar op de productie omgeving acties kunnen uitvoeren.

 Het inrichten van logging en monitoring waardoor het proces inzichtelijk gemaakt wordt en leveringen bewaakt kunnen worden.

Na het invoeren van alle acties zullen alle risico’s dan wel op ernst, kans of detectie afnemen, waardoor deze niet direct voor een groot gevaar zorgen.

Opvallend

Binnen de resultaten van de procesanalyse vallen een aantal punten op waaruit blijkt dat veel risico’s ontstaan. Dit zijn namelijk:

 Maatwerk

Binnen het conversie en opmaak proces is het meeste maatwerk gerealiseerd. Dit maatwerk is binnen deze gebieden gerealiseerd om alle klanten aan te kunnen sluiten op de dienstverlening. Zo is er voor vrijwel iedere klant een stukje maatwerk

gerealiseerd waarin de data omgezet en opgemaakt wordt. Wat hierbij opvalt is dat in deze gebieden veel risico’s liggen die betrekking hebben op dit maatwerk. Zo hebben 8 van de 17 risico’s in deze twee gebieden te maken met programmeerfouten in het systeem.

 Detectie

Het valt op dat er zeer weinig gedetecteerd wordt binnen het proces. Er zijn 53 oorzaken in de analyse naar voren gekomen die helemaal niet gedetecteerd worden en dan ook in de analyse het hoogste detectiecijfer ‘10’ hebben gekregen. Bij een grote hoeveelheid van deze risico’s is dit echter wel mogelijk, maar gebeurd dit niet omdat deze functionaliteit niet ingericht is. Wanneer een risico optreedt ontdekken

klanten/cliënten dan ook vaak deze fouten en hoort Document Management deze fouten via hun klanten.

(25)

24 6. Gewenste situatie

In dit hoofdstuk wordt de gewenste situatie beschreven. Het doel binnen de gewenste situatie was om minder fouten te maken en als deze toch gemaakt worden deze door Document Management zelf te laten ontdekken. In dit hoofdstuk is dan ook te vinden naar welk gewenst volwassenheidsniveau het proces

zal stijgen en welke verbeteringen toegepast zijn in de gewenste situatie.

6.1 Volwassenheid

In de huidige situatie is het volwassenheidsniveau van het proces vastgesteld. Binnen de gewenste situatie is vastgesteld in welk niveau het proces minimaal zal moeten komen. De verschillende niveaus zijn nogmaals opgenomen in figuur 6.1 ‘CMMI’. Het liefst valt het proces in de toekomst in het hoogste niveau namelijk niveau vijf, omdat de dienstverlening hier continue verbeterd wordt en fouten voor zal blijven. Echter is dit niet haalbaar en

realistisch. Om de stabiliteit van de dienstverlening te kunnen garanderen zal minimaal niveau drie behaald moeten worden. Waarin de documentatie van alle processen op orde is, er proactief gehandeld kan worden en er gebruik gemaakt wordt van standaarden. Niveau drie is voldoende aangezien er zo inzicht in de dienstverlening komt die er momenteel niet is en tevens een grote stap is voor de afdeling. Om op dit niveau te komen zal de dienstverlening dus geprofessionaliseerd moeten worden.

(26)

25 6.2 Verbeteringen

Om het volwassenheidsniveau te behalen en de dienstverlening stabieler met minder fouten te laten verlopen is een gewenste situatie geschetst. Na dat de gewenste situatie is opgesteld is deze teruggekoppeld aan de betrokkenen, waaronder Product Managers, Tactisch Functioneel Beheerders en een Kwaliteitsmanager. De verbeteringen die toegepast zijn in de gewenste situatie zijn:

 Inzicht krijgen in het proces door het proces te loggen en te monitoren;  Splitsing tussen het ontvangst/omzetting van data en het opmaken hiervan;  Beperken van aanlever vormen;

 Uitfaseren van de oude PrintManager omgeving;  Beter testen van de dienstverlening;

 Inrichten van generieke doorbelasting en rapportages;  Documentatie op orde.

In bijlage VIII. ‘Bijlage Gewenste situatie’ is de uitgewerkte gewenste situatie opgenomen inclusief een aangepaste procestekening.

(27)

26 7. Oplossingen

In dit hoofdstuk worden de oplossingen die opgesteld zijn beschreven. Om structurele oplossingen te introduceren om een stap richting de gewenste situatie te zetten, risico’s weg te nemen en bevindingen op te lossen zijn een aantal oplossingen opgesteld en besproken met de projectgroep.

7.1 Aanpak

De projectgroep bestond binnen dit deel van het project tevens uit Tactisch Functioneel Beheerders, Product Managers en Ontwikkelaars. Binnen de oplossingen is waar mogelijk gebruik gemaakt van alternatieven en zijn deze met voor- en nadelen beoordeeld. Aangezien de doelstelling van het project is om de stabiliteit en continuïteit van de dienstverlening te verbeteren is er vooral gekeken wat de oplossingen betekenen voor het aantal incidenten en/of risico’s en is minder naar het financiële aspect gekeken. Door deze oplossingen binnen de projectgroep te bespreken zijn de keuzes gemaakt voor de meest geschikte oplossingen.

7.2 De oplossingen

De belangrijkste oplossingen zijn:

1. Het inrichten van logging en monitoring

Het inrichten van logging en monitoring moet inzicht geven in het proces, waardoor risico’s afnemen doordat deze ontdekt worden. Met een oplossing als deze zijn direct 15 risico’s te detecteren en kan er bij vele andere risico’s onderzoek gedaan worden mocht dit toch voorkomen. Verdere uitwerking van deze oplossing zijn te vinden in hoofdstuk ‘7. Logging en monitoring’.

2. Het inrichten van een input omgeving

Door het inrichten van een input omgeving kunnen leveringen gemanaged worden vanaf binnenkomst. Daarnaast liggen er mogelijkheden om de omzetting naar het standaard formaat en de controle op de data in deze omgeving op te nemen, zodat het standaard pakket ‘PrintNet’ puur gebruikt wordt voor het opmaken van documenten en het distribueren van deze documenten naar de gewenste outputkanalen. Door deze oplossing te implementeren zullen er allereerst direct 7 risico’s verlaagd worden. Daarnaast zal de dienstverlening minder complex worden waardoor minder fouten gemaakt zullen worden en bijvoorbeeld beheer- en testkosten dalen.

3. Het beperken van aanlever formaten en structuren

Door klanten te stimuleren volgens de richtlijnen van Document Management ruwe data aan te leveren kan er veel meer gestandaardiseerd worden. Wanneer een groot deel van de klanten overstapt naar deze standaard richtlijnen verdwijnen er een heleboel omzettingen in het proces, waardoor het minder complex wordt. Klanten stimuleren kan bijvoorbeeld door verschillende tarieven te hanteren, waardoor

standaard leveringen goedkoper zijn dan maatwerk. Daarnaast kan een hoger risico op fouten in de leveringen bij de klant neergelegd worden wanneer zij niet volgens de richtlijnen aanleveren.

(28)

27

4. Betere screening op data toepassen

Door de aangeleverde data van de klant beter te controleren zullen de problemen in het proces afnemen. Wanneer er een controle plaatsvindt op de aanwezigheid, verwachte inhoud en het verwachte formaat van velden die vereist zijn voor de dienstverlening zullen de fouten afnemen. Wanneer een klant niet voldoet aan de gestelde eisen zal de data terug gezonden worden, zodat de dienstverlening van Document Management hier geen hinder van ondervind. Door deze oplossing te implementeren zullen er allereerst direct 5 risico’s verlaagd worden. Daarnaast zullen er minder fouten en incidenten optreden in het proces aangezien de velden die benodigd zijn voor de verwerking gecontroleerd worden.

5. Reduceren van de complexiteit van systemen

Door de complexiteit van de systemen te reduceren zal het eenvoudiger worden de dienstverlening onder controle te houden en zullen ook kosten dalen. Door iedere komende wijziging te beoordelen op of deze daadwerkelijk nodig is, alternatieven en wat de impact is kan het aantal wijziging teruggedrongen worden. Daarnaast zullen de benodigde wijzigingen goed afgewogen worden en zal de beste oplossing gekozen worden. Ook zullen de reeds ingevoerde wijzigingen op de zelfde wijzen beoordeeld worden, zodat overbodige wijzigingen terug gedraaid worden. Door een

complexiteitsreductie door te voeren zal de dienstverlening inzichtelijker en stabieler worden en zullen ook de kosten dalen.

De oplossingen en de bijbehorende alternatieven zijn opgenomen in bijlage IX. ‘Bijlage – Oplossingen’.

Wat leveren de oplossingen op?

Wanneer de oplossingen ingevoerd worden zal allereerst de dienstverlening stabieler worden, waardoor er minder fouten zullen ontstaan. Door de hierboven geformuleerde oplossingen in te voeren zullen direct 26 van de 38 risico’s, waar een actie gewenst, verlaagd, gedetecteerd of geheel afgevangen worden.

Als er gekeken wordt naar de grote incidenten die de afgelopen anderhalf jaar voorkomen zijn konden met deze oplossingen direct 11 grote incidenten afgevangen worden. In het totaal hebben er ongeveer 30 grote incidenten plaats gevonden binnen de gehele afdeling in dit anderhalf jaar. Dit wil dus zeggen dat hier ook incidenten van andere processen zijn opgenomen, waardoor het terugdringen van 11 grote incidenten een enorme winst zou zijn voor de afdeling. Dit zou aan directe kosten ruim 72.000 euro bespaart hebben, waarbij niet eens de overige kosten voor de afdeling of zelfs de Rabobank in geheel zijn opgenomen, als bijvoorbeeld schade op het gebied van imago.

Als voorbeeld van de totale schade heeft er in 2011 een incident plaats gevonden, waardoor bestemde e-mail berichten van ruim 1.800 cliënten bij verkeerde cliënten terecht zijn

gekomen. Als per cliënt een bedrag van 142 dollar wordt gerekend, dat volgens Ponemon.org de gemiddelde kosten zijn voor het fout terecht komen van data (herstel, correctie en imago), zou ruim 200.000 euro (255.600 dollar) bespaard kunnen worden met één enkel incident.

In bijlage XIII. ‘ Bijlage Resultaat en inspanning tabellen’ zijn schema’s opgenomen waar de benodigde acties en oplossingen zijn opgenomen. Hier is te zien of de actie of oplossing veel oplevert en wat voor inspanning hierbij benodigd is. Dit geeft een goed beeld waar eventuele Quick Wins zijn opgenomen en hoe de winst per oplossing is gedefinieerd.

(29)

28 8. Logging en monitoring

In dit hoofdstuk wordt de oplossing logging en monitoring verder uitgewerkt. In de bevindingen en oplossingen komt naar voren dat er meer inzicht en grip in het proces

gerealiseerd moet worden. Voor de start van het onderzoek kwamen al een aantal vragen op dit gebied naar voren om te onderzoeken welke richting het beste aansluit bij de

dienstverlening. In dit hoofdstuk worden de requirements die gesteld worden aan deze

oplossing behandeld, de logging architectuur, logging per stap en de integriteit van de logging.

8.1 Requirements

Allereerst zijn gesprekken met de betrokken medewerkers gevoerd om de visie voor het loggen en monitoren van het proces te inventariseren. Binnen dit deel van het onderzoek zijn Product Managers en Tactisch Functioneel Beheerders bij het project betrokken. Er is gekozen hier geen Ontwikkelaar bij te betrekken aangezien het een advies op hoofdlijnen betreft en geen technische oplossing. Na het inventariseren van de visie van de betrokkenen is deze in een groepssessie teruggekoppeld en is de richting bepaald. Hierbij is vastgesteld dat er in eerste instantie alleen gekeken wordt naar de eisen vanuit de Tactisch Functioneel Beheerders aangezien het niet realistisch is om de eisen van de gehele afdeling mee te nemen.

Hierbij zijn de eisen in individuele gesprekken naar voren gekomen. Een aantal eisen die hierin naar voren komen zijn:

 Het kunnen volgen van leveringen;

 Track en Trace mogelijkheden om de levering, documenten en recepten inzichtelijk te maken en te koppelen;

 Monitoring op SLA’s;  Monitoring op afwijkingen;  Koppeling met de klant gegevens;  Koppeling met de distributeur gegevens;  Registratie per outputkanaal;

 Registratie van de gebruikte bestanden;  De logging moet generiek ingericht worden.

Daarnaast is het gewenst rekening te houden met de mogelijkheden van Document

Management. Zo moet het mogelijk blijven vanuit de logging gegevens generiek te kunnen doorbelasten en rapportages op te stellen.

8.2 Logging architectuur

Om de logging van het proces generiek te laten verlopen is er een logging architectuur opgesteld om een beeld te geven hoe de gewenste logging en monitoring functionaliteit ingericht dient te worden. Hierbij is gebruik gemaakt van een intern document waarin de loggingstandaarden worden geformuleerd (Groenewoud 2012). Tevens is deze architectuur doorgesproken met alle betrokken.

Allereerst is gekozen om dit buiten het standaard pakket PrintNet te realiseren, omdat:  De functionaliteit dan niet van PrintNet afhankelijk is en wanneer het pakket

vervangen wordt dit geen/weinig invloed heeft op de logging en monitoring functionaliteit. Daarnaast zullen de verwerkingsgegevens bewaard blijven en niet vergaan;