Comunicare in azienda per migliorare i processi

Ci siamo passati tutti: i piani alti dell'azienda hanno preso delle importanti decisioni con sostanziose ricadute sulle infrastrutture informatiche, senza consultarci. Ci siamo sentiti scavalcati, ignorati, trattati come l'ultima ruota del carro. Abbiamo vissuto il fatto come un'umiliazione della nostra professionalità e delle nostre competenze, lamentando la poca considerazione di cui gode la professione del tecnico informatico agli occhi del management aziendale. E poi ci siamo ritirati brontolando nel nostro ufficetto a configurare un server e a lanciare una sessione di test, aspettando la notifica delle nuove specifiche da adottare.

Non mi interessa parlare qui delle ragioni di questa scarsa considerazione. Ma ammettiamolo, a volte è anche colpa nostra. A questo proposito, parlavo tempo fa con il direttore di uno stabilimento. Gli avevo chiesto su quali competenze informatiche interne all'azienda potessimo contare per un piccolo progetto da avviare. "Conosco poco quelli del CED" fu la sua risposta, perché si accorgeva della loro esistenza solo dalle continue richieste di fondi per gli acquisti e per le lamentele sugli utenti, sulle password e "qualcos'altro che adesso non ricordo". Siamo onesti: non ci riconosciamo, almeno in parte, in questo quadretto?

Potremmo obiettare che forse chi comanda dovrebbe comunque conoscere i suoi uomini; ma non è questo il punto. Il ruolo del reparto IT dovrebbe essere quello di supportare a livello informatico i processi aziendali: portare soluzioni, non creare nuovi problemi. Se i livelli superiori tendono a escluderci dai processi decisionali che ci dovrebbero riguardare, cerchiamo il modo di intervenire. Positivamente. Mai in modo conflittuale.

Per proporre un caso concreto, legato al tema di questo blog, pensiamo alle norme sempre più stringenti su privacy e sicurezza dei dati. La nostra azienda potrebbe finalmente decidere di adottare misure adeguate (magari perché costretta...); oppure potrebbe sentire l'esigenza di certificarsi per l'ISO 27001. Riunione dopo riunione, le decisioni alla fine sono prese. E a conti fatti, ci arrivano le richieste - magari in conflitto tra loro perché fatte da responsabili di settori diversi - di adattare i sistemi alle nuove specifiche.

Avremo due possibilità: mugugnare sul lavoro da fare che porterà inevitabilmente una serie di nuovi problemi; oppure avviare un canale di collaborazione e comunicazione aziendale. In entrambi i casi il lavoro sarà fatto, ma i risultati saranno di gran lunga diversi.

Scartiamo la prima ipotesi, e concentriamoci sulla seconda. Raccogliamo le richieste che ci sono state fatte:

• riflettiamo su come implementarle: gli strumenti a disposizione sono sufficienti? L'acquisto di nuovo hardware/software porterebbe a un miglioramento quantificabile? Saranno necessari dei corsi di formazione e aggiornamento specifici per gli amministratori dei sistemi e per gli utenti? In tal caso, basteranno dei corsi tenuti da personale interno, o sarà più opportuno rivolgersi a consulenti esterni?
  

• valutiamo i possibili inconvenienti che potremmo incontrare, sia prima che dopo: l'implementazione richiederà modifiche di portata limitata, o saranno necessari cambiamenti radicali nell'infrastruttura? Abbiamo le competenze necessarie per farlo? È consigliabile una fase di test, o sarà necessario portare immediatamente i sistemi a livello operativo, accettando un margine di rischio di malfunzionamenti?
  

• valutiamo l'impatto che avrà l'adozione delle nuove specifiche sul lavoro quotidiano: come prevediamo che saranno accettate le nuove regole d'uso da parte degli utenti? È possibile semplificarle in qualche modo? Tutti i dirigenti, fino ai massimi livelli, sono pronti ad adottarle diligentemente a loro volta?
  

L'aspetto fondamentale di questa analisi non è solo individuare le criticità del progetto, ma proporre delle soluzioni fattibili. A questo punto avremo tutti gli elementi per stilare un rapporto da inviare a tutti i dirigenti coinvolti dal progetto, in spirito di collaborazione. Non deve essere necessariamente un dettagliatissimo mattone di centinaia di pagine: poche pagine ben scritte si faranno leggere più facilmente, e ci sarà sempre l'occasione per un eventuale approfondimento.

Al primo rapporto potranno seguirne altri per aggiornare i dirigenti sui progressi del progetto, sulle difficoltà impreviste che si sono incontrate e su come sono state superate (in tono piano, evitando espressioni imbarazzanti del tipo "grazie alle mie conoscenze tecniche...").

Se lo stile sarà correttamente propositivo, non interpretabile come una risposta polemica alle nuove esigenze aziendali, l'effetto sarà positivo. Magari si avvierà una discussione interna basata sulle nostre considerazioni per valutare meglio la portata del cambiamento; e forse saremo finalmente visti come una risorsa capace di collaborare, degni di essere consultati per le prossime decisioni.

E se l'effetto sarà opposto? Può succedere, purtroppo non tutte le aziende sono guidate da persone capaci di riconoscere e apprezzare adeguatamente i propri collaboratori. Sta a noi decidere se pretendere di meglio per la nostra professionalità, o se tornare a mugugnare in sala server.