L’introduzione e la diffusione dei moderni sistemi informativi ha comportato delle modificazioni pesantissime nelle procedure gestionali. Si è passati da contesti nei quali la gestione si basava sulla totale padronanza da parte degli addetti delle logiche delle diverse procedure, sulla conoscenza della storia di vita dei diversi prodotti, sulla memoria delle specificità dei singoli articoli, ad un contesto nel quale la gestione è più spersonalizzata e meno legata alla vita gestionale dei diversi prodotti.

Senza dubbio si sono ottenuti dei sensibili miglioramenti in termini di correttezza delle informazioni, in termini di sofisticazione delle logiche elaborative, in termini di visibilità e trasparenze dei diversi processi e una maggior condivisione dei dati tra varie aree aziendali.

Accanto a questi vantaggi è emersa però una serie di controindicazione delle quali è importante che l’azienda abbia contezza, pena il fatto di vanificare molti dei benefici che dai nuovi sistemi possono discendere.

Tra questi vogliamo ricordare:

• La presa di distanza dalle logiche di funzionamento dei sottosistemi che compongono il sistema informativo
• La delega al sistema informativo dei criteri per l’effettuazione delle scelte, talvolta anche strategiche
• Una qual sorta di pigrizia nell’analisi delle variabili che affettano un processo in vista della sua ottimizzazione, con delega di questa direttamente al sistema
• L’incapacità di completare l’analisi di un fenomeno industriale affiancando ai parametri oggettivi (e pseudo oggettivi di competenza del sistema informativo) l’insieme delle sensazioni e delle informazioni non ancora codificate che l’operatore può aver raccolto ed interiorizzato
• La progressiva attenuazione della capacità nel fronteggiare situazioni impreviste.

In sintesi

Volendo sintetizzare si può pensare che in una fase di infanzia dei sistemi informativi ci sia stata una specie di ubriacatura circa la onnipresenza ed onnipotenza di questi dimenticando il ruolo fondamentale che l’operatore deve sempre esercitare nella gestione dell’azienda ed ingessando il sistema informativo in una rigidità che spesso risulta eccessiva.

Per meglio capire questo aspetto pensiamo a quelle attività ed a quei prodotti trattati in azienda ma che non hanno in questa la loro origine, che non hanno vissuto, per la loro nascita, un adeguato processo tecnico progettuale e che non hanno un livello di utilizzo tale da giustificare lo sforzo di creare tutta quell’impalcatura di dati indispensabile per poterne attivare una gestione informatica.

Gestire il ciclo di vita di un prodotto in un sistema informatico comporta un dispendio di energie che, nel caso di oggetti con scarsa frequenza di utilizzo e/o scarsi volumi, potrebbe risultare ingiustificato e/o costoso.

Basti pensare che per trattare nel sistema informatico una parte di provenienza interna (FAB) occorre codificarla, definirne i dati identificativi, definirne i dati gestionali, preparare la configurazione del prodotto, fotografare il processo produttivo e definire i flussi di movimentazione, se la parte è di provenienza esterna (ACQ), analizzare e codificare il processo di approvvigionamento.

La soluzione

La soluzione normalmente scelta, è di considerare l’architettura del sistema informatico come intoccabile e quindi non modificabile adattando quindi la gestione a questa architettura. Architettura basata sull’assioma che un sistema informatico può trattare solo oggetti che hanno subito prima un processo di codifica e che quindi sono dotati di un proprio identificativo che costituisce la chiave di accesso al sistema, chiave indispensabile per poter fare la successiva gestione.

Per contro l’attività di identificazione e codifica di articoli ma anche prestazioni che hanno un utilizzo molto marginale sul sistema informatico, è molto onerosa e priva di un reale ritorno specie se rapportata alla frequenza di utilizzo.  Si sceglie quindi la solita via di mezzo: non codificare i singoli oggetti, ma attribuire ad oggetti diversi, ma in certo qual modo omogenei fra di loro, lo stesso codice.

Sono nati così gli articoli “bidone”, gli articoli “punto”, “punto e virgola” e così di seguito. Si sono cioè inventati una serie di contenitori e per conseguenza di codici nei quali sono stati fatti confluire una serie di articoli e per i quali sono state create una serie di informazioni del tutto generiche. Il risultato? Si è ottenuta una riduzione del carico di lavoro per la loro gestione nel sistema, ma senza   poter avere un reale ritorno di informazioni utili per migliorare la gestione. Come direbbe un buon cavallerizzo: “si è caduti dall’altra parte del cavallo”.

Visto che in tutte le aziende esistono delle voci, siano esse prestazioni o materiali, per le quali non è giustificato creare tutta quell’impalcatura di dati richiesta per le voci codificate, la soluzione ideale dovrebbe prevedere che il sistema possa gestire in tutto il suo inviluppo anche quelle voci sprovviste di codice identificativo.

Per queste voci l’elemento caratterizzante non sarà più il codice ma bensì la descrizione che diventa un elemento identificativo univoco, tanto quanto il codice.

Anche dal punto di vista della raccolta delle informazioni consuntive e statistiche non si opera più con dei dati mediati di articoli diversi posti nello stesso contenitore, ma con dei valori puntuali associati alla singola voce fisica.

Ovviamente il sistema informativo dovrà disporre di funzioni specifiche che consentano di trattare in tutti i sottosistemi e in perfetta identità con il modo in cui sono trattati i materiali codificati, anche quelle voci che di fatto non saranno state oggetto di codifica.

La soluzione ERP Si5 di Sorma consente di trattare in modo semplice e rapido i materiali non codificati garantendo la stessa correttezza e rigore gestionale applicato per i materiali codificati.