E vepruar, unë e kam parë me sytë e mi.
Për disa vite, një djalë, ashtu si shumë nga ju, punonte si programues. Në rastin më të keq do të shkruaj kështu: "programues". Sepse ai ishte 1C, në një kompani prodhimi.
Para kĂ«saj, ai kishte provuar profesionet e ndryshme â 4 vjet si programues nĂ« njĂ« kompani tĂ« madhe, menaxher projekti, duke arritur tĂ« mbyllte deri nĂ« 200 orĂ«, duke marrĂ« njĂ« pĂ«rqindje nga projekti, menaxhimin dhe duke u marrĂ« pak me shitjet. Ai pĂ«rpiqej tĂ« zhvillonte produkte pĂ«r herĂ« tĂ« parĂ«, ishte kreu i departamentit IT nĂ« njĂ« kompani tĂ« madhe me 6,000 punonjĂ«s, provonte modele tĂ« ndryshme tĂ« pĂ«rdorimit tĂ« profesionit tĂ« tij â programuesit 1C.
Por të gjitha këto pozita ishin disi të bllokuara, sidomos përsa i përket të ardhurave. Ne të gjithë në atë kohë merrnim përafërsisht të njëjtat para, punonim në të njëjtat kushte.
Ky djalë filloi të interesohej se si mund të fitonte më shumë para, pa u angazhuar me shitje dhe pa krijuar biznesin e tij të përbashkët.
Ai e kishte menduar veten si një inteligjent dhe vendosi të gjente një niƥë në kompaninë ku punonte. Kjo niƥë duhej të ishte diçka speciale, e paprekur nga të tjerët. Dhe dëshiroi që kompania vetë të dëshironte të paguante një njeri në këtë niƥë, që të mos ishte e nevojshme të gënjehej ndokush ose të manipulohej. Të ishte objektive: njeriut në këtë pozita i duhej të paguhej shumë.
Kërkimet nuk zgjatën shumë. Në kompaninë, ku ky djalë punonte, kishte një niƥë të plotë të cilën mund ta quajmë "organizimi i proceseve të biznesit". Në çdo kompani ka shumë probleme. Gjithmonë diçka nuk funksionon dhe nuk ka ndonjë njeri që të vijë dhe të rregullojë procesin e biznesit. Kështu që ai vendosi të provonte veten si specialist që mund të ndihmojë pronarin të zgjidhë problemet e tij në proceset e biznesit.
NĂ« atĂ« kohĂ« ai kishte punuar nĂ« kompaninĂ« pĂ«r gjashtĂ« muaj dhe merrte njĂ« pagĂ« mesatare pĂ«r tregun. Nuk kishte çfarĂ« tĂ« humbiste â sidomos, qĂ« njĂ« punĂ« tĂ« tillĂ« ai e mund tĂ« gjenin brenda njĂ« jave. NĂ« pĂ«rgjithĂ«si, ky djalĂ« e arsyetoi se nuk do tĂ« ndodhte asgjĂ« e keqe, nĂ«se ndodhte qĂ« gjĂ«rat tĂ« mos funksiononin dhe ai tĂ« shkarkohej.
Ai mblodhi guximin dhe i shkoi pronarit. I propozi tĂ« pĂ«rmirĂ«sojĂ« procesin mĂ« problematik, i cili ishte nĂ« biznes. NĂ« atĂ« kohĂ«, ky ishte menaxhimi i magazinave. Tani, tĂ« gjithĂ«ve qĂ« punojnĂ« nĂ« kĂ«tĂ« kompani, madje u vjen turp tĂ« kujtojnĂ« ato probleme, por inventarizimet qĂ« zhvilloheshin çdo tremujor tregonin diferenca mes sistemit tĂ« menaxhimit dhe mbetjeve reale tĂ« shumĂ« pĂ«rqindjeve. Si nĂ« vlerĂ« ashtu edhe nĂ« sasi, dhe nĂ« sasinĂ« e pozita. Kjo ishte njĂ« fatkeqĂ«si. Kompania kishte tĂ« dhĂ«na tĂ« sakta nĂ« sistemin e menaxhimit vetĂ«m katĂ«r herĂ« nĂ« vit â ditĂ«n pas inventarizimit. Ky proces e kishte marrĂ« nĂ«n kontroll djaloshin tonĂ«.
Djali ra dakord me pronarin që ai duhej të ulte diferencat nga rezultatet e inventarizimit me gjysmën. Për më tepër, pronari nuk kishte shumë për të humbur, sepse deri te heroina jonë, punonjës të ndryshëm kishin bërë përpjekje për ta bërë këtë dhe në përgjithësi, detyra kinse ishte pothuajse e pa zgjidhur. E gjithë kjo e intensifikonte interesimin, sepse nëse gjithçka do të shkonte mirë, atëherë djaloshi automatikisht do të bëhej një njeri që dinte si të vendosë rend dhe të zgjidhë probleme që dukej se nuk kishin zgjidhje.
Pra, përpara tij ishte një detyrë: brenda një viti të reduktonte diferencat nga rezultatet e inventarizimit në gjysmë. Në momentin e fillimit të projektit, ai nuk e dinte se si do të arrinte këtë, por e kuptonte se menaxhimi i magazinave ishte një gjë e thjeshtë, prandaj do t'i jepte fund diçkaje të dobishme. Po ashtu, ulja e diferencave nga shumë përqindje në një përqindje të vetme, duket, nuk ishte aq e komplikuar. Të gjithë ata që kanë punuar në fushën e konsultimeve ose aktiviteteve të ngjashme e dinë se shumica e problemeve të procesit zgjidhen nga veprime mjaft të thjeshta.
Nga janari deri nĂ« maj, ai u pĂ«rgatit, automatizoi pak, rishkroi procesin e regjistrimit tĂ« magazinĂ«s, ndryshoi rrjedhat e punĂ«s pĂ«r magazinierĂ«t, kontabilistĂ«t dhe nĂ« pĂ«rgjithĂ«si e riorganizoi tĂ«rĂ« sistemin pa treguar asgjĂ« dhe pa raportuar askujt. NĂ« maj, ai shpĂ«rndau udhĂ«zime tĂ« reja pĂ«r tĂ« gjithĂ«, dhe pas inventarizimit tĂ« parĂ« tĂ« vitit filloi njĂ« jetĂ« e re â punĂ« sipas rregullave tĂ« tij. PĂ«r tĂ« parĂ« rezultatet, kompania filloi tĂ« kryejĂ« inventarizime mĂ« shpesh â çdo dy muaj. Rezultatet e para ishin pozitive, dhe deri nĂ« fund tĂ« vitit, devijimet nga rezultatet e revizionit ranĂ« nĂ« pjesĂ« tĂ« njĂ« pĂ«rqindjeje.
Suksesi ishte kolosal, por nuk kishte besim nĂ« qĂ«ndrueshmĂ«rinĂ« e tij. Djaloshi vetĂ« dyshonte se rezultati do tĂ« ruhej nĂ«se do tĂ« largohej dhe do tĂ« ndalonte sĂ« vĂ«zhguari procesin. MegjithatĂ«, rezultati ishte aty, dhe djaloshi mori gjithçka pĂ«r tĂ« cilĂ«n kishte rĂ«nĂ« dakord me pronarin. MĂ« pas, pas disa vjetĂ«sh, qĂ«ndrueshmĂ«ria e rezultatit u konfirmua â pĂ«r disa vjet devijimet mbetĂ«n nĂ« kufijtĂ« e 1%.
AtĂ«herĂ« ai vendosi tĂ« pĂ«rsĂ«rijĂ« eksperimentin dhe i propozoi pronarit tĂ« pĂ«rmirĂ«sonte njĂ« proces tjetĂ«r problematik â furnizimin. Atje kishte mungesa, tĂ« cilat nuk lejonin tĂ« eksportoheshin volume tĂ« tilla sa dĂ«shironin klientĂ«t tanĂ«. U dakordua qĂ« brenda njĂ« viti mungesat do tĂ« reduktoheshin me gjysmĂ«n, dhe djali do tĂ« realizonte gjithashtu 10-15 projekte tĂ« lidhura me 1C, pĂ«r automatizimin e proceseve tĂ« ndryshme tĂ« biznesit dhe gjĂ«ra tĂ« tjera.
Në vitin e dytë përsëri gjithçka arriti të përfundojë me sukses, mungesat u reduktuan për më shumë se 2 herë, të gjitha projektet IT u përfunduan me sukses.
Meqenëse paga tashmë e plotësonte plotësisht të gjitha kërkesat e djaloshit, për dy vjet përpara, ai vendosi të qetësohej pak, të relaksohej dhe të qëndronte në një vend të ngrohtë dhe të rehatshëm që e kishte krijuar vetë.
ĂfarĂ« pĂ«rfaqĂ«sonte ajo? Formalisht, ai ishte drejtori IT. Por Ă«shtĂ« e vĂ«shtirĂ« tĂ« kuptohet se çfarĂ« ishte ai nĂ« tĂ« vĂ«rtetĂ«. ĂfarĂ« bĂ«n zakonisht njĂ« drejtori IT? NĂ« pĂ«rgjithĂ«si, ai administron infrastrukturĂ«n IT, drejton administratoret sistemike, implementon sistemin ERP, merr pjesĂ« nĂ« mbledhjet e kĂ«shillit tĂ« drejtorĂ«ve.
Një nga detyrat kryesore të këtij personi ishte pjesëmarrja në proceset e ndryshimit, kryesisht - gjenerimi, nismat e këtyre proceseve, kërkimi dhe propozimi i zgjidhjeve, aplikimi i metodikave të reja të menaxhimit, ekspertiza e ndryshimeve të propozuara, analiza e efikasitetit të funksioneve dhe njësive të tjera, dhe, në fund, pjesëmarrja e drejtpërdrejtë në zhvillimin strategjik të ndërmarrjes, deri në hartimin e planit strategjik të gjithë kompanisë.
I dhanë atij një kartë të bardhë. Ai mund të merrte pjesë në çdo takim ku më parë nuk kishte akses. Qëndronte aty me një bllok shënimesh, duke shënuar diçka, ose thjesht duke dëgjuar. Fliste rrallë. Pastaj filloi të luante në telefon - pretendonte se kështu funksiononte më mirë kujtesa asociative.
Në takime rrallë ndonjëherë dha diçka të dobishme. Shkonte, mendonte, pastaj e merrte një mesazh - ose me kritika, ose me mendime, ose me propozime, ose me përshkrime të zgjidhjeve që ai tashmë kishte aplikuar.
Por më shpesh ai mbante takime vetë. Gjeti një problem, shpiku varianta të zgjidhjeve, përcaktoi palët e interesuara dhe i çoi të gjithë në dhomën e negociatave. Dhe aty - si e dinte ai. Bindte, motivonte, argumentonte, debatonte, arrinte.
Jozyrtarisht, ai konsiderohej osobë e tretë në kompani, pas pronarit dhe drejtorit. Natyrisht, ai nervozonte shumë 'fytyrat e kompanisë', duke filluar nga numri 4. Sidomos me xhinset e tij të grisura dhe t-shirtet e ndritshme, po ashtu - me kohën e pronarit.
Pronari i jepte atij 1 orĂ« nĂ« ditĂ«. Ădo ditĂ«. Ata flisnin, diskutonin probleme, zgjidhje, biznese tĂ« reja, drejtime zhvillimi, tregues dhe efikasitet, zhvillimin personal, libra, dhe thjesht - jetĂ«n.
Por ky djalë ishte i çuditshëm. Duket se - qëndro dhe gëzo, jeta ka shkuar mirë. Por jo. Ai vendosi të refleksionojë.
Iu vendi i interesuar: pse ai arriti, ndersa të tjerët nuk arritën? Pronari gjithashtu e inkurajoi, duke thënë se donte që të tjerët gjithashtu të arrinin të krijonin rend, sepse menaxherë kishte shumë, zakonisht ata merreshin me menaxhimin operativ dhe planifikimin strategjik, por praktikisht askush nuk merrej me ndryshime sistematike të proceseve të tyre. Në përshkrimin e punës së tyre, ndoshta ishte shkruar se ata duhet të acceleronin procesin e tyre, ta rrisnin efikasitetin e tij, por në fakt, askush nuk merret me këtë. Pse ndodh kështu? Po ashtu, djaloshi u bë i interesuar pse dhe shkoi të bisedonte me të gjithë këta menaxherë.
Ai shkoi te zĂ«vendĂ«sdirektori pĂ«r cilĂ«sinĂ« dhe propozoi tĂ« zbatonte kartat e kontrollit tĂ« Shuhartit, pĂ«r tĂ« pasur njĂ« produkt mĂ« tĂ« mirĂ« se ai japonez. Por doli se kollega nuk e dinte se çfarĂ« ishin kartat e kontrollit tĂ« Shuhartit, çfarĂ« ishte menaxhimi statistik i proceseve, dhe vetĂ«m nga njĂ« anĂ« kishte dĂ«gjuar pĂ«r pĂ«rdorimin e ciklit tĂ« Deming nĂ« menaxhimin e cilĂ«sisĂ«. MirĂ«âŠ
Ai shkoi te një zëvendësdirektor tjetër dhe propozoi të zbatonte menaxhimin e kontrollit. Por as këtu nuk gjeti mbështetje. Pak më vonë, ai mësoi për menaxhimin e kufijve dhe iu propozoi të gjithë zëvendësve të drejtorit të zbatonin pjesën sistematike të kësaj metode për të përmirësuar proceset. Por sa herë që djaloshi fliste, askush nuk donte të thellohej për atë çfarë flitej. Ndoshta ata nuk ishin të interesuar ose ishte shumë e komplikuar. Por, në fakt, askush nuk e kuptoi.
Në përgjithësi, ai tregoi gjithçka që dinte dhe kishte zbatuar në kompani. Por askush nuk e kuptoi asnjëherë. Ata ende nuk kuptonin pse, për shembull, gjithçka u arrit të rregullohej në llogaritë e magazinës, dhe si lidhen këtu menaxhimi i kontrollit dhe menaxhimi i kufijve.
SĂ« fundmi, ai arriti te programuesit e tij â nĂ« ekip ishin 3 persona. Ai tregoi pĂ«r menaxhimin e kufijve, menaxhimin e kontrollit, menaxhimin e cilĂ«sisĂ«, pĂ«r agile dhe scrum⊠Dhe pĂ«r habinĂ« e tij, ata tĂ« gjithĂ« e kuptuan, madje mundĂ«n ta diskutonin me tĂ« edhe hollĂ«sitĂ« teknike dhe metodologjike. Ata kuptuan pse projektet pĂ«r magazinĂ«n dhe furnizimin dolĂ«n. Dhe kĂ«tu djaloshi u ndriçua: nĂ« tĂ« vĂ«rtetĂ«, programuesit do ta shpĂ«tojnĂ« botĂ«n.
Programuesit, kuptoi ai â janĂ« tĂ« vetmit qĂ« mund tĂ« kuptojnĂ« nĂ« mĂ«nyrĂ« tĂ« detajuar proceset e biznesit.
Pse pikërisht ata? Në të vërtetë, ai nuk e gjeti kurrë një përgjigje të qartë. Ai formuloj vetëm aludime të thjeshta.
Së pari, programuesit njohin fushat e biznesit, madje, i njohin ato më mirë se çdo njeri tjetër në kompaninë e tyre.
Për më tepër, programuesit realisht kuptojnë se çfarë është algoritmi i procesit. Kjo është e rëndësishme sepse proceset e biznesit janë algoritme dhe elementet brenda tyre mund të mos jenë thjesht të harmonizuara. Për shembull, në procesin e furnizimit, në të cilin punonte ai, hapi i parë është hartimi i planit vjetor të blerjeve, dhe hapi i dytë është blerja ditore. Këta hapa janë të lidhur përmes një lidhjeje direkte, do të thotë se sipas këtij algoritmi, njerëzit duhet të punojnë - të hartojnë planin vjetor të blerjeve dhe menjëherë të përmbushin kërkesën. Plani vjetor i blerjeve hartohet një herë në vit, ndërsa kërkesa vjen deri në 50 herë në ditë. Këtu përfundon algoritmi, dhe duhet punuar sipas tij. Në të vërtetë, mendoi ai, njohja e algoritmeve për programuesit është një përparësi konkurruese, sepse çdo person tjetër, që nuk është njohur me ta, thjesht nuk e kupton se si duhet të punojë procesi i biznesit dhe se si mund ta paraqesë atë.
NjĂ« tjetĂ«r avantazh i programuesve, sipas fjalĂ«ve tĂ« atij djali - ata kanĂ« mjaft kohĂ« tĂ« lirĂ«. TĂ« gjithĂ« ne e kuptojmĂ« se si njĂ« programues mund tĂ« tregojĂ« tri herĂ« mĂ« shumĂ« kohĂ« nĂ« njĂ« detyrĂ« se sa ajo nĂ« tĂ« vĂ«rtetĂ« kĂ«rkon, dhe pak kush do ta vĂ«rejĂ« kĂ«tĂ«. Kjo Ă«shtĂ«, pĂ«rsĂ«ri, njĂ« pĂ«rparĂ«si konkurruese, sepse pĂ«r tĂ« organizuar njĂ« proces biznesi, nevojitet tĂ« kesh shumĂ« kohĂ« tĂ« lirĂ« â pĂ«r tĂ« mĂ«suar, vĂ«zhguar, studiuar dhe provuar.
Shumica e menaxherĂ«ve, sipas fjalĂ«ve tĂ« djalit, nuk e kanĂ« kĂ«tĂ« kohĂ« tĂ« lirĂ« dhe krenohen me kĂ«tĂ«. MegjithatĂ«, kjo nĂ« fakt nĂ«nkupton se personi nuk mund tĂ« bĂ«het efikas, sepse nuk ka kohĂ« pĂ«r tĂ« rritur efikasitetin â njĂ« qark i mbyllur. NĂ« kulturĂ«n tonĂ« Ă«shtĂ« nĂ« modĂ« tĂ« jesh i zĂ«nĂ«, prandaj gjithçka mbetet nĂ« vend. NdĂ«rsa pĂ«r ne, programuesit, kjo Ă«shtĂ« njĂ« avantazh. Ne mund ta gjejmĂ« kohĂ«n e lirĂ« dhe tĂ« mendojmĂ« pĂ«r gjithçka.
Programuesit, tha ai, mund të ndryshojnë shpejt sistemin informativ. Kjo nuk është e aplikueshme në të gjitha bizneset, por kudo që ka punuar ai, ka pasur mundësi për të bërë përmirësime siç dëshirohej. Sidomos nëse ato nuk preknin punën e askujt. Për shembull, ai mund të fillonte një sistem që do të masë fshehtas veprimet e përdoruesve dhe pastaj të përdorë këtë informacion për të analizuar efikasitetin e punës së kontabilitetit dhe për të ndjekur koston e administratës.
Dhe e fundit qĂ« mbajta mend nga fjalĂ«t e tij â programuesit kanĂ« akses nĂ« njĂ« sasi tĂ« madhe informacioni, sepse kanĂ« qasje administratived nĂ« sistem. Prandaj mund tĂ« pĂ«rdorin kĂ«tĂ« informacion nĂ« analizat e tyre. Askush tjetĂ«r nĂ« njĂ« fabrikĂ« normale nuk disponon njĂ« burim tĂ« tillĂ«.
Pastaj ai u largua. Gjatë periudhës së rregullt dyjavore, ne e detyruam atë të ndante përvojën e tij, sepse donim të vazhdonim punën që ai kishte bërë. Dhe pozita e tij po bëhej vacant.
Për disa ditë e vendosëm në një karrige, e ndiznim kamerën dhe regjistronim monologët e tij. E kërkuam të fliste për të gjitha projektet e përfunduara, metodat, qasjet, sukseset dhe dështimet, arsyet dhe pasojat, portretet e menaxherëve etj. Nuk e kufizuam shumë, sepse nuk e dinim se çfarë kishte në mendje.
NĂ« monologĂ«t e tij, sigurisht, nĂ« shumicĂ« kishte gjithfarĂ« marrĂ«zie dhe tĂ« qeshura â ai ishte nĂ« njĂ« humor tĂ« shkĂ«lqyer, sepse po largohej nga njĂ« vend tĂ« vogĂ«l pĂ«r nĂ« Piter. Dhe ku tĂ« shkoje pĂ«r tĂ« punuar nĂ« Piter? NĂ« Gazprom, natyrisht.
Por ndonjë gjë të dobishme na arritën ta nxjerrim nga monologët e tij. Do t'ju tregoj se çfarë mbaj mend.
Kështu, rekomandimet e atij djali. Atij që do të dëshironte të provonte të bënte rendin në proceset e biznesit.
PĂ«r tĂ« bĂ«rĂ« njĂ« punĂ« tĂ« tillĂ«, sĂ« pari duhet tĂ« kesh njĂ« nivel tĂ« caktuar «tĂ« çmendurisë». Duhet tĂ« mos kesh frikĂ« tĂ« humbasĂ«sh punĂ«n, tĂ« mos kesh frikĂ« tĂ« rrezikosh, tĂ« mos kesh frikĂ« nga konfliktet me kolegĂ«t. Ai e bĂ«nte lehtĂ« kĂ«tĂ«, sepse kishte filluar rrugĂ«n e tij pas vetĂ«m gjashtĂ« muajve nĂ« kompani dhe nuk kishte pasur kontakte me askĂ«nd, as qĂ« e kishte menduar kĂ«tĂ«. Ai e kuptonte se njerĂ«zit vijnĂ« dhe largohen, ndĂ«rsa pĂ«r tĂ« ishin tĂ« rĂ«ndĂ«sishme rezultatet e tij dhe vlerĂ«simi nga pronari i biznesit. Si e trajtojnĂ« kolegĂ«t â mirĂ« apo keq â atĂ«herĂ« e shqetĂ«sonte pak.
Momenti i dytĂ« â pĂ«r tĂ« angazhuar nĂ« kĂ«tĂ« punĂ« efikas, fatkeqĂ«sisht, do tĂ« duhet tĂ« mĂ«soni. Por tĂ« mĂ«soni jo pĂ«rmes MBA, as kurseve, as nĂ« institute, por vetĂ«. PĂ«r shembull, nĂ« projektin e tij tĂ« parĂ«, pĂ«r magazinĂ«n, ai veproi intuitivisht, nuk dinte asgjĂ«, vetĂ«m se çfarĂ« ishte "menaxhimi i cilĂ«sisĂ«".
Kur filloi të lexonte literaturë, se cilat metoda ekzistojnë për rritjen e efikasitetit, ai zbuloi ato teknologji që kishte aplikuar. Djaloshi i kishte aplikuar intuitivisht, dhe rezulton se kjo nuk ishte krijimi i tij, gjithçka ishte shkruar prej kohësh. Por ai shkoi duke humbur shumë më tepër kohë se sa do të kishte marrë nëse do të kishte lexuar menjëherë librin e duhur. Këtu është vetëm e rëndësishme të kuptohet se kur studioni një metodologji specifike, asnjëra prej tyre, madje as më e avancuara, nuk do të zgjidhë krejtësisht problemet e procesit të biznesit.
Fusha e dytĂ« Ă«shtĂ« se sa mĂ« shumĂ« metodologji tĂ« njihni, aq mĂ« mirĂ«. PĂ«r shembull, nĂ« Japoni tĂ« lashtĂ« ka jetuar Miyamoto Musashi â njĂ« nga spadash mĂ« tĂ« njohur, autor i stilit tĂ« dy shpatave. Ai kishte studiuar nĂ« ndonjĂ« shkollĂ« nga ndonjĂ« master, pastaj kishte udhĂ«tuar nĂ«pĂ«r Japoni, duke u pĂ«rballur me djem tĂ« ndryshĂ«m. NĂ«se ndonjĂ« djalosh ishte mĂ« i fortĂ«, atĂ«herĂ« udhĂ«timi ndalonte pĂ«r njĂ« kohĂ« dhe Musashi shkonte si nxĂ«nĂ«s. Si rezultat, gjatĂ« disa viteve ai fitoi aftĂ«si nga praktikantĂ« tĂ« ndryshĂ«m dhe formoi shkollĂ«n e tij, duke e shtuar diçka tĂ« re. NĂ« fund, ai arriti njĂ« master unik. KĂ«tu Ă«shtĂ« e njĂ«jta gjĂ«.
Sigurisht, mund të veprohet si konsulentë biznesi. Në përgjithësi, ata janë djem të shkëlqyer. Por, zakonisht, ata vijnë për të implementuar ndonjë metodologji dhe nuk aplikojnë atë që i nevojitet biznesit. Edhe ne kemi pasur situata të trishtueshme: askush nuk e di se si ta zgjidhë problemin dhe askush nuk dëshiron të mendojë se si ta zgjidhë. Fillojmë të kërkojmë ose në internet, ose thërrasim një konsulent dhe i kërkojmë atij se çfarë mund të na ndihmojë. Konsulenti mendon dhe thotë që duhet të implementojmë teorinë e kufizimeve. I paguajmë atij për rekomandimin, shpenzojmë për implementimin, por rezultati është zero.
Pse ndodh kĂ«shtu? Sepse konsulenti tha, implementoni kĂ«tĂ« sistem, dhe tĂ« gjithĂ« u pajtuan me tĂ«. ShkĂ«lqyeshĂ«m, por njĂ« metodologji nuk zgjidh tĂ« gjitha problemet e njĂ« procesi tĂ« vetĂ«m biznesor, veçanĂ«risht nĂ«se nuk pĂ«rputhen premisat fillestare â tonat dhe ato qĂ« kĂ«rkohen pĂ«r tĂ« implementuar metodologjinĂ«.
NĂ« praktikĂ«n qĂ« rekomandon djali, duhet tĂ« marrim mĂ« tĂ« mirĂ«n dhe ta zbatojmĂ« mĂ« tĂ« mirĂ«n. TĂ« mos marrim metodat plotĂ«sisht, por tĂ« marrim karakteristikat kyçe, truket, praktikat e tyre. Dhe mĂ« e rĂ«ndĂ«sishmja â duhet tĂ« kuptojmĂ« thelbin.
Të marrim, tha ai, për shembull, scrum ose agile. Në monologët e tij, djali përsëriti shumë herë se jo të gjithë e kuptojnë plotësisht thelbin e scrum-it. Ai gjithashtu kishte lexuar librin e Jeff Sutherland, i cili disa u duket «lehtë lexim». Atij iu duk si një lexim i thellë, sepse një nga bazat themelore të scrum-it është menaxhimi i cilësisë, për këtë shkruhet qartë në libër.
Aty shkruhet pĂ«r Prodhimin Toyota, pĂ«r mĂ«nyrĂ«n si Jeff Sutherland e tregoi scrum nĂ« Japon, sa mirĂ« iu pĂ«rshtat dhe sa afĂ«r ishte filozofisĂ« sĂ« tyre. Dhe Sutherland foli pĂ«r rĂ«ndĂ«sinĂ« e rolit tĂ« scrum-master-it, pĂ«r ciklin e Deming-ut. Roli i scrum-master-it Ă«shtĂ« tĂ« pĂ«rshpejtojĂ« vazhdimisht procesin. Gjithçka tjetĂ«r qĂ« ndodhet nĂ« scrum â dorĂ«zimi nĂ« faza, kĂ«naqĂ«sia e klientit, lista e qartĂ« e punĂ«ve pĂ«r periudhĂ«n e sprint-it â gjithashtu ka rĂ«ndĂ«si, por gjithçka duhet tĂ« evoluojĂ« gjithnjĂ« e mĂ« shpejt. ShpejtĂ«sia e punĂ«s duhet tĂ« rritet vazhdimisht nĂ« ato njĂ«si qĂ« matet.
Mund tĂ« jetĂ« qĂ« kjo ka tĂ« bĂ«jĂ« me pĂ«rkthimin, sepse ne librin e kemi pĂ«rkthyer si «Scrum â metoda revolucionare e menaxhimit tĂ« projekteve», dhe nĂ«se e pĂ«rkthejmĂ« dosido titullin anglez, rezulton: «Scrum â dy herĂ« mĂ« shumĂ« pĂ«r dy herĂ« mĂ« pak kohë», pra edhe nĂ« titull flitet pĂ«r shpejtĂ«sinĂ« si funksion kyç tĂ« scrum-it.
Kur ky djalë e implementoi scrum-in, në muajin e parë shpejtësia u rrit dyfish pa ndonjë ndryshim të veçantë. Ai gjeti pika për ndryshime, modifikoi veten scrum-in për ta bërë atë të punonte shumë më shpejt. E vetmja, siç shkruajnë në internet, ishte se para tyre doli pyetja: «E rritëm shpejtësinë dyfish, tani duhet të kuptojmë çfarë po bëjmë me një shpejtësi të tillë?». Megjithatë, kjo është një fushë krejtësisht tjetër...
Ai gjithashtu rekomandoi disa metodika personale. I quajti ato themelore dhe bazë.
E para â boundary management.
Ai mësohet në «Skolkovo», nuk ka libra e materiale të tjera, sipas pohimeve të djaloshit. Ajo pati fatin të ishte e pranishme në një leksion nga një profesor i Harvardit, i cili predikon menaxhimin e kufijve, si dhe të lexojë disa artikuj në Harvard Business Review për punimet e Erik Trist.
Menaxhimi i kufijve flet pĂ«r nevojĂ«n pĂ«r tĂ« parĂ« kufijtĂ« dhe pĂ«r t'u marrĂ« me ta. Ka shumĂ« kufij, ata janĂ« gjithandej â midis departamenteve, midis llojeve tĂ« ndryshme tĂ« punĂ«s, midis funksioneve, midis punĂ«s operative dhe asaj analitike. Njohuria e menaxhimit tĂ« kufijve nuk zbulon ndonjĂ« tĂ« vĂ«rtetĂ« mĂ« tĂ« lartĂ«, por lejon tĂ« shohim realitetin nĂ« njĂ« dritĂ« tĂ« ndryshme â pĂ«rmes prizmit tĂ« kufijve. Dhe, pĂ«r rrjedhojĂ«, t'i menaxhojmĂ« ata â tĂ« krijojmĂ« aty ku Ă«shtĂ« e nevojshme dhe t'i heqim atje ku pengojnĂ«.
Por më shumë dhe më shpesh, djali fliste për kontrollin. Ishte një obsesion i tij në këtë temë.
Kontrolli, nĂ«se e shpjegojmĂ« shkurt, Ă«shtĂ« menaxhim bazuar nĂ« numra. KĂ«tu, thoshte ai, Ă«shtĂ« e rĂ«ndĂ«sishme çdo pjesĂ« e definicionit â dhe 'menaxhim', dhe 'nĂ« bazĂ«', dhe 'numra'.
Ne, thoshte ai, jemi të dobët me të tri komponentët e kontrollit. Sidomos nëse merret parasysh se ato janë ngushtësisht të lidhura me njëra-tjetrën, si dhe me pjesët e tjera të sistemit të biznesit.
E para qĂ« Ă«shtĂ« e dobĂ«t â numrat. JanĂ« tĂ« pakĂ«t dhe me cilĂ«si tĂ« ulĂ«t.
Një pjesë të konsiderueshme të numrave atëherë e merrnim nga sistemi informativ 1C. Kështu, cilësia e numrave në 1C, siç pohonte ai, është e papranueshme. Të paktën, për shkak të mundësisë për të ndryshuar të dhënat pas datës.
E qartĂ«, se fajin pĂ«r kĂ«tĂ« nuk e kanĂ« zhvilluesit e 1C â ata thjesht marrin parasysh kĂ«rkesat e tregut dhe mentalitetin e kontabilitetit vendas. Por pĂ«r qĂ«llimet e kontrollit, parimet e punĂ«s sĂ« 1C me tĂ« dhĂ«nat duhet tĂ« ndryshohen nĂ« njĂ« ndĂ«rmarrje tĂ« caktuar.
Pastaj, sipas tij, numrat nga 1C kalojnë një përpunim gjysmë manual, duke përdorur Excel, për shembull. Kjo përpunim nuk shton as cilësi për të dhënat, as shpejtësi.
NĂ« fund, raporti pĂ«rfundimtar kontrollohet nga dikush tjetĂ«r, qĂ« tĂ« mos dorĂ«zojĂ« gabim numra tek drejtuesi. Si rezultat, numrat arrijnĂ« te marrĂ«si tĂ« bukur, tĂ« kontrolluar, por shumĂ« vonĂ«. Zakonisht â pas pĂ«rfundimit tĂ« periudhĂ«s (muaj, javĂ«, etj.).
Dhe këtu, thoshte ai, gjërat janë shumë të thjeshta. Nëse numrat për janarin ju kanë arritur në shkurt, atëherë nuk mund të menaxhoni aktivitetin e janarit. Sepse janari ka përfunduar tashmë.
Dhe nëse numrat bazohen në kontabilitet, dhe kompania është krejtësisht normale, me dorëzimin e TVSh-së çdo tremujor, atëherë për drejtorin e saj rezultati relativisht i arsyeshëm del çdo tremujor.
MĂ« pas Ă«shtĂ« e qartĂ«. Merrni numrat çdo muaj â keni mundĂ«sinĂ« tĂ« menaxhoni sipas numrave (dmth. tĂ« bĂ«ni kontrollim) 12 herĂ« nĂ« vit. Praktikoni raportimin tremujor â menaxhoni 4 herĂ« nĂ« vit. Plus bonus â raportimi vjetor. NjĂ« herĂ« tjetĂ«r pĂ«r ta drejtuar.
Në kohën tjetër menaxhimi, zakonisht, kryhet në errësirë.
Kur (dhe nĂ«se) numrat pĂ«rfundimisht shfaqen, atĂ«herĂ« hyn nĂ« veprim problemi i dytĂ« â si tĂ« menaxhojmĂ« mbi bazĂ«n e numrave? MĂ« kĂ«tĂ« pikĂ« tĂ« arsyetimit tĂ« tij, unĂ« thjesht nuk mund tĂ« pajtohem.
Djali pretendonte se nĂ«se numrat nuk kishin qenĂ« mĂ« parĂ« pĂ«r drejtorin, shfaqja e tyre do tĂ« kishte njĂ« efekt wow. Ai do tĂ« shikonte dhe do tĂ« pĂ«rzgjidhte numrat çdo mĂ«nyre, do tĂ« thĂ«rriste njerĂ«zit, do tĂ« kĂ«rkonte shpjegime dhe hetime. Pasi tĂ« luante me numrat, duke bĂ«rĂ« analiza, duke u kĂ«rcĂ«nuar me tĂ« gjithĂ« punonjĂ«sit se âtani, unĂ« nuk do tâju lĂ«shojâ, drejtori do tĂ« qetĂ«sohej mjaft shpejt dhe do tĂ« heqĂ« dorĂ« nga kjo punĂ«. Ai do tĂ« pushonte sĂ« pĂ«rdoruri kĂ«tĂ« mjet. Por problemet do tĂ« mbeteshin nĂ« vend.
Kjo ndodh, tha ai, pĂ«r shkak tĂ« kompetencave tĂ« pamjaftueshme tĂ« drejtuesit. NĂ« kontrollim, nĂ« radhĂ« tĂ« parĂ«. Drejtori thjesht nuk di se çfarĂ« tĂ« bĂ«jĂ« me kĂ«ta numra. ĂfarĂ« metĂ« bĂ«jĂ« â e di, por se çfarĂ« tĂ« bĂ«jĂ« â jo. TĂ« bĂ«sh â Ă«shtĂ« ajo qĂ« Ă«shtĂ« shkruar mĂ« lart (tĂ« qortohet, tĂ« luhet). TĂ« bĂ«sh â Ă«shtĂ« procesi i biznesit tĂ« pĂ«rditshĂ«m.
Ai pretendonte se gjithçka Ă«shtĂ« shumĂ« e thjeshtĂ«: numri duhet tĂ« bĂ«het pjesĂ« e procesit tĂ« biznesit. NĂ« procesin e biznesit duhet tĂ« jetĂ« qartĂ«sisht e kuptueshme: kush, çfarĂ«, dhe kur duhet tĂ« bĂ«jĂ« nĂ« rast tĂ« devijimit tĂ« numrit nga norma (çfarĂ«do variante â mbi kufirin, nĂ«n kufirin, dalja nga korridori, prania e tendencĂ«s, mosshkaktimi i kuantilit, etj.)
Dhe kështu ai shënoi dilemmën kryesore: numri është, ai duhet të bëhet pjesë e sistemit të biznesit, për të rritur efikasitetin e menaxhimit, por... kjo nuk ndodh. Pse?
Sepse drejtori rus nuk do tâi japĂ« njĂ« copĂ« tĂ« pushtetit tĂ« tij konkurruesit.
Konkurruesit e drejtuesit rus janĂ« njĂ« proces biznesi cilĂ«sor dhe funksional, njĂ« motivim i mirĂ«menduar dhe i ndĂ«rsjellĂ« dhe automatizimi i duhur â fatkeqĂ«sisht, do ta lĂ«nĂ« drejtuesin pa punĂ«.
Bëni një marrëveshje, a nuk është kjo një absurditet? Sidomos për udhëheqësit. Po, ju thashë, vendosni vetë.
Pak më pak, por prapë shumë, sipas mendimit tim, ai fliste për scrum.
Sigurisht, tha, lexoni dhe provoni scrum nĂ« praktikĂ«. NĂ«se, thotĂ«, keni lexuar, por nuk e keni provuar â konsideroni se nuk e dini. ĂshtĂ« mĂ« mirĂ« tĂ« lexoni njĂ« libĂ«r, pĂ«r shembull nga Sutherland, sesa artikuj dhe gjithĂ« ato guĂa (çfarĂ« marifeti Ă«shtĂ« ky?) nĂ« internet.
Scrum, tha ai, njihĂ«t vetĂ«m nĂ« praktikĂ«, dhe me matje tĂ« detyrueshme tĂ« volumit tĂ« punĂ«s qĂ« Ă«shtĂ« kryer. Provoni personalisht dy rolet mĂ« tĂ« rĂ«ndĂ«sishme â pronarin e produktit dhe scrum-masterin.
Sidomos e rëndësishme, sipas fjalëve të djaloshit, është të përjetoni në praktikë rolin e scrum-masterit, kur ju mund të rrisni volumin e detyrave të mbyllura në sprint, pa rritur burimet dhe koston e sprintit.
Një tjetër në rangun e tij ishte TOC (teoria e kufizimeve të sistemeve).
Këto, sipas djaloshit, janë parimet bazë, themelore të rritjes së efikasitetit, që mund të aplikohen në çdo fushë, në çdo proces dhe sistem biznesi në përgjithësi.
Kur mĂ«soi qĂ« ne nuk ishim tĂ« njohur me TOC, ai ndali sĂ« foluri. Thjesht shtoi se nuk do tĂ« na hiqte kĂ«naqĂ«sinĂ« e leximit tĂ« librave nga Eliyahu Goldratt. Dha njĂ« rekomandim tĂ« ngjashĂ«m me scrum â lexoni dhe provoni. Siç thotĂ«, nĂ« çdo pozitĂ« qĂ« jeni, nĂ« çfarĂ«do pune qĂ« bĂ«ni, ka njĂ« vend pĂ«r rritjen e efikasitetit me metodat e TOC.
Pastaj duket se ai ishte i papërgatitur për metoda dhe tha: përzieni parimet, për të krijuar zgjidhje aplikative në situata të caktuara.
Kjo, thotĂ«, Ă«shtĂ« rekomandimi kryesor, çelĂ«si i suksesit. Kuptoni parimet, thelbin, dhe krijoni zgjidhje aplikative unike â procese dhe sisteme biznesi.
Më pas ai u mundua të kujtonte një citat, deri sa duhej të hynte në internet. Doli se citati ishte nga artikulli "Duke qëndruar mbi krahët e gjigantëve" nga Eliyahu Goldratt:
Ka pas një dallim ndërmjet zgjidhjeve aplikative dhe koncepteve themelore në të cilat bazohen këto zgjidhje. Konceptet janë të përgjithshme, ndërsa zgjidhjet aplikative janë një përshtatje e koncepteve në një mjedis të caktuar. Siç e kemi parë, një përshtatje e tillë nuk është e lehtë dhe bën të nevojshme zhvillimin e elementeve të caktuar të zgjidhjes. Duhet të kujtojmë se zgjidhja aplikative bazohet në postulatat fillestare (ndonjëherë të fshehura) për mjedisin konkret. Mos prisni që kjo zgjidhje aplikative të funksionojë në një mjedis për të cilin postulatat fillestare nuk janë të sakta.
Tha se puna e programuesit dhe e "përmirësuesit të proceseve biznesore" është shumë e ngjashme. Dhe u largua.
Burimi: habr.com
