La struttura per governare i processi

Come ho già detto la definizione di una struttura è legata all'organizzazione già esistente, quindi quello che segue è solo un esempio generico.

I ruoli da definire potrebbero essere:

BPO: Business Process Owner; spesso si tratta di un ruolo strategico, quindi viene affiancato da un

BPC: Business Process Coordinator; se l'azienda è complessa o distribuita geograficamente, probabilmente altre figure di Local Business Process Coordinator (LBPC) dovranno essere introdotte.

Mentre queste primi ruoli sono di provenienza Business, quello che segue è di estrazione IT (per esempio un analista di esperienza).

BIE (BIC): Business IT Expert (Coordinator); anche in questo caso in funzione della complessità aziendale altre figure tipicamente IT sono coinvolte in seconda battuta (responsabili di un prodotto/servizi IT).

Manca ancora un tassello; perché la struttura funzioni veramente bisogna identificare e inserire anche dei Key-User; utenti dei sistemi e applicazioni che per la vicinanza con l'esecuzione day-by-day del processo sono in grado di valutare l'efficacia degli interventi e suggerire e filtrare miglioramenti.

Questa struttura si troverà ad operare con il classico approccio della ruota a ciclo continuo di Deming: Pianifica, Fai, Controlla, Agisci (Plan, Do, Check, Act).

Dovrà inoltre pianificare meeting periodici (non troppi, non troppo pochi) e avrà, tra l'altro il compito annuale di stilare il Portfolio IT.

Naturalmente la struttura si ripeterà N-volte per ogni processo identificato.

L'insieme dei BPO, IT Manager e Board dell'azienda costituiscono insieme il Comitato Esecutivo.

Governare i processi

Per un Manager Informatico analizzare e descrivere un Processo Aziendale è qualcosa di familiare, un po' perché è una necessità che si incontra nell'analisi del software gestionale un po' perché i Sistemi di  Qualità lo richiedono.

Diverso è prendere in esame  il Governo di un Processo.

Governare un processo vuol dire saper individuare e proporre una direzione strategica, e non solo, significa impostare le priorità; approvare i budget, seguire i progetti nello stato di avanzamento, verificare il ritorno degli investimenti e naturalmente saper rendere conto di tutto ciò al Board.

Il governo di un processo non può essere efficace se non è condiviso con l'area IS (Information Services).

Ricordo ancora con incredulità quando un Direttore (preferisco non citare nel dettaglio il caso) mi chiese di "prestargli" delle risorse IT per poter costituire un centro di sviluppo e manutenzione sotto il suo diretto controllo. La sua idea era: io sono l'esperto del processo io mi gestisco le risorse incluse quelle IT. Insomma un'azienda nell'azienda.

Era una posizione inaccettabile, non per una mia difesa di potere, ma perché denotava una visione limitata delle potenzialità informatiche, ignorava completamente la necessità di avere in azienda un'antenna tecnologica, un consulente interno, pronto, perché esperto e dedicato alla funzione, a proporre e sfruttare le novità come opportunità di business; era un'idea che non teneva conto degli altri processi aziendali, delle sinergie possibili, delle sovrapposizione che si sarebbero verificate e, alla lunga, sarebbe stato fonte di extra costi.

Un'altro atteggiamento che contrasta con questa impostazione viene spesso attuata dagli amministratori delegati o dai direttori generali. Nel momento in cui si organizzano meeting di tipo cosiddetti Commerciale, i direttori IT, i direttori delle Risorse Umane, l'Organizzazione in generale, vengono esclusi pensando che farli  partecipare sia una perdita di tempo. 

Non dovrebbe essere così la dove si decide di Governare i Processi.

Ritorno quindi a caldeggiare un lavoro di team fra componenti di Business e IT per il governo dei processi.

Come un Direttore Commercial o un direttore Tecnico deve avere avere una consapevolezza delle opportunità tecnologiche, così anche il Direttore IT deve avere una competenza sul Business nel quale opera.

Non capisco e non approvo quei direttori IT che pretendono di ignorare il Business perché pensano che il loro ambito sono i Server, le reti i Sistemi, i servizi IT. Non bisogna poi stupirsi se con questa impostazione i software strategici subiscono dei ritardi e dei costi imprevisti. 

E' nel manico che mancava la sensibilità per impugnare e utilizzare bene l'attrezzo...

chi decide priorità e tempi di sviluppo delle applicazioni software in azienda

La domanda potrebbe essere questa: chi decide la direzione, le priorità e tempi di sviluppo delle applicazioni software in azienda?
Sono convinto che in giro c'è ancora qualche IT Manager che si sente ancora investito da questo ruolo; da svolgere da solo o insieme ad una ristretta cerchia di suoi collaboratori.
Un po' per ragioni storiche; un po' per difesa di poteri interni; un po', purtroppo, per mancanza di visione nella Direzione, ma penso che oramai dovrebbe essere abbastanza chiaro che una corretta gestione per processi, determina uno spostamento di questa responsabilità dall'area IT ai responsabili di processo.

Naturalmente, attenzione a non confondere processo con reparto. La definizione di reparto è strutturale e gerarchica, quella di processo è spesso trasversale e coinvolge differenti uffici interni, clienti e fornitori ed è legata a una sequenza di attività che a partire da un'origine (input) hanno il compito di realizzare uno scopo (output).

Dire che il business process owner (BPO) , cioè il responsabile delle attività di un processo, decide le priorità, detta i tempi, seleziona le funzionalità da far crescere, deve però uscire dalla teoria e diventare una pratica operativa all'interno dell'azienda.
Perché questa affermazione sia reale bisogna fare qualcosa.
E' evidente che le figure dell' IT non possono essere estranee a questo meccanismo,  ma laddove si è vissuto un periodo IT-centrico, bisogna rimodellare il contributo degli informatici all'interno di un nuovo paradigma. Gli analisti e analisti-programmatori senior sono i migliori candidati a recitare il ruolo di Business IT Expert (BIE).

Un'ipotesi di lavoro, che poi va personalizzata all'interno di ogni realtà organizzativa, è quella di dare spazio a una struttura dove BPO e BIE lavorano a stretto contatto.

Definire responsabilità e ruoli non è argomento esauribile in un singolo post.
Per il momento vorrei solo appuntarmi che è necessario che questi due gruppi di persone che, sia ben chiaro, hanno radici, conoscenze e approccio completamente differenti al lavoro, si mettano insieme per creare una sorta di portafoglio IT dinamico.

L'esperienza vissuta in questi ultimi anni mi fa anche aggiungere che comunque ci sono dei rischi da non ignorare; rischi che possono portare, estremizzati, ad una paralisi informatica, o a gravi perdite di produttività; mi ripropongo, nelle prossime settimane di illustrare a grandi linee, struttura, processo, compiti e focalizzare pro e contro.