Bert Teeuwen beschrijft in zijn boek Dagstarts en Hoshin Kanri - Continu Leren en Verbeteren in de juiste richting met Dagstarts en Hoshin Kanri het Lean-instrument van de Hoshin Kanri:

Hoshin Kanri is bedoeld om het verbeteren in de hele organisatie te richten naar hetzelfde doel, en om alle verbeteractiviteiten aan de doelen te koppelen. Leangoeroe Masaaki Imai:

"Hoshin Kanri is het proces om het beleid te internaliseren om continu te verbeteren, van hoog tot laag in de organisatie. Het roept iedereen op om het beleid te vertalen in het licht van zijn eigen verantwoordelijkheden... Zodat ze alleen maar tijd besteden aan het verbeteren in de gekozen richting."

De betekenis van het Japanse woord Hoshin is 'koers' of 'kompasnaald'. Kanri is 'managen' of 'beheersen'. De samenvoeging Hoshin Kanri betekent heel letterlijk zoiets als 'glanzend metaal dat de richting wijst', en meer toepasselijk: richting management, navigatiemanagement of met de Engelse term Strategy Deployment. Het Japans is een beeldende soms poëtische taal. De genoemde richting wordt wel aangeduid als 'Het Waarde Noorden'. Hoshin Kanri is de methodiek om dat ware noorden te benoemen en de weg er naar toe te bepalen.

Hoshin Kanri of Hoshin Planning werd in de zestiger jaren van de vorige eeuw ontwikkeld en toegepast bij Bridgestone Tyre Company en de Kobe Scheepswerf in Japan, en later bij bedrijven als Toyota en Komatsu. Inmiddels is de methodiek in aangepaste vormen overgneomen door veel organisaties in de hele wereld.

Hoshin Kanri heeft zes basiselementen:

(1) Catchball

Hoshin Kanri is een strategie-ontwikkelproces, waarbij de directie begint door een concept voor een strategisch plan te maken. Zij geeft die door aan onderliggende lagen in de organisatie om er feedback op te geven. Op basis van die feedback past de directie de plannen aan. Elke laag maakt op zijn beurt een vertaling van de strategische doelen in afdelingsdoelen. Daarop geven de directieleden dan weer feedback. De veelgebruikte term voor deze methodiek om consensus te krijgen voor de strategie is catchball. De producten van het strategische proces worden als een bal overgegooid, opgevangen, van commentaar voorzien en besproken, en dan naar de volgende 'geworpen'. Uiteindelijk ontstaat er een breed gedragen strategisch plan.

(2) Cascade van doelstellingen

Elke afdeling bepaalt aan de hand van het strategische plan een eigen set van doelstellingen, die passen bij de strategische doelen. Zo ontstaat een cascade van doelstellingen; met elkaar samenhangend en trapsgewijs van boven naar beneden lopend. Een doelstelling op afdelingsniveau halen is de oorzaak dat het halen van een doelstelling op het hoogste niveau dichterbij komt.

(3) PDCA-cylus als basisroutine

De basisroutine voor Hoshin Kanri is Plan-Do-Check-Act, de Deming-cyclus. In de Plan-fase wordt het strategische plan gemaakt en ontstaat de cascade van afdelingsdoelstellingen. Als Hoshin Kanri een jaarcyclus is, dan ligt de Plan-fase in het najaar. In het aansluitende jaar volgende de fasen Do-Check-Act: de strategie uitvoeren, de effecten bestuderen en bijsturen. In het najaar start dan weer de Plan-fase voor het komende jaar.

(4) X-matrix voor het verbinden van strategische doelstellingen en verbeteractiviteiten

Strategische doelstellingen en verbeteractiviteiten hebben een logisch verband. Een duidelijke oorzaak-gevolg-relatie. ALs we een bepaalde verbeteractiviteit succesvol afronden, zal die als gevolg een bijdrage leveren aan het realiseren van een afdelingsdoelstelling - een stapje in de juiste richting -, zodat de organisatie als geheel wat dichter bij haar geplande strategische doelen komt. Het instrument om deze oorzaak-gevolg relatie van doelen en middelen te visualiseren is de X-matrix.

(5) Continu leren en verbeteren in de juiste strategische richting met de prestatiedialoog

Dagelijks, wekelijks en maandelijks zijn er in alle lagen van de organisatie gesprekken over doelstellingen en verbeteractiviteiten. Het doel van deze gesprekken is continu leren en verbeteren in de juiste strategische richting. Dit gesprek heet de prestatiedialoog. Elke prestatiedialoog volgt de Plan-Do-Check-Act-routine, de Deming-cyclus.

(6) Dag- en/of weekstarts als epicentrum voor continu leren en verbeteren

Door de hele organisatie heen voert elk team, van directieteam tot productieteam, daar de prestatiedialoog. In deze korte en staande overleggen, streeft een team naar controle en beheersing van het proces, reageert snel op veranderingen en verbetert en experimenteert. Als het Hoshin Kanri-proces goed is gegaan, kun je het gesprek bij een willekeurige dagstart via de doelstellingen van het team herleiden naar de strategische richting van de organisatie.

Bron: Dagstarts en Hoshin Kanri - Continu Leren en Verbeteren in de juiste richting met Dagstarts en Hoshin Kanri, Bert Teeuwen

Bewaren

Bert Teeuwen beschrijft in zijn boek Dagstarts en Hoshin Kanri - Continu Leren en Verbeteren in de juiste richting met Dagstarts en Hoshin Kanri het risico op verbeteren om het verbeteren en het belang om wat er op de werkvloer en in vergaderzalen gebeurt af te stemmen op de strategische richting van de organisatie:

De term Kaizen - 'continu verbeteren' - nodigt uit om een cultuur te creëren waarin iedereen elke dag nadenkt over wat beter kan en hoe het beter kan. Dat zou ertoe kunnen leiden dat medewerkers alles gaan doen waar ze vandaag last van hebben. Maar bestaan er ook zoiets als ongewenste verbeteringen?

Verbeteren kost tijd en capaciteit, want er is een grondige analyse nodig en de oplossingen moeten uitgewerkt en ingevoerd worden. En tijd en capaciteit zijn schaars. Daar zou je verstandig mee om moeten gaan, door alleen tijd te besteden aan verbeteringen die in lijn liggen van een vooraf bepaalde richting en een gemeenschappelijk doel, waarbij de wens van de klant centraal staat. Het zou zonde zijn als de klanten de resultaten van alle aan verbeteringen bestede tijd niet kunnen waarderen.

(...)

De medewerkers kunnen beter nadenken over wat hun bijdrage aan de missie en de doelen van de totale organisatie is. En wat zij moeten verbeteren om de strategische doelen van de organisatie als geheel te realiseren. Wat zou het mooi zijn als iedere afdeling en elk team doelen najaagt, die perfect in lijn liggen met de doelen van de hele organisatie. ... En dat iedereen weet welke richting het op moet, en welke bijdrage hij daar aan kan leveren. "Vertel me waar we de komende jaren heen willen, zodat ik kan bepalen wat ik vandaag kan daaraan kan doen."

(...)

Wat zou het mooi zijn als de gesprekken op de werkvloer en in de vergaderruimten direct en indirect te linken zijn aan de strategische richting, dat de informatieborden op de afdelingen en de periodieke rapportages de strategie ademen. En dat er een heldere oorzaak-gevolg relatie is tussen de teamdoelen en de hoger liggende doelen. Dat iedereen uit kan leggen: als ons team zijn doelen haalt, draagt dat aantoonbaar bij aan de realisatie van de organisatiedoelen. Leidinggevenden en hun teams zouden dan zelf, aan de hand van de voor de organisatie bepaalde richting, moeten kunnen bepalen wat die voor hen betekent en welke doelen zij moeten nastreven en welke verbeteringen daarvoor nodig zijn.

Bron: Dagstarts en Hoshin Kanri - Continu Leren en Verbeteren in de juiste richting met Dagstarts en Hoshin Kanri, Bert Teeuwen

Bewaren

In het boek Scaling agile in organisaties - wegwijzer voor projectmanagers en agile teammanagers schrijft Henny Portman het volgende over Kanban:

Kanban in vogelvlucht

Inleiding

Kanban is van oorsprong een systeem uit de productie-industrie om voorraden mee te beperken en preciecs op tijd (just in time. of JIT) te leveren. Het is ontwikkeld door de japanner Taiichi Ohno bii de autoproducent Toyota (eerste versie in 1953). Dit systeem houdt overbelasting van het productieproces in de hand door te werken met bovengrenzen voor het aantal stukken onderhanden werk. Een stuk onderhanden werk wordt gevisualiseerd middels een signaalkaart. Het totaal aantal beschikbare kaarten geeft de beschikbare capaciteit van het betreffende station weer. Nieuw werk zal dus moeten wachten in een rij totdat een vrije kaart beschikbaar komt.

0p basis van Taiicho Ohno's Kanban-systeem is een Kanban-mahode ontwikkeld ter ondersteuning van kenniswerkers. Een van de eersten die hierover schreef was David ]. Anderson  (zie zijn in 2010 verschenen boek over Kanban) over de toepassing bij softwareontwikkeling.

Tegenwoordig zien we steeds meet disciplines gebruikmaken van Kanban-systemen om hun werk te managen, zoals marketing, productontwikkeling. personeelszaken. juridische zaken, auditing, et cetera. Veel implementaties gaan echter niet dieper dan een bord en de visualisatie van work?ow. Weinigen bereiken de diepgang die David J. Anderson promoot (namelijk metingen van allerlei tijden en actief WIP beheersen, et ectera).


De Kanban-filosofie

Kanban betekent letterlijk ‘signaalkaart' in het Japans. De belangrijkstc eigenschappen  van een Kanban-systeem zijn:

- Het te managen proces wordt opgedeeld in een aantal verschillende stappen.
- De werkstroom wordt gevisualiseerd.
- Het onderhanden werk is gelimiteerd.
- Doorlooptijden worden beheerst en gemeten.
- Prestatieafspraken, zoals het aantal eenheden onderhanden werk of doorlooptijd, worden vastgelegd.
- Er wordt veelvuldig gebruikgemaakt van feedbackloops (met het team en met de klant/opdrachtgever).
- De werkstroom kan onderverdeeld worden middels serviceklassen (incidenten, onderhoud, projecten).
- Het team maakt gezamenlijk afspraken hoe het werk gemanaged wordt.
- Het team verbetert gezamenlijk de werkwijze.
- Modellen worden gebruikt om verbeteringen te identi?ceren (bijvoorbeeld systeemtheorie).

Invoeren van een Kanban-systeem is een evolutionair proces.

Begin met de focus op kwaliteit.

Verlaag vervolgens het onderhanden werk. Als er te veel onderhanden werk in het systeem zit, betekent dit veelvuldig multitasken. Het tot een minimum beperken van multitasken,  resulteert in minder omschakelen en dus in minder verspilling. Dit is een belangrijke stap om daarmee uiteindelijk in dezelfde periode veel meer werk te kunnen realiseren.

Lever zo vaak mogelijk op en balanceer de vraag ten opzichte van de mogelijke doorvoer van werk. Prioriteer je invoerwachtrij en verhoog de voorspelbaarheid door beheersing van bronnen van variabiliteit in het systeem (bijvoorbeeld beschikbare sleutel?guren).

Breng indien nodig, voorafgaand aan probleempunten in het proces, buffers aan om daarmee de doorstroom te garanderen.


Het Kanban-systeem

Om een Kanban—systeem in te voeren kunnen de volgende stappen doorlopen worden:

- Bepaal het start— en het eindpunt van het proces, inclusief de tussenliggende stappen, en leg dit werkproces vast op een visueel besturingsbord zodat direct zichtbaar is wat de status is van het onderhanden werk en waar een speci?eke werkeenheid zich bevindt.

- Voeg wachtrijen en buffers toe om de doorstroom in het proces te beheersen.

- De?nieer de opzet van de signaalkaarten. Bepaal welke informatie hierop wordt vastgelegd (ID—nummer, naam, omschrijving, opnamedatum, eventueel harde opleverdatum, ...).

- Bepaal de grenzen aan het begin en bij de uitvoer van het proces. Aanleverende en ontvangende partijen Willen wellicht hun eigen werk ook kunnen zien op het Kanban-bord, maar focus eerst op je eigen proces. Neem aan het begin en eind een overeenkomstige wachtrij op en leg vast hoe en wanneer prioritering van de invoerwachtrij plaatsvindt en op welke wijze producten worden overgedragen naar de ontvangende partij.

- Bepaal voor iedere processtap het maximaal aantal werkeenheden onderhanden werk (de  WIP—limiet). Kan het systeem meer aan, dan is dat direct zichtbaar en kan er om nieuw werk gevraagd worden (treksysteem).

- Bepaal welke typen services worden geleverd. Iedere service kenmerkt zich door eigen afspraken over bijvoorbeeld verwachte doorlooptijd van realisatie en hoeveel van deze services tegelijkertijd in het systeem zich kunnen bevinden. Spreek af hoe de verschillende services zichtbaar zijn op het Kanban—bord. Bijvoorbeeld gele post—its voor standaard Wijzigingen, paarse post—its voor wijzigingen met een verplichte opleverdatum en grijze post—its voor wijzigingen met de hoogste prioriteit die direct opgepakt moeten worden. Blokkerende issues of knelpunten kunnen op rode post—its vastgelegd worden en aan een signaalkaart gekoppeld worden.

- Maak het zichtbaar als er gedurende het proces werkeenheden komen te vervallen. Dat biedt inzicht aan de aanvragers en verhoogt de kwaliteit van het vraagproces.

- Leg alle afspraken vast in serviceafspraken en beleidsrichtlijnen en evalueer regelmatig of er beleidsrichtlijnen moeten worden toegevoegd of aangepast.

- Meet de doorlooptijd per type service en optimaliseer het proces. Pas eventueel het aantal eenheden onderhanden werk aan om hiermee de doorlooptijd te verkorten en de voorspelbaarheid te vergroten.

Bron: Scaling agile in organisaties - wegwijzer voor projectmanagers en agile teammanagers, Henny Portman

Volgens adviesbureau Turner is Lean is een beproefde methode om te werken aan Operational Excellence (Opex):

Operational Excellence (‘Opex’) is de strategische keuze om de organisatie ‘beter, sneller, goedkoper en wendbaarder’ te maken. Doel is klanten beter te bedienen en de bedrijfsvoering continu te verbeteren.

(...)

Uw organisatie kan met Opex uw klanten beter bedienen en zichzelf en de medewerkers continu verbeteren. De prestaties voor klanten worden daardoor:

1. Beter - bv hogere kwaliteit, door minder fouten in het proces en minder afkeur van producten.

2. Sneller - bv kortere doorlooptijd en levertijd, door minder wachttijd.

3. Goedkoper - bv lagere kostprijs, door minder rework in het proces en herstelkosten.

4. Wendbaarder -- bv beheerster reageren op variaties in klantvraag, door meer ‘grip’ op de bedrijfsprocessen.

Bron: Lean is van het Team, Turner

Rijnconsult hanteert de onderstaande vragenlijst - bestaande uit 40 vragen - om te beoordelen hoe lean een organisatie is.
Elke vraag wordt gescoord op een vijfpuntsschaal, met als mogelijke opties:

- Geen idee/weet ik niet
- Helemaal NIET waar
- Een beetje waar
- Bijna helemaal niet waar
- Helemaal waar

In een spinnenwebdiagram wordt de eindscore samengevat in 8 thema's:

1. Toegevoegde waarde en kwaliteit.

2. Standaardisatie en werkwijzen.

3. Processen en flow.

4. Stabiliteit van processen.

5. Problemen oplossen.

6. Dagelijks management.

7. Leren en ontwikkelen.

8. Formuleren en doorvertalen van doelstellingen

Lean-vragenlijst

• Wij weten wie onze klanten zijn en welke waarde wij toevoegen
• Afwijken van de standaard wordt niet geaccepteerd
• Processen worden geanalyseerd op en door de werkvloer
• Onze planningen zijn gericht op een gelijkmatige verdeling van de werklast/werkcapaciteit
• Problemen worden opgelost op en door de werkvloer
• Op ieder niveau in onze organisatie weten wij wat er aan de hand is (transparantie)
• Wij mogen fouten maken als we er maar van leren
• Onze doelstellingen zijn een afgeleide van de doelstellingen van de organisatie
• Iedereen weet dat alles wat hij doet waarde moet toevoegen voor onze klanten
• Wij gebruiken standaarden (procedures, werkwijzen) in onze organisatie
• Het vraagritme van de klant is de hartslag voor al onze processen
• Wij weten wanneer wij een afwijkende hoeveelheid werk hebben en sturen daarop
• Klachten zijn een trigger om problemen te signaleren
• Wij grijpen pas in als we begrijpen hoe het systeem functioneert en presteert
• Wij worden regelmatig opgeleid
• Individuele doelstellingen zijn onderdeel van een persoonlijk ontwikkelingsplan
• Wij voeren regelmatig klanttevredenheidsonderzoeken uit
• Onze medewerkers ontwikkelen gezamenlijk hun standaarden
• Omschakeltijden minimaliseren is een permanente uitdaging voor de organisatie
• Beschikbaarheid van apparatuur en/of ICT systemen is geen belemmering
• Oplossen van problemen is team-werk
• Wij kennen onze prestaties en verstoringen door gebruik te maken van visuele hulpmiddelen
• Wij leren van onze fouten door ze met elkaar te bespreken
• Voor iedereen is helder welke bijdrage hij/zij levert aan het (team) resultaat
• Wij betrekken onze leveranciers in ons kwaliteitsysteem
• Onze standaarden beschrijven de op dit moment beste werkwijze
• Onze processen kennen weinig verspilling
• Wij zijn gericht op het realiseren van constante kwaliteit van onze output
• Voordat wij oplossingen bedenken weten wij wat het echte probleem is
• Wij hebben voortgangsrapportages op acties/implementatie van verbeteringen
• Wij geven en ontvangen feedback van elkaar
• De organisatiedoelstellingen zijn doorvertaald tot op individueel niveau
• Onze klanten zijn zonder meer tevreden over de kwaliteit van onze producten en diensten
• Onze standaarden worden na iedere verbetering bijgewerkt
• Tussenvoorraden worden overal minimaal gehouden
• Onze medewerkers zijn competent om de processen goed uit te voeren
• Wij volgen de effecten van ingevoerde verbeteringen
• Wij evalueren dagelijks/wekelijks/maandelijks/jaarlijks
• Wij hebben een persoonlijk ontwikkelingsplan
• Onze doelstellingen zijn SMART (specifiek / meetbaar / acceptabel / realistisch / tijdgebonden)

 

Bron: Hoe lean is uw organisatie?, Rijnconsult

In het boek Kanban and Scrum - making the most of both beschrijven Henrik Kniberg en Mattias Skarin het Lean-instrument van de Kanban:

Kanban is based on a very simple idea. Work in Progress (WIP) should be limited and something new should be started only when an existing piece of work is delivered or pulled by a downstream functioe. The kanban (or signal card) implies that a visual signal is produced to indicate that new work can be pulled because current work does not equal the agreed limit.

(...)

The principle of Kanban is that you start with whatever you are doing now. You understand your current process by mapping the value stream and then you agree to WIP limits for each stage in that process. You then start to flow work through the system by pulling it when kanban signals are generated.

(...)

Because WIP is limited in a Kanban system, anything that becomes blocked for any reason tends to clog up the system. If enough work items become blocked the whole process grinds to a halt. This has the effect of focusing the whole team and the wider organization on solving the problem, unblocking the item and restoring flow.

Kanban uses a visual control mechanism to track work as it flows through the various stages of the value stream. Typically, a whiteboard with sticky notes, or and electronic card wall system is used.

(...)

Kanban exposes bottlenecks, queues, variability and waste - all of which are things which impact the performance of the organization in terms of the quantity of valuable work deliverd and the cycle time required to deliver it. Kanban provides team members and external stakeholders with visibility into the effect of theri actions (or inactions.) As such, early case studies are showing that Kanban changes behavior and encourages greater collaboration within the workplace. The visibility into and impact on bottlenecks, waste and variability also encourages discussion about improvements, and teams quickly start implementing improvements to their process.

(...)

Through the nature of the pull system, Kanban also encourages delayed commitment on both prioritization of new work and delivery of existing work. ... This improves agility by managing expectations, shortening cycle times from commitment to delivery and eliminating rework since the change that priorities will change is minimized.

One final word on Kanban is that the effect of limiting WIP provides predictability of cycle time and makes deliverables more reliable. The "stop the line" approach to impediments and bugs also appears to encourage very high levels of quality and a rapid form of rework.

 

(...)

 

Kanban in a nutshell

(1) Visualize the workflow

• Split the work into pieces, write each item on a card and put on the wall
• Use named columns to illustrate where each item is in the workflow

(2) Limit Work in Progress (WIP)

Assign explicit limits to how many items may be in progress at earch workflow state.

(3) Measure the lead time (average time to complete one item, sometimes called 'cycle time'), optimizing the process to make lead time as small and predictable as possible.

 

(...)

Summaryof Scrum vs. Kanban

Similarities
· Both are Lean and Agile
· Both use pull scheduling
· Both limit WIP
· Both use transparency to drive process improvement
· Both focus on delivering releasable software early and often
· Both are based on self-organizing teams
· Both require breaking the work into pieces
· In both, release plan is continuously optimized based on empirical data (velocity / lead time)

Differences

Scrum	Kanban
Timeboxed iterations prescribed.	Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed.
Team commits to a specific amount of work for this iteration.	Commitment optional.
Uses Velocity as default metric for planning and process improvement.	Uses Lead time as default metric for planning and process improvement.
Cross-functional teams prescribed.	Cross-functional teams optional. Specialist teams allowed.
Items must be broken down so they can be completed within 1 sprint.	No particular item size is prescribed.
Burndown chart prescribed.	No particular type of diagram is prescribed.
WIP limited indirectly (per sprint)	WIP limited directly (per workflow state)
Estimation prescribed	Estimation optional
Cannot add items to ongoing iteration.	Can add new items whenever capacity is available
A sprint backlog is owned by one specific team	A kanban board may be shared by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team)	Doesn’t prescribe any roles
A Scrum board is reset between each sprint	A kanban board is persistent
Prescribes a prioritized product backlog	Prioritization is optional.

Bron: Kanban and Scrum - making the most of both, Henrik Kniberg & Mattias Skarin

In een 2-delige serie over Lean projectmanagement geeft Jaap van Ede hoofdredacteur van www.procesverbeteren.nl elf tips voor het realiseren van meer flow in projecten. Hieronder een aantal - meer algemene - fragmenten uit de 2 artikelen:

Voor procesverbetering zijn tenminste drie zaken nodig:

(1) Een besturingssysteem dat de flow reguleert. Denk bijvoorbeeld aan het voorkomen van pieken en dalen in de capaciteitsvraag. Pas als processen redelijk voorspelbaar verlopen, is er een basis voor procesverbetering.

(2) Het is zichtbaar wat er op dit moment gebeurt: zijn er afwijkingen, dreigende problemen, of bottleneck.

(3) Het is bekend waar de prioriteit ligt: wat is het overkoepelende doel, en hoe kun jij daaraan vanaf jouw werkplek bijdragen?

Is de flow beheersbaar, zichtbaar en weet je wat jij of je team als eerste daaraan moet verbeteren, dan kan stapsgewijs worden gewerkt aan verbetering. Dit gebeurt binnen Lean via ‘wetenschappelijke’ experimenten. Hypothesevorming en testen, uiteraard binnen veilige grenzen. ‘Beter’ is daarbij een productiesysteem dat nog steeds stabiel is, ondanks lagere buffers qua (tussen)voorraad, tijd en/of capaciteit. Feitelijk is het systeem dan een stukje ‘sneller’ geworden!

Hoewel de principes van procesverbetering gelijk blijven, zijn deze moeilijker toe te passen naarmate de producten of diensten meer klantspecifiek zijn. In het meest extreme geval is elk product een uniek project. Het uitvoeren daarvan vergt een zekere mate van creativiteit, waardoor het proces niet volledig voorspelbaar is. De onzekerheid en complexiteit worden nog verder vergroot, als bij de uitvoering meerdere partijen zijn betrokken.

(...)

Tip 1. Standaardiseer en modulariseer
De eerste tip is: voorkóm dat je maatwerk moet leveren! Een klant kan je producten of diensten dan als klantspecifiek ervaren, terwijl ze achter de schermen worden opgebouwd uit standaardonderdelen.

(...)

Tip 2. Doorgrond de klantwens
Achterhaal allereerst wat de klant precies wil, zodat je geen onnodige features toevoegt die producten complexer maken dan nodig. In het boek The Toyota Product Development System van Morgan & Liker staat een anekdote over een chief engineer van Toyota. Die reed heel Noord-Amerika rond met een minibusje, om te onderzoeken wat de gebruikers daarvan vonden. Het bleek onder meer belangrijk er voor te zorgen dat grote platen hout erin pasten.

Het go to the gemba principe (bezoek de plaats waar het gebeurt) werd zo toegepast in de omgeving van de klant. Oplossingen voor kleine ergernissen kunnen vaak een bijzondere propositie opleveren.

Bij het definiëren van de klantwens gaat het om de behoefte, lees: wat is waardevol voor een klant en waarom. Hoe dat technisch wordt ingevuld komt pas daarna. Het kan zelfs nodig zijn om een klant te assisteren bij het formuleren van zijn of haar wensen.

(...)

Tip 6. Creëer stapsgewijs waarde
Soms is het niet mogelijk om in één keer te weten wat een klant wil, omdat de klant een product eerst moet ervaren om te weten of het bevalt. Dit is vaak het geval bij software, en is één van de redenen waarom grote IT-projecten vaak mislukken. Bij de oplevering blijkt het dan bijvoorbeeld toch niet het systeem te zijn wat de gebruikers hadden gedacht!

Bron:

• Lean projectmanagement: Elf Tips voor flow [1], Jaap van Ede
• Lean projectmanagement: Elf Tips voor flow [2], Jaap van Ede

In het boek Six Sigma - stap voor stap beschrijven Volgens Ronald Does en Jeroen de Mast de DMAIC-fase Measure. Deze fase bestaat uit drie stappen:

1. Selecteren van de interne CTQ's.

2. Operationaliseren van de CTQ's.

3. Valideren van de meetprocedure.

 

[1] Selecteer een interne CTQ en de bijbehorende processen

Alvorens pogingen ondernomen worden om een probleem op te lossen, is het belangrijk eerst het probleem duidelijk te definiëren en meetbaar te maken. Veel problemen manifesteren zich als een wazige brij en het uiteenrafelen van deze brij, zodat het echte probleem duidelijk wordt, is de eerste stap bij (Lean) Six Sigma-projecten. Het niet scherp definiëren van het probleem is één van de meest gebruikelijke oorzaken van de mislukkende projecten.

Een probleem niet kunnen meten betekent dat niet vastgesteld kan worden hoe groot het probleem is en dat niet vastgesteld kan worden of het probleem opgelost is. Vaak is het zelfs niet helder welke richting als verbetering en welke als verslechtering aangeduid moet worden.

Het probleem moet daarom geformuleerd worden in termen van één of meer meetbare grootheden die van belangrijk zijn voor een klant. Deze grootheden heten CTQ's, of Critical to Quality.

Er kunnen twee soorten CTQ's worden onderscheiden:

1. Externe CTQ's: eigenschappen van een product of dienst. Een externe CTQ representeert het perspectief van de klant en is vaak tamelijk vaak en dubbelzinnig.

2. Interne CTQ's (of kortweg: CTQ's): metingen in het proces. Interne CTQ's zijn de metingen waarmee de producent de externe CTQ's bewaakt. Ze zijn concreet en meetbaar.

De externe CTQ volgt rechtstreeks uit de projectselectie. De vertaling van externe CTQ naar een of meer interne CTQ's is het doel van de eerste stap van de DMAIC-fasering. Idealiter correspondert de externe CTQ direct met een interne CTQ. Maar vaak moet een grondige analyse verricht worden om geschikte interne CTQ's te vinden.

(...)

Er zijn verschillende technieken voor het koppelen van externe CTQ's aan interne CTQ's. We onderscheiden vijf gevallen:

1. De externe CTQ is een meting in het proces. De interne CTQ is dan gelijk aan de externe CTQ en stap 1 is klaar.

2. Er is een duidelijk verband tussen de externe CTQ en één of meer metingen in het proces. We kunnen dit vaststellen met een statistische techniek die correlatie heet. De metingen die met de externe CTQ's correleren, zijn de interne CTQ's.

3. De externe CTQ is de som van een aantal grootheden. Met een CTQ-flowdown of een Pareto-analyse selecteren we die grootheden als interne CTQ's, die de belangrijkste bijdrage leveren aan de externe CTQ.

4. De externe CTQ's heeft een aantal dimensies. Met een boomdiagram analyseren we welke dimensies we kunnen onderscheiden.

5. Tijdens de projectselectie is slechts een product, dienst of proces aangegeven zonder een duidelijke externe CTQ. De BB moet dan zelf op zoek naar grootheden die van belang zijn voor klanten. Dit onderzoek heeft Customer-Needs Mapping.

 

Ad (2) De externe CTQ correleert met grootheden in het proces: correlatie

Twee grootheden zijn gecorreleerd als grotere waarden van de één neigen samen te vallen met grotere (of juist kleinere) waarden van de ander. (...) Indien de externe CTQ sterk correleert met een meting in het proces, selecteren we deze meting als interne CTQ.

(...)

De mate waarin twee grootheden gecorreleerd zijn, wordt uitgedrukt in de correlatie-coëfficiënt. Dit is een getal tussen 1 en -1, waarbij de waarde 1 duidt op een één-op-één-verband tussen beide grootheden en de waarde -1 op een één-op-één negatief verband.

 

Ad (3) De externe CTQ is de som van een aantal grootheden: CTQ flowdown, Pareto

[Door gebruik te maken van een CTQ flowdown] wordt de externe CTQ uiteengerafeld in zijn componenten, waarbij de bijdrage van iedere component wordt gekwantificeerd (deze bijdragen moeten samen natuurlijk sommeren tot de totale waarde die in de top genoemd wordt). (...) Indien een CTQ-flowdown uit slechts één niveau bestaat, wordt vaak gekozen voor de alternatieve weergave, een zgn. Pareto-kaart. Deze kaart geeft duidelijk aan welke van de deelgebieden de grootste bijdrage hebben en welke de kleine visjes zijn.

 

Ad (4) De externe CTQ heeft een aantal dimensies: boomdiagram

De externe CTQ ontleden in een aantal aspecten, waarbij elke dimensie - indien mogelijk - vervolgens verder wordt gesplitst. Deze analyse kan visueel worden weergegeven in de vorm van een boomdiagram.

 

Ad (5) Een project zonder duidelijke CTQ: Customer Needs Mapping

Leidraad in Customer-Needs Mapping (CNM) zijn drie vragen:

1. Wie zijn de klanten?

2. Wat leveren we aan de klanten?

3. Welke eigenschappen van de geleverde producten of diensten zijn van belang voor de klanten?.

(...)

[Het Kano-model is één van de instrumenten om de wensen van de klant te achterhalen] Dit model geeft grafisch weer de mate van klanttevredenheid (verticale-as) naarmate een leverancier beter of slechter presteert op een bepaalt aspect (horizontale as). De eigenschappen die Performance Satisfiers genoemd worden, zijn de aspecten waarop de kwaliteit van een product of dienst doorgaans beoordeeld wordt. ... Voor deze eigenschappen geldt: Hoe beter erop gepresteerd wordt, des te tevredener is de klant.

Maar andere aspecten zijn moeilijker te achterhalen. De eigenschappen die met dissatisfiers zijn aangeduid zijn kwaliteitsaspecten die de klant vanzelfsprekend vindt. ... Omdat klanten deze eigenschappen vanzelfsprekend vinden, leidt het in orde zijn slechts tot een neutrale reactie. Maar het in gebreke blijven kan tot grote ergernis leiden! Bovendien moet de BB zich realiseren dat deze eigenschappen niet snel als belangrijk worden genoemd door de klant, simpelweg omdat deze ze als vanzelfsprekend beschouwd.

De eigenschappen die met delighters zijn aangeduid zijn juist aspecten die klanten niet verwachten. Het ontbreken van zulke zaken zal daardoor door klanten niet als negatief worden ervaren, terwijl de leverancier er wel mee kan scoren. De BB moet zich realiseren dat delighters niet noodzakelijkerwijsuit klanteninterviews naar voren komen.

Procesbeschrijving

Omdat de CTQ's en de invloedsfactoren onderdeel zijn van het (productie)proces, is het van belang dat de BB dit in kaart brengt om er een adequaat beeld van te hebben. Een procesbeschrijving maakt expliciet hoe de relevante processen in de praktijk gevoerd worden. Bovendien maakt een procesbeschrijving vaak evidente verbetermogelijkheden manifest, wat to snelle, makkelijke verbeteracties leidt.

Om een procesbeschrijving te maken , begint de BB op macro-niveau door het maken van een zgn. SIPOC, waarbij de toeleveranciers van het proces (Suppliers), de invoer die ieder van deze toeleveranciers levert (Input), de start van het proces (Process), het eindpunt van het proces (Output) en de klanten van het proces (Customers).

[2] Operationaliseer CTQ (definieer standaarden)

Met het bepalen van een interne CTQ heeft de BB het onderwerp van zijn project gekoppeld aan een meting. Maar daarmee heeft hij nog geen precieze definitie van zijn probleem gegeven. Om de probleemdefinitie precies te maken, moeten de volgende zaken worden gespecificeerd:

1. Meetprocedure: met welk apparaat wordt de CTQ gemeten en wat is de procedure? Waar in het proces wordt de meting verricht?.

2. De eenheid die wordt gemeten: de eenheid is het 'ding' of de 'zaak' waarvan de CTQ een eigenschap is. Let op: hiermee wordt dus niet de meeteenheid bedoeld! De verzameling van alle eenheden wordt de populatie genoemd. De BB moet aangeven wat hij als eenheid beschouwt, maar hij moet ook de populatie begrenzen.

3. De eisen: de BB geeft aan voor welke waarden van de CTQ een gemeten eenheid als 'defect' wordt beschouwd, bijv. in termen van specificatiegrenzen.

Wanneer de BB bovenstaande zaken heeft vastgelegd, zeggen we dat het probleem operationeel gedefinieerd is. Dat wil zeggen dat is vastgelegd welke handelingen verricht moeten worden om vast te stellen hoe groot het probleem is. Voor iedere eenheid van de gedefinieerde populatie (2) kan met de aangegeven meetprocedure (1) de waarde van de CTQ bepaald worden. Door deze waarden te vergelijken met de vastgelegde eisen (3) kan bepaald worden welk percentage van de eenheden voldoet. Dit percentage geeft de omvang van het probleem weer.

[3] Valideer de meetprocedure

Vanwege het belang dat Six Sigma hecht aan data, dient de BB de betrouwbaarheid van de meetprocedure die hij gedefinieerd heeft na te gaan.

Validiteit

De eerste vraag die de BB zich moet stellen over de meetprocedure is: 'Geeft het resultaat van de meting inderdaad de eigenschap weer die ik denk te meten?' Vooral wanneer de BB gegevens gebruikt uit en computersysteem, is het van eminent belang dat hij de definities van de opgeslagen statistieken verifieert.

Twee onderwerpen die vaak een rol spelen, zijn:

• Meten we de juiste aspecten van de CTQ?
• Verstrengelt de meetprocedure de CTQ met verstorende invloeden?

Verstrengeling met verstorende invloeden

De uitslag van meetmethoden hangt natuurlijk af van de waarde die gemeten wordt. Vaak hebben verstorende invloeden echter ook een belangrijke invloed op het resultaat van de meting.

(a) Systematisch meetfout

Als het mogelijk is voor een CTQ om over de 'werkelijke waarde' ervan te spreken, kunnen we de zogenaamde systematische meetfout bestuderen. Een synoniem voor systematische meetfout is onzuiverheid. De systematische meetfout is het verschil tussen de werkelijke waarde van een CTQ en de gemiddelde waarde die een meetprocedure geeft.

(b) Toevallige meetfout: herhaalbaarheid en reproduceerheid

Indien een eenheid verschillende malen gemeten wordt met een meetsysteem, zal niet iedere keer precies dezelfde waarde gevonden worden. Deze variatie, die zichtbaar wordt indien een enkele eenheid meerdere malen gemeten wordt, is de meetspreiding. Vergelijken we het resultaat van een meting met de werkelijke waarde, dan is het verschil toe te wijzen aan enerzijds de systematische meetfout en anderzijds de toevallige meetfout die wordt veroorzaakt door de meetspreiding.

(...)

Om inzicht te krijgen in de meetspreiding doet de BB een experiment, Gage Repeatability & Reproducibilit study (Gage R&R studie) genoemd. Een dergelijk experiment bestaat uit het herhaaldelijk meten van een eenheid met hetzelfde meetinstrument (de 'gage'). Als de metingen zo identiek mogelijk worden verricht (vlak na elkaar en door dezelfde persoon) zal de waargenomen spreiding het best haalbare vertegenwoordigen. Deze spreiding heet herhaalbaarheid (of in het Engels: Repeatability). Als deze metingen voor een deel worden verricht door andere personen en op een ander moment, zal de spreiding groter zijn. Deze extra spreiding wordt de reproduceerbaarheid (of in het Engels: Reproducability) genoemd.

(...)

Conclusie

De volgende stappenmoeten worden voltooid voor de Measure-fase:

(1) Selecteer een interne CTQ

• Vertaal de externe CTQ naar één of meer interne CTQ's
• Beschrijf de bijbehorende processen
• Geef aan in de procesbeschrijving waar de interne CTQ's gemeten woden.

(2) Operationaliseer de CTQ's

• Definieer de meetprocedure
• Specificeer welke eenheid gemeten wordt
• Specificeer de eisen aan de CTQ

(3) Valideer de meetprocedure

• Controleer de validiteit van de meetprocedure
• Indien van toepassing, bepaal de systematische meetfout
• Bepaal de meetspreiding (herhaalbaarheid en reproduceerbaarheid)
• Indien de meetprocedure op de bovengenoemde punten niet voldoet: verbeter de meetprocedure

Bron: Six Sigma - stap voor stap, Ronald Does & Jeroen Mast

In het boek Leidinggeven aan Lean transformatie - Leading with Lean beschrijft Philip Holt zijn variant van de impact/inspannings-matrix. Hij introduceert zijn 'mogelijkhedencorridor' als methode voor het prioriteren van problemen:

Een veelgemaakte fout ... is alleen te focussen op problemen die groot zijn, dat wil zeggen, de grootste potentiële impact qua verbetering hebben, maar, uiteraard, ook de meeste inspanning kosten. Dit is een veelgemaakte fout in organisaties waar alleen 'experts' problemen oplossen en het resultaat is vaak dat problemen die kleiner zijn, maar die tezamen een grotere impact hebben, blijven doorwoekeren.

In operationeel uitmuntende organisaties lost iedereen problemen op, waardoor prioritering plaatsvindt langs de 'mogelijkhedencorridor'. Daarbij worden een paar grote problemen opgelost via projecten, een behoorlijk aantal problemen worden opgepakt in meerdaagse, cross-functionele 'Kaizen events', en heel veel problemen worden op dagelijkse basis door de teamleden opgelost via 'Kaizen', soms ook wel 'Quick and Easy Kaizen' (QEK) genoemd, of snel en gemakkelijk Kaizen.

De meeste problemen worden linksonder opgepakt, omdat ze snel en gemakkelijk op te lossen zijn en daarom zullen de teamleden zelf de probleemoplossing op zich nemen.

Een heel belangrijke kanttekening bij het prioriteringsproces is dat problemen die met veiligheid te maken hebben altijd meteen bovenaan de lijst moeten komen, en kwaliteitsgerelateerde kwesties hoeven alleen te wijken voor veiligheid. Een safety first, quality always-benadering is een voorwaarde voor excellence en moet dus een vanzelfsprekendheid zijn in onze probleemoplossings-mindset.

Als de keuze welke problemen opgelost moeten worden eenmaal is gemaakt, zijn zorgvuldigheid en discipline vereist om de problemen snel en effectief op te lossen. Maar het feit dat de tijd is gekomen om te prioriteren, betekent dat de teamleden die deze taak krijgen meer tijd zullen hebben om te focussen op deze 'paar uitverkorenen' en dus niet worden overspoeld met de 'vele hoopvolle'. Steun van leiders voor de snelle oplossing van de problemen is essentieel, waarbij de term 'snel' afhangt van de schaal van het probleem. De problemen linksonder in de mogelijkhedenmatrix zouden heel snel moeten kunnen worden opgelost, wellicht binnen een uur of zo, maar in elk geval binnen een dag of twee. De problemen rechtsboven daarentegen, kunnen aanzienlijk langer in beslag nemen en kosten wellicht enkele maanden om helemaal af te ronden.

Wat belangrijk is, is dat het proces van probleemoplossing gegeven het probleem zo snel mogelijk verloopt, en dus niet traag is door overbelasting van de teamleden en de daarmee samenhangende wachttijden. Hierin spelen de leiders een rol.

Een ander cruciaal element van 'probleemoplossing' als de manier-van-werken, is dat de oplossingen die worden ingevoerd ook duurzame oplossingen moeten zijn. Nogmaals, duurzaam is een relatief begrip, aangezien in sommige gevallen de oplossing korte termijn kan zijn om het verminderen van het probleem totdat een langere termijn oplossing wordt geïmplementeerd. Dit is een van de redenen dat de term 'oplossing' in veel Lean denken-organisaties zelden wordt gebruikt. Zij geven de voorkeur aan de term 'tegenmaatregel', omdat die, van nature, altijd tijdelijk is, alleen met verschillende niveaus van tijdelijkheid. Daarom zul je het gebruik van korte termijn en lange termijn tegenmaatregelen tegenkomen, maar nooit permanente, omdat het probleem op de langere termijn altijd beter kan worden opgelost, dat is immers de essentie van continu verbetering en een Kaizen-cultuur.

Bron: Leidinggeven aan Lean transformatie - Leading with Lean, Philip Holt