Cum procesele în buclă deschisă perturbă fluxul de informații în afaceri

Am făcut o cantitate destul de mare de reproiectare a proceselor de afaceri de-a lungul carierei mele, iar cea mai mare problemă pe care o găsesc este întotdeauna aceeași: procesele de afaceri în buclă deschisă. Procesele în buclă deschisă apar mai ales pentru că responsabilitatea este împărțită între mai mulți oameni și adesea între mai multe departamente. Un flux de informații care începe în cercetare și dezvoltare cu o solicitare pentru un nou echipament poate călători prin Finanțe și Achiziții înainte de a trece în afara graniței organizaționale către Furnizor (unde va trece prin mai multe departamente la rândul său), și apoi, în cele din urmă, înapoi la Primire și , cu noroc, grupul R&D care a inițiat fluxul.

La fiecare pas, există posibilitatea ca comunicarea să fie întreruptă, iar managerii de proiect trebuie să atenueze aceste riscuri. Dacă fluxurile de informații integrate într-un proces de afaceri nu sunt structurate în mod explicit pentru a captura și apoi gestiona orice excepții, eșecul nu va fi detectat decât mult mai târziu sau poate deloc. În timp ce unele defecțiuni ale fluxului de informații au ca rezultat pur și simplu articolele relativ neimportante să nu fie comandate sau livrate corect, alte eșecuri pot costa organizații sume mari de bani sau pot impune întârzieri activităților esențiale.

Buclele deschise pot costa milioane de dolari

Pentru a ilustra ideea, voi vorbi mai întâi despre o mare organizație farmaceutică care plătea taxe pentru sute de milioane de dolari de echipamente pe care nu le mai putea urmări și dorea să elimine această cheltuială inutilă. Proiectul nostru a descoperit multe defecte fundamentale ale procesului, toate acestea aducând până la zeci de milioane de dolari taxe inutile pe an și cheltuind mult mai mult pentru a comanda aceleași lucruri de mai multe ori din greșeală.

Comunicare unidirecțională între domeniile de responsabilitate

Ca toate organizațiile mari, responsabilitățile erau în siloz. Cineva din Manufacturing are nevoie de echipament X, așa că informează Finanțe și se generează o comandă de achiziție (PO). Comanda trimite PO către vânzător. Până la un an în viitor, X este livrat și acceptat de către Recepție. Primirea notificărilor Producție și Finanțe. Finanțe emite o etichetă de active, pe care Recepția îl plesnește pe X. X este plasat în linia de producție și totul este bine.

Doar că nu totul este bine. Pentru început, angajații vin și pleacă și este ușor să comanzi X fără să-ți dai seama că altcineva în același rol a comandat X acum nouă luni. Finanțe nu au idee că această comandă este o dublură: ei presupun că aveți nevoie pur și simplu de încă un X și astfel este generat un alt PO și este plasat o altă comandă. În afară de asta, chiar dacă nu comandi excesiv din greșeală, pierzi rapid evidența a ceea ce ai.

Să presupunem că X este un echipament complex, poate o linie de umplere-terminare. Este format din 20 de componente majore, toate acestea fiind înlocuite de mai multe ori pe parcursul duratei sale de funcționare. O etichetă de bun plasată întâmplător pe o parte a lui X va dispărea din cauza uzurii. Mai rău, este posibil ca eticheta de material să nu fie aplicată, deoarece nu ajunge la Primire la timp. După aceea, nimeni nu are idee cum să țină evidența lui X și, prin urmare, nicio idee cum să-l dezafecteze la sfârșitul vieții. Din punct de vedere fiscal, X este încă un element impozabil funcțional.

Pe parcursul a peste 20 de ani, acest lucru ar începe să rănească linia de jos într-un mod deloc nesemnificativ. Mai mult, Finanțe utilizează o parte a sistemului lor ERP cu un set de desemnatori de active, în timp ce Manufacturing utilizează un modul ERP complet separat, cu un set diferit de desemnatori de active. La sfârșitul anului, nimeni nu poate reconcilia cele două seturi de numere, iar auditorii se întreabă de ce aveți zeci sau sute de milioane de dolari în discrepanță în ceea ce privește echipamentele dvs. de capital.

Acestea sunt probleme clasice care decurg dintr-un set de procese de afaceri în buclă deschisă. Bucla deschisă este atunci când nu construiți puncte de confirmare explicită de-a lungul liniei de flux a procesului. În exemplul de mai sus, au existat atât de multe procese în buclă deschisă încât eșecul a fost garantat.

Crearea fluxurilor de informații bidirecționale

Iată cum am abordat problema. Am modelat fiecare flux de proces semnificativ de la început până la sfârșit. Am identificat toate buclele deschise. Apoi am conceput modalități simple de a închide acele bucle, una câte una, începând de la bun început.

Primul pas

Manufactura are nevoie de X, așa că solicită Finanțelor să deschidă un PO. Finanțe verifică acum cu Manufacturing pentru a confirma, oferind detalii despre comenzile anterioare pentru X, care au trecut de 24 de luni. Se evită dublarea accidentală a comenzilor.

Pasul doi

Manufacturing oferă Finanțelor o defalcare a componentelor lui X, care vor fi înlocuite în timpul duratei de funcționare. Finanțe creează etichete de active pentru fiecare componentă și confirmă cu Manufacturing. Ambele module ERP sunt populate cu etichete de active potrivite pentru fiecare componentă, permițând urmărirea de-a lungul ciclului de viață al activelor.

Pasul trei

Primirea notifică Finanțe, care informează Manufacturing. Plasarea etichetelor activelor se face de către o parte responsabilă din producție pentru a se asigura că fiecare etichetă este plasată pe componenta corectă. Toate etichetele/componentele sunt apoi reconfirmate pentru cele două module ERP.

Pasul patru

De fiecare dată când o componentă este schimbată, Manufacturing informează Finanțe și o nouă etichetă de activ pentru acea componentă este generată și plasată pe noua componentă de către Manufacturing, apoi confirmată în ambele module ERP. Finanțe începe apoi procesul de eliminare a componentei vechi din registre, în timp ce Manufacturing trece prin procesul de dezafectare a Ghidului de bune practici (GMP). La sfârșitul dezafectării, Manufacturing informează Finanțe, astfel încât activul să poată fi scos din contabilitate.

Detaliile sunt puțin mai complexe decât acest exemplu simplificat, dar ideea este clară: la fiecare etapă de-a lungul drumului, există verificări și confirmări explicite.

Asigurarea acțiunilor de urgență

Într-un alt proiect, mi s-a cerut să ajut o companie de servicii să-și îmbunătățească ratele de satisfacție a clienților. Afacerea lor se referea la procesarea cererilor și erau îngrijorați că nu reușesc să câștige oferte. Mai mult, în ofertele lor câștigătoare, nemulțumirea ulterioară din partea clienților a însemnat că rata contului pierdut era prea mare.

A fost nevoie de doar câteva zile pentru a identifica miezul problemei, care au fost din nou procese în buclă deschisă. Atunci când un client potențial solicita o ofertă, managerul de cont își folosea sistemul intern pentru a trimite o schiță a cerințelor clientului persoanei responsabile cu asamblarea ofertei. Creatorul sumei licitate ar crea apoi oferta și o va transmite clientului. Sperăm că în cele din urmă clientul va răspunde, de obicei, cu modificările dorite, pe care creatorul licitației le-ar integra în versiunea următoare. La un moment dat, clientul ar accepta oferta și un nou cont de client va fi creat de către Accounting, o factură ridicată și echipa de onboarding informată.

Prima problemă a fost că nu a existat nicio confirmare explicită din partea creatorului sumelor licitate către managerul contului, așa că uneori ofertele nu erau create și trimise la timp și nimeni nu știa despre asta. Acest lucru a fost posibil deoarece sistemul intern nu avea niciun câmp care să afișeze o dată limită pentru o ofertă și, deoarece creatorul licitației era mereu suprasolicitat, acest lucru a dus la depunerea ofertelor prea târziu. Din cauza fluxului slab de informații în afaceri, aceste situații nu au apărut niciodată.

Ulterior, modificările aduse ofertei nu au fost transmise managerului de cont. Acest lucru a contat deoarece managerul de cont a fost cel care a informat echipa de onboarding atunci când un client a semnat în sfârșit pe linia punctată. Adesea, brief-ul se baza pe înțelegerea inițială a managerului de cont și nu pe oferta pe care clientul o acceptase de fapt.

Odată ce a început angajamentul, documentele clientului urmau să sosească și să fie transmise oricărui membru al echipei din grupul de procesare care fusese desemnat în acea săptămână să se ocupe de ele. Neexistând o confirmare explicită de primire, a fost posibil ca documentele să dispară fără ca nimeni să fie conștient de acest lucru, până când clientul a început să întrebe de ce nu primește rezultatele lucrării de prelucrare.

Când documentele procesate au fost trimise înapoi clientului, nu a existat nicio confirmare la primire, astfel încât orice documente lipsă au fost pierdute pentru a fi vizualizate până când cineva de undeva a început să se plângă de absența lor.

Confirmați evenimentele cheie

La fiecare pas al procesului de licitare, am construit confirmări explicite. Am creat soluții pentru deficiențele sistemului, astfel încât toate informațiile esențiale să fie capturate, inclusiv data cerută de și modificările ulterioare ale ofertei. Am implementat verificări și confirmări explicite pentru tot fluxul de informații în afaceri în cadrul companiei și între companie și client.

De exemplu, atunci când un client trimitea un pachet de documente, acum trimitea un e-mail managerului de cont client, informându-i. Managerul de cont client ar transmite acest lucru părții responsabile în procesarea reclamațiilor. Dacă documentele nu ar fi primite în termen de trei zile, s-ar declanșa o alertă. Când documentele au fost primite, clientului a fost trimis un e-mail care confirma primirea. Reversul a fost valabil și atunci când compania a trimis documente procesate înapoi clientului.

Deoarece majoritatea clienților foloseau corespondența din SUA pentru a amesteca documentele tipărite înainte și înapoi, procesele în buclă închisă care foloseau verificări explicite la fiecare pas au însemnat că orice documente pierdute puteau fi identificate rapid și luați măsuri pentru a remedia situația.

Proceduri de gestionare a excepțiilor de proiectare

Pentru a vedea cum procedurile de tratare a excepțiilor pot fi construite într-un mod rezonabil de ușor, dar eficient, vom analiza un alt exemplu din lumea reală pe care l-am întâlnit în cariera mea când eram CIO al unei organizații de cercetare științifică care se concentrează pe investigarea cauzelor îmbătrânirea și factorii declanșatori ai bolilor legate de vârstă.

Toate institutele de cercetare finanțate de NIH conțin multe laboratoare individuale, fiecare condus de un investigator principal (PI) și cu personal de diverși oameni de știință subordonați și post-doc. La un moment dat, PI are nevoie de o nouă tavă cu reactiv multicameral, așa că îi solicită unuia dintre post-docs să creeze cererea necesară. Post-doc creează cererea și o trimite prin e-mail la Finanțe pentru a cere ca un PO să fie ridicat, cc'ing PI pentru a se asigura că PI este conștient că cererea a fost trimisă. Între timp, PI are setat o notificare automată de calendar pentru a le reaminti să verifice starea solicitării dacă nu au primit confirmarea până la o anumită dată. Acest lucru asigură un mecanism de siguranță în cazul în care post-doc uită să creeze sau să trimită cererea necesară.

Acum, post-doc are, de asemenea, o notificare automată de calendar pentru a verifica cu Finanțe dacă nu primește confirmarea că OP este ridicat într-o perioadă de timp stabilită. Când Finanțe ridică PO, post-doc primește confirmarea prin e-mail că a fost trimis furnizorului, iar post-doc transmite această confirmare către PI.

În această etapă, fie PI, fie post-doc setează o altă notificare automată de calendar pentru a se asigura că, dacă nu se aude nimic de la vânzător într-o perioadă de timp stabilită, cineva verifică cu vânzătorul pentru a se asigura că primirea OP-ului și expedierea acestuia. echipamentul care a fost comandat.

Presupunând că vânzătorul confirmă primirea OP și expediază articolul împreună cu o notificare de expediere, aceasta este direcționată către PI sau post-doc. Apoi au stabilit o notificare calendaristică finală pentru trei zile după data programată de primire pentru a se asigura că, dacă articolul nu apare, ei știu să contacteze furnizorul pentru a urmări ceea ce s-a întâmplat și a primi articolul corect. Dacă articolul ajunge așa cum a fost planificat, post-doc notifică Finanțe, iar dacă organizația folosește etichete de active, atunci acest set de procese poate fi inițiat.

La fiecare pas al procesului, există o confirmare explicită necesară și un sub-proces disponibil pentru a asigura că acțiunea de remediere are loc dacă fluxul principal al procesului este întrerupt. Nimic nu este lăsat atârnând, neconfirmat sau nesuportat. Nu sunt necesare acțiuni ad-hoc, deoarece toată lumea știe ce este necesar și ce trebuie să facă dacă lucrurile merg prost.

Învățați să creați procese în buclă închisă din SQL

Esența unui proces bun este foarte asemănătoare cu modul în care bazele de date relaționale bazate pe SQL au fost concepute pentru a asigura consistența tranzacțională. Orice acțiune trebuie confirmată pentru a putea fi considerată finalizată. Toate comunicațiile bidirecționale au nevoie de confirmare explicită încorporată ca parte a procesului și procese subordonate dezvoltate pentru a se asigura că, dacă nu se primește confirmarea, se ia măsurile corecte. Managerii de proiect de succes ar trebui să creeze procese în buclă închisă pentru a îmbunătăți fluxul de informații într-o afacere și pentru a economisi organizațiilor cantități mari de timp și bani.