Zgodba je resnična, vse sem videl na lastne oči.
Nekaj let je en fant, kot mnogi izmed vas, delal kot programer. Za vsak slučaj bom napisal takole: "programer." Ker je bil 1Snik, na fiksu, producentsko podjetje.
Pred tem je poskusil različne specialitete - 4 leta v Franciji kot programer, vodja projektov, lahko je opravil 200 ur, hkrati pa prejel odstotek projekta, za vodenje in malo prodaje. Poskušal sem sam razvijati izdelke, bil vodja IT oddelka v velikem podjetju s 6 tisoč ljudmi, preizkusil sem različne možnosti za uporabo svojega cenjenega poklica - programerja 1C.
A vsa ta delovna mesta so bila nekoliko slepa, predvsem glede dohodkov. Takrat smo vsi prejemali približno enak denar in delali pod enakimi pogoji.
Ta tip se je spraševal, kako bi lahko zaslužil več denarja, ne da bi prodal ali ustvaril lastno podjetje.
Imel se je za pametnega fanta in se odločil, da bo našel nišo v podjetju, kjer je delal. Ta niša je morala biti nekaj posebnega, ki je ni nihče zasedel. In želel sem, da podjetje samo želi plačati denar osebi v tej niši, da ne bi bilo treba nikogar goljufati ali goljufati. Da bi dosegli ta cilj: osebo na tem položaju je treba plačati veliko denarja. Ekscentrik, z eno besedo.
Iskanje je bilo kratkotrajno. V podjetju, kjer je ta tip delal, je obstajala popolnoma prosta niša, ki bi ji lahko rekli »spravljanje stvari v poslovni proces«. Vsako podjetje ima veliko težav. Vedno nekaj ne deluje in ni človeka, ki bi prišel in uredil poslovni proces. Zato se je odločil, da se preizkusi kot strokovnjak, ki lahko lastniku pomaga pri reševanju težav v poslovnih procesih.
Takrat je bil v podjetju zaposlen že šest mesecev in prejemal povprečno plačo na trgu. Ničesar ni imel za izgubiti, še posebej, ker je isto službo zlahka našel v enem tednu. Na splošno se je ta tip odločil, da se ne bo zgodilo nič slabega, če nenadoma nič ne uspe, in je bil odpuščen.
Opogumil se je in prišel do lastnika. Predlagal sem mu, da izboljša najbolj problematičen proces v poslu. Takrat je bilo to skladiščno računovodstvo. Zdaj se je vseh, ki delajo v tem podjetju, celo sram spominjati teh težav, toda inventure, ki so jih opravljali četrtletno, so pokazale odstopanja med računovodskim sistemom in dejanskim stanjem tudi za več deset odstotkov. In v stroških, v količini in v številu položajev. Bila je katastrofa. Podjetje je dejansko imelo pravilna stanja v računovodskem sistemu le štirikrat na leto – dan po popisu. Naš fant je začel ta proces urejati.
Fant se je z lastnikom dogovoril, da odstopanja od rezultatov inventure zmanjša za polovico. Poleg tega lastnik ni imel ničesar posebnega za izgubiti, saj so pred našim junakom različni delavci že poskušali vse popraviti in na splošno je bila naloga praktično nerešljiva. Vse to je močno podžgalo zanimanje, kajti če bi se vse izšlo, bi tip samodejno postal oseba, ki zna stvari postaviti v red in rešiti nerešljive probleme.
Tako se je soočil z nalogo: zmanjšati odstopanja na podlagi inventurnih rezultatov za 2-krat v enem letu. Na začetku projekta si ni predstavljal, kako bi to dosegel, vendar je razumel, da je skladiščno knjigovodstvo preprosta stvar, zato bo še lahko naredil kaj koristnega. Še več, zmanjšati odstopanja z desetin odstotkov na eno desetino odstotkov ni tako težko. Vsakdo, ki se je kdaj ukvarjal s svetovanjem ali podobnimi dejavnostmi, razume, da je večino procesnih težav mogoče rešiti z dokaj preprostimi koraki.
Od januarja do maja je pripravil, nekaj malo avtomatiziral, prepisal poslovni proces skladiščnega knjigovodstva, spremenil poteke dela skladiščnikov, računovodij in nasploh predelal celoten sistem, ne da bi komu kaj pokazal ali povedal. Maja je vsem razdelil nova navodila in po prvi letošnji inventuri se je začelo novo življenje – delo po njegovih pravilih. Da bi opazovali rezultate, je podjetje v prihodnje začelo izvajati inventure pogosteje - enkrat na dva meseca. Že prvi rezultati so bili pozitivni, do konca leta pa so odstopanja od revizijskih rezultatov upadla na delček odstotka.
Uspeh je bil gromozanski, a človek ni mogel verjeti v njegovo trajnost. Sam je dvomil, da se bo rezultat ohranil, če se bo umaknil in nehal opazovati proces. Kljub temu je bil rezultat in fant je dobil vse, kar se je z lastnikom dogovoril. Nato je bila po nekaj letih potrjena stabilnost rezultata - več let so odstopanja ostala znotraj 1%.
Nato se je odločil poskus ponoviti in lastniku predlagal, da izboljša še en problematičen proces - dobavo. Prišlo je do pomanjkanja, ki nam ni omogočalo pošiljanja količin, ki so jih naše stranke želele. Dogovorili smo se, da se v enem letu primanjkljaji prepolovijo, fant pa bo dokončal tudi 10-15 projektov, povezanih z 1C - za avtomatizacijo različnih poslovnih procesov in drugih herezij.
V drugem letu je bilo spet vse uspešno zaključeno, primanjkljaji so se zmanjšali za več kot 2-krat, vsi IT projekti so bili uspešno zaključeni.
Ker je plača že v celoti zadovoljila vse potrebe tega fanta za dve leti vnaprej, se je odločil, da se malo umiri, umiri in se usede v prijeten, topel prostor, ki si ga je ustvaril sam.
Kako je bilo? Formalno je bil direktor informatike. A kdo je v resnici bil, je težko razumeti. Konec koncev, kaj počne direktor IT? Praviloma skrbi za IT infrastrukturo, vodi sistemske skrbnike, implementira ERP sistem in sodeluje na sejah upravnega odbora.
In ta tip je imel eno ključnih odgovornosti za sodelovanje v procesih sprememb, predvsem pa - generiranje, zagon teh procesov, iskanje in predlaganje rešitev, uporaba novih tehnik vodenja, pregledovanje predlaganih sprememb, analiza učinkovitosti drugih funkcij in divizije in končno neposredno sodelovanje pri strateškem razvoju podjetja, vse do samostojnega razvoja strateškega načrta za celotno podjetje.
Dobil je carte blanche. Lahko je prišel na kateri koli sestanek, kamor prej ni imel dostopa. Sedel sem tam z beležko, si nekaj zapisoval ali samo poslušal. Redko je govoril. Potem se je začel igrati po telefonu, češ da asociativni spomin tako bolje deluje.
Na sestanku je redko izdal kaj koristnega. Odšel je, razmišljal, potem je prišlo pismo - ali s kritiko, ali z mnenjem, ali s predlogi, ali z opisom rešitev, ki jih je že uporabil.
A pogosteje je sestanke skliceval sam. Našel sem problem, našel rešitve, identificiral zainteresirane strani in vse privabil na sestanek. In potem – kakor je znal. Prepričeval je, motiviral, dokazoval, argumentiral, dosegal.
Neuradno je veljal za tretjo osebo v podjetju, za lastnikom in direktorjem. Seveda je strašno razjezil vse “osebe podjetja”, začenši s številko 4. Predvsem s strganimi kavbojkami in svetlečimi majicami, pa tudi z lastniškim časom.
Lastnik mu je namenil 1 uro na dan. Vsak dan. Pogovarjali so se, razpravljali o problemih, rešitvah, novih poslih, področjih razvoja, kazalnikih in učinkovitosti, osebnem razvoju, knjigah in preprosto življenju.
Toda ta tip je bil čuden. Kot da se usedite in bodite srečni, življenje je dobro. Vendar ne. Odločil se je razmisliti.
Spraševal se je: zakaj je njemu uspelo, drugim pa ne? Lastnik ga je tudi priganjal: rekel je, da želi, da bi tudi drugi naredili red, ker je menedžerjev veliko, ti se praviloma ukvarjajo z operativnim vodenjem in strateškim načrtovanjem, s sistemskimi spremembami pa se tako rekoč nihče ne ukvarja. v svojih procesih. Morda jim je v opisu delovnega mesta zapisano, da bi morali pospešiti svoj proces in povečati njegovo učinkovitost, a tega dejansko nihče ne počne. Zakaj? Tudi fanta je začelo zanimati, zakaj, in je šel na pogovor z vsemi temi menedžerji.
Prišel je do namestnika direktorja za kakovost in predlagal uvedbo Shewhartovih kontrolnih kart, da bi bili izdelki boljši od japonskih. A izkazalo se je, da sodelavec ni vedel, kaj so Shewhartove kontrolne karte, kaj je statistična kontrola procesov in je samo slišal za uporabo Demingovega cikla pri vodenju kakovosti. V REDU…
Šel je do drugega namestnika direktorja in predlagal uvedbo kontrolinga. Ampak tudi tukaj nisem našel podpore. Malo kasneje je izvedel za upravljanje z mejami (border management) in predlagal, da vsi namestniki direktorjev implementirajo sistemski del te metodologije za izboljšanje procesov. A ne glede na to, koliko je naš fant govoril, se nihče ni želel poglobiti v to, za kaj gre. Mogoče jih ni zanimalo ali pa je bilo pretežko. Toda v resnici tega nihče ni ugotovil.
Na splošno je govoril o vsem, kar je poznal in uporabljal v podjetju. A nihče ga ni razumel. Še vedno jim ni jasno, zakaj so na primer vse popravljali v skladiščnem knjigovodstvu in kaj ima s tem kontroling in upravljanje meje.
Nazadnje je dosegel svoje programerje - osebje je vključevalo 3 osebe. Govoril je o boundary managementu, o kontrolingu, o managementu kakovosti, o agili in scrumu ... In presenetljivo so vse razumeli in se z njim lahko celo nekako pogovarjali, tudi o tehničnih in metodoloških tankočutnostih. Razumeli so, zakaj sta se projekta skladišča in dobave obnesla. In potem se je fantu posvetilo: pravzaprav bodo programerji rešili svet.
Programerji so, je spoznal, edini, ki lahko normalno razumejo poslovne procese s potrebnimi podrobnostmi.
Zakaj njih? Pravzaprav nikoli ni našel jasnega odgovora. Oblikoval sem samo namige za tezo.
Prvič, programerji poznajo področja poslovanja in jih poznajo bolje kot vsi drugi ljudje v podjetju.
Poleg tega programerji resnično razumejo, kaj je procesni algoritem. To je pomembno, ker so poslovni procesi algoritmi in elementi v njih morda preprosto niso skladni. Na primer, v procesu nabave, na katerem je fant delal, je bil prvi korak ustvarjanje letnega načrta nabave, drugi pa dnevna nabava. Ti koraki so povezani z neposredno povezavo, to pomeni, da bi morali ljudje delati po tem algoritmu - pripraviti letni načrt javnih naročil in takoj izvršiti zahtevo. Letni načrt nabave se oblikuje enkrat letno, vloge pa sprejemajo 50-krat na dan. Tu se algoritem konča in na njem morate delati. Pravzaprav, je razmišljal, je za programerje poznavanje algoritmov konkurenčna prednost, saj kdorkoli drug z njimi ni seznanjen, preprosto ne razume, kako bi moral poslovni proces delovati in kako ga je mogoče predstaviti.
Druga prednost programerjev je po njegovem mnenju ta, da imajo dovolj prostega časa. Vsi razumemo, kako lahko programer porabi trikrat več časa za nalogo, kot dejansko zahteva, in le redki bodo opazili. To je spet konkurenčna prednost, saj je za ureditev nekega poslovnega procesa treba imeti veliko prostega časa – razmišljati, opazovati, študirati in poskušati.
Večina menedžerjev po njegovem mnenju nima tega prostega časa in so na to ponosni. Čeprav v resnici to pomeni, da človek ne more postati učinkovit, ker nima časa za izboljšanje učinkovitosti - začaran krog. V naši kulturi je moderno biti zaposlen, zato vse ostane po starem. In za nas programerje je to prednost. Lahko najdemo prosti čas in razmislimo o vsem.
Programerji lahko po njegovih besedah hitro spremenijo informacijski sistem. To ne velja za vsa podjetja, a kjer koli je delal, je lahko naredil kakršne koli spremembe. Še posebej, če se ne nanašajo na delo drugih. Lahko bi na primer zagnal sistem, ki bi na skrivaj meril dejanja uporabnikov, nato pa s temi informacijami analiziral učinkovitost istega računovodskega oddelka in spremljal stroške računovodstva.
In zadnje, česar se spomnim iz njegovih besed je, da imajo programerji dostop do velike količine informacij, ker ... imajo administrativni dostop do sistema. Zato lahko te informacije uporabijo v svoji analizi. Nihče drug v navadnem obratu nima takšnega vira.
In potem je odšel. V zahtevanem dvotedenskem priporu smo ga prisilili, da je delil svoje izkušnje, ker smo želeli nadaljevati delo, ki ga je opravljal. No, njegovo mesto je postalo prosto.
V nekaj dneh so ga posedli na stol, prižgali kamero in posneli njegove monologe. Prosili so, da nam povedo o vseh izvedenih projektih, metodah, pristopih, uspehih in neuspehih, vzrokih in posledicah, portretih managerjev itd. Ni bilo posebnih omejitev, saj Niso vedeli, kaj se dogaja v njegovi glavi.
Monologi so bili seveda večinoma samo bedarije in smeh – bil je odlično razpoložen, saj. odhajal iz divjine v St. Petersburg. Kam bi morali iti na delo v Sankt Peterburgu? Gazpromu seveda.
Iz njegovih monologov pa nam je uspelo izluščiti nekaj uporabnega. Povedal ti bom, česa se spomnim.
Torej, priporočila tega tipa. Za tiste, ki želite poskušati narediti red v poslovnih procesih.
Za opravljanje tovrstnega dela morate najprej imeti določeno stopnjo "omrzlin". Naj vas ne bo strah izgube službe, ne bojte se tvegati, ne bojte se konfliktov s sodelavci. Zanj je bilo lahko, saj je svojo pot začel, ko je bil v podjetju zaposlen le šest mesecev in ni imel časa z nikomer priti v stik in tega tudi ni nameraval storiti. Razumel je, da ljudje pridejo in gredo, vendar so mu pomembni lastni rezultati in njihova ocena lastnika podjetja. Ali so kolegi z njim ravnali dobro ali slabo, ga takrat ni zanimalo.
Druga točka je, da se boste za učinkovito opravljanje tega dela na žalost morali učiti. Toda ne študirajte za MBA, ne na tečajih, ne na inštitutih, ampak sami. Na primer, pri svojem prvem projektu, projektu skladišča, je deloval intuitivno, vedel ni ničesar, le kaj je "vodenje kakovosti".
Ko je začel prebirati literaturo o tem, kakšne metode povečanja učinkovitosti obstajajo, je odkril tehnologije, ki jih uporablja. Fant jih je uporabil intuitivno, vendar se je izkazalo, da to ni bil njegov izum, vse je bilo napisano že zdavnaj. A porabil je čas, in to veliko več, kot če bi takoj prebral pravo knjigo. Tukaj je pomembno le razumeti, da ko preučujete določeno tehniko, nobena od njih, tudi najbolj napredna, ne bo popolnoma rešila vseh težav poslovnega procesa.
Drugi trik je, da več tehnik poznate, bolje je. Na primer, v starodavni Japonski je živel Miyamoto Musashi, eden najbolj znanih mečevalcev, avtor sloga z dvema mečema. Študiral je v neki šoli pri nekem mojstru, nato pa potoval po Japonski, se boril z različnimi tipi. Če je bil fant močnejši, se je potovanje za nekaj časa ustavilo in Musashi je postal študent. Posledično je več let pridobival veščine različnih praks različnih mojstrov in oblikoval svojo šolo ter dodal nekaj svojega. Posledično je dosegel edinstveno veščino. Tukaj je enako.
Seveda lahko delujete kot poslovni svetovalci. Na splošno so super fantje. A praviloma pridejo uvajat nekakšno metodologijo, izvajajo pa napačno metodologijo, ki jo podjetje potrebuje. Imeli smo tudi take žalostne situacije: nihče ne ve, kako rešiti problem, in nihče noče razmišljati, kako bi ga rešil. Začnemo iskati bodisi po internetu bodisi pokličemo svetovalca in ga vprašamo, kaj nam lahko pomaga. Svetovalec razmišlja in pravi, da moramo uvesti teorijo omejitev. Plačamo ga za njegovo priporočilo, porabimo denar za izvedbo, rezultati pa nič.
Zakaj se to zgodi? Ker je svetovalec rekel, uvajamo tak in tak sistem, in vsi so se strinjali z njim. Super, ampak ena metodologija ne pokrije vseh problemov niti enega poslovnega procesa, sploh če začetni predpogoji - naši in tisti, ki so potrebni za implementacijo metodologije - ne sovpadajo.
V praksi, ki jo fant priporoča, morate vzeti najboljše in implementirati najboljše. Ne jemljite metod v celoti, ampak vzemite njihove ključne značilnosti, funkcije in prakse. In najpomembnejše je razumeti bistvo.
Vzemite, je rekel, na primer Scrum ali Agile. V svojih monologih je tip večkrat ponovil, da vsi ne razumejo popolnoma bistva Scruma. Prebral je tudi knjigo Jeffa Sutherlanda, ki se nekaterim zdi "lahko branje". Zdelo se mu je kot globoko branje, saj je eno od temeljnih načel Scruma upravljanje kakovosti, to piše neposredno v knjigi.
Govori o Toyota Production, o tem, kako je Jeff Sutherland pokazal Scrum na Japonskem, kako se je tam uveljavil in kako blizu je bil njihovi filozofiji. In Sutherland je govoril o pomenu vloge Scrum Masterja, o Demingovem ciklu. Vloga Scrum Masterja je nenehno pospeševanje procesa. Vse ostalo, kar je v Scrumu - fazna dostava, zadovoljstvo strank, jasen seznam dela za obdobje sprinta - je prav tako pomembno, a vse to se mora odvijati vedno hitreje. Hitrost dela mora nenehno naraščati v enotah, v katerih se meri.
Morda je to stvar prevoda, saj je bila naša knjiga prevedena kot "Scrum - revolucionarna metoda vodenja projektov", in če angleški naslov prevedemo dobesedno, se bo izkazalo: "Scrum - dvakrat več v polovičnem času" , torej celo v Ime se nanaša na hitrost kot ključno funkcijo Scruma.
Ko je ta tip implementiral Scrum, se je hitrost podvojila v prvem mesecu brez bistvenih sprememb. Našel je točke za spremembe in sam Scrum spremenil, da je deloval veliko hitreje. Edino, kar pišejo na internetu, je, da so se soočili z vprašanjem: "Podvojili smo hitrost, ostane nam le še, da razumemo, kaj počnemo s tako hitrostjo?" Vendar je to povsem drugo področje ...
Osebno je priporočil tudi več tehnik. Imenoval jih je temeljne in temeljne.
Prvi je upravljanje meja.
To poučujejo v Skolkovu; po fantovih besedah ni drugih knjig in materialov. Imel je nekako srečo, da je obiskal predavanje profesorja s Harvarda, ki pridiga o upravljanju meja, prebral pa je tudi nekaj člankov v Harvard Business Review o delu Erica Trista.
Upravljanje meja pravi, da morate biti sposobni videti meje in delati z mejami. Mej je veliko, povsod so - med oddelki, med različnimi vrstami dela, med funkcijami, med operativnim in analitičnim delom. Poznavanje urejanja meja ne odkriva nobenih višjih resnic, ampak nam omogoča, da realnost vidimo v nekoliko drugačni luči – skozi prizmo meja. In v skladu s tem upravljajte z njimi - postavite jih, kjer je potrebno, in jih odstranite, kjer so v napoto.
Toda najpogosteje je tip govoril o nadzoru. Imel je samo nekakšno domislico na to temo.
Kontroling je skratka upravljanje s številkami. Tu je po njegovih besedah pomemben vsak del definicije – tako »upravljanje« kot »na podlagi« in »številke«.
Po njegovih besedah smo slabi z vsemi tremi komponentami kontrolinga. Še posebej glede na to, da so tesno povezani tako med seboj kot tudi z drugimi deli poslovnega sistema.
Prva stvar, ki je slaba, so številke. Malo jih je in so nizke kakovosti.
Precejšen del številk smo nato prevzeli iz informacijskega sistema 1C. Torej, kakovost številk v 1C, kot je trdil, ni dobra. Vsaj zaradi možnosti spreminjanja podatkov za nazaj.
Jasno je, da to ni krivda razvijalcev 1C - upoštevajo le zahteve trga in miselnost domačega računovodstva. Toda za namene nadzora je bolje spremeniti načela dela 1C s podatki v določenem podjetju.
Poleg tega so številke iz 1C po njegovih besedah podvržene polročni obdelavi, na primer z uporabo Excela. Takšna obdelava tudi ne dodaja kakovosti podatkov, pa tudi učinkovitosti.
Na koncu nekdo drug še enkrat preveri končno poročilo, da ne bi slučajno upravniku oddal številk z napakami. Kot rezultat, številke pridejo do prejemnika lepe, preverjene, a zelo pozno. Običajno - po koncu obdobja (mesec, teden itd.).
In tukaj, je rekel, je vse zelo preprosto. Če so vam februarja prišle številke o januarju, potem januarskih aktivnosti ne morete več upravljati. Ker januarja je že konec.
In če številke temeljijo na računovodstvu in je podjetje najbolj navadno, s četrtletno predložitvijo DDV, potem njegov vodja prejme relativno ustrezne številke enkrat na četrtletje.
Ostalo je jasno. Številke prejmete enkrat mesečno - možnost upravljanja s številkami (t.i. nadzora) imate 12-krat na leto. Če izvajate četrtletno poročanje, ga upravljate 4-krat na leto. Plus bonus - letno poročanje. Krmarite še enkrat.
Preostali čas se kontrola običajno izvaja na slepo.
Ko (in če) se številke vendarle pojavijo, nastopi drugi problem - kako upravljati na podlagi številk? S to točko njegovega sklepanja se ne morem strinjati.
Fant je trdil, da če vodja prej ne bi imel številk, bi njihov videz povzročil vau učinek. Gledal bo in obračal številke tako in tako, klical ljudi na preprogo, zahteval pojasnila in preiskave. Po igranju s številkami, opravljeni analizi in grozečim obljubam vsem zaposlenim, da se "zdaj se vas ne bom znebil", se bo vodja zelo hitro umiril in obupal nad to zadevo. Nehajte uporabljati orodje. Toda težave bodo ostale na mestu.
To se po njegovih besedah dogaja zaradi nezadostnih vodstvenih kompetenc. V kontrolingu, najprej. Upravitelj preprosto ne ve, kaj bi s temi številkami. Kaj сnarediti - ve, kaj storiti - ne. Delati je to, o čemer piše zgoraj (prepirati se, igrati). Delanje je vsakodnevni poslovni proces.
Trdil je, da je vse zelo preprosto: digital mora postati del poslovnega procesa. V poslovnem procesu mora biti jasno jasno: kdo mora kaj storiti in kdaj, če številke odstopajo od norme (poljubne možnosti - nad mejo, pod mejo, preseganje koridorja, prisotnost trenda, neizpolnjevanje kvantil itd.)
In tako orisal ključno dilemo: številka obstaja, morala bi postati del poslovnega sistema za večjo učinkovitost upravljanja, a ... to se ne dogaja. Zakaj?
Ker ruski voditelj ne bo prepustil koščka svoje moči tekmecu.
Tekmovalci ruskega menedžerja - kakovosten in delujoč poslovni proces, dobro premišljena obojestransko koristna motivacija in ustrezna avtomatizacija - žal bodo menedžerja pustili brez službe.
Nekakšna neumnost, se strinjate? Predvsem o voditeljih. V redu, sem ti rekel, odločaš se sam.
Malo manj, a še vedno preveč, je po mojem mnenju govoril o Scrumu.
Bodite prepričani, sem rekel, preberite in preizkusite Scrum v praksi. Če, pravi, ste ga prebrali, a niste poskusili, se imejte za nevednega. Bolje je prebrati knjigo, na primer Sutherlanda, kot članke in vse vrste vodnikov (kaj za vraga?) na internetu.
Scrum se je po njegovih besedah mogoče naučiti le s prakso in z obveznimi meritvami količine opravljenega dela. Osebno preizkusite dve najpomembnejši vlogi – Product Owner in Scrum Master.
Po njegovem mnenju je še posebej pomembno, da v praksi izkusite vlogo Scrum Masterja, ko lahko povečate količino opravljenih nalog na sprint, ne da bi povečali sredstva in stroške sprinta.
No, v njegovem vrhu je bil TOS (teorija sistemskih omejitev).
To so po njegovem mnenju osnovna, temeljna načela povečanja učinkovitosti, ki jih je mogoče uporabiti na skoraj vseh področjih, v katerem koli poslovnem procesu in poslovnem sistemu kot celoti.
Ko je ugotovil, da ne poznamo TOS, nam je nehal govoriti. Dodal je le, da nas ne bo prikrajšal za užitek ob branju knjig Eliyahua Goldratta. Podobno priporočilo je dal Scrumu – preberite in poskusite. Na primer, ne glede na to, na katerem položaju ste, ne glede na delo, ki ga opravljate, obstaja prostor za povečanje učinkovitosti z uporabo metod TOC.
Potem je njegova vreča tehnik očitno usahnila in rekel je: zmešajte principe, da ustvarite uporabne rešitve v specifični situaciji.
To je, pravi, glavno priporočilo, ključ do uspeha. Razumeti principe, bistvo in ustvariti edinstvene aplikativne rešitve – poslovne procese in poslovne sisteme.
Potem se je poskušal spomniti kakšnega citata, na koncu pa je moral na splet. Izkazalo se je, da gre za citat iz članka Eliyahu Goldratta »Stojati na ramenih velikanov«:
»Obstaja razlika med aplikativnimi rešitvami (aplikacijami) in temeljnimi koncepti, na katerih te rešitve temeljijo. Koncepti so splošni, aplikativne rešitve pa so prilagoditve konceptov določenemu okolju. Kot smo že videli, takšno prilagajanje ni preprosto in zahteva razvoj določenih elementov rešitve. Ne smemo pozabiti, da aplikacijska rešitev temelji na začetnih predpostavkah (včasih prikritih) o določenem okolju. Ne bi smeli pričakovati, da bo ta aplikacijska rešitev delovala v okolju, za katerega predpostavke niso pravilne.«
Povedal je, da sta si delo programerja in »izboljševalca poslovnih procesov« zelo podobna. In levo.
Vir: www.habr.com