Operational excellence: continu verbeteren met procesmanagement

De term ‘procesmanagement’ gonst door ons vak. We willen opeens allemaal operational excellence. Wat is het en waar komt het vandaan?

Door: Matthijs van Otegem

Het bouwen van de digitale bibliotheek ging uitstekend in projecten. Vaak naast de ‘oude’ organisatie met een klein, slagvaardig team dat telkens een nieuw stukje opleverde. Maar de digitale bibliotheek is geen project meer. Het is de dagelijkse werkelijkheid.

In deze digitale bibliotheek zijn we sterker dan voorheen afhankelijk van elkaar. We selecteren, verwerken, beheren en bieden toegang, net als vroeger. Maar terwijl het toen niet uitmaakte voor beschikbaarstelling van wie je een boek kocht, is de toegang nu rechtstreeks afhankelijk van de voorwaarden die je afspreekt bij het verwerven van digitale content.

De keten grijpt sterker in elkaar. De stappen van selectie tot toegang kun je nietmeer zien als losse activiteiten die ieder voor zich kan uitvoeren. Het is een proces geworden: een systematische reeks handelingen om van input naar output te komen.

Het is net de EU: als er een land omvalt, hebben we er allemaal last van. En dat willen we beheersen: we willen de klant een bepaalde kwaliteit leveren en we willen dat die kwaliteit stabiel is. Een 24/7-service, zonder ‘maandagochtend-ebooks’.

Tools

We moeten ons proces dus managen. Rol de consultants maar naar binnen, want we hebben daarvoor tools nodig! Door al onze digitale bibliotheekprojecten zijn we gekneist in het meten van output: bijvoorbeeld met key performance indicators en/ of de balanced score card.1

Maar we weten vaak niet zo goed hoe we tot het resultaat komen en hoe het proces zich gedraagt door de tijd heen. Je kan alleen zien dat op een moment in het verleden iets niet goed ging. Niet waar het precies niet goed ging – en de klant van toen heeft niets meer aan ons inzicht van nu. De eerste stap is dus om het proces te beschrijven: wat gaat erin, wat komt eruit en wat gebeurt er daartussen? We kunnen de handelingen vastleggen, maar ook wat de input is per stap, de werkvoorraden, de doorlooptijden en/of wie welk werk verricht.

INK / CAF

Een populair instrument voor procesverbetering is het INK-model (zie figuur 1). Dit is een instrument voor kwaliteitsmanagement, maar niet toevallig staat procesmanagement hierin letterlijk centraal. In Europees verband staat dit bekend als het Common Assessment Framework (CAF).2

schematisch: INK-model

Als verbeterstrategie gebruikt INK de cyclus Plan, Do, Check en Act. Deze is erg op output gericht en dat is vooral goed toepasbaar in een productieomgeving. Logisch, want daar ligt ook de oorsprong ervan. Dit model is in bibliotheken nu het populairst, omdat het de hele organisatie bij de verandering betrekt en goed voorbereidt op certificering.

Een kritiekpunt op INK/CAF is dat het model moeilijk hanteerbaar zou zijn vanwege de vele aandachtsgebieden en de relaties daartussen. Bovendien is het erg gericht op de inhoud en niet op de mens. Daarom is hier inmiddels ook de IMWR-cyclus naast gekomen: Inspireren, Mobiliseren, Waarderen en Reflecteren, om ook de menselijke kant van de organisatie te ontwikkelen. Het model wordt er alleen niet eenvoudiger op.

Lean

Binnen Toyota is in de jaren zeventig Lean ontwikkeld. Lean heeft tot doel om een proces zodanig in te richten dat meerwaarde wordt gecreëerd voor de klant. De klant staat centraal en zijn vraag stuurt het proces: producten worden ‘just in time’ geleverd op basis van de vraag (pull), in plaats van uit voorraad (push). Wat niet bijdraagt aan klantwaarde, is verspilling.3

Het streven is om continu te verbeteren: niet zozeer ten opzichte van de concurrentie maar ten opzichte van wat maximaal haalbaar is. Work to perfection of operational excellence. Op de werkvloer wordt de waarde toegevoegd, niet in de directiekamer. In een Lean-organisatie krijgen medewerkers daarom een grote verantwoordelijkheid toebedeeld. Ook Lean kent de nodige kritiek. Het zou alleen leiden tot verbetering van de bestaande situatie en het zou innovatie belemmeren.

Six Sigma

Het doel van Six Sigma is om de variatie in het proces te beperken door fouten te elimineren. Six Sigma – zes keer de standaarddeviatie – is letterlijk een kwaliteitsnorm: 99,99966 procent is goed. Of anders gezegd: 3,4 fout per 1 miljoen stuks. De norm is de naam van de methode geworden.

Dit instrument volgt een vast stramien voor een procesverbetering en vraagt een kwantitatieve onderbouwing, vaak met behulp van statistiek. Het gaat om bewezen verbetering: geen ‘trial and error’, maar ‘first time right’.

De meest fundamentele kritiek op Six Sigma is dat het behoorlijk complex is om de statistiek correct toe te passen en daarmee daadwerkelijk in de praktijk een verbetering te halen in plaats van alleen in de spreadsheet. Daarom worden Lean en Six Sigma vaak tezamen gebruikt: het is zinloos om een significante verbetering te behalen in een aspect dat voor de klant geen waarde toevoegt.

Toepassingen in de bibliotheek

Welk model je gebruikt, hangt van je eigen situatie en voorkeur af. Maar dat we iets aan procesmanagement kunnen hebben, is duidelijk. Mits er tenminste sprake is van een proces. Een project is een prima werkvorm voor een eenmalige activiteit met een concreet einddoel in een bepaalde periode. Start je echter voor de zesde keer een digitaliseringsproject, dan moet je toch eens overwegen of procesmanagement iets voor jou is.

Een voorbeeld

In de Koninklijke Bibliotheek was digitalisering een van de eerste processen om te verbeteren. Hiervoor hebben we de combinatie van Lean en Six Sigma (LSS) gebruikt. Een LSS-verbeterproject doorloopt de volgende stappen:

  1. Define: Wat is het probleem? Wat is het proces? Wat is kritisch voor de klant?
  2. Measure: Hoe presteert het proces nu? Hebben we echt het probleem dat we denken te hebben? Wat is onze verbeterstrategie: moet de gemiddelde kwaliteit omhoog of moet de variatie kleiner?
  3. Analyze: Wat zijn de grondoorzaken? Kunnen we dit statistisch hard maken? (NB: geen trial & error.)
  4. Improve: Aanpassen van de significante variabelen om het proces te verbeteren.
  5. Control: Borgen dat je de afwijkingen bij kunt sturen voordat je buiten je toleranties komt.

We beginnen met de definitie: voor onze klanten is de hoeveelheid beschikbare digitale content zeer belangrijk: als ze kunnen kiezen tussen ‘meer’ of ‘beter’, kiezen ze tot nu toe nog steeds voor meer. Volume is dus de externe factor die kritisch is voor succes. Intern vertaalt zich dit naar kosten: hoe goedkoper we kunnen digitaliseren, des te meer kunnen we doen voor hetzelfde geld. Onze klant raakt ons proces hier dus op kostenefficiëntie. Om inzichtelijk te krijgen welke kosten binnen het project vallen, maken we een CTQ-break down (zie figuur 2).

schematisch: CTQ-break down

 

We zoeken naar wat critical to quality (CTQ) is en waar dat ons proces raakt. De klantvraag naar volume (externe CTQ) vertaalt zich door de kostprijs per pagina (interne CTQ). Deze 93 cent kunnen we weer uitsplitsen in interne personele kosten per pagina (33 cent), materiële kosten (18 cent) en uitbesteed werk (42 cent). Niet alle kosten zijn beïnvloedbaar. Uitbesteed werk ligt contractueel vast. Natuurlijk kunnen we opnieuw aanbesteden, maar dat is een ander project.

Nu moeten we het dus zoeken in de interne personele kosten van 33 cent. Ons projectdoel wordt de personele kosten per pagina omlaag krijgen: een verandering van het gemiddelde. Let op: een fantastische 10 procent kostenreductie in je project betekent dan voor de klant slechts een reductie van 3,5 procent.

Maar welk proces willen we nu verbeteren? Hiervoor is een SIPOC-plaatje (zie figuur 3) handig: een overzicht van Supplier, Input, Process, Output en Customer. Zo hoef je nog niet het hele proces uit te werken, maar zie je het proces op hoofdlijnen en wie erbij betrokken zijn. De stap ‘klaarmaken voor digitalisering’ is het meest arbeidsintensief. Daar registreren we het materiaal in een database en nemen het door op aspecten die voor de scanner belangrijk zijn: scheuren in pagina’s, uitklapprenten of tabellen die over meer bladzijden lopen. Als we willen besparen op arbeidstijd, zit daar de grootste kans. We weten nu genoeg in de definitiefase, het is tijd om te gaan meten.

 

schematisch: SIPOC

 

Analyse

Uit de productiemetingen bij de afdeling Digitalisering van de KB bleek al snel dat er enorme verschillen zaten tussen medewerkers. Gemiddeld maakte men 1200 pagina’s per uur klaar voor digitalisering, met een minimum van 600 en een maximum van 4000. Natuurlijk is de een wat sneller dan de ander, maar deze aantallen lopen te ver uiteen. Het proces was niet stabiel. Laten we daar eerst maar wat aan doen. Als we de uitschieters aan de onderkant zouden kunnen vermijden, stijgt het gemiddelde mee.

We gingen analyseren: wat veroorzaakt de onderlinge variatie? Hiervoor organiseerden we een brainstormsessie, waarbij we op zoek gingen naar de grondoorzaken. Een ‘ishikawa-diagram’, ook wel visgraatdiagram, is hiervoor een leuke werkvorm (zie figuur 4). Via een paar hoofdoorzaken graaf je door naar de diepere oorzaak door telkens ‘waarom’ te vragen. Met elke ‘waarom’ komt er een graatje bij. Al snel bleek dat onze methodes onderling heel verschillend waren. Door opschalen van het proces in aantallen scans was het halen, opslaan en terugsturen van de fysieke leggers een probleem geworden. Dat zijn stuk voor stuk zaken die je kan aanpakken. We hadden de individuele variatie in de productie per uur gemeten en getest met een hypothesetoets, het team vertelde het en we konden het ook zien door een ochtendje mee te draaien op de werkvloer. Nu de significante variabele was opgespoord en aangetoond, konden we aan de slag met de verbeterfase (improve).

Ishikawa-diagram

Beste werkwijze

De beste werkwijze hebben we gevonden door de snelste medewerkers aan de rest van het team te laten zien hoe ze werkten en dat als standaard te nemen. Het gemiddelde van de afdeling spoot vervolgens omhoog. Deze standaard heeft het team vastgelegd in een werkinstructie. Dat doet dus niet de teamleider: een werkinstructie is in feite de ‘best practice’ van het team en het team kan dit prima zelf beheren. Zo verdwijnt het ook niet ongebruikt in een bureaula. Daarnaast hebben we duidelijker afspraken gemaakt wie wanneer welk materiaal haalt en waar we het opbergen. Hiermee hebben we de verbeterfase afgesloten.

En dan bijhouden: control. Als de kosten per pagina voor onze klant zo belangrijk zijn, dan willen we wekelijks weten hoe we het doen… en of we niet nog iets kunnen verzinnen waardoor het nog beter kan. We meten nu per week de output en delen die door het aantal shifts per taak in het rooster. Dreigen we buiten onze toleranties te zakken, dan weten we dat snel genoeg. Andersom, als we er een paar keer boven zitten, hebben we weer iets te vieren.

Uiteindelijk heeft dit project een besparing opgeleverd van 2 cent per pagina. Bij een volume van 5 miljoen pagina’s in 2012 is dat toch 100.000 euro. Daarmee kunnen we weer meer digitaliseren.

Tot slot

Ik hoop duidelijk te hebben gemaakt hoe het komt dat procesmanagement steeds meer opgang maakt in de bibliotheekwereld. Je kan er behoorlijk veel plezier van hebben. Met dit voorbeeld uit de digitaliseringspraktijk is hopelijk ook helder geworden dat het geen hightech, ingewikkeld verhaal hoeft te zijn. Als je bereid bent kritisch naar je eigen werk te kijken en je pakt het systematisch aan, dan kom je een heel eind. De oplossing is lang niet altijd een duur it-project. Je kan zelf al veel doen met weinig middelen. En zo gaan we aan de slag met het verbeteren van onze processen. Oeps, ik hoop dat we toch vooral de uitkomsten van ons proces bedoelen. Daar heeft de klant tenminste iets aan. En daar is het allemaal om begonnen.

Noten

  1. Leo Waaijers, ‘Ervaringen in de TU Delft’ in: InformatieProfessional 4, nr. 5, p. 36-39, (2000). tinyurl.com/chl2vvt
  2. www.eipa.eu/en/topic/show/&tid=191
  3. Zie Matthijs van Otegem: ‘Backoffice op de voorgrond (8): Wat kost digitalisering… en wat levert het op?’ tinyurl.com/dycqw4n

Matthijs van Otegem is redacteur van InformatieProfessional.

Deze bijdrage komt uit IP nr. 4 / 2013. Het gehele nummer kun je hier lezen