Indicatori di sintesi.

Forse qualcuno si aspetta che io parli della festa del primo maggio, sfortunatamente ero a visitare un castello a Wupperthal/Solingen, e onestamente non l'ho seguita. Del resto, fare la festa del lavoro quando manca il lavoro e' come fare una festa dell'acqua quando manca l'acqua: una festa per pochi fortunati che si sono accaparrati le ultime riserve. Vorrei invece parlare dei numeri di Grillo, perche' si parla e si parla, ma nessuno propone un approccio un minimo sistematico al problema.

Supponete di offrire un prodotto od un servizio, per prima cosa vi chiederete quanti siano potenzialmente interessati al prodotto, ovvero chi siano coloro che potrebbero usarlo. Se fate una macchina che raccoglie pesche dai campi, ovviamente saranno le aziende che coltivano pesche, eccetera.

Rimaniamo in un campo a me congeniale, e diciamo che stiamo scrivendo una app per un cellulare, e diciamo che il numero di cellulari su cui questa app potrebbe girare sia di circa 9 milioni.

Cosi', abbiamo questa app, diciamo "LiquidDM!" , che va sul nostro market (in questo caso, fa da enabler, cioe' e' il meccanismo che permette ai clienti di essere in grado di usare un servizio. Attenzione, non sempre l'utente e' il cliente: posso vendere un servizio ad un supermercato (il mio cliente), che poi lo offre agli utenti veri - i SUOI clienti, che non hanno un contratto con me) .

Allora, la nostra app LiquidDM! dopo essere stata pubblicizzata in qualche modo, viene scaricata da 48.000 persone. In questo caso si parla di "indicatori di successo", perche' il cliente non usa nemmeno l'enabler, ovvero non fa parte di un processo. In questo senso, non e' un pessimo indicatore di processo, ma un pessimo indicatore di successo.

Quel numero e' ovviamente un numero catastrofico, ma onestamente nella vita non mi occupo di indicatori di successo, per cui l'analisi  e lo splitting in CSF (un elenco dei fattori piu' importanti nella produzione del successo) di solito la fa chi si occupa del mercato. Lanciano customer surveys, licenziano gli ideatori, cercano feedback, fanno piu' pubblicita', cambiano canale pubblicitario, eccetera. Non e' il mio lavoro, quindi diciamo: l'indicatore di successo e' catastrofico, ma non saprei dirvi la rava e la fava su questo.

Andiamo agli indicatori di processo, perche' qui ne ricevo una paccata ogni mattina, da controllare con il mio bello splunk. Insomma, e' il mio lavoro. 

Abbiamo detto che il nostro UCD(1)  in questo servizio contiene almeno:

Dal punto 2 al punto 8 il cliente e' gia' abilitato al sistema. Significa che da questo momento e' parte di un processo, e il fallimento di uno di questi punti e' (o dovrebbe)  essere misurato da un apposito KPI. In che modo prendere il KPI , cioe' in che modo entrare in possesso del dato, e' tutto da discutere coi tecnici, ovvero la APP potrebbe per esempio confermare la propria installazione, il market lo scaricamento, la applet dovrebbe loggare l'avvio (tipo, esegue il login al sistema producendo un evento loggato), e poi ci saranno dei cookie o qualche altro token che , leggendo sul backend, mi dice se il cliente ritorna. E cosi' via.

Ognuna di queste fasi deve essere tracciata, altrimenti vi sognate quello che ITIL v3  definisce "miglioramento perpetuo":

Detto questo, se il cliente si provisiona ma non usa il sistema, siamo parlando di KPI. Che cosa pubblica Casaleggio?

Pubblica che alle parlamentarie circa il 30% degli abilitati abbia scelto di non votare, e i voti siano stati circa 25K, mentre alle quirinarie i voti sono stati circa 28K, su un totale di 48K.

Questo e' un KPI evidentemente ORRIBILE.

Sicuramente il tale utente puo' scegliere di NON partecipare, o di non partecipare piu', o di non partecipare quella volta. Aha. Ma questo innanzitutto non lo potete dire voi. Una volta stabilito che C'E' un PROBLEMA, allora il punto e' che si va ad investigare.

Non si puo' dire che "e' normale" senza investigare. Il ciclo e':

Ora, stabilito che NON VOLEVAMO la rinuncia del 40% degli iscritti, e preferiremmo che tutti partecipassero , ci sono diversi "stakeholders":

 Una volta splittato il problema in incidenti, si assegnano gli incidenti e si analizzano i numeri. Se nessuno di questi punti mostra un fallimento, allora il problema non e' di processo, ma viene prima, ed e' un problema di successo.

Qui entrano in campo persone che avevano definito i CSF http://en.wikipedia.org/wiki/Critical_Success_Factor e via dicendo. Come ho gia' spiegato, non e' il mio lavoro. Io mi fermo alla gestione "informatica" del prodotto.

A quel punto, poi chi gestisce il prodotto in se' dovra' capire quale "Quality gate" ha mancato. Questo e' il campo che mi e' piu congeniale dei CSF ma e' piu' distante da me, perche' gli unici quality Gate di cui mi occupo nella costruzione di un servizio sono quelli legati all'infrastruttura, quindi mi limitero' ad un modello di Quality Gate per la messa live di un servizio IT. (che di solito ha un software alle spalle).(2)

Supponiamo che non ci siano problemi di processo , ovvero che tutti i punti del processo funzionino, semplicemente il cliente non usa il prodotto. In quel caso, sembra che il problema sia in G0, che normalmente contiene la fase di "ideazione" del prodotto stesso. Esso e' pensato per fare una cosa che gli utenti non vogliono davvero fare. E questo e' il fallimento che porta da 9 milioni di elettori a 48 mila iscritti.

Puo' succedere che e' un problema , sempre in G0, legato al fatto che l'utente non si fida del media, la raccomandata coi documenti, o non vuole usarlo, o non si fida di chi poi terra' i documenti. Siamo sempre in fase di ideazione.

Se invece si iscrivono in 48.000 e poi usano il servizio solo in 28.000, possono esserci diversi gates mancati, dall'implementazione alla scarsita' di portfolio, nel senso che magari si vota poco, o su poche cose , insomma l'idea in se' piace, ma poi mancano use cases interessanti. Qui il fallimento sta , e bisogna stabilire dove , nei quality gates successivi:

 Adesso, so che cosa avrete in mente: ma tutti quei disegni non sono altro che buon senso!

Ora, tutto questo non appare altro che essere una formalizzazione del buon senso. Perche' il buon senso viene formalizzato in schemi e tabelle piu' o meno colorate/i , e in terminologie piu' o meno esotiche?

Nessuno pensa che questi concetti siano alieni o troppo difficili, quello che si vuole fare e' molto semplice:

Insomma, il punto e' che magari voi COME SINGOLI non avete bisogno di tutto questo, ma ne ha bisogno l'azienda come sistema complesso pieno di persone. E ne ha bisogno perche' vuole che le persone si capiscano tra loro in fretta, che usino metodi analoghi cosi' da potersi aiutare meglio, che svolgano ALMENO un certo numero di "pezzetti di buon senso", numero e tipo chiari sin dall'inizio, e che lavorando tutti allo stesso modo possano anche essere confrontati. I framework non servono a voi, servono alle aziende ove volete lavorare. Se non ne conoscete nessuno, sarete bravi quanto volete, e vi troverete a venire "misteriosamente" sorpassati dagli altri, oppure finirete a fare "i lavori che nessuno vuole fare". Vi consiglio vastamente di conoscere uno o due di questi framework.


Sicuramente, FUORI da questi framework possono esserci degli autodidatti molto bravi a parlare, a "ggestire", a "spegare" a "comunicare", normalmente si tratta di persone che sanno parlarvi otto ore di qualcosa senza dire niente, e "senza dire niente" significa che, non usando framework riconoscibili (ITIL, MOF, 6sigma, e-tom, PMP,  etc) quel che dicono risulta letteralmente incomprensibile agli altri.

Sicuramente, un venditore troppo bravo riuscira' a prendere questo ed infilarlo in una galleria d'arte , e magari a venderlo bene, come hanno fatto quelli di DNV, ma dal punto di vista degli addetti ai lavori, quello non puo' essere un documento tecnico. Certo, Santi Licheri sembra un giudice (lo era) e Forum sembra un processo, ma un esperto di procedura civile lo trova piu' o meno come uno scarabocchio. Questo perche', anche se ai profani sembrera' che Licheri faccia le cose giuste, agli esperti apparira' per cio' che e'. Lo stesso dicasi per la disamina pubblica della questione degli "attacchi hacker" di Grillo (3)

Questo e' il motivo per il quale i parlatori possono anche tacere: parlando non faranno altro che manifestare la propria incompetenza, e parlando di piu' manifesteranno ancora piu' incompetenza.

Chi ha fatto lo scarabocchio sopra, se vuole venderlo come progetto di un circuito elettrico, potra' anche aggiungere altri scarabocchi, ma anziche' migliorare la situazione aggiungendo scarabocchi, non fara' altro che mostrare che non sa cosa sia lo schema di un circuito elettrico, e piu' scarabocchi aggiunge, piu' la situazione peggiora.

Uriel