La gestione del rapporto che, all’interno di una qualsiasi organizzazione, s’instaura tra chi eroga i servizi informativi e chi ne fruisce è un tema fondamentale per chi, come da sempre fa la comunità di ZeroUno, considera l’informatica come strumento di crescita e competitività di un’impresa. Dalla qualità di questo rapporto, dal fatto cioè che si sviluppi nell’ambito di una naturale dialettica tesa a una fattiva collaborazione tra le parti, piuttosto che in quello di un artificioso antagonismo teso ad affermare le rispettive aree di potere, dipende infatti la maggiore o minore capacità della funzione It di assolvere al suo compito di sostegno e propulsore del business.
Tra le soluzioni che sono state via via elaborate per aiutare le organizzazioni a gestire le relazioni tra le funzioni aziendali, il cosiddetto ‘demand management’ è quello che oggi pare più adatto ad assolvere uno dei punti fondamentali del rapporto tra il fornitore dei servizi It e i suoi utenti. Volendone infatti dare una definizione, si tratta, come sintetizza Paolo Pasini (nella foto), professore Information Systems Management della Sda Bocconi, di un “organizzatore di richieste”. Vale a dire, chiarisce Pasini, di “un processo strutturato che ha l’obiettivo di raccogliere, e se possibile anticipare, i fabbisogni informativi dei clienti interni dell’It; di comprenderne le finalità e di valutarne le priorità”. Non è, come si vede, un compito da poco, ma in quelle aziende che hanno un’utenza interna vasta e differenziata, che genera un grande volume di richieste, diventa inevitabile come processo a monte e, per così dire, ‘alimentatore’ del Project (o Application) Portfolio management, indirizzato a gestire la funzione It assegnando al meglio risorse e priorità. Anche nelle piccole e medie imprese il demand management è un qualcosa che va fatto, ma, dice Pasini, solo “quanto basta”, ossia senza esagerare nella strutturazione del processo per non rischiare di ‘ingessare’ la relazione business-It in una inutile burocrazia.
Il problema principale del demand management sta nella necessità di mettere e punto un processo che sia ben strutturato nelle sue fasi e definisca con chiarezza ruoli e compiti delle persone che vi sono coinvolte. Come si può capire, non esistono formule universali applicabili a qualsiasi realtà. Le ‘best practices’ raccolte dalle ‘librerie’ dell’Itil e del Cobit, sono un buon punto di riferimento (soprattutto l’Itil, osserva Pasini, affronta il tema con un certo approfondimento riguardo la struttura del processo), ma ogni impresa deve trovare la propria strada nel definire un processo e una figura di demand manager che, senza rinunciare ad alcuna delle prerogative che più avanti vedremo, si collochi per quanto possibile in modo armonico nell’organizzazione esistente.
Sotto l’ala del Cio
Sempre sul piano dell’organizzazione, è importante che questa strada sia tracciata da chi è a capo dei Servizi Informativi. Sia pure operando, come è ovvio, di concerto con le figure responsabili del business, o meglio ancora con le Direzioni Generali (qualora la funzione It sia una DG), spetta al Cio farsi promotore dell’iniziativa e guidare la strutturazione del processo e la definizione dei compiti del demand manager. Questo (anche) affinché la figura della persona nel cui lavoro si concretizza il processo di gestione della domanda di servizi It, finisca, in modo quasi naturale, per emergere dalle sue file e rispondere a lui direttamente.
Va detto che questa, allo stato attuale delle cose, è la situazione prevalente in quelle imprese dove il demand management è stato organizzato. Esistono però altre situazioni, che sono frutto della storia e della cultura della singola impresa nonché, ovviamente, delle caratteristiche delle risorse umane disponibili. Così, in molte aziende il demand manager proviene dalle file del business, è in organigramma presso le funzioni utente e da queste dipende; in altre invece, pur essendo presso l’It, non risponde al Cio ma al responsabile dell’area applicativa. Nel primo caso (che a volte si presenta con più figure dedicate alle diverse funzioni aziendali, con un demand manager per il marketing, uno per il finance e così via), il problema è, evidentemente, che una figura la cui attività influenza quella dell’It non solo non è da questa gestita, ma può anche non avere una conoscenza dei processi It adeguata a reggere il dialogo, limitandosi quindi a far da portatore di istanze. Nel secondo caso, invece, sono un po’ troppo enfatizzati i compiti, per così dire ‘interni’ all’It relativi al portafoglio applicativo (la cui gestione peraltro non è di sua competenza) rispetto a quelli della gestione della relazione ‘esterna’ con l’utente business, che come vedremo sono i più importanti. Esistono infine aziende dove sono presenti entrambe le figure: un demand manager presso l’It che ha il suo interlocutore in un ‘esperto It’ posto presso le funzioni utente. Si tratta di una situazione ottimale, che semplifica il dialogo, ma, come osserva Pasini, “non tutti se lo possono permettere”.
Mille cose da seguire
Vediamo allora quali sono responsabilità e compiti di questa nuova figura aziendale, delicato punto di snodo fra business e It, il cui ‘identikit’ ideale lo identifica come una persona che, dotata di un’ottima conoscenza della struttura e dei processi It dell’impresa (preferibilmente maturata all’interno della stessa), abbia sviluppato una particolare attenzione verso i problemi del business, a volte con una specializzazione per aree aziendali. Specie nelle grandi imprese esistono strutture di demand management con manager specializzati per l’area commerciale, per l’area amministrativa e così via. Fondamentale per tutti, è infine l’essere dotati di un’innata capacità di relazione.
Infatti, come chiarisce Pasini: “La prima grande responsabilità è certamente quella di gestire la relazione con il cliente interno lungo tutto il processo di gestione della domanda”. Sul piano del compiti, la cosa si complica perché si entra in un ambito dove si possono, per così dire, immaginare tante cose da fargli fare”. Tra i compiti principali del demand manager abbiamo in primo luogo quello di organizzare i momenti d’incontro con la sua clientela interna, cioè con il business, definendone le modalità d’indizione (con quale periodicità per gli incontri programmati e in base a quali eventi per quelli non programmati) e quelle di svolgimento, cioè chi vi deve partecipare, dove e come (se di persona, in teleconferenza e così via).
In secondo luogo, deve stabilire le modalità formali di raccolta delle richieste (sia nei momenti d’incontro, sia al di fuori di questi), arrivando a definirne tempistica, eventuale modulistica e quant’altro. Ora, è intuibile come, a seconda delle dimensioni, dell’organizzazione e anche della ‘cultura’ aziendale, vi siano realtà dove queste cose avvengono in modo abbastanza informale ed altre dove invece viene tutto formalizzato; l’importante è che tutte le ‘caselle’ relative agli incontri tra business e It e alla raccolta delle istanze vengano riempite e che il demand manager tenga traccia di tutto il processo. Una qualche formalizzazione diventa quindi prima o poi necessaria.
Una voce per il business
“Un altro compito importantissimo – prosegue Pasini – è quello di definire la descrizione dei fabbisogni informativi”. Si tratta, in pratica, di dire come il business debba esporre le sue istanze, chiarendo con termini univoci quali sono gli obiettivi che l’utente intende raggiungere con la sua richiesta e quali le macrofunzionalità che si vogliono realizzare. A ciò va aggiunta una breve sintesi (“un minimo”, dice Pasini) della fattibilità tecnica ed economica e della previsione sugli impatti organizzativi. Si tratta, fondamentalmente, di una questione di linguaggio, ma sappiamo che gran parte delle incomprensioni e delle difficoltà di rapporto tra business e It nascono proprio dal parlare lingue diverse. In genere, si usano allo scopo strumenti molto simili a quelli degli studi di fattibilità che, in modo più o meno approfondito, dicono come questi fabbisogni vadano esplicitati.
Questo punto è importante perché le richieste degli utenti interni possono tradursi, per l’It, in una gamma di attività che va da banali interventi sulla procedura a veri e propri progetti applicativi che ogni azienda classifica in modo diverso, con termini convenzionali propri (tipo: piccola manutenzione, manutenzione evolutiva, progetti di cambiamento, progetti di innovazione e così via) per definirne la complessità. Non si chiede al demand manager di valutare, per così dire, ‘il peso’ di una richiesta ai fini dell’impegno e dell’impatto sulla funzione It, ma di fare da interprete tra utente interno e It recependo sia le richieste del primo, che deve chiarire, oltre ad obiettivi e funzionalità anche e soprattutto quali siano i ritorni attesi in termini di business, sia le risposte della seconda quanto a costi e tempi, e traducendo il tutto in termini univoci e comprensibili per entrambi gli interlocutori.
Gli strumenti per fare
Per svolgere le complesse e delicate funzioni che abbiamo descritto, il demand manager può contare sull’aiuto di diverse soluzioni tecnologiche. Si tratta di suite di prodotti modulari integrati che si occupano di gestire la raccolta delle richieste, di definire le priorità, descrivere i progetti che ne conseguono, assegnare le risorse e, soprattutto, controllare, nello svolgimento del progetto, l’utilizzo di tali risorse, il rispetto dei tempi e dei costi e, in una parola, tutto quanto permette di passare dalla fase di demand management a quelle di project e di application management che stanno a valle e ne sono la conseguenza.
Si tratta di soluzioni in genere alquanto costose, sia come licenza sia come installazione, ma che offrono il grande vantaggio di proporre logiche di lavoro che permettono di strutturare i processi così assistiti secondo best practices collaudate e affinate dagli studi e dal patrimonio di esperienza raccolto dai fornitori. “Occorre però fare un bilancio – avverte Pasini – tra ciò che viene proposto, che è adattabile solo entro certi limiti, e quello che invece l’azienda ha già deciso sul come organizzarsi per strutturare i processi di cui stiamo parlando”. Il consiglio (come insegna l’esperienza degli Erp) è quello che, se ci si orienta verso queste suite, bisogna prima verificare, magari con l’aiuto di un consulente, se le pratiche proposte siano compatibili con quanto già esiste e si fa in azienda e poi, una volta effettuata la scelta, farsi guidare dal prodotto rinunciando a personalizzazioni che possono risolversi, per usare l’espressione di Pasini, nel classico “bagno di sangue”.
Figura 1: La collocazione della figura del Demand manager e l'indicazione di a chi appartiene lo ownership dei progetti di alcune primarie realtà internazionali.
Fonte: Sda Bocconi
(Cliccare sull'immagine per ingrandirla)
Secondo una ricerca sponsorizzata da Hp e condotta dalla Sda Bocconi presso un campione rappresentativo delle aziende italiane di medie e grandi dimensioni (quelle che, come si è detto, hanno più necessità di processi di demand e project management) le suite specializzate sono adottate nella maggioranza (il 58%) dei casi. Nelle situazioni restanti si trova un gruppo significativo (il 22%) di realtà, evidentemente dotate di buone risorse di analisi e programmazione, che hanno scelto di realizzare applicazioni custom, ‘tagliate’ cioè a misura dei propri processi, che ovviamente devono essere stati già ben determinati e definiti in ogni particolare (compreso tutto il workflow delle operazioni e autorizzazioni) e poi sviluppate in casa. I prodotti risultanti possono funzionare bene ed essere anche competitivi, come costo, rispetto alle suite del mercato, ma non è detto che siano la soluzione ideale. Infatti non sempre le pratiche che un’azienda ha sviluppato al proprio interno sono le migliori possibili. Insomma: un abito su misura veste meglio di uno già pronto solo se il sarto è bravo davvero. E i bravi sarti sono sempre più rari da trovare. Quanto al resto è… terreno di conquista. Nel senso che chi fa demand management lo fa con Excel. Uno strumento certamente efficace per tener traccia di ciò che si fa e fungere quindi da repository, ma che con quanto si è detto finora in termini di gestione di processo non ha nulla a che vedere.
