Příběh je skutečný, všechno jsem viděl na vlastní oči.
Několik let pracoval jeden chlapec, jako spousta z vás, jako programátor. Pro jistotu to napíšu takto: „programátor“. Protože byl specialistou na 1C, ve fixační výrobní společnosti.
Předtím zkoušel různé profese – 4 roky jako programátor ve franšíze, vedoucí projektů, dokázal zakrývat 200 hodin, přičemž zároveň dostával procenta z projektu za řízení a trochu se věnoval prodeji. Zkoušel vyvíjet produkty sám, byl vedoucím IT oddělení ve velké společnosti s 6000 zaměstnanci, zkoušel různé varianty využití svého nefandovského povolání – programátora 1C.
Ale všechny tyto pozice byly docela bezvýchodné, především co do příjmu. Tehdy jsme všichni dostávali zhruba stejné peníze, pracovali ve stejných podmínkách.
Tomu chlapci se začalo zajímat, jak by mohl vydělávat více peněz, aniž by se věnoval prodeji nebo zakládal vlastní podnikání.
Představoval si, že je chytrý, a rozhodl se najít mezeru ve společnosti, kde pracoval. Tato mezera by měla být nějaká zvláštní, nikým nezaplněná. A chtěl, aby společnost sama chtěla platit peníze člověku v této oblasti, aby nikdo nemusel nikoho podvádět nebo cokoli navyšovat. Aby to bylo objektivní: člověku na této pozici je třeba platit hodně peněz. V podstatě blázen.
Hledání netrvalo dlouho. Ve společnosti, kde tento chlapec pracoval, byla zcela volná mezera, kterou lze podmíněně nazvat „uspořádání obchodních procesů“. V každé společnosti je spousta problémů. Vždycky něco nefunguje a není tam nikdo, kdo by přišel a opravil obchodní proces. Tak se rozhodl zkusit se uplatnit jako specialista, který může majiteli pomoci vyřešit jeho problémy v obchodních procesech.
V té době pracoval ve společnosti půl roku a měl průměrnou mzdu podle trhu. Neměl co ztratit – tím spíše, že takovou práci by si mohl najít za týden. Celkově tento chlapec usoudil, že se nic hrozného nestane, pokud by najednou nic nevyšlo a byl by propuštěn.
Nabral odvahu a přišel za majitelem. Navrhl mu zlepšit nejproblematičtější proces v podnikání. V té době to byla skladová evidence. Dnes je lidem, kteří v této společnosti pracují, dokonce trapné vzpomínat na tyto problémy, ale inventury, které se konaly čtvrtletně, odhalovaly nesoulady mezi účetním systémem a skutečnými zůstatky o desítky procent. A to jak v ceně, tak v množství a počtu položek. To byla pohroma. Společnost měla skutečné zůstatky v účetním systému pouze čtyřikrát za rok – den poté, co byla provedena inventura. Tento proces dal ten kluk do pořádku.
Kluk se domluvil s majitelem, že musí snížit odchylky podle výsledků inventur na polovinu. Přitom majiteli moc nezbývalo, protože před naším hrdinou se pokusy vše opravit dělali různí zaměstnanci a celkově byla úloha považována za prakticky neřešitelnou. To všechno velmi zvedalo zájem, protože pokud se to podaří, člověk by automaticky získal reputaci někoho, kdo dokáže zavádět pořádek a řešit neřešitelné úkoly.
Takže před ním stálo úkol: během roku snížit odchylky podle výsledků inventur na polovinu. Na začátku projektu neměl ponětí, jak to dosáhnout, ale chápal, že skladová evidence je jednoduchá záležitost, takže stále bude moci něco užitečného udělat. O to víc, že snížit odchylky z desítek procent na jednotkové procento – to se zdá, že to není tak složité. Všichni, kdo pracovali v oblasti poradenství nebo podobné činnosti, chápou, že většina problémů procesu se odstraňuje poměrně jednoduchými opatřeními.
Od ledna do května se připravoval, trochu něco automatizoval, přepsal obchodní proces skladového hospodářství, změnil pracovní toky skladníků, účetních a celkově přepracoval celý systém, aniž by to komukoli ukazoval nebo říkal. V květnu dal všem nové instrukce a po první inventuře v roce začal nový život – práce podle jeho pravidel. Aby mohl sledovat výsledek, začala firma provádět inventury častěji – jednou za dva měsíce. Již první výsledky byly pozitivní a do konce roku k odchylkám v revizních výsledcích došlo pouze na úrovni zlomku procenta.
Úspěch byl obrovský, ale v jeho udržitelnost se nevěřilo. Samotný chlapec pochyboval, že výsledek zůstane, pokud se od něj odtáhne a přestane sledovat proces. Nicméně, výsledek byl, a chlapec dostal všechno, o čem se dohodl s majitelem. Po několika letech se udržitelnost výsledku potvrdila — po několik let se odchylky držely v mezích 1 %.
Tehdy se rozhodl opakovat experiment a navrhl majiteli vylepšit jiný problematický proces – zásobování. Tam byly nedostatky, které neumožňovaly dodávat takové objemy, jaké naši klienti chtěli. Dohodli se, že během roku se nedostatky sníží na polovinu, a chlapec navíc dokončí 10-15 projektů souvisejících s 1C — na automatizaci různých obchodních procesů a dalšími záležitostmi.
Ve druhém roce se znovu vše úspěšně podařilo dokončit, nedostatky se snížily více než dvakrát, všechny IT projekty byly úspěšně dokončeny.
Jelikož plat již zcela uspokojoval všechny požadavky toho chlapce na dva roky dopředu, rozhodl se trochu zklidnit, uklidnit se a posedět na útulném teplém místě, které si sám vytvořil.
Co to vlastně představovalo? Formálně byl IT ředitelem. Ale čím skutečně byl, pochopit je obtížné. Vždyť co dělá IT ředitel? Obvykle administruje IT infrastrukturu, řídí systémové administrátory, zavádí ERP systém, účastní se zasedání správní rady.
Jednou z klíčových povinností tohoto muže byla účast na procesech změn, přičemž se převážně zaměřoval na generaci a iniciaci těchto procesů, hledání a navrhování řešení, aplikaci nových metod řízení, posuzování navržených změn, analýzu efektivity jiných funkcí a oddělení a nakonec i přímou účast na strategickém rozvoji podniku, až po samostatné vypracování strategického plánu celé společnosti.
Dostal naprostou volnost. Mohl chodit na jakoukoli schůzi, kam dříve neměl přístup. Seděl tam s blokem, něco si zapisoval nebo jednoduše poslouchal. Mluvil zřídka. Poté se pustil do hraní na telefonu — tvrdil, že takto lépe pracuje asociativní paměť.
Na schůzích málokdy něco užitečného vyprodukoval. Odešel, přemýšlel, a pak přišel e-mail — buď s kritikou, nebo s názorem, nebo s návrhy, nebo s popisem řešení, která už aplikoval.
Ale častěji schůze organizoval sám. Našel problém, vymyslel varianty řešení, určil zúčastněné strany a tahal je všechny do jednací místnosti. A tam už — jak uměl. Přesvědčoval, motivoval, dokazoval, hádal se, dosahoval.
Neoficiálně byl považován za třetí osobu ve firmě, po majiteli a řediteli. Samozřejmě, že všechny „osoby firmy“ začínající od čísla 4 hrozně štval. Zvlášť svými roztrhanými džíny a jasnými tričky, a také — časem stráveným s majitelem.
Majitel mu věnoval 1 hodinu denně. Každý den. Rozhovory vedli o problémech, řešeních, nových obchodech, směrech rozvoje, ukazatelích a efektivitě, osobním rozvoji, knihách, a jednoduše — o životě.
Ale ten kluk byl podivný. Jakoby — sedni a raduj se, život se podařil. Ale ne. Rozhodl se o něčem přemýšlet.
Zajímalo ho, proč se to jemu podařilo, zatímco ostatním ne? Majitel ho také povzbudil: říkal, že chce, aby i ostatní uměli zavádět pořádek, protože manažerů je mnoho, obvykle se zabývají operativním řízením a strategickým plánováním, ale nikdo se prakticky nezabývá systémovými změnami ve svých procesech. Možná to mají zapsané v pracovním náplni, že mají zrychlit svůj proces a zvyšovat jeho efektivitu, ale ve skutečnosti se tím nikdo nezabývá. Proč? Chlapce to také zajímalo, a tak se šel bavit se všemi těmi manažery.
Přišel k zástupci ředitele pro kvalitu a navrhl zavést kontrolní mapy Šuharta, aby byla produkce lepší než japonská. Ale ukázalo se, že kolega neví, co to jsou kontrolní mapy Šuharta, co je to statistické řízení procesů, a pouze okrajově slyšel o aplikaci Demingova cyklu v řízení kvality. No nic...
Přešel k další zástupkyni ředitele a navrhl zavést controlling. Ale ani tady nenašel podporu. O něco později se dozvěděl o managementu hranic a všem zástupcům ředitele navrhl zavést systémovou část této metodiky k zlepšení procesů. Ale kolikrát s nimi mluvil, nikdo se o to příliš nezajímal. Možná je to nezajímalo, nebo bylo příliš složité. Ale ve skutečnosti to nikdo nepochopil.
Celkově jim pověděl vše, co věděl a co používal ve firmě. Ale nikdo ho tak a nepochopil. Dodnes jim není jasné, proč například všechno vyšlo opravit ve skladovém účetnictví, a jaký to má vztah k controllingu a managementu hranic.
Nakonec se dostal ke svým programátorům – ve společnosti byli 3 lidé. Povídal o managementu hranic, o controllingu, o řízení kvality, o agile a scrumu… A k jeho překvapení všichni rozuměli, a dokonce s ním mohli nějak diskutovat, včetně technických a metodických nuancí. Pochopili, proč projekty týkající se skladu a zásobování vyšly. A tady chlapce osvítlo: ve skutečnosti svět zachrání programátoři.
Programátoři, pochopil, jsou jedniní, kdo se mohou normálně, s potřebnou detailností, ponořit do obchodních procesů.
Proč právě oni? Ve skutečnosti na tuto otázku nenašel jednoznačnou odpověď. Formuloval pouze teze jako náznaky.
Za prvé, programátoři znají oborové specifika byznysu a to lépe než ostatní lidé ve firmě.
Kromě toho programátoři skutečně chápou, co znamená algoritmus procesu. To je důležité, protože byznysové procesy jsou algoritmy a prvky v nich mohou být zcela nesouhlasné. Například v procesu nákupu, na kterém ten chlapec pracoval, je prvním krokem sestavení ročního plánu nákupů a druhým – každodenní nákup. Tyto kroky jsou spojeny přímým vztahem, což znamená, že podle tohoto algoritmu by lidé měli pracovat – sestavit roční plán nákupů a ihned vykonat objednávku. Roční plán nákupů se sestavuje jednou za rok, zatímco objednávky přicházejí 50krát za den. Na tomto algoritmu to končí a podle něj je třeba pracovat. O skutečnosti, uvažoval, je pro programátory znalost algoritmů konkurenční výhodou, protože každý jiný člověk, který je nezná, prostě nechápe, jak byznysový proces má fungovat a jak to lze ztvárnit.
Další výhodou programátorů, dle slov toho chlapce, je, že mají dostatek volného času. Všichni chápeme, jak programátor může strávit na úkolu třikrát více času, než to ve skutečnosti vyžaduje, a málokdo si toho všimne. To je opět konkurenční výhoda, protože pro to, aby bylo možné upravit nějaký byznysový proces, je potřeba mít hodně volného času — přemýšlet, pozorovat, zkoumat a vyzkoušet.
Většina manažerů, podle slov toho chlapce, toto volné čas nemá a pyšní se tím. Ačkoli to ve skutečnosti znamená, že člověk nemůže být efektivní, protože nemá čas na zvyšování efektivity — uzavřený kruh. V naší kultuře je módní být zaneprázdněn, takže vše zůstává na svém místě. A pro nás, programátory, je to výhoda. Můžeme najít volný čas a o všem přemýšlet.
Programátoři, říkal, mohou rychle změnit informační systém. To není možné ve všech podnicích, ale všude, kde pracoval, mohli provádět jakékoli úpravy, které si přáli. Zvlášť pokud se to netýkalo práce někoho jiného. Například mohl spustit systém, který tajně měří aktivity uživatelů, a poté tuto informaci využít — k analýze efektivity práce účetní a sledování nákladů na vedení účetnictví.
A poslední, co jsem si zapamatoval z jeho slov – programátoři mají přístup k velkému množství informací, protože mají administrativní přístup k systému. Mohou tedy tímto způsobem využívat tyto informace ve svých analýzách. Nikdo jiný v běžné továrně nemá takové zdroje.
A pak odešel. Během dvoutýdenní výpovědní lhůty jsme ho donutili podělit se o zkušenosti, protože jsme chtěli pokračovat v jeho práci. A samozřejmě se jeho pozice stala volnou.
Během několika dní jsme ho posadili na židli, zapnuli kameru a natáčeli jeho monology. Prosili jsme ho, aby mluvil o všech dokončených projektech, metodách, přístupech, úspěších a neúspěších, příčinách a následcích, portétech vedoucích atd. Nepřeháněli jsme to s omezeními, protože jsme nevěděli, co má v hlavě.
V monologech samozřejmě většinou bylo spousta nesmyslů a legrace — byl ve skvělé náladě, protože opouštěl zapadlou oblast a směrem do Petrohradu. A kam se jít pracovat v Petrohradu? Do Gazpromu, samozřejmě.
Ale podařilo se nám vytáhnout i něco užitečného z jeho monologů. Pověděl bych, co si pamatuji.
Takže, doporučení toho kluka. Pro ty, kteří chtějí zkusit udělat pořádek v business procesech.
Aby se člověk mohl takové práci věnovat, je především potřeba mít určitou úroveň "otrmovanosti". Nesmíte se bát ztratit práci, nebát se riskovat, nebát se konfliktů s kolegy. On to zvládal snadno, protože začal svou cestu, když v jaké společnosti pracoval teprve půl roku, a nestihl se s nikým seznámit, a ani neměl v úmyslu to dělat. Chápal, že lidé přicházejí a odcházejí, a pro něj byly důležité pouze jeho výsledky a jejich hodnocení majitelem firmy. To, jestli byli kolegové k němu dobří nebo špatní — to ho tehdy moc nezajímalo.
Druhým bodem je, že abyste se této práci efektivně věnovali, bohužel se budete muset učit. Ale učit se ne na MBA, ne na kurzech, ne na vysokých školách, ale samostatně. Například ve svém prvním projektu týkajícím se skladu jednal intuitivně, nic nevěděl, pouze co je "řízení kvality".
Když začal číst literaturu o metodách zvyšování efektivity, zjistil, jaké technologie používal. Chlapec je intuitivně používal, a prý to nebyla jeho vynález, všechno už bylo dávno napsáno. Ale ztratil čas, a mnohem víc, než kdyby si hned přečetl potřebnou knihu. Důležité je pochopit, že když se učíte konkrétní metodiku, žádná z nich, i ta nejpokročilejší, nevyřeší všechny problémy obchodního procesu.
Druhou zajímavostí je, že čím více metodik znáte, tím lépe. Například ve starověké Japonsku žil Miyamoto Musashi – jeden z nejznámějších šermířů, autor stylu dvou mečů. Učil se v nějaké škole u nějakého mistra, pak cestoval po Japonsku a bojoval s různými lidmi. Pokud byl někdo silnější, cestování na nějakou dobu přestalo a Musashi šel pod učení. Výsledkem bylo, že během několika let získal dovednosti různých praktik od různých mistrů a vytvořil si vlastní školu, přidávajíc něco svého. Nakonec se mu podařilo dosáhnout jedinečné dovednosti. Tady je to stejné.
Samozřejmě, můžete jednat jako obchodní konzultanti. Obecně, jsou to skvělí lidé. Ale obvykle přicházejí, aby zavedli nějakou metodiku, a zavádějí ne tu metodiku, která je potřeba pro podnik. I my jsme měli takové smutné situace: nikdo neví, jak problém vyřešit a nikdo nechce přemýšlet, jak to udělat. Začínáme hledat buď na internetu, nebo si voláme konzultanta, a ptáme se ho, co nám může pomoci. Konzultant přemýšlí a říká, že je potřeba zavést teorii omezení. Platíme mu za doporučení, investujeme do zavedení, ale výsledek je nulový.
Proč se to tak děje? Protože konzultant řekl, že zavádíme takový systém, a všichni s ním souhlasili. Skvěle, ale jedna metodika neřeší všechny problémy ani jednoho obchodního procesu, zvlášť pokud se neshodují výchozí předpoklady – naše a ty, které jsou potřebné pro zavedení metodiky.
V praxi, kterou doporučuje ten kluk, je důležité vzít to nejlepší a implementovat to nejlepší. Neberte metody v celku, ale zaměřte se na jejich klíčové vlastnosti, triky a praktiky. A co je nejdůležitější – je třeba pochopit podstatu.
Vezměme si, říkal, příklad scrumu nebo agile. V jeho monolozích se mnohokrát opakoval, že ne všichni úplně rozumí podstatě scrumu. Také četl knihu Jeffa Sutherlanda, kterou někteří považují za "snadné čtení". Pro něj byla hlubokým čtením, protože jednu z základních principů scrumu – řídění kvality – napsal v knize přímo.
Je tam napsáno o Toyota Production, jak Jeff Sutherland prezentoval scrum v Japonsku, jak se tam zabydlel a jak byl blízký jejich filozofii. A Sutherland hovořil o důležitosti role scrum mastera, o Demingově cyklu. Role scrum mastera spočívá v neustálém zrychlování procesu. Vše ostatní, co je ve scrumu – fáze dodání, spokojenost zákazníků, jasný seznam prací na období sprintu – je také důležité, ale to všechno by se mělo pohybovat stále rychleji a rychleji. Rychlost práce by měla neustále růst v těch jednotkách, ve kterých se měří.
Možná je to zde věcí překladu, protože u nás knihu přeložili jako „Scrum – revoluční metoda řízení projektů“, ale pokud přeložíme anglický název doslovně, dostaneme: „Scrum – dvakrát více za polovinu času“, tedy i v názvu se odkazuje na rychlost jako klíčovou funkci scrumu.
Když ten kluk zaváděl scrum, během prvního měsíce se rychlost zdvojnásobila bez jakýchkoli zvláštních změn. Našel body pro změny, modifikoval samotný scrum pro sebe, aby fungoval mnohem rychleji. Jediné, jak píší na internetu, je, že před nimi vyvstala otázka: „Zvýšili jsme rychlost dvakrát, zbývá nám pochopit, co vlastně děláme s takovou rychlostí?“. Nicméně, to je už úplně jiná oblast…
Také osobně doporučil několik metodik. Nazval je fundamentálními a zásadními.
První — boundary management.
Učí se to na „Skolkovu“, jinak tvrdí, že žádné další knihy a materiály nejsou. Měl štěstí, že mohl být na přednášce profesora z Harvardu, který se věnuje managementu hranic, a přečíst si několik článků v Harvard Business Review o pracích Erika Trista.
Management hranic říká, že je třeba vidět hranice a umět s nimi pracovat. Hranice jsou všude — mezi odděleními, mezi různými druhy práce, mezi funkcemi, mezi operativní a analytickou prací. Znalost managementu hranic neodhaluje žádné vyšší pravdy, ale umožňuje vidět realitu v trochu jiném světle — skrze prizma hranic. A tím pádem s nimi efektivně řídit — budovat tam, kde je to potřeba, a odstraňovat tam, kde překážejí.
Ale častěji mluvil o controllingu. Měl na tuto téma doslova fixaci.
Controlling, zjednodušeně řečeno, je řízení na základě čísel. Tady, říkal, je důležitá každá část definice — jak „řízení“, tak „na základě“, tak „čísel“.
U nás, říkal, je to špatné se všemi třemi složkami controllingu. Zvlášť když vezmete v úvahu, že jsou navzájem úzce propojeny, a také s dalšími částmi podnikatelského systému.
První problém jsou čísla. Je jich málo a mají nízkou kvalitu.
Podstatnou část čísel jsme tehdy brali z informačního systému 1C. Kvalita čísel v 1C, jak tvrdil, je naprosto nedostatečná. Minimálně kvůli možnosti měnit data zpětně.
Je jasné, že za to mohou vývojáři 1C, kteří jen zohledňují požadavky trhu a mentalitu domácího účetnictví. Ale pro účely controllingu je lepší změnit principy práce 1C s daty na konkrétním podniku.
Dále čísla z 1C podle jeho slov procházejí poloručním zpracováním, například pomocí Excelu. Takové zpracování také nepřidává kvalitu dat ani rychlost.
Nakonec je někdo jiný ještě kontroluje, aby náhodou nedal řediteli čísla s chybami. Výsledkem je, že čísla přicházejí k adresátům pěkná, ověřená, ale velmi pozdě. Obvykle po skončení období (měsíce, týdne atd.).
A tady, říkal, je to velmi jednoduché. Pokud čísla za leden obdržíte v únoru, už nemůžete řídit činnost za leden. Protože leden už skončil.
A pokud jsou čísla založena na účetnictví a společnost je zcela běžná s čtvrtletním podáváním DPH, pak její vedoucí dostává relativně adekvátní čísla jednou za čtvrtletí.
Dál je to jasné. Dostáváte čísla jednou za měsíc — máte možnost řídit se podle čísel (tj. provádět controlling) 12krát ročně. Pokud praktikujete čtvrtletní reporting, řídíte 4krát ročně. Plus bonus — roční reporting. Ještě jednou se chopit kormidla.
Ostatní dobu se řízení obvykle provádí naslepo.
Když (a pokud) se čísla přece jen objeví, nastává druhý problém — jak řídit na základě čísel? S tímto bodem jeho úvah jsem se tak nějak nemohl ztotožnit.
Chlapec tvrdil, že pokud vedoucí dříve neměl čísla, pak jejich uvedení vyvolá wow efekt. Bude se dívat a manipulovat s čísly všemi možnými způsoby, povolá lidi na koberec, bude vyžadovat vysvětlení a vyšetřování. Pohrávaje si s čísly, po důkladném přezkoumání, hrozivě slibuje všem zaměstnancům, že 'teď už vás nenechám na pokoji', vedoucí se velmi rychle uklidní a této záležitosti se vzdá. Nástroj přestane používat. A problémy zůstanou na svém místě.
Tak to prý je, říkal, kvůli nedostatečným kompetencím vedoucího. Především v controllingu. Vedoucí prostě neví, co s těmito čísly dělat. Co sdělat — ví, co dělat — ne. Udělat — to je to, co je napsáno výše (pohádat se, pohrát si). Dělat — to je každodenní obchodní proces.
Tvrdil, že je to velmi jednoduché: číslo by mělo být součástí obchodního procesu. V obchodním procesu by mělo být jasně uvedeno: kdo, co a kdy by měl udělat při odchylce čísla od normy (jakékoli varianty — nad hranicí, pod hranicí, výstup za koridor, přítomnost trendu, nedodržení kvantilu atd.)
A tady vymezil klíčovou dilematu: číslo je, mělo by se stát součástí obchodního systému, aby se zefektivnilo řízení, ale... to se neděje. Proč?
Protože ruský vedoucí nepředá konkurentovi kousek své moci.
Konkurenti ruského vedoucího — kvalitní a fungující obchodní proces, promyšlená vzájemně výhodná motivace a správná automatizace — bohužel, ponechají vedoucího bez práce.
Není to absurdní, souhlasíte? Zejména když mluvil o vedoucích pracovnících. Dobře, já jsem to řekl, nyní se rozhodněte sami.
O něco méně, ale přesto příliš mnoho, podle mě, mluvil o scrumu.
Určitě, říkal, přečtěte si o scrumu a vyzkoušejte to v praxi. Pokud jste, říká, četli, ale nezkusili, považujte se za neznalé. Je lepší číst knihu, například od Sutherland, než články a různé příručky (co to za nesmysl?) na internetu.
Scrum, říkal, se poznává jen praxí a s povinným měřením objemu vykonané práce. Osobně vyzkoušejte dvě nejdůležitější role – vlastníka produktu a scrum mastera.
Zvlášť důležité, podle jeho slov, je na vlastní kůži pocítit roli scrum mastera, když můžete zvýšit objem úloh uzavřených za sprint, aniž byste zvyšovali zdroje a náklady na sprint.
A ještě měl ve svém topu TOC (teorie omezení systémů).
To jsou, podle jeho slov, základní, fundamentální principy zvyšování efektivity, které lze použít prakticky v jakékoli oblasti, v jakémkoli podnikatelském procesu a v podnikatelském systému jako celku.
Když zjistil, že neznáme TOC, přestal vyprávět. Jen dodal, že nás neochudí o potěšení číst knihy Eliyahu Goldratta. Doporučil podobné scrumu - přečtěte si a vyzkoušejte. Bez ohledu na to, na jaké pozici jste, nebo jakou práci vykonáváte, tam najdete místo pro zvyšování efektivity metodami TOC.
Pak, zdá se, mu došly metodiky, a řekl: směšujte principy pro vytváření aplikačních řešení v konkrétní situaci.
To, říká, je hlavní doporučení, klíč k úspěchu. Pochopte principy, podstatu a vytvářejte unikátní aplikační řešení — podnikatelské procesy a podnikatelské systémy.
Pak se snažil vzpomenout na nějaký citát, nakonec musel hledat na internetu. Ukázalo se, že citát pochází z článku „Stojí na bedrech obrů“ Eliyahu Goldratta:
„Existuje rozdíl mezi aplikačními řešeními a fundamentálními koncepty, na kterých jsou tato řešení založena. Koncepty jsou obecným rámcem, aplikační řešení představují adaptaci těchto konceptů do konkrétního prostředí. Jak jsme již viděli, taková adaptace není jednoduchá a vyžaduje vývoj určitých prvků řešení. Musíme mít na paměti, že aplikační řešení vychází z předpokladů (někdy skrytých) o konkrétním prostředí. Nelze očekávat, že toto aplikační řešení bude fungovat v prostředí, pro které jsou předpoklady nesprávné.“
Řekl, že práce programátora a „vylepšovače obchodních procesů“ je velmi podobná. A odešel.
Zdroj: habr.com
