In che modo i processi ad anello aperto interrompono il flusso di informazioni nelle aziende

Nel corso della mia carriera ho fatto una buona dose di reingegnerizzazione dei processi aziendali e il problema più grande che trovo è sempre lo stesso: processi aziendali a ciclo aperto. I processi ad anello aperto si verificano principalmente perché la responsabilità è suddivisa tra più persone e spesso tra più reparti. Un flusso di informazioni che inizia in R&D con una richiesta di un nuovo pezzo di attrezzatura può viaggiare attraverso Finance and Purchasing prima di uscire dal confine organizzativo fino al Vendor (dove passerà attraverso diversi reparti a turno), e poi eventualmente tornare a Ricezione e , con fortuna, il gruppo di ricerca e sviluppo che ha avviato il flusso.

Ad ogni passaggio, esiste la possibilità che la comunicazione venga interrotta e i project manager devono mitigare questi rischi. Se i flussi di informazioni integrati in un processo aziendale non sono strutturati in modo esplicito per rilevare e quindi gestire eventuali eccezioni, l'errore verrà rilevato molto più tardi o forse non verrà rilevato affatto. Mentre alcuni errori nel flusso di informazioni si traducono semplicemente in articoli relativamente poco importanti non ordinati o consegnati correttamente, altri errori possono costare alle organizzazioni ingenti somme di denaro o imporre ritardi nelle attività mission-critical.

Gli anelli aperti possono costare milioni di dollari

Per illustrare il punto, parlerò prima di una grande organizzazione farmaceutica che stava pagando le tasse su centinaia di milioni di dollari di apparecchiature che non riusciva più a rintracciare e voleva rimuovere questa spesa inutile. Il nostro progetto ha scoperto molti difetti di processo fondamentali, che si sommavano a decine di milioni di dollari di tasse inutili all'anno e altrettante spese per ordinare le stesse cose più volte per errore.

Comunicazione unidirezionale tra aree di responsabilità

Come tutte le grandi organizzazioni, le responsabilità erano in silos. Qualcuno nel settore manifatturiero ha bisogno dell'attrezzatura X, quindi informa Finance e viene generato un ordine di acquisto (PO). L'ordine invia l'ordine di acquisto al venditore. Fino a un anno nel futuro, X viene consegnato e accettato da Receiving. Ricevere notifiche Produzione e Finanza. Finance emette un tag asset, che Receiving schiaffeggia su X. X viene inserito nella linea di produzione e tutto va bene.

Tranne che non va tutto bene. Per cominciare, i dipendenti vanno e vengono ed è facile ordinare X senza rendersi conto che qualcun altro con lo stesso ruolo ha ordinato X nove mesi fa. Le finanze non hanno idea che questo ordine sia un duplicato: presumono che tu abbia semplicemente bisogno di un'altra X, quindi viene generato un altro ordine di acquisto e viene effettuato un altro ordine. A parte questo, anche se non ordini accidentalmente in eccesso, perdi rapidamente le tracce di ciò che hai.

Supponiamo che X sia un'attrezzatura complessa, forse un traguardo di riempimento. È composto da 20 componenti principali, che verranno tutti sostituiti più volte durante il suo ciclo di vita. Un'etichetta della risorsa schiaffeggiata a casaccio su una parte di X scomparirà a causa dell'usura. Peggio ancora, il tag asset potrebbe non essere nemmeno applicato perché non raggiunge la ricezione in tempo. Dopodiché, nessuno ha idea di come tenere traccia di X, e quindi non ha idea di come disattivarlo a fine vita. Dal punto di vista fiscale, X è ancora una voce imponibile funzionante.

Nel corso di oltre 20 anni, questo comincerebbe a danneggiare i profitti in modo non trascurabile. Inoltre, Finance utilizza una parte del proprio sistema ERP con un set di designatori di asset, mentre Manufacturing utilizza un modulo ERP completamente separato con un set diverso di designatori di asset. Alla fine dell'anno, nessuno può riconciliare le due serie di numeri e i revisori dei conti si chiedono perché hai decine o centinaia di milioni di dollari di discrepanza riguardo ai tuoi beni strumentali.

Questi sono i classici problemi derivanti da un insieme di processi aziendali a ciclo aperto. Il ciclo aperto è quando non si creano punti di conferma espliciti lungo la linea di flusso del processo. Nell'esempio sopra, c'erano così tanti processi ad anello aperto che il fallimento era garantito.

Creazione di flussi informativi bidirezionali

Ecco come abbiamo affrontato il problema. Abbiamo modellato ogni flusso di processo significativo dall'inizio alla fine. Abbiamo identificato tutti i circuiti aperti. Quindi abbiamo progettato modi semplici per chiudere quei circuiti, uno alla volta, a partire dall'inizio.

Primo passo

La produzione ha bisogno di X, quindi chiedono alla finanza di aprire un ordine di acquisto. Finance ora verifica con Manufacturing per confermare, fornendo i dettagli degli ordini precedenti per X risalenti a 24 mesi fa. Si evita la duplicazione accidentale degli ordini.

Passo due

La produzione fornisce a Finance un'analisi dei componenti di X che verranno sostituiti durante il periodo di servizio. Finance crea tag asset per ogni componente e conferma con Manufacturing. Entrambi i moduli ERP sono popolati con tag asset corrispondenti per componente, consentendo il monitoraggio attraverso il ciclo di vita degli asset.

Fase tre

Ricezione notifica Finance, che notifica Manufacturing. Il posizionamento delle etichette delle risorse viene eseguito da una parte responsabile della produzione per garantire che ciascuna etichetta sia posizionata sul componente corretto. Tutti i tag/componenti vengono quindi riconfermati per i due moduli ERP.

Fase quattro

Ogni volta che un componente viene sostituito, Manufacturing informa Finance e un nuovo tag asset per quel componente viene generato e inserito sul nuovo componente da Manufacturing, quindi confermato in entrambi i moduli ERP. La finanza inizia quindi il processo di rimozione del vecchio componente dai libri contabili mentre la produzione passa attraverso il processo di smantellamento della Good Practice Guide (GMP). Al termine della disattivazione, Manufacturing informa la Finanza in modo che l'asset possa essere ritirato dai libri contabili.

I dettagli sono un po' più complessi rispetto a questo esempio semplificato, ma il punto è chiaro: in ogni fase lungo la strada ci sono controlli e conferme espliciti.

Garantire le azioni di emergenza

In un altro progetto, mi è stato chiesto di aiutare un'azienda di servizi a migliorare i suoi tassi di soddisfazione dei clienti. La loro attività riguardava l'elaborazione dei reclami ed erano preoccupati di non riuscire a vincere le offerte. Inoltre, nelle loro offerte vincenti, la successiva insoddisfazione da parte dei clienti significava che il loro rapporto di perdita del conto era troppo alto.

Ci sono voluti solo pochi giorni per identificare il cuore del problema, che era ancora una volta i processi ad anello aperto. Quando un potenziale cliente chiedeva un'offerta, il gestore dell'account utilizzava il proprio sistema interno per inviare uno schema dei requisiti del cliente alla persona responsabile dell'assemblaggio dell'offerta. Il creatore dell'offerta creerebbe quindi l'offerta e la inoltrerebbe al cliente. Si spera che il cliente alla fine risponda, di solito con le modifiche desiderate, che il creatore dell'offerta incorporerà nella versione successiva. Ad un certo punto, il cliente avrebbe accettato l'offerta e un nuovo account cliente sarebbe stato creato da Accounting, una fattura sollevata e il team di onboarding informato.

Il primo problema era che non c'era una conferma esplicita dal creatore dell'offerta al gestore dell'account, quindi a volte le offerte non venivano create e inviate in tempo e nessuno lo sapeva. Ciò è stato possibile perché il sistema interno non aveva campi per mostrare una data di scadenza per un'offerta e, poiché il creatore dell'offerta era perennemente oberato di lavoro, ciò ha portato a presentare offerte troppo tardi. A causa dello scarso flusso di informazioni nell'azienda, queste situazioni non sono mai emerse.

Successivamente, le modifiche all'offerta non sono state trasmesse all'account manager. Questo era importante perché è stato l'account manager a informare il team di onboarding quando un cliente ha finalmente firmato sulla linea tratteggiata. Spesso il brief si basava sulla comprensione iniziale del gestore dell'account piuttosto che sull'offerta che il cliente aveva effettivamente accettato.

Una volta iniziato il coinvolgimento, i documenti del cliente sarebbero arrivati ​​e sarebbero stati inoltrati a qualsiasi membro del team nel pool di elaborazione fosse stato assegnato quella settimana per gestirli. Non essendoci una conferma esplicita di ricezione, è stato possibile che dei documenti sparissero senza che nessuno ne fosse a conoscenza, fino a quando il cliente non ha iniziato a chiedere perché non riceveva i risultati del lavoro di elaborazione.

Quando i documenti elaborati sono stati rispediti al cliente, non c'era conferma al momento della ricezione, quindi tutti i documenti mancanti sono stati persi da vedere fino a quando qualcuno da qualche parte ha iniziato a lamentarsi della loro assenza.

Conferma gli eventi chiave

In ogni fase del processo di offerta, abbiamo integrato conferme esplicite. Abbiamo creato soluzioni alternative per le carenze del sistema in modo da acquisire tutte le informazioni critiche, inclusa la data richiesta e le successive modifiche dell'offerta. Abbiamo implementato controlli e conferme esplicite per tutti i flussi di informazioni negli affari all'interno dell'azienda e tra l'azienda e il cliente.

Ad esempio, quando un cliente ha inviato un pacchetto di documenti, ora invia un'e-mail al gestore dell'account cliente per informarlo. Il gestore dell'account cliente lo trasmetterà alla parte responsabile nell'elaborazione dei reclami. Se i documenti non fossero stati ricevuti entro tre giorni, sarebbe stato lanciato un avviso. Quando i documenti sono stati ricevuti, è stata inviata un'e-mail al cliente di conferma della ricezione. Il contrario era vero anche quando l'azienda ha rispedito i documenti elaborati al cliente.

Poiché la maggior parte dei clienti utilizzava la posta statunitense per mischiare i documenti cartacei avanti e indietro, i processi a ciclo chiuso che utilizzavano controlli espliciti in ogni fase significavano che tutti i documenti smarriti potevano essere rapidamente identificati e adottare misure per correggere la situazione.

Procedure di gestione delle eccezioni di progettazione

Per vedere come le procedure di gestione delle eccezioni possono essere costruite in modo ragionevolmente leggero ma efficace, esamineremo un altro esempio del mondo reale che ho incontrato nella mia carriera quando ero il CIO di un'organizzazione di ricerca scientifica focalizzata sull'indagine sulle cause di l'invecchiamento e le cause scatenanti delle malattie legate all'età.

Tutti gli istituti di ricerca finanziati dai NIH contengono molti laboratori individuali, ognuno gestito da un investigatore principale (PI) e composto da vari scienziati subordinati e post-dottorati. Ad un certo punto, il PI ha bisogno di un nuovo vassoio per reagenti multicamera, quindi chiedono a uno dei dottorandi di creare la richiesta necessaria. Il post-doc crea la richiesta e la invia tramite e-mail a Finance per chiedere che venga sollevato un PO, inserendo in cc il PI per assicurarsi che il PI sia a conoscenza che la richiesta è stata inviata. Nel frattempo, il PI ha una notifica automatica del calendario impostata per ricordare loro di controllare lo stato della richiesta se non hanno ricevuto conferma entro una certa data. Ciò garantisce un meccanismo di sicurezza nel caso in cui il post-doc dimentichi di creare o inviare la richiesta necessaria.

Ora anche il post-dottorato ha una notifica automatica del calendario per verificare con Finance se non riceve la conferma dell'ordine di acquisto sollevato entro un determinato periodo di tempo. Quando Finance aumenta l'ordine di acquisto, il post-doc riceve un'e-mail di conferma che è stato inviato al fornitore e il post-doc inoltra questa conferma al PI.

In questa fase, il PI o il post-dottorato imposta un'altra notifica automatica del calendario per garantire che, se non viene ricevuto alcun riscontro dal venditore entro un determinato periodo di tempo, qualcuno verifichi con il venditore la ricezione dell'ordine di acquisto e l'invio del attrezzatura che è stata ordinata.

Supponendo che il venditore riconosca la ricezione dell'ordine di acquisto e spedisca l'articolo insieme a una notifica di spedizione, questa viene indirizzata al PI o al post-doc. Hanno quindi impostato una notifica di calendario finale per tre giorni dopo la data di ricezione programmata per assicurarsi che se l'articolo non si presenta, sappiano contattare il venditore per tenere traccia dell'accaduto e ricevere l'articolo correttamente. Se l'articolo arriva come pianificato, il post-doc informa Finance e se l'organizzazione utilizza tag asset, è possibile avviare questo insieme di processi.

In ogni fase del processo, è richiesta una conferma esplicita e un sottoprocesso disponibile per garantire che si verifichi un'azione correttiva in caso di interruzione del flusso del processo principale. Nulla viene lasciato sospeso, non confermato o non supportato. Non sono necessarie azioni ad hoc perché tutti sanno cosa è richiesto e cosa fare se le cose vanno male.

Imparare a creare processi a ciclo chiuso da SQL

L'essenza di un buon processo è molto simile al modo in cui i database relazionali basati su SQL sono stati progettati per garantire la coerenza transazionale. Qualsiasi azione deve essere confermata affinché possa essere considerata completata. Tutte le comunicazioni bidirezionali necessitano di una conferma esplicita integrata come parte del processo e di processi subordinati sviluppati per garantire che se la conferma non viene ricevuta, venga intrapresa l'azione corretta. I project manager di successo dovrebbero creare processi a circuito chiuso per migliorare il flusso di informazioni in un'azienda e far risparmiare alle organizzazioni grandi quantità di tempo e denaro.