Quando cambiare non è una scelta

Trattando "cambiamenti" questo post è stato pubblicato prima nel mio blog personale a
http://tre-chiavi-inglesi-in-dubbio.blogspot.com/2012/02/quando-cambiare-non-e-una-scelta.html

ma trattandosi di argomenti legati al counseling aziendale, mi sembra opportuno aggiungerlo anche in questa sezione.

Ci sono cambiamenti dovuti ad eventi che uno non si andrebbe mai a cercare. Uno di questi casi è la perdita del posto di lavoro.

Succede; si scatenano delle emozioni; è inevitabile che ci sia un momento di confusione e smarrimento; si può avere l'opportunità di accrescere la propria consapevolezza che, attraverso un'accettazione della nuova situazione, diventa il punto di partenza per cogliere un insight - una illuminazione, per individuare la giusta direzione da prendere.

La prima domanda potrebbe essere: perché e cosa cambiare? La perdita del lavoro non è stata frutto di un mio errore, di difficoltà nel rapporto con l'azienda o di una carenza professionale. Una ristrutturazione... un ridimensionamento, una centralizzazione, la conseguenza di una crisi del mercato...

Tutto vero ma... è successo! Ed è un dato di fatto che, senza lo stimolo derivante da un evento, la spinta al cambiamento è quasi impossibile.

Sì, si potrebbe decidere di non voler cambiare nulla, ma come ho già scritto in qualche post precedente, il mio desiderio non è girare l'interruttore e ripristinare la stessa situazione di prima. Troverei triste non aver saputo approfittare di questo momento per crescere, o almeno provarci.

Per esempio comprendere e valorizzare l'idea che non esiste un io "professionale" con i suoi attributi costituiti dalle esperienze di lavoro, dai ruoli svolti nelle varie aziende, le realizzazioni fatte, i corsi frequentati, le competenze costruite, e un altro io "personale" con i suoi attributi di natura umana, interessi individuali, rigidità o flessibilità, storia personale ecc.

Che le due "io" si compenetrano uno con l'altro dovrebbe essere abbastanza chiaro e accettabile; diverso è tirarne fuori un paradigma utilizzabile nella propria vita.

In questo periodo di cambiamento sono coinvolti i miei interessi, la rete delle mie conoscenze, la cerchia di persone che mi sostengono, gli scambi di comunicazione che avvengono, i valori che decido di mettere in luce.

Ieri ho frequentato un seminario che partendo da queste considerazioni ha gettato dei semi per sapersi muovere in questo percorso e decidere cosa si vuole diventare. 

Mi sembra giusto aggiungere che è stato guidato da Maria Cristina Manicardi di MIR-LA TENDA (nel nome il programma da scoprire).

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.