Software Selection… è un nome antico che rimanda alla attività di un esperto tecnico informatico che ricerca su un mercato ricco di offerta il prodotto software migliore compatibilmente con i vincoli economici e tecnici imposti a progetto.
Questa visione deve essere superata, perché il focus di una software selection non è più sugli aspetti tecnologici, ma deve essere la definizione e la ricerca di una architettura di sistemi che interpreti la strategia dell’azienda.
Perché cambiare un sistema informativo
Le motivazioni che possono portare un’Azienda al grande passo di cambiare in parte od in toto il sistema informativo possono essere di svariata natura.
1) Paleo_informatizzazione: in aziende, non necessariamente di piccole dimensioni, il sistema è rimasto ancorato agli schemi della prima/seconda informatizzazione in cui il sistema era uno strumento per supportare il ciclo attivo e ciclo passivo dell’azienda. Nel tempo questi sistemi hanno rincorso le necessità organizzative senza un piano, snaturando il sistema con micro_personalizzazioni ingestibili e conosciute solo dagli sviluppatori.
È la sindrome di Stoccolma, in cui l’Azienda è l’ostaggio dello sviluppatore e via via se ne innamora, fino a che l’amore finisce di fronte allo stillicidio continuo di costi ed al proliferare di infiniti fogli di calcolo
2) Cambia il management: frequentemente la causa scatenante deriva dall’entrata di un nuovo management (o dal cambio generazionale) che non riesce ad avere una lettura unica dello stato dell’azienda e non riesce ad avere strumenti per governarla, in quanto il patrimonio di informazione è polverizzato in mille cassetti o depositato solo nelle memorie storiche di alcuni.
3) Cambia il business: un altro elemento che può indurre alla scelta dell’abbandono del vecchio sistema è anche, ovviamente il cambiamento del business, in cui le produzioni si trasformano in piccoli lotti personalizzati, oppure in cui cambiano radicalmente gli interlocutori, sia intesi come Clienti e Fornitori, sia l’appartenenza a nuovi Gruppi Industriali.
Uno stato di “tutti contro tutti”
Osservando l’offerta di prodotti software ci si rende facilmente conto del mutamento che il mercato ha subito negli ultimi anni.
Abbiamo assistito alla concentrazione dei sistemi ERP su pochi player, principalmente internazionali, quindi molte strutture hanno avviato lo sviluppo di sistemi dipartimentali capaci di integrare le funzionalità degli ERP tradizionali, soluzioni nate con l’obiettivo di supportare specifici processi aziendali, con l’obiettivo ultimo di recuperare uno spazio nel mercato.
Lo sviluppo di tali sistemi dipartimentali è stata quindi la risposta alla concentrazione degli ERP, nel tentativo di diversificare l’offerta su un terreno che non era ancora saturo, cioè di offrire quelle funzionalità che al momento non erano garantite dagli ERP.
Per esempio si sono sviluppati i MES per schedulazione ed avanzamento Produzione, WMS per i processi logistici, CRM per i processi commerciali, ecc…
La risposta dei principali ERP è stata, a loro volta, lo sviluppo/integrazione di tali funzionalità, a volte anche per acquisizione, per evitare che il sistema ERP diventasse un semplice repository in cui sono conservati i di dati essenziali, a cui altri sistemi si sarebbero interfacciati, svilendo, di fatto, il suo ruolo.
Oltre alla sovrapposizione funzionale tra i vari sistemi, bisogna anche considerare la presenza di applicativi nati per la gestione di meta-processi, come per esempio i sistemi work-flow, i documentali, ed i sistemi di business intelligence.
Il risultato di queste dinamiche di mercato ha creato uno stato di generale confusione perché:
C’è grande offerta di sistemi dipartimentali
C’è grande sovrapposizione di funzionalità
In questa condizione l’offerta commerciale spazia da prodotti specialistici ma capaci di interfacciarsi con tutti a prodotti integrati capaci di fare un po’ di tante funzioni.
Va ulteriormente aggiunto a questo scenario la nascita di provider in grado di offrire servizi nella logica dell’outsourcing completo di soluzioni software.
Per scegliere dobbiamo sapere chi siamo
È ormai chiaro a tutti che un sistema informativo può essere solo uno strumento con cui l’azienda realizza i propri obiettivi, quindi è inutile soffermarsi sul concetto che nessun sistema informativo è la soluzione.
Quindi è necessario prima di tutto capire quale è il DNA dell’Azienda per scegliere il sistema che meglio si adatta a questo imprinting genetico.
Schematizzando possiamo ricondurre i processi di un’azienda in quattro tipologie che dipendono dalla combinazione del livello di personalizzazione del prodotto (prodotto standardizzato o customizzato) e dalle modalità di pianificazione.
Produzione su Commessa
Produzione in Serie
Prodotto Standard
Beni Strumentali standardizzati (macchine utensili)
Beni di largo consumo
Beni di grande serie
Prodotto Custom
Beni Strumentali dedicati (macchine assemblatrici)
Prodotti configurabili con gruppi prodotti a stock
Il modello di Wortmann si presta bene a questa classificazione, in quanto suddivide i modelli organizzativi in base alla allocazione del punto di disaccoppiamento delle scorte.
In funzione di queste classi cambierà il focus organizzativo dell’azienda.
Premesso che, come tutte le schematizzazioni, questo schema presenti dei limiti, il focus aziendale sarà diverso per ognuna delle diverse tipologie. Per focus dobbiamo intendere i processi core dell’Azienda.
A puro titolo di esempio possiamo immaginare questa sintesi dei processi core per ogni diversa tipologia di azienda, con la consapevolezza che per ogni singola realtà non si troverà in un unico posizionamento nella matrice, ma diverse linee di business potranno avere diversi posizionamenti.
Saranno le ATTIVITÀ necessarie per sviluppare i processi core quelle che dovranno essere considerate le basi per definire l’architettura del sistema.
Come intendere l’architettura del Sistema Informativo
Una volta chiariti i processi core dell’azienda è necessario definire le ATTIVITÀ dei singoli processi core.
Sarebbe troppo banale distinguere le classiche due fasi di un’analisi organizzativa in as is e to be.
La domanda da porsi è: quali sono i risultati che devono emergere dall’analisi as is e dall’analisi to be?
Nella fase as is è necessario porsi con l’atteggiamento mentale UMILE, cioè assumere che se certe ATTIVITÀ vengono svolte, anche in modo inefficiente e con strumenti inadatti (intrico di fogli elettronici ed email) c’è un motivo legato al business. Quindi è proprio l’analisi delle ATTIVITÀ che vengono portate avanti faticosamente che rivelerà quelle più critiche.
In altre parole, non è la ricerca della inefficienza fine a sé stessa, ma è la ricerca delle cause che hanno mantenuto in vita una ATTIVITÀ inefficiente, perché l’organizzazione svolge i processi core comunque, sfruttando gli strumenti che ha a disposizione, e se gli strumenti non sono quelli adatti proverà a modificarli quanto possibile o a trovare metodi alternativi.
L’obiettivo della fase to be, quindi, non è la semplice enunciazione della best practice, ma deve essere la definizione di:
Caratteristiche di ogni funzione critica
Sistemi che devono garantire le funzioni critiche
Confini ed interfacce tra i sistemi informatici
In altre parole si tratta di sviluppare il deployment delle funzioni rispetto ai sistemi informatici e definirne le interfacce.
Potremmo dire che la mappatura delle ATTIVITÀ critiche sarà anche il modo per ridefinire i processi aziendali.
Definendo le interfacce si elimineranno anche le inefficienze.
Riprendendo i possibili scenari di posizionamento si può immaginare, come pure semplificazione, quali strumenti informatici core siano prioritari, indipendentemente che essi siano integrati nel sistema ERP:
Produzione su Commessa
Produzione in Serie
MtO MAKE to ORDER
ATP (Availability to Promise)
MES (schedulatore a capacità finita)
SUPPLIER PORTAL
WMS (Warehouse Management System)
…
MtO MAKE TO STOCK
CRM (Customer Relationship Management)
MES (Manufacturing Execution System)
WMS (Warehouse Management System)
B2B portal
…
EtO ENGINEERING TO ORDER
PDM/PLM Product Data Management/ Product Lifecycle Management
PM Project Management
GESTIONE COMMESSA
TICKETING Assistenza Post Vendita
…
AtO ASSEMBLY TO ORDER
PDM/PLM Product Data Management/ Product
Lifecycle Management
MES (Manufacturing Execution System)
ATP (Availability to Promise)
SUPPLIER PORTAL
TICKETING Assistenza Post Vendita
Dopo aver definito l’architettura di sistema deve essere anche stabilito il piano di realizzazione, che non deve solo contenere la schedulazione delle attività, ma deve definire tutte le soluzioni transitorie che dovranno essere implementate man mano che verranno rilasciate porzioni del sistema.
