Zgodba je resnična, vse sem videl s svojimi očmi.
Pred nekaj leti je en fant, tako kot mnogi izmed vas, delal kot programer. Za vsak primer naj napišem tako: "programer". Kajti bil je 1C programer, na fiksni plači v proizvodnem podjetju.
Pred tem je preizkusil različne specialnosti – 4 leta je delal kot programer v franchisingu, nato vodja projektov, uspel je zaključi 200 delovnih ur in hkrati prejemati provizijo z projekta, vodil projekte in se nekoliko ukvarjal s prodajo. Poskušal je razvijati izdelke samostojno, bil je vodja IT Oddelka v veliki družbi z 6000 zaposlenimi, preizkusil različne možnosti uporabe svoje "programerske" stroke 1C.
Vendar so bile vse te pozicije nekoliko brezizhodne, predvsem zaradi dohodka. Vsi smo takrat prejemali približno enak denar in delali v enakih razmerah.
Ta fant je postal radoveden, kako lahko zasluži več denarja, ne da bi se ukvarjal s prodajo in ne da bi ustvarjal svoje podjetje.
Zamislil si je, da je pameten, in se odločil najti nišo v podjetju, v katerem je delal. Ta niša bi morala biti nekakšna posebna, brez konkurence. In želel je, da bi podjetje samo želelo plačati človeku v tej niši, da ne bi bilo treba nikogar prevarati ali kaj izmišljevati. Da bi bilo to objektivno: človeku na tej poziciji je treba plačati veliko denarja. Čuden tip, lahko rečem.
Iskanje ni bilo dolgo. V podjetju, kjer je ta fant delal, je bila povsem prosta niša, ki jo lahko odzovemo kot "urejanje poslovnih procesov". V vsakem podjetju obstaja kup težav. Vedno nekaj ne deluje, in nikogar ni, ki bi prišel in popravil poslovne procese. Tako je se odločil poskusiti v vlogi specialistične, ki lahko pomaga lastniku rešiti njegove težave v poslovnih procesih.
V tistem času je delal v podjetju že pol leta in prejemal povprečno plačilo na trgu. Ničesar ni imel za izgubiti — še posebej, ker bi lahko hitro našel enako delo v enem tednu. Na splošno je ta fant presodil, da se ne bo zgodilo nič groznega, če se slučajno ne bo izšlo in ga odpustijo.
Zbral je dovolj poguma in se obrnil na lastnika. Predlagal mu je izboljšanje najbolj problematičnega procesa, ki je obstajal v poslu. Takrat je to bila skladiščna evidenca. Zdaj je vsem, ki delajo v tej družbi, celo nerodno spominjati se tistih težav, toda inventure, ki so potekale vsaka tri mesece, so pokazale odstopanja med evidenco in dejanskimi zalogami v odstotkih, ki so se merili v desetinah. Tako po vrednosti kot po količini in številu postavk. To je bila prava težava. Družba je v resnici imela pravilne zaloge v evidenci le štirikrat letno – naslednji dan po inventuri. Ta proces je naš junak začel urejati.
Fantek se je dogovoril z lastnikom, da mora zmanjšati odstopanja po rezultatih inventure za polovico. Mimogrede, lastniku ni bilo težko, ker so pred našim junakom različni zaposleni že poskušali vse popraviti in je naloga veljala za skoraj nerešljivo. Vse to je močno povečalo zanimanje, ker bi, če bi uspelo, naenkrat postal človek, ki zna vzpostaviti red in rešiti nerešljive naloge.
Torej, pred njim je bila naloga: v enem letu zmanjšati odstopanja po rezultatih inventure za dvakrat. Ob začetku projekta si ni predstavljal, kako bo to dosegel, vendar je razumel, da je skladiščna evidenca preprosta zadeva, zato bi se vseeno dalo narediti kaj koristnega. Še posebej, ker znižati odstopanja s deset odstotkov na enajst odstotkov ni tako težko. Vsi, ki so delali na področju svetovanja ali sorodnih dejavnosti, razumejo, da se večina težav v procesu odpravi s precej preprostimi dejanji.
Od januarja do maja se je pripravljal, nekoliko avtomatiziral, preklical poslovni proces skladiščnega računovodstva, spremenil delovne tokove skladiščnikov, računovodij in sploh preoblikoval celoten sistem, nikomur ničesar ni pokazal in ne povedal. Maja je vsem razdelil nove navodila, in po prvi inventuri v letu se je začelo novo življenje – delo po njegovih pravilih. Da bi opazovali rezultate, je podjetje začelo izvajati inventure pogosteje – vsakih dva meseca. Prvi rezultati so bili že pozitivni, do konca leta pa so se odstopanja od rezultatov revizij znižala na deleže manj kot enega odstotka.
Uspeh je bil ogromen, čeprav mu ni bilo verjeti. Sam mladenič je dvomil, da se bo rezultat obdržal, če se umakne in preneha opazovati proces. Kljub temu je bil rezultat prisoten, mladenič pa je prejel vse, kar je dogovoril z lastnikom. Kasneje, po nekaj letih, se je stabilnost rezultata potrdila – odstopanja so se še naprej gibala znotraj 1 %.
Takrat se je odločil ponoviti poskus in predlagal lastniku, da izboljša še en problematičen proces – oskrbo. Tam so bila pomanjkanja, ki niso dopuščala odpošiljanja takšnih količin, kot so si želeli naši kupci. Dogovorili so se, da se bodo pomanjkanja v enem letu prepolovila, mladenič pa bo izvajal še 10-15 projektov v zvezi s 1C – avtomatizacijo različnih poslovnih procesov in drugih stvari.
V drugem letu je spet uspelo doseči vse, pomanjkanja so se zmanjšala za več kot 2-krat, vsi IT projekti so bili uspešno zaključeni.
Ker je bilo plačilo že povsem zadovoljivo za vse zahteve tega mladeniča, za dve leti naprej, se je odločil malo umiriti, sprostiti in sedeti na prijetnem toplem mestu, ki si ga je sam ustvaril.
Kaj je to sploh pomenilo? Formalno je bil IT direktor. A kdo je bil v resnici, je težko razumeti. Kaj običajno počne IT direktor? Običajno upravlja IT infrastrukturo, vodi sistemske administratorje, uvaja ERP sisteme in sodeluje na sestankih upravnega odbora.
Eden z njegovih ključnih nalog je bilo sodelovanje v procesih sprememb, predvsem pa generiranje, iniciiranje teh procesov, iskanje in predlaganje rešitev, uporaba novih metod upravljanja, presojo predlaganih sprememb, analizo učinkovitosti drugih funkcij in oddelkov ter končno - neposredno sodelovanje pri strateškem razvoju podjetja, vse do samostojnega oblikovanja strateškega načrta celotnega podjetja.
Dali so mu proste roke. Lahko je prihajal na vsak sestanek, do katerega prej ni imel dostopa. Sedež je tam z zvezkom, nekaj zapisoval ali preprosto poslušal. Redko je govoril. Potem se je začel igrati na telefonu - trdil je, da tako bolje deluje asociativna spomin.
Na sestankih redko kaj koristnega predstavil. Odhajal je, razmišljal, potem je priletelo pismo - ali s kritikami, ali mnenji, ali predlogi, ali z opisom rešitev, ki jih je že uporabil.
A pogosteje je sam organiziral sestanke. Našel je problem, izumil reševalne možnosti, določil zainteresirane strani in vse potegnil v pogajalsko sobo. Tam pa je - kar se je znal. Prepričeval, motiviral, dokazoval, razpravljal, dosegal.
Neformalno je bil tretja oseba v podjetju, takoj za lastnikom in direktorjem. Seveda, grozno je jezil vse "osebe podjetja", začenši s številko 4. Še posebej s svojimi raztrganimi džinsom in svetlimi majicami, pa tudi z lastnikovim časom.
Lastnik mu je posvetil 1 uro na dan. Vsak dan. Pogovarjala sta se, razpravljala o težavah, rešitvah, novih poslovnih priložnostih, razvojnih smereh, kazalcih in učinkovitosti, osebnem razvoju, knjigah in preprosto - življenju.
A ta fant je bil čuden. Videti je bilo tako - sedi in se veseli, življenje se je izkazalo. Ampak ne. Odločil se je, da bo reflektiral.
Zanimalo ga je, zašto je njemu uspevalo, a drugima ne? Vlasnik ga je takođe podsticao: govorio je da želi da i drugima uspe u organizaciji, jer ima mnogo menadžera koji se obično bave operativnim upravljanjem i strateškim planiranjem, ali praktično se niko ne bavi sistemskim promenama svojih procesa. U njihovoj radnoj instrukciji možda i piše da treba da ubrzaju svoje procese, da povećaju efikasnost, ali u praksi se tim ne bavi niko. Zašto je to tako? I njemu je postalo zanimljivo, zašto, i krenuo je da razgovara sa svim tim menadžerima.
Došao je do zamenika direktora za kvalitet i predložio uvođenje Šuhartovih kontrolnih karata, kako bi proizvod bio bolji od japanskog. Ali se ispostavilo da kolega ne zna šta su Šuhartove kontrolne karte, šta je statističko upravljanje procesima, i samo je na kraju čuo za Demingov ciklus u upravljanju kvalitetom. Dobro…
Otišao je kod drugog zamenika direktora i predložio uvođenje kontrolinga. Ali ni ovde nije našao podršku. Malo kasnije saznao je za menadžment granica (boundary management) i svim zamenicima direktora predložio uvođenje sistemskog dela ove metodologije kako bi poboljšali procese. Ali koliko god da je razgovarao, niko nije hteo da se previše uključuje u temu. Možda im je bilo dosadno ili previše složeno. Ali, u suštini, niko se nije razumeo.
U suštini, ispričao je sve što je znao i primenjivao u kompaniji. Ali ga niko nije razumeo. I dalje im nije jasno zašto, na primer, sve uspeo da ispravi u skladišnom računovodstvu, kakve veze tu ima kontroling i menadžment granica.
Na kraju je došao do svojih programera – u timu su bila tri čoveka. Ispričao je o menadžmentu granica, o kontrolingu, o upravljanju kvalitetom, o agile-u i scrumu… I iznenađujuće, svi su razumeli i čak mogli da razgovaraju o tehničkim i metodološkim detaljima. Razumeli su zašto su projekti o skladištu i snabdevanju uspeli. I tada ga je obasjalo: zapravo, svet će spasiti programeri.
Programeri, shvatio je – jedini koji mogu normalno, sa potrebnom preciznošću, da se razumeju u poslovne procese.
Zakaj ravno oni? V resnici ni našel enoznačnega odgovora. Oblikoval je le teze in namige.
Prvič, programerji poznajo specifična poslovna področja, in to bolje od vseh drugih ljudi v podjetju.
Poleg tega programerji resnično razumejo, kaj pomeni algoritem procesa. To je pomembno, ker so poslovni procesi algoritmi, in elementi v njih so lahko preprosto neusklajeni. Na primer, v procesu oskrbe, na katerem je delal fant, je prvi korak priprava letnega načrta nabave, drugi pa dnevna nabava. Ti koraki so povezani z neposredno povezavo, kar pomeni, da bi morali ljudje delovati po tem algoritmu – pripraviti letni načrt nabave in nato takoj izvesti naročilo. Letni načrt nabave se pripravi enkrat letno, naročilo pa je oddano 50-krat na dan. Tu se algoritem konča, in po njem je treba delati. V resnici je razmišljal, da je za programerje poznavanje algoritmov konkurenčna prednost, ker vsak drug človek, ki ni seznanjen z njimi, preprosto ne razume, kako bi moral poslovni proces delovati in kako ga lahko predstavimo.
Še ena prednost programerjev, po besedah tistega fanta, je, da imajo dovolj prostega časa. Vsi razumemo, kako dolgo lahko programerji porabijo za nalogo, ki dejansko zahteva tri krat manj časa, in malo kdo to opazi. To je spet konkurenčna prednost, saj za to, da bi uredili kakšen poslovni proces, potrebujemo veliko prostega časa – razmišljati, opazovati, študirati in preizkušati.
Večina managerjev, po njegovih besedah, tega prostega časa nima in se s tem ponaša. Čeprav to dejansko pomeni, da človek ne more postati učinkovit, ker nima časa za povečanje učinkovitosti – začaran krog. V naši kulturi je moderno biti zaposlen, zato vse ostaja na svojem mestu. Mi, programerji, pa imamo to prednost. Lahko najdemo prosti čas in o vsem premislimo.
Programerji, je pripovedoval, lahko hitro spremenijo informacijski sistem. To ni uporabno na vseh podjetjih, ampak povsod, kjer je delal, je bilo mogoče uveljaviti kakršne koli spremembe, ki so mu ustrezale. Še posebej, če se niso dotikale dela drugih. Na primer, lahko je zagnal sistem, ki bo prikrito meril dejanja uporabnikov in nato to informacijo uporabil – za analizo učinkovitosti dela istega računovodstva in spremljanje stroškov vodenja knjigovodstva.
In zadnje, kar sem si zapomnil iz njegovih besed – programerji imajo dostop do velike količine informacij, saj imajo administrativni dostop do sistema. Zato lahko te informacije uporabijo v svoji analizi. Nihče drug v običajni tovarni nima takšnega vira.
Potem pa je odšel. Med zakonsko dvotedensko odpovedjo smo ga prisilili, da deli svoje izkušnje, ker smo želeli nadaljevati delo, ki ga je opravljal. Pa tudi njegova funkcija je postajala prazna.
V nekaj dneh smo ga posadili na stol, vklopili kamero in posneli njegove monologe. Prosili smo ga, da pripoveduje o vseh opravljenih projektih, metodah, pristopih, uspehih in neuspehih, vzrokih in posledicah, portretih vodij itd. Nismo ga posebej omejevali, saj nismo vedeli, kaj se mu dogaja v mislih.
V monologih je seveda predvsem bilo veliko neumnosti in smešnih stvari – bil je v odličnem razpoloženju, saj je odhajal iz odročnega kraja v Peterburg. Kam pa delati v Peterburgu? Seveda v Gazprom.
Vendar smo uspeli iz njegovih monologov potegniti nekaj koristnega. Povedal bom, kar se spomnim.
Torej, priporočila tega fanta. Tistim, ki bi želeli poskusiti vzpostaviti red v poslovnih procesih.
Da se ukvarjaš s takšnim delom, moraš imeti določeno raven 'otrplosti'. Ne smemo se bati izgubiti službo, ne smemo se bati tveganja, ne smemo se bati konfliktov s sodelavci. Njemu je to šlo zlahka, saj je svojo pot začel, ko je v podjetju delal le pol leta, in se ni uspel navezati na nikogar, prav tako tudi ni nameraval. Zavedal se je, da ljudje prihajajo in odhajajo, zanj pa so pomembni njegovi lastni rezultati in njihova ocena lastnika podjetja. Ali ga sodelavci slabo ali dobro sprejemajo – to ga takrat ni veliko skrbelo.
Drugi trenutek je, da se boste morali, žal, učiti, da bi učinkovito opravljali to delo. Učiti se ne na MBA, ne na tečajih, ne na univerzah, temveč samostojno. Na primer, v svojem prvem projektu, ki se je nanašal na skladišče, je deloval intuitivno, nič ni vedel, samo to, kaj je "upravljanje kakovosti".
Ko je začel brati literaturo o metodah povečanja učinkovitosti, je odkril tehnologije, ki jih je uporabljal. Fant jih je intuitivno uporabljal, a se je izkazalo, da to ni bila njegova iznajdba, ampak da je bilo vse to že dolgo opisano. A je porabil čas, in veliko več, kot če bi takoj prebral pravo knjigo. Tukaj je le pomembno razumeti, da ko preučujete določeno metodo, nobena izmed njih, tudi najbolj napredna, ne bo povsem rešila vseh težav poslovnega procesa.
Druga stvar je, da bolj ko poznate metod, boljše je. Na primer, v stari Japonski je živel Miyamoto Musashi – eden najbolj znanih mečevalcev in avtor stila z dvema mečema. Učil se je v neki šoli pri nekem mojstru, nato je potoval po Japonski in se boril z različnimi nasprotniki. Če je bil nasprotnik močnejši, je potovanje za nekaj časa prenehalo, in Musashi je postal učenec. Tako je v nekaj letih pridobil veščine različnih praks različnih mojstrov in oblikoval svojo šolo, dodajajoč nekaj svojega. Tako je dobil edinstveno mojstrstvo. Tukaj je enako.
Seveda lahko delujete kot poslovni svetovalci. V resnici so odlični ljudje. A običajno pridejo, da uvedejo neko metodo, in uvedejo ne tisto metodo, ki jo podjetju potrebuje. Tudi pri nas so bile takšne žalostne situacije: nihče ne ve, kako rešiti težavo in nihče noče razmišljati, kako jo rešiti. Začnemo iskati ali na internetu, ali pokličemo svetovalca ter ga vprašamo, kaj nam lahko pomaga. Svetovalec pomisli in pove, da je treba uvesti teorijo omejitev. Plačamo mu za priporočilo, zapravimo za uvedbo, a rezultata ni.
Zakaj se to dogaja? Ker je svetovalec rekel, uvedimo to in to sistem, in vsi so se s tem strinjali. Odlično, ampak ena metoda ne reši vseh težav niti enega poslovnega procesa, še posebej, če se izhodiščne predpostavke ne ujamejo – naše in tiste, ki so potrebne za uvedbo metode.
V praksi, ki jo priporoča fant, je treba vzeti najboljše in implementirati najboljše. Ne vzeti metod v celoti, temveč njihove ključne značilnosti, funkcije in prakse. In najpomembneje je razumeti bistvo.
Vzamemo, je dejal, na primer scrum ali agile. V monologih je fant večkrat ponovil, da ne vsi do konca razumejo bistvo scruma. Tudi on je bral knjigo Jeffa Sutherland, ki se nekaterim zdi 'lahko branje'. Njega se je zdela globoka, ker je ena od temeljev scruma upravljanje kakovosti, o tem je v knjigi neposredno napisano.
Tam je napisano o Toyota Production, o tem, kako je Jeff Sutherland prikazal scrum na Japonskem, kako se je tam prijel in kako je bil blizu njihovi filozofiji. In Sutherland je govoril o pomenu vloge scrum masterja, o Demingovem ciklu. Vloga scrum masterja je stalno pospeševanje procesa. Vse ostalo, kar je v scrumu – fazno predajanje, zadovoljstvo naročnika, jasen seznam nalog za obdobje sprinta – je prav tako pomembno, vendar se vse to mora premikati vedno hitreje in hitreje. Hitrost dela mora stalno naraščati v enotah, v katerih se meri.
Mogoče je tukaj težava v prevodu, ker so pri nas knjigo prevedli kot 'Scrum – revolucionarna metoda upravljanja projektov', če pa bi dobesedno prevedli angleški naslov, bi dobili: 'Scrum – dvakrat več v polovici časa', kar pomeni, da že v naslovu gre namig na hitrost kot ključno funkcijo scruma.
Ko je ta fant uvajal scrum, se je v prvem mesecu hitrost povečala dvakrat brez kakršnih koli posebnih sprememb. Našel je točke za spremembe, prilagodil je sam scrum sebi, da je delal precej hitreje. Edino, kot pišejo na internetu, se je pred njimi pojavilo vprašanje: 'Povečali smo hitrost dvakrat, zdaj moramo razumeti, kaj delamo s to hitrostjo?'. Vendar pa je to že povsem drugo področje...
Poleg tega je osebno priporočil več metod. Poimenoval jih je temeljne in osnovne.
Prva – boundary management.
Uči se u "Skolkovo", drugih knjiga i materijala, prema tvrdnjama dečka, nema. Imao je sreću da prisustvuje predavanju profesora sa Harvard-a koji propoveda boundary management, kao i da pročita nekoliko članaka u Harvard Business Review o radovima Erika Trista.
Boundary management se odnosi na sposobnost da se uoče granice i da se njima upravlja. Granica ima svuda — između odeljenja, između različitih vrsta posla, između funkcija, između operativnog i analitičkog rada. Poznavanje boundary management-a ne otkriva više istine, ali omogućava da se realnost vidi iz malo drugačijeg ugla — kroz prizmu granica. Takođe, omogućava upravljanje granicama — postavljanje tamo gde je to potrebno i uklanjanje gde smetaju.
Ali dečko je više i često govorio o kontroli. Imao je neku fiksaciju na tu temu.
Kontrola, ukratko — to je upravljanje zasnovano na brojkama. Ovdje, govorio je, važan je svaki deo definicije — i "upravljanje", i "zasnovano", i "brojkama".
Kod nas, govorio je, slabo stoji sa svim tri aspekta kontrole. Pogotovo ako se uzme u obzir da su oni usko povezani jedni s drugima, kao i s drugim delovima poslovnog sistema.
Prva stvar koja je loša — brojevi. Ima ih malo i niske su kvalitete.
Znatnu većinu brojeva tada smo uzimali iz informacionog sistema 1C. Pa, kvalitet brojeva u 1C, kako je on tvrdio, nije na zadovoljavajućem nivou. Bar, zbog mogućnosti izmene podataka retroaktivno.
Jasno je da krivice programera 1C za to nema — samo uzimaju u obzir zahteve tržišta i mentalitet domaćeg knjigovodstva. Ali za potrebe kontrole, principi rada 1C sa podacima trebali bi se promeniti na konkretnom preduzeću.
Zatim se brojevi iz 1C, prema njegovim rečima, prolaze kroz poluručnu obradu, koristeći Excel, na primer. Takva obrada ne dodaje kvalitetu podacima, kao ni operativnost.
Na kraju, konačni izveštaj još neko prekontrolira, da se slučajno ne pošalju rukovodiocu greške. Na kraju, brojevi stižu do odredišta lepi, provereni, ali vrlo kasno. Obično — nakon isteka perioda (meseca, nedelje, itd.).
I tu, govorio je, sve je vrlo jednostavno. Ako su vam brojevi za januar stigli u februaru, ne možete više upravljati aktivnostima januara. Jer je januar već prošao.
Če so številke zasnovane na računovodstvu in gre za povsem običajno podjetje, ki kvartalno oddaja DDV, potem vodstvo podjetja enkrat na četrtletje prejme razmeroma razumne številke.
Naprej je jasno. Če prejemate številke enkrat na mesec, imate priložnost za upravljanje na podlagi teh številk (tj. izvajati kontroling) 12-krat na leto. Če izvajate kvartalno poročanje, upravljate 4-krat na leto. Plus bonus — letno poročanje. Še enkrat lahko upravljate.
Preostali čas se upravljanje običajno izvaja na slepo.
Ko (in če) številke končno pridejo na dan, se pojavi drugi problem — kako upravljati na podlagi številk? S tem delom njegovih razmišljanj se preprosto nisem mogel strinjati.
Fant je trdil, da če vodja prej ni imel številk, bo njihovo pojavljanje povzročilo učinek 'wau'. Gledal bo in obračal številke na vsak način, klical ljudi na preiskavo, zahteval razlage in preiskave. Potem ko se je igral s številkami, izvedel razpredelnice in grozno obljubil vsem zaposlenim, da "zdaj pa ne odneham", se bo vodja hitro umiril in nehal s tem. Orodje ne bo več uporabljal. A težave bodo ostale.
To se dogaja, je dejal, zaradi pomanjkanja kompetenc vodje. Predvsem v kontrolingu. Vodja preprosto ne ve, kaj naj stori s temi številkami. Kaj zvedeti — ve, kaj storiti — ne. Narediti — to je tisto, kar je zapisano zgoraj (prepirati se, igrati se). Delati — to je vsakodnevni poslovni proces.
Trdil je, da je vse zelo preprosto: številka mora postati del poslovnega procesa. V poslovnem procesu mora biti jasno, kdo, kaj in kdaj mora storiti, ko pride do odstopanja številke od norme (katerikoli primeri — nad meja, pod meja, prekoračitev koridorja, prisotnost trenda, neizpolnitev kvantila itd.)
Tukaj je izpostavil ključno dilemo: številka je tukaj, mora postati del poslovnega sistema, da poveča učinkovitost upravljanja, toda... to se ne dogaja. Zakaj?
Ker ruski vodja ne bo prepustil konkurentu dela svoje moči.
Konkurenti ruskega vodje — kvaliteten in delujoč poslovni proces, premišljena obojestransko koristna motivacija in pravilna avtomatizacija — žal, bodo pustili vodjo brez dela.
Nore, se strinjate? Še posebej, ko gre za vodje. V redu, povedal sem, zdaj pa se odločite sami.
Malo manj, a še vedno preveč, po mojem mnenju, je govoril o scrumu.
Obvezno, je rekel, preberite in poskusite scrum v praksi. Če ste, pravi, brali, a niste poskusili — štejte, da ne veste. Bolje je prebrati knjigo, na primer Sutherlandovo, kot pa članke in razne vodiče (kaj za vraga?) na internetu.
Scrum, je rekel, se spoznava samo v praksi, z obveznim merjenjem obsega opravljenega dela. Osebno poskusite dve najpomembnejši vlogi — lastnika produkta in scrum masterja.
Še posebej pomembno je, po njegovih besedah, doživeti v praksi vlogo scrum masterja, ko boste lahko povečali obseg nalog, ki jih dokončate v sprintu, ne da bi povečali vire in stroške sprinta.
In še v njegovem najboljšem je bila TOC (teorija omejitev sistemov).
To so, po njegovih besedah, osnovni, temeljni principi povečanja učinkovitosti, ki jih je mogoče uporabiti praktično na kateremkoli področju, v katerem koli poslovnem procesu in poslovnem sistemu na splošno.
Ko je izvedel, da se ne poznamo s TOC, je prenehal pripovedovati. Le dodal je, da nas ne bo prikrajšal za veselje branja knjig Eliyahu Goldratta. Podal je priporočilo podobno scrumu — preberite in poskusite. Tipično, ne glede na to, na katerem mestu ste in katero delo opravljate, tam bo prostor za povečanje učinkovitosti z metodami TOC.
Potem mu je očitno ponagajal nabor metod in je rekel: mešajte principe za ustvarjanje uporabnih rešitev v konkretni situaciji.
To je, pravi, glavna priporočilo, ključ do uspeha. Razumite principe, bistvo in ustvarite edinstvene uporabne rešitve — poslovne procese in poslovne sisteme.
Nato je poskušal obuditi neko citat, na koncu pa je moral poiskati na internetu. Izkazalo se je, da je citat iz članka „Stoječ na ramenih velikanov“ Eliyahu Goldratta:
Obstaja razlika med aplikativnimi rešitvami in temeljnimi koncepti, na katerih so te rešitve osnovane. Koncepti so splošni, aplikativne rešitve pa prilagoditve konceptov specifičnemu okolju. Kot smo že videli, takšna prilagoditev ni preprosta in zahteva razvoj določenih elementov rešitve. Moramo se zavedati, da je aplikativna rešitev osnovana na izhodiščnih predpostavkah (včasih skritih) o specifičnem okolju. Ne smemo pričakovati, da bo ta aplikativna rešitev delovala v okolju, za katerega te izhodiščne predpostavke niso veljavne.
Rekel je, da sta delo programerja in 'izboljševalca poslovnih procesov' zelo podobna. In odšel je.
Izvor: habr.com
