Bert Teeuwen beschrijft in Dagstarts en Hoshin Kanri - Continu Leren en Verbeteren in de juiste richting met Dagstarts en Hoshin Kanri hoe je binnen een organisatie met Hoshin Kanri alle neuzen dezelfde kant op krijgt:

In de doelenmatrix staan de verbeterdoelen, gelinkt aan de succesfactoren van de verschillende belanghebbenden. In de X-matrix zijn die gekoppeld aan de benodigde inspanningen. De A3-rapporten bevatten de gedetailleerde projectbeschrijvingen. De doelstelling van een project komt rechtstreeks uit de X-matrix. Het is de mix van de 'benodigde verbetering' en de 'baten' die met kruisjes aan het project gelinkt zijn. De voortdurende bijgewerkte A3-rapporten dienen als verslagvan de voortgang van de projecten.

Cascaderen met X-matrices

Doelen van afdelingen en die van de organisatie als totaal moeten met elkaar samenhangen. Hoe mooi zou het zijn als de doelen op alle niveaus met elkaar een oorzaak-gevolg-relatie hebben. Nog mooier is het als ook de geplande verbeter-inspanningen een plaats hebben in dat oorzaak-gevolg-plaatje. Een cascade van doelen en inspanningen, waarbij elk project niet alleen is terug te herleiden wat die moet gaan opbrengen. Maar ook aan welke afdelingsdoelstelling het een bijdrage zal leveren, en hoe dat ervoor zorgt dat het halen van de organisatie-doelstellingen een stapje dichterbij komt. En, als klap op de vuurpijl, dat het aantoonbaar een zetje in de juiste richting is, namelijk die van de strategische meerjarendoelen.

De Hoshin Kanri-methodiek met doelenmatrices, X-matrices en A3-rapporten werkt als volgt:

(1) Bepaal aan de hand van een strategische visie of een paar strategische doelen de doelenmatrix voor de hele organisatie. Laat daarin de stem van de klanten doorklinken. Bespreek deze met de managers van de afdelingen of waardestromen.

(2) De managers van de afdelingen of waardestromen maken met hun team van leidinggevenden een doelenmatrix voor hun niveau.

(3) Beoordeel met de strategische X-matrix of deze afdelingensdoelenmatrices een sluitend geheel vormen met elkaar en met de bovenliggende doelenmatrix. Pas aan waar dat nodig is.

(4) Bepaal op afdelingsniveau of op waardestroom-niveau welke obstakels en verliezen aangepakt moeten orden (de benodigde verbeteringen) om de doelen te gaan halen. Zet die in de X-matrix, en vul die verder in.

(5) Bepaal aan welk project welke benodigde verbetering gaat realiseren. Beoordeel hoeveel tijd en geld al die projecten gaan kosten. Ga, als blijkt dat het allemaal te veel is, weer onderhandelen. En pas de doelenmatrices aan op het resultaat van dat gesprek.

(6) Werk, als er consensus over de doelenmatrices en de X-matrices is, de gekozen projecten verder uit in A3-rapporten.

(7) Ontwerp de dag- en weekstarts op de diverse niveaus, zodat die met elkaar een cascade van informatie vormen om het verbeteren in de organisatie te volgen en te sturen. De directie volgt en bestuurt het strategische proces in zijn eigen strategische weekstart.

(...)

Het Catchball-proces

Hoshin Kanri is co-creatie. Iemand zei eens: "Hoshin Kanri helpt ons om de neuzen dezelfde richting op te krijgen, dat we allemaal hetzelfde lied zingen." De methodiek om in co-creatie de strategie te maken heet Catchball. Dat woord is in het Hoshin Kanri-proces de metafoor voor het horizontaal en verticaal naar elkaar overgooien van de bal - de deelresultaten -, die vangen, bestuderen en verder uitwerken en verbeteren. Die deelresultaten zijn dan het visiedocument, de doelenmatrices en de X-matrices. Het vangende team reageert op wat ze krijgt. niet met de rode pen, maar in gesprekken tussen werpers en vangers. Daarbij gebruik makend van de kennis en ervaring die ze hebben van de Stem van de Klant en de Stem van het Proces.

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

In de whitepaper Van applicatiecomplexiteit naar een businessgerichte architectuur geeft Atos Consulting haar visie op applicatieportfoliorationalisatie.

Voor veel bedrijven is de informatievoorziening een 'stroperige spaghetti' als gevolg van een (te) complex applicatielandschap. Deze applicatielandschapcomplexiteit heeft nadelige gevolgen voor de business: inconsistente gegevens, ondermaatse ondersteuning van bedrijfsprocessen (incl. slechte managementinformatie), langzame ontwikkeling van nieuwe producten, trage aanpassing aan wijzigende wet- en regelgeving en/of oplopende beheer- en onderhoudskosten.

Volgens Atos geeft "Driekwart van IT-managers ... aan grote problemen te ervaren met onderhoud, ontwikkeling en uitfaseren van applicaties als gevolg van complexiteit. Waarbij ontwikkeling en integratie van nieuwe systemen teveel tijd en geld kost, applicatie-onderhoud te duur is en uitfaseren van verouderde applicaties moeilijk is."

Atos stelt dat voor het oplossen van IT-complexiteit de business hard nodig is en bepleit een aanpak in zeven stappen:

1. Bepaal de uitgangspunten voor de ideale applicatieportfolio: identificeer de juiste business drivers (bijv. gemeenschappelijk klantbeeld, ketenintegratie, risicobeheersing, enz.); een adequaat inzicht in de business-strategie is nodig om vervolgens de criteria op te stellen waaraan de applicatieportfolio moet voldoen.

2. Breng kwaliteit en knelpunten van het bestaande applicatielandschap in kaart: inzicht in het bestaande situatie is nodig voor het opstellen van een migratiestrategie. Relevante aspecten hierbij zijn: bedrijfsarchitectuur, informatie- en applicatiearchitectuur, architectuur van de IT-infrastructuur en de governance (besturing van de informatievoorziening) en alignment (afstemming van de informatievoorziening op de business strategie).

3. Stel een bestemmingsplan op, eventueel met meerdere scenario’s: op basis van een beeld van de toekomstige situatie weet je waar je naar toe wilt gaan, beschreven in een doelarchitectuur (bedrijfsprocessen, producten en/of diensten, informatie, applicaties en infrastructuur) die fungeert als bestemmingsplan. Een architectuur in de vorm van een bestemmingsplan geeft principes, keuzes en richtlijnen, duidelijk genoeg om richting aan te geven, maar laat daarbinnen ruimte voor invulling.

4. Maak de businesscase voor de rationalisatie van de applicatieportfolio: de businesscase geeft inzicht in wat de rationalisatie gaat opleveren en voor wie, vanuit een bedrijfsbreed perspectief.

5. Kies een scenario en stel een roadmap op: onderlinge vergelijking van de scenario's en afstemming met de bedrijfsstrategie leidt tot de keuze van één oplossingsrichting welke vervolgens wordt uitgewerkt. Bij de uitwerking hoort ook het opstellen van een roadmap voor de implementatie van de rationalisatie.

6. Herontwerp de IT-governance om rationalisatie blijvend te kunnen besturen: de complexiteit van het applicatielandschap is een afgeleide van de complexiteit van de productportfolio (stimuleren van hergebruik ter bestrijding van het 'wij-zij-uniek-syndroom', het reduceren van applicaties door een overzicht te creëren in hoeverre het applicatielandschap bijdraagt aan de ondersteuning van de business processen). Applicatiecomplexiteit kan dan ook alleen door de business en IT samen worden opgelost.

7. Voer de rationalisatie uit en monitor de realisatie van besparingen: het rekenmodel dat bij de businesscase is gebruikt kan met de nodige voorzorg ook worden toegepast om te blijven monitoren of tijdens het implementatietraject de investeringen en de baten aan de beoogde doelen blijven voldoen.

Bij het opstellen van het bestemmingsplan (zie 3) kan rationalisatie worden bereikt door een mix van de onderstaande negen maatregelen:

1. Harmonisatie: uitfaseren van een applicatie ten faveure van een meer geschikte andere in geval van functionele redundantie (meerdere applicaties bieden dezelfde of vergelijkbare functionaliteit).

2. Consolidatie: gelijktrekken van verschillende technische uitvoeringen van dezelfde applicatie.

3. Standaardisatie: vervanging van maatwerksoftware door standaard 'pakket' software. Maatwerk kan nog ingezet worden voor het realiseren van concurrentievoordeel en het realiseren van noodzakelijke functionaliteit waarvoor geen pakketten beschikbaar zijn.

4. Nieuwe functionaliteit: toevoegen van nieuwe functionaliteit om 'zwakke plekken' in het applicatielandschap aan te pakken.

5. Uitfasering: uitfaseren van systemen die overbodig zijn of een lage toegevoegde waarde hebben.

6. Reduceren platformen: reductie van variëteit aan technische platformen (hardware systemen, operating systemen, databases, ontwikkelingsomgevingen).

7. Integratie: integreren van applicaties door modulaire opbouw, ontsluiting via webservices en het optimaliseren van koppelingen.

8. Herontwerp: herinrichten en/of optimaliseren van bedrijfsprocessen met IT.

9. Optimaliseren onderhoud, beheer en exploitatie: met een gerationaliseerd systeemlandschap kan het beheer vaak eenvoudiger gecentraliseerd worden, tegen lagere kosten en met een hogere kwaliteit van dienstverlening.

Zie ook: Applicatierationalisatie volgens Dave van Herpen en Applicatieportfoliomanagement volgens Arjan Juurlink

Bron: whitepaper Applicatie Portfolio Rationalisatie: 'Van applicatiecomplexiteit naar een businessgerichte architectuur' Jeroen van Dullemen, Rick Teunissen en Peter-Jan van de Venn (Atos Consulting), juni 2006