Ongeveer één man

Het verhaal is echt, ik heb alles met eigen ogen gezien.

Jarenlang heeft één man, zoals velen van jullie, als programmeur gewerkt. Voor het geval dat, zal ik het op deze manier schrijven: "programmeur." Omdat hij 1Snik, op een fix, productiebedrijf was.

Daarvoor probeerde hij verschillende specialiteiten - 4 jaar in Frankrijk als programmeur en projectmanager, hij kon 200 uur voltooien, terwijl hij tegelijkertijd een percentage van het project ontving voor management en een beetje verkoop. Ik probeerde zelf producten te ontwikkelen, was hoofd van de IT-afdeling in een groot bedrijf met zesduizend mensen, probeerde verschillende opties uit om mijn citeerbare beroep te gebruiken: 6C-programmeur.

Maar al deze posities waren enigszins doodlopend, vooral in termen van inkomen. We ontvingen destijds allemaal ongeveer hetzelfde geld en werkten onder dezelfde omstandigheden.

Deze man vroeg zich af hoe hij meer geld kon verdienen zonder zijn eigen bedrijf te verkopen of op te richten.

Hij zag zichzelf als een slimme jongen en besloot een plekje te vinden in het bedrijf waar hij werkte. Deze nis moest iets bijzonders zijn, door niemand bezet. En ik wilde dat het bedrijf zelf geld zou willen betalen aan een persoon in deze niche, zodat het niet nodig zou zijn iemand te misleiden of iets te bedriegen. Om dit doel te bereiken: een persoon in deze positie moet veel geld betaald krijgen. Een excentriekeling, in één woord.

De zoektocht was van korte duur. In het bedrijf waar deze man werkte, was er een volledig vrije niche die je 'ordening in bedrijfsprocessen' zou kunnen noemen. Ieder bedrijf heeft veel problemen. Er werkt altijd iets niet en er is niemand die het bedrijfsproces komt repareren. Daarom besloot hij zichzelf uit te proberen als een specialist die de eigenaar kan helpen zijn problemen in bedrijfsprocessen op te lossen.

Hij werkte toen zes maanden bij het bedrijf en ontving het gemiddelde salaris op de markt. Er viel niets te verliezen, vooral omdat hij binnen een week gemakkelijk dezelfde baan kon vinden. Over het algemeen besloot deze man dat er niets ergs zou gebeuren als er plotseling niets zou lukken en hij zou worden ontslagen.

Hij verzamelde moed en kwam naar de eigenaar. Ik stelde voor dat hij het meest problematische proces in het bedrijf zou verbeteren. Destijds was dat magazijnboekhouding. Nu schaamt iedereen die in dit bedrijf werkt zich zelfs als ze zich die problemen herinneren, maar de inventarisaties, die elk kwartaal werden uitgevoerd, lieten discrepanties zien tussen het boekhoudsysteem en de werkelijke saldi van tientallen procenten. En in kosten, en in hoeveelheid, en in het aantal posities. Het was een ramp. Slechts vier keer per jaar beschikte het bedrijf over de juiste saldi in het boekhoudsysteem: de dag na de voorraadtelling. Onze man begon dit proces op orde te brengen.

De man was het met de eigenaar eens dat hij de afwijkingen van de inventarisresultaten met de helft moest verminderen. Bovendien had de eigenaar niets bijzonders te verliezen, want vóór onze held hadden verschillende arbeiders al pogingen ondernomen om alles te repareren, en over het algemeen werd de taak als praktisch onoplosbaar beschouwd. Dit alles heeft de belangstelling enorm aangewakkerd, want als alles zou lukken, zou de kerel automatisch een persoon worden die weet hoe hij zaken op orde moet brengen en onoplosbare problemen moet oplossen.

Hij stond dus voor de taak: afwijkingen op basis van inventarisresultaten binnen een jaar met een factor 2 verminderen. Bij de start van het project had hij geen idee hoe hij dit moest bereiken, maar hij begreep dat magazijnboekhouding iets eenvoudigs is, zodat hij toch iets nuttigs zou kunnen doen. Bovendien lijkt het terugbrengen van afwijkingen van tientallen procenten naar één tientallen procent niet zo moeilijk. Iedereen die in consultancy of soortgelijke activiteiten heeft gewerkt, begrijpt dat de meeste procesproblemen met vrij eenvoudige stappen kunnen worden opgelost.

Van januari tot mei heeft hij voorbereidingen getroffen, iets geautomatiseerd, het bedrijfsproces van de magazijnboekhouding herschreven, de werkstromen van winkeliers en accountants veranderd en in het algemeen het hele systeem opnieuw gemaakt, zonder iets aan iemand te laten zien of te vertellen. In mei deelde hij nieuwe instructies uit aan iedereen, en na de eerste inventarisatie van het jaar begon een nieuw leven - werkend volgens zijn regels. Om de resultaten te observeren, begon het bedrijf in de toekomst vaker inventarisaties uit te voeren - eens per twee maanden. De eerste resultaten waren al positief en tegen het einde van het jaar waren de afwijkingen van de auditresultaten gedaald tot een fractie van één procent.

Het succes was kolossaal, maar men kon niet geloven in de duurzaamheid ervan. De man zelf betwijfelde of het resultaat behouden zou blijven als hij een stap opzij deed en het proces niet meer observeerde. Niettemin was er resultaat en de man ontving alles wat hij met de eigenaar was overeengekomen. Vervolgens werd na enkele jaren de stabiliteit van het resultaat bevestigd - gedurende meerdere jaren bleven de afwijkingen binnen 1%.

Toen besloot hij het experiment te herhalen en stelde voor dat de eigenaar een ander problematisch proces zou verbeteren: de levering. Er waren tekorten waardoor we niet de volumes konden verschepen die onze klanten wilden. We waren het erover eens dat binnen een jaar de tekorten zouden worden gehalveerd, en dat de man ook 10-15 projecten zou voltooien die verband hielden met 1C - om verschillende bedrijfsprocessen en andere ketterijen te automatiseren.

In het tweede jaar werd alles weer succesvol afgerond, de tekorten daalden ruim 2 keer, alle IT-projecten werden succesvol afgerond.

Omdat het salaris al twee jaar van tevoren volledig aan alle behoeften van die man voldeed, besloot hij zich een beetje te vestigen, te kalmeren en op een gezellige, warme plek te gaan zitten die hij voor zichzelf had gecreëerd.

Hoe was het? Formeel was hij de IT-directeur. Maar wie hij werkelijk was, is moeilijk te begrijpen. Wat doet een IT-directeur tenslotte? In de regel beheert hij de IT-infrastructuur, geeft leiding aan systeembeheerders, implementeert een ERP-systeem en neemt deel aan vergaderingen van de raad van bestuur.

En deze kerel had een van de belangrijkste verantwoordelijkheden om deel te nemen aan veranderingsprocessen, en vooral - het genereren, initiëren van deze processen, het zoeken en voorstellen van oplossingen, het toepassen van nieuwe managementtechnieken, het onderzoeken van voorgestelde veranderingen, het analyseren van de effectiviteit van andere functies en divisies, en ten slotte directe deelname 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 bijeenkomst komen waar hij voorheen geen toegang had. Ik zat daar met een notitieblok iets op te schrijven of gewoon te luisteren. Hij sprak zelden. Toen begon hij aan de telefoon te spelen en beweerde dat associatief geheugen op deze manier beter werkt.

Tijdens de bijeenkomst deelde hij zelden iets nuttigs uit. Hij ging weg, dacht na, en toen kwam er een brief - met kritiek, of met een mening, of met suggesties, of met een beschrijving van de oplossingen die hij al had toegepast.

Maar vaker belegde hij zelf bijeenkomsten. Ik heb een probleem gevonden, oplossingen bedacht, geïnteresseerden geïdentificeerd en iedereen bij de bijeenkomst betrokken. En dan - zo goed als hij kon. Hij overtuigde, motiveerde, bewees, betoogde en bereikte.

Officieus werd hij beschouwd als de derde persoon in het bedrijf, na de eigenaar en directeur. Natuurlijk maakte hij alle 'personen van het bedrijf' verschrikkelijk woedend, te beginnen met nummer 4. Vooral met zijn gescheurde spijkerbroek en felgekleurde T-shirts, en ook met zijn tijd als eigenaar.

De eigenaar gaf hem 1 uur per dag. Elke dag. Ze praatten, bespraken problemen, oplossingen, nieuwe bedrijven, ontwikkelingsgebieden, indicatoren en efficiëntie, persoonlijke ontwikkeling, boeken en gewoon het leven.

Maar deze man was vreemd. Het is zoiets als: leun achterover en wees gelukkig, het leven is goed. Maar nee. Hij besloot na te denken.

Hij vroeg zich af: waarom lukte het hem wel, maar anderen niet? De eigenaar duwde hem ook onder druk: hij zei dat hij wilde dat anderen ook de orde konden herstellen, omdat er veel managers zijn, zij houden zich in de regel bezig met operationeel management en strategische planning, maar vrijwel niemand houdt zich bezig met systemische veranderingen in hun processen. Er staat misschien in hun functieomschrijving dat ze hun proces moeten versnellen en de efficiëntie ervan moeten vergroten, maar in feite doet niemand dit. Waarom is dat? De man raakte ook geïnteresseerd in het waarom, en hij ging met al deze managers praten.

Hij kwam naar de adjunct-directeur voor kwaliteit en stelde voor om Shewhart-controlekaarten te introduceren, zodat de producten beter zouden zijn dan de Japanse. Maar het bleek dat de collega niet wist wat Shewhart-controlediagrammen waren, wat statistische procesbeheersing was, en alleen had gehoord over het gebruik van de Deming-cyclus in kwaliteitsmanagement. OKÉ…

Hij ging naar een andere adjunct-directeur en stelde voor om controle in te voeren. Maar ook hier vond ik geen steun. Even later leerde hij over grensbeheer (grensbeheer) en stelde voor dat alle adjunct-directeuren het systemische deel van deze methodologie zouden implementeren om processen te verbeteren. Maar hoeveel onze man ook praatte, niemand wilde zich echt verdiepen in waar het over ging. Misschien waren ze niet geïnteresseerd of was het te moeilijk. Maar eigenlijk heeft niemand het door.

Over het algemeen vertelde hij over alles wat hij wist en gebruikte in het bedrijf. Maar niemand begreep hem. Ze begrijpen nog steeds niet waarom bijvoorbeeld alles in de magazijnboekhouding is gecorrigeerd en wat controle en grensbeheer daarmee te maken hebben.

Als laatste bereikte hij zijn programmeurs - het personeel bestond uit drie personen. Hij sprak over grensbeheer, over controle, over kwaliteitsmanagement, over agile en scrum... En verrassend genoeg begrepen ze alles en konden ze zelfs op de een of andere manier met hem discussiëren, inclusief technische en methodologische subtiliteiten. Ze begrepen waarom de magazijn- en bevoorradingsprojecten succesvol waren. En toen drong het tot de man door: programmeurs zullen in feite de wereld redden.

Hij realiseerde zich dat programmeurs de enigen zijn die bedrijfsprocessen normaal kunnen begrijpen, met de nodige details.

Waarom zij? In feite heeft hij nooit een duidelijk antwoord gevonden. Ik heb alleen thesistips geformuleerd.

Ten eerste kennen programmeurs de vakgebieden van het bedrijf, en zij kennen deze 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 eenvoudigweg niet consistent kunnen zijn. In het inkoopproces waar de man aan werkte, was de eerste stap bijvoorbeeld het opstellen van een jaarlijks inkoopplan en de tweede stap was de dagelijkse inkoop. Deze stappen zijn verbonden door een directe verbinding, dat wil zeggen dat er van wordt uitgegaan dat mensen volgens dit algoritme moeten werken: een jaarlijks inkoopplan opstellen en de aanvraag onmiddellijk uitvoeren. Eén keer per jaar wordt het jaarlijkse inkoopplan opgesteld en er komen 50 keer per dag aanvragen binnen. Dit is waar het algoritme eindigt en je moet eraan werken. In feite, zo redeneerde hij, is kennis van algoritmen voor programmeurs een concurrentievoordeel, omdat iedereen die er niet bekend mee is simpelweg niet begrijpt hoe een bedrijfsproces zou moeten werken en hoe het kan worden weergegeven.

Een ander voordeel van programmeurs is volgens de man dat ze voldoende vrije tijd hebben. We begrijpen allemaal hoe een programmeur drie keer langer aan een taak kan besteden dan hij eigenlijk nodig heeft, en weinigen zullen het merken. Dit is opnieuw een concurrentievoordeel, want om een ​​​​bepaald bedrijfsproces op orde te krijgen, moet je veel vrije tijd hebben - nadenken, observeren, studeren en proberen.

De meeste managers hebben volgens de man deze vrije tijd niet en zijn er trots op. Hoewel dit in feite betekent dat een persoon niet effectief kan worden omdat hij geen tijd heeft om de efficiëntie te verbeteren - een vicieuze cirkel. In onze cultuur is het in de mode om bezig te zijn, dus alles blijft hetzelfde. En voor ons programmeurs is dit een voordeel. We kunnen vrije tijd vinden en over alles nadenken.

Programmeurs, zei hij, kunnen een informatiesysteem snel veranderen. Dit geldt niet voor alle ondernemingen, maar waar hij ook werkte, hij kon alle wijzigingen aanbrengen die hij wilde. Vooral als ze het werk van iemand anders niet betreffen. Hij zou bijvoorbeeld een systeem kunnen lanceren dat in het geheim gebruikersacties meet, en deze informatie vervolgens gebruiken om de efficiëntie van dezelfde boekhoudafdeling te analyseren en de kosten van de boekhouding bij te houden.

En het laatste dat ik me uit zijn woorden herinner, is dat programmeurs toegang hebben tot een grote hoeveelheid informatie, omdat... beheerderstoegang tot het systeem hebben. Daarom kunnen ze deze informatie gebruiken in hun analyse. Niemand anders in een gewone fabriek heeft zo'n hulpbron.

En toen ging hij weg. Tijdens de verplichte detentie van twee weken hebben we hem gedwongen zijn ervaringen te delen, omdat we het werk dat hij deed wilden voortzetten. Welnu, zijn functie kwam vacant.

In de loop van een aantal dagen zetten ze hem op een stoel, zetten de camera aan en namen zijn monologen op. Ze vroegen ons te vertellen over alle voltooide projecten, methoden, benaderingen, successen en mislukkingen, oorzaken en gevolgen, portretten van managers, enz. Er waren geen speciale beperkingen, omdat Ze wisten niet wat er in zijn hoofd omging.

De monologen waren natuurlijk meestal allemaal onzin en gelach - hij was namelijk in een goed humeur verliet de outback naar Sint-Petersburg. Waar moet je gaan werken in Sint-Petersburg? Aan Gazprom natuurlijk.

Maar we zijn erin geslaagd iets nuttigs uit zijn monologen te halen. Ik zal je vertellen wat ik me herinner.

Dus de aanbevelingen van die kerel. Voor wie orde wil proberen te krijgen in bedrijfsprocessen.

Om dit soort werk te doen, moet je eerst een bepaald niveau van "bevriezing" 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. Het was gemakkelijk voor hem, omdat hij zijn reis begon toen hij nog maar zes maanden in het bedrijf had gewerkt en geen tijd had om met iemand in contact te komen, en ook niet van plan was dat te doen. Hij begreep dat mensen komen en gaan, maar zijn eigen resultaten en de beoordeling daarvan door de ondernemer zijn belangrijk voor hem. Of zijn collega's hem goed of slecht behandelden, interesseerde hem toen weinig.

Het tweede punt is dat je, om dit werk effectief te kunnen doen, helaas moet studeren. Maar studeer niet voor een MBA, niet in cursussen, niet in instituten, maar alleen. In zijn eerste project, een magazijnproject, handelde hij bijvoorbeeld intuïtief, hij wist van niets, alleen wat ‘kwaliteitsmanagement’ was.

Toen hij de literatuur begon te lezen over welke methoden er bestonden om de efficiëntie te vergroten, ontdekte hij de technologieën die hij gebruikte. De man paste ze intuïtief toe, maar het blijkt dat dit niet zijn uitvinding was, alles is al lang geleden geschreven. Maar hij bracht tijd door, en veel meer dan wanneer hij meteen het juiste boek had gelezen. Hier is het alleen belangrijk om te begrijpen dat wanneer je een specifieke techniek bestudeert, niet één ervan, zelfs niet de meest geavanceerde, alle problemen van een 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, de auteur van de twee-zwaardstijl. Hij studeerde op een school bij een of andere meester, reisde vervolgens door Japan en vocht met verschillende kerels. Als de man sterker was, stopte de reis een tijdje en werd Musashi een student. Als gevolg hiervan verwierf hij gedurende een aantal jaren de vaardigheden van verschillende praktijken van verschillende meesters en vormde hij zijn eigen school, waaraan hij iets van zichzelf toevoegde. Als gevolg hiervan bereikte hij een unieke vaardigheid. Het is hier hetzelfde.

U kunt uiteraard optreden als bedrijfsadviseur. Over het algemeen zijn het geweldige jongens. Maar in de regel introduceren ze een bepaalde methodologie en implementeren ze de verkeerde methodologie die het bedrijf nodig heeft. We hadden ook zulke verdrietige situaties: niemand weet hoe het probleem op te lossen en niemand wil nadenken over hoe het op te lossen. We gaan op internet zoeken of bellen een adviseur en vragen hem wat ons kan helpen. De consultant denkt en zegt dat we de theorie van beperkingen moeten introduceren. We betalen hem voor zijn aanbeveling, we geven geld uit aan de implementatie, maar het resultaat is nul.

Waarom gebeurt dit? Omdat de adviseur zei: we introduceren dit en dat systeem, en iedereen was het met hem eens. Geweldig, maar één methodologie dekt niet alle problemen van zelfs maar één bedrijfsproces, vooral als de initiële vereisten – die van ons en die nodig zijn om de methodologie te implementeren – niet samenvallen.

In de praktijk die de man aanbeveelt, moet je het beste nemen en het beste implementeren. Neem de methoden niet volledig, maar neem hun belangrijkste kenmerken, kenmerken en praktijken. En het belangrijkste is om de essentie te begrijpen.

Neem, zei hij, bijvoorbeeld Scrum of Agile. In zijn monologen herhaalde de man vele malen dat niet iedereen de essentie van Scrum volledig begrijpt. Hij las ook het boek van Jeff Sutherland, dat sommige mensen 'licht lezen' vinden. Het leek hem een ​​diepgaande studie, omdat een van de fundamentele principes van Scrum kwaliteitsmanagement is, dit staat direct in het boek geschreven.

Het gaat over Toyota Production, over hoe Jeff Sutherland Scrum in Japan liet zien, hoe het daar wortel schoot en hoe dicht het bij hun filosofie lag. En Sutherland sprak over het belang van de rol van de Scrum Master, over de Deming-cyclus. De rol van de Scrum Master is om het proces voortdurend te versnellen. Al het andere dat in Scrum zit – gefaseerde oplevering, klanttevredenheid, een duidelijke werklijst voor de sprintperiode – is ook belangrijk, maar dit alles moet steeds sneller gaan. De werksnelheid moet voortdurend toenemen in de eenheden waarin deze wordt gemeten.

Misschien is dit een kwestie van vertalen, want ons boek is vertaald als “Scrum - een revolutionaire methode voor projectmanagement”, en als de Engelse titel letterlijk wordt vertaald, zal het blijken: “Scrum - twee keer zoveel in de helft van de tijd” , dat wil zeggen, zelfs in De naam verwijst naar snelheid als een sleutelfunctie van Scrum.

Toen deze man Scrum implementeerde, verdubbelde de snelheid in de eerste maand zonder noemenswaardige veranderingen. Hij vond punten voor verandering en paste Scrum zelf aan, zodat het veel sneller werkte. Het enige dat ze op internet schrijven, is dat ze werden geconfronteerd met de vraag: "We hebben de snelheid verdubbeld, het enige dat overblijft is begrijpen wat we met zo'n snelheid doen?" Dit is echter een heel ander gebied...

Hij heeft ook persoonlijk verschillende technieken aanbevolen. Hij noemde ze fundamenteel en fundamenteel.

De eerste is grensbeheer.

Ze leren het in Skolkovo, volgens de man zijn er geen andere boeken en materialen. Hij had op de een of andere manier het geluk een lezing bij te wonen van een professor uit Harvard die grensmanagement predikt, en las ook verschillende artikelen in de Harvard Business Review over het werk van Eric Trist.

Grensmanagement zegt dat je grenzen moet kunnen zien en met grenzen moet kunnen werken. Grenzen zijn er genoeg, ze zijn overal - tussen afdelingen, tussen verschillende soorten werk, tussen functies, tussen operationeel en analytisch werk. Kennis van grensmanagement onthult geen hogere waarheden, maar stelt ons in staat de werkelijkheid in een iets ander licht te zien – door het prisma van grenzen. En beheer ze dienovereenkomstig - plaats ze waar nodig en verwijder ze waar ze in de weg zitten.

Maar meestal had de man het over controle. Hij had gewoon een of andere eigenaardigheid over dit onderwerp.

Controleren is, kort gezegd, sturen op basis van cijfers. Hier, zei hij, is elk onderdeel van de definitie belangrijk – zowel ‘management’ als ‘gebaseerd op’ en ‘cijfers’.

Wij, zei hij, zijn slecht in alle drie de componenten van controle. Vooral gezien het feit dat ze nauw verbonden zijn met elkaar en met andere delen van het bedrijfssysteem.

Het eerste dat slecht is, zijn de cijfers. Er zijn er maar weinig en ze zijn van lage kwaliteit.

Vervolgens hebben we een aanzienlijk deel van de cijfers uit het informatiesysteem 1C gehaald. De kwaliteit van de cijfers in 1C is dus, zoals hij beweerde, niet goed. In ieder geval vanwege de mogelijkheid om gegevens met terugwerkende kracht te wijzigen.

Het is duidelijk dat dit niet de schuld is van de 1C-ontwikkelaars - ze houden alleen 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-werk met gegevens bij een specifieke onderneming te veranderen.

Verder ondergaan de cijfers uit 1C volgens hem een ​​semi-handmatige verwerking, bijvoorbeeld met behulp van Excel. Een dergelijke verwerking voegt ook geen kwaliteit toe aan de gegevens, noch efficiëntie.

Uiteindelijk controleert iemand anders de eindrapportage nog eens, zodat er niet per ongeluk cijfers met fouten aan de manager worden voorgelegd. Hierdoor komen de cijfers mooi, geverifieerd, maar erg laat bij de ontvanger terecht. Meestal - na het einde van de periode (maand, week, etc.).

En hier, zei hij, is alles heel eenvoudig. Als u in februari de cijfers over januari heeft ontvangen, kunt u de activiteiten van januari niet meer beheren. Want januari is alweer voorbij.

En als de cijfers gebaseerd zijn op de boekhouding, en het bedrijf het meest gewone is, met driemaandelijkse BTW-aangifte, dan ontvangt de manager één keer per kwartaal relatief adequate cijfers.

De rest is duidelijk. U ontvangt één keer per maand nummers - u heeft 12 keer per jaar de mogelijkheid om op nummer te beheren (d.w.z. controle). Als je oefent met kwartaalrapportage, beheer je deze 4 keer per jaar. Plus een bonus: jaarlijkse rapportage. Nog een keer sturen.

De rest van de tijd wordt de controle meestal blind uitgevoerd.

Wanneer (en als) de cijfers verschijnen, komt het tweede probleem om de hoek kijken: hoe te handelen op basis van de cijfers? Met dit punt van zijn redenering kon ik het niet eens zijn.

De man voerde aan dat als de manager de cijfers niet eerder had, hun uiterlijk een wow-effect zou veroorzaken. Hij zal de cijfers heen en weer kijken en verdraaien, mensen op het tapijt bellen, uitleg en onderzoek eisen. Na met cijfers te hebben gespeeld, analyses te hebben uitgevoerd en alle medewerkers dreigend te hebben beloofd: 'Nu kom ik niet van je af', zal de manager heel snel kalmeren en deze kwestie opgeven. Stop met het gebruik van het hulpmiddel. Maar de problemen zullen blijven bestaan.

Dit gebeurt, zei hij, als gevolg van onvoldoende managementcompetenties. In de eerste plaats bij het controleren. De manager weet simpelweg niet wat hij met deze cijfers moet doen. Wat сte doen - weet wat te doen - nee. Doen is waar hierboven over geschreven is (ruzie maken, spelen). Doen is een dagelijks bedrijfsproces.

Hij betoogde dat alles heel eenvoudig is: digitaal moet onderdeel worden van het bedrijfsproces. In het bedrijfsproces moet het duidelijk duidelijk zijn: wie moet wat doen en wanneer als de cijfers afwijken van de norm (eventuele opties - boven de grens, onder de grens, voorbij de corridor gaan, de aanwezigheid van een trend, het niet voldoen aan de kwantiel, enz.)

En dus schetste hij het belangrijkste dilemma: het getal bestaat, het zou onderdeel moeten worden van het bedrijfssysteem om de managementefficiëntie te vergroten, maar... dit gebeurt niet. Waarom?

Omdat de Russische leider geen deel van zijn macht zal afstaan ​​aan een concurrent.

De concurrenten van de Russische manager - een kwalitatief hoogstaand en werkend bedrijfsproces, een goed doordachte, wederzijds voordelige motivatie en goede automatisering - zullen de manager helaas zonder baan achterlaten.

Een beetje onzin, ben je het daar niet mee eens? Vooral over leiders. Oké, ik zei het toch, jij beslist zelf.

Iets minder, maar nog steeds te veel, naar mijn mening had hij 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, beschouw jezelf dan als onwetend. Je kunt beter een boek lezen, bijvoorbeeld van Sutherland, dan artikelen en allerlei gidsen (wat maakt het uit?) op internet.

Scrum, zei hij, kan alleen worden geleerd door oefening en met verplichte metingen van de hoeveelheid uitgevoerd werk. Probeer persoonlijk de twee belangrijkste rollen: Product Owner en Scrum Master.

Het is volgens de man vooral belangrijk om de rol van een Scrum Master in de praktijk te ervaren, wanneer je het aantal voltooide taken per sprint kunt vergroten zonder de middelen en kosten van de sprint te verhogen.

Welnu, in zijn top stond TOS (theorie van systeembeperkingen).

Volgens de man zijn dit de fundamentele principes van het vergroten 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, vertelde hij ons dat niet meer. Hij voegde er alleen aan toe dat hij ons het plezier van het lezen van de boeken van Eliyahu Goldratt niet zou ontnemen. Hij gaf een soortgelijke aanbeveling aan Scrum: lees het en probeer het. Ongeacht in welke functie u zich bevindt en welk werk u ook doet, er is ruimte voor het vergroten van de efficiëntie met behulp van TOC-methoden.

Toen droogde zijn tas met technieken blijkbaar op en zei hij: mix de principes om toegepaste oplossingen te creëren in een specifieke situatie.

Dit is volgens hem de belangrijkste aanbeveling, de sleutel tot succes. Begrijp de principes, de essentie en creëer unieke applicatieoplossingen - bedrijfsprocessen en bedrijfssystemen.

Vervolgens probeerde hij zich een citaat te herinneren, en uiteindelijk moest hij online gaan. Het bleek een citaat te zijn uit het artikel “Standing on the Schouders of Giants” van Eliyahu Goldratt:

“Er is een verschil tussen toegepaste oplossingen (applicaties) en de fundamentele concepten waarop die oplossingen zijn gebaseerd. Concepten zijn algemeen; toegepaste oplossingen zijn de aanpassing van concepten aan een specifieke omgeving. Zoals we al hebben gezien, is een dergelijke aanpassing niet eenvoudig en vereist deze de ontwikkeling van bepaalde elementen van de oplossing. We moeten niet vergeten dat een applicatieoplossing gebaseerd is op initiële aannames (soms verborgen) over een specifieke omgeving. Je mag niet verwachten dat deze applicatieoplossing werkt in een omgeving waarvan de aannames niet kloppen.”

Hij zei dat het werk van een programmeur en een ‘bedrijfsprocesverbeteraar’ erg op elkaar lijken. En links.

Bron: www.habr.com