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:

De kern van elke dagstart is de dialoog. De letterlijke betekenis van het woord dialoog is een gesprek tussen twee of meer mensen. Het is een samensteling van de Griekse woorden dia (door) en logos (woord, taal of rede). Een prestatiedialoog is in essentie een gesprek over de prestaties. Wat je daarvoor nodig hebt is een of meer indicatoren die een gemeten prestatie laten zien, en een vaste route waarlangs het gesprek over die prestaties loopt.

Elke prestatiedialoog volgt een vast patroon, een vaste routine, namelijk de Plan-Do-Check-Act-cyclus. [William Edwards Deming vond dat de term Check lijkt op controleren. Het woord wekt de suggestie dat je alleen maar hoeft te beoordelen of het probleem nu weg is en het doel gehaald. Ook heeft Check in het Engels als tweede betekenis in toom houden. Wat Deming betreft is Check het bestuderen van alle effecten van oplossingen, ook de (mogelijke onverwachte en ongewenste) bijeffecten. Om daarvan te leren. Deming stelde voor om van PDCA de PDSA-cyclus te maken, waarin de S staat voor Study: bestudeer de effecten en leer daarvan. Tevergeefs. Vrijwel iedereen gebruikt PDCA. En dat is prima, zolang je de brede betekenis van Check toepast zoals Deming die voor ogen had.

(...)

Voor een prestatiedialoog heb je prestatie-indicatoren nodig. Dat zijn meetpunten die een indicatie geven hoe goed het gaat met het proces, het werk en de kwaliteit van de producten. Teams gebruiken de meetwaarden die de prestaties weergeven om te beoordelen of het proces en hun werk goed loopt of bijsturing nodig heeft. Ook laten prestatie-indicatoren zien of ingezette verbeteracties de gewenste effecten geven.


-------------------

In de PDCA-cyclus staat Plan voor het begrijpen en analyseren van een probleem of situatie en het bedenken van oplossingen, Do voor het toepassen van die oplossing in de praktijk of in een test, Check voor het bestuderen van de effecten ervan en Act voor het bijsturen en borgen.

De Plan-fase is opgedeeld in drie stappen (Begrijpen - Verklaren - Oplossen):

(1) Begrijpen we de huidige situatie?

• Wat is de huidige prestatie?
• Wat zien we nog meer als we naar de huidige situatie kijken?
• Begrijpen we het proces? Begrijpen we het probleem?
• Naar welk niveau willen we de prestatie tillen? (verbeteren naar de doelstelling)
• Of is herstellen naar de norm voldoende? (terugbrengen binnen de normen of regelgrenzen)

(2) Kunnen we het probleem verklaren?

• Wat hindert ons om op dat niveau te presteren? (obstakels)
• Waarom zijn die obstakels er? (verklaringen en bronoorzaken)
• Of fundamenteler: wat zijn de onderliggende principes van onze manier van werken, en waarom hebben we die? (de principes en het 'waarom' van wat we doen en van het proces)

(3) Hoe kunnen we het probleem oplossen?

• Hoe kunnen we die obstakels wegnemen? (tegenmaatregel of oplossing)
• Wat verwachten we van de gekozen oplossing? (verwachtingen)

Check-fase

• Welke gewenste en ongewenste effecten hebben we gezien?
• Wat kunnen we leren van de effecten van deze oplossing?

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

Marcel van Assen, Gerben van den Berg en Paul Pietersma schrijven in hun boek Het Groot Managementmodellenboek - 70 essentiële modellen: inhoud, toepassing, analyse en referenties het volgende over Six Sigma:

De kern

De naam Six Sigma komt oorspronkelijk uit de statistiek: sigma is het wiskundig symbool voor de standaarddeviatie. Six Sigma is een maat voor het maximum aantal defecten dat binnen een systeem is toegestaan. Op het Six Sigma-niveau moet 99,999998% van alle producten goed zijn ofwel binnen de tolerantiegrenzen vallen. Dit betekent dat er niet mee dan 3,4 defecten worden gemaakt per miljoen gevalle. Dit niveau kan bereikt worden door de variatie van het proces te beperken en te beheersen. Om dat kwaliteitsniveau te bereiken moeten de processen worden verbeterd. Maar proces- en kwaliteitsverbetering vormen niet het uiteindelijke doel; dat is financiële verbetering.

Six sigma raakte het eerst in zwang bij Motorola. Om de zware Japanse concurrentie het hoofd te bieden, begon Motorola zich in 1987 te concentreren op kwaliteitsverbetering. Motorola's ingenieurs besloten dat de norm die ze gebruikten voor defecten per duizend niet langer houdbaar was. Daarom besloten ze om het aantal defecten per miljoen te meten. Allied Signal en General Electric hebben de methode vervolgens geperfectioneerd. Deze bedrijven hebben enorme winsten behaald door miljarden dollars te besparen en tegelijkertijd de klanttevredenheid te verbeteren. Tegenwoordig worden Six Sigma-projecten niet alleen ingevoerd in productiebedrijven, maar ook in de dienstverlening.

(...)

Bruikbaarheid

Six Sigma wordt gebruikt om de operationele prestaties van een organisatie te verbeteren door haar tekortkomingen te bepalen en onder ogen te zien. Six Sigma-projecten dragen bij aan de realisatie van betere financiële resultaten door de kwaliteit en procesbetrouwbaarheid te verbeteren. Elk Six Sigma-project moet zich richten op financiële verbeteringen en kostenbesparingen. De Six Sigma-filosofie stelt dat het topmanagement geen project mag goedkeuren als het niet minstens $ 175.000 beoogt te besparen.

(...)

Uitvoering

Six Sigma bestaat uit vijf stappen: definieer, meet, analyseer, verbeter en controleer (ook bekend als DMAIC).

1. Definieer: allereerst moet er een selectie plaatsvinden van te verbeteren processen en verbeteringsdoelen worden bepaald.

2. Meet: na de defniëringsfase vindt dataverzameling plaats om de prestatie van het huidige proces te bepalen voor toekomstige vergelijking.

3. Analyseer: dit is de fase waarin de verschillen tussen de huidige en gewenste toestand worden bepaald.

4. Verbeter (improve): vervolgens optimaliseert men het proces op basis van die analyse.

5. Beheer (control): de verbeterde processen moeten worden geëvalueerd, beheerst en geborgd.

(...)

Bron: Het Groot Managementmodellenboek - 70 essentiële modellen: inhoud, toepassing, analyse en referenties, Marcel van Assen, Gerben van den Berg en Paul Pietersma

Oleg Skrynnik schrijft in het handboek DevOps Handboek het volgende over waardestromen:

Waardestroom

Een van de belangrijkste concepten van DevOps, geleend van Lean productie, is de waardestroom (value stream).

(...)

Het is nuttig om het werk van een organisatie te beschouwen als het creëren van waarde als reactie op het verzoek van een consument. De acties die worden uitgevoerd om aan de vraag te voldoen staan opgesteld in een reeks met de naam 'waardestroom'. Doorgaans verwerkt een organisatie een verscheidenheid aan verschillende verzoeken. ... Er zijn dus veel waardestroom in het bedrijf.

Werken aan stroomvisualisatie staat bekend als ´value stream mapping´. Het begint bij de selectie van een product: soms het product met de grootste mogelijkheden voor optimalisatie; soms het product dat de snelste significante verbeteringen belooft, en tegelijkertijd materiaal verstrekt om de methode te bestuderen.

Mapping gebeurt in twee stappen: eerst wordt een as-is ('zoals het is') plaatje gemaakt en vervolgens een to-be ('zoals het moet worden'). De studie van de 'to-be map' is om twee redenen belangrijk.

Ten eerste helpt het om lokale optimalisatie te vermijden ... Ten tweede maakt begrip van de gewenste eindtoestand het mogelijk om een realistisch verbeteringsmechanisme op te zetten, met een zo duidelijk mogelijke richting van verbetering.

In feite is de value stream mapping exercitie eenvoudig: men moet eerst de belangrijkste stappen van de aanvraagverwerking identificeren, het werk documenteren dat bij elk van deze wordt uitgevoerd, en ervolgens deze stappen in de juiste volgorde van creatie voor het resultaat rangschikken.

Een van de moeilijkheden is het buitensporige detailniveau, wanneer de resulterende map niet op één blad past. [De tip is] om het aantal mapblokken te beperken tot vijftien om verder te werken met de map gemakkelijker te maken.

De tweede moeilijkheid is om het eens te worden over wat de precieze stappen zijn, en hoe en door wie ze worden uitgevoerd. In sommige organisatie bestaat er geen algemeen begrip van het proces, wat leidt tot vele uren van geschillen.

Bron: DevOps Handboek, Oleg Skrynnik

In het boek The Toyota Way to Lean Leadership beschrijven Jeffery LIker & Gary L. Convis het nut en de noodzaak van de A3-methode:

A3 Problem Solving Makes the Thinking Proces Visible

(...)

Mr Fumitake Ito became president of NUMMI and was not satisfied with the uptime of the body shop. He also noticed the body-shop engineers spending too much time in the office, which of course meant the problems were not going to get solved. In one meeting, he asked Gary to start a new practice. Whenever equipment was shut down for 30 minutes or more, he wanted a personal report from the engineers, with Gary present. The report should be on one piece of paper, the famous Toyota "A3 report" (after the A3 paper size used in the metric system). Ito did not offer a training course on A3, but rather asked for a 'breakdown report' for each instance and suggested that the Japanese engineers in the body shop would be able to show the American engineers how to prepare it.

The purpose of the report is to produce, in a single page, a 'problem-solving story' that summarizes the problem, its root cause, and the countermeasures taken to solve the problem. ... The single-page report details the problem, the gap between the current and the ideal state, the countermeasures tried, the results, and further actions required. The engineers' job was not only to fix the breakdown but to identify why the breakdown happened and to address the root causes so that the breakdown would not be repeated. The engineers were to present the report personally to Ito and Gary within a week of the breakdown.

By approaching the situation this way, Ito was addressing several needs at once. First, he was addressing the production problems that NUMMI was having in a sustainable way (rather than putting production goals first and just letting the Japanese engineers solve the problems). Second, he was creating a development opportunity for the American engineers to practice their problem-solving skills. By instituting the policy of having the American engineers take the lead and be responsible for the A3 reports, Ito-san was focing them to learn problem solving and learn the value of genchi genbutsu. Third, he was gving Gary an opportunity to be engaged in the problem-solving process and creating an opportunity to coach Gary in his responsibility to develop engineers.

(...)

The goal of filling out the A3 report, of course, is not to fill out the form perfectly, but to serve as an aid to clear thinking and learning in the problem-solving process. ... As every developing leader at Toyota learns, the reports are a powerful technique for developing problem-solving ability. (...) Any individual report was relatively unimportant in the grand scheme of developing leaders. The steady improvement in the reports showed the more important progress in developing the engineers and to see how they thought, how they reasoned, how they were going to prevent problems, and how they were going to sustain that prevention.

Bron: The Toyota Way to Lean Leadership, Jeffery Liker & Gary L. Convis

Rijk Schildmeijer & Paul Suijkerbuijk beschrijven in het boek Six Sigma in de praktijk wat zij verstaan onder een datacollectieplan:

Het datacollectieplan is een plan waarin vastgelegd wordt wat er gemeten gaat worden, hoe er gemeten gaat worden en door wie er gemeten gaat worden. Het format van het datacollectieplan is bruikbaar voor de hele DMAIC-cyclus:

1. Measure: verzamelen van data over de project Y en de (stratificatie)factoren om zo tot de 'Baseline performance' en het entitlement vast te stellen.

2. Analyse: verzamelen van data over de project Y en de potentiële X-en om te komen tot de hoofdoorzaken die Y beïnvloeden.

3. Improve: verzamelen van data over experimenten van procesverbeteringen en pilotprojecten om zo te komen tot de beste oplossing.

4. Control: verzamelen van data na de implementatie van de oplossing, om zo de verbetering te kunnen aantonen.

(...)

In het datacollectieplan zijn er drie onderdelen die samen het 'wat' van het datacollectieplan vormen:

• De operationele definitie
• Type meetresultaat
• Type data

(...)

Bij een verdeling van data in subgroepen is het belangrijk dat de verschillen tussen groepen zo groot mogelijk zijn en verschillen binnen de groepen zo klein mogelijk. De verschillende factoren van de groepen moeten elkaar uitsluiten en samen het geheel vormen.

Stratificatie helpt bij het zoeken naar prestatieverschillen tussen groepen of perioden om te komen tot de best case of het verklaren van een defect.

Bron: Six Sigma in de praktijk, Rijk Schildmeijer & Paul Suijkerbuijk

Business Rule Management (BRM)

Definitie

...

Alias: ...

In toenemende mate is er (vernieuwde) belangstelling voor business rule management (BRM), een activiteit zie zich concentreert op het vastleggen en valideren van business rules. Business rules (“bedrijfsregels” in goed Nederlands) vormen de bedrijfslogica waarmee de business wordt gedreven en uitgevoerd. De aandacht voor BRM wordt vooral ingegeven door de noodzaak om verantwoording af te leggen over de gevoerde bedrijfslogica, o.a. in het kader van compliance aan wet- en regelgeving. Bovendien biedt BRM een mogelijkheid om inrichtingsonafhankelijk over die bedrijfslogica te beschikken; de logica bepaalt namelijk wat kan en mag, los van hoe dat wordt uitgevoerd in de bedrijfsprocessen. Daarmee worden de bedrijfsprocessen makkelijker veranderbaar, wat de business agility aanzienlijk kan bevorderen. Tenslotte ligt het belang van BRM in de mogelijkheid om de regels met geavanceerde technologie uitgevoerd te krijgen, wat het mogelijk maakt om hele processen straigh-through, zonder tussenkomst van mensen uit te voeren. Kortom het belang van BRM ligt hoofdzakelijk in drie mogelijkheden: compliance, agility en straight-through-processing.

Bron: https://www.naf.nl/werkgroepen/afgeronde-werkgroepen/business-rules/

A business rule is a statement that defines or constrains some aspect of the business.

Business rules have a business motivation and an enforcement regime.

The business rules approach enables, (a) a better alignment between information systems and business, and (b) a greater business agility.

Business rule applications externalize business logic and separate it from the underlying computational infrastructure where it can be managed by business.
Business rule development differs from traditional application development in many ways:
(1) it is business requirements-centric,
(2) enterprise-level ownership — and management — of business logic, and
(3) business-led implementation and maintenance of business logic.

(...)

So, what is a business rule? If we break down the term "business rule" we get a rule of the business. Wordnet defines a rule as, among other things, "a principle or condition that customarily governs behavior," or "a prescribed guide for conduct or action." A rule of the business means that this principle or prescription is in the business domain, that is, it is part of the requirements (the problem domain), as opposed to a prescription dictated by a particular technological choice (the solution domain).

Business rule authors have proposed a number of definitions for business rules.

- Tony Morgan defines a business rule informally as "a compact statement about an aspect of the business ... It is a constraint in the sense that a business rule lays down what must or must not be the case" (Morgan 2002, p. 5).

- Ronald Ross defines a business rule as "a directive intended to influence or guide business behavior" (Ross 2003, p. 3).

- Barbara von Halle would like us to think of business rules as "the set of conditions that govern a business event so that it occurs in a way that is acceptable to the business" (von Halle 2001, p. 28). \

- The Object Management Group (OMG) defines a rule as a "proposition that is a claim of obligation or of necessity," and a business rule as a rule that is under business jurisdiction (OMG 2008).

The Business Rules Group, which is an inde-pendent non-commercial peer group of business rule specialists, has produced a number of documents about the business rules approach, and has contributed to OMG's work on business process management and business rules. The Business Rules Group considers business rules from two perspectives, the business perspective, and the information systems perspective, defined as follows:
• From the business perspective: "... a business rule is guidance that there is an obligation concerning conduct, action, practice or procedure within a particular activity or sphere. Two important characteristics of a business rule:
(1) there ought to be an explicit motivation for it, and
(2) it should have an enforcement regime stating what the consequences would be if the rule were broken" (BRG 2008).

• From the information system perspective: "... a business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure, or to control or influence the behavior of the business" (BRG 2008).

Bron: Agile Business Rule Development: Process, Architecture, and JRules Examples - Jérôme Boyer, Hafedh Mili

Kjeld Aij beschrijft in zijn boek Wie vraagt wordt beter! - ware Lean leiders houden hun zorgorganisatie gezond dat werken om meer gaat dan het behalen van resultaten; het gaat ook om continu te leren en verbeteren:

Ontwikkeling als doel

Het is logisch dat het zelflerend vermogen van medewerkers alleen kan groeien in een lerende organisatie. Volgens de Lean-theorie moet je het dagelijks werk daarom zien als middel om te verbeteren, leren en ontwikkelen. Het doel van het dagelijks werk is dus niet uitsluitend het behalen van hoogwaardige resultaten, het is veel breder.

Zelf fungeer je daarbij als een coachende leidinggevende, die in staat is het initiatief tot leren en ontwikkelen bij de medewerker te leggen. Je daagt anderen dus uit en prikkelt hen tot kritische reflectie en nieuwsgierigheid. Of, zoals Galileo Galilei het zo treffend verwoordde: 'You cannot teach a many anything, you can only help to discover it within himself.'

Bron: Wie vraagt wordt beter! - ware Lean leiders houden hun zorgorganisatie gezond, Kjeld Aij

Via Managementboek

Bureau Tromp beschrijft in het artikel Kano model: wat is het en wat kun je er mee? de essentie van het Kano-model van Noriaki Kano:

Kano model: wat is het en wat kun je er mee?

Binnen lean management draait alles om de klant. Het succes van een product of dienst wordt bepaald door wat de klant ervan vindt. Het is daarom erg belangrijk dat je de wensen van de klant scherp in beeld hebt. Dit noemen we de Voice of the Customer. Als je de wensen van de klant eenmaal in beeld hebt, is het zaak erachter te komen welke wensen het verschil maken, en wat er minimaal op orde moet zijn. Je gaat prioriteit aanbrengen in de klantwensen. Dit doe je met behulp van het Kano model.
3 factoren

Het Kanomodel werd in de jaren ’80 ontwikkeld door Noriako Kano. Het model helpt je verwachtingen, prioriteiten en expliciete behoeften van klanten in kaart te brengen. Het model zet 2 indicatoren naast elkaar af. Het kijkt naar in welke mate een bepaalde klantbehoefte is ingevuld, en welke mate van tevredenheid dit met zich mee brengt voor de klant. Bij het in kaart brengen van behoeftes kun je vervolgens onderscheid maken tussen 3 verschillende factoren. Dit zijn basisfactoren, prestatiefactoren en wow-factoren.

(1) Basisfactoren

Factoren die minimaal aanwezig moeten zijn (basic needs). Als deze factoren niet aanwezig zijn, is de klant per definitie ontevreden. Neem bijvoorbeeld een hotelkamer. Daar moet altijd een bed in staan. Als dit niet het geval is, zal het ervoor zorgen dat de klant niet tevreden is. Het is andersom niet per se het geval dat hoe meer bedden er zijn, hoe tevredener de klant is.

(2) Prestatiefactoren

Voor prestatiefactoren (performers) geldt dat hoe meer ze aanwezig zijn, hoe tevredener de klant is. Andersom kan een klant ook minder tevreden worden als deze factoren in mindere mate aanwezig zijn. Als je de hotelkamer neemt, kan de grootte van de kamer een prestatiefactor zijn. Een kleine kamer zorgt ervoor dat de klant minder tevreden is, maar de tevredenheid neemt toe naarmate de kamer groter is.

(3) Wow-factoren

Wow-factoren (delighters) zijn dingen die een klant niet mist als ze niet aanwezig, maar die de tevredenheid enorm positief beïnvloeden als ze er wel zijn. Dit zijn dingen waarvan de klant blij verrast is, hij had ze niet verwacht. Hij is dus ook niet ontevreden als ze er niet zijn. In een hotelkamer is dit bijvoorbeeld een schaal met vers fruit die elke dag aangevuld wordt, of een mooi boeket bloemen.

(...)

Als organisatie moet je ervoor zorgen dat de basisfactoren altijd op orde zijn, je werkt aan je prestatiefactoren en af en toe een wow-factor verzorgt. Klanten zijn dan in de basis tevreden, ervaren door goede prestatiefactoren een hoog servicelevel en worden zo af en toe echt verrast.

Bron: Kano model: wat is het en wat kun je er mee?