Una volta in azienda lo chiamavamo il “programma gestionale”.

Poi questo nome deve esser sembrato poco significativo e così ad un certo punto tutti abbiamo iniziato ad utilizzare una nuova sigla internazionale per identificare questo tipo di programmi. Così il vecchio “software gestionale” fu ribattezzato in ERP che sta per Enterprise Resource Planning.

Fin qui tutto ok. La sigla ERP, pianificazione delle risorse d’impresa, risulta ben esplicativa del fine che si pongono questo tipo di mezzi software.
Poi è arrivata la grande autostrada delle informazioni, internet.
Dal cielo piovve (o ricadde) un poco di analisi orientata agli oggetti e grazie a questo paradigma si iniziarono a far cooperare fra loro software di diversa natura.

Nacque così il modello SOA (Service Oriented Architecture) ed il mondo del software divenne un grande “LEGO Technic”.
In sintesi, i programmi gestionali, poi divenuti sistemi ERP, si sono molto evoluti tecnologicamente, sono divenuti… moderni, interoperabili e oggi corrono veloci sull’autostrada di internet.

Patente e libretto!   Patente è libretto?  Che c’entra?

Beh, se uno corre sull’autostrada può capitare.
E’ l’occasione per vedere se la filante ed aerodinamica carrozzeria del mezzo poggia su degli pneumatici dotati di sufficiente battistrada.

L’ho detto in premessa, la “carrozzeria” tecnologica dei moderni sistemi ERP è fiammante ed aerodinamica… ma il battistrada, come siamo messi con il battistrada, eh?
…ma poi cos’è il “battistrada” di un sistema ERP?

Risposta: il battistrada di un sistema ERP sono i dati, o meglio, la classificazione dei dati di base da cui poi deriva tutto il resto.
La classificazione dei dati sta ad un sistema ERP come gli pneumatici stanno ad un’automobile.

Capito il mezzo identifichiamo il fine. In sintesi massima, qual è la ragione d’esistere, il fine, di ogni impresa?
Risposta: offrire e realizzare merci o servizi ottenendo per questo un profitto.

Chiarito qual è il fine e qual è il mezzo, preso atto degli innegabili vantaggi offerti dalla moderna tecnologia informatica, dove è tutt’ora collocato uno dei maggiori gap presente nei moderni sistemi ERP?
In un punto preciso, a mio parere; il sistema di classificazione dei prodotti/servizi, la vecchia scheda anagrafica per intenderci, è rimasta ferma a quando chiamavamo questi software “programmi gestionali” e manco ancora erano comparsi sul pianeta i database relazionali.

Codice articolo/servizio, descrizione, categoria, settore… e mille altri attributi di classificazione statistico/dimensionale. Qualche tools qua e là, tipo la segmentazione dei codici items, per guidare gli operatori verso degli  “pseudo-sistemil di codifica parlante “ e… alla via così, passi lunghi e ben distesi.

Paradosso, la pioggia dell’analisi orientata agli oggetti ha provocato, nell’ordine: la crescita tecnologica dei linguaggi di programmazione, lo sviluppo dell’architettura di sistema, incluso ciò che oggi chiamiamo WEB 2.0, in ultimo anche lo sviluppo “arboreo” dei sistemi ERP… però, la pioggia dell’analisi ad oggetti non sembra essere arrivata alla radice della pianta che si chiama impresa.

Il mezzo, i sistemi ERP, con la loro “bellezza” tecnologica, rischiano di offuscare il fine; l’organizzazione e miglioramento dei processi d’impresa che altrimenti potrebbero trarre grande beneficio se diverse e standardizzate metodologie di classificazione dei dati di base iniziassero ad essere adottate in maniera diffusa.

Insomma, oggi un moderno sistema ERP è in grado di: permetterci di disegnare complessi workflow… di generare in automatico sofisticati  “watchdog allert”… di  possedere (o integrarsi) con sofisticati sistemi di analytics… etc, etc… e nonostante tutta questa roba, per classificare un prodotto/servizio ancora oggi la migliore best practice ERP rimane quella di generare codici parlanti lunghi quanto un treno merci?

Ciò è colpa del software oppure dell’hardware? Intendendo per hardware la capoccia di chi si occupa di dare soluzione ai problemi di classificazione.

Lunghe riunioni per decidere come strutturare un piano dei conti e ci mancherebbe, è giusto così (non scherzo). Un mio maestro era solito dire: “l’importante non è solo fatturare, l’importante è guadagnare, ben venga tutto ciò che può migliorare il controllo.”

Ma, fatta salva la taratura dei fondamentali sistemi di controllo dell’andamento economico, “forse” non sarebbe una cattiva just practice investire anche un po’ di tempo di qualità per decidere come risolvere i problemi di classificazione dei prodotti/servizi. Quella roba che si progetta, costruisce e vende, così da “legare il somaro dove serve al padrone”. Traduco: far fare al mezzo ERP ciò che serve per agevolare il raggiungimento del fine perseguito da ogni azienda.

Dettagli? In produzione diciamo che il “diavolo si nasconde nei dettagli”.
La classificazione/codifica di un oggetto, prodotto o servizio che sia, è la base del tutto da cui poi si dipana, fra l’altro, anche lo sviluppo del “motore di configurazione”, il cui ruolo è accelerare in sicurezza l’offerta e realizzazione di prodotti/servizi… facendo per tal ragione ottenere un profitto a chi se ne avvantaggia. Il mezzo ed il fine coincidono… yin e yang.

Auto-obiezione: i sistemi ERP standard non sviluppano diverse e migliori metodologie di classificazione dei dati di base dato che si tratta di funzionalità “verticali”, ovvero mutevoli azienda per azienda e quindi non standardizzabili.

Ciò non è vero in quanto tale asserzione si pone in palese contraddizione con la base fondante dell’analisi orientata agli oggetti, precisamente la parte che tratta i criteri di generalizzazione e classificazione dei dati.

Se l’analisi orientata agli oggetti ha provocato lo sviluppo tecnologico del mezzo, in tutte le sue forme, forse è giunto il tempo che di tal fatto inizi ad esserne informato anche il fine…l’impresa, in modo che possa così tornare a pilotare il mezzo ottenendo da esso migliori funzionalità e risultati.

In conclusione: l’indisponibilità di un’idonea struttura funzionale per la codifica dei prodotti/servizi, da cui deriva l’assenza di un “motore di configurazione”, costituisce il gap “fondante” che invece dovrebbe essere affrontato e risolto in maniera organica e generale dai moderni sistemi ERP così da far rientrare la soluzione a questo problema nelle funzionalità standard di “just practice” raccomandate.
Impossibile?

Un esempio… in contabilità oggi è normale utilizzare il sistema della partita doppia, questo è incontestabile, ma non è stato sempre così, almeno fino a quando un bravo frate di Sansepolcro, tal Luca Bartolomeo de Pacioli scrisse i canoni formali dei processi contabili.

Non è che prima del Pacioli i mercanti non sapessero far di conto, anzi, però ognuno si arrangiava come poteva con i criteri che riteneva più giusti, faticando così molto più del necessario.

Del resto nel 1400, quasi 1500, mica ci poteva essere un sistema contabile valido per tutti, buono sia per chi commerciava formaggi, sia per chi vendeva stoffe.

Poi arrivò il Pacioli… analizzo, valutò, sintetizzò, formulò… e oggi per la contabilità tutti, world wide, utilizziamo la partita doppia e il dare e l’avere.
Forse fortuna del Pacioli fu che nel tardo 1400 la tecnologia ancora non correva e per tal ragione si passava molto più tempo a riflettere… non so se sotto un albero di mele, come poi divenne di moda dai tempi di Newton in avanti.

Oggi le mele le possiamo comprare tramite una piattaforma di e-commerce e il melo si è updatato diventando cloud…

Morale. bisogna assolutamente trovare nuovi posti e tempi per riflettere sugli argomenti “core” utilizzando l’occhio e la logica del semplificatore così da guidare e sfruttare meglio i mezzi tecnologici oggi disponibili, come i sistemi software per la pianificazione delle risorse d’impresa, gli ERP.