Příběh je skutečný, vše jsem viděl na vlastní oči.
Několik let jeden člověk, stejně jako mnoho z vás, pracoval jako programátor. Pro jistotu to napíšu takto: „programátor“. Protože byl 1Snik, na fix, produkční společnosti.
Předtím zkoušel různé speciality - 4 roky ve Francii jako programátor, projektový manažer, dokázal absolvovat 200 hodin, zároveň dostávat procenta z projektu, na řízení a trochu prodeje. Zkoušel jsem vyvíjet produkty sám, byl jsem vedoucím IT oddělení ve velké firmě se 6 tisíci lidmi, zkoušel jsem různé možnosti využití mé kótované profese - 1C programátor.
Ale všechny tyto pozice byly poněkud slepé, především z hlediska příjmů. Všichni jsme tehdy dostávali přibližně stejné peníze a pracovali za stejných podmínek.
Tenhle chlapík přemýšlel, jak by mohl vydělat více peněz, aniž by prodával nebo zakládal vlastní firmu.
Považoval se za chytrého chlapa a rozhodl se najít místo ve společnosti, kde pracoval. Tento výklenek musel být něčím zvláštní, nikdo ho nezabíral. A chtěl jsem, aby sama společnost chtěla vyplatit peníze osobě v tomto výklenku, aby nebylo třeba nikoho podvádět nebo něco podvádět. Abychom dosáhli tohoto cíle: člověk v této pozici musí dostat hodně peněz. Jedním slovem výstředník.
Hledání bylo krátkodobé. Ve společnosti, kde tento člověk pracoval, bylo zcela volné místo, které by se dalo nazvat „uvedení věcí do pořádku v obchodních procesech“. Každá firma má spoustu problémů. Vždy něco nefunguje a není nikdo, kdo by přišel opravit obchodní proces. Proto se rozhodl vyzkoušet jako specialista, který může majiteli pomoci vyřešit jeho problémy v obchodních procesech.
V té době ve firmě pracoval šest měsíců a pobíral průměrnou mzdu na trhu. Nebylo co ztratit, tím spíše, že stejnou práci mohl snadno najít během jednoho týdne. Obecně se tento chlápek rozhodl, že se nestane nic špatného, pokud najednou nic nevyjde a bude vyhozen.
Sebral odvahu a přišel k majiteli. Navrhl jsem mu, aby zlepšil nejproblematičtější proces v podnikání. Tehdy to bylo skladové účetnictví. Nyní se každý, kdo v této firmě pracuje, dokonce stydí na tyto problémy vzpomínat, ale čtvrtletní inventury vykazovaly nesrovnalosti mezi účetním systémem a skutečnými stavy v řádu desítek procent. A to v ceně, v množství a v počtu pozic. Byla to katastrofa. Správné zůstatky měla firma v účetním systému skutečně jen čtyřikrát do roka – den po inventuře. Náš chlap začal tento proces dávat do pořádku.
Chlápek se dohodl s majitelem, že by měl snížit odchylky od výsledků inventury na polovinu. Majitel navíc neměl co ztratit, protože před naším hrdinou se již různí pracovníci pokoušeli vše opravit a obecně byl úkol považován za prakticky neřešitelný. To vše značně podnítilo zájem, protože pokud by vše klaplo, pak by se z frajera automaticky stal člověk, který umí dělat pořádek a řešit neřešitelné problémy.
Byl tedy postaven před úkol: snížit odchylky na základě výsledků inventury 2krát do roka. Na začátku projektu neměl ponětí, jak toho dosáhnout, ale pochopil, že skladové účetnictví je jednoduchá věc, a tak bude stále schopen dělat něco užitečného. Snížit odchylky z desítek procent na desítky procent se navíc nezdá být tak složité. Každý, kdo pracoval v poradenství nebo podobných činnostech, chápe, že většinu procesních problémů lze vyřešit poměrně jednoduchými kroky.
Od ledna do května něco připravil, něco málo zautomatizoval, přepsal obchodní proces skladového účetnictví, změnil pracovní postupy skladníků, účetních a celkově předělal celý systém, aniž by komukoli něco ukazoval nebo říkal. V květnu všem rozdal nové instrukce a po první inventuře roku začal nový život – práce podle jeho pravidel. Aby bylo možné pozorovat výsledky, společnost v budoucnu začala provádět inventury častěji - jednou za dva měsíce. Již první výsledky byly pozitivní a do konce roku se odchylky od výsledků auditu snížily na zlomek jednoho procenta.
Úspěch byl kolosální, ale v jeho udržitelnost se nedalo věřit. Sám chlap pochyboval, že by výsledek zůstal zachován, kdyby ustoupil stranou a přestal proces pozorovat. Přesto se dostavil výsledek a chlap dostal vše, na čem se s majitelem dohodl. Poté se po několika letech potvrdila stabilita výsledku - několik let se odchylky držely do 1 %.
Poté se rozhodl experiment zopakovat a navrhl majiteli zlepšit další problematický proces – zásobování. Byly nedostatky, které nám neumožňovaly dodávat objemy, které naši zákazníci chtěli. Dohodli jsme se, že do roka se deficity sníží na polovinu a ten chlap také dokončí 10-15 projektů souvisejících s 1C - na automatizaci různých obchodních procesů a jiných herezí.
Ve druhém roce bylo vše opět úspěšně dokončeno, deficity poklesly více než 2x, všechny IT projekty byly úspěšně dokončeny.
Protože plat již plně uspokojoval všechny potřeby toho chlapa na dva roky dopředu, rozhodl se trochu usadit, uklidnit se a posedět v útulném, teplém místě, které si sám vytvořil.
Jaké to bylo? Formálně byl ředitelem IT. Ale kdo ve skutečnosti byl, je těžké pochopit. Ostatně, co dělá ředitel IT? Zpravidla spravuje IT infrastrukturu, řídí systémové administrátory, implementuje ERP systém a účastní se jednání představenstva.
A tento chlápek měl jednu z klíčových povinností podílet se na procesech změn, a to hlavně - generování, iniciování těchto procesů, hledání a návrhy řešení, aplikace nových manažerských technik, zkoumání navrhovaných změn, analýza efektivity dalších funkcí a divize a v neposlední řadě přímou účast na strategickém rozvoji podniku až po samostatné vypracování strategického plánu pro celou společnost.
Dostal carte blanche. Mohl přijít na jakoukoli schůzku, kam předtím neměl přístup. Seděl jsem tam s poznámkovým blokem, něco si zapisoval nebo jen poslouchal. Mluvil jen zřídka. Pak si začal hrát na telefonu a tvrdil, že asociativní paměť takto funguje lépe.
Na schůzce jen zřídka poskytl něco užitečného. Odešel, přemýšlel, pak přišel dopis - buď s kritikou, nebo s názorem, nebo s návrhy, nebo s popisem řešení, která už použil.
Častěji ale svolával porady sám. Našel jsem problém, přišel s řešením, identifikoval zainteresované strany a přivedl všechny na schůzku. A pak – jak nejlépe uměl. Přesvědčil, motivoval, dokazoval, argumentoval, dosahoval.
Neoficiálně byl považován za třetí osobu ve firmě, hned po majiteli a řediteli. Samozřejmě strašně rozzuřil všechny „osoby společnosti“, počínaje číslem 4. Zejména svými roztrhanými džínami a světlými tričky a také časem, kdy byl majitelem.
Majitel mu dával 1 hodinu denně. Každý den. Povídali si, diskutovali o problémech, řešeních, nových byznysech, oblastech rozvoje, ukazatelích a efektivitě, osobním rozvoji, knihách a prostě o životě.
Ale ten chlap byl zvláštní. Je to jako, sedněte si a buďte šťastní, život je dobrý. Ale ne. Rozhodl se přemýšlet.
Uvažoval: proč mu to vyšlo, ale ostatním ne? Majitel na něj také tlačil: řekl, že chce, aby i ostatní mohli nastolit pořádek, protože manažerů je mnoho, ti se zpravidla věnují operativnímu řízení a strategickému plánování, ale prakticky nikdo se nezabývá systémovými změnami. v jejich procesech. V popisu práce mohou mít napsáno, že by měli svůj proces zrychlit a zvýšit jeho efektivitu, ale ve skutečnosti to nikdo nedělá. proč tomu tak je? Ten chlap se také začal zajímat o to, proč, a šel si promluvit se všemi těmito manažery.
Přišel za zástupcem ředitele pro kvalitu a navrhl zavést Shewhartovy regulační diagramy, aby produkty byly lepší než japonské. Ukázalo se ale, že kolega nevěděl, co jsou Shewhartovy regulační diagramy, co je statistická procesní regulace, a o použití Demingova cyklu v řízení kvality pouze slyšel. OK…
Šel za dalším zástupcem ředitele a navrhl zavedení controllingu. Ale ani tady jsem nenašel podporu. O něco později se dozvěděl o boundary managementu (boundary management) a navrhl všem zástupcům ředitele implementovat systémovou část této metodiky za účelem zlepšení procesů. Ale bez ohledu na to, jak moc náš chlap mluvil, nikomu se moc nechtělo vrtat do toho, o čem to bylo. Možná je to nezajímalo nebo to bylo příliš těžké. Ale ve skutečnosti na to nikdo nepřišel.
Obecně mluvil o všem, co znal a používal ve firmě. Nikdo mu ale nerozuměl. Stále nechápou, proč se například vše opravovalo ve skladovém účetnictví a co s tím má společného controlling a správa hranic.
Nakonec se dostal ke svým programátorům - zaměstnanci zahrnovali 3 lidi. Mluvil o boundary managementu, o controllingu, o managementu kvality, o agilu a scrumu... A kupodivu všemu rozuměli, a dokonce s ním dokázali jakžtakž diskutovat, včetně technických a metodických jemností. Pochopili, proč se projekty skladů a zásobování osvědčily. A pak to chlapovi došlo: ve skutečnosti programátoři zachrání svět.
Uvědomil si, že programátoři jsou jediní, kdo dokáže porozumět obchodním procesům normálně, s nezbytnými detaily.
proč oni? Ve skutečnosti nikdy nenašel jasnou odpověď. Formuloval jsem pouze teze.
Za prvé, programátoři znají předmět podnikání a znají je lépe než všichni ostatní lidé ve společnosti.
Kromě toho programátoři skutečně chápou, co je procesní algoritmus. To je důležité, protože obchodní procesy jsou algoritmy a prvky v nich jednoduše nemusí být konzistentní. Například v procesu nákupu, na kterém ten chlap pracoval, bylo prvním krokem vytvoření ročního nákupního plánu a druhým denní nákup. Tyto kroky jsou propojeny přímým spojením, to znamená, že se předpokládá, že lidé by měli pracovat podle tohoto algoritmu - sestavit roční plán nákupu a okamžitě provést požadavek. Roční plán veřejných zakázek se sestavuje jednou ročně a žádosti jsou přijímány 50krát denně. Zde algoritmus končí a je třeba na něm pracovat. Ve skutečnosti usoudil, že pro programátory je znalost algoritmů konkurenční výhodou, protože kdokoli jiný, kdo je nezná, jednoduše nechápe, jak by měl obchodní proces fungovat a jak jej lze reprezentovat.
Další výhodou programátorů je podle chlapíka to, že mají dostatek volného času. Všichni chápeme, jak může programátor na úkolu strávit třikrát déle, než ve skutečnosti vyžaduje, a málokdo si toho všimne. To je opět konkurenční výhoda, protože k tomu, abyste si dali nějaký obchodní proces do pořádku, potřebujete mít spoustu volného času – přemýšlet, pozorovat, studovat a zkoušet.
Většina manažerů podle chlapíka tento volný čas nemá a jsou na něj hrdí. I když to ve skutečnosti znamená, že se člověk nemůže stát efektivním, protože nemá čas na zlepšení účinnosti - začarovaný kruh. V naší kultuře je módní být zaneprázdněn, takže vše zůstává při starém. A pro nás programátory je to výhoda. Umíme si najít volný čas a přemýšlet o všem.
Programátoři, řekl, mohou rychle změnit informační systém. Neplatí to ve všech podnicích, ale kdekoli pracoval, mohl provádět jakékoli úpravy, které chtěl. Zvláště pokud se netýkají cizí práce. Mohl by například spustit systém, který by tajně měřil akce uživatelů, a pak tyto informace použít k analýze efektivity stejného účetního oddělení a sledování nákladů na účetnictví.
A poslední, co si z jeho slov pamatuji, je, že programátoři mají přístup k velkému množství informací, protože... mít administrátorský přístup do systému. Proto mohou tyto informace použít ve své analýze. Nikdo jiný v běžné továrně takový zdroj nemá.
A pak odešel. Během požadované dvoutýdenní vazby jsme ho donutili podělit se o své zkušenosti, protože jsme chtěli pokračovat v práci, kterou dělal. No a jeho místo se uvolnilo.
Během několika dní ho posadili na židli, zapnuli kameru a nahráli jeho monology. Požádali nás, aby nám řekli o všech dokončených projektech, metodách, přístupech, úspěších a neúspěších, příčinách a následcích, portrétech manažerů atd. Neexistovala žádná zvláštní omezení, protože Nevěděli, co se mu honí hlavou.
Monology byly samozřejmě většinou samé nesmysly a smích – měl skvělou náladu, protože odjížděl z vnitrozemí do Petrohradu. Kam byste měli jít pracovat v Petrohradu? Samozřejmě do Gazpromu.
Ale podařilo se nám z jeho monologů vytěžit něco užitečného. Řeknu vám, co si pamatuji.
Takže doporučení toho chlapa. Pro ty, kteří se chtějí pokusit dát věci do pořádku v obchodních procesech.
Chcete-li dělat tento druh práce, musíte mít určitou úroveň „omrzliny“. Neměli byste se bát ztráty zaměstnání, nebát se riskovat, nebát se konfliktů s kolegy. Bylo to pro něj snadné, protože svou cestu začal, když ve firmě pracoval pouhých šest měsíců a neměl čas s nikým přijít do styku a ani to neměl v úmyslu. Pochopil, že lidé přicházejí a odcházejí, ale důležité jsou pro něj jeho vlastní výsledky a jejich posouzení majitelem firmy. Zda se k němu kolegové chovali dobře nebo špatně, ho tehdy příliš nezajímalo.
Druhým bodem je, že abyste tuto práci mohli efektivně dělat, budete bohužel muset studovat. Ale nestudujte na MBA, ne v kurzech, ne v ústavech, ale sami. Například ve svém prvním projektu, projektu skladu, jednal intuitivně, nevěděl nic, jen co je to „řízení kvality“.
Když začal číst literaturu o tom, jaké metody zvyšování efektivity existují, objevil technologie, které používal. Ten chlap je aplikoval intuitivně, ale ukázalo se, že to nebyl jeho vynález, vše už bylo dávno napsáno. Ale strávil čas a mnohem víc, než kdyby si hned přečetl správnou knihu. Zde je důležité pouze pochopit, že když studujete konkrétní techniku, ani jedna z nich, ani ta nejpokročilejší, zcela nevyřeší všechny problémy obchodního procesu.
Druhým trikem je, že čím více technik znáte, tím lépe. Například ve starověkém Japonsku žil Mijamoto Musashi, jeden z nejznámějších šermířů, autor stylu dvou mečů. Studoval na nějaké škole u nějakého mistra, pak cestoval po Japonsku, bojoval s různými chlápky. Pokud byl ten chlap silnější, cesta se na nějakou dobu zastavila a Musashi se stal studentem. Výsledkem bylo, že během několika let získal dovednosti různých praktik různých mistrů a vytvořil si vlastní školu a přidal něco vlastního. Díky tomu dosáhl jedinečné dovednosti. Tady je to stejné.
Můžete samozřejmě působit jako obchodní poradci. Obecně jsou to skvělí kluci. Ale zpravidla přijdou zavést nějakou metodologii a zavedou špatnou metodologii, kterou podnik potřebuje. Měli jsme i takové smutné situace: nikdo neví, jak problém vyřešit a nikdo nechce přemýšlet, jak ho vyřešit. Začneme hledat buď na internetu, nebo zavoláme konzultantovi a zeptáme se ho, co nám může pomoci. Konzultant se zamyslí a řekne, že musíme zavést teorii omezení. Platíme mu za jeho doporučení, utrácíme peníze za realizaci, ale výsledky jsou nulové.
Proč se to děje? Protože poradce řekl, zavádíme takový a takový systém a všichni s ním souhlasili. Skvělá, ale jedna metodika nepokryje všechny problémy ani jednoho podnikového procesu, zvláště pokud se prvotní předpoklady – naše a ty, které jsou nutné k implementaci metodiky – neshodují.
V praxi, kterou chlap doporučuje, je třeba vzít to nejlepší a implementovat to nejlepší. Neberte metody úplně, ale vezměte jejich klíčové vlastnosti, vlastnosti a postupy. A nejdůležitější je pochopit podstatu.
Vezměte si, řekl, například Scrum nebo Agile. Chlapík ve svých monolozích mnohokrát opakoval, že ne každý plně chápe podstatu Scrumu. Četl také knihu Jeffa Sutherlanda, kterou někteří lidé považují za „lehkou četbu“. Připadalo mu to jako hluboké čtení, protože jedním ze základních principů Scrumu je management kvality, to je napsáno přímo v knize.
Píše o produkci Toyota, o tom, jak Jeff Sutherland ukázal Scrum v Japonsku, jak se tam uchytil a jak blízko to bylo jejich filozofii. A Sutherland mluvil o důležitosti role Scrum Mastera, o Demingově cyklu. Úkolem Scrum Mastera je neustále urychlovat proces. Vše ostatní, co je ve Scrumu – fázové dodávky, spokojenost zákazníků, přehledný seznam práce na období sprintu – je také důležité, ale to vše se musí pohybovat stále rychleji. Rychlost práce se musí neustále zvyšovat v jednotkách, ve kterých se měří.
Možná jde o překlad, protože naše kniha byla přeložena jako „Scrum – revoluční metoda projektového řízení“, a pokud bude anglický název přeložen doslovně, vyjde to: „Scrum – dvakrát tolik za polovinu času“ , tedy i v Název odkazuje na rychlost jako klíčovou funkci Scrumu.
Když tento chlap implementoval Scrum, rychlost se během prvního měsíce zdvojnásobila bez jakýchkoli významných změn. Našel body pro změnu a upravil samotný Scrum, aby fungoval mnohem rychleji. Jediné, co na internetu píší, je, že byli postaveni před otázku: „Zdvojnásobili jsme rychlost, zbývá jen pochopit, co při takové rychlosti děláme?“ To je ovšem úplně jiná oblast...
Osobně také doporučil několik technik. Označil je za zásadní a zásadní.
První je správa hranic.
Učí to ve Skolkovo, podle toho chlapa neexistují žádné jiné knihy a materiály. Měl nějaké štěstí, že se zúčastnil přednášky profesora z Harvardu, který káže boundary management, a také si přečetl několik článků v Harvard Business Review o práci Erica Trista.
Boundary management říká, že musíte být schopni vidět hranice a pracovat s hranicemi. Hranic je spousta, jsou všude – mezi odděleními, mezi různými druhy práce, mezi funkcemi, mezi operativní a analytickou prací. Znalost boundary managementu neodhaluje žádné vyšší pravdy, ale umožňuje nám vidět realitu v trochu jiném světle – prizmatem hranic. A podle toho je spravujte - postavte je tam, kde je to nutné, a odstraňte je tam, kde překážejí.
Nejčastěji ale ten chlap mluvil o ovládání. Jen měl na toto téma nějaký vtípek.
Controlling je zkrátka řízení založené na číslech. Zde je podle něj důležitá každá část definice – jak „řízení“, tak „na základě“ a „čísla“.
Řekl, že jsme na tom špatně se všemi třemi složkami controllingu. Zejména s ohledem na to, že jsou úzce propojeny jak mezi sebou, tak s ostatními částmi obchodního systému.
První věc, která je špatná, jsou čísla. Je jich málo a jsou nekvalitní.
Značnou část čísel jsme pak převzali z informačního systému 1C. Takže kvalita čísel v 1C, jak tvrdil, není dobrá. Minimálně kvůli možnosti zpětně měnit data.
Je jasné, že to není chyba vývojářů 1C – berou v úvahu pouze požadavky trhu a mentalitu tuzemského účetnictví. Pro účely controllingu je ale lepší změnit principy práce 1C s daty u konkrétního podniku.
Dále čísla z 1C podle něj procházejí polomanuálním zpracováním, například pomocí Excelu. Takové zpracování také nepřidá datům kvalitu, stejně jako efektivitu.
Nakonec někdo jiný zkontroluje závěrečnou zprávu, aby náhodou nepředložil vedoucímu údaje s chybami. V důsledku toho se čísla dostávají k příjemci krásná, ověřená, ale velmi pozdě. Obvykle - po skončení období (měsíc, týden atd.).
A tady, řekl, je všechno velmi jednoduché. Pokud vám čísla o lednu přišla v únoru, tak lednové aktivity už nezvládáte. Protože leden už skončil.
A pokud čísla vycházejí z účetnictví a firma je tou nejobyčejnější, se čtvrtletním podáváním DPH, tak její manažer dostává jednou za čtvrtletí relativně adekvátní čísla.
Zbytek je jasný. Čísla dostáváte 12x měsíčně - máte možnost řídit podle čísel (tedy kontrolovat) 4x ročně. Pokud praktikujete čtvrtletní reporting, zvládnete to XNUMXx ročně. Plus bonus - roční hlášení. Řídit ještě jednou.
Ve zbytku času se kontrola obvykle provádí naslepo.
Když (a pokud) se čísla objeví, pak přichází na řadu druhý problém – jak na základě čísel hospodařit? S tímto bodem jeho úvahy jsem nemohl souhlasit.
Ten chlap tvrdil, že pokud manažer předtím neměl čísla, jejich vzhled by způsobil wow efekt. Bude se dívat a překrucovat čísla tak a tak, obvolávat lidi na koberci, požadovat vysvětlení a vyšetřování. Poté, co si manažer pohrál s čísly, provedl analýzu a výhružně slíbil všem zaměstnancům, že „teď se vás nezbavím“, se velmi rychle uklidní a vzdá se této záležitosti. Přestaňte nástroj používat. Problémy ale zůstanou na svém místě.
Děje se tak podle něj kvůli nedostatečným manažerským kompetencím. Především v controllingu. Manažer prostě neví, co s těmito čísly dělat. Co сdělat - ví, co dělat - ne. Dělat je to, o čem je psáno výše (hádat se, hrát si). Dělání je každodenní obchodní proces.
Tvrdil, že vše je velmi jednoduché: digitální se musí stát součástí obchodního procesu. V obchodním procesu by mělo být jasně jasné: kdo by měl co dělat a kdy, pokud se čísla odchylují od normy (jakékoli možnosti - nad hranicí, pod hranicí, překročení koridoru, přítomnost trendu, nesplnění kvantil atd.)
A tak nastínil klíčové dilema: číslo existuje, mělo by se stát součástí podnikového systému, aby se zvýšila efektivita řízení, ale... to se neděje. Proč?
Protože ruský vůdce neodevzdá kus své moci konkurentovi.
Konkurenti ruského manažera - kvalitní a fungující obchodní proces, promyšlená oboustranně výhodná motivace a správná automatizace - bohužel nechají manažera bez práce.
Nějaký nesmysl, nesouhlasíš? Zejména o vůdcích. Dobře, říkal jsem ti, rozhodni se sám.
O něco méně, ale stále příliš, podle mého názoru mluvil o Scrumu.
Buďte si jisti, řekl jsem, přečtěte si a vyzkoušejte Scrum v praxi. Pokud jste to podle něj četli, ale nezkoušeli, považujte se za ignoranta. Je lepší si přečíst knihu, třeba od Sutherlanda, než články a nejrůznější návody (co sakra?) na internetu.
Scrum, řekl, se lze naučit pouze praxí a povinným měřením množství vykonané práce. Osobně si vyzkoušejte dvě nejdůležitější role – Product Owner a Scrum Master.
Zvláště důležité je podle chlápka vyzkoušet si v praxi roli Scrum Mastera, kdy můžete zvýšit objem splněných úkolů na sprint, aniž byste navyšovali zdroje a náklady na sprint.
No a na jeho vrcholu byla TOS (teorie systémových omezení).
To jsou podle toho chlapíka základní, fundamentální principy zvyšování efektivity, které lze uplatnit téměř v jakékoli oblasti, v jakémkoli obchodním procesu a obchodním systému jako celku.
Když zjistil, že nejsme obeznámeni s TOS, přestal nám to říkat. Dodal pouze, že nás neochudí o potěšení ze čtení knih Eliyahu Goldratta. Podobné doporučení dal Scrumu – přečtěte si to a zkuste to. Stejně jako bez ohledu na to, na jaké pozici jste, bez ohledu na to, jakou práci děláte, existuje místo pro zvýšení efektivity pomocí metod TOC.
Pak mu zřejmě vyschl pytel technik a řekl: smíchejte principy, abyste vytvořili aplikovaná řešení v konkrétní situaci.
To je podle něj hlavní doporučení, klíč k úspěchu. Pochopte principy, podstatu a vytvořte jedinečná aplikační řešení - obchodní procesy a obchodní systémy.
Pak se pokusil zapamatovat si nějaký citát a nakonec musel jít na internet. Ukázalo se, že jde o citát z článku „Stát na ramenou obrů“ od Eliyahu Goldratta:
„Je rozdíl mezi aplikovanými řešeními (aplikacemi) a základními koncepty, na kterých jsou tato řešení založena. Koncepty jsou obecné, aplikovaná řešení jsou přizpůsobení pojmů konkrétnímu prostředí. Jak jsme již viděli, taková adaptace není jednoduchá a vyžaduje vývoj určitých prvků řešení. Musíme si uvědomit, že aplikační řešení je založeno na počátečních předpokladech (někdy skrytých) o konkrétním prostředí. Od tohoto aplikačního řešení by se nemělo očekávat, že bude fungovat v prostředí, pro které nejsou předpoklady správné.“
Řekl, že práce programátora a „zlepšovače obchodních procesů“ jsou velmi podobné. A vlevo.
Zdroj: www.habr.com