Istorioa benetakoa da, dena nire begiekin ikusi nuen.
Hainbat urtez, tipo batek, zuetako askok bezala, programatzaile lanetan aritu zen. Badaezpada, honela idatziko dut: "programatzailea". 1Snik zelako, konponketa batean, ekoiztetxea.
Aurretik, espezialitate desberdinak probatu zituen - 4 urte Frantzian programatzaile gisa, proiektu-zuzendari gisa, 200 ordu bete ahal izan zituen, aldi berean proiektuaren ehuneko bat jasoz, kudeaketarako eta salmenta apur bat egiteko. Nire kabuz produktuak garatzen saiatu nintzen, 6 mila laguneko enpresa handi batean IT saileko burua izan nintzen, nire lanbide zitagarria erabiltzeko aukera desberdinak probatu nituen - 1C programatzailea.
Baina postu horiek guztiak mutu samarrak zeuden, batez ere diru-sarreren aldetik. Garai hartan, denok gutxi gorabehera diru berdina jasotzen genuen eta baldintza berdinetan lan egiten genuen.
Mutil hau galdetzen ari zen nola irabazi zezakeen diru gehiago bere negozioa saldu edo sortu gabe.
Mutil inteligentea iruditu zitzaion eta lan egiten zuen enpresan nitxo bat aurkitzea erabaki zuen. Nitxo honek zerbait berezia izan behar zuen, inork okupatu gabekoa. Eta nik nahi nuen enpresak berak nitxo honetako pertsona bati dirua ordaindu nahi izan zezan, inor engainatu edo ezer engainatu beharrik ez izateko. Helburu hori lortzeko: postu honetan dagoen pertsona bati diru asko ordaindu behar zaio. Eszentriko bat, hitz batean.
Bilaketa laburra izan zen. Tipo honek lan egiten zuen enpresan, guztiz doako nitxo bat zegoen "negozio-prozesuetan gauzak ordenatzea" deitu zitekeena. Enpresa bakoitzak arazo asko ditu. Zerbaitek beti ez du funtzionatzen, eta ez dago negozio prozesua konponduko duen pertsonarik. Beraz, bere burua probatzea erabaki zuen jabeari negozio-prozesuetan dituen arazoak konpontzen lagun diezaiokeen espezialista gisa.
Garai hartan, sei hilabete zeramatzan enpresan lanean eta merkatuko batez besteko soldata jasotzen zuen. Ez zegoen ezer galtzeko, batez ere astebeteko epean lan bera erraz aurki zezakeelako. Oro har, tipo honek erabaki zuen ez zela ezer txarrik gertatuko, bat-batean ezer ez bazen eta kaleratua izan bazen.
Ausardia hartu eta jabearengana heldu zen. Negozioko prozesurik problematikoena hobetzea proposatu nion. Garai hartan biltegiko kontabilitatea zen. Orain enpresa honetan lan egiten duten guztiek lotsatzen dute arazo horiek gogoratzeak, baina hiru hilean behin egiten ziren inbentarioek kontabilitate sistemaren eta ehuneko hamarreneko benetako saldoen arteko desadostasunak erakutsi zituzten. Eta kostuan, eta kantitatean, eta postu kopuruan. Hondamendia izan zen. Konpainiak kontabilitate sisteman saldo zuzenak zituen urtean lau aldiz bakarrik - inbentarioen zenbaketaren biharamunean. Gure mutila prozesu hau ordenatzen hasi zen.
Tipoak jabearekin adostu zuen inbentarioaren emaitzen desbideratzeak erdira murriztu behar zituela. Gainera, jabeak ez zuen ezer berezirik galtzeko, zeren gure heroiaren aurretik hainbat langilek saiakerak egin baitzituzten guztia konpontzeko, eta, oro har, zeregina ia konpon ezinezkotzat jotzen zen. Horrek guztiak interes handia piztu zuen, zeren dena ondo aterako balitz, orduan mutila automatikoki gauzak ordenatzen eta konpon ezin diren arazoak konpontzen dakien pertsona bihurtuko litzateke.
Beraz, eginbeharra zuen aurrean: urtebeteko epean inbentarioaren emaitzetan oinarritutako desbideratzeak bi aldiz murriztea. Proiektua hasi zenean, ez zuen ideia hori nola lortu, baina biltegiko kontabilitatea gauza sinplea dela ulertu zuen, hala ere, zerbait erabilgarria egiteko gai izango zela. Gainera, desbideratzeak ehuneko hamarretik ehuneko hamarrera murriztea ez dirudi hain zaila denik. Aholkularitzan edo antzeko jardueretan lan egin duen edonork ulertzen du prozesuko arazo gehienak urrats nahiko errazekin konpon daitezkeela.
Urtarriletik maiatzera, zerbait prestatu, apur bat automatizatu, biltegiko kontabilitate negozio-prozesua berridatzi, biltegizainen, kontu-hartzaileen lan-fluxuak aldatu eta, oro har, sistema osoa berriro egin zuen, inori ezer erakutsi edo esan gabe. Maiatzean, argibide berriak banatu zituen denei, eta urteko lehen inbentarioaren ondoren, bizitza berri bat hasi zen - bere arauen arabera lan egiten. Emaitzak behatzeko, etorkizunean enpresa inbentarioak maizago egiten hasi zen - bi hilabetean behin. Dagoeneko lehen emaitzak positiboak ziren, eta urte amaierarako, auditoretzaren emaitzen desbideratzeak ehuneko bateko zatira jaitsi ziren.
Arrakasta izugarria izan zen, baina ezin zen sinetsi haren iraunkortasunean. Tipoak berak zalantzan jartzen zuen emaitza gordeko zenik, alde batera utzi eta prozesua behatzeari utziz gero. Hala ere, emaitza izan zen, eta tipoak jabearekin adostutako guztia jaso zuen. Gero, hainbat urteren buruan, emaitzaren egonkortasuna berretsi zen - hainbat urtez desbideratzeak% 1ean egon ziren.
Orduan, esperimentua errepikatzea erabaki zuen eta jabeari beste prozesu problematiko bat hobetzea proposatu zion: hornidura. Gure bezeroek nahi zituzten bolumenak bidaltzen uzten ez ziguten gabeziak zeuden. Urtebete barru defizitak erdira murriztuko zirela adostu genuen, eta tipoak 10C-rekin lotutako 15-1 proiektu ere osatuko zituela - hainbat negozio-prozesu eta beste heresia batzuk automatizatzeko.
Bigarren urtean, dena arrakastaz amaitu zen berriro, defizitak 2 aldiz baino gehiago murriztu ziren, IT proiektu guztiak arrakastaz burutu ziren.
Soldatak mutil horren behar guztiak guztiz asetzen zituenez bi urte lehenagotik, pixka bat lasaitu, lasaitu eta berak sortutako leku epel eta epel batean esertzea erabaki zuen.
Nolakoa izan zen? Formalki, IT zuzendaria zen. Baina benetan nor zen ulertzea zaila da. Azken finean, zer egiten du IT zuzendari batek? Oro har, IT azpiegitura administratzen du, sistema-administratzaileak kudeatzen ditu, ERP sistema bat ezartzen du eta administrazio kontseiluaren bileretan parte hartzen du.
Eta tipo honek aldaketa prozesuetan parte hartzeko funtsezko erantzukizunetako bat zuen, eta, batez ere, - prozesu hauen sorrera, hasiera, irtenbideen bilaketa eta proposamena, kudeaketa-teknika berriak aplikatzea, proposatutako aldaketen azterketa, beste funtzio batzuen eraginkortasuna aztertzea eta dibisioak, eta, azkenik, enpresaren garapen estrategikoan parte-hartze zuzena, enpresa osoaren plan estrategiko baten garapen independentea arte.
Karta zuria eman zioten. Aurretik sarbiderik izan ez zuen edozein bilerara etor zitekeen. Han eseri nintzen koaderno batekin, zerbait idazten edo entzuten besterik ez. Gutxitan hitz egiten zuen. Orduan telefonoz jotzen hasi zen, memoria elkartuak horrela hobeto funtzionatzen duela esanez.
Bileran oso gutxitan eman zuen ezer baliagarririk. Alde egin zuen, pentsatu, gero gutun bat heldu zen -edo kritikekin, edo iritzi batekin, edo iradokizunekin, edo lehendik aplikatutako irtenbideen deskribapenarekin.
Baina sarriago berak deitzen zituen bilerak. Arazo bat aurkitu nuen, irtenbideak asmatu, interesatuak identifikatu eta denak bilerara eraman nituen. Eta gero, ahal zuen moduan. Konbentzitu, motibatu, frogatu, argudiatu, lortu zuen.
Ofizialki, enpresaren hirugarren pertsonatzat hartzen zen, jabearen eta zuzendariaren ondoren. Noski, izugarri haserretu zituen "enpresako pertsona" guztiak, 4. zenbakitik hasita. Batez ere bere bakero urratuak eta kamiseta distiratsuekin, eta baita jabe gisa izandako denborarekin ere.
Jabeak egunean ordu bat ematen zion. Egunero. Hitz egin, arazoak, irtenbideak, negozio berriak, garapen arloak, adierazleak eta eraginkortasuna, garapen pertsonala, liburuak eta bizitza besterik gabe eztabaidatu zuten.
Baina mutil hau arraroa zen. Eseri eta zoriontsu izan, bizitza ona da. Baina ez. Hausnartzea erabaki zuen.
Galdetu zuen: zergatik funtzionatu zuen, baina beste batzuek ez? Jabeak ere bultzatu zuen: beste batzuk ere ordena berreskuratu ahal izatea nahi zuela esan zuen, kudeatzaile asko daudelako, haiek, oro har, kudeaketa operatiboan eta plangintza estrategikoan aritzen dira, baina ia inor ez dago aldaketa sistemikoetan parte hartzen. beren prozesuetan. Beren lan deskribapenean idatzita egon daiteke beren prozesua azkartu eta eraginkortasuna areagotu behar dutela, baina egia esan inork ez du horrelakorik egiten. Zergatik da hori? Mutilari zergatik ere interesatu zitzaion, eta arduradun horiekin guztiekin hitz egitera joan zen.
Kalitatearen zuzendariordearengana etorri zen eta Shewhart-en kontrol-taulak sartzea proposatu zuen, produktuak japoniarrak baino hobeak izan zitezen. Baina konturatu zen lankideak ez zekiela Shewhart-en kontrol-taulak zer ziren, prozesu estatistikoaren kontrola zer zen, eta kalitatearen kudeaketan Deming zikloaren erabilerari buruz bakarrik entzun zuela. ADOS…
Beste zuzendariorde batengana joan zen eta kontrolatzea iradoki zuen. Baina hemen ere ez nuen laguntzarik aurkitu. Pixka bat geroago, mugen kudeaketa (mugaren kudeaketa) ezagutu zuen eta zuzendariorde guztiei metodologia honen atal sistemikoa ezartzea proposatu zien prozesuak hobetzeko. Baina gure mutilak zenbat hitz egiten zuen, inork ez zuen benetan zertaz ari zen sakondu nahi. Agian ez zitzaien interesatzen edo oso zaila zen. Baina, egia esan, inork ez zuen asmatu.
Oro har, enpresan zekien eta erabiltzen zuen guztiaz hitz egin zuen. Baina inork ez zion ulertzen. Oraindik ez dute ulertzen zergatik, adibidez, biltegiko kontabilitatean dena zuzendu zen, eta zerikusi duten kontrolak eta mugen kudeaketak.
Azkenean, bere programatzaileengana iritsi zen - langileak 3 pertsona zeuden. Mugen kudeaketaz hitz egin zuen, kontrolaz, kalitatearen kudeaketaz, agile eta scrum buruz... Eta harritzekoa dena ulertu zuten, eta nolabait berarekin eztabaidatzeko gai izan ziren, ñabardura tekniko eta metodologikoak barne. Biltegi eta hornikuntza proiektuak zergatik funtzionatzen zuten ulertu zuten. Eta orduan argitu zen tipoa: izan ere, programatzaileek mundua salbatuko dute.
Programatzaileak, konturatu zen, negozio-prozesuak normaltasunez ulertu ditzaketen bakarrak dira, beharrezko xehetasunekin.
Zergatik haiek? Izan ere, ez zuen inoiz erantzun argirik aurkitu. Tesi-iradokizunak baino ez ditut formulatu.
Lehenik eta behin, programatzaileek negozioaren gai-arloak ezagutzen dituzte, eta konpainiako beste pertsona guztiek baino hobeto ezagutzen dituzte.
Gainera, programatzaileek benetan ulertzen dute zer den prozesu-algoritmo bat. Hau garrantzitsua da negozio-prozesuak algoritmoak direlako, eta haietako elementuak agian ez dira koherenteak izan. Adibidez, kontratazio prozesuan mutilak lan egiten zuen, lehen urratsa urteko erosketa plana sortzea zen, eta bigarrena eguneroko erosketa. Urrats hauek konexio zuzen baten bidez lotzen dira, hau da, jendeak algoritmo honen arabera lan egin beharko lukeela suposatzen da - urteko kontratazio plana egin eta eskaera berehala exekutatu. Urteko kontratazio plana urtean behin egiten da, eta eskaerak egunean 50 aldiz jasotzen dira. Hemen amaitzen da algoritmoa, eta landu behar duzu. Izan ere, arrazoitu zuen programatzaileentzat algoritmoen ezagutza abantaila lehiakorra dela, ezagutzen ez dituen beste edonork ez baitu ulertzen nola funtzionatu behar duen negozio prozesu batek eta nola irudikatu daitekeen.
Programatzaileen beste abantaila bat, tipoaren arabera, denbora libre nahikoa dutela da. Denok ulertzen dugu nola programatzaile batek benetan behar baino hiru aldiz gehiago igaro dezakeen zeregin batean, eta gutxik ohartuko dira. Hau, berriro ere, abantaila lehiakorra da, izan ere, negozio-prozesuren bat ordenatzeko, denbora libre asko izan behar duzu: pentsatu, behatu, ikasi eta saiatu.
Zuzendari gehienek, tipoaren arabera, ez dute denbora libre hori eta harro daude. Izan ere, horrek esan nahi du pertsona bat ezin dela eraginkorra bihurtu eraginkortasuna hobetzeko astirik ez duelako - gurpil zoroa. Gure kulturan modan dago lanpetuta egotea, beraz, dena berdin jarraitzen du. Eta programatzaileok, hau abantaila bat da. Denbora librea aurki dezakegu eta denetarik pentsatu.
Programatzaileek, esan zuen, azkar alda dezakete informazio sistema bat. Hau ez da aplikagarria enpresa guztietan, baina lan egiten zuen lekuan, nahi zituen aldaketak egin ditzake. Batez ere, beste inoren lanari ez badiote ardura. Esaterako, erabiltzaileen ekintzak ezkutuan neurtuko lituzkeen sistema bat abiarazi dezake, eta gero informazio hori erabil dezake kontabilitate sail beraren eraginkortasuna aztertzeko eta kontabilitate kostuaren jarraipena egiteko.
Eta bere hitzetatik gogoratzen dudan azken gauza da programatzaileek informazio kopuru handia eskura dutela, zeren... sistemarako sarbidea administratiboa izatea. Hori dela eta, informazio hori erabil dezakete analisian. Ohiko landare batean beste inork ez du horrelako baliabiderik.
Eta gero alde egin zuen. Beharrezko bi asteko atxiloaldian, bere esperientzia partekatzera behartu genuen, egiten ari zen lanean jarraitu nahi genuelako. Bada, bere postua hutsik geratu zen.
Hainbat egunetan, aulki batean eseri, kamera piztu eta bere bakarrizketak grabatu zituzten. Amaitutako proiektu guztiak, metodoak, planteamenduak, arrakastak eta porrotak, arrazoiak eta ondorioak, kudeatzaileen erretratuak, etab. Ez zegoen murrizketa berezirik, zeren Ez zekiten zer gertatzen zitzaion buruan.
Bakarrizketak, noski, denak zentzugabekeria eta barreak ziren gehienetan - aldarte onean zegoen, zeren kanpoaldetik irteten zen San Petersburgora. Nora joan behar duzu lanera San Petersburgon? Gazprom-era, noski.
Baina lortu genuen bere bakarrizketetatik zerbait erabilgarria ateratzea. Gogoratzen dudana esango dizut.
Beraz, tipo horren gomendioak. Negozio prozesuetan gauzak ordenatzen saiatu nahi dutenentzat.
Lan mota hau egiteko, lehenik eta behin, "izozte" maila jakin bat izan behar duzu. Ez duzu lana galtzeko beldur izan behar, ez arriskatzeko beldurrik izan behar, ez lankideekiko gatazkei beldurrik izan behar. Erraza egin zitzaion, enpresan sei hilabetez bakarrik lan egin zuenean hasi baitzuen bidea, eta ez baitzuen inorekin harremanetan jartzeko astirik, eta ez baitzuen horretarako asmorik. Jendea joan eta etorri dela ulertu zuen, baina bere emaitzak eta enpresa jabeak egindako balorazioa garrantzitsuak dira berarentzat. Bere lankideek ondo edo gaizki tratatu izanak gutxi kezkatzen zion orduan.
Bigarren puntua da lan hau modu eraginkorrean egiteko, zoritxarrez, ikasi egin beharko duzula. Baina ez ikasi MBA bat egiteko, ez ikastaroetan, ez institutuetan, zure kabuz baizik. Esaterako, bere lehen proiektuan, biltegiko proiektuan, intuizioz jokatu zuen, ez zekien ezer, "kalitatearen kudeaketa" zer zen besterik ez.
Eraginkortasuna areagotzeko zein metodo zeuden jakiteko literatura irakurtzen hasi zenean, erabiltzen zituen teknologiak aurkitu zituen. Tipoak intuizioz aplikatu zituen, baina hori ez zela bere asmakizuna ikusten da, dena aspaldi idatzita zegoen. Baina denbora eman zuen, eta liburu egokia berehala irakurri izan balu baino askoz gehiago. Hemen garrantzitsua da ulertzea teknika zehatz bat aztertzen duzunean, horietako batek, aurreratuenak ere, ez dituela negozio prozesu baten arazo guztiak guztiz konponduko.
Bigarren trikimailua zenbat eta teknika gehiago ezagutu, orduan eta hobeto. Esaterako, antzinako Japonian Miyamoto Musashi bizi zen, ezpatalari ospetsuenetako bat, bi ezpata estiloaren egilea. Eskola batean ikasi zuen maisu batekin, gero Japonian zehar bidaiatu zuen, tipo ezberdinekin borrokatu zuen. Tipoa indartsuagoa bazen, bidaia gelditu zen denbora batez, eta Musashi ikasle bihurtu zen. Ondorioz, hainbat urtetan maisu ezberdinen praktika ezberdinen gaitasunak bereganatu eta bere eskola sortu zuen, berezko zerbait gehituz. Ondorioz, trebetasun berezia lortu zuen. Hemen berdin da.
Jakina, negozio-aholkulari gisa jardun dezakezu. Orokorrean, mutil bikainak dira. Baina, oro har, nolabaiteko metodologia sartzera etortzen dira, eta negozioak behar duen metodologia okerra ezartzen dute. Egoera tristeak ere izan genituen: inork ez daki arazoa nola konpondu eta inork ez du pentsatu nahi nola konpondu. Bilatzen hasten gara Interneten edo aholkulari bati deitzen diogu eta zertan lagun gaitzakeen galdetzen diogu. Aholkulariak murrizketen teoria sartu behar dugula pentsatzen eta esaten du. Bere gomendioa ordaintzen diogu, ezartzeko dirua gastatzen dugu, baina emaitzak zero dira.
Zergatik gertatzen da hau? Aholkulariak esan duenez, halako eta halako sistema sartzen ari gara, eta denak ados zeuden berarekin. Bikaina, baina metodologia batek ez ditu negozio prozesu bakar baten arazo guztiak estaltzen, batez ere hasierako aurrebaldintzak -gureak eta metodologia ezartzeko beharrezkoak- bat ez badatoz.
Tipoak gomendatzen duen praktikan, onena hartu eta onena inplementatu behar duzu. Ez hartu metodoak osorik, baina hartu haien funtsezko ezaugarriak, ezaugarriak eta praktikak. Eta garrantzitsuena funtsa ulertzea da.
Hartu, esan zuen, adibidez, Scrum edo Agile. Bere bakarrizketetan, tipoak askotan errepikatu zuen denek ez dutela Scrum-en funtsa guztiz ulertzen. Jeff Sutherlanden liburua ere irakurri zuen, batzuek «irakurketa arina» iruditzen zaiena. Irakurketa sakona iruditu zitzaion, Scrum-en oinarrizko printzipioetako bat kalitatearen kudeaketa delako, hau zuzenean idatzita dago liburuan.
Toyota Productionri buruz esaten da, Jeff Sutherland-ek Scrum Japonian nola erakutsi zuen, han nola errotu zen eta haien filosofiatik zein hurbil zegoen. Eta Sutherland Scrum Master-aren rolaren garrantziaz hitz egin zuen, Deming zikloari buruz. Scrum Master-en eginkizuna prozesua etengabe bizkortzea da. Scrum-en dagoen gainontzeko guztia ere - faseko entrega, bezeroaren gogobetetasuna, sprint aldirako lan-zerrenda argia - garrantzitsua da, baina hori guztia gero eta azkarrago mugitu behar da. Lanaren abiadura etengabe handitu behar da neurtzen den unitateetan.
Agian hau itzultzeko kontua da, gure liburua "Scrum - proiektuen kudeaketarako metodo iraultzailea" bezala itzuli zelako eta ingelesezko izenburua literalki itzulita, hauxe izango da: "Scrum - bi aldiz gehiago denbora erdian" , hau da, nahiz eta izenak Scrum-en funtsezko funtzio gisa abiadura aipatzen du.
Tipo honek Scrum inplementatu zuenean, abiadura bikoiztu egin zen lehenengo hilabetean aldaketa garrantzitsurik gabe. Aldatzeko puntuak aurkitu zituen eta Scrum bera aldatu zuen askoz azkarrago funtzionatzeko. Interneten idazten duten gauza bakarra galderaren aurrean zeudela da: “Abiadura bikoiztu egin dugu, abiada horretan zer egiten ari garen ulertzea besterik ez da geratzen?”. Hala ere, eremu guztiz ezberdina da...
Hainbat teknika ere gomendatu zituen pertsonalki. Oinarrizko eta oinarrizkotzat jo zituen.
Lehenengoa mugen kudeaketa da.
Skolkovon irakasten dute; tipoaren arabera, ez dago beste liburu eta materialik. Nolabait zortea izan zuen muga-kudeaketa predikatzen duen Harvardeko irakasle baten hitzaldi batera joateko, eta Eric Trist-en lanari buruzko Harvard Business Review-en hainbat artikulu irakurri ere.
Mugen kudeaketak dio mugak ikusi eta mugekin lan egin behar duzula. Muga ugari daude, nonahi daude: sailen artean, lan mota ezberdinen artean, funtzioen artean, lan operatibo eta analitikoen artean. Mugen kudeaketaren ezagutzak ez du egia goragorik agerian uzten, baina errealitatea apur bat beste argi batean ikusteko aukera ematen digu, mugen prismatik. Eta, horren arabera, kudeatu - altxa itzazu behar den tokian, eta kendu bidean dauden tokian.
Baina gehienetan mutilak kontrolatzeaz hitz egiten zuen. Gai honen inguruan bitxikeriaren bat besterik ez zuen.
Kontrolatzea, laburbilduz, zenbakietan oinarritutako kudeaketa da. Hemen, esan zuen, definizioaren atal guztiak garrantzitsuak dira, bai "kudeaketa", bai "oinarritutako" eta "zenbakietan".
Gu, esan zuen, txarrak gara kontrolatzeko hiru osagaiekin. Batez ere, elkarren artean eta negozio-sistemako beste atal batzuekin oso lotuta daudela kontuan hartuta.
Txarra den lehen gauza zenbakiak dira. Gutxi daude eta kalitate baxukoak dira.
Ondoren, 1C informazio sistematik zenbakien zati esanguratsu bat hartu genuen. Beraz, 1C-ko zenbakien kalitatea, esan zuen bezala, ez da ona. Gutxienez, datuak atzeraeraginez aldatzeko gaitasunagatik.
Argi dago hori ez dela 1C garatzaileen errua - merkatuaren eskakizunak eta etxeko kontabilitatearen mentalitatea soilik hartzen dituzte kontuan. Baina kontrolatzeko, hobe da 1C lanaren printzipioak enpresa zehatz bateko datuekin aldatzea.
Gainera, 1C-ko zenbakiek, haren arabera, erdi eskuz prozesatzen dute, Excel erabiliz, adibidez. Prozesamendu horrek ere ez die kalitaterik gehitzen datuei, eta baita eraginkortasuna ere.
Azkenean, beste norbaitek behin betiko txostena egiaztatzen du, akatsak dituzten zifrak nahi gabe kudeatzaileari ez bidaltzeko. Ondorioz, zenbakiak ederki iristen dira hartzailearengana, egiaztatuta, baina oso berandu. Normalean - epea amaitu ondoren (hilabetea, astea, etab.).
Eta hemen, esan zuen, dena oso sinplea da. Urtarrilari buruzko zenbakiak otsailean iritsi bazaizkizu, ezin izango dituzu urtarrileko jarduerak kudeatu. Urtarrila jada amaitu delako.
Eta zifrak kontabilitatean oinarritzen badira, eta enpresa arruntena bada, BEZa hiru hilean behin aurkeztuta, bere kudeatzaileak hiruhilean behin kopuru nahiko egokiak jasotzen ditu.
Gainerakoa argi dago. Zenbakiak hilean behin jasotzen dituzu. Urtean 12 aldiz zenbakien arabera kudeatzeko aukera duzu (hau da, kontrolatzeko). Hiruhileko txostena praktikatzen baduzu, urtean 4 aldiz kudeatzen duzu. Hobari bat gehi - urteko txostena. Gidatu beste behin.
Gainerako denboran, kontrola itsu-itsuan egiten da.
Zenbakiak agertzen direnean (eta baldin) bigarren arazoa sartzen da jokoan: nola kudeatu zenbakietan oinarrituta? Ezin nintzen ados egon bere arrazoibidearen puntu honekin.
Mutilak argudiatu zuen zuzendariak aurretik zenbakiak ez bazituen, haien itxurak wow efektua eragingo zuela. Zenbakiak era batera eta bestera begiratu eta bihurrituko ditu, alfonbrako jendeari deitu, azalpenak eta ikerketak eskatuko ditu. Zenbakiekin jolastu, analisiak egin eta langile guztiei "orain ez zaituztela kenduko" mehatxatuz hitzeman ondoren, zuzendaria oso azkar lasaituko da eta amore emango du gai honetan. Utzi tresna erabiltzeari. Baina arazoak bere horretan jarraituko dute.
Hori, esan zuen, kudeaketa gaitasun nahikorik ez dagoelako gertatzen da. Kontrolean, lehenik eta behin. Kudeatzaileak ez daki zer egin zenbaki horiekin. Zer сegin - badaki zer egin - ez. Egitea da goian idatzitakoa (liskarra, jolastea). Egitea eguneroko negozio prozesu bat da.
Dena oso sinplea dela argudiatu zuen: digitala negozio prozesuaren parte bihurtu behar da. Negozio-prozesuan argi eta garbi egon behar da: nork egin behar du zer eta noiz zenbakiak arautik aldentzen badira (edozein aukera - mugaren gainetik, mugaren azpian, korridoretik haratago joan, joera baten presentzia, ez betetzea). kuantila, etab.)
Eta, beraz, funtsezko dilema azaldu zuen: kopurua existitzen da, enpresa sistemaren parte bihurtu beharko litzateke kudeaketa eraginkortasuna handitzeko, baina... hori ez da gertatzen. Zergatik?
Errusiako buruzagiak ez diolako bere boterearen zati bat lehiakide bati utziko.
Errusiako kudeatzailearen lehiakideek - kalitate handiko eta laneko negozio-prozesua, ongi pentsatutako motibazio onuragarria eta automatizazio egokia -, ai, zuzendaria lanik gabe utziko dute.
Zentzugabekeria modukoa, ez al zaude ados? Batez ere liderrei buruz. Ados, esan dizut, zuk zeuk erabakitzen duzu.
Gutxiago, baina hala ere gehiegi, nire ustez, Scrum-i buruz hitz egin zuen.
Ziurtatu, esan nion, irakurri eta probatu Scrum praktikan. Berak dioenez, irakurri baduzu baina probatu ez baduzu, kontuan hartu ezjakin. Hobe da liburu bat irakurtzea, adibidez Sutherlanden eskutik, Interneten artikuluak eta era guztietako gidak (zer demontre?) baino.
Scrum, esan zuen, praktikaren bidez bakarrik ikasi daiteke, eta egindako lanaren derrigorrezko neurketekin. Pertsonalki probatu bi rol garrantzitsuenak: Product Owner eta Scrum Master.
Bereziki garrantzitsua da, tipoaren arabera, Scrum Master baten rola praktikan esperimentatzea, sprint bakoitzeko burututako zereginen bolumena handitu dezakezunean sprintaren baliabideak eta kostuak handitu gabe.
Beno, bere goialdean TOS zegoen (sistemaren mugen teoria).
Hauek, tipoaren arabera, eraginkortasuna areagotzeko oinarrizko printzipioak dira, ia edozein arlotan aplika daitezkeenak, edozein negozio prozesu eta negozio sistema osoan.
TOS ezagutzen ez genuela jakin zuenean, esateari utzi zion. Eliyahu Goldratten liburuak irakurtzearen plazera kenduko ez zigula soilik gehitu zuen. Scrum-i antzeko gomendio bat eman zion: irakurri eta probatu. Esaterako, edozein posiziotan zauden, edozein dela ere egiten duzun lana, TOC metodoak erabiliz eraginkortasuna areagotzeko tokia dago.
Orduan, bere teknika poltsa itxuraz lehortu egin zen, eta esan zuen: nahastu printzipioak egoera zehatz batean aplikatutako irtenbideak sortzeko.
Horixe da gomendio nagusia, arrakastaren gakoa. Ulertu printzipioak, funtsa eta sortu aplikazio-soluzio bereziak: negozio-prozesuak eta negozio-sistemak.
Gero, aipuren bat gogoratzen saiatu zen, eta azkenean sarean sartu behar izan zuen. Eliyahu Goldratten "Erraldoien sorbalden gainean zutik" artikuluaren aipu bat izan zen:
“Bada aldea aplikatutako soluzioen (aplikazioen) eta soluzio horiek oinarritzen diren oinarrizko kontzeptuen artean. Kontzeptuak orokorrak dira; aplikatutako irtenbideak kontzeptuak ingurune zehatz batera egokitzea dira. Lehen ikusi dugunez, egokitzapen hori ez da erraza eta irtenbidearen zenbait elementu garatzea eskatzen du. Gogoratu behar dugu aplikazio-soluzio bat ingurune zehatz bati buruzko hasierako hipotesietan oinarritzen dela (batzuetan ezkutuan). Aplikazio-soluzio honek ez luke espero behar suposizioak zuzenak ez diren ingurune batean funtzionatuko duenik".
Programatzaile baten lana eta "negozio-prozesuen hobekuntza" baten lana oso antzekoak direla esan zuen. Eta utzi.
Iturria: www.habr.com