laatste nieuwsGeplaatst door Mary Beijleveld zo, september 05, 2010 23:24:11Leiderschap = management / management = leiderschap
Dit is de 8e en laatste blog over de 7 misverstanden die leven bij managers. In de vorige 7 blogs (blog nr. 0 meegerekend) heb ik al meerdere praktische tips gegeven. In ieder geval zouden de managers die ik op het oog heb, tenminste het volgende moeten overwegen:
- dat handboeken (alleen) er niet voor zorgen dat het in een bedrijf goed geregeld is, maar dat het een hooguit een instrumentele stap is die onderdeel is van het goed geregeld zijn;
- dat kwaliteit een continue zorg en streven moet zijn en niet een kwestie is van een certificering
- dat de hoge output van een systeem niet hetzelfde is als kwaliteit en dat kwaliteit tijd nodig heeft
- dat gecompliceerde dingen gemakkelijker zijn op te knippen in kleinere deelproblemen en complexe problemen alleen in samenhang kunnen worden opgelost; dat daarom pendelen tussen abstractieniveaus handig is om de ‘variabelen’ en de relatie daartussen te ontdekken. Dat de lieden die op alles hetzelfde truukje van complexiteitsreductie toepassen onderdeel zijn van een zelfreflecterend systeem (onderdeel van het probleem) en grote kans lopen op navelstaren en spijkerzoeken.
- dat het scoreboard (de kengetallen) niet hetzelfde als de wedstrijd is en de cijfers een reductionistisch kijk op de werkelijkheid geeft
- dat je eerst moet weten voordat je gaat meten i.p.v. uit te gaan van het adagium meten = weten
Als laatste dus de misvatting waaraan hele kuddes managers leiden namelijk dat leiderschap en management hetzelfde is. Vooral de types die nogal van zichzelf vervuld zijn en behoorlijk last hebben van oogkleppen, zijn daar stellig van overtuigd.
Jim Collins een auteur en wetenschappelijk onderzoeker heeft eens opgetekend wat voor niveaus er in leiderschap zijn: Op de ladder van leiderschap staat voor hem:
Op niveau 1 (laagste) een veelbelovend individu: iemand die talent, kennis, vaardigheden een goede werkhouding heeft en productief is. Gewoon prima mensen waar je iets aan over kan laten.
Op niveau 2 komt het goed presterend teamlid; iemand die met zijn/haar individuele capaciteiten bijdraagt aan het realiseren van teamdoelen en effectief samenwerkt met andere groepsleden zoals je dat o.a. ziet in goeddraaiende teams, of in bepaalde productieomgevingen. Ik kan mij vele collega’s voor de geest halen die aan deze kwalificatie voldoen en waar het fijn werken mee was.
Op niveau 3 zit de competente manager, iemand die het vak verstaat mensen en resources te organiseren en op een effectieve en efficiënte manier van tevoren vastgestelde doelen te bereiken, zoal een scrum productowner, een echt goede projectmanager en een inspirerende afdelingsmanager. Ik heb het geluk gehad dat ik aantal mensen van dit niveau in mijn werkzame leven tot nu toe heb mogen ontmoeten.
Op niveau 4 staat de effectieve leider. Deze persoon weet het streven naar een duidelijke visie en een sterk commitment op te roepen en tot kan hoge prestaties stimuleren. Deze mensen zijn al veel zeldzamer. Daarvan heb ik er maar een viertal persoonlijk mogen meemaken.
Op niveau 5 (hoogste) staat, het woord cijfer zegt het al: de niveau 5 leidinggevende. Iemand die bouwt aan langdurig succes van een stroming, bedrijf, maatschappelijk belang en als persoon een tegenstrijdige mix van persoonlijke bescheidenheid en professionele wil bezit.
De mensen die van zulk een statuur zijn ken ik eigenlijk alleen als mijn idolen en heb ik zelf nog nooit mogen ontmoeten. Een voorbeeld voor mij is bv. Mahatma Gandhi. Wel heb ik mensen ontmoet waarvan ik denk dat deze een niveau 5 zouden kunnen bereiken, ooit. Door vol te houden, moed te tonen, voor zichzelf te blijven denken, feedback op hun functioneren te blijven vragen en te onderzoeken, hoop te houden en gedisciplineerd te blijven werken aan datgene waarin zij geloven.
Verschil tussen leiders en managers
In de bovenstaande opsomming staan weer een aantal aanknopingspunten, waarvan deze meer met de persoonlijkheid te maken hebben. Dat wil zeggen de persoonlijke eigenschappen gepaard aan de werksituatie.
In het boek van Stephen Covey “de 7 eigenschappen van effectief leiderschap” gaat het ook om leiderschap. Maar dan om leiderschap in elke situatie: als volwassene, ouder of kind, als collega en leidinggevende en als gemeenschapslid.
Ik kan er niet helemaal over uitweiden, anders wordt deze blog wel erg lang, maar de 7 eigenschappen die je zou moeten bezitten zijn: wees proactief, begin met het eind in zicht, belangrijke dingen eerst, denk in termen van win/win, probeer eerst te begrijpen… en dan begrepen te worden, werk synergetisch en tenslotte hou de zaag scherp. Hier staan de eigenschappen als ‘werkwoorden’ omschreven. En dat moet ook want het is best lastig om dit te realiseren. Niet onmogelijk maar het is wel hard werken.
Nogmaals, ik denk dat er dus een groot verschil is tussen leiders en managers. In mijn mening doen leiders de goede dingen. Zoals samen met anderen de richting van de organisatie bepalen, boven zichzelf uitstijgen, mensen respecteren ook al hebben die een mening die even niet in het straatje te pas komt en die liefdevol of in ieder geval geweldloos kunnen communiceren.
Leiders vragen of de visie en missie aantrekkelijk is en zodanig parallel ligt aan de normen en waarden van de persoon dat ie daar in mee kan gaan of vraagt om kritiek.
Leiders aanvaarden onzekerheid en gaan de uitdaging aan en spelen gaandeweg op de ontwikkelingen in.
Leiders weten de vaklui aan zich te binden door hen vertrouwen te geven en krijgen vertrouwen terug, hebben echt interesse in wat mensen beweegt, en onderhouden contacten niet om reden van macht.
Leiders staan voor alle belanghebbenden (stakeholders) en gaan voor waardevermeerdering, kenniscreatie en effectiviteit. Leiders zijn een voorbeeld.
Managers doen vooral de dingen goed. Managers kunnen prima structuren maar zijn vaak risicomijdend, willen voorspeld krijgen hoe de risico’s onder controle te houden zijn en maken uitgebreide en gedetailleerde stappenplannen. Zelfs de competente managers.
In de ogen van managers staan de belangen van de aandeelhouders (shareholders) vaak voorop. Niet vreemd hoor als managers onderling hun succes afmeten aan de hoogte van hun salaris, de grootte van de leaseauto waarin ze rijden, het aantal xxx omzet vertegenwoordigende klanten in de portefeuille etc.
Managers hebben angst om vertrouwen te hebben in de mensen waar ze eigenlijk de zorg voor hebben gekregen hetgeen er bij hen tot bijna irrationele gedachten leidt, welke voortkomen uit het idee van een gebrek aan controle.
Managers doen vooraf bedachte en uit vliegtuigliteratuur gehaalde interventies om beoogde veranderingen door te voeren.
Manager stellen in contracten vooraf vast wat de leveringen door het personeel moeten zijn. Dit kan overigens sterk afhankelijk zijn de cultuur van een organisatie.
Managers gaan voor kostenvermindering en personeelsreductie.
Moet ik me daar iets van aantrekken?
Uiteraard heb ik 8 sterk opiniërende stukjes geschreven en de uitersten benadrukt. Ik hoop oprecht dat ik niet hele volkstammen met goedbedoelende managers heb geschoffeerd. Of, eigenlijk, toch wel. Want ik mag er toch wel van uitgaan dat juist die goedbedoelende manager begrijpt wat ik wil overbrengen en deze ernaar streeft zijn/ haar huidige niveau te ontstijgen? Als ik weer zo’n manager in mijn werksituatie mag treffen dan kan hij of zij op mijn bijdrage daaraan vertrouwen. Nieuwsgierig, onbevangen, eigenwijs en soms een beetje brutaal…!
Tenslotte.
Het is de lezer waarschijnlijk al opgevallen dat ik in deze blog nu eens niet naar Scrum, Lean of Agile verwijs om mijn punt te verduidelijken. Dat komt omdat ik vind dat technologie, architectuur, methodes, procedures, machines en regels niet een doel op zich zijn. Managers vergissen zich er wel eens in door van deze hulpmiddelen een doel te maken; Leiders brengen deze zaken altijd terug tot handige hulpmiddelen om een gedeeld -, of beter nog, een gezamenlijk doel en beeld te krijgen.
laatste nieuwsGeplaatst door Mary Beijleveld zo, augustus 29, 2010 19:54:57Meten = weten
Dit is alweer nummer 6 van de 7 misverstanden die leven bij managers en dit misverstand leeft erg sterk bij veel managers. Dat is niet verwonderlijk. Managers worden immers getraind in het gebruik van meetresultaten om daar conclusies uit te trekken en voelen zich sterk afhankelijk van de cijfers om de juiste conclusies te trekken en correcte beslissingen te nemen. Afgaan op intuïtie, buikgevoel of de tijd nemen om eens ergens langer over na te denken wordt al gauw als een zwakheid ervaren en zeggen dat je het niet weet, is al helemaal uit den boze. Snelle beslissingen op grond van de cijfers, dat is pas goed management!
Onderling stellen managers vragen zoals: ‘hoe vaak doet zich iets voor?’, ‘wat is de KSF, kun je met cijfers komen?’ Vooral als een andere manager iets van ze wil waar ze geen zin voor hebben of tijd in willen steken. Ook vragen zoals met ‘hoeveel is het budget overschreden’ en ‘hoeveel uitloop van het project heb je’ stellen ze elkaar, doch deze vragen zijn meer van het kaliber ‘competitie / aan elkaars stoelpoten zagen’ . Managers vragen aan de medewerkers: “halen we onze KPI” en aan zichzelf stellen ze geregeld de vraag ‘haal ik mijn bonus dit jaar?’ Dus geven cijfers uitkomst; althans, zo zijn ze opgevoed en zij denken dienovereenkomstig.
Deze, ik noem het maar, meetkramp van managers ontwikkelt parallel daaraan bij iedereen – van manager tot medewerker- een spasme om alleen te leveren wat er gemeten wordt.
De cijfers worden zo belangrijk dat iedereen aan de gestelde verwachtingen probeert of gaat voldoen. Het wordt als het ware een selffulfilling prophecy omdat de invloed van het meten zelf, een grote invloed op de uitkomst heeft. Hiermee wordt tevens algehele frustratie of voorgewende onwetendheid (in extremo: fraude) gestimuleerd en worden bovendien onnodige meetkosten gemaakt.
Alsof niets anders belangrijker is. Bijvoorbeeld het onderlinge verband tussen de gebeurtenissen die gemeten worden. De verandering in de omgeving waarbinnen de gebeurtenissen plaatsvinden en gemeten worden.
Teruglopende omzet
Laat ik eens een voorbeeld geven over meetgegevens en het gebruik ervan:
Een bedrijf heeft een probleem. De omzet is teruggelopen met 15%, de winst voor belasting is gedaald naar 98% in verhouding tot het vorige kwartaal, terwijl tegelijkertijd de afdeling marketing (M) in staat is geweest wel 30 nieuwe klanten aan het bestand toe te voegen.
Hé das gek! Het ligt vast aan Verkoop (V), immers de omzet is gedaald. Het kan niet aan Productie (P) liggen want dan zou de winst veel verder gedaald zijn. V: Nee! Het ligt wel aan productie want die leveren te laat. (M) O, ja? Hoe weet je dat? Nou, wij doen het in ieder geval goed! V: Nee, dat hebben we niet gemeten maar we horen het steeds vaker van de klanten. P: Marketing belooft veel te veel maatwerk en spreekt afwijkende levervoorwaarden af, dat geeft veel omsteltijd of vertragingen of lijdt tot kwaliteitsverlies. (M) Ja, wacht ff, wij proberen nieuwe klanten binnen te halen! Dan moet je eens wat geven en nemen. Kun je dat aantonen? P: Dat meten we niet, maar het zorgt bij ons dus echt voor vertragingen.
Ziet u wat er hier gebeurd? Sommige beslissingen (meer klanten met afwijkende specs.) versterken een lagere kwaliteit, waardoor de klanten niet meer tevreden zijn, waardoor ze niet meer bestellen, waardoor de omzet omlaag gaat, waardoor er weer extra inspanningen worden gedaan om meer klanten aan te trekken enz. Ook is het effect van een beslissing niet meteen meetbaar omdat er een tijdje overheen gaat voordat zich dat manifesteert. De cijfers komen altijd achteraf (hier per kwartaal) dus heb je op die uitkomsten geen invloed meer, hooguit heb je invloed op wat er nog komen gaat.
En hoewel er aan de wijze van met elkaar omgang nog wel e.e.a. verbeterd kan worden, praten deze managers gelukkig nog met elkaar. Waarschijnlijk heeft de echte leider ervoor gezorgd dat deze managers de koppen bij elkaar staken. Voor iedere keer dat managers alleen nog met elkaar in competitie zijn en elkaar beschuldigen van het gebrek aan commercieel leiderschap of gochme wil ik nog geen halve euro neertellen. Ik zou er straatarm van worden.
De tevreden burger
Nog een verhaaltje: De ‘tevreden burger’ is voor een willekeurige gemeente het meetgegeven. Onderling worden de gemeenten hierop in een zogenaamde ‘benchmark’ vergeleken en elke zichzelf respecterende gemeente wil dus een goed ‘rapportcijfer’
Tevredenheid bestaat echter uit een aantal dimensies o.a. veiligheid, bereikbaarheid van de woning met OV of parkeerplaats voor de deur, scholen nabij, geen overlast etc. Veiligheid op haar beurt heeft ook aantal dimensies.
Ah, denkt men: We hebben toch telling van aangiften en melding van incidenten?
Daar zijn we er niet mee! Situaties zoals: branden de lantaarns ’s avonds, is er herrie van spelende schoolkinderen, scooteren de tieners door de buurt, zijn er intimiderende hangouderen met van die nieuwerwetse looptoestellen vlak voor de deur van de supermarkt, fluitende glazenwassers, drugsoverlast, overlast van beschonken bezoekers van het café op de hoek etc.
De cijfers over de criminaliteit zeggen dan bijzonder weinig.
Ook heeft invloed op de tevredenheid wat de gemeente presteert op alle genoemde gebieden, hoe zij is omgegaan met verbeterpunten aangedragen door de eigen ambtenaren en de burgers, of er nazorg is geweest na een (opgelost) probleem.
Opstapelen van meetgegevens zegt in feite niets en meten doe je altijd achteraf. De balanced scorecard zegt geen ruk (meer) Ik zie dat in de praktijk naar mijn smaak te vaak gebeuren. Excessen daarvan zijn dat het versiebeheer belangrijker lijkt dan de oplevering. Nieuwe klanten zijn belangrijker dan klantretentie. De hoogte van de KLOC is belangrijker dan de waardetoevoeging voor de business. Een nieuw meetstelsel maakt dat Schiphol minder overlast bezorgd en Shell heeft elke twee jaar een ander balans waarderingsysteem. Het risico dat de methodiek waarop iets bereikt wordt belangrijker is dan het resultaat – de tevreden burger of tevreden klant - is meer dan levensgroot aanwezig.
Excuus
Bovendien worden de dashboards en scoreborden als excuus gebruikt om in ‘ de controlekamer’ of in ‘de ivoren toren’ te verblijven. En elkaar als managers vooral lekker bezig te houden met discussies over niet zo veel zeggende informatie en maar roepen ‘ druk, druk, druk!’. Als managers beweren dat ze deze houding hebben om hun medewerkers zo groot mogelijke vrijheid te geven, hoef je ze niet geloven. Ik beweer zelfs dat dit getuigt van een vrijblijvendheid en desinteresse dat zijn weerga niet kent.
Wat dan wel?
Eerst moet je het doel van de meting helder hebben dan moet je definiëren wat je wilt weten en waar dat uit bestaat. Dan pas kun je meten. Bovendien moeten de mensen die het resultaat tot stand moeten brengen enige invloed op de meetgegevens kunnen hebben. Ik wil maar zeggen: om te meten moet je eerst weten. Dus: weten = meten
Scrum, Agile en Lean
Bij scrum gebruiken we relatieve meetgegevens zoals het aantal storypoints in een sprint. Daar ben je als team voor verantwoordelijk, nadat je met zijn allen hebt ingestemd met het aantal. Na een tijdje, als je weet hoeveel storypoints een team in een sprint realiseert, kun je er de gemiddelde snelheid van opleveren mee berekenen. Dat vraagt naast weten wat en hoe o.a. samenwerking, overleg, aandacht en analyse en ook meten.
In Agile staat de klant centraal en het leveren van waardevolle (soft)waren. Dat is de maat die gehanteerd wordt.
In Lean zijn er een 5 tal normen om te meten of we nog goed bezig zijn: Zet de klant centraal, identificeer de waardestroom, reduceer verspillingen en creëer een constante flow, maak je klant de dirigent of de regisseur en streef naar perfectie.
Leiderschap
Ik ken ook een verhaal over een directeur van een zeer goedlopend bedrijf met vele filialen die slechts de voortgang van het bedrijf en de tevredenheid van zijn medewerkers mat door te kijken hoeveel bier en wijn op een vrijdagmiddag in de ijskast lag voor de vrijdagmiddag bijeenkomst in één van de filialen. Dat was voor hem in de ruim 20 jaar dat hij de leider was, de maat of het goed ging met het bedrijf.
Uit het langjarige onderzoek voor het boek Good to Great constateerde Jim Collins dat de grootse (niet grootste) bedrijven slechts 1 standaardrekeneenheid hadden welke precies vertegenwoordigde waar het bedrijf het beste in was: winst per medewerker, winst per klant of winst per merk. Maar ja, deze bedrijven kenden dan ook uitzonderlijk goed leiderschap. En deze bedrijven wisten éérst wat die ene rekeneenheid was voordat er gemeten werd.
Leiders hebben gezond vertrouwen in de mensen die het resultaat tot stand brengen. De meetlat is het resultaat of dat nou werkende software is, een mooi product, een excellente dienst of een waardetoevoegende service.
Ik wil tenslotte eindigen met een limerick die ik in december 2006 als een seizoensgrap (maar niet heus) schreef welke goed weergeeft hoe ik tegen normen zoals KSFén en KPI's aankijk:
"normen
Hoeveel water bij de wijn te lengen
ik persoonlijk vind het krengen
KPI en KSF
Heb je nog het lef
om er iets tegenin te brengen?,
laatste nieuwsGeplaatst door Mary Beijleveld di, augustus 24, 2010 22:06:39Het dashboard = de wedstrijd
In deze blog behandelen we het 5e misverstand dat leeft bij vele managers. Dat je aan de dashboards kan zien hoe het bedrijf ervoor staat, of de operatie soepel en adequaat verloopt en wat er werkelijk gebeurt in de organisatie. Waar het hier dus om gaat is dat veel managers naar scoreborden kijken en denken dat ze daaraan de ‘ stand van zaken tijdens de wedstrijd’ kunnen herkennen.
Deze blog heeft erg veel relatie met de volgende: meten = weten. Want het dashboard geeft de uitslag van de gedane meting. Wat daarbij in ieder geval vergeten wordt is dat de meters altijd op de werkelijkheid achterlopen. Scoreborden, kengetallen en spreadsheets geven bovendien een reductionistische kijk op de werkelijkheid. Geaggregeerde cijfers zijn bijna altijd waar, zo werkt nu eenmaal met geaggregeerde cijfers, en lopen tegelijkertijd ver achter. Je kunt er eigenlijk weinig mee. Tegen de tijd dat het dashboard aangeeft dat er een boom op de weg ligt, is de auto er al op gecrasht. Op wat betreft de metingen en wat je daardoor echt weet, ga ik graag de volgende keer uitgebreider in.
In tegenstelling tot de manager houdt een leider de wedstrijd zelf in de gaten. Er zijn slimme lieden geweest die daar voor managers een equivalent op hebben verzonnen: ‘ managing by wandering around’ . Je kunt dit min of meer vergelijken met een voorbeeld uit de sport. Een voetbalcoach staat aan de rand van het veld, leeft mee, geeft zo nodig aanwijzingen en moedigt het team aan. Toch gaat mij dat niet ver genoeg. Immers, je staat hier als manager aan de zijlijn.
Misschien kent u het verhaal van de fabrieksmedewerker die o.a. als taak had om een viertal schroeven te plaatsen en aan te draaien. Daar ging iets mee mis. Een van de schroeven paste niet goed en rolde bijgevolg op de vloer. Omdat in deze fabriek continue kwaliteitsverbetering hoog in het vaandel stond, drukte de fabrieksmedewerker op een rode knop en een sirene ging af. Direct daarop kwam diens manager aangesneld, maakte een diepe buiging naar de medewerker en een excuus aan de medewerker en reikte snel een nieuwe schroef aan. Daarop kon de medewerker voort met zijn werk en ging de manager op zoek naar de weggerolde schroef. De weggerolde schroef werd onderwerp van een scrutineus onderzoek.
Dit voorbeeld toont aan dat de manager hier een faciliterende rol heeft en zeer sterk betrokken is bij de wedstrijd. Meer nog, deze manager doet aan de wedstrijd mee.
Ook de genoemde voetbalcoach heeft zich er persoonlijk van vergewist van wat er op de trainingen is geoefend, heeft ervoor gezorgd dat er goed oefenmateriaal is, heeft de oefencondities gecheckt en de verbeteringen die zijn bereikt. Belangrijker is nog dat de voetbaltrainer feedback van zijn mensen heeft gekregen. Daar sta je dus midden tussen de mensen. Dat begint al flink op leiderschap te lijken.
Alleen van de wedstrijd zelf leert de manager en… niet in de minste plaats de werker, het meest. Samen kun je de situatie het best analyseren. Op de werkvloer (Gemba in LEAN) kun je het best beoordelen hoe hoog de kwaliteit van het productieproces en het product is (Gembutsu in LEAN). En daar gebruik je uiteraard feiten en data voor (Genjitsu in LEAN)
Het is bijzonder krachtig en getuigt van mensgerichtheid om ervoor te zorgen dat de mensen zich gewaardeerd voelen door naar ze te luisteren, de tijd voor ze te nemen en tijd te geven. Samen kun je, met elk je eigen blik op de werkelijkheid, oorzaak en gevolg onderscheiden, de daadwerkelijke problemen analyseren en oplossingen (op de langere termijn) genereren.
In Agile spreekt de kernwaarde “Individuen & interactie gaan vóór processen & hulpmiddelen” voor zich. 2 van de twaalf principes: “ Focus projecten rondom gemotiveerde mensen. Faciliteer en steun hen en vertrouw op erop dat zij het voor elkaar krijgen” + “De meest efficiënte en effectieve methode om informatie te delen binnen een ontwikkelteam is in een persoonlijk gesprek” geven ook al aan dat de wedstrijd het belangrijkst gevonden wordt en dat dit de plek is waar het gebeurd.
Een burndownchart (in scrum) bijvoorbeeld geeft slechts de relatieve ‘snelheid’ van het meest belangrijke wat wordt opgeleverd in een multidisciplinair ontwikkelteam: de oplevering van werkende, waardevolle software voor de klant. Enorm belangrijk want dat is het resultaat. Niet de duizenden lijntjes code die geproduceerd worden en die worden uitgedrukt in KLOC op het scorebord. In een van mijn vorige blogs noem ik dat, heel ondeugend, kilo load of crap ipv. kilo lines of code. Het samenwerken & kennisdeling, de kwaliteit van de code, de informatie-uitwisseling bij de standup-, retrospectie-, en planningsessies is waar het om draait = de wedstrijd. En de manager hoort hier voeling mee te houden en aandacht aan te besteden.
Ik kom er in de volgende blog nog op terug: Het dashboard geeft de cijfers in het verleden aan; niet wat er nu gebeurd. Bovendien ondersteunen de dashboards de, vooral bij manager aanwezige, neiging tot reductionisme en het nemen van snelle – minder adequate- beslissingen om daadkrachtig over te komen. Ik zal hier nog over verhalen.
De balanced scorecard wordt vaak maar 1 x per jaar opgesteld en bevat zulke ‘ hoog over’ indicaties dat dit bijzonder weinig zegt. En de dasboards worden ook als excuus gebruikt. Waarvoor?? Dat vertel ik in de volgende blog………..
laatste nieuwsGeplaatst door Mary Beijleveld ma, augustus 16, 2010 16:08:25Gecompliceerd = complexiteit
Dit is alweer misverstand nummer 4 dat ik hier bespreek. Misschien wel de lastigste om uit te leggen. In sommige (online) woordenboeken worden gecompliceerd en complex namelijk als synoniem gebruikt. Ik vind dat er een wezenlijk verschil is tussen gecompliceerdheid en complexiteit. (en met mij een aantal gerenommeerde anderen trouwens ook, maar dat terzijde)
Ik zal beide begrippen proberen te verhelderen aan de hand van voorbeelden.
Gecompliceerd
Als een probleem of situatie gecompliceerd is dan is het lastig te begrijpen. Dat heeft twee kanten. Meestal is het probleem niet triviaal en wordt gepercipieerd als ‘groot’. Dat zegt iets over het probleem zelve.
De manager die een gecompliceerd probleem moet snappen en oplossen heeft kennis nodig (en ook wel wat ervaring) van het domein waarin het probleem zich afspeelt, de notie dat het probleem niet triviaal is, en analysevaardigheden. Dat zegt dus iets over de persoon die het probleem probeert te snappen en de aanpak om het probleem op te lossen.
Een klassiek voorbeeld van een gecompliceerd probleem is het verhaal over hoe twee verschillende horlogemakers een horloge, dat uit 1000 onderdelen bestaat, in elkaar kunnen zetten. De ene horlogemaker (nr. 1) maakt het horloge door de onderdelen één voor één in elkaar te steken. De andere horlogemaker (nr. 2) door de logisch bij elkaar horende onderdelen in componenten bij elkaar te voegen en dan de componenten tot één geheel te maken. Beide horlogemakers hebben kennis van het domein maar voeren een andere aanpak. Gebleken is dat de aanpak van horlogemaker 2 efficiënter is. Ik gebruik deze ‘analogie’ ook wel eens om uit te leggen waarom het werken met services en procesbrokken efficiënter kan zijn, maar dat is weer een ander verhaal.
Ook het in elkaar steken van een legpuzzel zonder het voorbeeld werkt op die manier. Als we eerst legpuzzelstukjes uitzoeken op de randjes (de hoekjes zijn zeer belangrijk ! ;)) en de rest verdelen in kleuren, wordt het in elkaar zetten simpeler. Roger Sessions, die het boek ‘Simple Architecture for Complex Enterprises’ schreef, liet ons dit in zijn training aan de lijve ondervinden. Hij gaf een groep van deelnemers (a) een puzzel die in vier hoopjes van bij elkaar behorende stukjes was verdeeld, waarbij elke persoon zijn component in elkaar kon zetten en vervolgens het geheel geassembleerd. De andere groep deelnemers (b) kreeg alle stukjes ongesorteerd. Het was een lastig probleem voor groep b, we hadden geen voorbeeld (geen domeinkennis) en de dynamiek van samenwerking van 4 personen voor 1 probleem gaf misschien wat complexiteit als aanvulling door de onzekerheid over het domein, maar enfin. U begrijpt dat groep a sneller klaar was. Het gaf aan dat een gecompliceerd probleem simpel(er) kan worden opgelost als het in brokken is verdeeld ook als er enige onzekerheid is. Roger noemde de brokken 'synergetisch' bij elkaar horende onderdelen.
Managers en vele andere wetenschappers, architecten, softwareontwikkelaars en noem nog maar eens een hele riedel beroepsgroepen op, leren het principe van ophakken in onderdelen om begrip te krijgen van het probleem en als aanpak voor het oplossen ervan. De meeste problemen van gecompliceerde aard kunnen geanalyseerd worden door het ene (grote) probleem in brokken op te splitsen en dat is wat meestal gebeurt. Het is geschikt om de moeilijkheid te reduceren door ophakken in stukjes. Men noemt dat complexiteitsreductie. Een foute benaming in mijn idee, dus.
Complex
Ook complex heeft twee kanten nl . het ‘probleem’ en persoon die het probleem moet oplossen. Een complex probleem is ook ‘groot’ want is niet triviaal. Verschil is echter dat een complex probleem een dimensie kent die je bij een gecompliceerd probleem niet zult aantreffen namelijk: samenhang in een geheel.
De persoon die een complex probleem moet oplossen moet niet alleen over (domein)kennis beschikken en analysevaardigheden maar tevens over inzicht en besef van het grote geheel waarbinnen zich het probleem bevindt. Sterker nog: de persoon moet over een flinke dosis sensitiviteit beschikken want de meeste complexe problemen gaan niet de ‘harde’ zaken zoals een technische architectuur, de boekhouding, een vastgoedportefeuille, een rekenprogramma o.i.d. maar hebben samenhang met ‘zachte’ zaken. In het systeemdenken spreekt men over niet-lineaire relaties binnen een probleem (en een tijdsvertraging tussen de oorzaken en het ondervinden van een probleem, ook dat nog 
)
Als een probleem dat samenhangt met ‘zachte’ zaken zoals mensen, macht en –dit is belangrijk!!- bestaat uit elkaar beïnvloedende onderdelen van het probleem zelve, dan biedt het opknippen in stukjes niet meer de oplossing.
Het door managers gebruikelijkerwijs opknippen in stukjes negeert dan de connectie, of erger nog, maakt de samenhang stuk en levert een suboptimale aanpak / oplossing om maar eens een understatement te gebruiken. Dit levert o.a. de BOHICA of 'not invented here' houding op, politiek gekonkel en gekromde tenen bij degene die wel de verbanden kunnen leggen of de samenhang zien.
Ophakken in kleine stukjes van complexe problemen is een instrumentele en welhaast mechanische benadering en is daarmee als de spreekwoordelijke hamer. Je weet wel, het gereedschap dat maakt dat je in alles een spijker ziet. Zonder overzicht in de samenhang en de onderlinge beïnvloeding, komt het probleem nadat je dacht dat het opgelost was, weer opnieuw tegen en opnieuw en opnieuw.
Zoals ik met alle stellingen in deze serie beweer: Er is leiderschap m/v voor nodig om hulp te bieden aan het oplossen en aanpakken van (complexe)problemen.
De link met Agile en LEAN
Hoewel ook Agile en LEAN concepten zijn die in verschillende onderdelen verdeeld zijn – Agile met haar 4 kernwaarden en 12 principes en Lean bijvoorbeeld met z’n 5S, verspilling voorkomen door TIMWOOD en visualisatie- erkennen beide impliciet of expliciet dat de problemen, die beoogd te worden opgelost, met elkaar verband houden. In een omgeving afspelen die één geheel vormt. En opgelost zouden moeten worden met een fundamenteel andere benadering over wat leiderschap inhoudt.
Waarom de titel van Roger Sessions boek niet omgedoopt moet worden naar: Simple Architectuur for Complicated Enterprises? Omdat hij de samenhang tussen van bedrijfsprocessen en domeinen geïdentificeerd heeft door (het aantal) connecties tussen de componenten. Ook hier is het de samenhang die het complex maakt.
Aanbevolen literatuur
Naast het boek ‘de Intensieve Menshouderij’ van Jaap Peters kan ik u als leesvoer het boek ‘ The Fifth Discipline’ van Peter Senge aanbevelen. Of neem kennis van de inhoud van het boek ‘systeemdenken’ van Bryan, Goodman en Schaveling.
Is er nog iets ergers dan complexiteit?
Ik wil het niet te wazig maken maar ik heb nog even een nabrander. Er zijn in deze tijd van leven zelfs problemen die het predicaat RAPLEX verdienen. Dat is de vergrotende trap van complex: complex in a rapid changing environment. Mmm, dat zijn nog eens uitdagingen! Ik wens van harte dat managers er hun tanden niet op breken. Hoe dat te voorkomen wordt duidelijk door de tips die in deze serie naar voren komen.
De volgende blog in deze serie gaat over het misverstand (nr. 5) dat de wedstrijd gelijk is aan het dashboard/ scorebord.
vakantie avonturenGeplaatst door Mary Beijleveld zo, augustus 15, 2010 16:47:00Op vrijdag ochtend om 7 uur vertrokken we met de auto richting Zwitserland. Tot Venlo verloopt de reis prima. Geen files of oponthoud. Zoals altijd nemen we de A 61, de linksrijnse oever, in Duitsland. Woaoaw, tot de aansluiting met de A5 in de buurt van Mannheim tel ik 16 plekken met wegwerkzaamheden en bij Hockenheim staat een enorme file i.v.m. de race van zaterdag.
Na al deze hobbels rijdt het verkeer op de A5 richting Basel weer prima door. De grens en Basel zijn uiteraard druk, zoals gebruikelijk. We overnachten in Bern en de weg van Basel naar Bern is weer lekker rustig. Even over 7 uur ‘s avonds komen we aan in hotel Astoria, checken snel in en gaan daarna op zoek naar een fatsoenlijk restaurant. We moeten even langs de flappentap want in Zwitserland wordt de euro niet als betaalmiddel gevoerd. Wel leuk deze ‘folklore’ en het geeft een extra vakantiegevoel.
Heerlijk gegeten met een aangenaam glaasje Zwitserse rode wijn erbij; mijn wederhelft nam een Zwitserse witte want dat past beter bij zijn gerecht. Naar zeggen is ook dit een prima wijn. Na een goed nachtrust (aanrader, dit hotel!) ontbijten we om 9 uur en vertrekken om 11 uur voor de reis naar onze vakantiebestemming.
Via de weg langs Thun- & Brienersee en de Sustenpass (4 graden C, mist, regen en eeuwige sneeuw) komen we in de buurt van Wassen, waar we de A2 op willen. Vanaf de berg zien we een kilometerslange file naar de Gothardtunnel. Geschatte wachttijd 5 uur. We besluiten eerst te gaan tanken om vervolgens over de Göschenen- en Gothardpass te gaan. Veel sturen maar dat vindt mijn man juist wel leuk. Ook op deze passen is de buitentemperatuur zo laag en het weer zo grauw dat we een ‘vorst’ waarschuwing vanaf het dashboard krijgen.
Na de pas rijden we in droog weer naar het huurhuisje in Vogorno. Eerst even lang een mega supermarkt om wat inkopen te doen. Het allerlaatste stukje moeten we op een weggetje, breed genoeg voor 1 auto, steil naar boven rijden om te arriveren om 4 uur ’s middags. Het is een granieten huis met carport, steile trap naar de ingang 1 verdieping lager en tuin met pergola. Het interieur is verzorgd en compleet en laat niets te wensen over. Vanaf de tuin aan de voorkant hebben we een schitterend uitzicht op het stuwmeer van Vogorno en in de verte zien we een stad aan het Lago Maggiore liggen. Eerst even ‘settelen’ en twee dagen autorijden kwijtraken. Morgen de buurt verkennen.
Het stuwmeer blijkt geen echte toegang te bieden om te zwemmen. Je kan er wel komen maar dan na een klimpartij van heb-ik-jou-daar; het water is koud en er staat een flinke stroming. 
Onderaan de weg naar ons huisje is een vulstation voor duikflessen dus kennelijk zijn er wel lieden die het water in gaan. De stuwdam torent 220 meter hoog boven de rivier die naar het Lago Maggiore loopt. De stuwdam maakt deel uit van een heel stelsel aan stuwdammen en waterkrachtcentrales maar daar kom ik op terug verderop in dit verhaal. Er is in de buurt van het dorp een uitgebreide middenstand.
Locarno is een leuk plaatsje en biedt een boulevard en boottochten over het meer en een kabelbaan naar de berg die hoog boven de stad reikt. Ook hier geen publiek strand, wel niet-publieke “Lido’s”en een echt zwembad. Het heeft een mondain karakter.
In Bellinzona hebben we het Castel Grande bezocht. In de verte zien we het Castel Montobella liggen en er moet nóg een groot kasteel in de buurt zijn. Het is warm weer, vergt veel trappenlopen en ik heb de hele vakantie al pijn in mijn knieën. Dus we houden het bij deze ene en wandelen nog wat in de omgeving van het kasteel.
Op de stuwdam nabij ons vakantieadres wordt op zondag en dinsdagen ge-bungee- jumpt. Bij navraag blijkt mag ik niet meedoen want het maximum aantal kilo’s dat je mag wegen is ca. 80. Nou daar ga ik ver overheen. Ik kijk hoe een aantal schriele dames van formaat ‘Italiaanse poppetjes’en een paar jongemannen wel een jump mogen maken. Met afschrikwekkend gegil laten zij zich in de afgrond vallen en worden met een trots en grijnzend gezicht weer op de stelling getrokken. Super afgunstig ben ik! Het leek me echt iets voor mij. Dit is imers de stuwdam waar 007 in GoldenEye zijn basejump deed. 
Onze tochten door de Vallei van de Maggia, Bavone en Lavitaza zijn erg leuk. De bergen en bossen, watervallen (o.a. Foroglio), stuwdammen, granieten boerderijen en opslaghuisjes op palen zijn sprookjesachtig. Evenals de uitzichten. Aan het eind van de dag aldoor eerst langs de buurtsuper om avondeten te halen en broodjes voor de volgende ochtend. In de tuin is een stenen BBQ / haard die we enkele keren goed gebruikt hebben.
In dit deel van Zwitserland spreekt iedereen Italiaans. Ook de wegbewijzering en naamplaatjes zijn Italiaans. De provincie heet Ticino (naar de gelijknamige rivier) c.q. Tessin. Het Lago Maggiore is grotendeels Italiaans en vormt de grens met dit land. Net als het meer van Lugano verderop. Lugano is nog Zwitsers maar het grootste stuk van het meer is van Italië.
Na een week met z’n tweetjes arriveren mijn zus en haar man in de vroege middag. Zij zijn donderdagnacht vertrokken en hebben, behalve alle wegopbrekingen, geen oponthoud gehad. We hebben de lunch klaargezet. Terwijl zij een paar uurtjes slapen loop ik door mijn email, die ik met de ‘dongel’ heb opgehaald. Hier geen wifi.
Het is een leuke week geworden. Naast gezellig samenzijn en lekker gegeten, hebben we een hoop gedaan. We zijn met de funiculaire van San Carlo naar de Monte Robiei gegaan voor uitkijk op de gletsjer en de hoogste stuwdam van het hele stelsel, waar ik het hiervoor ook al over had. Per jaar levert dit ingewikkelde stelsel vele tienduizenden gigawatts aan elektriciteit op. Erg indrukwekkend
Ook een ritje via Ascona langs het Lago Maggiore, waar we zowat over de Bentley’s, Mercedessen 500 en 600 en prijzige BMW’s struikelde. Over mondain gesproken. 
Wij zijn de Italiaanse grens overgegaan en met de veerpont (daar had ik juist genoeg euro’s voor in de beurs, pff) naar de overkant om vervolgens weer naar de Zwitserse kant te rijden. Onderweg in een Italiaanse taverna gegeten en citroenijs genoten. Op het meer van Lugano hebben we een bootrondreis gedaan, hebben onder de druivenranken geluncht en zijn naar het douanemuseum geweest. Dat laatste was niet spectaculair maar het bootreisje was erg fijn. In het zonnetje op het dek en wind in de haren. Genieten!
Verder zijn we nog een dag met een tandradtrein naar de Monte Generose geweest, hebben daar een klein klimmetjes gedaan (mijn arme knieën) en geluncht. Echte spectaculaire uitzichten met uitzicht op het meer van Lugano, in de verte Lugano zelf en een aantal plaatsen zoals o.a. Meride. Als hier in de winter geskied wordt, dan zijn deze afdalingen superinktzwart. Dat zie ik mezelf dan weer niet doen.
Donderdag, bijna aan het eind van de tweede week, besloten we ’s avonds na het avondeten de terugreis te beginnen. Zowel vrijdag als zaterdag werd een recorddrukte op de Zwitserse en Duitse wegen verwacht. Bovendien is het weer gaan regenen en dit keer komt het echt met bakken uit de hemel, zodanig dat aan de bergwand aan de overkant van het meer ineens 3 watervallen zijn ontstaan. Mijn man is het eens met mijn typering: bergklimaat met mediterraan karakter . Afwisselend warm/koud, zon/mist/regen, sproeten-bijkleur-weer en warme-sweater-aan-weer.
De reis terug verliep voorspoedig. De 3 kwartier wachttijd voor de Gothardtunnel was te doen en we zijn ‘in een keer’ terug gereden. De hele rit duurde 12 uren, inclusief de tankstops en wisselmomenten. Toch had ik een beetje last van een jetlag na zo’n nacht doortrekken. Ik was blij dat mijn zwager ‘de haas’ speelde toen ik reed. We kwamen thuis op het moment dat de buurman naar zijn werk ging. Thuis konden we verder uitrusten, in mijn eigen bed slaap ik toch het best. Nu na een weekje thuis heeft Fons het film- en fotomateriaal tot een DVD omgetoverd. Geeft een mooie impressie.
-
AgileGeplaatst door Mary Beijleveld za, augustus 14, 2010 13:32:49Op het ogenblik volg ik met meer dan gemiddelde belangstelling de acties in de lean architecture groep op LinkedIn en de blogposts van Denis, Gerard, Gero en Sander.
Niet alleen vanwege het onderwerp maar natuurlijk ook omdat ik enige overeenkomst zie met de stellingen in mijn artikel voor InfoQ "Agile and SOA, hand in glove" en enkele verkregen inzichten bevestigd zie 'from the trenches'. Om het zo maar eens uit te drukken.
Wat erg prettig is, is dat je kunt zien dat de opgesomde (11) principes uit de lean architectuur benadering, aan kwaliteit winnen naarmate de tijd vordert. En dat is al Lean (en Agile) op zichzelf.
Een aantal van de principes hebben een sterk verband met een Lean principe: eliminate waste, zoals #2 travel light, #7 architecture initiated by business goals, #10, architecture emerging from projects en #8 focus on the value stream.
#5 just in time, just enough is zeer herkenbaar als het JIT principe.
De (kleine) feedbackloops die een continue kwaliteitsverbetering tot gevolg moeten hebben zijn herkenbaar in de principes #3 think BIG, take small steps (Wauw, dat deed mij enorm goed
) , #6 iterative architecture development en #11 freedom where possible, standardization where needed.
Verder zie ik enig verband met het Lean principe van 'suggestions systems" en "autonomation" in de principes #1 always involved en #4 all hands on deck early on. #9 comprehensible over comprehensiveness heeft mogelijke enige link met het visualisatieprincipe.
De link naar de Lean principes kan naar mijn mening toch sterker.
Wel komen de 4 kernwaarden van Agile goed terug. Bij mij rijst dan de vraag of we het hier dan over Lean of Agile architectuur hebben. Daar wordt nog steeds, tot mijn verdriet overigens, flink onderscheid in gemaakt. Maar kiezen voor Agile maakt de connectie met de business waarschijnlijk minder en de verkoopbaarheid lager. Agile klinkt (allang) niet meer sexy bij de business.
Want hoe mooi is om te merken dat door toepassing van 'wikinomics' en kennisdeling tussen een bedrijf en de Agile / Lean community, ideeën omgezet worden in praktische - en straks ook commercieel - toepasbare concepten/aanpakken. Ik verwacht dat vóór het einde van het jaar de kwaliteit zodanig is dat de presentatie en de uitwerkingen gebruikt kunnen worden voor opleiding/training voor klanten en belangstellenden tegen een marktconforme vergoeding. De in deze ontwikkeling gestoken tijd en energie wordt immers voor een deel 'in de baas zijn tijd' verstookt en de pijp moet ook roken
Ik twijfel of er met deze lean architectuur principes tevens een relatie gelegd kan worden naar architectuur op enterprise niveau. Wat nu is ontwikkeld bevindt zich naar mijn mening op operationeel niveau, zeg maar solutions architecture. Dan zijn de stellingen en vergelijkingen in mijn artikel volgens mij méér op bedrijf/enterpriseniveau.
Maar ik ben de beroerste niet, dus heb ik in reactie op de dia's op slideshare en het lekker simpele logo van de LI group, een plaatje gemaakt die de 3 architectuurprincipes "cohesion, connection en changeability" verbindt met 4 dimensies waarin de 11 Lean architectuurprincipes thuishoren: "business, proces, communication en artifacts".
Ik hou er nu eenmaal van om verbanden te leggen en om mij ermee te bemoeien. En wie weet, heeft iemand er iets aan..
laatste nieuwsGeplaatst door Mary Beijleveld di, augustus 10, 2010 14:23:08Henk de Vries schreef: (zaterdag 31 juli 2010)
Hoi Mary,
Even een reactie op de 2 blogs die je hebt geschreven over misverstanden. Zelf denk ik ook veel over deze dingen na en ben een eind op weg om het gegroepeerd te krijgen.
Wat je in je blog schrijft, is dat het beschrijven op zich geen garantie is voor kwaliteit. Dat vind ik herkenbaar. Wat ik wel denk is dat beschrijven een eerste stap kan zijn op weg naar kwaliteit.
Ter introductie: ik ben sinds een jaar bezig bij een investeringsbank om alles
rondom weblogic (mijn expertise) in kaart te brengen, processen te beschrijven en af en toe de weblogic productie omgevingen weer aan de praat te krijgen. Dit alles onder het mom van "In Control" zijn en van het maken van herhaalbare processen.
De bron van deze hele discussie is m.i. de vraag: “is het mogelijk kennis op te slaan, zodanig dat het
1. snel te vinden,
2. actueel en
3. relevant is
op het moment dat het nodig is zonder dat een persoon de drager van de kennis is?”
Wat je in het verhaal hieronder vindt is een eerste neerslag van mijn ideeën over kennis, de overdracht daarvan en herhaalbare processen. Ik wil dit graag tegen je aanhouden om het te toetsen en aan te scherpen.
Het ideaal van de lijn organisatie (waar ik werk dan) is dat je op het moment dat je kennis nodig hebt, je het uit de kast trekt en het laat lezen door een persoon zodat de kennis kan worden toegepast. Kan dat?
Ik noem dit het dehydratie model van kennis: Kennis is als cup a soup. Op een of andere manier ben je in staat kennis vast te leggen (poeder te maken), zodat iemand het alleen hoeft te lezen (water erbij) en je hebt weer kennis (soep). Misschien is het cup a soup model wel beter als term ;-).
Volgens mij ligt dit model ten onrechte ten grondslag aan een heleboel activiteiten als kennisoverdracht, ISO certificeringen en dergelijke.
Het punt is dat ten eerste de verpoedering vaak niet volledig lukt. Je weet niet altijd wat er nodig is, de relevantie kan ontbreken en je kunt niet elke situatie beschrijven, je kunt altijd alleen maar een begin maken met het beschrijven van concrete processen, applicaties en het resulterende landschap.
Ten tweede dat de kennis vaak heel moeizaam terug te vinden is voor mensen die nieuw zijn binnen een organisatie en dat die kennis verouderd kan zijn.
Ten derde loopt kennis hand in hand met ervaring. Kennis dient geënt te worden op reeds bestaande kennis en samen te gaan met inzicht dat gewonnen is uit ervaring.
Ten vierde is kennisoverdracht tussen personen effectiever omdat er interactiviteit mogelijk is, iets dat bij kennisoverdracht via papier niet mogelijk is. Dat raakt natuurlijk ook aan agile ideeën als documenten zien als een uitnodiging tot een conversatie. Herhaalbaarheid van processen is een ideaal dat achter de tekentafel heel mooi klinkt, ik denk dat het niet kan omdat ik hierboven heb uitgelegd dat het cup-a-soup model van kennis niet werkt.
Hoe moet kennis dan worden overgedragen?
- Kennis kan niet altijd worden overgedragen en dient steeds opnieuw te worden ontwikkeld en herzien. Die ontwikkeling is een (re)creatief proces dat vorm krijgt.
- Door dingen uit te proberen en gewoon te doen en daarbij goed te observeren
- Door een conversatie tussen iemand die meer en iemand die minder kennis heeft
- Door nieuwe oplossingen voor oude en nieuwe problemen te verzinnen en bestaande oplossingen toe te passen
- En tenslotte door relevante, actuele en goed te vinden documenten te lezen
Het is een heel verhaal geworden, je hebt nogal wat losgemaakt ;-).
Mary's reactie daarop: (8 augustus 2010)
Inmiddels weer terug in Nederland en tijd om op je mail te reageren. Ik vind jouw reactie waardevol. Mijn vraag aan jou is of ik jouw reactie ook op mijn weblog mag zetten. Dat zou ik heel fijn vinden.
Jouw ervaringen en overwegingen maken namelijk nog meer duidelijker dat het hebben van handboeken niet maakt dat je e.e.a. geregeld hebt en dat certificering niet hetzelfde is als kwaliteit. Je bevestigt het eigenlijk ook. Dat het hebben van handboeken en het certificeren wel nut heeft en ook een stap is naar het goed geregeld hebben en naar kwaliteit, is evenzeer waar.
Het is zo goed dat je de link legt naar kennismanagement. Daar raak je een punt dat mij zeer aan het hart ligt. Ik heb (niet zelf verzonnen, hoor) kennismanagement in 3 dimensies /niveaus verdeeld:
1. Asset management, daar vallen de handboeken onder en de certificering maar eigenlijk kijk je daar wat je aan cruciale(!) kennis in huis hebt.
2. Acces management, daar zorg je dat iemand de kennis kan gebruiken, benaderen (via wiki, leermeesterschap, tijd om de bibliotheek in te gaan, te zoeken)
3. Accruement management, daar vergroot je kennis, innoveer je, gebruik je nieuw oplossingen voor oude problemen en oude oplossingen voor nieuwe problemen.
In feite komt jouw verhaal, hoewel op een andere manier ingedeeld sterk overeen met de niveaus en dimensies, die hierboven beschreven zijn. Je bent er beslist niet met de cup a soup, terwijl deze wel als basis kan dienen.
Goede managers zullen ervoor zorgen dat minimaal dat de zakjes cup a soup klaarliggen en de betere manager kijken ook nog regelmatig of de houdbaarheidsdatum niet is overschreden ;) Om deze dimensies / niveaus van kennismanagement in te voeren en uit te voeren in een bedrijf heb je leiders met visie nodig. Dat vraagt ook maatregelen die misschien niet zo voor de hand liggen en een aanpak die niet eerder is uitgevoerd.
We kunnen hier nog wel een boompje over opzetten.
laatste nieuwsGeplaatst door Mary Beijleveld wo, juli 28, 2010 13:29:56Hoge kwaliteit van een systeem = hoge output.
In mijn artikel /blog noemde ik als voorbeeld bedrijven die door de moedermij / multinational zijn opgezweept om zeer hoge output te leveren. Deze worden vervolgens in de uitverkoop gezet nadat ze voldoende zijn uitgemolken. Meestal hebben deze bedrijven 1 specifiek ding waar ze een hoge productie van kunnen leveren. Of deze productie van hoge kwaliteit is, is niet belangrijk. Het gaat om er geld aan te verdienen, als speculatieobject of als wisselgeld. Als het echt om kwaliteit ging dan was de holding er namelijk alles aan gelegen het bedrijf te behouden.
Degene die vakinhoudelijk georiënteerden - de goede medewerkers of de informele leiders - die door hebben dat kwaliteit heel iets anders is dan hoge productie, zijn of blind voor de bedoelingen van de holding of ze hebben ‘t door en gaan serieus op zoek naar ander emplooi, zijn inmiddels al vertrokken of staan op de rand van een burn-out. De manager gaat door met maatregelen voor het opkrikken van de productiecijfers want daar zijn zij erg goed in.
Een ander voorbeeld is die uit de veeteelt / bio-industrie. Dat kennen we allemaal. Kuikens die zo opgefokt zijn dat hun blanke kippenborstjes in verhouding tot hun skeletjes zo zwaar worden dat ze door hun pootjes zakken. Hoge productie per kip? JA. Kwaliteit? NEE. Varkens en kalveren opgehokt in een ruimte, afgepast op de vierkante millimeter. Hoge productie aan vlees per vloeroppervlak? JA. Kwaliteit van vlees? NEE, het smaakt nergens meer naar. Daarnaast bijten de dieren elkaar de staart af, kluiven op elkaars oren en lijden aan bloedarmoede. En zijn kandidaat voor de vreselijkste ziektes, krijgen daarom hoge dosis aan antibiotica toegediend waardoor deconsument er resistent van wordt.
Als we voorbeelden van dit misverstand in de software-industrie willen vinden hoeven we ook niet ver te zoeken. In een software ontwikkelproject is bijvoorbeeld een zeer hoog aantal regels code echt geen teken van kwaliteit. Sommige vergelijken het KLOC (dat betekent, dacht ik, kilo lines of code) per project. Ik zag dat nog niet zo lang geleden in een presentatie over gedistribueerde c.q. offshore softwareontwikkeling. Het team produceerde in verhouding tot een traditioneel software ontwikkelteam vele malen meer. Hoge productie? JA. Maar leverde het ook waarde voor de klant? Of ging het hier om KLOC in de betekenis van “kilo load of crap”?
Het Agile principe: ‘Simplicity--the art of maximizing the amount of work not done--is essential’ is hierin erg duidelijk. Less is more. Ook het principe van ‘a sustainable pace indefinitely’ geeft al aan dat er kwalitatief goed gewerkt moet worden, waardevolle zaken opgeleverd moeten worden al is dat in verhouding bijzonder ‘klein’. Dit is essentieel. Kwaliteit heeft tijd nodig. Bij een hoge productie per sprint is er een grote kans op blijvende problemen. Het invoeren van een kanban (Lean) systematiek in een sprint is, naast nog enkele andere technische zaken, ook een manier om de software kwaliteit te verbeteren en tegelijkertijd een constante stroom te handhaven.
Ook bij Lean gaat het om duurzaam waarde toevoegen / succes. Bij problemen leggen we de lijn meteen stil, we verhelpen het probleem en eerst dan gaan we weer verder. Ook hier heeft kwaliteit tijd nodig. Pas na vele iteraties en feedbackloops komt een groei in kwalitatief goede en hoge output. Deze groei bereik je via Lean met continu verbeteren (Kaizen). Terwijl overproductie sowieso als een verspilling wordt beschouwd. (trouwens, bij BPM ook)
Om nog maar eens een paar voorbeelden te geven van hoge output en bedenkelijke kwaliteit:
· De ontvangst van een hoog aantal – slecht ingevulde – formulieren,
· tig wekelijkse rapportages over de voortgang van een project zonder dat risicobeperkende maatregelen werden uitgevoerd, een ontwerp op hoofdlijnen van 284 pagina’s en 3 PSA’s van ieder minimaal 70 bladzijden die niemand aansprak behalve de makers
· Een in 2 weken tijd opgestelde lijst van 392 non-functional requirements. JA, lekker snel en hoge output. Kwaliteit? NEE. Men zag door het spreekwoordelijk bos de bomen niet meer. Om er ‘iets’ mee te kunnen moest deze lijst dan maar eerst gerubriceerd worden in de bekende Quint2 kwaliteitsaspecten. Ha, kwaliteit? Welnee, vervolgens kwam men er achter dat dit weinig hielp, waarna met de MOSCOW methodiek e.e.a. teruggebracht werd tot ca. 50 must haves.
Dat waren sprintjes trekken met hoge productie, de druk werd telkens opgevoerd. Die 50 must haves, overigens, bleven daarna onderwerp van eindeloze discussies en werden steeds minder relevant.
Je kunt wel stellen dat ik op meerdere momenten in de tijd en op zeer verschillende niveaus heb ervaren dat hoge output niet hetzelfde is als hoge kwaliteit. Het is eigenlijk van de gekke dat er in elke taal wel een waarheid te vinden is dat aantoont dat de hoge kwaliteit van een systeem niet het zelfde is als hoge output. Je vraagt je af waarom managers nog steeds deze waarheid blijven ontkennen.
Ik heb zelf eens op de man af gevraagd waarom bepaalde maatregelen genomen werden om de 1 jaar geleden afgegeven planning zouden respecteren maar die in mijn ogen de kwaliteit teniet zouden doen. Mij werd toegebeten dat het was om de druk op te voeren! Precies mijn punt: is niet alleen slecht voor de kwaliteit maar uiteindelijk ook contraproductief. Mijn argumenten kwamen echter niet aan en we moesten doorwerken tot 12 uren per dag. Mijn analyse met voorstellen en alternatieven werd als bedreigend gezien en ik was opgelucht dat ik het project kon verlaten. En ik was een illusie armer: dat een doorsnee manager ook een leider zou kunnen zijn.
Eigenlijk geldt voor alle voorbeelden, hier gegeven, dat beter het principe ‘
work slower to go faster’ toegepast zou moeten worden. De chinezen hebben ook een mooi gezegde “
’we hebben haast, dus laten we eerst eens rustig nadenken’. Of wat vind je van deze: "
work smarter, not harder". Deze laatste probeer ik al sinds een jaar of 20 uit. (met wisselend succes, dat is dan wel duidelijk
)
