Seleziona una pagina
 

La fabbrica del duomo

da | Set 18, 2016 | Testi ironici di teoria utile

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?

You May Also Like…

Bocconi a cartoni?!

La mia Università ha preso una multa, ma brutta brutta, brutta proprio. Più brutta per la reputazione che per l'importo, che di per sè probabilmente per una macchina da soldi come la Bocconi è sopportabilissimo. E' "lo sfregio" che trovo particolarmente imbarazzante,...

2 Commenti

  1. renato

    Nella mia esperienza tra committente e specialisti bisogna interporre una figura in grado di fungere da interprete. Una figura che riscuota la fiducia di ambo le parti, perché conosce i problemi delle parti e protegge i rispettivi interessi, in modo che il processo avvenga in una logica win-win. Qualcuno, nei processi di cambiamento, ha maggior consapevolezza e visione, e prima o poi salta fuori, ben accetto dalle parti. Buono! Ma se da parte della Committenza avvengono sbandamenti (il processo di cambiamento organizzativo ne genera sempre) e gli obbiettivi cambiano sensibilmente e non sono più misurabili (ma soggettivi): la fabbrica del duomo porta alla conservazione. Si torna indietro. Se chi dovrebbe dirigere -nella Committenza- molla la barra del timone, la barca sbanda, i suoi vogatori spingono con sempre minor convinzione, gli specialisti sparano alzo zero per cautelarsi e la figura mediatrice che era necessaria si incazza, si rammarica, si stupisce, incredula. La logica win-win è saltata. Chissà se il top management e la proprietà se ne avvedono e corrono ai ripari. Non tutti hanno un Marchionne che li tiri fuori. Quelli che stanno peggio sono i vogatori.

    Rispondi
  2. Valerio Daelli

    Considera che non tutte le aziende, in ambito Amministrazione, hanno la necessità
    di sfruttare al 100% i propri dipendenti e il proprio software.
    Quindi se un motore (un Application Server ad es.) funziona male, poco male,
    basta che faccia il minimo indispensabile per mandare avanti l’azienda.
    Analogamente, se i miei impiegati o i miei tecnici hanno problemi a usare un complesso applicativo, poco male, mi basta che funzioni un Core delle mie risorse.
    Chiamiamola la politica del minimo indispensabile.

    Rispondi

Invia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

#comeunainformativa#

concisa, trasparente, intelligibile, semplice e Chiara

B86CDDD9-AA99-4ED4-ABE5-A4870105C83E_1_105_c
10006083_10204660300400194_6325890572134401797_o-1-1
f2e50901-a74a-473f-8bf2-30bdf107866c-1-1
F8984A9A-4B02-4E38-B15E-1FFF809CA533_1_105_c-1-1
5A4B92B8-3299-4186-BAD5-5699134764C5_1_105_c-1-1
D21E2F49-021A-479F-9B11-71750CF99CF3_1_105_c-1-1

Leggi un post a caso!

EU Digital COVID Certificate: grinpass o non pass?

Ne parlano tutti. Come al solito (e mediamente) in Italia, a sproposito: un po' perchè "medioman" imperat ed un po' perchè, come cantava Ligabue, "pensa a chi non ci sente e poi ne vuol parlare". Vien da dire, prima di cominciare, che alla fine il Paese è pieno di...

aspettando defcon 5

Mi chiedo se vi siate mai posti il problema, se abbiate mai realizzato quanto preziosi e delicati siano i vostri sistemi informativi. Gli ultimi giorni mi dicono che no, non ci avete mai pensato, cari imprenditori che chiamate sempre dopo che è successo un casino, mai...

Covid-19: fate un piano di continuità operativa

Sono in Lombardia, e qui sono tutti sconvolti. Chi più chi meno allucinato, chi più chi meno spaesato. Alcuni (pochissimi a dire il vero) hanno reagito subito, due settimane e un giorno fa. Altri si sono svegliati tra ieri e stamani pensando che fosse un brutto sogno...

ricordi dal not for profit

Ho incontrato una persona, oggi, che mi ha parlato di un fenomeno che per lui è inconoscibile, da consulente: una startup innovativa a vocazione sociale. Mi son sorpresa a guardarmi mentre lo ascoltavo parlare: mai sentito niente di più familiare, invece. Una startup....

Senza due diligence

La cosa bella delle storie è che si possono raccontare, perché non hanno freni, àncore, regole: le storie hanno un finale, una morale ed alcune (non tutte) un filo conduttore. Le storie che racconto qui son tutte senza nomi, e se ci sono è perché me li sono inventati,...

talis pater, talis filia

Avevo vent'anni forse, secondo anno al DES, facevo la brillante alla Bocconi coi miei colleghi geni che prendevano sempre voti altissimi e la mia testa volava tra 'scrivo libri' e 'dove vado stasera'. Per quanto credessi di sforzarmi, non mi rendevo bene conto di cosa...

Esplora il blog

Su di me

OLYMPUS DIGITAL CAMERA
081B7F82-3522-4D1F-95C9-AE3DD8883853_1_105_c
168980_1739107990282_5690240_n
180615_1739107830278_1312776_n
217943_4146273367912_379519022_n
389071_3894149904983_1094047988_n
423892_3230411951949_1828327562_n
561028_3339040027583_1641457904_n
1441533_10205520031292929_3582566704537519490_n
15727347_10210178170063487_2545053087441484216_n
44019711-C758-423E-972A-8C080C178949_1_105_c
120175075_10220932663119092_5780439823649154081_n
259869031_10223535325704030_6123869307689241603_n
C7FFB9E7-634A-4EC1-B484-0258E1306733_1_105_c
previous arrow
next arrow