Ez egy valós történet, minden saját szememmel láttam.
Néhány évvel ezelőtt egy fiatalember, akárcsak sokan közülük, programozó volt. Csak hogy tisztázzam: „programozó”. Mert ő 1C szakemberként dolgozott egy gyártó cégnél.
Előtte különböző szakmákban próbálkozott – 4 évet töltött franchise programozóként, projektvezetőként, képes volt 200 órát zárni, miközben részesedést kapott a projekttől, az irányításon kívül pedig kicsit az értékesítéssel is foglalkozott. Próbált önállóan termékeket fejleszteni, az IT osztály vezetője volt egy nagy, 6000 fős cégnél, és különböző módokat keresett programozóként – az 1C szakmán belül.
De ezek a pozíciók többnyire zsákutcák voltak, elsősorban a jövedelem miatt. Mindannyian körülbelül ugyanazt a pénzt kerestük abban az időben, ugyanazokban a körülmények között dolgoztunk.
Ez a fiatalembert kezdte érdekelni, hogyan lehetne több pénzt keresni úgy, hogy nem kell értékesítéssel foglalkoznia és nem kell saját vállalkozást indítania.
Úgy vélte, hogy okos, és elhatározta, hogy keres egy rést abban a cégben, ahol dolgozott. Ennek a résnek különlegesnek kellett lennie, senki által nem foglalt. Azt akarta, hogy a cég magától akarjon pénzt fizetni a pozícióban, hogy senkit ne kelljen megkárosítani, vagy csalni. Objektíven kellett lennie: az adott pozícióra sok pénzt kell fizetni. Egyszóval, furcsa figura volt.
A keresés nem tartott sokáig. A cégnél, ahol dolgozott, volt egy teljesen szabad niche, amit „a vállalati folyamatok rendberakásának” lehet nevezni. Minden cég tele van problémákkal. Mindig valami nem működik, és nincs senki, aki jönne és javítaná a vállalati folyamatokat. Nos, úgy döntött, hogy kipróbálja magát mint szakértő, aki segíthet a tulajdonosnak megoldani az üzleti folyamataival kapcsolatos problémáit.
Abban az időben fél éve dolgozott a cégnél, és a piaci átlagbért kereste. Nem volt mit veszítenie – főleg, hogy egy hasonló munkát egy héten belül könnyedén találhatott volna. Tehát ez a fiatalember úgy gondolta, hogy semmi rémisztő nem történik, ha esetleg semmi nem jön össze és kirúgják.
Összegyűjtötte a bátorságát, és elment a tulajdonoshoz. Javasolta, hogy javítson a legproblémásabb folyamaton, ami a vállalkozásban volt. Akkoriban ez a raktári nyilvántartás volt. Jelenleg mindenkinek, aki ebben a cégben dolgozik, még kínos is visszaemlékezni azokra a problémákra, de a negyedévente elvégzett leltárok eltéréseket mutattak a nyilvántartási rendszer és a tényleges készletek között, amelyek tízszázalékos nagyságrendűek voltak. Költségben, mennyiségben és tételszámban is. Ez igazi tragédia volt. A cég valójában évente csak négyszer rendelkezett helyes nyilvántartással – a leltár napján. Ezt a folyamatot szerette volna rendbe tenni a srác.
A srác megállapodott a tulajdonossal, hogy le kell csökkentenie a leltározási eredmények eltéréseit a felére. Ráadásul a tulajdonosnak nem sokat kellett veszítenie, mert a hősünk előtt már több dolgozó is próbálkozott a helyzet megoldásával, és a feladat összességében szinte megoldhatatlannak számított. Ez nagyon felkeltette az érdeklődést, mert ha sikerül, a fickó automatikusan az a személy lenne, aki rendet tud teremteni és meg tudja oldani a megoldhatatlan problémákat.
Tehát a feladata az volt, hogy egy éven belül a leltározási eltéréseket a duplájára csökkentse. A projekt elején még nem tudta, hogyan fogja ezt elérni, de tudta, hogy a raktári nyilvántartás egyszerű dolog, így valószínűleg sikerül majd valami hasznosat csinálnia. Ráadásul az eltérések csökkentése tíz százalékra a tíz százalékok helyett nem tűnik olyan bonyolultnak. Mindenki, aki a tanácsadói szakmában vagy hasonló területen dolgozik, tudja, hogy a legtöbb folyamati problémát meglehetősen egyszerű intézkedésekkel lehet megoldani.
Január és május között előkészületeket tett, automatizált néhány folyamatot, átírta a raktározás üzleti folyamatát, megváltoztatta a raktárosok és könyvelők munkafolyamatait, és az egész rendszert átalakította, senkinek sem mutatva vagy mesélve róla. Májusban új utasításokat adott mindenkinek, és az év első leltárának után új élet kezdődött – a saját szabályai szerint végzett munka. Az eredmények nyomon követése érdekében a vállalat később gyakrabban, két havonta tartott leltárt. Az első eredmények már pozitívak voltak, és az év végére a leltári eltérések az egy százalék töredékére csökkentek.
A siker óriási volt, de a tartósságában senki sem bízott. A srác maga is kételkedett abban, hogy az eredmény fennmarad, ha eltávolodik és nem figyeli a folyamatot. Ennek ellenére az eredmény megvolt, és a fiú mindent megkapott, amiben megállapodott a tulajdonossal. Később, néhány év elteltével, az eredmény tartóssága megerősítést nyert — néhány évig az eltérések 1 % körül maradtak.
Ekkor úgy döntött, megismétli a kísérletet, és javasolta a tulajdonosnak, hogy javítsanak egy másik problémás folyamatot – a beszállítást. Ott hiányosságok voltak, amelyek megakadályozták, hogy olyan mennyiségeket szállítsanak, amilyeneket az ügyfeleink szerettek volna. Megállapodtak, hogy egy éven belül a hiányosságok a felére csökkennek, és a srác 10-15 projektet is végrehajt, amelyek az 1C-hez kapcsolódnak – különböző üzleti folyamatok automatizálása és egyéb ügyek.
A második évben ismét sikerült mindent sikeresen befejezni, a hiányosságok több mint a felére csökkentek, az összes IT-projektet sikeresen befejezték.
Mivel a fizetés már teljes mértékben kielégítette a srác minden igényét, két évre előre, úgy döntött, hogy egy kicsit megáll, megnyugszik, és egy kényelmes, meleg helyen ül, amit saját magának teremtett.
Mit is jelentett ez? Formálisan ő volt az IT-igazgató. De hogy valójában ki volt, nehéz megérteni. Mivel foglalkozik az IT-igazgató? Általában az IT-infrastruktúra adminisztrálásával, a rendszergazdák irányításával, ERP-rendszerek bevezetésével és részt vesz a vállalat igazgatósági üléseken.
Ennek a srácnak az egyik kulcsfontosságú feladata a változási folyamatokban való részvétel volt, főként a folyamatok generálása, kezdeményezése, megoldások keresése és javaslatok tétele, új irányítási módszerek alkalmazása, a javasolt változások szakmai értékelése, más funkciók és részlegek hatékonyságának elemzése, végül pedig a vállalat stratégiai fejlesztésében való közvetlen részvétel, beleértve a vállalat teljes stratégiai tervének önálló kidolgozását.
Teljes szabad kezet kapott. Bármilyen értekezletre elmehetett, ahová korábban nem volt hozzáférése. Ült ott egy jegyzetfüzettel, valamit írt, vagy csak hallgatott. Ritkán szólt. Aztán elkezdett játszani a telefonján - állította, hogy így jobban működik az asszociatív memória.
Az értekezleten ritkán adott hasznos információt. Elment, gondolkodott, majd érkezett egy levél - vagy kritikával, vagy véleménnyel, vagy javaslatokkal, vagy a már alkalmazott megoldások leírásával.
De gyakrabban ő szervezett értekezleteket. Megtalálta a problémát, kitalálta a megoldásokat, meghatározta az érdekelteket, és mindenkit magával húzott a tárgyalóba. Ott már úgy, ahogy tudott. Meggyőzött, motivált, bizonyított, vitatkozott, elérte a célját.
Hivatalosan őt a cég harmadik személyének tartották, a tulajdonos és a igazgató után. Természetesen ő borzalmasan idegesítette az összes "cégvezetőt", kezdve a 4-es számtól. Különösen szakadt farmereivel és élénk pólóival, nem is beszélve a tulajdonos idejéről.
A tulajdonos minden nap 1 órát szánt neki. Minden nap. Beszélgettek, megbeszélték a problémákat, megoldásokat, új üzleteket, fejlesztési irányokat, teljesítményeket és hatékonyságot, személyes fejlődést, könyveket, és egyszerűen - az életet.
De ez a srác furcsa volt. Mintha csak ült volna és örült volna, hogy az élete sikerült. De nem. Elhatározta, hogy egy kicsit reflektál.
Érdekelni kezdte, hogy miért sikerült neki, míg másoknak nem? A tulajdonos is ösztönözte: azt mondta, hogy szeretné, ha mások is képesek lennének rendet teremteni, mert sok a menedzser, akik általában a működési irányítással és a stratégiai tervezéssel foglalkoznak, de gyakorlatilag senki sem foglalkozik a folyamataik rendszerszintű változtatásaival. Lehet, hogy a munkaköri leírásban benne van, hogy gyorsítaniuk kellene a folyamataikat, növelni a hatékonyságukat, de a valóságban ezzel senki sem foglalkozik. Miért van ez így? Nos, a srácot is érdekelni kezdte, és elment beszélgetni minden menedzserrel.
Elment a minőségügyi igazgató helyetteséhez, és javasolta a Shuhart-féle ellenőrző térképek bevezetését, hogy a termékek jobbak legyenek a japánokénál. De kiderült, hogy a kolléga nem tudta, mi az a Shuhart-féle ellenőrző térkép, mi az a statisztikai folyamatirányítás, és csak hallomásból ismerte a Deming-ciklus alkalmazását a minőségirányításban. Na jó...
Elment egy másik igazgatóhelyetteshez, és javasolta a kontrolling bevezetését. De itt sem talált támogatásra. Kicsivel később hallott a határok kezeléséről, és mindenkinek, aki igazgatóhelyettes, javasolta a módszer rendszerszintű részének bevezetését, hogy javítsák a folyamatokat. De bármennyit beszélgetett, senki sem akart igazán belemerülni a témába. Talán nem érdekli őket, vagy túl bonyolultnak találták. De a valóság az, hogy senki sem jött rá.
Összességében mindent elmondott, amit tudott és alkalmazott a cégnél. De senki sem értette meg. Ma is fogalmuk sincs, hogy például miért sikerült mindent rendbe tenni a raktári nyilvántartásban, holott a kontrolling és a határok kezelése mivel áll kapcsolatban.
Utolsóként eljutott a programozóihoz – a csapatában 3 ember volt. Elmondta a határok kezeléséről, a kontrollingról, a minőségirányításról, az agileről és a scrummal kapcsolatosan… És meglepő módon mindannyian megértették, és még a technikai és módszertani részletekről is tudtak vele beszélgetni. Rájöttek, miért sikerültek a raktári és beszerzési projektek. És ekkor a srácnak eszébe jutott: valójában a programozók fogják megmenteni a világot.
A programozók, jött rá, az egyetlenek, akik képesek megfelelő részletességgel megérteni az üzleti folyamatokat.
Miért pont ők? Valójában nem találta meg a kérdésre a egyértelmű választ. Csak néhány tézist fogalmazott meg.
Először is, a programozók ismerik a vállalati szakterületeket, ráadásul jobban, mint a cég többi munkatársa.
Ezen kívül a programozók valóban értik, mi az algoritmus folyamata. Ez fontos, mert az üzleti folyamatok algoritmusok, és az elemek között egyszerűen nincs összhang. Például a beszerzési folyamatban, amin a srác dolgozott, az első lépés az éves beszerzési terv elkészítése, a második pedig a napi beszerzés. Ezek a lépések közvetlen kapcsolatban állnak, vagyis feltételezzük, hogy az embereknek ezen algoritmus szerint kell dolgozniuk - elkészíteni az éves beszerzési tervet, és azonnal végrehajtani a megrendelést. Az éves beszerzési tervet évente készítik el, míg a megrendelés naponta 50 alkalommal érkezik. Itt ér véget az algoritmus, és ennek alapján kell dolgozni. Valójában úgy ítélte meg, hogy a programozók számára az algoritmusok ismerete versenyelőny, mert bármely más ember, aki nem ismeri ezeket, egyszerűen nem érti, hogyan kell működnie az üzleti folyamatnak, és hogyan lehet azt ábrázolni.
Még egy előnyük van a programozóknak, a fiú szavai szerint - van elég szabad idejük. Mindannyian tudjuk, hogy egy programozó mennyivel többet tölthet egy feladatra, mint amennyi valójában szükséges, és ezt kevesen veszik észre. Ez ismét versenyelőny, mert ahhoz, hogy egy üzleti folyamatot rendbe tegyünk, sok szabadidőre van szükség — gondolkodni, figyelni, tanulmányozni és kísérletezni.
A srác szerint a legtöbb menedzsernek nincs ilyen szabadideje, és büszkék is erre. Mégis, valójában ez azt jelenti, hogy az ember nem tud hatékony lenni, mert nincs ideje a hatékonyság növelésére — ördögi kör. A mi kultúránkban divatos elfoglaltaknak lenni, így minden változatlan marad. Számunkra, programozók számára ez előny. Meg tudjuk találni a szabad időt, és mindent átgondolni.
A programozók, ahogy ő mondta, gyorsan meg tudják változtatni az információs rendszert. Ez nem minden vállalatnál alkalmazható, de ahol ő dolgozott, ott bármilyen módosítást el lehetett végezni, ahogy csak kedvük tartotta. Különösen, ha ez nem érinti senki munkáját. Például elindíthatott egy rendszert, amely titokban méri a felhasználók tevékenységét, és ezt az információt később felhasználhatja a könyvelés hatékonyságának elemzésére és a nyilvántartás költségeinek nyomon követésére.
És az utolsó dolog, amit megjegyeztem a szavaiból – a programozók hozzáféréssel rendelkeznek egy csomó információhoz, mivel adminisztrátori jogosultságokkal bírnak a rendszerhez. Ezért ezt az információt felhasználhatják az elemzéseikhez. Másnak egy hagyományos gyárban ilyen erőforrása nincs.
Aztán elment. A kötelező két hét munkaviszony alatt rákényszerítettük, hogy ossza meg tapasztalatait, mert folytatni akartuk a munkát, amit végezett. Ráadásul az állása is megüresedett.
Néhány napig ültettük a székre, bekapcsoltuk a kamerát és rögzítettük az ő monológjait. Kértük, hogy meséljen minden elvégzett projektről, módszerekről, megközelítésekről, sikerekről és kudarcokról, okokról és következményekről, vezetők portréiról stb. Különösebben nem korlátoztuk, mivel nem tudtuk, mi zajlik a fejében.
A monológokban természetesen főleg mindenféle hülyeség és poén volt – ő csodás hangulatban volt, mivel a tanyáról Pesten való kiruccanásról volt szó. Hová menjünk dolgozni Pesten? Hát a Gazpromhoz, természetesen.
De némi hasznos dolgot sikerült kinyernünk a monológjaiból. Elmondom, mit emlékszem.
Tehát, az a srác javaslatai. Azoknak, akik megpróbálnák rendbe tenni a üzleti folyamatokat.
Ahhoz, hogy ilyen munkát végezzünk, először is egy bizonyos szintű „személyi elborultságra” van szükség. Nem szabad félni a munka elvesztésétől, kockázatot kell vállalni, nem szabad félni a kollégákkal való konfliktusoktól. Neki ez könnyen ment, mert a pályafutását fél év után kezdte a cégnél, és nem volt ideje kapcsolatba lépni senkivel, és nem is akarta. Ő értette, hogy az emberek jönnek és mennek, de számára a saját eredményei és azokat a cég tulajdonosa által végzett értékelése számított. A kollégák mit gondolnak róla, az alig foglalkoztatta akkor.
A második fontos dolog az, hogy ahhoz, hogy hatékonyan végezzük ezt a munkát, sajnos tanulnunk kell. De nem MBA-n, nem kurzusokon, nem intézményekben, hanem önállóan. Például az első projektjében, amely a raktárral foglalkozott, intuíción alapult, semmit sem tudott, csak annyit, hogy mi az a "minőségirányítás".
Amikor elkezdett olvasni az irodalomban, hogy milyen módszerek léteznek a hatékonyság növelésére, felfedezte azokat a technológiákat, amelyeket alkalmazott. A srác intuitíve alkalmazta ezeket, és kiderült, hogy ez nem az ő találmánya, már régóta leírták. De időt pazarolt, és sokkal többet, mint amennyi időt azonnal a szükséges könyv elolvasására kellett volna szánnia. Itt csak az a fontos, hogy megértsük, hogy amikor egy konkrét módszertan tanulmányozunk, egyetlen módszertan, még a legfejlettebb is, nem oldja meg teljesen a vállalati folyamatok összes problémáját.
A másik fontos dolog, hogy minél több módszert ismer, annál jobb. Például a régi Japánban élt Miyamoto Musashi – az egyik leghíresebb vívómester, a két kard stílusának szerzője. Egy iskolában tanult egy mesternél, majd beutazta Japánt, különböző emberekkel harcolt. Ha valaki erősebb volt, akkor az utazás egy időre leállt, és Musashi tanítvány lett. Ennek eredményeként néhány év alatt különböző mesterek különböző gyakorlatait sajátította el, és saját iskoláját alakította ki, hozzáadva saját dolgait. Ennek eredményeként egyedi mesterség birtokába jutott. Itt is ugyanez a helyzet.
Természetesen lehet úgy is eljárni, mint a vállalati tanácsadók. Valójában ők nagyszerű srácok. De általában azért jönnek, hogy bevezessenek egy bizonyos módszert, és nem a vállalat számára szükséges módszert vezetik be. Nálunk is voltak ilyen szomorú helyzetek: senki sem tudta, hogyan oldja meg a problémát, és senki sem akart gondolkodni a megoldáson. Elkezdjük vagy az interneten keresni, vagy meghívni egy tanácsadót, és megkérdezzük tőle, hogy mi segíthet nekünk. A tanácsadó gondolkodik, és azt mondja, hogy be kell vezetni a korlátozások elméletét. Fizetünk neki a javaslatért, költünk a bevezetésre, de az eredmény nulla.
Miért történik ez? Mert a tanácsadó azt mondta, hogy be kell vezetni ezt a rendszert, és mindenki egyetértett vele. Szuper, de egyetlen módszertan sem zár le minden problémát még egyetlen üzleti folyamat esetében sem, különösen, ha az alapfeltételek — a mieink és a bevezetéshez szükségesek — nem egyeznek.
A gyakorlatban, amelyet a srác javasol, a legjobbat kell választani és a legjobbat bevezetni. Nem az összes módszert kell teljesen átvenni, hanem azokat a kulcsfontosságú jellemzőiket, praktikáikat. És a legfontosabb - meg kell érteni a lényegét.
Vegyünk például a scrum-ot vagy az agile-t. A monológokban a srác sokszor megismételte, hogy nem mindenki érti teljesen a scrum lényegét. Ő is olvasta Jeff Sutherland könyvét, amely néhányak számára „könnyű olvasmány”. Számára viszont mélyreható olvasmány volt, mert a scrum alapelvei közé tartozik a minőségirányítás, erről a könyv egyértelműen ír.
Ott szó van a Toyota Production-ról, arról, hogyan mutatta be Jeff Sutherland a scrum-ot Japánban, mennyire beilleszkedett oda és mennyire volt közel az ő filozófiájukhoz. Sutherland mesélt a scrum master szerepének fontosságáról, a Deming ciklusról. A scrum master szerepe a folyamat folyamatos felgyorsítása. Minden egyéb, ami a scrum-ban van – a szakaszos átadás, az ügyfél elégedettsége, a sprint időszakra vonatkozó pontos feladatlista - szintén fontos, de mindennek egyre gyorsabban kell haladnia. A munkasebességnek folyamatosan növekednie kell azokon az egységeken, amelyekben mérik.
Lehet, hogy itt a fordítás a probléma, mert nálunk a könyvet „Scrum – forradalmi projektmenedzsment módszer” címmel fordították, de ha szó szerint lefordítjuk az angol címet, akkor ez kijön: „Scrum – kétszer annyi idő alatt kétszer annyit”, vagyis még a címben is utalás van a sebességre, mint a scrum kulcsfontosságú funkciójára.
Amikor ez a srác bevezette a scrum-ot, az első hónapban a sebesség kétszeresére nőtt különösebb változtatások nélkül. Megtalálta a változtatások helyeit, módosította a scrum-ot, hogy sokkal gyorsabban működjön. Az egyetlen dolog, ahogy az interneten írják, hogy előttük felmerült a kérdés: „Megnöveltük a sebességet a kétszeresére, most már csak azt kell kitalálni, mit kezdünk ezzel a sebességgel?”. Bár ez már egy teljesen más terület...
Ezenkívül személyesen ajánlott néhány módszert. Azokat alapvetőnek és lényegesnek nevezte.
Az első – boundary management (határok kezelése).
A "Skolkovo"-ban tanítják, más könyvek és anyagok állítólag nincsenek. Valahogy szerencséje volt a Harvard egyik professzora előadásán részt venni, aki a boundary management-ről prédikál, és elolvashatta Eric Trist munkáival kapcsolatos néhány cikket a Harvard Business Review-ban.
A boundary management arról szól, hogy meg kell tanulni látni a határokat és dolgozni velük. Határokból rengeteg van, mindenhol - osztályok között, különböző munkaformák között, funkciók között, operatív és elemző munka között. A boundary management tudása nem tár fel magasabb igazságokat, de lehetővé teszi, hogy a valóságot egy kicsit más fényben lássuk - a határok prizmaszerűen. Ennek megfelelően kezelni őket - ahol szükséges, ott felépíteni, ahol pedig gátolják, ott eltüntetni.
De a fiú többet és gyakrabban beszélt a kontrollingról. Valamilyen megszállottsága volt e téma iránt.
A kontrolling röviden annyit jelent, hogy a számok alapján irányítunk. Itt, mondta ő, minden része a definíciónak fontos - az "irányítás", a "számok alapján" és a "számok".
Nálunk, mondta ő, mindhárom összetevővel rosszul állunk a kontrollingban. Különösen figyelembe véve, hogy ezek szorosan összefüggenek egymással és más üzleti rendszer részekkel is.
Az első dolog, ami rossz - a számok. Kevés van belőlük, és a minőségük is alacsony.
A számok jelentős részét akkor a 1C információs rendszerből vettük. Azt mondta, hogy a 1C-ben található számok minősége elég silány. Legalábbis azért, mert lehetőség van az adatok utólagos módosítására.
Nyilvánvaló, hogy a 1C fejlesztőinek nincs ebben hibájuk - csupán figyelembe veszik a piac követelményeit és a hazai könyvelés mentalitását. De a kontrolling céljaira a 1C adatokkal való munkájának elveit inkább meg kellene változtatni egy konkrét vállalatnál.
A 1C-ből érkező számok, a szavai szerint, félig manuális feldolgozáson mennek keresztül, például Excel segítségével. Ilyen feldolgozás nem ad hozzá minőséget az adatokhoz, és az operativitásnak sem segít.
Végül is, a végső jelentést valaki még egyszer átnézi, hogy véletlenül se küldjön a vezetőnek hibás számokat. Az eredményül kapott számok pedig szép, ellenőrzött, de nagyon későn kerülnek a címzetthez. Általában - a periódus (hónap, hét stb.) vége után.
És itt, mondta ő, minden nagyon egyszerű. Ha a januári számok februárban érkeznek meg, akkor a januári tevékenységekhez már nem tudunk irányítani. Mert január már véget ért.
Ha a számok a könyvelésen alapulnak és a vállalat egy átlagos cég, negyedéves áfabevallással, akkor az igazgatója viszonylag reális számokat kap negyedévente.
Továbbá ez érthető. Ha havi számokat kap, lehetősége van a számok alapján menedzselni (azaz kontrolling tevékenységet végezni) évente 12 alkalommal. Ha negyedéves jelentést készít, évente 4 alkalommal tud irányítani. Plusz bónusz - éves jelentés. Ismét egy kicsit irányítani.
A többi időben az irányítás általában olyan, mint a vaksötétben való navigálás.
Amikor (és ha) a számok végre megjelennek, akkor bekapcsolódik a második probléma - hogyan lehet a számok alapján irányítani? Ezzel a kérdéssel még mindig nem tudtam egyetérteni.
A fiú azt állította, hogy ha a vezetőnek korábban nem voltak számok, akkor azok megjelenése wow-effektust fog okozni. Nézni fogja a számokat és görgeti majd ide-oda, embereket hív elő, magyarázatokat és vizsgálatokat követelve. Miután játszott a számokkal, elvégezve az elemzést, és komolyan megígérve minden alkalmazottnak, hogy "most már végleg rajtuk fogok lenni", a vezető nagyon gyorsan megnyugszik és abbahagyja a dolgot. Már nem fogja használni az eszközt. A problémák pedig a helyükön maradnak.
Ez azért történik, mondta, mert a vezető kompetenciái nem elegendőek. Elsősorban a kontrollingban. A vezető egyszerűen nem tudja, mit kezdjen ezekkel a számokkal. Azt atudja, hogy mit kell tenni - tudja, hogy mit kellene csinálni - nem tudja. Megtenni - ez az, amiről fent szó van (kiabálni, játszani). Csinálni - ez a napi üzleti folyamat.
Azt állította, hogy minden nagyon egyszerű: a számnak a vállalati folyamat részévé kell válnia. A vállalati folyamatban világosan kell érteni: ki, mit és mikor kell tennie, ha a szám eltér a normától (bármilyen variáció - a határok fölött, a határok alatt, a koridoron kívül, tendencia jelenléte, kvantálás nem teljesítése stb.)
És itt kijelölte a kulcsdilemmát: a szám ott van, részévé kell válnia az üzleti rendszernek, hogy javítsa a menedzsment hatékonyságát, de... ez nem történik meg. Miért?
Mert az orosz vezető nem ad át egy darabot a hatalmából a konkurenciának.
A helyi vezető konkurensei - egy minőségi és működő üzleti folyamat, jól megtervezett, kölcsönösen előnyös motiváció és megfelelő automatizáció - sajnos munka nélkül hagyják a vezetőt.
Ez valami butaság, nemde? Különösen a vezetőkről. Na mindegy, elmondtam, döntsenek önök.
Kicsit kevesebb, de még mindig túl sok, véleményem szerint a Scrumról beszélt.
Kötelező, mondta, olvassák el és próbálják ki a Scrummal kapcsolatban. Ha mondja, olvasták, de nem próbálták — hát, azt mondják, hogy nem tudják. Jobb egy könyvet olvasni, mondjuk Sutherlandtől, mint cikkeket és különféle útmutatókat (mi ez a hülyeség?) az interneten.
A Scrummal kapcsolatban, mondta, csak a gyakorlatban lehet megtapasztalni, és kötelező méréseket végezni a végzett munka mennyiségéről. Személyesen próbálják ki a két legfontosabb szerepet — a terméktulajdonost és a Scrum mestert.
Különösen fontos, a srác szavai szerint, a Scrum mester szerepének gyakorlati megélése, amikor képesek a sprintek során lezárt feladatok mennyiségét növelni anélkül, hogy a forrásokat vagy a sprint költségét növelnék.
Továbbá a top listáján szerepelt a TOC (a rendszerek korlátozásainak elmélete).
Ez, a srác szavai szerint, alapvető, fundamentális hatékonyságnövelő elvek, amelyeket szinte bármely területen, bármely üzleti folyamatban és üzleti rendszerben alkalmazni lehet.
Amikor megtudta, hogy nem ismerjük a TOC-t, abbahagyta a mesélést. Csak annyit fűzött hozzá, hogy nem akar megfosztani minket Eliyahu Goldratt könyveinek élvezetétől. Hasonló ajánlást adott, mint a Scrumra — olvassák el és próbálják ki. Akárhol is dolgoznak, bármilyen pozícióban, ott található a TOC módszereivel a hatékonyság növelésének lehetősége.
Aztán úgy tűnik, elfogyott a módszertani repertoárja, és azt mondta: keverjék a principiokat, hogy konkrét helyzetekben alkalmazott megoldásokat hozzanak létre.
Ez, mondta, a fő ajánlás, a siker kulcsa. Értse meg az elveket, lényegét, és hozzon létre egyedi alkalmazott megoldásokat — üzleti folyamatokat és üzleti rendszereket.
Aztán próbálta felidézni valamilyen idézetet, végül az internethez kellett nyúlnia. Kiderült, hogy a Goldratt „Óriások vállán állva” című cikkéből származik az idézet:
Van has különbség az alkalmazási megoldások és azok alapvető fogalmai között, amelyekre ezek a megoldások épülnek. A fogalmak általánosak, az alkalmazási megoldások pedig a fogalmak konkrét környezethez való alkalmazásai. Ahogy már láthattuk, ez az alkalmazás nem egyszerű feladat, és bizonyos elemek kifejlesztését igényli. Emlékeznünk kell arra, hogy az alkalmazási megoldás a konkrét környezetről szóló alapfeltevések (néha rejtettek) alapján áll fel. Ne várjuk el, hogy ez az alkalmazási megoldás működjön olyan környezetben, ahol az alapfeltevések nem érvényesek.
Azt mondta, hogy a programozó és a "business process improvement" (üzleti folyamatok fejlesztése) munkája nagyon hasonló. Aztán elment.
Forrás: habr.com
