La fabbrica del duomo

Si sono inventati la nuova fabbrica del duomo e l’hanno chiamata ERP, questa è la sensazione comune.

Delle volte, vi dirò la verità, ce l’ho anche io. Ma solo delle volte.

Lo so, lo so: ho un’angolazione particolare. Faccio organizzazione aziendale, per me il sistema informativo è lo strumento più duttile ed utile per disegnare e poi far girare sulla ruota di Deming i processi aziendali. E se mi date un giocattolo come SAP, tra le mani, io mi diverto da matti. E chi mi dice che non è flessibile, lo sappia: non avete mai visto quante cose può fare, il mostro sacro, nelle mani di chi fa davvero ingegneria di processo.

Lo so, lo so: ho un’angolazione particolare. Ma l’implementazione di un ERP non deve essere una fabbrica del duomo, bensì la figlia concepita, voluta e con una gestazione ben monitorata di una madre evoluta (il fornitore) e di un padre esigente (il cliente).

Eppure, in tanti casi, non va proprio così. E SAP e i suoi fratelli fanno la fine del nemico pubblico numero uno, anziché del miglior amico di qualunque buon gestore di informazioni. Non avete idea, davvero, del miliardo di informazioni che contiene e vi può dare, se solo imparate a fare le domande anziché cercare le risposte.

I dati, organizzati, servono a quello: a dare le risposte alle vostre domande.

Provate ad andare in un posto dove non hanno idea di cosa sia un sistema informativo (a me capita spesso) e provate a parlare di ingegnerizzazione di processo e di costruzione di una preziosissima architettura delle informazioni che lo supporti: vi guarderanno come se foste alieni.

In effetti, forse, quelli come me lo sono tutti, alieni.

Invece è proprio di questo che si tratta, e se non vi basta il mio parere, leggetevi un po’ quello, ben più condiviso e quindi inteso autorevole, di Wikipedia: il processo di costruzione di un ERP è sempre accompagnato, se non virtuosamente preceduto, da quello di BPR, che vuol dire Business Process Reengineering.

Che poi vuol dire, banalmente, che prima di fare una cosa bisognerebbe pensare come farla, dove andare, e capire se c’è qualcosa da cambiare nel tragitto.

Ma no, Chiara, non funziona così davvero.

Epperdio se funziona così! Così funziona, negli altri modi… va.

Che non vuol dire che poi funzioni.

Va che c’è un cliente, che se ha deciso di cambiare tutto e mettere in produzione un sistema di gestione integrata delle informazioni dal logistico al finanziario significa che ha qualche problema, a meno che non sia un illuminato visionario che ha capito tutto.

E normalmente, davvero, il cliente non sa bene quello che vuole: è per questo che vuole dei bravi consulenti.

So cosa voglio fare ma non so come si fa: me lo dici tu che sei un esperto?

Va poi che c’è un fornitore, che ha quello skill particolarissimo, abbastanza raro, decisamente costoso, di saper fare il tanto celebre customizing. Che magari ha anche forti competenze nel settore industriale di riferimento.

Lui sa vedere dietro il software, nelle sue logiche, dentro le strutture, e sa piegarlo (con una flessibilità massima) alle esigenze del cliente, quelle espresse e quelle non, ai requisiti normativi cogenti, ai potenziali sviluppi evolutivi.

Va da sé che c’è una ben definita linea di demarcazione tra l’uno e l’altro: due obiettivi ben distinti di business ed uno, teoricamente comune, di successo.

 Ve lo dico senza mezzi termini: se lì, nel guado, non c’è l’ingegneria di processo, quel che succederà è un delirio.

E non è tanto il durante che mi preoccupa: mi preoccupa il dopo.

Più o meno, grossomodo, quasi tutti, in qualche modo, a finire il progetto ce la fanno.

Basta redigere una sommaria serie di Business Blue Print in fretta e furia, senza analisi organizzative ma pensando solo a range di numerazione e struttura di master data, col cliente che impazzisce a chiedersi se vuole i codici parlanti e provare a migrare le anagrafiche dal vecchio sistema.

Che poi spiegatemelo, senza valutazione degli input di processo, come si fa a pensare ai master data?

Ma soprattutto spiegatemi che ce ne frega, nel terzo millennio, nel cloud e con la velocità dei nostri processori, che ce ne frega dei codici parlanti?

Il progetto parte su quei quattro rudimenti che nessuno dal cliente ha letto con attenzione, perché ci sono così tante tecnicalità che alla fine non si capisce niente, e che anche i consulenti non hanno incrociato bene, così che c’è qualche contraddizione qua e là, ma tanto non si vede.

Specifiche funzionali e tecniche? Nella maggior parte dei casi un sogno proibito, talora invece, documenti redatti ex post, quando del BBP non c’è rimasto niente.

Il progetto continua con l’implementazione, una sorta di mistero della fede.

Si sa solo che da qualche parte, qualcuno, sta lavorando su una celebre macchina di sviluppo che nessuno ha mai visto.

Ed i key user si trovano davanti a qualche strana presentazione dell’interfaccia un po’ ostile di SAP, senza neanche sapere cosa sia una transazione e senza magari neanche sapere che cosa sia, davvero, un key user, ma fa figo.

La responsabilità del ruolo picchierà, dopo, ma solo dopo.

E poi si fanno i test.

Scusate, ma non facciamo un po’ di formazione prima?

Cioè, voglio dire, vogliamo mica per caso costruire un linguaggio comune e imparare a guardare tutti assieme questa schermata grigia e non morire annegati davanti ai click veloci dei consulenti senza capire niente di quello che succede?

Ma no, che cosa dici, la formazione si fa dopo.

E adesso allora, spiegatemi anche questa:

ma come faccio a testare che una cosa funzioni e compilare il mio UAT se non ho capito come fare a farla funzionare e sto ancora pensando a cosa fosse quella strana traduzione dal Tedesco in quello sterminato menù ad albero?

No beh, poi la formazione si fa, magari un mese o due prima del go live, che tanto nessuno ci capisce niente e figuriamoci se perde il suo tempo a testare su un sistema di quality mentre deve lavorare, che tanto poi c’è il go-live.

E poi wow: il go-live.

Osannato, celebrato, atteso, il go-live.

Che se lo diciamo in Italiano è già meno magico: si chiama messa in produzione. Che noia.

Quelli sì che son giorni eccitanti.

I consulenti farneticano a bassa voce di tutto quel che si son dimenticati per strada.

I key user aspettano che la macchina magica funzioni da sola e invece lo devono fare loro.

Gli altri, i poveri utenti, non ci han capito niente e non san neanche cosa devono fare.

E i capi progetto, tutti e due, sono un po’ isterici.

Così wow, il go-live, che la scrivente ci è anche svenuta, al primo go-live.

Un mese di assistenza, forse due, quattro picconate, due martellate e tre toppe e via: il progetto è finito.

Fatti dei key user.

Ed è lì che comincia il delirio.

Perché senza ingegneria di processo, gli utenti chiederanno di poter riprodurre esattamente quello che avevano prima, non penseranno che se le cose si possono fare in un modo nuovo, magari sono anche più facili.

Se nessuno ha disegnato il nuovo modo, come fanno ad immaginarselo?

Bisognerebbe ascoltare ‘Altre forme di vita’ dei Blu Vertigo, per capirlo.

E senza ingegneria di processo gli specialisti, brillantissimi consulenti funzionali di modulo, vi proporranno solo i metodi che conoscono, non necessariamente delle virtuose best practises studiate in saecula saeculorum dai loro colleghi alla casa madre, lassù da qualche parte nel Baden-Württemberg.

Eccola qui, la fabbrica del duomo.

C’è un report che sarebbe utile: per farlo ci vuole un custom.

E si fanno i report prima di aver buttato dentro i dati.

C’è un pezzo di processo che è rimasto scoperto, ce lo eravam scordati: ci vuole un custom.

Non riguardare il processo con gli occhi spalancati.

C’è una specificità di mercato: ci vuole un custom.

Ma non eravamo specialisti?

C’è un nuovo dettato normativo, coi tempi del nostro rapidissimo Stato: ci vuole un custom.

Certo, è ovvio, perché non ce l’hanno tutti lo stesso problema, quello della fatturazione elettronica o quello della Certificazione Unica. No, è una specificità legata alle fissazioni dei singoli fiscalisti e dobbiamo fare un custom.

Un programma apposta, che tra un anno, appena il Ministero cambia una virgola, andrà rifatto di sana pianta. 

E allora il progetto è finito, ma il lavoro continua, sommesso, silenzioso, dietro la maschera dell’application manteinance.

E costa. Tanto.

Ma avete mai visto una macchina nuova che dopo un mese e mezzo ha già bisogno di manutenzione?

Io guido un’Audi: la mia Audi non ha visto un’officina finchè non ho bucato la prima gomma e fatto il primo tagliando.

E un maledetto sistema informativo nuovo di pacca, che è costato una barca di soldi, non può avere un comportamento diverso!

Ma non facciamoci caso, sono solo i primi mesi post go-live.

Non è così: senza ingegneria di processo le richieste continueranno schizofreniche, le soluzioni arriveranno disintegrate.

E che ve ne fate di una soluzione disintegrata in un sistema che è concepito per essere integrato?

Ve lo dico io: un bel niente.

Costruirete solo un mostro a più teste di un Cerbero cui, prima o poi, e facilmente prima, verrà il cancro, con le richieste degli utenti che fanno da innesco rapidissimo della mitosi delle cellule tumorali che sono i custom. 

Basta!

Io dico basta, basta, basta, ascoltate quelli che la pensano come me!

But business is business. E le richieste sono impellenti, e le risposte urgenti. Fa niente se poi domani sarà un casino, ci penseremo domani.

Lo dicono anche i consulenti, con scarsa eleganza ma grande nitore: shit in, shit out.

Me lo dicono tutti: Chiara, dai, lascia stare, questo era urgente. E anche questo e anche questo, perché dobbiam perdere tempo a fare i tuoi schemi di processo e i tuoi percorsi critici del cazzo?

Ed io impazzisco.

Ma scusate, ma il famoso PDCA? Quella favola che le cose prima si pensano e poi si fanno e se non van più bene si cambiano?

Ma scusate, ma i famosi GANNT e PERT? È possibile che continuiamo ad ignorare che per intraprendere una serie di azioni, concatenate ed integrate verso un obiettivo, ci vogliono un percorso critico e una pianificazione degli oggetti e che quindi ogni cambiamento è normalmente prevedibile e quindi prevenibile?

Si vede che sono matta, non proprio aliena.

E che l’ERP è la fabbrica del duomo e che avete ragione voi.

Io però non son d’accordo, no: si può fare in un altro modo.

Con un nucleo stretto e competente di persone interessate al processo (dal cliente), che se le cose non le sanno le devono imparare.

Con un capo progetto (del cliente) con le palle.

Un buon padre, rigoroso ed esigente, per la bambina gioiello che sarà un vero sistema integrato di processi e informazioni.

Con una squadra di competenze e non solo di persone, duttile, flessibile, elastica come il corpo di un contorsionista, composta di competenze di processo prima e di sistema poi.

E un altro capo progetto con le palle, quello del fornitore. Ma quadrate!

Una madre affettuosa ed evoluta, che sa guardare più avanti del suo naso, ma sa anche dire di no quando le pretese di un padre talora inconsapevole rischiano di danneggiare la gestazione.

E ci vuole un concepimento basato sulle necessità di funzionamento. Efficacia, efficienza, no?

Il cliente deve sapere, e sapere bene, quali sono i suoi obiettivi. Il fornitore deve capirli, profondamente, e proporre soluzioni costruttive, proattive, talora apparentemente visionarie.

Fregatevene, per piacere, clienti cari, dei tecnicismi, dei nomi dei campi, della posizione delle informazioni nella finestra: vi serve che funzioni, non tanto sapere come. Soprattutto perché non sapete bene come funzionerà, ma avete decisamente bisogno che lo faccia.

Fregatevene, per piacere, fornitori cari, del fatto che un custom sembra più facile e porta più reddito, perché quando domani a fare una modifica ad un programma attaccato ad un modulo si bloccherà il funzionamento di un altro, sarete voi a sbattere la testa sul muro e mettere a posto i cocci.

Dite di no alle richieste insensate, è l’unico modo serio di lavorare: il cliente si aspetta suggerimenti ed idee che anticipano i problemi, non che li risolvono dopo che si sono presentati. Anche perché costano di più, dopo, e se business is business… spendere male i soldi non lo è.

L’ERP non è la fabbrica del duomo, è la follia del business incastrato nel conflitto di interessi che lo rende tale. Ci vuole la cerniera che lo minimizza: ci vuole l’ingegneria di processo.

Si può fare in un altro modo, e si può fare bene.

Con immensa soddisfazione da ambo le parti.

E vi lascio, dunque, con una domanda: ma voi, quando vi comprate una macchina, scegliete gli optional dal listino prendendo tutti e soli quelli che vi servono o vi fate davvero modificare il motore secondo supposte esigenze che nemmeno sapete se avete davvero perché non l’avete mai guidata?