Riorganizzare i servizi di Information Technology
di Davide Storni e Francesco Varanini
Si parla di BPR da anni ormai, eppure all’interno dei servizi informatici si riscontra quasi ovunque una suddivisione del lavoro basata su una logica funzionale e professionale (sistemisti, programmatori, DBA, …) nata e sviluppatasi con il diffondersi delle tecnologie di Big Blue.
Il servizio al cliente è declamato, ma raramente ne consegue un modello organizzativo che favorisca un effettivo riorientamento di compiti, meccanismi di controllo e sistemi di incentivazione.
Al più è possibile riscontrare la presenza di ruoli di interfaccia verso specifici settori di utenza che, seppur lodevoli nelle intenzioni, portano ad un appesantimento dei processi di comunicazione e non incidono realmente nei comportamenti.
Ma quali sono le controindicazioni ad una organizzazione basata su logica professionale?
La suddivisione del lavoro su base professionale consente un buon livello di approfondimento del know how specialistico. All’interno delle direzioni IT si sono nel tempo sviluppate diverse figure professionali riconducibili alle famiglie dei sistemisti, schedulatori, operatori, degli analisti-programmatori, ecc. che hanno seguito mode ed evoluzioni tecnologiche.
Così troviamo sistemisti host, sistemisti oracle, lotus notes, ….. figure che senz’altro rispondono all’esigenza di sviluppare know how specifico, ma tendono a concentrare l’attenzione sull’aspetto tecnico, tralasciando completamente le vere finalità di un servizio IT.
In un’organizzazione finalizzata (al profitto, come all’erogazione di servizi socialmente utili) lo sviluppo di know how deve essere una premessa alla costruzione di valore aggiunto da parte della stessa organizzazione. Può quindi evolversi verso la ricerca di efficacia (nuovi servizi, nuovi prodotti, maggior capacità di risposta ai bisogni del cliente, ….) o di efficienza (minori costi per l’erogazione dei servizi), ma sempre con una forte attenzione alla catena del valore.
È facile che direzioni o consulenti IT propongano approcci di CRM o di BPR, ma stranamente ciò non si manifesta in cambiamenti organizzativi interni ai servizi IT, dove il modello organizzativo rimane costante da almeno un trentennio (cioè da quando le direzioni IT hanno cominciato a svolgere una funzione importante nelle organizzazioni).
>>Solo recentemente si è manifestata la tendenza all’interno dei grandi gruppi di consulenza IT ad un’organizzazione più integrata nella logica di processo, dove però l’organizzazione formale contrasta ancora con gli orientamenti culturali e con i sub obiettivi dei diversi gruppi professionali.
La conseguenza di questa invariabilità organizzativa si manifesta in diversi modi:
· Scarsa attenzione ai livelli di servizio erogati;
· Forte orientamento verso soluzioni belle dal punto di vista tecnologico (anche se non sempre fondate dal punto di vista del business) con una continua lievitazione dei livelli di spesa;
· Difficoltà di problem solving (difesa delle scelte specialistiche a discapito del processo complessivo di erogazione dei servizi);
· Difficoltà di gestione dei progetti (per la presenza di culture/obiettivi differenti anche all’interno di gruppi costituiti);
· Orientamento della conoscenza solo in termini specialistici (e conseguente proliferazione delle parcelle ai consulenti di system integration);
Il risultato complessivo di queste spinte divergenti si traduce in una quasi cronica incapacità di rispondere alle esigenze del business e di generare un sia pur minino ritorno sugli investimenti (non ho ancora trovato un esperto IT che mi portasse un caso certificato di ROI positivo su un progetto IT).
Come conseguenza i vertici delle organizzazioni hanno cominciato a pensare all’IT non come abilitatore, ma come una sorta di “male necessario”, senza troppa convinzione riguardo ai ritorni attesi.
È possibile pensare a logiche organizzative più rispondenti alle esigenze di business?
La logica di processo può essere applicata anche all’interno di un servizio IT con una sostanziale modifica di ruoli, livelli di responsabilità, sistemi di apprendimento e di valutazione/incentivazione.
La logica di processo porta con sè un maggior orientamento all’utente, una maggior attenzione al ritorno sugli investimenti, una costante ricerca di efficacia ed efficienza anche internamente alle direzioni IT, l’avvio di processi di apprendimento legati all’efficacia dei sistemi e non all’approfondimento specialistico.
Non si tratta di introdurre cambiamenti spettacolari (e costosi), ma di imparare a guardare le cose da un’altra angolazione, quella del business invece che quella della famiglia professionale.
Di seguito vi proponiamo un modello che non ha mire universalistiche, anzi ci teniamo a ribadire l’importanza di costruire le soluzioni organizzative sulla base delle specifiche esigenze di business e degli specifici contesti culturali, ma vuole essere uno spunto di riflessione verso la costruzione di nuove possibilità.
Riorganizzare il servizio IT sulla base degli effettivi processi di erogazione dei servizi.
Premessa.
L’erogazione di servizi da parte dell’IT si manifesta ovviamente tramite l’erogazione di processi complessi che coinvolgono competenze e capacità diverse. E questo è sempre più vero con l’aumentare della complessità delle soluzioni IT.
L’abuso fatto degli ultimi anni della parola processo ci impone una definizione che chiarisca esattamente ciò che intendiamo.
Per processo intendiamo una serie di attività scatenate dall’evidenziazione di una esigenza da parte del cliente (interno o esterno che sia) e che porta alla soddisfazione della stessa.
Questo schema comporta l’inclusione del cliente nel processo, come punto iniziale (ciò che scatena il processo) e finale (la valutazione di efficacia/efficienza del processo stesso).
Questa impostazione differisce da altre impostazioni che si rifanno alla scuola della qualità o del controllo interno che vedono il processo come attività concatenate per la produzione di un output, e che tendono a concentrare l'attenzione dell'analista sulla completezza/congruità della sequenza di attività o sulla presenza o meno di adeguati sistemi di controllo. L'efficienza e la riduzioni di errori all'interno di un'attività o di una sequenza di attività, così come una classificazione dei processi che garantisca un adeguato sistema di controllo offrono senza dubbio un importante fonte di riflessione, ma non danno la dovuta rilevanza a ciò per cui i processi stessi sono stati creati, soddisfare una aspettativa del cliente. Porre questa al centro non significa tralasciare le riflessioni in merito all'efficienza o ai sistemi di controllo, che rappresentano comunque passi importanti nella riflessione sui processi. Significa invece dare priorità alla creazione di valore, che poi rappresenta il senso dell'operare organizzato.
L'impostazione gerarchica e funzionale delle organizzazioni tendo spesso a far perdere questo senso e a concentrare l'attenzione su sub-obiettivi, cosa che oggi risulta particolarmente vero per le strutture di servizio dell'organizzazione (direzioni IT, risorse umane, …).
Molto spesso l’IT si autopercepisce come qualcosa di “diverso” dal resto dell’organizzazione, una sorta di gruppo di iniziati che vive secondo proprie regole e sviluppando una propria cultura.
Pensare in ottica di processo implica il reinserimento dell’IT nelle logiche del business ed un ripensamento delle priorità:
· “è un ritardo accettabile”, “è normale che ci siano dei problemi” >>> quali disagi genero nei processi di business?, quanto costa la mia inefficienza?
· Abbiamo comprato la soluzione migliore sul mercato >>> quanto risponde alle esigenze del nostro business?, è un abilitatore o rappresenta un limite?
· Quali investimenti dobbiamo fare >>> qual è il Roi che possiamo generare, quali nuove soluzioni di business rendiamo possibili, …
Questo paradigm shift non deve però portare a perdere il contatto con le tecnologie, le culture specialistiche avanzate. Infatti l’apporto al business crea valore quando proviene da una competenza forte, aggiornata, in continua evoluzione.
L’attenzione al business deve aggiungersi e non sostituirsi alla cultura tecnica e tecnologica, pena la perdita di valore che il singolo specialista IT e/o l’intero gruppo possono apportare all’organizzazione.
Il passo in avanti consiste nella integrazione di competenze forti, nella capacità di utilizzare personalità e competenze differenziate rendendole funzionali al raggiungimento di un obiettivo comune, la creazione di valore per il cliente, inteso sia come cliente finale che come cliente interno.
Il primo step: individuare i processi
Nella logica contingency, i processi dovranno essere di volta in volta individuati e definiti, sempre partendo dall’individuazione dei clienti (non devono essere una categoria generica, ma individuati con attenzione) e dei loro fabbisogni.
È tuttavia possibile individuare alcune famiglie di processi con caratteristiche e finalità simili. In una caso specifico abbiamo individuato tre famiglie di bisogni e di processi.
1. Bisogno di soddisfare a mutamenti significativi nelle attese del cliente, tramite la realizzazione di nuove procedure/soluzioni tecnologiche >>> processo si sviluppo e realizzazione di nuovi progetti.
2. Bisogno di ottenere determinate prestazioni nei tempi e nelle modalità stabilite e compatibili con le esigenze di business seguendo le modifiche richieste dal divenire delle esigenze di business >>> processo di gestione e manutenzione evolutiva di procedure informatiche in essere.
3. Bisogno di assistenza nell’uso di procedure e/o strumenti >>> processo di erogazione di servizi di assistenza e formazione.
Tutti questi macroprocessi partono dall’evidenziazione di un bisogno di una specifica famiglia di clienti e possono essere valutati come rispondenti o meno al fabbisogno attraverso la determinazione di parametri di performance che varieranno in base alla famiglia di processi in esame e ovviamente alle specifiche esigenze del cliente che andremo a servire.
Esistono poi delle famiglie di processi interni al servizio informatico che hanno come scopo
· La costruzione di capacità e il monitoraggio dell’efficienza/efficacia interna dei sistemi;
· La erogazione di capacità elaborativa e di connessione;
· Il mantenimento di sistemi di sicurezza.
Questi processi che definiremo infrastrutturali non sono sempre visibili dal cliente, ma risultano determinanti per il raggiungimento dei livelli di servizio attesi da questo.
Se, per esempio, partiamo dalla esigenza di un cliente che deve accedere a servizi internet, la disponibilità 24*24, la facilità e la velocità di accesso, la sicurezza, sono elementi altrettanto importanti della navigazione e dei contenuti predisposti dalla procedura applicativa.
I processi infrastrutturali hanno quindi un impatto sul cliente finale, ma hanno anche un cliente interno ben definito, l’utilizzatore di capacità, solitamente colui che gestisce la procedura applicativa.
Possiamo quindi individuare più livelli di processi, inserendoli in una catena del valore e legandoli in una logica di cliente fornitore.
Ogni volta che esiste un punto di contatto con un cliente finale o interno che sia esiste la possibilità di definire aspettative e parametri di soddisfazione, in modo da misurare l’efficacia del servizio fornito.
Step due: l’organizzazione.
Ogni processo così individuato dovrà avere un process owner, responsabile del livello di servizio erogato.
Sarà con questo process owner che il cliente interfaccerà per manifestare le proprie esigenze e per trattare i livelli di servizio richiesti.
È importante capire che questo nuovo ruolo si definisce a partire dal cliente di riferimento e dalla tipologia di fabbisogno e non in base ad una appartenenza professionale.
La definizione dei ruoli a partire dal cliente dovrà rispecchiare il processo di identificazione dei processi. Per ogni processo dovrà essere individuato chi sarà responsabile della funzionalità del processo e dei livelli di servizio.
Nei casi concreti dove stiamo operando abbiamo definito due nuovi ruoli di interfaccia con il cliente:
· L’operation supervisor che è responsabile della gestione e della manutenzione evolutiva di una procedura o di un insieme di procedure atte a garantire un ben individuato servizio a un ben individuato cliente interno;
· Il project manager che è responsabile della costruzione di una nuova procedura, di una nuova piattaforma tecnologica o di una nuova architettura, ed è misurato sul fitting fra risultato del progetto e fabbisogni del cliente, nonché su tempi e costi relativi al progetto stesso.
Perché queste responsabilità siano reali è indispensabile che l’operation supervisor e il project manager abbiano le leve per poter raggiungere il loro obiettivi.
In particolare dovranno operare nell’individuare e gestire le risorse necessarie al raggiungimento del loro obiettivo (interne, outsourcer, strumenti, …) garantendo i livelli di efficacia ed efficienza concordatied operando su tutto il processo (procedura, architettura tecnica e applicativa, livelli di servizio, …).
È chiaro che una figura di questo tipo non può essere completa in uno schema gerarchico funzionale tipico delle attuali strutture di IT.
È infatti un figura trasversale (ogni processo richiede competenze differenziate), con doti di negoziazione e di vision molto forti. La negoziazione opera a due livelli, nei confronti del cliente e nei confronti dei fornitori di servizi, siano essi outsourcer (sviluppatori) o responsabili di processi infrastrutturali interni con i quali dovrà concordare i livelli di servizio necessari per la soddisfazione del proprio cliente finale.
Ed è una figura con notevole responsabilità, perché l’output finale dipende completamente da lei, sia per le attività direttamente gestite sia per quelle “comperate” da altri processi/fornitori.
Questi nuovi ruoli richiedono forti competenze di negoziazione, gestione delle risorse, autorganizzazione, oltre a competenze tecnologiche ampie, capaci di capire le problematiche relative a applicativi, comunicazioni, architetture. Il coordinamento di specialisti è infatti necessario per garantire un risultato complessivo di eccellenza, curando però sempre l’obiettivo complessivo del processo e il fitting con gli obiettivi di business.
I processi infrastrutturali avranno anche loro un process owner o operation supervisor che provvederà all’organizzazione delle risorse a sua disposizione per garantire livelli di servizio concordati.
Si delinea così la catena del valore che comprende processi infrastrutturali e di erogazione del servizio finale, interni ed acquisiti dall’esterno.
Per garantire però un elevato livello qualitativo dei servizi di IT è necessario, parallelamente all’introduzione della logica di processo, sviluppare e diffondere le competenze tecniche specifiche e approfondire la conoscenza delle esigenze di business.
La conoscenza dei processi di business è importante per garantire un apporto critico e propositivo da parte dell’IT, in particolare nei processi di sviluppo di nuove procedure. Questa attività richiede un ruolo specifico che comporta competenze legate ad uno determinato settore di business unitamente ad una profonda conoscenza delle opportunità e dei vincoli dell’informatica.
Il mix di competenze è difficile da costruire. A volte può essere una persona proveniente da un settore di business il candidato più opportuno per questo ruolo, a volte gli analisti di organizzazione (o i consulenti) rispondono a queste esigenze.
Il mantenimento del presidio tecnico è un’altra attività importante nella riorganizzazione dell’IT.
L’orientamento trasversale, per processo, di project manager e operation supervisor richiede il ricorso a specialisti che vengono integrati attorno ad un obiettivo comune. Questi specialisti devono garantire un profonda conoscenza della evoluzione delle tecnologie confrontandosi con il mercato.
Il mantenimento di competenze specialistiche in azienda risponde all’esigenza di selezionare le offerte di collaborazione provenienti dal mercato e quindi effettuare le scelte più corrette in termini tecnici e, dialogando con i responsabili di processo, di rispondenza alle esigenze di business.
Proprio la dialettica fra esperti tecnici e esperti di processo dovrebbe garantire il corretto mix fra ricerca della soluzione più avanzata e rispondenza alle specifiche esigenze di business.
Riassumendo si sono individuati quattro nuovi ruoli ognuno responsabilizzato su specifici obiettivi;
· Project manager: garantisce la compatibilità del risultato di un progetto rispetto alle esigenze di business;
· Operation supervisor: garantisce i livelli di servizio richiesti dal cliente esterno (procedure applicative e assistenza) e interno (processi infrastrutturali);
· Specialista IT: garantisce l’allineamento delle competenze rispetto all’evoluzione del mercato tecnologico e la diffusione delle stesse all’interno dell’IT;
· Esperto dei processi di business; favorisce il dialogo con i clienti e garantisce la corretta interpretazione delle aspettative del cliente.
Esisteranno tanti operation supervisor quanti sono i processi gestiti dall’IT, e per ogni processo dovranno essere definiti dei livelli di servizio (o SLA service level agreement). Questi saranno identificati partendo dall’output richiesto dal cliente interno o esterno (quanti output, tanti accordi) e dovranno essere costantemente aggiornati.
Leggendo i nomi dei ruoli può sembrare che il cambiamento non sia radicale, perché i capi progetto esistevano anche nella vecchia organizzazione, i responsabili delle procedure (assimilabili agli operation supervisor) pure. Quello che cambia in modo radicale è la tipologia di responsabilità inerente ai ruoli. Mentre oggi il responsabile gerarchico governa una procedura, gestisce progetti, analizza i processi di business e si inventa esperto informatico, nel nostro schema queste diverse responsabilità vengono affidate a ruoli distinti, più specializzati, responsabilizzati su risultati complessivi, mentre oggi i limiti della competenza gerarchica portano spesso ad alibi e a perdere di vista la finalità principale di un ruolo, cioè la produzione di output attesi da un cliente.
Così nell’impostazione per famiglie professionali e dove prevale il concetto gerarchico capita che il capo progetto dichiari che il non raggiungimento dei risultati non dipenda da lui, perché gli outsourcer o le persone dei sistemi o …. non hanno fatto quanto concordato. Nella nuova impostazione il capo progetto è responsabile del controllo degli outsourcer e del risultato complessivo del progetto, essendogli stati affidati i livelli di delega e le risorse necessarie per il compimento del progetto stesso.
Analogamente essere responsabili di una procedura significa avere come riferimento il cliente con il quale vengono definiti dei livelli di servizio, che sono contemporaneamente oggetto e base del dialogo fra le parti. Tutto il ciclo di produzione che porta all’erogazione del servizio è di responsabilità dell’operation supervisor, che dovrà ora gerarchicamente, ora con accordi sugli SLA o con contratti di outsourcing garantire il risultato atteso.
Il cambiamento significativo, e culturalmente difficile da realizzare, consiste quindi nell’orientamento ai processi e al cliente più che nei nomi dei nuovi ruoli.
Conclusioni (per il momento).
Riorganizzare i servizi di IT per processo significa includere il cliente in modo sistematico sia nella pianificazione dei servizi, sia nella erogazione degli stessi.
Questo comporta una forte responsabilizzazione rispetto alle aspettative dei clienti, prima ancora che rispetto alla propria linea gerarchica.
Questa diviene garante dell’organizzazione complessiva del servizio rispetto alla Direzione Generale, mentre il dialogo con il cliente è garantito dai ruoli di interfaccia (PM, operation supervisor).
L’orientamento ai processi ed al cliente devono parallelamente prevedere un forte impegno sul processo di sviluppo delle competenze interne, al fine di evitare situazioni di obsolescenza professionale e/o di difforme diffusione delle competenze. Questo è un processo chiave sia per garantire una corretta selezione delle offerte di beni e servizi da parte del mercato, sia per consentire all’azienda un processo decisionale corretto (nuovi investimenti, aggiornamenti tecnici, …) che non sia frenato da una conoscenza parziale o non aggiornata delle tecnologie e dei software.
L’attenzione alla gestione della conoscenza è ancor più importante in un organizzazione per processi dove il livello di competenza è riverificato di continuo a partire dai risultati e dalla negoziazione con i clienti e i fornitori.
Riorientare l’organizzazione dell’IT richiede quindi un supporto formativo forte, per favorire il passaggio dal ruolo dichiarato al ruolo agito, ma anche per garantire l’evoluzione delle competenze necessarie a far fronte alla dinamica di mercato (inteso come mercato dell’IT) e alla dinamica delle esigenze di business.