
| |
Non uso particolari metodologie di analisi e di rappresentazione.
Ne applico alcune in funzione del contesto o del progetto usando ad esempio un diagramma IDEF0.
Da oltre 20 anni alla base di ogni mio progetto IT c'è una analisi dei processi aziendali.
Anche in un contesto di evoluzione dei Sistemi Informativi prevalentemente a livello sistemistico o dei servizi, parto dalla considerazione di come questa possa avere un qualche impatto sull'Azienda e se possa essere di stimolo di una evoluzione positiva dei processi o piuttosto essere di ostacolo alle procedure organizzative già definite e date per assodate.
Si avvia quando si intendono approfondire le relazioni ad un maggiore livello, ad esempio in un contesto di progettazione di un nuovo ERP (CC Holding) o di un Sistema di Workflow (Silent Gliss, Kernah).
Alla base delle attività di analisi vi sono le interviste presso gli utenti (es.: CC Holding) oppure, dove questo non è possibile, dei diagrammi elaborati in via preventiva da portare all'approvazione dei Direttori di Funzione (es.: Silent Gliss), sebbene questo metodo può comportare una inesatta identificazione ed interpretazione dei processi.
Non è raro, infatti, che i Direttori abbiano una percezione generale (e a volte, purtroppo, superficiale) dei processi reali.
Tra gli altri questi gli elementi che si desidera identificare:
|
Nel caso di Processi da Fornitori, si tenderà a mettere in risalto gli elementi tra loro in comune non potendo spesso influenzare la tipologia del processo. In taluni casi si evidenzieranno i processi di maggiore criticità o quelli in cui maggiori sono i vincoli imposti.
Nel caso dei processi di vendita si tenderà ad evidenziare i processi sotto il profilo del valore aggiunto generato presso i clienti così come viene da questi percepito e non, come spesso accade, dal punto di vista della Direzione Commerciale.
N.B.: In ogni caso i processi di analisi evidenziano i processi attuali e non manifestano un orientamento verso una soluzione.