Oggi espressioni come ‘approccio sistemico’, ‘visione integrata in azienda’, ‘fusione dei processi di business’, non sono più esclusive del lessico dei consulenti e degli altri ‘addetti ai lavori’. Stanno invece entrando, sia pur lentamente, nel vissuto di ogni impresa, permeandone la cultura e guidandone le scelte di sviluppo. Anche i sistemi informativi non possono trascurare la dimensione organizzativa. Un piano Ict che non origini da un’analisi del contesto in cui va a porsi, infatti, è un piano che può presto rivelarsi inadeguato, finanche dannoso.
Occorre ricordare che un sistema informativo nasce per risolvere problemi concreti; se questi non sono individuati con chiarezza, se non sono note le esigenze da soddisfare e le aspettative dei fruitori, il rischio del fallimento è davvero dietro l’angolo. E, a tale proposito, non si sottolineerà mai abbastanza il ruolo cruciale del coinvolgimento e della motivazione del management, come dei quadri e dei livelli esecutivi. Convincersi (ovviamente a ragion veduta) che il sistema che si va a realizzare è davvero funzionale, significa affrontare con maggior serenità le difficoltà dell’implementazione.
Ancora una volta, quindi, è dal ‘conosci te stesso’, che bisogna partire, ma questo passo, sebbene fondamentale, resta insufficiente se poi, a struttura realizzata, mancano gli strumenti di misura e controllo. Ma come si governa la complessità? Facendo ricorso a procedure, unità di misure e requisiti: tutti elementi che permettono di fare ordine nel disordine e di verificare la corrispondenza tra le attese e le prestazioni reali.
Il Service Level Agreement nell’azienda complessa
Verificare la qualità, vale a dire accertarsi che ciò che si acquista e ciò che si installa soddisfi i requisiti che ne hanno consigliato l’acquisto e l’installazione, è la missione fondamentale di un Service Level Agreement, il punto di incontro tra fornitore e acquirente, il luogo in cui diventa esplicito tutto ciò che è implicito nella fornitura di un servizio.
Perché un accordo si realizzi sono necessari due partner; nel nostro caso, uno è quello di business, l’azienda che cerca e chiede il servizio, e l’altro è quello che eroga quanto richiesto, il service provider appunto. Quanto al servizio stesso, il termine è intenzionalmente generico perché si spazia dal sistema informativo, all’help desk, dal contact center, ad applicazioni mirate e strategiche per il business. L’ambito di applicazione è vasto almeno quanto ampia è la gamma di proposte dell’It. I punti invarianti dell’accordo sono invece: la dichiarazione di intenti delle parti, la descrizione del servizio e del contesto operativo, la disponibilità del servizio e infine le misure adottate per monitorare quanto erogato. A ben guardare, si tratta di una struttura che rispecchia l’essenza dell’It Governance e, in effetti, un Sla può trasformarsi in un valido sostegno alle attività di pianificazione in azienda, perché identifica in modo univoco le aspettative, le traduce in un linguaggio condiviso dai partner impegnati e fissa le condizioni che determinano il contesto operativo. Insomma, l’Sla quasi si configura come “mediatore” tra la cultura dell’It e la cultura del business, suscitando dialogo e confronto anche là dove questi sono più difficili.
Al Symposium It di Gartner dello scorso novembre, è emersa con forza, come nuovo tema conduttore dell’Ict, la ‘Business Process Fusion’, la fusione cioè dei processi del business, un concetto che trascende il tema della re-ingegnerizzazione tipica di questi ultimi anni. Ancora una volta, gli analisti hanno usato un riferimento preso dalla natura per descrivere un fenomeno di natura organizzativa. Come nella fisica un processo di fusione sottintende un ‘rimescolamento’ delle strutture originarie degli elementi che si fondono per creare qualcosa di nuovo e di inedito, così fondere due processi di business (interni o esterni, poco importa) significa crearne di totalmente nuovi. La Business Process Fusion (Bpf) non riorganizza i processi, ma ne crea di nuovi, in base ai cambiamenti del mercato e del contesto in cui l’organizzazione si trova ad operare. E l’azienda che cambia ha bisogno di strumenti dinamici che ne accompagnino il mutamento crescendo con lei.
Questo quadro di cambiamento coinvolge necessariamente anche i Service Level Agreement, la cui attuale filosofia realizzativa è tuttora improntata al controllo dello status quo. Proviamo invece a pensare a quanto complesso possa diventare il controllo di processi che non solo cambiano nel corso del tempo e della vita di prodotti e servizi ma si fondono generandone di nuovi. Perché tutto ciò non si trasformi in una babele di attività è necessario dare una visione prospettica agli strumenti di governo disponibili; vale a dire, introdurre la dimensione del cambiamento nei sistemi informativi come nei Service Level Agreement.
La lettura di tipo organico che si porta dietro quest’approccio trascende la visione meccanica e lineare dei problemi. Non è più sufficiente assegnare una sequenza logica agli eventi; è indispensabile individuare e costruire la mappa delle relazioni di ogni singola attività, indagare le finalità dei processi e individuare la natura dei problemi quando e dove si manifestano. Gli Sla attuali, però, molto poco ci possono dire sulle cause di errori e problemi. Evidenziano un disservizio, ma perché questo non si ripeta, bisogna capirne le ragioni. Ecco allora che, fermo restando il prezioso contributo degli Sla nel sistematizzare i rapporti fornitore-acquirente, il passo successivo è quello di affrontare questo aspetto in una logica dinamica, dove il livello di servizio viene ‘gestito’ e si parla quindi di Service Level Management (Slm). .
Il Service Level Management
Il Chief information officer oggi ha il compito di creare un ponte tra il business e le tecnologie. Sincronizzare scelte di business e tecnologiche (magari anticipando le richieste del mercato), controllare costi ed efficienza del servizio fornito, misurare, verificare e comunicare i risultati di tali analisi sono dimensioni tipiche del suo lavoro, in cui rientra anche la stesura di un Sla come l’impostazione di un Slm. Perché Sla e Slm siano strumenti utili al governo dell’It è necessario però che la dimensione relazionale sia rispettata sin dall’inizio. Nel senso che l’uno e l’altro sono il risultato di un gruppo di lavoro a cui si chiedono doti creative, di analisi e di negoziazione. E nel senso che sono servizi che per funzionare hanno bisogno che tutti coloro che sono coinvolti, a tutti i livelli (compreso quello esecutivo) ne condividano la filosofia per ‘forma mentis’ ancor prima che per intesa contrattuale.
Molto delicata è poi l’individuazione delle metriche, non solo perché ogni modello di business ha la sua specificità, ma soprattutto perché è difficile tradurre percezioni in indici misurabili. Riflettiamo sul concetto di affidabilità o di disponibilità e pensiamo a quante sfumature ci sono nella loro individuazione a seconda del contesto di lavoro. Riflettiamo sul valore del ‘real time’ e sulla capacità del sistema informativo di rispondere, appunto in tempo reale: esiste una definizione univoca? No, perciò è necessario comprenderne la natura e tradurne le caratteristiche per ogni contesto. Ogni Sla è dunque una creazione a sé stante e pur avendo, dal punto di vista costruttivo, tratti in comune con tutti gli altri Sla implementati, ha una ‘personalità’ propria che è espressione del gruppo di lavoro che ha interpretato le istanze dei partner.
Quali sono allora gli orizzonti evolutivi del Service Level Agreement? Non è difficile immaginare che al crescere della complessità organizzativa possa seguire una pressante richiesta di normalizzazione e semplificazione delle procedure; gli Sla potrebbero quindi diventare strumenti preziosi. Gartner, ad esempio, ritiene che l’espansione del Business Process Outsourcing ne potenzierà l’adozione.
La frontiera sembra comunque essere quella dell’Slm, con un approccio strutturato alla misura dei servizi, alla ricerca delle cause dei problemi, allo sviluppo dell’ assistenza per offrire una piattaforma di governo della complessità che si raccordi con le attività di change management. Sono infatti tre i livelli che caratterizzano il modello Slm: il primo è quello del problem e change management; il secondo è l’access, availability e performance management: il terzo è quello riservato al monitoraggio del livello di servizio, quello in cui, dal punto di vista logico, possiamo collocare l’Sla, in quanto interfaccia tra fornitore e cliente.
Se da un lato (quello dell’Slm, appunto) ho un sistema, dall’altro ho un componente di questo sistema (l’Sla): la differenza concettuale tra i due acronimi è tutta qui e sottende due ottiche diverse, la prima, in fieri, concentrata sui processi, la seconda, consolidata, concentrata sul singolo evento esaminato come elemento discreto.
