O poveste reală, am văzut totul cu ochii mei.
Cu câțiva ani în urmă, un băiat, la fel ca mulți dintre voi, lucra ca programator. În caz că nu e clar, voi scrie așa: „programator”. Pentru că el era specialist 1C, angajat într-o companie de producție.
Înainte de asta, a încercat diferite specialități – 4 ani ca programator la franciză, manager de proiecte, reușind să închidă 200 de ore, primind în același timp un procent din proiect, pentru conducere și lucrând puțin la vânzări. A încercat să dezvolte produse singur, a fost șeful departamentului IT într-o companie mare, cu 6000 de angajați, încercând diverse variante de aplicare a profesiei sale specifice – programator 1C.
Dar toate aceste poziții erau oarecum fără ieșire, în primul rând din cauza veniturilor. Toți câștigam aproximativ aceleași sume, lucrând în aceleași condiții.
Acest băiat a devenit curios cum poate câștiga mai mulți bani fără să se ocupe de vânzări și fără să-și creeze propria afacere.
S-a crezut bine informat și a decis să găsească o nișă în compania în care lucra. Această nișă ar trebui să fie una specială, neocupată de nimeni. Și și-ar dori ca compania să vrea să plătească bani unei persoane în această nișă, astfel încât să nu fie nevoie să înșele pe cineva sau să meargă pe căi ocolitoare. Să fie obiectiv: persoana din această poziție ar trebui să fie plătită bine. O idee ciudată, pe scurt.
Căutările nu au durat mult. În compania în care lucra acest băiat, era complet liberă o nișă pe care o putem numi „organizarea proceselor de afaceri”. În fiecare companie există o mulțime de probleme. Mereu ceva nu funcționează și nu este nimeni care să vină și să corecteze procesul de afaceri. Așadar, el a decis să încerce să fie specialistul care poate ajuta proprietarul să-și rezolve problemele din procesele de afaceri.
În acel moment, el lucrase în companie de șase luni și câștiga salariul mediu pe piață. Nu avea ce pierde — mai ales că putea găsi o muncă similară în decurs de o săptămână. În general, băiatul a considerat că nu s-ar întâmpla nimic teribil dacă, brusc, nu ar ieși nimic bine și ar fi dat afară.
S-a strâns de curaj și a venit la proprietar. I-a propus să îmbunătățească cel mai problematic proces din afacere. În acel moment, acesta era contabilitatea de stocuri. Acum, tuturor celor care lucrează în această companie le este chiar rușine să își amintească acele probleme, dar inventarierile care se realizau trimestrial arătau discrepanțe între sistemul de contabilitate și stocurile reale de zeci de procente. Atât la preț, cât și la cantitate, și la numărul de articole. Era o mare problemă. Compania avea, de fapt, stocuri corecte în sistemul de contabilitate doar de patru ori pe an – în ziua următoare după inventariere. Acest proces l-a adus pe băiatul nostru în ordine.
Băiatul a convenit cu proprietarul că trebuie să reducă deviațiile în rezultate de inventariere cu jumătate. Mai mult, proprietarului nu îi era frică să piardă, deoarece până la eroul nostru, diferiți angajați încercaseră să rezolve aceste probleme, iar în general, sarcina era considerată aproape imposibilă. Totul a crescut foarte mult interesul, deoarece, dacă totul ieșea bine, atunci tipul ar deveni automat persoana care știe să pună ordine și să rezolve problemele imposibile.
Așadar, în fața sa se afla sarcina: în decurs de un an să reducă deviațiile în rezultatele de inventariere cu 2 ori. La începutul proiectului, nu avea idee cum să realizeze asta, dar înțelegea că contabilitatea de stocuri este o treabă simplă, așa că tot ar fi reușit să facă ceva util. Cu atât mai mult, că scăderea deviațiilor de la zeci de procente la un singur digit – nu pare atât de complicat. Toți cei care au lucrat în consultanță sau în activități similare înțeleg că cele mai multe probleme ale procesului sunt eliminate prin acțiuni destul de simple.
Între ianuarie și mai, s-a pregătit, a automatizat puțin, a rescris procesul de gestiune a stocurilor, a schimbat fluxurile de lucru ale depozitarilor, contabililor și practic a refăcut întregul sistem, fără să arate sau să împărtășească nimic cu nimeni. În mai, a distribuit tuturor instrucțiuni noi, iar după prima inventariere din an a început o nouă viață - lucrând după regulile sale. Pentru a observa rezultatul, compania a început să efectueze inventarieri mai des - la fiecare două luni. Primele rezultate au fost deja pozitive, iar până la sfârșitul anului, abaterile în rezultatele reviziei au scăzut la fracțiuni de procent.
Succesul a fost colosal, dar o asemenea stabilitate nu se credea. Chiar și tânărul era îndoielnic că rezultatul va rămâne, dacă se va da la o parte și nu va mai observa procesul. Cu toate acestea, rezultatul a fost și tânărul a obținut tot ce a convenit cu proprietarul. Apoi, după câțiva ani, stabilitatea rezultatului s-a confirmat - abaterile au rămas în limitele de 1 % timp de câțiva ani.
Atunci, a decis să repete experimentul și a propus proprietarului să îmbunătățească un alt proces problematic - aprovizionarea. Acolo erau deficiențe care nu permiteau livrările la volumele pe care clienții noștri le doreau. S-a convenit ca, în decurs de un an, deficiențele să fie reduse la jumătate, iar tânărul va implementa încă 10-15 proiecte legate de 1C - pentru automatizarea diverselor procese de afaceri și alte chestiuni.
În al doilea an, din nou, totul s-a finalizat cu succes, deficiențele s-au redus cu mai mult de 2 ori, toate proiectele IT au fost finalizate cu succes.
Întrucât salariul său deja satisfăcea toate cerințele acelui tânăr pentru următorii doi ani, el a decis să se așeze puțin, să se calmeze și să stea într-un loc cald și confortabil pe care chiar el și l-a creat.
Ce reprezenta el? Formal, era director IT. Dar, de fapt, ce era el, este greu de spus. Ce face, de obicei, un director IT? De regulă, administrează infrastructura IT, coordonează administratorii de sisteme, implementează un sistem ERP, participă la întâlniri ale consiliului de administrație.
La acest tip, una dintre responsabilitățile cheie era participarea la procesele de schimbare, în principal – generarea și inițierea acestor procese, găsirea și propunerea de soluții, aplicarea de noi metode de management, expertizarea modificărilor propuse, analizarea eficienței altor funcții și departamente și, în cele din urmă – participarea directă la dezvoltarea strategică a întreprinderii, până la elaborarea independentă a planului strategic întregii companii.
I s-a dat un cec în alb. Putea să participe la orice întâlnire, la care anterior nu avea acces. Stătea acolo cu un caiet, notând ceva sau pur și simplu ascultând. Vorbea rar. Apoi a început să joace pe telefon – susținea că astfel își activează memoria asociativă mai bine.
La întâlniri rar oferea ceva util. Pleca, medita, apoi primea un e-mail – fie cu critici, fie cu o opinie, fie cu propuneri sau cu descrierea unor soluții pe care deja le aplicase.
Dar mai des, el organiza întâlnirile singur. Găsea o problemă, inventa variante de soluționare, identifica persoanele interesate și îi ducea pe toți în sala de negocieri. Acolo, făcea ce știa mai bine. Convins, motiva, argumenta, disputa, obținea rezultatele dorite.
Neoficial, era considerat a treia persoană în companie, după proprietar și director. Evident, îi enerva grozav pe toți „actorii companiei”, începând cu numărul 4. În special cu blugii săi rupți și tricourile stridente, dar și cu timpul dedicat proprietarului.
Proprietarul îi dedica o oră pe zi. În fiecare zi. Discutau, analizau probleme, soluții, noi afaceri, direcții de dezvoltare, indicatori și eficiență, dezvoltare personală, cărți și, pur și simplu – viața.
Dar tipul acesta era ciudat. De parcă – stai și bucură-te, viața a reușit. Dar nu. A decis să reflecteze.
Îi stârni curiozitatea: de ce el a reușit, iar alții nu? Proprietarul l-a încurajat, spunând că dorește ca și ceilalți să reușească să pună ordine, deoarece sunt mulți manageri, care, de obicei, se ocupă cu managementul operațional și planificarea strategică, dar practic nimeni nu se ocupă de schimbările sistemice ale proceselor lor. În fișa postului lor poate fi scris că trebuie să își accelereze procesele, să le eficientizeze, dar în realitate nimeni nu face acest lucru. De ce? Ei bine, tânărul s-a întrebat și el de ce, și a început să discute cu toți acești manageri.
A mers la adjunctul directorului pentru calitate și a propus implementarea diagramelor de control Shewhart, pentru ca produsele să fie mai bune decât cele japoneze. Dar s-a dovedit că colegul nu știa ce sunt diagrama de control Shewhart, ce este managementul statistic al proceselor, și abia a auzit despre aplicarea ciclului Deming în managementul calității. Bine...
A mers la un alt adjunct al directorului și a propus implementarea controlului. Dar nici aici nu a găsit sprijin. A aflat puțin mai târziu despre managementul frontierelor și a propus tuturor adjuncților directorului să implementeze partea sistemică a acestei metode pentru a îmbunătăți procesele. Dar, oricât a încercat să discute, nimeni nu părea interesat să înțeleagă despre ce era vorba. Poate că nu le păsa sau era prea complicat. În realitate, nimeni nu a reușit să înțeleagă.
În general, le-a spus tot ce știa și aplica în companie. Dar nimeni nu l-a înțeles. Ei nu pot înțelege de ce, de exemplu, totul a fost corectat în contabilitatea de stocuri, ce legătură are controlul și managementul frontierelor.
În cele din urmă, a ajuns la programatorii săi – echipa cuprindea 3 persoane. Le-a povestit despre managementul frontierelor, despre control, despre managementul calității, despre agile și scrum… Și, spre surprinderea lui, toți au înțeles și au putut discuta cu el, inclusiv despre detaliile tehnice și metodologice. Au realizat de ce proiectele legate de stocuri și aprovizionare au avut succes. Și atunci tânărul a realizat: de fapt, programatorii vor salva lumea.
Programatorii, a înțeles el – sunt singurii care pot să analizeze în mod corespunzător, cu detaliile necesare, procesele de afaceri.
De ce anume ei? De fapt, nu a găsit un răspuns clar. A formulat doar indicații sumare.
În primul rând, programatorii cunosc domeniile de activitate ale afacerii, și, de fapt, le cunosc mai bine decât orice alt om din companie.
În plus, programatorii înțeleg cu adevărat ce înseamnă un algoritm de proces. Acest lucru este important deoarece procesele de afaceri sunt algoritmi, iar elementele din ele pot fi pur și simplu nesynchronizate. De exemplu, în procesul de aprovizionare, la care lucra băiatul, primul pas este întocmirea planului anual de achiziții, iar al doilea – achiziția zilnică. Aceste etape sunt conectate printr-o legătură directă, adică se presupune că oamenii trebuie să lucreze conform acestui algoritm – să întocmească planul anual de achiziții și să execute imediat cererea. Planul anual de achiziții este întocmit o dată pe an, iar cererea vine de 50 de ori pe zi. Asta este limita algoritmului, iar conform lui trebuie lucrat. De fapt, a rezonat el, pentru programatori, cunoașterea algoritmilor este un avantaj competitiv, deoarece oricine altcineva, care nu este familiarizat cu ele, pur și simplu nu înțelege cum ar trebui să funcționeze un proces de afaceri și cum poate fi reprezentat.
Un alt plus al programatorilor, conform spuselor băiatului – au suficient timp liber. Toți înțelegem cum un programator poate petrece de trei ori mai mult timp pe o sarcină decât este necesar, iar puțini își vor da seama. Acesta este, din nou, un avantaj competitiv, deoarece pentru a pune în ordine un proces de afaceri, este nevoie de mult timp liber – pentru a gândi, a observa, a studia și a încerca.
Majoritatea managerilor, conform afirmațiilor băiatului, nu au acest timp liber și se mândresc cu asta. Deși, de fapt, acest lucru înseamnă că o persoană nu poate deveni eficientă, deoarece nu are timp pentru a-și spori eficiența – un cerc vicios. În cultura noastră, este la modă să fii ocupat, așa că toate rămân în aceeași stare. Și pentru noi, programatorii, aceasta este o favoare. Putem găsi timp liber și să ne gândim la toate.
Programatorii, spunea el, pot schimba rapid sistemul informațional. Acest lucru nu se aplică în toate întreprinderile, dar în toate locurile în care a lucrat, se puteau face modificări după bunul plac. Mai ales dacă acestea nu implicau munca nimănui. De exemplu, el putea să lanseze un sistem care să măsoare în secret acțiunile utilizatorilor și să folosească ulterior aceste informații pentru a analiza eficiența muncii contabilității și pentru a urmări costurile gestionării contabilității.
Iar ultimul lucru pe care l-am reținut din spusele lui este că programatorii au acces la o cantitate mare de informații, deoarece beneficiază de acces administrativ la sistem. De aceea, pot folosi aceste informații în analiza lor. Nimeni altcineva într-o fabrică obișnuită nu dispune de o astfel de resursă.
Apoi a plecat. În timpul celor două săptămâni de preaviz, l-am făcut să împărtășească experiența sa, deoarece voiam să continuăm activitatea pe care o desfășura. Iar postul său devenea vacant.
Pe parcursul câtorva zile, l-am așezat pe scaun, am pornit camera și am înregistrat monologurile sale. L-am rugat să vorbească despre toate proiectele realizate, metode, abordări, succese și eșecuri, cauze și efecte, portretele conducătorilor etc. Nu l-am restricționat prea mult, deoarece nu știam ce se petrece în mintea lui.
În monologuri, desigur, a fost în principal o mulțime de prostii și glume — era într-o stare de spirit minunată, deoarece ieșea dintr-un loc uitat de lume spre Sankt Petersburg. Și unde să meargă să lucreze în Sankt Petersburg? La Gazprom, desigur.
Dar am reușit să extragem câteva informații utile din monologurile sale. Voi spune ce îmi amintesc.
Așadar, recomandările acelui tip. Pentu cei care vor să încerce să pună ordine în procesele de afaceri.
Pentru a se ocupa de o astfel de muncă, în primul rând, trebuie să ai un anumit nivel de "neînfricare". Nu trebuie să te temi să îți pierzi locul de muncă, să riști, să ai conflicte cu colegii. Pentru el era ușor, deoarece și-a început drumul când a lucrat în companie doar jumătate de an și nu apucase să interacționeze cu nimeni, iar nici nu intenționa să o facă. Înțelegea că oamenii vin și pleacă, iar pentru el conta rezultatele sale personale și evaluarea acestora din partea proprietarului afacerii. Ceea ce gândeau colegii despre el — nu îl prea preocupa atunci.
Un al doilea aspect este că, pentru a te ocupa eficient de această activitate, din păcate, va trebui să înveți. Dar nu să înveți la MBA, nu la cursuri, nu în institute, ci pe cont propriu. De exemplu, în primul său proiect, legat de depozit, a acționat instinctiv, nu știa nimic, doar ce înseamnă „managementul calității.”
Când a început să citească literatura despre metodele de creștere a eficienței, a descoperit tehnologiile pe care le aplica. Tânărul le aplica instinctiv, iar acum realizează că nu era invenția lui, ci totul fusese scris de mult. Dar a pierdut timp, mult mai mult decât dacă ar fi citit direct cartea potrivită. Este important să înțelegem că atunci când studiezi o metodă specifică, niciuna dintre ele, chiar și cea mai avansată, nu va rezolva toate problemele procesului de afaceri.
Al doilea truc este că cu cât cunoști mai multe metode, cu atât mai bine. De exemplu, în Japonia antică trăia Miyamoto Musashi - unul dintre cei mai cunoscuți spadasini, autorul stilului celor două săbii. A studiat într-o școală cu un anumit maestru, apoi a călătorit prin Japonia, luptând împotriva diverselor persoane. Dacă cineva era mai puternic, călătoria se oprea pentru o vreme, iar Musashi devenea ucenic. Drept urmare, în câțiva ani, și-a dezvoltat abilitățile în diverse practici ale diferitelor maeștri și a format propria sa școală, adăugând ceva personal. În final, a dobândit o maestrie unică. Aici este la fel.
Desigur, poți acționa ca consultanți de afaceri. În general, sunt niște oameni excelenți. Dar, de regulă, vin pentru a implementa o anumită metodă și nu implementa metoda de care are nevoie businessul. Am avut și noi astfel de situații neplăcute: nimeni nu știe cum să rezolve problema și nimeni nu vrea să gândească cum să o rezolve. Începem să căutăm fie pe internet, fie chemăm un consultant și îl întrebăm ce ne poate ajuta. Consultantul gândește și spune că trebuie să implementăm teoria constrângerilor. Îi plătim pentru recomandare, cheltuim pe implementare, dar rezultatul este zero.
De ce se întâmplă asta? Pentru că consultantul a spus să implementăm un anumit sistem, iar toată lumea a fost de acord cu el. Excelent, dar o metodă nu rezolvă toate problemele unui singur proces de afaceri, mai ales dacă nu coincid premisele inițiale - ale noastre și cele necesare pentru implementarea metodei.
În practică, pe care tânărul o recomandă, trebuie să iei ce e mai bun și să implementezi ce e mai bun. Să nu iei metodele în întregime, ci să extragi caracteristicile cheie, trăsăturile, practicile. Și cel mai important - trebuie să înțelegem esența.
Să luăm, spunea el, de exemplu, scrum sau agile. În monologurile sale, tânărul a repetat de multe ori că nu toată lumea înțelege pe deplin esența scrum-ului. El a citit și cartea lui Jeff Sutherland, care pentru unii pare a fi „o lectură ușoară”. Pentru el, a fost o lectură profundă, fiindcă una dintre fondamentele scrum-ului este managementul calității, iar acest lucru este scris direct în carte.
Acolo este scris despre Toyota Production, despre cum Jeff Sutherland a prezentat scrum în Japonia, cât de bine s-a integrat acolo și cât de apropiat era de filosofia lor. Sutherland vorbea despre importanța rolului scrum master-ului, despre ciclul Deming. Rolul scrum master-ului este de a accelera constant procesul. Tot ce este altceva în scrum - livrarea etapizată, satisfacția clientului, o listă clară de sarcini pentru perioada sprint-ului - este, de asemenea, important, dar toate acestea trebuie să avanseze tot mai repede. Viteza de lucru trebuie să crească constant în unitățile în care este măsurată.
Poate că aici este vorba despre traducere, pentru că la noi cartea a fost tradusă ca „Scrum - metoda revoluționară de gestionare a proiectelor”, iar dacă am traduce literar titlul englezesc, ar ieși: „Scrum - de două ori mai mult în jumătate din timp”, adică chiar și în titlu se face referire la viteză, ca fiind funcția cheie a scrum-ului.
Când tânărul a implementat scrum, în prima lună viteza a crescut de două ori fără a face modificări semnificative. A găsit punctele de schimbare, a modificat scrum-ul pentru a funcționa mult mai repede. Singurul lucru, așa cum scrie pe internet, este că s-a pus întrebarea: „Am crescut viteza de două ori, acum trebuie să înțelegem ce facem cu o astfel de viteză?”. Totuși, aceasta este o cu totul altă zonă...
De asemenea, el a recomandat personal câteva metode. Le-a numit fundamentale și esențiale.
Prima - boundary management (managementul frontierelor).
Este subiect este predat în cadrul «Skolkovo», iar după spusele tânărului, nu există alte cărți sau materiale. A avut ocazia să participe la o prelegere a unui profesor de la Harvard care promovează managementul granițelor și a citit câteva articole în Harvard Business Review despre lucrările lui Eric Trist.
Managementul granițelor se referă la abilitatea de a vedea și de a lucra cu granițele. Există granițe peste tot — între departamente, între diferitele tipuri de muncă, între funcții, între activitatea operațională și cea analitică. Cunoașterea managementului granițelor nu deschide vreo adevăruri superioare, dar permite să vezi realitatea sub o altă lumină — prin prisma granițelor. Și, prin urmare, să le gestionezi — să le stabilești acolo unde este necesar și să le elimini atunci când deranjează.
Dar cel mai des tânărul a vorbit despre control. Avea o obsesie pentru acest subiect.
Controlul, pe scurt, înseamnă gestionare pe baza cifrelor. Aici, spunea el, este important fiecare parte a definiției — atât «gestionare», cât și «pe baza» și «cifrelor».
La noi, spunea el, este prost cu toate cele trei componente ale controlului. Mai ales dacă ne gândim că acestea sunt strâns interconectate atât între ele, cât și cu alte părți ale sistemului de afaceri.
Primul lucru care este slab — cifrele. Sunt puține și de calitate scăzută.
O mare parte din cifrele pe care le foloseam atunci proveneau din sistemul informațional 1C. Ei bine, calitatea cifrelor din 1C, după cum susținea el, este inacceptabilă. Cel puțin din cauza posibilității de a modifica datele retroactiv.
Este clar că vina dezvolatorilor 1C nu este în acest sens — ei doar țin cont de cerințele pieței și de mentalitatea contabilității autohtone. Dar pentru scopurile controlului, principiile de lucru ale 1C cu datele ar trebui schimbate la nivelul unei anumite întreprinderi.
Apoi, cifrele din 1C, potrivit spuselor lui, trec printr-un proces de prelucrare semi-manual, folosind Excel, de exemplu. Această prelucrare nu adaugă calitate datelor, la fel cum nu îmbunătățește rapiditatea.
În cele din urmă, raportul final este verificat de cineva, pentru a nu cumva să fie prezentate conducerii cifre greșite. În consecință, cifrele ajung la destinatar în mod frumos, verificate, dar foarte târziu. De obicei, după încheierea perioadei (lunar, săptămânal, etc.).
Și aici, spunea el, lucrurile sunt foarte simple. Dacă cifrele din ianuarie ajung în februarie, atunci nu mai poți gestiona activitatea din ianuarie. Pentru că ianuarie s-a încheiat deja.
Dacă cifrele sunt bazate pe contabilitate și compania este una obișnuită, cu declarații de TVA trimestriale, atunci directorul obține cifre relativ adecvate o dată la trei luni.
Apoi, e clar. Obțineți cifre o dată pe lună — aveți ocazia să gestionați pe baza cifrelor (adică să faceți controllings) de 12 ori pe an. Practicați raportare trimestrială — gestionați de 4 ori pe an. Plus un bonus — raportarea anuală. Încă o dată, mai bine zis, să mai conduceți.
În restul timpului, gestionarea se face, de regulă, pe ciegă.
Când (și dacă) cifrele apar, atunci intervine a doua problemă — cum să gestionăm pe baza cifrelor? Cu acest punct al argumentației nu am reușit să mă înțeleg.
Tipul a susținut că, dacă directorul nu a avut anterior cifre, apariția acestora va provoca un efect wow. Se va uita la cifre și le va analiza în toate felurile, va chema oamenii, va cere explicații și va desfășura investigații. După ce se va juca cu cifrele, va face analize, promițând amenințător tuturor angajaților că „de data asta nu mă voi da înapoi”, directorul se va calma foarte repede și va renunța la acest lucru. Nu va mai folosi instrumentul. Iar problemele vor rămâne la locul lor.
Asta se întâmplă, a spus el, din cauza competenței insuficiente a directorului. În controllings, în primul rând. Directorul pur și simplu nu știe ce să facă cu aceste cifre. Ce desă facă — știe, ce să facă — nu știe. A face — este ceea ce este scris mai sus (a se certa, a te juca). A efectua — este un proces de afaceri zilnic.
El a afirmat că totul este foarte simplu: cifra trebuie să devină parte din procesul de afaceri. În procesul de afaceri ar trebui să fie clar: cine, ce și când trebuie să facă în cazul abaterii cifrei de la normă (orice variante — peste limite, sub limite, ieșirea din coridor, existența unui trend, neîndeplinirea cuantilelor etc.)
Și a marcat dilema cheie: cifra există, trebuie să devină parte din sistemul de afaceri pentru a spori eficiența managementului, dar... asta nu se întâmplă. De ce?
Pentru că managerul rus nu va ceda concurentului o parte din puterea sa.
Concurenții managerului rus — un proces de afaceri de calitate și funcțional, o motivație bine gândită și automatizare corectă — din păcate, îl vor lăsa pe manager fără muncă.
Este o prostie, nu-i așa? Mai ales când vine vorba de lideri. Ei bine, eu am povestit, acum decideți voi.
Puțin mai puțin, dar tot prea mult, din punctul meu de vedere, vorbea despre scrum.
Cu siguranță, spunea, citiți și încercați scrum în practică. Dacă, spune el, ați citit, dar nu ați încercat — considerați că nu știți. Este mai bine să citiți o carte, de exemplu, cea de Sutherland, decât articole și tot felul de ghiduri (ce e cu asta?) de pe internet.
Scrum, spunea el, se învață numai prin practică, cu măsurători obligatorii ale volumului de muncă realizat. Încercați personal cele două roluri esențiale — proprietarul de produs și scrum master-ul.
A fost deosebit de important, conform spuselor lui, să simțiți în practică rolul de scrum master, când reușiți să creșteți volumul sarcinilor închise într-un sprint, fără a crește resursele și costul sprintului.
Și în topul lui era și TOC (teoria constrângerilor sistemelor).
Acestea sunt, conform spuselor lui, principii fundamentale de creștere a eficienței, care pot fi aplicate practic în orice domeniu, în orice proces și sistem de afaceri în general.
Când a aflat că nu suntem familiarizați cu TOC, a încetat să mai povestească. A adăugat doar că nu ne va lipsi de plăcerea de a citi cărțile lui Eliyahu Goldratt. A dat o recomandare similară cu scrum — citiți și încercați. Gen, indiferent de funcția pe care o aveți, orice muncă ați desfășura, acolo veți găsi un loc pentru creșterea eficienței prin metodele TOC.
După aceea, se pare că bagajul lui de metodologii s-a epuizat, iar el a spus: combinați principiile pentru a crea soluții aplicate în situații concrete.
Aceasta, spune el, este principala recomandare, cheia succesului. Înțelegeți principiile, esența și creați soluții aplicate unice — procese și sisteme de afaceri.
Apoi s-a străduit să-și amintească o citat, în cele din urmă a fost nevoie să caute pe internet. S-a dovedit că citatul provine din articolul „Stând pe umerii gigantilor” de Eliyahu Goldratt:
„Există o diferență între soluțiile aplicate (aplicările) și conceptele fundamentale pe care se bazează aceste soluții. Conceptele sunt generale, soluțiile aplicate sunt o adaptare a conceptelor la un mediu specific. Așa cum am văzut deja, o astfel de adaptare nu este simplă și necesită dezvoltarea unor elemente specifice ale soluției. Trebuie să ne amintim – soluția aplicată se bazează pe premisele inițiale (uneori ascunse) despre mediu. Nu trebuie să ne așteptăm ca această soluție aplicată să funcționeze într-un mediu pentru care premisele inițiale nu sunt valide.”
A spus că munca unui programator și a unui „îmbunătățitor de procese de afaceri” sunt foarte asemănătoare. Și a plecat.
Sursa: habr.com
