Cum să planificăm dezvoltări cu risc redus

Comenzile unui magazin online sosesc, dar cineva trebuie să le copieze manual în sistemul de gestiune în fiecare dimineață. Depozitul vede date de stoc diferite față de vânzări, iar vinerea trei persoane adună cifrele pentru rapoartele manageriale. Într-o astfel de situație, întrebarea cum să planificăm dezvoltări cu risc redus nu este în primul rând o sarcină tehnologică. Mai întâi trebuie să înțelegem cum a ajuns funcționarea zilnică să depindă atât de mult de transferurile manuale, tabele și cunoștințele unor colegi.

Reducerea riscului nu înseamnă că o companie nu ar trebui să facă schimbări. Înseamnă că schimbarea are un motiv de afaceri clar, limite bine definite și consecințe verificabile. Chiar și în timpul unei dezvoltări bine planificate, compania rămâne funcțională: facturile sunt pregătite, comenzile sunt îndeplinite, producția nu se oprește, iar angajații implicați știu ce se întâmplă.

Riscul dezvoltării este adesea deja prezent în proces

Multe organizații fac greșeala de a căuta imediat un sistem sau o automatizare pentru un simptom enervant. Dacă facturarea întârzie, cer un nou modul de facturare. Dacă nu există un raport bun, cer un nou tablou de bord. Dacă sunt prea multe e-mailuri, ar introduce un nou sistem de gestionare a fluxului de lucru.

Aceste soluții pot fi justificate, dar nu întotdeauna. De exemplu, este posibil ca facturarea să întârzie deoarece datele de comandă sunt în trei locuri diferite și nu este clar care este sursa autentică. Tabloul de bord ar arăta doar mai rapid aceleași date incorecte sau înregistrate cu întârziere.

Cel mai mare risc operațional nu este adesea sistemul vechi în sine. Ci procesul în care oamenii servesc ca legături între sisteme, departamente și surse de informații. Dacă un angajat pleacă în concediu, procesul încetinește. Dacă greșește un cod de produs, eroarea se propagă în depozit, facturare sau comunicarea cu clienții. Dacă proprietarul unui tabel nu este disponibil, nimeni nu este sigur ce versiune ar trebui folosită.

De aceea, o dezvoltare cu risc redus nu ar trebui să înceapă cu un ecran sau o tehnologie, ci cu un proces de afaceri concret.

Cum să planificăm dezvoltări cu risc redus în practică?

Un bun punct de plecare este un proces care este suficient de dureros pentru a merita îmbunătățit, dar suficient de bine definit pentru a nu deschide întreaga funcționare a companiei deodată. Acesta poate fi transferul comenzilor magazinului online către depozit, procesarea documentelor furnizorilor, înregistrarea cerințelor de service sau un raport managerial compilat manual în mod regulat.

Pentru procesul selectat, merită să urmăriți ce se întâmplă cu adevărat. Nu ceea ce spune procedura, ci ceea ce fac colegii zi de zi. De unde vine informația? Cine o verifică? De câte ori este introdusă aceeași informație? Unde așteaptă o sarcină pentru aprobare? La ce pas se sună sau se scrie un e-mail pentru că sistemul nu clarifică ceva?

Cartografierea procesului adesea scoate rapid la suprafață faptul că un pas nu mai are un scop real. Este posibil ca un tabel să fi fost introdus cu ani în urmă deoarece sistemul de atunci nu putea gestiona o anumită informație. Între timp, sistemul s-a schimbat, dar tabelul a rămas și acum doar generează verificări suplimentare, copiere și incertitudine.

Scopul dezvoltării ar trebui să fie formulat în limbaj de afaceri. Scopul nu este să „integrăm sistemele”, ci, de exemplu, ca datele comenzilor magazinului online să ajungă la echipa responsabilă de îndeplinire fără înregistrare manuală și verificabil. Nu este să „creăm o soluție AI”, ci ca angajații să găsească mai rapid datele necesare pentru luarea deciziilor din documentele primite.

Domeniu mai restrâns, rezultat real

Un prim pas prea mare face proiectul imprevizibil. Dacă o dezvoltare afectează simultan vânzările, depozitul, achizițiile, facturarea și finanțele, numărul de decizii crește rapid. Fiecare excepție, regulă veche și mod de lucru diferit necesită o nouă consultare. Până când soluția ar fi finalizată, însăși cerința de afaceri s-ar putea schimba.

Este mai bine să se creeze o primă etapă care să aducă valoare de sine stătătoare. De exemplu, nu transformați întreaga lanț de gestionare a comenzilor de la început. Asigurați-vă mai întâi că comenzile din magazinul online apar automat într-un format uniform în sistemul operațional intern. În etapa următoare, se poate gestiona rezervarea stocului, apoi transferul către transportator sau notificările către clienți.

Aceasta nu este o abordare mai lentă. Adesea aduce rezultate tangibile mai rapid, reducând în același timp șansa ca un presupus să ducă întregul proiect într-o direcție greșită. În timp ce se utilizează prima etapă, se va descoperi dacă ideea originală a fost corectă și ce excepții trebuie luate în considerare.

Restrângerea domeniului nu ar trebui să însemne ignorarea extinderii ulterioare. Soluția trebuie să se integreze în mediul sistemului astfel încât să nu fie necesar să fie aruncată mai târziu. De aceea, de la început trebuie clarificate responsabilitățile datelor, conexiunile sistemului, permisiunile și ce este considerat date de afaceri oficiale.

Riscul poate fi gestionat prin puncte de măsurare

O dezvoltare este controlabilă dacă managementul nu vede doar că „se lucrează”, ci și că îmbunătățește funcționarea. Nu este nevoie de un sistem de indicatori complicat. Într-un proces de comandă, se poate măsura timpul petrecut pentru introducerea manuală a datelor, numărul de comenzi greșite, timpul de procesare și câte excepții trebuie gestionate de oameni.

Măsurarea trebuie să înceapă înainte de schimbare. Dacă nu există o valoare de referință, ulterior se poate discuta doar pe baza impresiilor dacă dezvoltarea a meritat. De asemenea, este posibil ca noul proces să pară inițial mai lent, deoarece face vizibile verificările care anterior erau efectuate informal sau inconsistent. Acest lucru nu este neapărat un eșec. Trebuie să înțelegem că încetinirea este un efect de învățare temporar, un control necesar sau o problemă reală de proiectare.

Condițiile de succes trebuie stabilite în avans. De exemplu: 95% din comenzile zilnice pot fi procesate fără copiere manuală; depozitul vede aceeași stare ca și serviciul pentru clienți; pregătirea raportului financiar scade de la trei ore la treizeci de minute. Un obiectiv concret ajută la deciderea când se poate trece la pasul următor și când mai trebuie îmbunătățit.

Implementare: nu totul se decide în ziua instalării

O soluție tehnic finalizată nu este neapărat o soluție de afaceri funcțională. În timpul implementării, se va vedea dacă cazurile excepționale, responsabilitățile și ritmul zilnic de lucru sunt cu adevărat gestionabile. De aceea, este recomandabil să se utilizeze mai întâi noul proces într-un cadru limitat: pentru un grup de produse, un sediu, un tip de client sau o echipă desemnată.

Funcționarea paralelă este justificată în anumite cazuri, dar nu ar trebui menținută pe termen nelimitat. Dacă vechiul și noul proces coexistă prea mult timp, angajații lucrează dublu, datele pot diferi și nimeni nu știe în ce sistem să aibă încredere. Este mai bine să se stabilească în avans cât durează perioada de probă controlată, cine aprobă rezultatul și în ce condiții noua procedură devine prioritară.

Planul de revenire este, de asemenea, parte a gestionării riscurilor. Nu pentru că dezvoltarea este de așteptat să eșueze, ci pentru că afacerea trebuie protejată. Dacă o integrare trimite date incorecte, trebuie să se știe cum poate fi oprită, cum pot fi identificate tranzacțiile afectate și cine decide asupra corecției. O opțiune de revenire bine documentată face introducerea mai încrezătoare.

Cunoștințele oamenilor nu ar trebui să rămână o componentă ascunsă a sistemului

În companiile în creștere, este frecvent ca o persoană cheie să țină minte excepțiile: ce format de document trebuie trimis fiecărui client, ce date ale furnizorului trebuie verificate separat sau de ce o anumită comandă nu trebuie transmisă automat. Aceasta este o experiență valoroasă, dar un risc de afaceri dacă există doar la o singură persoană.

Scopul dezvoltării cu risc redus nu este de a înlocui acest coleg. Mai degrabă, este de a face ca cunoștințele sale să fie exprimate în reguli verificabile, statusuri vizibile și un flux de lucru utilizabil în comun. Astfel, el petrece mai puțin timp cu administrarea repetitivă și mai mult acolo unde este nevoie de evaluare, cunoașterea clientului sau decizie profesională.

Documentația ar trebui să fie scurtă, dar utilizabilă. Într-un nou proces, echipa trebuie să știe ce s-a schimbat, ce trebuie să facă în caz de eroare, la cine să apeleze și ce date nu pot fi modificate liber. Clarificarea responsabilității operaționale este la fel de importantă ca și lista de sarcini de dezvoltare.

Cea mai bună primă dezvoltare nu este neapărat cea mai spectaculoasă. Adesea, cea care elimină o copiere zilnică de jumătate de oră, face vizibilă o comandă blocată sau face procesul independent de un singur tabel este cea valoroasă. Aceste acțiuni nu doar economisesc timp: oferă dovezi că funcționarea companiei poate fi îmbunătățită controlat, fără riscul unui salt mare următor.