Een waargebeurd verhaal, ik heb alles met mijn eigen ogen gezien.
Jarenlang werkte een jongen, net als velen van jullie, als programmeur. Voor de zekerheid zal ik het zo formuleren: "programmeur". Want hij was een 1C-specialist, werkzaam in een productiebedrijf.
Eerder had hij verschillende functies geprobeerd – 4 jaar als programmeur bij een franchise, projectmanager, hij was in staat om 200 uur te sluiten, terwijl hij tegelijkertijd een percentage van het project ontving, voor het leiderschap en een beetje bezig was met verkopen. Hij had geprobeerd om zelfstandig producten te ontwikkelen, was hoofd van de IT-afdeling in een groot bedrijf met 6000 werknemers, en had verschillende mogelijkheden van zijn "specialistische" beroep – 1C-programmeur – uitgeprobeerd.
Maar al deze posities waren enigszins doodlopend, vooral wat betreft het inkomen. We verdienden toen ongeveer hetzelfde, werkten onder dezelfde omstandigheden.
Deze jongeman werd geïnteresseerd in hoe hij meer geld kon verdienen, zonder zich met verkopen bezig te zijn en zonder zijn eigen bedrijf op te zetten.
Hij zag zichzelf als een slimme jongen en besloot een niche te vinden in het bedrijf waar hij werkte. Deze niche moest iets bijzonders zijn, niemand had het bezet. En hij wilde dat het bedrijf zelf geld wilde betalen aan iemand in deze niche, zodat hij niemand hoefde te bedriegen of iets te manipuleren. Het moest objectief zijn: iemand in deze positie moest veel geld verdienen. Een vreemd figuur, met andere woorden.
De zoektocht was niet lang. In het bedrijf waar deze jongen werkte, was er een vrij lege niche, die we "orde scheppen in bedrijfsprocessen" kunnen noemen. Elke onderneming heeft talloze problemen. Er gaat altijd iets mis en er is niemand die komt en het bedrijfsproces herstelt. Dus besloot hij het te proberen als een specialist die de eigenaar kan helpen zijn problemen in de bedrijfsprocessen op te lossen.
Op dat moment werkte hij een half jaar in het bedrijf en ontving hij het gemiddelde salaris op de markt. Hij had niets te verliezen – vooral omdat hij een soortgelijke baan binnen een week kon vinden. Over het algemeen redeneerde deze jongen dat er niets ergs zou gebeuren als het niet zou lukken en hij werd ontslagen.
Hij verzamelde zijn moed en ging naar de eigenaar. Hij stelde voor om het meest problematische proces in het bedrijf te verbeteren. Op dat moment was dat het magazijnbeheer. Nu is het voor iedereen die in dit bedrijf werkt zelfs gênant om terug te denken aan die problemen, maar de voorraadinventarissen die elk kwartaal werden uitgevoerd, toonden afwijkingen tussen het boekhoudsysteem en de werkelijke voorraden van tientallen procenten. Zowel in waarde als in aantal en in het aantal posities. Het was een ramp. Het bedrijf had in werkelijkheid slechts vier keer per jaar de juiste voorraden in het boekhoudsysteem – de dag na de inventarisatie. Dit proces begon onze jongen op orde te brengen.
De jongen kwam met de eigenaar overeen dat hij de afwijkingen in de inventarisatie met de helft moest verminderen. Bovendien had de eigenaar niet veel te verliezen, omdat verschillende medewerkers al eerder hadden geprobeerd om alles recht te zetten, en de taak in het algemeen als vrijwel onoplosbaar werd beschouwd. Dit verhitte de interesse enorm, want als alles zou lukken, zou de jongen automatisch de persoon worden die orde kan scheppen en onoplosbare problemen kan oplossen.
Dus stond hij voor de taak: binnen een jaar de afwijkingen in de inventarisatie met de helft te verminderen. Op het moment dat het project begon, wist hij niet goed hoe hij dit moest aanpakken, maar hij besefte dat magazijnbeheer een eenvoudig iets was, dus zou hij hoe dan ook iets nuttigs kunnen doen. Bovendien, het verlagen van de afwijkingen van tientallen procenten naar enkele procenten lijkt niet zo moeilijk. Iedereen die in de adviessector of soortgelijke activiteiten werkt, snapt dat de meeste procesproblemen worden opgelost door vrij eenvoudige acties.
Van januari tot mei heeft hij zich voorbereid, een beetje geautomatiseerd, het bedrijfsproces van de voorraadadministratie herschreven, de werkschema's van de magazijnmedewerkers en boekhouders gewijzigd en in het algemeen het hele systeem veranderd zonder iemand iets te laten zien of te vertellen. In mei gaf hij iedereen nieuwe instructies, en na de eerste inventarisatie van het jaar begon een nieuw leven – werk volgens zijn regels. Om de resultaten te observeren, begon het bedrijf later vaker inventarisaties uit te voeren – elke twee maanden. De eerste resultaten waren al positief, en tegen het einde van het jaar waren de afwijkingen in de revisieresultaten gedaald tot minder dan één procent.
Het succes was enorm, maar men geloofde niet in de duurzaamheid ervan. De jongen zelf twijfelde of het resultaat zou blijven bestaan als hij zich terugtrok en het proces niet meer in de gaten hield. Desondanks was het resultaat er, en kreeg de jongen alles waar hij met de eigenaar over was overeengekomen. Later, na een paar jaar, werd de duurzaamheid van het resultaat bevestigd - de afwijkingen bleven jarenlang binnen de 1%.
Toen besloot hij het experiment te herhalen en stelde hij de eigenaar voor om een ander problematisch proces te verbeteren – de bevoorrading. Daar waren tekorten die het niet mogelijk maakten om de hoeveelheden te leveren die onze klanten wilden. Ze kwamen overeen dat de tekorten binnen een jaar gehalveerd zouden worden, en de jongen zou bovendien 10-15 projecten uitvoeren die verband hielden met 1C, zoals de automatisering van verschillende bedrijfsprocessen en andere gerelateerde zaken.
In het tweede jaar slaagde hij er weer in alles succesvol af te ronden, de tekorten waren met meer dan de helft verminderd, en alle IT-projecten waren succesvol afgerond.
Aangezien het salaris al volledig voldeed aan alle eisen van de jongen voor de komende twee jaar, besloot hij om wat rustiger aan te doen, zich te kalmeren en op een gezellig, warm plekje te zitten dat hij zelf had gecreëerd.
Wat hield dat precies in? Formeel was hij IT-directeur. Maar wie hij werkelijk was, is moeilijk te begrijpen. Wat doet een IT-directeur eigenlijk? Gewoonlijk beheert hij de IT-infrastructuur, leidt hij de systeembeheerders, implementeert hij ERP-systemen en neemt hij deel aan vergaderingen van de raad van bestuur.
Een van de belangrijkste verantwoordelijkheden van deze man was deelname aan veranderingsprocessen, voornamelijk het genereren en initiëren van deze processen, het zoeken naar en voorstellen van oplossingen, het toepassen van nieuwe managementmethoden, het beoordelen van voorgestelde veranderingen, het analyseren van de effectiviteit van andere functies en afdelingen, en tot slot - directe bijdrage aan de strategische ontwikkeling van het bedrijf, tot het zelfstandig opstellen van een strategisch plan voor het hele bedrijf.
Hij kreeg carte blanche. Hij kon naar elke vergadering gaan waar hij voorheen geen toegang toe had. Hij zat daar met een notitieboekje, noteerde iets of luisterde gewoon. Hij sprak zelden. Daarna begon hij op zijn telefoon te spelen - hij beweerde dat dit zijn associatieve geheugen verbeterde.
Tijdens vergaderingen gaf hij zelden iets nuttigs. Hij ging weg, dacht na, en daarna kwam er een mail - of met kritiek, of met een mening, of met voorstellen, of met beschrijvingen van oplossingen die hij al had toegepast.
Maar vaker organiseerde hij zelf de vergaderingen. Hij vond een probleem, bedacht oplossingen, bepaalde de betrokken partijen en sleepte iedereen de vergaderzaal in. En daar deed hij wat hij kon. Hij overtuigde, motiveerde, bewees, voerde discussies en behaalde resultaten.
Onofficieel werd hij beschouwd als de derde persoon in het bedrijf, na de eigenaar en de directeur. Uiteraard irriteerde hij alle 'personen van het bedrijf' vreselijk, te beginnen met nummer 4. Vooral met zijn gescheurde jeans en felle T-shirts, en ook - de tijd van de eigenaar.
De eigenaar schonk hem elke dag 1 uur. Elke dag. Ze praatten, bespraken problemen, oplossingen, nieuwe bedrijven, ontwikkelingsrichtingen, indicatoren en effectiviteit, persoonlijke ontwikkeling, boeken, en gewoon - het leven.
Maar deze jongen was vreemd. Het leek alsof hij moest zitten en genieten, dat het leven gelukt was. Maar nee. Hij besloot te reflecteren.
Hij vroeg zich af: waarom was het hem gelukt, terwijl anderen dat niet deden? De eigenaar stimuleerde hem ook: hij zei dat hij wilde dat anderen ook in staat waren om orde te scheppen, omdat er veel managers zijn die over het algemeen zich bezighouden met operationeel beheer en strategische planning, maar bijna niemand houdt zich bezig met systematische veranderingen in hun processen. Misschien staat er in hun functieomschrijving dat ze hun proces moeten versnellen en de efficiëntie ervan moeten verhogen, maar in werkelijkheid doet niemand dat. Waarom is dat zo? Ook deze jongen was nieuwsgierig naar de redenen en ging met al die managers in gesprek.
Hij ging naar de kwaliteitsdirecteur en stelde voor om control kaarten van Shuhart in te voeren, zodat het product beter zou zijn dan het Japanse. Maar het bleek dat zijn collega niet wist wat control kaarten van Shuhart zijn, wat statistisch procesbeheer is, en alleen maar oppervlakkig had gehoord over de toepassing van de Deming-cyclus in kwaliteitsbeheer. Maar goed...
Hij ging naar een andere adjunct-directeur en stelde voor om controlling in te voeren. Maar ook hier vond hij geen steun. Even later kwam hij te weten over boundary management en stelde hij aan alle adjunct-directeuren voor om het systematische deel van deze methode in te voeren om de processen te verbeteren. Maar hoe vaak hij ook sprak, niemand wilde echt luisteren naar waar het over ging. Misschien vonden ze het niet interessant of te ingewikkeld. Maar feit is dat niemand het begreep.
Kortom, hij vertelde alles wat hij wist en toepaste in het bedrijf. Maar niemand begreep hem echt. Het is hen nog steeds niet duidelijk waarom, bijvoorbeeld, alles opgelost kon worden in de voorraadadministratie en wat controlling en boundary management daarmee te maken hebben.
Ten slotte kwam hij bij zijn programmeurs terecht – het team bestond uit drie mensen. Hij legde uit over boundary management, over controlling, over kwaliteitsmanagement, over agile en scrum... En tot zijn verbazing begrepen ze het allemaal, en konden zelfs met hem discussiëren, inclusief de technische en methodologische nuance. Ze begrepen waarom de projecten voor het magazijn en voor bevoorrading succesvol waren. En toen had de jongen een inzicht: in feite zullen programmeurs de wereld redden.
Programmeurs, realiseerde hij zich, zijn de enigen die normaal en met de benodigde detaillevel de bedrijfsprocessen kunnen doorgronden.
Waarom zij precies? In werkelijkheid heeft hij daar geen eenduidig antwoord op kunnen vinden. Hij formuleerde alleen enkele stellingachtige hints.
Ten eerste weten programmeurs meer over de zakelijke domeinen, en wel beter dan alle andere mensen in het bedrijf.
Bovendien begrijpen programmeurs echt wat een procesalgoritme is. Dit is belangrijk omdat bedrijfsprocessen algoritmen zijn en de elementen daarin vaak niet goed op elkaar zijn afgestemd. Neem bijvoorbeeld het inkoopproces waar die jongen aan werkte. De eerste stap is het opstellen van een jaarlijkse inkoopplanning en de tweede is dagelijkse inkoop. Deze stappen zijn met elkaar verbonden, wat betekent dat mensen volgens dit algoritme zouden moeten werken – de jaarlijkse inkoopplanning opstellen en onmiddellijk de aanvraag uitvoeren. De jaarlijkse inkoopplanning wordt eenmaal per jaar opgesteld, terwijl de aanvragen tot wel 50 keer per dag binnenkomen. Dit is waar het algoritme eindigt, en daarop moet gewerkt worden. In feite, concludeerde hij, is kennis van algoritmen voor programmeurs een concurrentievoordeel, omdat elke andere persoon die er niet mee bekend is, gewoon niet begrijpt hoe het bedrijfsproces zou moeten werken en hoe dit in beeld gebracht kan worden.
Een ander pluspunt van programmeurs, volgens die jongen, is dat ze genoeg vrije tijd hebben. We begrijpen allemaal hoe een programmeur drie keer zoveel tijd aan een taak kan besteden als dat die daadwerkelijk vereist, en weinigen zullen dat opmerken. Dit is opnieuw een concurrentievoordeel, omdat je veel vrije tijd nodig hebt om een bepaald bedrijfsproces op orde te krijgen — om na te denken, te observeren, te leren en te experimenteren.
De meeste managers, volgens die jongen, hebben die vrije tijd niet en zijn daar trots op. Hoewel dit in feite betekent dat een persoon niet effectief kan worden, omdat hij geen tijd heeft om zijn effectiviteit te verhogen – een vicieuze cirkel. In onze cultuur is het modieus om druk bezig te zijn, waardoor alles blijft zoals het is. Voor ons, programmeurs, is dit echter een voordeel. We kunnen vrije tijd vinden om over alles na te denken.
Programma's, zei hij, kunnen het informatiesysteem snel veranderen. Dit is niet op alle bedrijven van toepassing, maar overal waar hij heeft gewerkt, konden aanpassingen worden gemaakt zoals gewenst. Vooral als ze niemand anders beïnvloeden. Bijvoorbeeld, hij kon een systeem opzetten dat in het geheim de acties van gebruikers meet, en deze informatie dan gebruiken voor het analyseren van de effectiviteit van de boekhouding en het bijhouden van de kosten van de administratie.
En het laatste wat ik me herinner van zijn woorden – programmeurs hebben toegang tot een grote hoeveelheid informatie, aangezien ze administratieve toegang tot het systeem hebben. Daarom kunnen ze deze informatie gebruiken in hun analyses. Niemand anders in een gewone fabriek heeft deze middelen.
En toen ging hij weg. Tijdens de gebruikelijke opzegtermijn van twee weken hebben we hem gedwongen zijn ervaringen te delen, omdat we het werk dat hij deed wilden voortzetten. Bovendien kwam zijn functie beschikbaar.
Gedurende enkele dagen zetten we hem op een stoel, startten de camera en namen zijn monologen op. We vroegen hem om te vertellen over alle voltooide projecten, methoden, benaderingen, successen en mislukkingen, oorzaken en gevolgen, profielen van leidinggevenden, enzovoorts. We beperkten hem niet echt, omdat we niet wisten wat er in zijn hoofd omging.
In de monologen was er natuurlijk vooral veel onzin en gekheid – hij was in een geweldige stemming, omdat hij uit een uithoek naar Sint-Petersburg vertrok. En waar naartoe te gaan om te werken in Petersburg? Naar Gazprom, natuurlijk.
Maar we hebben wel wat nuttigs uit zijn monologen kunnen halen. Ik zal vertellen wat ik me herinner.
Dus, de aanbevelingen van die jongen. Voor degenen die willen proberen orde te scheppen in bedrijfsprocessen.
Om dergelijk werk te doen, moet je allereerst een bepaald niveau van 'hardheid' hebben. Je moet niet bang zijn om je baan te verliezen, niet bang zijn om risico's te nemen, niet bang zijn voor conflicten met collega's. Hij deed dit gemakkelijk, omdat hij zijn carrière begon toen hij nog maar zes maanden bij het bedrijf werkte en hij had nog geen contact kunnen leggen met iemand, en daar was hij ook niet van plan. Hij begreep dat mensen komen en gaan, en voor hem waren zijn eigen resultaten en de waardering daarvan door de eigenaar van het bedrijf belangrijk. Hoe goed of slecht zijn collega's over hem dachten, boeide hem toen weinig.
Een tweede punt is dat je helaas moet leren om deze taak effectief uit te voeren. Maar je leert niet via een MBA, cursussen of instituten, maar zelfstandig. Bijvoorbeeld, in zijn eerste project, met een magazijn, handelde hij intuïtief, hij wist niets, alleen wat "kwaliteitsmanagement" was.
Toen hij literatuur begon te lezen over welke methoden er zijn om de efficiëntie te verhogen, ontdekte hij technieken die hij al toepaste. De jongen paste ze intuïtief toe, en het bleek dat dit geen uitvinding van hem was, alles was al lang geschreven. Maar hij verspeelde tijd, en veel meer dan als hij meteen het juiste boek had gelezen. Het belangrijkste is te begrijpen dat wanneer je een specifieke methode bestudeert, geen enkele, zelfs de meest geavanceerde, alle problemen van een bedrijfsproces volledig oplost.
Een tweede tip is dat hoe meer methoden je kent, hoe beter. Bijvoorbeeld, in het oude Japan leefde Miyamoto Musashi - een van de bekendste zwaardvechters, de auteur van de twee-zwaardenstijl. Hij studeerde op een bepaalde school bij een bepaalde meester, daarna reisde hij door Japan en vocht met verschillende mannen. Als iemand sterker was, stopte de reis tijdelijk en ging Musashi in de leer. In de loop der jaren verwierf hij vaardigheden in verschillende praktijken van verschillende meesters en vormde zijn eigen school, waarbij hij zijn eigen inbreng toevoegde. Uiteindelijk ontwikkelde hij een unieke bekwaamheid. Hier is het hetzelfde.
Je kunt natuurlijk handelen als bedrijfsconsultants. Over het algemeen zijn ze geweldige jongens. Maar doorgaans komen ze om een bepaalde methode toe te passen, en passen ze niet de methode toe die het bedrijfsleven nodig heeft. Wij hebben ook zulke droevige situaties meegemaakt: niemand weet hoe het probleem op te lossen en niemand wil nadenken over hoe het op te lossen. We beginnen ofwel op internet te zoeken, of we roepen een consultant en vragen hem wat ons kan helpen. De consultant denkt na en zegt dat we de Theory of Constraints moeten implementeren. We betalen hem voor de aanbeveling, investeren in de implementatie, maar het resultaat is nul.
Waarom gebeurt dit? Omdat de consultant zei dat we zo'n systeem moeten implementeren, en iedereen het met hem eens was. Geweldig, maar één enkele methode dekt niet alle problemen van zelfs maar één bedrijfsproces, vooral als de aannames -de onze en die nodig zijn voor de implementatie van de methode- niet overeenkomen.
In de praktijk die de jongen aanbeveelt, moet je het beste nemen en het beste implementeren. Niet de methoden als geheel overnemen, maar hun sleutelkenmerken, trucs, en praktijken. En het belangrijkste is dat je de essentie moet begrijpen.
Laten we, zei hij, bijvoorbeeld scrum of agile nemen. In zijn monologen herhaalde de jongen vaak dat niet iedereen de essentie van scrum volledig begrijpt. Hij had ook het boek van Jeff Sutherland gelezen, dat sommigen als 'luchtig lezen' beschouwen. Voor hem was het een diepgaand boek omdat een van de fundamenten van scrum kwaliteitsbeheer is, en dat wordt letterlijk in het boek geschreven.
Er staat geschreven over Toyota Production, hoe Jeff Sutherland scrum in Japan demonstreerde, hoe goed het daar werd ontvangen en hoe dicht het bij hun filosofie stond. Sutherland sprak ook over het belang van de rol van de scrum-master en de Deming-cyclus. De rol van de scrum-master is het proces voortdurend te versnellen. Alles wat in scrum is, zoals gefaseerde oplevering, klanttevredenheid, en een duidelijke lijst van werkzaamheden voor de sprintperiode, is ook belangrijk, maar dit alles moet steeds sneller gaan. De werktempo moet continu toenemen in de eenheden waarin het wordt gemeten.
Misschien ligt het hier aan de vertaling, want in onze versie is het boek vertaald als 'Scrum - een revolutionaire methode voor projectbeheer', terwijl de letterlijke Engelse titel zou zijn: 'Scrum - twee keer zoveel in de helft van de tijd', wat betekent dat zelfs in de titel de nadruk op snelheid als een kernfunctie van scrum wordt gelegd.
Toen deze jongen scrum implementeerde, steeg de snelheid in de eerste maand verdubbeld zonder enige bijzondere wijzigingen. Hij vond de punten voor verandering, pas de scrum aan voor zichzelf zodat het veel sneller werkte. Het enige, zoals op het internet wordt vermeld, is dat de vraag zich voordeed: 'We hebben de snelheid verdubbeld, wat doen we nu met zo'n snelheid?'. Dit is echter een heel ander gebied...
Hij raadde ook persoonlijk verschillende methodieken aan. Hij noemde ze fundamenteel en essentieel.
De eerste is boundary management.
Het wordt onderwezen aan het "Skolkovo", volgens de jongen zijn er geen andere boeken of materialen. Hij had het geluk om bij een lezing van een professor uit Harvard te zijn, die het heeft over boundary management, en ook om enkele artikelen in de Harvard Business Review over de werken van Eric Trist te lezen.
Boundary management gaat erover dat je grenzen moet kunnen zien en ermee moet werken. Er zijn overal grenzen – tussen afdelingen, tussen verschillende soorten werk, tussen functies, tussen operationeel en analytisch werk. Kennis van boundary management onthult geen hogere Waarheden, maar stelt je in staat om de werkelijkheid vanuit een ander perspectief te zien – door de lens van grenzen. En, dienovereenkomstig, om ze te beheren – ze te creëren waar nodig en te verwijderen waar ze in de weg staan.
Maar het meeste en vaak sprak de jongen over controlling. Hij had er echt een obsessie voor.
Controlling, in het kort, is management op basis van cijfers. Hier is elke component van de definitie belangrijk – zowel "management", als "op basis van", als "cijfers".
Bij ons, zei hij, staat het slecht met alle drie de componenten van controlling. Vooral als je bedenkt dat ze nauw met elkaar verbonden zijn, evenals met andere onderdelen van het bedrijfsysteem.
Het eerste dat slecht is, zijn de cijfers. Ze zijn schaars en van lage kwaliteit.
Een aanzienlijk deel van de cijfers haalden we toen uit het informatie systeem 1C. Maar, zoals hij beweerde, is de kwaliteit van de cijfers in 1C niet om over naar huis te schrijven. Tenminste, vanwege de mogelijkheid om gegevens met terugwerkende kracht te wijzigen.
Het is duidelijk dat de ontwikkelaars van 1C hier niet schuldig aan zijn – zij houden alleen rekening met de eisen van de markt en de mentaliteit van de nationale boekhouding. Maar voor controlling zou de manier waarop 1C met gegevens omgaat, op specifieke ondernemingen beter veranderd moeten worden.
Vervolgens, volgens hem, ondergaan de cijfers uit 1C een half-handmatige verwerking, bijvoorbeeld met gebruik van Excel. Deze verwerking voegt geen kwaliteit of snelheid toe aan de gegevens.
Uiteindelijk wordt het eindrapport weer door iemand gecontroleerd om te voorkomen dat er per ongeluk verkeerde cijfers aan het management worden gepresenteerd. Het gevolg is dat de cijfers mooi, gecontroleerd, maar veel te laat bij de ontvanger aankomen. Gewoonlijk – na afloop van de periode (maand, week, enz.).
En hier, zei hij, is het heel eenvoudig. Als de cijfers van januari in februari bij je terechtkomen, kun je de activiteiten van januari niet meer beheren. Omdat januari al voorbij is.
Als de cijfers zijn gebaseerd op boekhouding en het bedrijf heel gewoon is, met kwartaalafgifte van btw, dan ontvangt de directeur eens in het kwartaal redelijk accurate cijfers.
Vervolgens is het duidelijk. Als je elke maand cijfers ontvangt, heb je de kans om op basis van cijfers te beheren (d.w.z. management control uit te voeren) 12 keer per jaar. Als je kwartaalrapportage hanteert, beheer je 4 keer per jaar. Een bonus is de jaarverslaggeving. Nog een keer kunnen sturen.
De rest van de tijd wordt het beheer meestal in het duister uitgevoerd.
Wanneer (en als) de cijfers eindelijk verschijnen, ontstaat het tweede probleem — hoe te beheren op basis van cijfers? Met dit punt in zijn redenering kon ik het niet eens worden.
De jongen beweerde dat als de directeur eerder geen cijfers had, hun verschijnen een wow-effect zou geven. Hij zou de cijfers bekijken en draaien, mensen oproepen voor uitleg en onderzoeken. Nadat hij met de cijfers heeft gespeeld, analyses heeft uitgevoerd en dreigend aan alle medewerkers heeft beloofd: 'Nu laat ik jullie echt niet meer los', zal de directeur snel kalmeren en ermee stoppen. Hij zal het instrument niet meer gebruiken. En de problemen blijven bestaan.
Dit gebeurt, zei hij, door een gebrek aan competenties van de directeur. In management control, in de eerste plaats. De directeur weet gewoon niet wat hij met deze cijfers moet doen. Wat mette doen — weet hij, maar wat te doen — niet. Te doen — is wat hierboven is geschreven (ruziemaken, spelen). Doen — dat is het dagelijkse bedrijfsproces.
Hij beweerde dat het heel eenvoudig is: het cijfer moet een onderdeel worden van het bedrijfsproces. In het bedrijfsproces moet het duidelijk zijn: wie, wat en wanneer moet handelen bij afwijkingen van de norm (enkele opties — boven de grens, onder de grens, buiten de corridor, aanwezigheid van een trend, niet-naleving van een kwantiel, enz.)
En hier gaf hij de sleutel dilemma aan: het cijfer is er, het moet een deel van het bedrijfsysteem worden om de efficiëntie van het bestuur te verhogen, maar… dat gebeurt niet. Waarom?
Omdat een Russische directeur niet zomaar een deel van zijn macht aan de concurrent zal afstaan.
De concurrenten van de Russische directeur — een kwalitatief en goed functionerend bedrijfsproces, doordachte wederzijds voordelige motivatie en de juiste automatisering — laten de directeur helaas zonder werk.
Wat een onzin, vindt u niet? Vooral als het gaat om leiders. Goed, ik heb het verteld, jullie moeten zelf beslissen.
Een beetje minder, maar nog steeds te veel, vond ik, vertelde hij over Scrum.
Zeker, zei hij, lees en probeer Scrum in de praktijk. Als je alleen hebt gelezen, maar het nog niet hebt geprobeerd — beschouw je het als niet weten. Lees liever een boek, zoals dat van Sutherland, dan artikelen en allerlei gidsen (wat een onzin?) op internet.
Scrum, zei hij, leer je alleen door te doen, en met verplichte metingen van het volume geleverde werk. Probeer persoonlijk de twee belangrijkste rollen — de Product Owner en de Scrum Master.
Bijzonder belangrijk, volgens de jongen, is het om de rol van de Scrum Master in de praktijk te ervaren, waarbij je het aantal taken dat in een sprint wordt gesloten kunt verhogen zonder de middelen en kosten van de sprint te verhogen.
Ook had hij TOC (Theory of Constraints) in zijn toplijst staan.
Dit zijn, volgens de jongen, de basisprincipes voor het verhogen van efficiëntie die in vrijwel elk gebied, in elk bedrijfsproces en in het bedrijfsysteem als geheel kunnen worden toegepast.
Toen hij ontdekte dat we niet bekend waren met TOC, stopte hij met vertellen. Hij voegde alleen toe dat hij ons niet wilde beroven van het plezier om de boeken van Eliyahu Goldratt te lezen. Hij gaf een soortgelijke aanbeveling als voor Scrum — lees en probeer het. Ongeacht welke functie je bekleedt of welke werk je doet, er is altijd ruimte om de efficiëntie te verhogen met TOC-methoden.
Toen was zijn verzameling methoden blijkbaar uitgeput en zei hij: mix principes om praktische oplossingen te creëren in een specifieke situatie.
Dit, zegt hij, is de belangrijkste aanbeveling, de sleutel tot succes. Begrijp de principes, de essentie, en creëer unieke praktische oplossingen — bedrijfsprocessen en bedrijfsystemen.
Vervolgens probeerde hij zich een bepaalde quote te herinneren, maar uiteindelijk moest hij het internet op. Het bleek een citaat te zijn uit het artikel 'Standing on the Shoulders of Giants' van Eliyahu Goldratt:
«Er is een verschil tussen toepassingsoplossingen en fundamentele concepten waarop deze oplossingen zijn gebaseerd. Concepten zijn algemeen, toepassingsoplossingen zijn de aanpassing van concepten aan een specifieke omgeving. Zoals we al hebben gezien, is die aanpassing niet eenvoudig en vereist het de ontwikkeling van bepaalde elementen van de oplossing. We moeten ons herinneren - een toepassingsoplossing is gebaseerd op uitgangspunt(en) (soms verborgen) over de specifieke omgeving. Verwacht niet dat deze toepassingsoplossing zal werken in een omgeving waarvoor de uitgangspunt(en) niet correct zijn.»
Hij zei dat het werk van een programmeur en een ‘business process improver’ heel vergelijkbaar is. En hij ging weg.
Bron: habr.com
