MONITOR & MANAGEMENT

di Renato Comes

Se non si può misurare una cosa, magari non la si può gestire

Si dice che se un fenomeno non può essere misurato in modo oggettivo, non può essere monitorato in modo puntuale e quindi non siamo certi del suo stato e della correttezza del suo comportamento. Dal monitoraggio alle decisioni operative che incidono sul fenomeno il passo è breve.

C'è decisione e decisione, però. Ovvero, ci sono decisioni tipiche di un sistema di monitor ed altre tipiche di un sistema di management.

Un sistema di monitor opera in tempo reale su un determinato fenomeno ed ha come scopo il comprendere e segnalare un comportamento anomalo mentre un sistema di management opera su tempi più lunghi e permette di programmare azioni ed iniziative anche non operative a monte e a valle dell'accadimento del fenomeno. La cosa può risultare banale, ma non lo è. In particolare per chi si occupa di informatica. Agli informatici che operano sempre in tempo reale dedico questo spunto di riflessione.

Real Time o On Line ?

Prendiamo in considerazione un'applicazione software. Per definirla, bisogna specificare sia i suoi flussi di dati (input ed output, contenuti) sia il suo comportamento funzionale.

Il comportamento funzionale è l'insieme delle azioni che le applicazioni svolgono a seguito dell'accadere di determinati eventi. Tali comportamenti possono essere corretti o sbagliati rispetto a delle regole di funzionamento prefissate.

Monitorare un'applicazione significa quindi monitorare sia il comportamento sia il contenuto dei dati che manipola come effetto ulteriore della correttezza delle funzionalità.

Monitorare il contenuto dei dati non è però cosa semplice specie se i dati sono tanti, e poi anche perché il comportamento dei dati è caotico a causa delle altre applicazioni concorrenti, con tutti i rischi di “rumore” indotto.

Se il monitoraggio sui contenuti non è agevole, i contenuti debbono comunque rispettare delle regole d'integrità, di aderenza a principili legali, correttezza ecc. Sui contenuti è molto più agevole svolgere azioni di ispezione e di analisi che prevedano un orizzonte temporale più ampio e che facciano focus su aspetti di auditing più che di stretto monitor.

Monitor o management ?

Nella tabella acclusa ho riassunto alcune caratteristiche che distinguono i processi di monitor da quelli di management. Dal punto di vista temporale la differenza è notevole. I primi operano in tempo reale mentre i secondi in on line. Il Real Time è spesso sinonimo di sistemi che funzionano anche senza presenza umana (si pensi ai sistemi di controllo di una diga), le elaborazioni on line sono schedulabili e a richiesta e danno una immagine ferma ad un certo momento.

La seconda riga ci chiarisce la differenza di scopo da raggiungere: nel primo caso bisogna tenere sotto controllo i comportamenti, nel secondo caso c'è bisogno di una visione di più ampio respiro, bisogna ispezionare nel tempo i contenuti, magari confrontando nel tempo i risultati ottenuti.

Lo stile operativo sarà nel primo caso reattivo, ovvero “a fronte di questo evento si deve compiere questa azione” mentre nel secondo caso sarà del tipo analitico, ovvero: “analizzare i fatti in modo da comprendere ed eventualmente compiere azioni conseguenti che non necessariamente riguardano l'immediato”.

Nel primo caso si definisce quale azione e chi la deve compiere (un computer, un macchinario o un operatore, uno specialista) dopo aver classificato l'evento secondo gradi d'importanza e di urgenza operativa. Nel secondo caso si operano vere e proprie ispezioni (spesso sono fasi di auditing) secondo regole operative e si ragiona sui dati con logiche di medio e lungo periodo per poter esprimere ipotesi sul comportamento del sistema e coprono aspetti di processo a più alto livello (Capacity Planning, rispetto di un contratto di Service Level).

Dal punto di vista dei dati, un monitor esamina solo quelli i dati correnti e quelli generati dai suoi “sensori” inseriti nel prodotto software, mentre un sistema di management opera su dati aggregati secondo viste di business e coerenti nel tempo.

La logica conseguenza operativa è rappresentata dall'ultima riga della tabella, ovvero ragionando per metafore, un monitor sta ad un'applicazione transazionale (pochi dati, operativi, una operazione ripetitiva nel tempo …) come un sistema di management sta ad un'applicazione di Business Intelligence (tanti dati aggregati, creatività e libertà di disamina …).

Quanto monitor e quanto management nelle applicazioni aziendali ?

Definite le differenze stilistiche fra Monitor e Management, ritorniamo sugli aspetti organizzativi e di processo. Gli informatici pensano che ci sia molto più monitor che management nelle applicazioni aziendali forse perché è più consono alla loro forma mentale ed è più visibile in termini di ritorno dell'investimento.

E' facilmente dimostrabile il contrario guardando la figura sottostante.

L'ambiente di sviluppo applicativo opera specialmente nelle prime due fasi del ciclo di sviluppo di un'applicazione, mentre i clienti concentrano la loro attenzione specialmente nelle fasi di produzione e management / chargeback. Il Management dell'ICT (Information e Communication Technology) ha un interesse esteso al processo ma è evidente il maggior coinvolgimento nelle fasi finali. I Sistemisti operano su tutto il processo e su di loro gravano molte incombenze di “collante culturale”. Alla gestione operativa la parte di gestione del servizio.

Si controlla un'applicazione quando è in produzione per verificare in tempo reale se si accadono anomalie. Durante le fasi di sviluppo e test, le anomalie sono gestite per definizione.

Il management di un'applicazione è un processo costante: cambia forme, mansioni, obiettivi, dalla gestione dell'ambiente di sviluppo alla software factory (quanti studi economici sono stati fatti in merito !). Come non prendere in considerazione il capacity planning ? ed i controlli ispettivi di qualità di certificazione sull'applicazione e sul processo ?

E ancora, se il servizio applicazione viene proposto in modalità outsourcing o ASP, esiste una continua attività di costificazione in base all'utilizzo dell'applicazione stessa, di fatturazione di Service Level Agreement.

Oggi il problema del management applicativo è ancora sottostimato in termini qualitativi ed eluso in termini quantitativi poiché visto come un costo infrastrutturale di dubbio ritorno dell'investimento.

Negli anni passati c'è stato molto dibattito sul problemi legati al ciclo di vita del software e sulle economics, ma molto è stato dimenticato, è rimasto un utile esercizio e niente più.

Molte aziende hanno ridotto notevolmente l'entità dello sforzo per lo sviluppo applicativo acquistando package o addirittura hanno esternalizzato il problema. Dal punto di vista del ritorno immediato hanno diminuito il problema del management delle applicazioni e dei loro dati, ma si sono caricati dei problemi derivanti da un service level agreement di non sempre facile gestione: credo che abbiano semplicemente spostato il problema, prova ne sia la difficoltà di gestione dei rapporti con i fornitori di software.

Molto spesso si dice che il fornitore di prodotti o di servizi outsourcing non è sempre all'altezza della situazione ma … che fare ? Come cambiare un cavallo in corso ? E se il fornitore o l'outsourcer fanno parte della stesso gruppo d'azienda, ovvero dietro la terziarizzazione ci sono solo logiche finanziarie e non industriali ?

Nuovi modelli, nuovi strumenti

E così il problema del management, che a prima vista sembrava più semplice del monitor, è molto più infido e complesso dell'altro e lo è talmente che i professionisti dell'informatica sono chiusi in un angolo fra fornitori esterni e clienti interni, i quali si sono ben presto abituati a vantare i loro diritti senza sconti, una sorta di vendetta, dopo anni di muta rassegnazione ai diktat tecnologici della lobby del bit.

Il problema del management sta diventando sempre più grave poiché ai consueti rapporti basati sulla tecnologia e sulla normale dialettica aziendale e cliente-fornitore si stanno aggiungendo e moltiplicando quelli basati su modelli organizzativi sempre più estesi e flessibili ove non bastano neanche più la semplice definizione di livello di servizio e le relative procedure definite in sempre più corposi quanto inutili contratti di servizio.

La realtà è molto complessa, si pensi non solo alle applicazioni, mansioni etc. cose tipiche di un contratto di servizio, ma anche a come cambia il servizio stesso a fronte dell'evoluzione tecnologica e dell'impatto che i singoli pezzi (nuove release di software, per esempio) possono avere sull'insieme. E senza contare i continui ribaltoni delle strutture del personale sia dei fornitori (e dei loro fornitori) sia dei clienti. Se le logiche finanziarie prevalgono su quelle industriali e quindi il risparmio immediato su qualunque costo viene premiato a scapito della stabilità di funzionamento di medio e lungo periodo, come si può pensare ancora al monitor come fenomeno più importante del management ?

Questo durissimo periodo di mercato e di vita aziendale sta facendo molti danni sul terreno e per dare calma e fiducia ci vuole un nuovo atteggiamento nei manager, una nuova prospettiva di management.

Oggi si decide poco anche perché si sa poco e molto è fluttuante. E' necessario definire nuovi modelli d'integrazione allargati a tutti gli attori del processo applicativo secondo una logica di chiara definizione di responsabilità – fasi e di empowerment sulla base delle responsabilità. I modelli collaborativi basati sulla chiara definizione di ruoli (controllati da opportune applicazioni) restano i modelli migliori. Dal punto di vista applicativo, è importante avere applicazioni agili che svolgano poche ma importanti funzioni e che lo facciano bene ed in modo semplice per l'utente. Servono applicazioni per i diversi tipi di utente ed ognuna con le funzionalità che servono allo specifico utente nelle varie fasi del processo, dall'apprendimento della soluzione alle specifiche funzionalità utili nel lavoro quotidiano, alle fasi di collaborazione.

Ciò che serve è uno stile funzionale oltre che un insieme di funzionalità. Non vogliamo rigidi stardard dove non servono, vogliamo avere la situazione sotto controllo e potre decidere in tempi brevi e su dati oggettivi e condividere queste decisioni con gli altri attori del processo.