Maparea proceselor în supply chain

Așa cum o spune și cuvântul (map = hartă), e nevoie de o hartă pentru a te orienta. Ce ați face dacă v-ați propune sa mergeți într-o drumeție pe un munte pe care nu ați mai fost vreodată? Sau dacă ați vrea să vizitați un oraș? Cum vă orientați? Folosind o hartă, nu? Acum, folosim hărți virtuale dar tot hărți sunt. La fel este și cu procesele într-o companie.

Un consultant are nevoie să vadă harta de ansamblu a proceselor, așa cum un constructor are nevoie de o hartă topografică a locului unde construiește, pentru a ști ce soluții tehnice trebuie să adopte. Fără să știi cum arată „topografia” activităților din companie, nu ai cum să vezi unde și cum poți optimiza.

Așadar dacă dorim să răspundem la întrebarea „De ce să facem o mapare a proceselor?” putem da cel puțin răspunsurile de mai jos:

• Este o mare posibilitate de a identifica oportunități de optimizare și este o precondiție în demararea oricărui proces de optimizare.
• Ajută la înțelegerea funcționării organizației.
• Harta proceselor este extrem de utilă în procesele de instruire internă a personalului, mai ales în cazul noilor angajați.
• Harta proceselor este, de asemenea, un foarte bun instrument de marketing în relațiile cu acționarii, furnizorii, partenerii și, mai ales, clienții.
• Dar, mai ales, harta proceselor este necesară atunci când se implementează o nouă aplicație software (fie înlocuind un software vechi, fie o primă implementare). Modelarea unei aplicații software nu poate fi făcută fără această mapare.

Când ar trebui sa facem o mapare a proceselor?

Iată câteva răspunsuri la această întrebare:

• Atunci când dorești să faci un benchmarking intern, care să te ajute să identifici cum și de ce unele business unit-uri (sau departamente) au performanțe mai bune și altele mai proaste.
• Atunci când încerci să identifici ce anume nu funcționează corect. O root-cause analysis este inutilă fără identificarea punctelor vulnerabile și critice de pe harta proceselor.
• Așa cum am spus, în mod indirect, și mai sus, o aplicație software (fie ea un TMS, un WMS, un ERP sau orice altă aplicație software) nu poate fi modelată și implementată fără o desenare de procese.

Buuun … deci am decis că trebuie să facem această mapare de procese.

Cum procedăm ? De unde începem ?

Aceasta mapare este, în esență, un proiect și atunci el trebuie abordat ca atare:

• Pasul 1: obțineți sponsorizarea zonei executive a companiei
• Pasul 2: creați echipa de proiect
• Pasul 3: creați echipa de proiect și desemnați Project Managerul
• Pasul 4: lucrul în echipă pentru identificarea și desenarea în draft a hărții proceselor, așa cum sunt ele în acel moment
• Pasul 5: analiza proceselor actuale din perspectiva:
• bottle-neck-urilor
• redundanțelor
• value-chainului
• flexibilității și adaptabilității la schimbări etc.
• Pasul 6 : redesenarea proceselor, pentru satisfacerea tuturor criteriilor utilizate la Pasul 5
• Pasul 7 : formalizarea livrabilelor acestui proiect: schema proceselor, proceduri, instrucțiuni de lucru etc.

O schemă de proces arată cam așa:

Exemplu: implementarea unei aplicații software

Pentru a ieși din „sinergia faptelor” și „recursul la universalitate”, vom coborî în „meandrele concretului”, luând în discuție cel mai folosit caz în care se face o mapare a proceselor: implementarea unei aplicații software. Voi încerca să punctez câteva aspecte importante care să ajute la evitarea unor capcane, la identificarea oportunităților de îmbunătățire, la abordarea provocărilor și piedicilor inerente unei schimbări.

Capcane:

• În primul rând, nu trebuie să uităm că, structural, ființa umană are o reticență primordială la schimbare. De aceea, o schimbare trebuie precedată de o campanie de comunicare foarte bună, în interiorul organizației, menită să prezinte avantajele aduse tuturor de această schimbare.
• În consecință, ca un corolar, alegeți cu mare atenție membrii echipei de proiect a implementării aplicației software. Rezistența la schimbare este în codul nostru genetic și este exacerbată atunci când acea schimbare ne poate scoate din zona noastră de confort. Membrii echipei trebuie să fie, la rândul lor, cei mai mari sponsori ai acestei schimbări.
• În ceea ce privește leadership-ul proiectului de IMPLEMENTARE a aplicației software, este de evitat a fi dat IT-iștilor. Implementarea trebuie coordonată de cineva din zona operațională. Persoana respectivă trebuie să beneficieze de întreaga viziune, atât a activității modelate prin aplicația software, cât și a impactului activității atât în amonte, cât și în aval, pe supply-chain.
• Acolo unde se poate (și se vrea!!), este de preferat ca maparea proceselor DAR ȘI REDESENAREA proceselor să fie făcută de un „ochi străin”… adică o firmă de consultanță care să facă parte și din echipa de implementare a aplicației software. „Ochiul străin” va vedea mult mai ușor redundanțele, risipa de resurse, tiparele „așa am făcut întotdeauna”, care sunt frâne în schimbare etc.
• Când faceți maparea proceselor, gândiți-vă întotdeauna că implementați acel software pentru un timp mai îndelungat, iar piața este veșnic în schimbare și e bine să setați architectural acel software, astfel încât să vă permită, în viitor, schimbări și dezvoltări ușor de făcut, pe baza cărora să vă puteți adapta aplicația la noile condiții ale pieței (traduse prin redesenare procese care duc la modificări de setări).

Atenție!

Cu sau fără firma de consultanță, CEA MAI IMPORTANTĂ IDEE este că Pasul 6 din procesul de mapare (REdesenarea proceselor), precum și setările aplicației software să fie făcute respectând principiile menționate la Pasul 5, având permanent în cap ideea:

„Modelați procesele după nevoile de business și de eficiență operațională… NU modelați procesele după oameni/utilizatori!”.

Modelarea proceselor după oameni duce, FĂRĂ EXCEPȚII, la:

• CREȘTEREA ineficienței operaționale
• frustrări în cadrul organizației
• aduce argumentul „V-am spus eu că nu trebuia făcut” pe buzele celor din companie care s-au împotrivit schimbării.

Romeo DUMITRU

logistics manager Euroccoper