Het verhaal is waar, ik heb het met eigen ogen gezien.
Jarenlang werkte Ć©Ć©n persoon, net als velen van jullie, als programmeur. Voor de zekerheid schrijf ik het zo: "een programmeur". Omdat hij een 1C-ontwikkelaar was bij Fix, een productiebedrijf.
Daarvoor heeft hij verschillende specialismen geprobeerd - 4 jaar in Frankrijk als programmeur, projectmanager, hij kon 200 uur werken en tegelijkertijd een percentage van het project ontvangen voor het management en een beetje verkoop. Ik heb geprobeerd om zelf producten te ontwikkelen, ik was hoofd van de IT-afdeling in een groot bedrijf met 6 mensen, ik heb verschillende opties uitgeprobeerd om mijn zogenaamde beroep ā 1C-programmeur ā in te zetten.
Maar al deze functies waren qua inkomsten uitzichtloos. We kregen toen allemaal ongeveer hetzelfde salaris en werkten onder dezelfde omstandigheden.
Deze man raakte geĆÆnteresseerd in hoe hij meer geld kon verdienen zonder te verkopen of een eigen bedrijf te beginnen.
Hij dacht dat hij een slimme jongen was en besloot een plekje te vinden in het bedrijf waar hij werkte. Deze nis moest iets bijzonders zijn, waar niemand aanwezig was. En ik wilde dat het bedrijf zelf bereid was om geld te betalen aan iemand in deze niche, zodat er geen reden was om iemand te misleiden of iets op te blazen. Om het objectief te maken: iemand in deze positie moet veel geld verdienen. Kortom, een vreemde eend in de bijt.
De zoektocht duurde niet lang. Het bedrijf waar deze man werkte had een volledig vrije niche die je conventioneel zou kunnen noemen: āorde brengen in bedrijfsprocessenā. Elk bedrijf heeft problemen. Er is altijd wel iets dat niet werkt en er is niemand die het bedrijfsproces komt repareren. Daarom besloot hij de rol van specialist op zich te nemen, die de eigenaar kon helpen bij het oplossen van problemen in bedrijfsprocessen.
Hij werkte toen zes maanden bij het bedrijf en ontving het gemiddelde marktconforme salaris. Hij had niets te verliezen, vooral omdat hij binnen een week dezelfde baan gemakkelijk kon vinden. Eigenlijk had deze man besloten dat er niets ergs zou gebeuren als er opeens niets meer zou lukken en hij ontslagen zou worden.
Hij verzamelde al zijn moed en ging naar de eigenaar. Ik stelde voor dat hij het meest problematische proces in het bedrijf zou verbeteren. Destijds ging het om magazijnboekhouding. Iedereen die bij dit bedrijf werkt schaamt zich om aan die problemen te denken, maar de inventarisaties die per kwartaal werden uitgevoerd, lieten verschillen van tientallen procenten zien tussen het boekhoudsysteem en de werkelijke saldi. Zowel wat betreft kosten, kwantiteit als aantal artikelen. Het was een ramp. Eigenlijk had het bedrijf slechts vier keer per jaar een correcte balans in de boekhouding: de dag na de inventarisatie. Onze man is begonnen met het op orde brengen van dit proces.
De man was het met de eigenaar eens dat hij de afwijkingen in de inventarisresultaten met de helft moest verminderen. Bovendien had de eigenaar niets te verliezen, want vĆ³Ć³r onze held hadden verschillende arbeiders al geprobeerd alles te repareren, en over het geheel genomen werd de taak als praktisch onoplosbaar beschouwd. Dit alles wakkerde de interesse enorm aan, want als alles goed zou gaan, zou de man automatisch een persoon worden die de orde kan herstellen en onoplosbare problemen kan oplossen.
Hij stond dus voor de taak om de afwijkingen in de inventarisresultaten binnen een jaar met een factor 2 te reduceren. Aan het begin van het project had hij geen idee hoe hij dit moest realiseren, maar hij begreep dat voorraadbeheer een eenvoudige zaak is, dus hij zou er toch iets nuttigs mee kunnen doen. Bovendien lijkt het niet zo moeilijk om afwijkingen van tientallen procenten terug te brengen tot Ć©Ć©n tiende procent. Iedereen die in de consultancy of een vergelijkbare sector heeft gewerkt, weet dat de meeste procesproblemen met vrij eenvoudige stappen kunnen worden opgelost.
Van januari tot mei was hij bezig met het voorbereiden, een beetje automatiseren, herschrijven van het boekhoudproces van het magazijn, het aanpassen van de workflows van magazijnmeesters en accountants en het herontwerpen van het hele systeem, zonder dat hij iemand iets liet zien of vertelde. In mei gaf hij iedereen nieuwe instructies en na de eerste inventarisatie van het jaar begon een nieuw leven: werken volgens zijn regels. Om de resultaten te kunnen observeren, begon het bedrijf vervolgens vaker inventarisaties uit te voeren: eens in de twee maanden. De eerste resultaten waren al positief en tegen het einde van het jaar waren de afwijkingen in de auditresultaten gedaald tot fracties van een procent.
Het succes was enorm, maar er was geen vertrouwen in de duurzaamheid ervan. De man zelf betwijfelde of het resultaat behouden zou blijven als hij een stap opzij zou doen en het proces niet meer zou observeren. Maar het resultaat was er wel en de man kreeg alles wat hij met de eigenaar had afgesproken. Vervolgens werd na enkele jaren de stabiliteit van het resultaat bevestigd: gedurende enkele jaren bleven de afwijkingen binnen 1%.
Vervolgens besloot hij het experiment te herhalen en stelde hij voor dat de eigenaar een ander problematisch proces zou verbeteren: de aanvoer. Er was sprake van tekorten waardoor wij niet de volumes konden leveren die onze klanten wilden. We spraken af āādat de tekorten binnen een jaar gehalveerd zouden zijn en dat die man nog eens 10-15 projecten zou afronden die verband hielden met 1C: het automatiseren van diverse bedrijfsprocessen en andere onzin.
In het tweede jaar werd alles opnieuw succesvol afgerond, de tekorten werden ruim verdubbeld en alle IT-projecten werden succesvol afgerond.
Omdat het salaris al ruimschoots voldeed aan de behoeften van die man voor de komende twee jaar, besloot hij het wat rustiger aan te doen, tot rust te komen en te gaan zitten op een gezellige, warme plek die hij zelf had gecreƫerd.
Wat stelde het voor? Formeel was hij IT-directeur. Maar het is moeilijk te begrijpen wie hij werkelijk was. Wat doet een IT-directeur eigenlijk? In de regel beheert hij de IT-infrastructuur, stuurt hij systeembeheerders aan, implementeert hij het ERP-systeem en neemt hij deel aan bestuursvergaderingen.
En deze man had een van zijn belangrijkste verantwoordelijkheden: deelnemen aan veranderingsprocessen, en dan met name het genereren en initiƫren van deze processen, het zoeken naar en voorstellen van oplossingen, het toepassen van nieuwe managementmethoden, het onderzoeken van voorgestelde veranderingen, het analyseren van de effectiviteit van andere functies en afdelingen en, tot slot, rechtstreeks deelnemen aan de strategische ontwikkeling van de onderneming, tot aan de onafhankelijke ontwikkeling van een strategisch plan voor het hele bedrijf.
Hij kreeg carte blanche. Hij kon naar elke vergadering komen waar hij voorheen geen toegang toe had. Ik zat daar met een notitieboekje, schreef iets op of luisterde gewoon. Hij sprak zelden. Vervolgens begon hij op zijn telefoon te spelen en beweerde dat het associatieve geheugen op die manier beter werkte.
Hij produceerde zelden iets nuttigs tijdens vergaderingen. Hij vertrok, dacht na en toen kwam er een brief ā met kritiek, met een mening, met suggesties of met een beschrijving van de oplossingen die hij al had toegepast.
Maar meestal organiseerde hij de vergaderingen zelf. Ik vond een probleem, bedacht oplossingen, identificeerde belanghebbenden en sleepte iedereen naar de vergaderzaal. En toen - zo goed als ik kon. Overtuigd, gemotiveerd, bewezen, beargumenteerd, bereikt.
Officieus werd hij beschouwd als de derde persoon in het bedrijf, na de eigenaar en de directeur. Natuurlijk maakte hij alle āgezichten van het bedrijfā echt boos, te beginnen met nummer 4. Vooral met zijn gescheurde jeans en felle T-shirts, en ook met de tijd van zijn baasje.
De eigenaar besteedde 1 uur per dag aan hem. Elke dag. Ze praatten, bespraken problemen, oplossingen, nieuwe bedrijven, ontwikkelingsrichtingen, indicatoren en efficiƫntie, persoonlijke ontwikkeling, boeken en gewoon het leven.
Maar deze man was vreemd. Het lijkt erop dat je achterover kunt leunen en blij kunt zijn, het leven is een succes. Maar nee. Hij besloot na te denken.
Hij werd nieuwsgierig: waarom werkte het bij hem wel en bij anderen niet? Ook de eigenaar spoorde hem aan: hij wilde dat anderen ook de orde konden herstellen, zei hij. Want er zijn veel managers, die zich doorgaans bezighouden met operationeel management en strategische planning, maar vrijwel niemand houdt zich bezig met systematische veranderingen in hun processen. In hun functiebeschrijving staat weliswaar dat ze hun proces moeten versnellen en de efficiĆ«ntie ervan moeten vergroten, maar in werkelijkheid doet niemand dat. Hoe komt dat? De man raakte ook geĆÆnteresseerd in het waarom en ging met al die managers praten.
Hij ging naar de adjunct-directeur kwaliteit en stelde voor om de controlekaarten van Shewhart te implementeren, zodat de producten beter zouden zijn dan de Japanse. Maar het bleek dat de collega niet wist wat Shewhart-controlekaarten waren, wat statistische procescontrole was en dat hij slechts vaag had gehoord van het gebruik van de Deming-cyclus in kwaliteitsmanagement. OKĆā¦
Hij ging naar een andere adjunct-directeur en stelde voor om controlerend te werk te gaan. Maar ook hier vond hij geen steun. Kort daarna leerde hij over grensbeheer en stelde voor dat alle adjunct-directeuren het systemische deel van deze methode zouden implementeren om processen te verbeteren. Maar hoeveel onze man ook praatte, niemand wilde echt begrijpen waar hij het over had. Misschien waren ze niet geĆÆnteresseerd of was het te moeilijk. Maar eigenlijk had niemand het door.
In het algemeen vertelde hij over alles wat hij wist en toepaste binnen het bedrijf. Maar niemand begreep hem. Ze begrijpen nog steeds niet waarom bijvoorbeeld alles in de magazijnboekhouding is gecorrigeerd en wat controlling en grensbeheer ermee te maken hebben.
Als laatste nam hij contact op met zijn programmeurs. Er werkten drie mensen in het team. Hij vertelde me over boundary management, over controlling, over kwaliteitsmanagement, over agile en scrum... En verrassend genoeg begrepen ze alles en konden ze er zelfs op de een of andere manier met hem over praten, inclusief technische en methodologische details. Ze begrepen waarom de magazijn- en bevoorradingsprojecten werkten. En toen drong het tot hem door: programmeurs zullen de wereld redden.
Hij besefte dat programmeurs de enigen zijn die bedrijfsprocessen tot in detail kunnen begrijpen.
Waarom zij? Eigenlijk heeft hij nooit een duidelijk antwoord gevonden. Ik heb alleen thematische tips geformuleerd.
Ten eerste kennen programmeurs de vakgebieden waar het bedrijf over gaat, en ze kennen ze beter dan wie dan ook in het bedrijf.
Bovendien begrijpen programmeurs daadwerkelijk wat een procesalgoritme is. Dit is belangrijk omdat bedrijfsprocessen algoritmen zijn en de elementen daarin eenvoudigweg niet op elkaar kunnen worden afgestemd. Bijvoorbeeld, in het inkoopproces waar de man aan werkte, was de eerste stap het opstellen van een jaarlijks inkoopplan en de tweede stap het dagelijks inkopen. Deze stappen zijn met elkaar verbonden door een directe link, dat wil zeggen dat ervan wordt uitgegaan dat mensen volgens dit algoritme werken - jaarlijks een inkoopplan opstellen en de aanvraag onmiddellijk uitvoeren. Het jaarlijkse aanbestedingsplan wordt eenmaal per jaar opgesteld en er komen 50 keer per dag aanvragen binnen. Hier eindigt het algoritme en moeten we ermee aan de slag. Hij redeneerde dat het voor programmeurs een concurrentievoordeel is om algoritmes te kennen, omdat iemand anders die er niet mee bekend is, eenvoudigweg niet begrijpt hoe een bedrijfsproces zou moeten werken en hoe het kan worden weergegeven.
Een ander voordeel van programmeurs is volgens die man dat ze voldoende vrije tijd hebben. We weten allemaal dat een programmeur drie keer zoveel tijd aan een taak kan besteden als nodig is, en dat maar weinig mensen het doorhebben. Dit is opnieuw een concurrentievoordeel, want om een āābedrijfsproces op orde te krijgen, moet je veel vrije tijd hebben om na te denken, te observeren, te studeren en te proberen.
Volgens de man hebben de meeste managers deze vrije tijd niet en zijn ze er trots op. In feite betekent dit echter dat iemand niet effectief kan worden, omdat hij geen tijd heeft om zijn effectiviteit te verbeteren. Een vicieuze cirkel. In onze cultuur is het mode om druk te zijn, dus blijft alles bij het oude. En voor ons, programmeurs, is dat een voordeel. We kunnen vrije tijd vinden en over alles nadenken.
Programmeurs, zei hij, kunnen een informatiesysteem snel veranderen. Dit was niet in alle ondernemingen toepasbaar, maar waar hij ook werkte, hij kon alle gewenste aanpassingen doorvoeren. Vooral als ze niets met iemands werk te maken hebben. Hij zou bijvoorbeeld een systeem kunnen lanceren dat in het geheim de handelingen van gebruikers meet en die informatie vervolgens kan gebruiken om de efficiƫntie van dezelfde boekhoudafdeling te analyseren en de kosten van de boekhouding bij te houden.
En het laatste wat ik me van zijn woorden herinner, is dat programmeurs toegang hebben tot heel veel informatie, omdat ze beheerdersrechten hebben op het systeem. Daarom kunnen ze deze informatie gebruiken in hun analyses. Niemand anders in een gewone fabriek heeft zo'n hulpbron.
En toen ging hij weg. Tijdens de verplichte werkperiode van twee weken dwongen we hem om zijn ervaringen te delen, omdat we het werk dat hij deed, wilden voortzetten. Nou, zijn functie kwam vrij.
Gedurende een aantal dagen lieten ze hem op een stoel zitten, zetten de camera aan en namen zijn monologen op. Ze vroegen om te praten over alle voltooide projecten, methoden, benaderingen, successen en mislukkingen, oorzaken en gevolgen, portretten van managers, etc. Ze beperkten het niet echt, omdat... hij niet wist wat er in zijn hoofd omging.
De monologen bestonden natuurlijk vooral uit onzin en gelach - hij was in een opperbeste stemming, want... vertrok vanuit het achterland naar Sint-Petersburg. Waar kun je in Sint-Petersburg werken? Naar Gazprom, natuurlijk.
Maar we hebben toch iets bruikbaars uit zijn monologen kunnen halen. Ik zal je vertellen wat ik me herinner.
Dus, de aanbevelingen van die gast. Voor iedereen die orde in bedrijfsprocessen wil scheppen.
Om dit soort werk te kunnen doen, moet je allereerst een bepaald niveau van ābevriezingā hebben. Je hoeft niet bang te zijn om je baan te verliezen, om risico's te nemen of om conflicten met collega's te krijgen. Dat was voor hem niet zo moeilijk, want hij begon zijn carriĆØre pas zes maanden bij het bedrijf en had nog geen tijd gehad om met iemand contact te leggen. Hij had ook niet de intentie om dat te doen. Hij begreep dat mensen komen en gaan, maar voor hem waren zijn eigen resultaten en de beoordeling daarvan door de ondernemer het belangrijkste. Het kon hem destijds weinig schelen of zijn collega's hem goed of slecht behandelden.
Het tweede punt is dat je, om dit werk effectief te kunnen doen, helaas wel zult moeten studeren. Maar studeer niet voor een MBA, niet via cursussen, niet aan instituten, maar zelfstandig. Bij zijn eerste project handelde hij bijvoorbeeld intuĆÆtief, hij wist niets, alleen wat ākwaliteitsmanagementā was.
Toen hij literatuur begon te lezen over de methoden om de efficiĆ«ntie te verhogen, ontdekte hij de technologieĆ«n die hij gebruikte. De man gebruikte ze intuĆÆtief, maar het bleek niet zijn uitvinding te zijn, alles was al lang geleden opgeschreven. Maar hij besteedde er tijd aan, en veel meer dan wanneer hij meteen het juiste boek had gelezen. Hierbij is het belangrijk om te begrijpen dat wanneer u een specifieke methodologie bestudeert, geen enkele methode, zelfs de meest geavanceerde, alle problemen van het bedrijfsproces volledig zal oplossen.
De tweede truc is: hoe meer technieken je kent, hoe beter. In het oude Japan leefde bijvoorbeeld Miyamoto Musashi, een van de beroemdste zwaardvechters en de bedenker van de twee-zwaardstijl. Hij studeerde op een school met een meester, reisde daarna door Japan en vocht met verschillende kerels. Als de man sterker was, zou de reis tijdelijk stoppen en zou Musashi student worden. Hierdoor verwierf hij in de loop van de jaren de vaardigheden van verschillende meesters en richtte hij zijn eigen school op, waaraan hij telkens iets van zichzelf toevoegde. Hierdoor ontwikkelde hij een unieke vaardigheid. Hier is het hetzelfde.
Natuurlijk kunt u ook optreden als bedrijfsadviseur. Over het algemeen zijn het geweldige kerels. Maar in de regel implementeren ze een bepaalde methodologie, maar ze implementeren de verkeerde methodologie die het bedrijf nodig heeft. Wij hebben ook zulke trieste situaties meegemaakt: niemand weet hoe het probleem opgelost moet worden en niemand wil erover nadenken. We beginnen met zoeken op internet of bellen een adviseur en vragen hem wat ons kan helpen. De adviseur denkt en zegt dat de theorie van beperkingen moet worden geĆÆmplementeerd. We betalen hem voor de aanbeveling, besteden geld aan de uitvoering, maar er is geen resultaat.
Hoe gebeurt dit? Omdat de adviseur zei: we zijn een bepaald systeem aan het implementeren, en iedereen was het met hem eens. Prima, maar ƩƩn methodologie dekt niet alle problemen van zelfs maar ƩƩn bedrijfsproces, vooral niet als de initiƫle aannames niet overeenkomen - de onze en de aannames die vereist zijn voor de implementatie van de methodologie.
In de praktijk die de man aanbeveelt, moet je het beste nemen en het beste implementeren. Neem niet de methoden in hun geheel over, maar benoem hun belangrijkste kenmerken, trucs en werkwijzen. En het allerbelangrijkste is om de essentie te begrijpen.
Neem bijvoorbeeld scrum of agile, zei hij. In zijn monologen herhaalde de man herhaaldelijk dat niet iedereen de essentie van Scrum volledig begrijpt. Hij las ook het boek van Jeff Sutherland, dat door sommige mensen als 'makkelijk leesbaar' wordt ervaren. Hij vond het een diepgaand boek, omdat een van de fundamentele principes van Scrum kwaliteitsmanagement is. Dit wordt ook expliciet in het boek beschreven.
Het gaat over Toyota Production, over hoe Jeff Sutherland Scrum in Japan liet zien, hoezeer het daar wortel schoot en dicht bij hun filosofie stond. En Sutherland sprak over het belang van de rol van de Scrum Master en over de Deming-cyclus. De rol van een Scrum Master is om het proces voortdurend te versnellen. Alles wat bij Scrum hoort - gefaseerde oplevering, klanttevredenheid, een duidelijke lijst met werkzaamheden voor de sprintperiode - is ook belangrijk, maar het moet allemaal steeds sneller. De werksnelheid moet voortdurend toenemen in de eenheden waarin deze wordt gemeten.
Misschien is het een kwestie van vertalen, want in ons land werd het boek vertaald als "Scrum - een revolutionaire methode van projectmanagement", maar als je de Engelse titel letterlijk vertaalt, krijg je: "Scrum - twee keer zoveel in de helft van de tijd", dat wil zeggen, zelfs de titel verwijst naar snelheid als een sleutelfunctie van Scrum.
Toen deze man Scrum implementeerde, verdubbelde de snelheid in de eerste maand, zonder grote veranderingen. Hij vond verbeterpunten en paste Scrum zelf aan, zodat het veel sneller zou werken. Het enige, zo schrijven ze op internet, is dat ze geconfronteerd werden met de vraag: āWe hebben de snelheid verdubbeld, nu moeten we bedenken wat we met die snelheid doen?ā Maar dit is een heel ander gebied...
Hij raadde ook persoonlijk een aantal technieken aan. Hij noemde ze fundamenteel en fundamenteel.
Het eerste is grensbeheer.
Het wordt onderwezen in Skolkovo; Volgens de man zijn er geen andere boeken of materialen. Hij had ooit het geluk een lezing bij te wonen van een professor aan Harvard die predikte over grensbeheer. Ook las hij verschillende artikelen in de Harvard Business Review over het werk van Eric Trist.
Bij grensbeheer is het belangrijk dat je grenzen kunt zien en ermee kunt werken. Er zijn veel grenzen, ze zijn overal: tussen afdelingen, tussen verschillende soorten werk, tussen functies, tussen operationeel en analytisch werk. Kennis van het beheer van grenzen onthult geen hogere waarheden, maar het stelt ons wel in staat om de werkelijkheid in een iets ander licht te zien - door het prisma van grenzen. En beheer ze dienovereenkomstig: bouw ze waar nodig en verwijder ze waar ze hinderen.
Maar de man had het steeds vaker over controle. Hij was gewoon geobsedeerd door dit onderwerp.
Controleren is, kort gezegd, management op basis van cijfers. Hierbij, zei hij, is elk onderdeel van de definitie belangrijk: āmanagementā, āgebaseerd opā en ācijfersā.
Wij, zei hij, presteren slecht op alle drie de aspecten van controle. Zeker omdat ze nauw met elkaar en met andere onderdelen van het bedrijfssysteem verweven zijn.
Het eerste wat opvalt zijn de cijfers. Er zijn er maar weinig en ze zijn van slechte kwaliteit.
Vervolgens hebben we een aanzienlijk deel van de cijfers uit het 1C-informatiesysteem gehaald. De kwaliteit van de getallen in 1C is dus, zoals hij beweerde, niet goed. Op zijn minst omdat we gegevens met terugwerkende kracht kunnen wijzigen.
Het is duidelijk dat de ontwikkelaars van 1C hier niet de schuld van hebben. Zij houden simpelweg rekening met de eisen van de markt en de mentaliteit van de binnenlandse boekhouding. Maar voor controledoeleinden is het beter om de principes van 1C-werken met gegevens binnen een specifieke onderneming te wijzigen.
Vervolgens worden de getallen uit 1C volgens hem semi-handmatig verwerkt, bijvoorbeeld met behulp van Excel. Deze vorm van verwerking zorgt niet voor een hogere kwaliteit en ook niet voor een hogere snelheid van de gegevens.
Er is immers nog iemand die het eindrapport controleert, om te voorkomen dat er per ongeluk cijfers met fouten aan de manager worden voorgelegd. Hierdoor komen de cijfers weliswaar mooi, gecontroleerd, maar wel erg laat bij de ontvanger aan. Meestal - na het einde van de periode (maand, week, enz.).
En hier, zei hij, is alles heel eenvoudig. Als u de cijfers van januari in februari hebt ontvangen, kunt u de activiteiten van januari niet meer beheren. Omdat januari alweer voorbij is.
En als de cijfers gebaseerd zijn op boekhoudkundige gegevens en het gaat om een āāheel gewoon bedrijf, met kwartaallijkse BTW-aangifte, dan ontvangt de manager eenmaal per kwartaal relatief toereikende cijfers.
De rest is duidelijk. U ontvangt maandelijks cijfers. U heeft 12 keer per jaar de mogelijkheid om op cijfers te sturen (controleren). Voer kwartaalrapportages uit - beheer deze 4 keer per jaar. En als bonus: jaarlijkse rapportage. Neem nog een keer het stuur in handen.
De rest van de tijd wordt de controle meestal blindelings uitgevoerd.
Als (en wanneer) er daadwerkelijk cijfers verschijnen, komt het tweede probleem om de hoek kijken: hoe kunnen we op basis van cijfers sturen? Ik kon het niet met dit punt van zijn redenering eens zijn.
De man beweerde dat als de manager voorheen geen cijfers had, hun verschijning een wow-effect zou veroorzaken. Hij zal de cijfers op allerlei manieren verdraaien, mensen op het matje roepen, uitleg en onderzoek eisen. Nadat hij met de cijfers heeft gespeeld, analyses heeft uitgevoerd en alle werknemers dreigend heeft beloofd dat āik jullie nu niet meer met rust zal latenā, zal de manager heel snel kalmeren en de zaak laten rusten. Ik zal het gereedschap niet meer gebruiken. Maar de problemen blijven bestaan.
Volgens hem gebeurt dit door het gebrek aan competentie van de manager. In de eerste plaats door te controleren. De manager weet gewoon niet wat hij met deze cijfers moet doen. Wat Ńte doen - weet, wat te doen - nee. Doen is wat hierboven geschreven staat (ruzie maken, spelen). Doen is een dagelijks bedrijfsproces.
Volgens hem was het allemaal heel eenvoudig: digitaal moest onderdeel worden van het bedrijfsproces. In het bedrijfsproces moet duidelijk worden vastgelegd wie, wat en wanneer er moet worden gehandeld als een getal afwijkt van de norm (alle opties - boven de grens, onder de grens, buiten de bandbreedte, aanwezigheid van een trend, niet halen van het kwantiel, etc.)
En zo schetste hij het kerndilemma: het getal bestaat, het zou onderdeel moeten worden van het bedrijfssysteem om de managementefficiƫntie te verhogen, maar... dat gebeurt niet. Waarom?
Omdat de Russische leider geen deel van zijn macht aan een concurrent zal afstaan.
Concurrenten van de Russische manager - een kwalitatief hoogstaand en werkend bedrijfsproces, doordachte wederzijds voordelige motivatie en correcte automatisering - zullen de manager helaas zonder werk laten.
Wat een onzin, vindt u ook niet? Vooral wat betreft de leiders. OkƩ, ik zei het toch, jij beslist zelf.
Iets minder, maar nog steeds te veel, naar mijn mening, hij had het over scrum.
Zeker, zei ik, lees en probeer Scrum in de praktijk. Als je het hebt gelezen maar nog niet hebt geprobeerd, zegt hij, bedenk dan dat je het niet weet. Het is beter om een āāboek te lezen, bijvoorbeeld van Sutherland, dan artikelen en allerlei gidsen (wat is dat nou weer?) op internet.
Scrum, zei hij, kan alleen worden geleerd door oefening en door verplichte metingen van de hoeveelheid voltooid werk. Ervaar zelf twee van de belangrijkste rollen: Product Owner en Scrum Master.
Volgens de man is het vooral belangrijk om de rol van een scrum master in de praktijk te ervaren, wanneer je het aantal taken dat je tijdens een sprint afrondt kunt vergroten zonder dat de middelen en kosten van de sprint toenemen.
Nou, ook TOS (Theory of Systems Constraints) stond op zijn hoogtepunt.
Volgens de man zijn dit fundamentele basisprincipes voor het verhogen van de efficiƫntie die op vrijwel elk gebied, in elk bedrijfsproces en bedrijfssysteem als geheel kunnen worden toegepast.
Toen hij erachter kwam dat wij TOS niet kenden, stopte hij ermee het ons te vertellen. Hij voegde er alleen aan toe dat hij ons niet het plezier zou ontnemen om de boeken van Eliyahu Goldratt te lezen. De aanbeveling was vergelijkbaar met Scrum: lees het en probeer het. Ongeacht welke functie u bekleedt, ongeacht het werk dat u doet, er is altijd ruimte voor verbetering van de efficiƫntie door TOC-methoden te gebruiken.
Toen raakte zijn bagage aan methoden kennelijk op en zei hij: meng principes om in een specifieke situatie toegepaste oplossingen te creƫren.
Dit is volgens hem de belangrijkste aanbeveling, de sleutel tot succes. Begrijp de principes, de essentie en creƫer unieke toegepaste oplossingen - bedrijfsprocessen en bedrijfssystemen.
Vervolgens probeerde hij zich een citaat te herinneren, maar uiteindelijk moest hij online gaan. Het bleek een citaat te zijn uit het artikel "Standing on the Shoulders of Giants" van Eliyahu Goldratt:
āEr is een verschil tussen toegepaste oplossingen (applicaties) en de fundamentele concepten waarop deze oplossingen zijn gebaseerd. De concepten zijn algemeen, de toegepaste oplossingen zijn de aanpassing van de concepten aan een specifieke omgeving. Zoals we al hebben gezien, is een dergelijke aanpassing niet eenvoudig en vereist het de ontwikkeling van bepaalde elementen van de oplossing. We moeten onthouden dat een toegepaste oplossing is gebaseerd op initiĆ«le aannames (soms verborgen) over een specifieke omgeving. Je moet niet verwachten dat deze applicatieoplossing werkt in een omgeving waarvoor de initiĆ«le aannames niet waar zijn."
Hij zei dat het werk van een programmeur en een ābedrijfsprocesverbeteraarā erg op elkaar lijken. En hij ging weg.
Bron: www.habr.com
