I miei interessi ed il mio ambito lavorativo mi ha sempre portato ad avere una visione abbastanza ampia e non solo focalizzata su una tematica specifica. Oggi le mie competenze coprono diversi ambiti quali IT audit, information security, project e programme management, IT service management e Green IT. In questi ambiti ci sono sia standard ISO/IEC che best practices. Avendo una cultura non focalizzata che deriva sia dagli studi che ho fatto che dalle esperienze professionali nonché interessi personali mi è sempre piaciuto comprendere l’integrazione fra le diverse cose. Questo perché le cose sono molto connesse fra di loro molto più di quanto pensano gli specialisti di settore, andare a schematizzare e razionalizzare queste cose non è poi sempre semplice, ancor meno far si che queste integrazioni funzionino effettivamente nelle organizzazioni.
Il mondo ISO/IEC sta andando su dei concetti di coerenza delle norme fra di loro come dimostra l’Annex SL delle ISO/IEC “Directives Supplement” di maggio 2012 che ha come obiettivo quello di fornire tutte le indicazioni al fine di avere un allineamento di tutte le norme dei sistemi di gestione con una stessa organizzazione dei contenuti. Oggi già ci sono delle norme aggiornate a queste nuove linee guida e altre sono in lavorazione. Per alcune, come la ISO/IEC 20000 dovremo aspettare ancora diverso tempo probabilmente dato che l’ultimo aggiornamento risale al 2011 cioè poco prima della “Directives Supplement”. Questo purtroppo è solo un primo passo perché continuano ad essere presenti delle diversità di ambiti di certificazione e, sopratutto, di criteri di definizione degli stessi. Ad es. la ISO/IEC 27001 definisce un ambito o scope di certificazione mentre la ISO/IEC 20000-1 definisce dei servizi, quindi ci sono ancora diversità di “criteri”. Ma la strada di sistemi di gestione integrati oramai è intrapresa e li arriveremo.
Per parlare di integrazione mi piace guardare anche alle best practices e non solo agli standard e su quest ambito il mondo anglosassone da dei begli spunti. Il portfolio di AXELOS contiene molte best practices su tematiche limitrofe ma strettamente connesse fra di loro. Per intenderci sto parlando di ITIL, PRINCE2, MSP, M_o_R, P3O, MoV, ecc. Queste best practices hanno una caratteristica interessante che è quella di avere una stessa “mamma” quindi molta complementarietà e pochissima sovrapposizione. Per la sovrapposizione più che altro è un portare dei concetti base di una best practice per quella tematica in un’altra. Ad esempio in ITIL quando si parla di gestione dei rischi troviamo una sorta di M_o_R light in quanto spiega i concetti principali da sapere per qualcuno che sta vedendo la tematica di ITSM.
Discorso del tutto analogo lo si potrebbe fare con framework nord americani come CMMi for Services ed il PMI per project, program e risk management. Personalmente preferisco parlare di quelle AXELOS perché le conosco meglio e perché coprono tutto lo spettro.
La figura che vedete sopra prova a dare un po’ una collocazione alle diverse best practices. Con l’ultimo aggiornamento delle diverse best practices ha portato un maggiore allineamento e coerenza fra di lor, la cosa ancora non è perfetta ovviamente ma comunque è stato fatto un buon passo avanti rispetto a prima. Il collocamento del programme management (quindi di MSP) sopra al project management (quindi PRINCE2) penso sia quasi ovvia. Se poi andiamo a vedere più in dettaglio troviamo in PRINCE2 il processo Directing a Project che rappresenta proprio il punto di contatto fra progetto e programma di cui è parte integrante. La figura dell’Executive in PRINCE2 coincide con quella del Programme Manager di MSP. Qui trovate un White Paper AXELOS che da maggiori dettagli sulle connessioni, nota importante è che qui si parla di MSP ed. 2007 e non della versione del 2011.
Se iniziamo a ragionare dell’integrazione e relazioni fra ITIL e PRINCE2, quindi fra project management e IT service management, i ragionamenti diventano più ampi e più complessi. L’ambito dei servizi e quello dei progetti sono strettamente legati fra di loro, un servizio prima di essere messo in esercizio deve essere progettato (nel senso del termine inglese design) e poi deve essere messo in esercizio. Queste fasi sono delle fasi progettuali a tutti gli effetti. I vari processi che sono presenti nelle diverse fasi del ciclo di vita hanno spesso due anime, quella principale da cui deriva il collocamento all’interno della fase ed una “secondaria” che è più relativa ad un’altra fase (spesso il Service Operation). Se vediamo le fasi del ciclo di vita del servizio abbiamo che le attività che sono presenti nelle fasi del Service Design e nel Service Transition sono delle fasi progettuali almeno per quanto riguarda la loro anima principale quindi sono attività che ci troveremo a gestire con tecniche di project management (quindi PRINCE2). Quindi se vogliamo essere pignoli non sono tematiche di service management puro. Tutti gli aspetti del Service Design sono da gestire come progetti a tutti gli effetti, quindi la progettazione di uno SLA, la progettazione dell’availability, della continuity o dell’ISMS sono dei progetti; l’approccio PBS e non di WBS di PRINCE2 si colloca ed adatta bene a questo contesto. Se pensiamo alla fase del Service Strategy questa si collega di più a concetti di programme management (quindi MSP) in quanto riguarda più aspetti di scelta su cosa fare, pensiamo al Service Portfolio.
Ora proviamo a ragionare su M_o_R con le altre best practices. Qui è, sotto alcuni aspetti, più semplice. E’ più semplice perché le altre best practices già collocano la gestione dei rischi al loro interno, quindi già collocano M_o_R. Però se entriamo un po’ più nel dettaglio la cosa si fa’ più complessa ed articolata soprattutto se vogliamo dare coerenza alla risk analysis e al risk management in tutti i diversi ambiti.
In futuro vorrei provare a fare una mappa complessiva fra i diversi processi delle diverse best practices.