A történet valós, mindent a saját szememmel láttam.
Több éven át egy srác, mint sokan közületek, programozóként dolgozott. Minden esetre így írom le: „programozó”. Mert 1Snik volt, egy javítási, produkciós cégnél.
Előtte különböző szakterületeket próbált ki - 4 évet Franciaországban programozóként, projektmenedzserként, 200 órát tudott teljesíteni, ugyanakkor megkapta a projekt százalékát, menedzsmentre és egy kis értékesítésre. Megpróbáltam önállóan termékeket fejleszteni, egy 6 ezer fős nagy cég informatikai osztályának vezetője voltam, különféle lehetőségeket próbáltam ki az idézhető szakmám - 1C programozó - felhasználására.
De mindezek a pozíciók némileg zsákutcába kerültek, elsősorban a jövedelem tekintetében. Abban az időben mindannyian megközelítőleg ugyanannyi pénzt kaptunk, és ugyanolyan feltételekkel dolgoztunk.
Ez a srác azon töprengett, hogyan tudna több pénzt keresni anélkül, hogy eladná vagy létrehozná saját vállalkozását.
Okos fickónak képzelte magát, és úgy döntött, hogy keres egy rést a cégben, ahol dolgozott. Ennek a résnek valami különlegesnek kellett lennie, nem foglalta el senki. És azt akartam, hogy a cég maga akarjon pénzt fizetni egy embernek ebben a résben, hogy ne kelljen senkit megtéveszteni vagy becsapni. Ennek a célnak az eléréséhez: egy ilyen pozícióban lévő személynek sok pénzt kell fizetnie. Egyszóval különc.
A keresés rövid ideig tartott. A cégben, ahol ez a fickó dolgozott, volt egy teljesen szabad rés, amelyet úgy lehetne nevezni, hogy „rendet rakunk az üzleti folyamatokban”. Minden cégnek sok problémája van. Valami mindig nem működik, és nincs olyan személy, aki eljönne és megjavítaná az üzleti folyamatot. Ezért úgy döntött, hogy kipróbálja magát olyan szakemberként, aki segíthet a tulajdonosnak megoldani az üzleti folyamatokban felmerülő problémákat.
Ekkor már hat hónapja dolgozott a cégnél, és a piaci átlagkeresetet kapta. Nem volt vesztenivalója, főleg, hogy egy héten belül könnyen megtalálta ugyanazt a munkát. Általában ez a srác úgy döntött, hogy semmi rossz nem történik, ha hirtelen semmi sem sikerül, és kirúgják.
Összeszedte a bátorságát, és odament a tulajdonoshoz. Azt javasoltam neki, hogy javítsa az üzlet legproblémásabb folyamatát. Akkoriban raktári könyvelés volt. Ma már mindenki, aki ebben a cégben dolgozik, még szégyell is emlékezni ezekre a problémákra, de a negyedévente végzett leltározások több tíz százalékos eltérést mutattak ki a számviteli rendszer és a tényleges egyenlegek között. És költségben, mennyiségben és pozíciók számában. Katasztrófa volt. A cég tulajdonképpen csak évente négyszer – a készletszámlálást követő napon – rendelkezett a helyes egyenlegekkel a számviteli rendszerben. A srácunk elkezdte rendbe tenni ezt a folyamatot.
A srác megegyezett a tulajdonossal, hogy felére csökkentse a leltári eredményektől való eltéréseket. Sőt, a tulajdonosnak nem volt vesztenivalója, hiszen hősünk előtt már különféle munkások próbáltak mindent helyrehozni, és általában a feladatot gyakorlatilag megoldhatatlannak ítélték. Mindez nagymértékben felpörgette az érdeklődést, mert ha minden sikerülne, akkor a csávóból automatikusan olyan ember lesz, aki tudja, hogyan kell rendet rakni és megoldani a megoldhatatlan problémákat.
Így a feladat előtt állt: egy éven belül 2-szeresére csökkentse a leltári eredmények alapján az eltéréseket. A projekt indulásakor fogalma sem volt, hogyan érheti el ezt, de megértette, hogy a raktári könyvelés egyszerű dolog, így még tud majd valami hasznosat csinálni. Ráadásul a több tíz százalékos eltérések egytíz százalékra csökkentése nem tűnik olyan nehéznek. Bárki, aki tanácsadói vagy hasonló tevékenységgel foglalkozott, tudja, hogy a legtöbb folyamatprobléma meglehetősen egyszerű lépésekkel megoldható.
Januártól májusig előkészített, kicsit automatizált valamit, átírta a raktári könyvelés üzleti folyamatát, megváltoztatta a raktárosok, könyvelők munkafolyamatait, és általában az egész rendszert átdolgozta, anélkül, hogy bárkinek is megmutatott vagy elmondott volna. Májusban mindenkinek új instrukciókat osztott ki, majd az idei első leltár után új élet kezdődött - az ő szabályai szerint dolgozva. Az eredmények megfigyelése érdekében a jövőben a vállalat gyakrabban - kéthavonta egyszer - kezdett leltárt végezni. Már az első eredmények is pozitívak voltak, az év végére pedig egy százalék töredékére csökkentek az eltérések az ellenőrzési eredményektől.
A siker óriási volt, de nem lehetett hinni a fenntarthatóságában. A srác maga is kételkedett abban, hogy az eredmény megmaradna, ha félrelép, és abbahagyja a folyamat megfigyelését. Ennek ellenére megvolt az eredménye, és a srác mindent megkapott, amiben megegyezett a tulajdonossal. Aztán több év elteltével az eredmény stabilitása megerősítést nyert - több évig az eltérések 1%-on belül maradtak.
Aztán úgy döntött, hogy megismétli a kísérletet, és azt javasolta a tulajdonosnak, hogy javítson egy másik problémás folyamatot - az ellátást. Olyan hiányok voltak, amelyek nem tették lehetővé, hogy a megrendelőink által kívánt mennyiséget szállíthassuk. Megállapodtunk, hogy egy éven belül felére csökkentik a hiányt, és a srác 10-15 projektet is végrehajt az 1C-vel kapcsolatban - különféle üzleti folyamatok és egyéb eretnekségek automatizálására.
A második évben ismét minden sikeresen lezajlott, a hiány több mint 2-szeresére csökkent, minden informatikai projekt sikeresen zárult.
Mivel a fizetés már két évre előre teljesen kielégítette annak a srácnak az összes igényét, ezért úgy döntött, letelepszik egy kicsit, megnyugszik és leül egy hangulatos, meleg helyre, amit maga teremtett.
Milyen volt? Formálisan informatikai igazgató volt. De hogy ki is volt valójában, azt nehéz megérteni. Végül is mit csinál egy informatikai igazgató? Főszabályként az informatikai infrastruktúrát adminisztrálja, a rendszergazdákat irányítja, ERP rendszert vezet be, részt vesz az igazgatósági üléseken.
Ennek a csávónak pedig az volt az egyik legfontosabb feladata, hogy részt vegyen a változási folyamatokban, és főként - ezeknek a folyamatoknak a generálása, elindítása, megoldások keresése és javaslata, új vezetési technikák alkalmazása, javasolt változtatások vizsgálata, egyéb funkciók hatékonyságának elemzése, ill. részlegek, végül közvetlen részvétel a vállalkozás stratégiai fejlesztésében, egészen a teljes vállalatra vonatkozó stratégiai terv önálló kidolgozásáig.
Carte blanche-t kapott. Bármely találkozóra eljöhetett, ahová korábban nem jutott be. Ott ültem egy jegyzettömbbel, írtam valamit, vagy csak hallgattam. Ritkán beszélt. Aztán elkezdett játszani a telefonon, és azt állította, hogy az asszociatív memória így jobban működik.
A találkozón ritkán mondott valami hasznosat. Elment, gondolkodott, majd levél érkezett - akár kritikával, akár véleménnyel, akár javaslatokkal, vagy az általa már alkalmazott megoldások leírásával.
De gyakrabban ő maga hívott össze gyűléseket. Találtam egy problémát, megoldásokat találtam ki, beazonosítottam az érdeklődőket, és mindenkit bevontam a találkozóra. És akkor – ahogy csak tudta. Meggyőzött, motivált, bizonyított, érvelt, elért.
Nem hivatalosan a tulajdonos és az igazgató után a cég harmadik személyének számított. Persze borzasztóan felbőszítette a 4-es számmal kezdődően a „cég összes személyét. Főleg szakadt farmereivel, fényes pólóival, illetve tulajdonosi idejével.
A tulajdonos napi 1 órát adott neki. Minden nap. Beszélgettek, megvitatták a problémákat, megoldásokat, új vállalkozásokat, fejlesztési területeket, indikátorokat és hatékonyságot, személyes fejlődést, könyveket és egyszerűen az életet.
De ez a srác furcsa volt. Ez olyan, hogy dőlj hátra és légy boldog, az élet jó. De nem. Úgy döntött, reflektál.
Elgondolkodott: miért jött be neki, de másoknak nem? A tulajdonos is drukkolt neki: azt mondta, hogy szeretné, ha mások is helyreállíthatnák a rendet, mert sok a vezető, ők általában operatív irányítással és stratégiai tervezéssel foglalkoznak, de rendszerszintű változtatásokkal gyakorlatilag senki nem foglalkozik. folyamataikban. Lehet, hogy a munkaköri leírásukban le van írva, hogy gyorsítsák a folyamatukat, növeljék annak hatékonyságát, de ezt valójában senki sem teszi. Miert van az? A srácot is érdekelni kezdte, hogy miért, és elment beszélni ezekkel a menedzserekkel.
Minőség miatt jött az igazgatóhelyetteshez, és javasolta a Shewhart vezérlőtáblák bevezetését, hogy a termékek jobbak legyenek, mint a japánok. Ám kiderült, hogy a kolléga nem tudja, mi az a Shewhart vezérlőtábla, mi az a statisztikai folyamatszabályozás, és csak a Deming-ciklus minőségirányítási használatáról hallott. RENDBEN…
Elment egy másik igazgatóhelyetteshez, és javasolta a kontrolling bevezetését. De itt sem találtam támogatást. Kicsit később megismerte a határkezelést (határkezelés), és azt javasolta, hogy minden igazgatóhelyettes alkalmazza ennek a módszertannak a rendszerszintű részét a folyamatok javítása érdekében. De hiába beszélt a srácunk, senki sem akart belemenni abba, hogy miről is van szó. Lehet, hogy nem érdekelte őket, vagy túl nehéz volt. De valójában senki sem jött rá.
Általában mindenről beszélt, amit tudott és használt a társaságban. De senki sem értette meg. Továbbra sem értik, hogy például a raktári könyvelésben miért korrigáltak mindent, és mi köze ehhez az ellenőrzésnek és a határigazgatásnak.
Végül elérte a programozóit – a személyzet 3 főből állt. Beszélt a határkezelésről, a kontrollingról, a minőségirányításról, az agilisról és a scrumról... És meglepő módon mindent megértettek, sőt valahogy meg is tudtak vele beszélni, beleértve a technikai és módszertani finomságokat is. Megértették, miért sikerültek a raktári és ellátási projektek. És ekkor feltűnt a srácnak: valójában a programozók fogják megváltani a világot.
Rájött, hogy a programozók az egyedüliek, akik normálisan, a szükséges részletekkel megérthetik az üzleti folyamatokat.
Miért pont őket? Valójában soha nem talált egyértelmű választ. Csak a tézis tippeket fogalmaztam meg.
Először is, a programozók ismerik az üzlet tárgyköreit, és jobban ismerik azokat, mint a cég többi tagja.
Ráadásul a programozók igazán értik, mi az a folyamatalgoritmus. Ez azért fontos, mert az üzleti folyamatok algoritmusok, és előfordulhat, hogy a bennük lévő elemek egyszerűen nem konzisztensek. Például a beszerzési folyamatban a srác dolgozott, az első lépés az éves beszerzési terv elkészítése volt, a második pedig a napi beszerzés. Ezeket a lépéseket közvetlen kapcsolat köti össze, vagyis feltételezzük, hogy az embereknek ezen algoritmus szerint kell dolgozniuk - éves beszerzési tervet kell készíteni, és azonnal végrehajtani a kérést. Az éves beszerzési terv évente egyszer készül, a pályázatok napi 50 alkalommal érkeznek. Itt ér véget az algoritmus, és dolgozni kell rajta. Tulajdonképpen – indokolta – a programozók számára az algoritmusok ismerete versenyelőnyt jelent, mert aki nem ismeri őket, egyszerűen nem érti, hogyan kell működnie egy üzleti folyamatnak, és hogyan ábrázolható.
A programozók másik előnye a srác szerint, hogy van elég szabadidejük. Mindannyian megértjük, hogy egy programozó háromszor hosszabb időt tölthet egy feladattal, mint amennyit valójában igényel, és kevesen veszik észre. Ez ismét versenyelőny, hiszen ahhoz, hogy egy-egy üzleti folyamatot rendbe tudjunk tenni, sok szabadidőre van szükség – gondolkodni, megfigyelni, tanulni és próbálkozni.
A legtöbb menedzsernek a srác szerint nincs ilyen szabadideje, és büszkék rá. Bár valójában ez azt jelenti, hogy az ember nem lehet hatékony, mert nincs ideje a hatékonyság javítására - ez egy ördögi kör. A mi kultúránkban divat elfoglaltnak lenni, így minden marad a régiben. És nekünk, programozóknak ez előny. Találhatunk szabadidőt és mindent átgondolhatunk.
Azt mondta, a programozók gyorsan képesek megváltoztatni egy információs rendszert. Ez nem minden vállalkozásnál érvényes, de bárhol dolgozott, tetszőleges módosítást végezhetett. Főleg, ha nem mások munkáját érintik. Például elindíthat egy olyan rendszert, amely titokban méri a felhasználói műveleteket, majd ezt az információt felhasználja ugyanannak a számviteli osztálynak a hatékonyságának elemzésére és a könyvelés költségeinek nyomon követésére.
És az utolsó dolog, amire a szavaiból emlékszem, hogy a programozók nagy mennyiségű információhoz férnek hozzá, mert... rendszergazdai hozzáféréssel rendelkezik a rendszerhez. Ezért ezeket az információkat felhasználhatják elemzésük során. Egy normál üzemben senki másnak nincs ilyen erőforrása.
És akkor elment. Az előírt kéthetes fogva tartás alatt arra kényszerítettük, hogy ossza meg tapasztalatait, mert folytatni akartuk az általa végzett munkát. Nos, a pozíciója megüresedett.
Néhány nap leforgása alatt leültették egy székre, bekapcsolták a kamerát és felvették a monológjait. Azt kérték, hogy meséljenek minden megvalósult projektről, módszerről, megközelítésről, sikerekről és kudarcokról, okokról és következményekről, vezetői portréról stb. Különös korlátozások nem voltak, mert Nem tudták, mi jár a fejében.
A monológok persze nagyrészt hülyeségek és nevetések voltak – remek hangulatban volt, mert elhagyta a külvárost Szentpétervárra. Hová menjen dolgozni Szentpéterváron? Természetesen a Gazpromnak.
De a monológjaiból sikerült valami hasznosat kiszednünk. Elmondom, amire emlékszem.
Szóval a srác ajánlásai. Azoknak, akik szeretnének rendet tenni az üzleti folyamatokban.
Az ilyen jellegű munka elvégzéséhez először is bizonyos szintű „fagyással” kell rendelkeznie. Nem kell félni az állás elvesztésétől, nem kell félni a kockázatvállalástól, nem kell félni a kollégákkal való konfliktusoktól. Könnyű volt neki, mert akkor indult útjára, amikor még csak hat hónapja dolgozott a cégnél, és nem volt ideje senkivel kapcsolatba lépni, és nem is állt szándékában. Megértette, hogy az emberek jönnek-mennek, de a saját eredményei és a cégtulajdonos értékelése fontosak számára. Az, hogy kollégái jól vagy rosszul bántak-e vele, akkoriban nem érdekelte.
A második pont az, hogy ennek a munkának a hatékony elvégzéséhez sajnos tanulnia kell. De ne MBA-ra tanulj, ne tanfolyamokon, ne intézetekben, hanem önállóan. Például első projektjében, egy raktárprojektben intuitívan cselekedett, nem tudott semmit, csak azt, hogy mi az a „minőségmenedzsment”.
Amikor elkezdte olvasni a szakirodalmat arról, hogy milyen módszerek léteznek a hatékonyság növelésére, felfedezte az általa használt technológiákat. A srác intuitívan alkalmazta őket, de kiderült, hogy ez nem az ő találmánya, minden már régen meg volt írva. De időt töltött, és sokkal többet, mintha azonnal elolvasta volna a megfelelő könyvet. Itt csak azt fontos megérteni, hogy ha egy adott technikát tanulmányoz, egyikük sem, még a legfejlettebb sem fogja teljesen megoldani az üzleti folyamat összes problémáját.
A második trükk az, hogy minél több technikát ismersz, annál jobb. Például az ókori Japánban élt Miyamoto Musashi, az egyik leghíresebb kardforgató, a kétkardos stílus szerzője. Valamelyik iskolában tanult valami mesternél, majd körbeutazta Japánt, harcolt különböző haverokkal. Ha a srác erősebb volt, akkor az utazás egy ideig megállt, és Musashi diák lett. Ennek eredményeként több év alatt elsajátította a különböző mesterek különféle gyakorlatainak készségeit, és megalapította saját iskoláját, hozzáadva valamit a sajátjából. Ennek eredményeként egyedülálló képességekre tett szert. Ez itt is ugyanaz.
Természetesen üzleti tanácsadóként is tevékenykedhet. Általában véve nagyszerű srácok. De általában azért jönnek, hogy bevezessenek valamilyen módszertant, és rossz módszertant alkalmaznak, amire a vállalkozásnak szüksége van. Nekünk is voltak ilyen szomorú helyzeteink: senki sem tudja, hogyan oldja meg a problémát, és senki sem akar arra gondolni, hogyan oldja meg. Elkezdünk keresgélni az interneten, vagy felhívunk egy tanácsadót, és megkérdezzük, mi tud nekünk segíteni. A tanácsadó gondolkodik, és azt mondja, hogy be kell vezetnünk a korlátok elméletét. Fizetünk neki az ajánlásáért, pénzt költünk a megvalósításra, de az eredmény nulla.
Miért történik ez? Mert a tanácsadó azt mondta, ilyen-olyan rendszert vezetünk be, és mindenki egyetértett vele. Remek, de egy módszertan még egy üzleti folyamat összes problémáját sem fedi le, főleg, ha a kezdeti előfeltételek - a miénk és a módszertan megvalósításához szükségesek - nem esnek egybe.
A srác által javasolt gyakorlatban a legjobbat kell vennie, és a legjobbat kell végrehajtania. Ne vegye teljesen a módszereket, hanem vegye figyelembe a legfontosabb jellemzőit, jellemzőit és gyakorlatait. És a legfontosabb, hogy megértsük a lényeget.
Vegyük például a Scrumot vagy az Agile-t – mondta. A srác monológjaiban sokszor elismételte, hogy nem mindenki érti teljesen a Scrum lényegét. Olvasta Jeff Sutherland könyvét is, amelyet egyesek "könnyed olvasmánynak" találnak. Mély olvasmánynak tűnt számára, mert a Scrum egyik alapelve a minőségirányítás, ez van közvetlenül a könyvben megírva.
A Toyota Productionról szól, arról, hogyan mutatta be Jeff Sutherland a Scrumot Japánban, hogyan honosodott meg ott, és mennyire közel állt a filozófiájukhoz. Sutherland pedig a Scrum Master szerepének fontosságáról, a Deming-ciklusról beszélt. A Scrum Master feladata a folyamat folyamatos felgyorsítása. Minden más, ami a Scrumban van - szakaszos szállítás, vevői elégedettség, egyértelmű munkalista a sprint időszakra - szintén fontos, de ennek mind gyorsabban kell haladnia. A munka sebességének folyamatosan növekednie kell azokban a mértékegységekben, amelyekben mérik.
Talán ez fordítás kérdése, mert könyvünket „Scrum - a projektmenedzsment forradalmi módszere”-nek fordították, és ha az angol címet szó szerint fordítják, akkor kiderül: „Scrum - kétszer annyi, feleannyi idő alatt” , vagyis még a A név a Scrum kulcsfunkciójaként utal a sebességre.
Amikor ez a fickó bevezette a Scrumot, a sebesség az első hónapban megduplázódott, minden lényeges változás nélkül. Pontokat talált a változtatáshoz, és magát a Scrumot módosította, hogy sokkal gyorsabban működjön. Csak annyit írnak az interneten, hogy szembesültek azzal a kérdéssel: „Dupláztuk a sebességet, csak az van hátra, hogy megértsük, mit csinálunk ilyen sebességgel?” Ez azonban egy teljesen más terület...
Több technikát személyesen is ajánlott. Alapvetőnek és alapvetőnek nevezte őket.
Az első a határkezelés.
Skolkovóban tanítják, a srác szerint nincs más könyv és anyag. Valamilyen szerencséje volt, hogy részt vegyen egy harvardi professzor előadásán, aki a határkezelést prédikálja, és több cikket is elolvasott a Harvard Business Review-ban Eric Trist munkásságáról.
A határkezelés azt mondja, hogy tudnia kell látni a határokat és dolgozni a határokkal. Rengeteg határ van, mindenhol ott vannak - osztályok között, különféle munkatípusok között, funkciók között, operatív és elemző munka között. A határkezelés ismerete nem tár fel magasabb igazságokat, de lehetővé teszi, hogy a valóságot egy kicsit más megvilágításban lássuk – a határok prizmáján keresztül. És ennek megfelelően kezelje őket - állítsa fel, ahol szükséges, és távolítsa el őket, ahol az útban vannak.
De leggyakrabban a srác az irányításról beszélt. Csak volt valami furcsasága ebben a témában.
A kontrolling röviden: számokon alapuló menedzsment. Itt szerinte a meghatározás minden része fontos – mind a „menedzsment”, mind a „számok alapján”.
Azt mondta, rosszak vagyunk a kontrolling mindhárom összetevőjével. Főleg, ha figyelembe vesszük, hogy szorosan összefüggenek egymással és az üzleti rendszer más részeivel is.
Az első dolog, ami rossz, az a számok. Kevés van belőlük és rossz minőségűek.
Ezután a számok jelentős részét az 1C információs rendszerből vettük át. Tehát a számok minősége az 1C-ben, ahogy állította, nem jó. Legalábbis az adatok visszamenőleges megváltoztatásának lehetősége miatt.
Nyilvánvaló, hogy ez nem az 1C fejlesztőinek hibája - csak a piac követelményeit és a hazai könyvelés mentalitását veszik figyelembe. Ellenőrzési célokra azonban jobb, ha megváltoztatjuk az 1C adatokkal való munka alapelveit egy adott vállalatnál.
Továbbá az 1C-ből származó számok szerinte félkézi feldolgozáson esnek át, például Excel segítségével. Az ilyen feldolgozás szintén nem növeli az adatok minőségét és hatékonyságát.
A végén valaki más kétszer ellenőrzi a zárójelentést, hogy véletlenül se küldje el a hibás számadatokat a vezetőnek. Ennek eredményeként a számok gyönyörűen, igazoltan, de nagyon későn jutnak el a címzetthez. Általában - az időszak vége után (hónap, hét stb.).
És itt, mondta, minden nagyon egyszerű. Ha a januári számok februárban értek el, akkor már nem tudod kezelni a januári tevékenységeket. Mert a januárnak már vége.
Ha pedig a számok számviteli alapúak, és a cég a leghétköznapibb, negyedéves áfa-bevallással, akkor annak vezetője negyedévente kap viszonylag megfelelő számokat.
A többi világos. Havonta egyszer kap számokat – évente 12 alkalommal van lehetősége számokkal kezelni (vagyis vezérelni). Ha gyakorolja a negyedéves jelentést, akkor évente 4 alkalommal kezeli. Plusz egy bónusz – éves jelentés. Kormányozzon még egyszer.
A fennmaradó időben az irányítást általában vakon végzik.
Amikor (és ha) megjelennek a számok, akkor jön a második probléma – hogyan kell kezelni a számok alapján? Érvelésének ezen pontjával nem tudtam egyetérteni.
A srác azzal érvelt, hogy ha a menedzser korábban nem rendelkezett a számokkal, akkor a megjelenésük wow hatást váltana ki. Megnézi és csavarja a számokat erre-arra, szőnyegre hív, magyarázatot és vizsgálatot követel. A számokkal való játék, elemzések elvégzése és fenyegetően megígért minden alkalmazottnak, hogy „most nem szabadulok meg tőled”, a menedzser nagyon gyorsan megnyugszik és feladja ezt az ügyet. Hagyja abba az eszköz használatát. De a problémák a helyükön maradnak.
Ez szerinte az elégtelen vezetői kompetenciák miatt történik. Az irányításban mindenekelőtt. A menedzser egyszerűen nem tud mit kezdeni ezekkel a számokkal. Mit сtenni – tudja, mit kell tenni – nem. Csinálni az, amiről fentebb le van írva (veszekedni, játszani). A cselekvés mindennapos üzleti folyamat.
Azzal érvelt, hogy minden nagyon egyszerű: a digitálisnak az üzleti folyamat részévé kell válnia. Az üzleti folyamatban egyértelműen világosnak kell lennie: kinek mit kell tennie és mikor, ha a számok eltérnek a normától (bármilyen lehetőség - határ felett, határ alatt, folyosón túllépés, trend jelenléte, nem teljesítik a kvantilis stb.)
És így felvázolta a kulcsdilemmát: a szám létezik, az üzleti rendszer részévé kellene válnia a menedzsment hatékonyságának növelése érdekében, de... ez nem történik meg. Miért?
Mert az orosz vezető egy darabot sem ad át hatalmából egy versenytársnak.
Az orosz menedzser versenytársai - magas színvonalú és működő üzleti folyamat, átgondolt, kölcsönösen előnyös motiváció és megfelelő automatizálás - sajnos állás nélkül hagyják a menedzsert.
Valami hülyeség, nem értesz egyet? Főleg a vezetőkről. Oké, mondtam, döntsd el magad.
Kicsit kevesebbet, de még mindig túl sokat, szerintem Scrumról beszélt.
Mindenképpen olvassa el, és próbálja ki a Scrumot a gyakorlatban, mondtam. Ha – mondja – elolvasta, de nem próbálta ki, tekintse magát tudatlannak. Jobb olvasni egy könyvet, például Sutherlandtől, mint cikkeket és mindenféle útmutatót (mi a fenét?) az interneten.
A Scrumot szerinte csak gyakorlással lehet megtanulni, és az elvégzett munka mennyiségének kötelező mérésével. Személyesen próbálja ki a két legfontosabb szerepet – a terméktulajdonost és a Scrum mestert.
A srác szerint különösen fontos a gyakorlatban is megtapasztalni a Scrum Master szerepét, amikor a sprint erőforrásainak és költségének növelése nélkül lehet növelni a sprintenként elvégzett feladatok mennyiségét.
Nos, a felsőjében ott volt a TOS (rendszerkorlátozások elmélete).
Ezek a srác szerint a hatékonyság növelésének alapvető, alapvető elvei, amelyek szinte minden területen, bármely üzleti folyamatban és üzleti rendszer egészében alkalmazhatók.
Amikor megtudta, hogy nem ismerjük a TOS-t, nem mondta el nekünk. Csak annyit tett hozzá, hogy nem foszt meg minket attól az örömtől, hogy Eliyahu Goldratt könyveit olvassuk. Hasonló ajánlást adott a Scrumnak – olvassa el és próbálja ki. Bármilyen pozícióban is vagy, bármilyen munkát végez, van helye a hatékonyság növelésének a TOC módszerekkel.
Aztán látszólag kiszáradt a táskája a technikákból, és azt mondta: keverje össze az elveket, hogy egy adott helyzetben alkalmazott megoldásokat alkosson.
Szerinte ez a fő ajánlás, a siker kulcsa. Ismerje meg az alapelveket, a lényeget, és hozzon létre egyedi alkalmazási megoldásokat - üzleti folyamatokat és üzleti rendszereket.
Aztán megpróbált visszaemlékezni valami idézetre, és végül fel kellett lépnie az internetre. Kiderült, hogy ez egy idézet Eliyahu Goldratt „Állunk az óriások vállán” című cikkéből:
„Különbség van az alkalmazott megoldások (alkalmazások) és az alapkoncepciók között, amelyeken ezek a megoldások alapulnak. A fogalmak általánosak, az alkalmazott megoldások a fogalmak egy adott környezethez való adaptálása. Mint már láttuk, az ilyen adaptáció nem egyszerű, és a megoldás bizonyos elemeinek kidolgozását igényli. Emlékeznünk kell arra, hogy egy alkalmazásmegoldás egy adott környezettel kapcsolatos kezdeti (néha rejtett) feltételezéseken alapul. Ettől az alkalmazási megoldástól nem várható el, hogy olyan környezetben működjön, amelyre a feltételezések nem helytállóak.”
Elmondta, hogy a programozó és az „üzleti folyamatjavító” munkája nagyon hasonló. És elment.
Forrás: will.com