Lean Six Sigma vs. Agile vs. Waterfall in context RPA. Ce alegem?
Am observat in ultima vreme o multime de pareri legate de alegerea intre Lean Six Sigma si Agile, cu trecere uneori si prin Waterfall, cu atat mai mult cu cat se intetesc eforturile de implementare a RPA si toata lumea isi doreste proiecte de succes.
Trebuie sa facem din start o mentiune esentiala: Lean Six Sigma este despre CE si CU CE, NU este despre CUM, sau in termeni mai expliciti, spre deosebire de Agile sau Waterfall, LSS nu este despre Project Managament. Metodologiile de management de proiect se aplica in diverse domenii, de la constructii la proiectare, de la productia de echipamente la dezvoltarea de software si chiar, uneori, in proiecte in care se urmareste optimizarea unor procese, de exemplu proiecte Lean Six Sigma. Lean Six Sigma NU ESTE despre managementul proiectelor, ci doar o metodologie din interiorul unui tip special de proiecte.
Lean Six Sigma poate fi o metodologie aplicata intr-un poiect in care sa folosesc, in anumite situatii elemente de Waterfall (ceea ce de altfel succesiunea DMAIC recomanda clar), iar in alte situatii (de exemplu in fazele de Analiza/Imbunatatire) ingrediente din Agile.
Aparent, deoarece metodologia LSS impune enuntarea unui obiectiv concret, masurabil, o astfel de abordare nu ar prea lasa loc de variatii si in consecinta n-ar prea putea fi vorba despre Agile, ci despre cascadarea D-M-A-I-C. Fals. Chiar si in contextul unor obiective initiale, unele dintre principiile din Agile (de bun simt, de altfel) sunt aplicate, adica o eventuala redefinire (un loop back) dupa faza de Masurare, sau chiar dupa faza de Analiza, sunt nu doar acceptate ci chiar recomandate, exact conform principiului 2 din Manifestul Agile. Firesc, in conditiil in care chiar si versiunea initiala, “puritana” de Waterfall a acceptat ca este necesara o anume flexibilitate.
De asemenea, in zona fazelor mai putin structurate din metodologia Lean Six Sigma, de exemplu Analiza si/sau Imbunatatire, o abordare de tip Agile pe zone bine definite de generare de solutii poate fi o solutie optima. In fond, Agile a aparut ca o necesitate de a evita risipa din anumite proiecte de dezvoltare software, ceea ce, de multa vreme, se numeste Lean
Alegerea uneia sau alteia dintre instrumentele de Project Management se face in functie de criteriile specifice fiecarui instrument, nu sunt nici impuse nici obstructionate de Lean Six Sigma in cazul proiectelor de optimizare de procese.
Situatia este si mai interesanta in cadrul proiectelor de implementare Robotic Process Automation. Un proiect de implementare complet are doua etape majore:
a. pregatirea pentru automatizare
b. automatizarea propriu-zisa
In prima etapa de identificare, evaluare a compatibilitatii cu automatizarea, descriere detaliata a procesului “As Is”, pregatire a versiunii “To Be” si intocmirea unui raport final pe baza caruia sa se faca, in etapa urmatoare, automatizarea, recomandarea evidenta pentru metodologie este Lean Six Sigma. Cu ce metodologie de project management? Aici incepe sa se aplice ceea ce spuneam mai devreme. NU Lean Six Sigma, ca set de instrumente utilizate, impune tipul de PM. Cea mai fireasca ar fi o abordare de tip Waterfall, cu eventuale compromisuri necesare de gen “overlapping”, in care sa adaugam ingrediente de Agile in faza de proiectare a versiunii “To Be”.
La nivel de Lean Six Sigma Green Belt am inceput sa introducem in materialele de training, acolo unde au sens, recomandari si trimiteri la aplicarea unora dintre principiile Agile
De asemenea, lasand, in ultima instanta, alegerea instrumentelor de PM la latitudine organizatiilor, ne-am focalizat pe adaptarea unora dintre instrumentele Lean Six Sigma la utilizarea in proiecte RPA. E interesant de vazut, de exemplu, cum adaptam Process Mapping la perspectiva utilizarii in proiecte RPA, dar si cum ar fi de folosit, acolo unde exista, documentatii pentru Cause & Effect Diagrams sau FMEA.
In cea de-a doua etapa, de implementare propriu-zisa a automatizarii, apare o situatie oarecum interesanta, in care programatorul are la dispozitie cerinte foarte clare, sintetizate in ceea ce, de obicei se numeste Process Description Document (PDD). Agile este despre cand NU ai foarte clar ce se doreste, pe cand aici lucrurile sunt clare. SAU NU. Iar atunci cand nu sunt clare incepe “dansul” care poate sa fie complicat. Elaborarea codului (sau mai precis a algoritmului), testarea si implementarea depind in proportie uriasa de calitatea acestei zone de interfata numita PDD, iar calitatea acesteia depinde de cativa factori:
- Competentele echipei de analisti in ceea ce priveste intelegerea proceselor
- Calitatea procesului de analiza si elaborare a cerintelor
- Acceptarea ideii ca procesele nu pot fi automatizate “As Is” ci trebuie reproiectate ca “To Be”.
- Constientizarea faptului ca aceste proiecte NU sunt proiecte IT si deci implicarea utilizatorilor procesului.
Concluzia: raspunsul la interbarea din titlu este “Le folosim pe toate in mod ISTET”
