Facoltà di Ingegneria
Corso di Laurea Specialistica in
Ingegneria Informatica per la Gestione d’Azienda
Installazione di Microsoft Navision in
una PMI e integrazione con strumenti
di Business Intelligence
Relatori: prof. Roberto CHIAVACCINI prof. Francesco MARCELLONI ing. Luciano MASCIADRI candidato Luca MARIONI
alla mia famiglia
Sommario
INDICE DELLE FIGURE ... 4
1.
INTRODUZIONE ... 5
2.
L’AZIENDA ... 6
2.1. Breve presentazione dell’azienda ... 63.
SITUAZIONE INIZIALE ... 8
3.1. Situazione AS‐IS ... 8 3.2. Situazione AS‐LIKE‐TO‐BE ... 12 3.3. Metodologie a confronto: il caso Toyota ... 154.
INSTALLAZIONE DI MICROSOFT NAVISION 4.0 SP3 ... 19
4.1. Panoramica sul prodotto ... 19 4.2. Installazione e personalizzazioni ... 20 4.3. Punti di forza ... 21 4.3.1. Aspetti architetturali e implementazione di MS Navision ... 22 4.3.2. Principi di Inventory Costing ... 26 4.3.3. Inventory Posting e costo del venduto ... 30 4.4. Vantaggi e cambiamenti ... 405.
BUSINESS INTELLIGENCE ... 42
5.1. Cos’è la BI ... 42 5.2. SQL Server 2005 Reporting Service ... 46 5.3. Funzionamento dei report: RDL ... 48 5.4. Report per Univergomma ... 54 5.5. Vantaggi e cambiamenti ... 586.
COMUNICAZIONE AZIENDALE ... 60
6.1. Importanza della comunicazione in un’azienda ... 60 6.2. Microsoft Sharepoint Portal Server 2007 ... 61 6.3. Portale UGShare per Univergomma ... 64 6.4. Architettura di Sharepoint ... 66 6.5. Integrazione tra Sharepoint e Reporting Services ... 68 6.6. Vantaggi e cambiamenti ... 707.
CONCLUSIONI ... 71
7.1. Possibili evoluzioni ... 71 7.2. Valutazioni d’impatto ... 74Indice delle figure
FIGURA 1 ‐ SCHEMA AZIENDALE DI UNIVERGOMMA E FUNZIONALITÀ DI BUSINESS ... 7
FIGURA 2 ‐ PROCESS DIAGRAM EVASIONE ORDINI CLIENTE ... 9
FIGURA 3 ‐ PROCESS DIAGRAM VARIAZIONE ORDINI CLIENTE ... 10
FIGURA 4 ‐ DIAGRAMMA DI ATTIVITÀ DEL PROCESSO SPEDIZIONI ... 11
FIGURA 5 ‐ MAPPATURA DI MAGAZZINO ... 14
FIGURA 6 ‐ MAGAZZINO TOYOTA PRIMA DEL LEAN THINKING ... 16
FIGURA 7 ‐ MAGAZZINO TOYOTA DOPO IL LEAN THINKING ... 17
FIGURA 8 ‐ MAGAZZINO TOYOTA DOPO IL PASSAGGIO AD ORDINI GIORNALIERI ... 18
FIGURA 9 ‐ MODULI FUNZIONALI DI MICROSOFT NAVISION ... 20
FIGURA 10 ‐ DETTAGLIO DELL'INTERFACCIA GRAFICA DI MICROSOFT NAVISION ... 22
FIGURA 11 ‐ SCHEMA FUNZIONALE A VENTAGLIO DI MICROSOFT NAVISION ... 23
FIGURA 12 ‐ ARCHITETTURA INTEGRATA DI MICROSOFT NAVISION ... 24
FIGURA 13 ‐ FASI DI UN PROGETTO DI IMPLEMENTAZIONE NAVISION ... 25
FIGURA 14 ‐ CONFIGURAZIONE DI UN TEAM DI IMPLEMENTAZIONE MICROSOFT NAVISION ... 26
FIGURA 15 ‐ POLITICA DI COSTING FIFO IN UN MAGAZZINO ... 29
FIGURA 16 ‐ POLITICA DI COSTING LIFO IN UN MAGAZZINO ... 29
FIGURA 17 ‐ POLITICA DI COSTING A MEDIA PESATA IN UN MAGAZZINO... 30
FIGURA 18 ‐ INTERDIPENDENZA TRA INVENTORY INCREASE, INVENTORY DECREASE E GENERAL LEDGER ... 30
FIGURA 19 ‐ INVENTORY POSTING ... 31
FIGURA 20 ‐ CREAZIONE DELL'ARTICOLO DI PROVA ITEM ... 33
FIGURA 21 ‐ PRIMO ORDINE DI ACQUISTO PER L'ARTICOLO ITEM ... 34
FIGURA 22 ‐ COSTO MEDIO DELL'ARTICOLO ITEM DOPO IL PRIMO ACQUISTO ... 35
FIGURA 23 ‐ DRILL‐DOWN SUL COSTO MEDIO DOPO IL PRIMO ACQUISTO ... 35
FIGURA 24 ‐ COSTO MEDIO DOPO IL SECONDO ACQUISTO ... 36
FIGURA 25 ‐ ORDINE DI VENDITA PER L'ARTICOLO ITEM ... 37
FIGURA 26 ‐ COSTO MEDIO PRIMA DELL'ADJUST COST ITEM ENTRY ... 38
FIGURA 27 ‐ SITUAZIONE DI MAGAZZINO PER L'ARTICOLO ITEM DOPO LA VENDITA DI 18 PEZZI ... 38
FIGURA 28 ‐ DRILL‐DOWN SUL COSTO MEDIO PRIMA DELL'ADJUST COST ITEM ENTRY ... 39
FIGURA 29 ‐ DRILL‐DOWN SUL COSTO MEDIO PRIMA DELL'ADJUST COST ITEM ENTRY ... 39
FIGURA 30 ‐ SCHEMA VARIAZIONI FUNZIONALI CALL CENTER E LOGISTICA ... 41
FIGURA 31 ‐ ARCHITETTURA DI UN SISTEMA DI BUSINESS INTELLIGENCE ... 42
FIGURA 32 ‐ SISTEMA AVANZATO DI BUSINESS INTELLIGENCE ... 45
FIGURA 33 ‐ ARCHITETTURA DI SQL SERVER 2005 REPORTING SERVICES... 47
FIGURA 34 ‐ INTEGRAZIONE SQL SERVER 2005 CON PIATTAFORME MICROSOFT ... 48
FIGURA 35 ‐ DIAGRAMMA UML DELLO SCHEMA STRUTTURALE RELATIVO AD UN FILE RDL ... 52
FIGURA 36 ‐ ARCHITETTURA ED ELABORAZIONE DI UN REPORT ... 53
FIGURA 37 ‐ REPORTING SERVICES ARCHITECTURE ... 54
FIGURA 38 ‐ REPORT R24 VALORIZZAZIONE MAGAZZINO ... 55
FIGURA 39 ‐ REPORT R25 VALORIZZAZIONE MAGAZZINO AD UNA CERTA DATA ... 56
FIGURA 40 ‐ REPORT R26 VENDITE AGENTI ... 57
FIGURA 41 ‐ REPORT R01 VENDITE ... 58
FIGURA 42 ‐ GRAFICO DEL VALORE STRATEGICO CON LA BUSINESS ANALYSIS ... 59
FIGURA 43 ‐ STRUTTURA GENERALE DELLA PIATTAFORMA MICROSOFT SHAREPOINT ... 61
FIGURA 44 ‐ INTEGRAZIONE DI SHAREPOINT CON I SISTEMI ERP ... 65
FIGURA 46 ‐ INFRASTRUTTURA TECNOLOGICA PER SHAREPOINT ... 67
FIGURA 47 ‐ RICHIESTA DI UNA RISORSA NEL PORTALE SHAREPOINT ... 68
FIGURA 45 ‐ INTEGRAZIONE TRA SHAREPOINT E REPORTING SERVICES ... 69
FIGURA 48 ‐ POSSIBILE STACK DI INTEGRAZIONI PER UNA BUSINESS COMPANY ... 71
FIGURA 49 ‐ RUOLO DI ANALYSIS SERVICES ... 72
FIGURA 50 ‐ RUOLO DI INTEGRATION SERVICES ... 73
1. Introduzione
Il presente elaborato ha come scopo essenziale la presentazione di un “caso di studio” molto significativo, in cui si possono esaminare gli impatti, le trasformazioni, i risultati e i miglioramenti che ha comportato l’installazione di un sistema ERP, nel nostro caso Microsoft Navision 4.0, in una PMI del settore della distribuzione e l’integrazione del sistema informativo così ottenuto con importanti strumenti per l’analisi dei processi aziendali e la Business Intelligence da un lato, e piattaforme tecnologiche avanzate per la comunicazione aziendale dall’altro.
Qui di seguito analizzeremo in primo luogo l’azienda, offrendo una breve panoramica del suo ambito operativo e della sua struttura.
Poi passeremo ad evidenziare la situazione iniziale in cui l’azienda era al momento della richiesta del nuovo sistema informativo, analizzando brevemente le criticità principali emerse e alcuni processi aziendali; successivamente vedremo qual è la situazione aziendale che si è ottenuta successivamente all’installazione di Navision e i cambiamenti che ne sono derivati, per poi guardare aspetti tecnici relativi a questo recente ERP prodotto dalla Microsoft, con particolare riguardo alle metodologie di costing. Nella seconda parte ci occuperemo di Business Intelligence: vedremo innanzitutto cos’è, a che serve e quali sono le caratteristiche essenziali. Passeremo dunque a parlare dello strumento utilizzato nel nostro caso, SQL Server 2005 Reporting Service e del suo impiego all’interno del sistema informativo realizzato. Nella terza parte affronteremo il tema della comunicazione aziendale, cruciale per gli ingranaggi di business delle imprese moderne e metteremo in luce un potente strumento, messo a disposizione sempre da Microsoft, per risolvere le problematiche connesse alla comunicazione interna ed esterna alle aziende.
Nella quarta parte valuteremo la possibilità di estendere il sistema informativo così realizzato con ulteriori strumenti per la Business Analysis e il Customer Relationship Management, accennando brevemente alle funzionalità che essi possono implementare.
Infine faremo il punto della situazione sull’impatto economico ed organizzativo che ha avuto l’introduzione del nuovo sistema informativo nell’azienda in esame.
2. L’azienda
2.1. Breve presentazione dell’azienda Univergomma S.p.A. è un’azienda che opera nel settore della distribuzione di pneumatici ed è leader di mercato in Italia. E’ nata dapprima come distributore locale di pneumatici ai gommisti dell’area di Firenze, poi nel tempo è cresciuta e si è sviluppata sul territorio nazionale mediante una politica di acquisizione‐incorporazione aziende. La sede principale è a Scandicci (FI), dove è situato anche il deposito più importante al quale consegnano i fornitori e che fa da “hub” per altri 2 depositi periferici situati a Civitanova Marche e Brescia. Esiste poi una struttura di depositi minori situati a Castelfiorentino, Prato, Poggibonsi, Perugia e Genova, sempre riforniti dall’hub di Scandicci, in cui è prevista anche vendita al dettaglio.Nella sede principale sono situati il centro direzionale e il call center che prende le ordinazioni; inoltre a Scandicci viene ricevuta la merce dai fornitori, e quindi si provvede allo smistamento verso i vari centri di distribuzione della rete.
I due centri di distribuzione più importanti, quelli di Civitanova Marche e di Brescia, effettuano vendita all’ingrosso, devono gestire un ampio magazzino e pertanto hanno un solido controllo di gestione.
Le altre sedi si configurano più come grossi centri di distribuzione al dettaglio. Quindi oltre a dover gestire comunque un magazzino (sono pur sempre depositi), essi devono supportare sia la vendita all’ingrosso che al dettaglio.
Ci sono poi diversi agenti che si occupano dell’interfacciamento tra il cliente finale e l’azienda, facendo da tramite funzionale per la transazione col cliente. Questi agenti fanno riferimento ad uno specifico deposito. Dati generali: FATTURATO: Nell’anno 2006 è stato conseguito un fatturato di 40 milioni di €. FORZA LAVORO: 70 dipendenti. VOLUME PRODUZIONE: L’azienda gestisce circa 11000 articoli di magazzino.
Ecco lo schema generale dell’azienda, in cui è mostrata l’interconnessione dei vari centri di distribuzione e le funzionalità commerciali che ognuno di esso implementa.
3. Situazione iniziale
3.1. Situazione ASIS
Allo stato iniziale, dopo un’accurata analisi elaborata grazie all’osservazione da vicino dei processi aziendali e mediante interviste effettuate a gran parte del personale coinvolto, è stata rilevata una notevole criticità sia interna all’impresa che verso il cliente, la maggior parte delle quali erano presenti in ambito logistico e nell’interfacciamento col call center. I problemi derivavano da diversi ambiti:
• DIFFERENZIAZIONE DI PRODOTTO: L’evoluzione del mercato degli ultimi anni ha portato ad un’esplosione della gamma dei prodotti disponibili. L’azienda è arrivata a dover gestire dai 7800 prodotti del 2001 ai circa 11000 del 2007: ciò ha comportato enorme crisi logistica, soprattutto legata al numero di scorte e agli spazi operativi all’interno di ogni magazzino. Infatti l’aumento della gamma di prodotti vendibili, dovuto alla massiccia differenziazione di prodotto portata avanti negli ultimi anni dalle case produttrici (si pensi solo che per i nuovi modelli di Porsche le gomme di una vettura non sono tutte uguali ma sono differenti a seconda di dove vengono montate, se a dx, a sx, anteriori o posteriori!), ha portato all’esigenza di creare nuovi spazi per i magazzini senza doverne acquisire dei nuovi, di riorganizzare la logistica e di regolamentare i flussi di materiale. Allo stato iniziale infatti, appena l’esplosione del numero di prodotti vendibili ha cominciato ad influire sulla logistica, si sono registrate difficoltà oggettive nel reperimento di merci all’interno dei magazzini, nella gestione degli spazi fisici (in giornate di lavoro intense capitava che i trasportatori non riuscivano a trovare spazio per scaricare la merce!) e nella logistica in generale. In questo scenario è evidente che ne risentono soprattutto i tempi di prelievo e stoccaggio della merce, con ovvi influssi sulla soddisfazione del cliente.
• SOVRACCARICO DEL CALL CENTER: il call center di Univergomma ha il compito di prelevare gli ordini dai clienti e passarli in gestione ai reparti di competenza. Tuttavia esso si trovava spesso a dover svolgere compiti che non gli si addicevano: stampa dei DDT, verifica disponibilità dei prodotti, etc. Questo era dovuto in parte a carenze organizzative, in parte alla volontà di alleggerire il carico di lavoro ai magazzini, già provati dai problemi descritti in precedenza, per cercare di ridurre il time‐to‐customer dell’azienda.
• ELEVATI COSTI DI TRASPORTO: Tra le voci di bilancio in uscita risulta abbastanza onerosa quella relativa al trasporto, affidato a logistica interna. Infatti servirsi di un proprio sistema di trasporto comporta elevati costi di gestione, sia del parco automezzi che della manutenzione dello stesso.
• RESI E RECLAMI: L’azienda ha una grande mole di resi e reclami. Per resi si intendono le coperture buone e da reinserire ne magazzino, per reclami tutto ciò che risulta difettato e non più vendibile per il quale a seconda delle marche l’azienda si assume l’onere del risarcimento o restituire al fornitore in attesa di nota credito. Tutte queste bolle di reso o reclamo una volta rientrate nel magazzino devono essere importate nel sistema tramite immissione di un documento: bolla di reso e/o di reclamo.
Qui di seguito riportiamo il diagramma di attività che descrive i processi logistici ed evidenzia le criticità interne.
Criticità interne all’azienda • I pancali non sono aggiornati tempestivamente; capita spesso di non trovare la merce nel pancale indicato in bolla (organizzativo, integrazione dati) • Quando prelevano la merce spesso trovano pneumatici vecchi, deve essere avvisato il cliente. In fase di inventario questa merce potrebbe essere stipata in un luogo ben specifico (organizzativo) Criticità emerse dall’analisi • L’85% delle sistemazioni della merce nelle gabbie avviene dopo che il carico di magazzino è stato fatto, il 15% prima (organizzativo) • Per sicurezza il pancale viene inserito due volte. • Non sempre vengono riportate in AS/400 le correzioni sui DDT. (organizzativo) • Non c’è una gestione formalizzata dei corrieri. (organizzativo) • Chi prepara la merce non sempre segna in bolla errori o mancanza di merce sui pancali. (organizzativo) • Le bolle non vengono firmate dal corriere ma spesso vengono firmate dal personale. (organizzativo) 3.2. Situazione ASLIKETOBE Si vuole quindi progettare e realizzare un sistema informativo che apporti notevoli miglioramenti ai processi generali di business dell’impresa, con particolare riguardo al settore logistico e di trasporto. Esso infatti rappresenta la maggiore leva operativa per Univergomma, e quindi migliorare la logistica significa in gran parte migliorare l’azienda nel suo complesso. Gli obiettivi principali da realizzare sono dunque: • Riduzione delle scorte: è necessario innanzitutto implementare un sistema di gestione del magazzino che contribuisca a diminuire il numero delle scorte, sia nel deposito principale di Scandicci, che in quelli periferici. Poiché infatti la gamma dei prodotti vendibili è aumentata, risulta necessario agire sul numero di scorte per sfruttare al meglio gli spazi logistici senza dover apportare modifiche strutturali.
• Ottimizzazione degli spazi: un’oculata gestione del magazzino dovrebbe portare ad identificare strategie operative per sfruttare gli spazi disponibili traendone il miglior utilizzo possibile. Bisogna essere in grado di garantire lo spazio necessario quando serve e occuparlo quando non è necessario per altre operazioni.
• Riduzione tempi di stoccaggio e di prelievo: se si riesce a diminuire il time‐to‐customer complessivo, in gran parte gonfiato dal malfunzionamento della gestione logistica, si possono ottenere elevate performances, soprattutto in termini di customer satisfaction. Per farlo è dunque indispensabile intervenire sul prelievo e sullo stoccaggio diminuendone i tempi. • Riduzione costi legati al trasporto: le uscite relative al trasporto della merce sono elevate e bisognerebbe trovare un modo per diminuirle o abbatterle. • Alleggerire call center: il lavoro del call center risulta troppo macchinoso e pesante; inoltre comporta delle responsabilità maggiori rispetto a quello a cui normalmente è destinato un call center (ad es. la stampa dei documenti di trasporto). Attività previste L’obiettivo a livello operativo è quello di supportare la logistica di magazzino in modo tale da: • disporre sempre di dati affidabili riguardanti articoli presenti, quantità e relativa
collocazione
• guidare gli operatori nelle operazioni di ricevimento merce e spedizione fornendo loro le informazioni necessarie per prelevare e collocare la merce nel deposito. Si desidera pertanto realizzare un modello operativo che consenta di: • supportare le operazioni di ricevimento e di spedizione della merce e le attività correlate di stoccaggio e prelievo • riorganizzare la gestione dei documenti necessari per la spedizione della merce facendo in modo tale che la documentazione cartacea necessaria venga prodotta sempre al momento più opportuno • migliorare la precisione dei dati inventariali (quantità disponibili e relativo posizionamento in magazzino) • tenere traccia della movimentazione merce all’interno di ciascun deposito.
Per il conseguimento degli obiettivi di progetto è necessario prevedere le seguenti attività preliminari necessarie per definire un nuovo modello operativo da supportare con le procedure messe a disposizione da Navision:
1. Definizione di un nuovo modello operativo per:
a. gestione ordini cliente e relativa spedizione : nel caso in cui un ordine cliente sia già in fase di spedizione, in fase di prelievo o sia già stato prelevato e sia in attesa della spedizione, può essere modificato.
b. ricevimento merce: il nuovo modello prevede che il call‐center gestisca gli ordini cliente dal loro arrivo fino all’evasione ma che i documenti di spedizione vengano stampati in magazzino solo al momento della spedizione della merce.
c. resi da cliente d. resi a fornitore 2. Mappatura del magazzino
Qualora, per un deposito, si desideri gestire la movimentazione interna secondo il modello di riferimento proposto si rende necessario una mappatura secondo lo schema raffigurato qui di seguito che prevede la definizione e l’attribuzione di un nome identificativo a:
a. Zone
sono le zone logiche in cui è suddiviso ogni magazzino (spedizione, ricevimento, stoccaggio, prelievo, ecc.
b. Collocazioni
sono le unità fisiche di stoccaggio merce che vanno qualificate anche in funzione del loro utilizzo in magazzino
3. Realizzazione di un prototipo
Questa attività ha lo scopo di provare sul campo le soluzioni proposte e di addestrare il personale ad operare secondo l’ambiente di lavoro configurato con il nuovo sistema informativo basato su Navision.
3.3. Metodologie a confronto: il caso Toyota
Uno dei casi di successo più noti in letteratura riguardo a reingegnerizzazione dei processi logistici è sicuramente quello della Toyota, noto agli studiosi col nome di Lean Warehousing. Il concetto di “lean production” ha origine nella produzione di massa e si è poi esteso ad altri settori, quali l’aeronautica e il settore bancario. Al contrario la logistica, e la distribuzione in generale, non è produzione di massa ma si configura come un’attività del settore dei servizi; infatti, salvo rare eccezioni, i volumi di merce gestita da un magazzino non assumono proporzioni tali da potere essere definita “massiva” e raramente i processi logistici possono essere standardizzati. Il fatto che ad esempio il cliente non solo può avere diverse preferenze su un colore, ma può anche scegliere tra centinaia o migliaia di prodotti simili ma differenti dà maggiore risalto alla differenza fra produzione e distribuzione. Come può essere applicato il principio di “produzione snella” allo sviluppo dei centri di distribuzione? La Toyota ha applicato il cosiddetto principio delle 5 ‘S’: • Sortation (ordinamento): è il processo di separazione tra strumenti e accessori necessari da quelli che non servono e rimozione dei materiali non necessari; • Straightening (raddrizzamento): significa che gli oggetti vengono disposti in un ordine che ne renda l’utilizzo il più facile possibile • Shining (lucidatura): è la campagna di “clean‐up”. I magazzini lean devono essere dotati di un eccellente ordine.
• Standardization (standardizzazione): è lo sviluppo di procedure e sistemi usati per monitorare e controllare le prime 3 S.
• Sustaining (mantenimento): è il mantenimento del magazzino stabilizzato e lean, attraverso politiche di miglioramento continuo.
Grazie all’adozione di questo criterio la Toyota all’inizio degli anni novanta è riuscita a riorganizzare il proprio magazzino di Chicago attraverso l’implementazione di diversi step intermedi. Il primo step è stato quello di ridurre fisicamente la capienza degli scomparti e riordinare le zone di stoccaggio per grandezza e frequenza di domanda: infatti altro problema era quello legato al fatto che i mezzi sia piccoli che grandi durante lo stoccaggio o il picking si incontravano causando “traffico” nel magazzino, perdita di pezzi e lentezza nelle operazioni logistiche.
Figura 6 ‐ Magazzino Toyota prima del Lean Thinking
Perciò divenne importante segregare gli oggetti in piccoli, medi e grandi, cosicchè poteva essere ridotto il traffico di mezzi diversi nella stessa zona.
Lo step successivo è stato quello di introdurre i concetti di standardizzazione del lavoro e controllo visivo attraverso la divisione della giornata lavorativa in cicli di dodici minuti. Un intervallo di questa dimensione fu deciso in quanto miglior compromesso tra distanza da percorrere e dimensione dei carrelli nell’effettuare un giro del magazzino per caricare o scaricare un carrello.
Durante ogni ciclo un associate, come venivano chiamati i lavoratori pagati ad ora, aveva il compito di prelevare o stoccare in diversi numeri di linee, a seconda della dimensione del pezzo. Ad esempio, in un ciclo di picking di 12 minuti un associate potrebbe dover prelevare in 30 linee di pezzi piccoli o 20 di pezzi medi oppure 12 di pezzi grandi.
Figura 7 ‐ Magazzino Toyota dopo il Lean Thinking
Una lavagna per il controllo dell’avanzamento del lavoro fu costruita tra il dock di ricevimento merce e quello di consegna, allo scopo di mostrare a tutti i lavoratori il numero di cicli ancora in sospeso e il tempo a disposizione per completarli. Ciò rese possibile che chiunque nel team potesse visualizzare esattamente come stava procedendo il lavoro ed eliminare la necessità di un team leader, poiché il team diveniva cosi autogestito e auto controllato.
Tutto ciò divenne la base di partenza per le cosiddette attività di kaizen attuate a partire dal 1992 in poi. Contemporaneamente all’introduzione dei cicli di picking, il sistema informativo della Toyota fu riprogrammato per raggruppare gli ordini per committenza e per locazione all’interno di ogni magazzino in modo tale che potesse essere stampato un set di etichette per il picking in un preciso ordine, in modo da ottimizzare i cicli di dodici minuti. Il picking in questo modo veniva dimensionato non alla quantità di materiale da prelevare ma al ciclo di 12 minuti e ai pezzi che potevano essere prelevati in modo ottimale durante tale ciclo, considerando soprattutto la loro dimensione.
Dopo un lungo periodo di test e lavoro per stabilizzare questo sistema, nell’Agosto del 1995 la Toyota fu pronta alla transizione da ordini settimanali ad ordini giornalieri e alla gestione dinamica di tali ordini da parte della committenza. Questo passaggio ebbe due effetti importanti: il primo effetto fu quello dell’aumento di spazio disponibile all’interno di ogni deposito, perché l’estrema dinamicità della gestione degli ordini ha reso superflua la presenza di
linee di magazzino d’appoggio; altro aspetto fu la riduzione delle aree di stoccaggio dovuta ai flussi di materiale più veloci che non necessitano depositi temporanei.
Figura 8 ‐ Magazzino Toyota dopo il passaggio ad ordini giornalieri
Questa soluzione si è rivelata vincente ed è stata presa come modello da tante altre realtà aziendali medio‐grandi.
Oltre a ciò, tutti i moderni ERP e sistemi integrati che si occupano anche di logistica e warehousing hanno un modello implementativo che ricalca a grandi linee ciò che è stato fatto ormai 15 anni fa dalla Toyota. Ad esempio, i grandi ERP di casa Microsoft come Axapta e Great Plains adottano un metodo gestione di magazzini che consente un’indicizzazione personalizzata della merce e la possibilità di tracciare con moderne tecnologie (RFID e chip wireless) gli oggetti immagazzinati, che consente un rapido picking ed un efficiente stocking.
Microsoft Navision, seppure rimanendo ancorato a dimensioni aziendali ridotte, permette un lean warehousing, anche se non è consentita ancora (ma lo sarà in versioni future) una completa integrazione con tecnologie avanzate.
4. Installazione di Microsoft Navision 4.0 SP3
4.1. Panoramica sul prodotto Microsoft Dynamics Navision è un sistema integrato per la gestione di praticamente tutti i processi aziendali che un’impresa di medio‐piccole dimensioni si trova quotidianamente a dover affrontare. Le caratteristiche principali di Navision sono:Qualsiasi vista sui dati: grazie alla tecnologia SIFT(Sum Indexed Flow Technology) le viste, i dati, i saldi, gli aggregati, vengono istantaneamente calcolati dal sistema in base al tipo di interrogazione desiderata dall’utente, che può filtrare liberamente i dati anche in base alle dimensioni.
Criteri di analisi illimitati: sono possibili relazioni e analisi su un numero illimitato di criteri, creando dimensioni ed effettuando analisi in base ad esse.
Funzionalità intercompany: si possono raggruppare diverse aziende (ad es. una filiera) per condividere dati e informazioni integrandoli in un unico sistema ERP.
Migliore organizzazione: le procedure aziendali vengono perfezionate con l’uso delle note di stoccaggio e di prelievo. La gestione dei resi tiene conto anche dei costi aggiuntivi come lo stoccaggio.
Condivisione e consultazione informazioni on‐line: il portale di Navision, Emloyee Portal, offre un’interfaccia intuitiva, basata sul web, che consente ai propri collaboratori di accedere con maggiore facilità e tempestività sia alle informazioni presenti in Navision che ai documenti condivisi, il tutto all’interno di un ambiente Intranet protetto. Navision viene personalizzato su misura per soddisfare esattamente le esigenze del cliente. Dal punto di vista tecnico ha le seguenti caratteristiche: • Integrazione delle diverse funzionalità che caratterizzano gli ERP di seconda generazione quali Relationship Management, Gestione Assistenza, e‐Business, Supply Chain Collaboration, Multi‐dimension; • Un motore di sviluppo semplice e potente che consente di realizzare rapidamente anche le più complesse personalizzazioni; • Un’architettura a 3 livelli con Application Server, piattaforma Microsoft con elevata integrazione tra prodotti Microsoft e l’ERP, database nativo o SQL Server; • Client multilingua attivabile a caldo; • Un ambiente di sviluppo a più livelli: dal Designer per utenti evoluti, alla possibilità di accedere al codice sorgente. Come ormai la maggior parte dei sistemi Enterprise Resource Planning (ERP), Navision suddivide le funzionalità messe a disposizione in moduli (che nel caso specifico sono detti granuli),
implementabili in stadi successivi ma perfettamente integrati ed interagenti tra di loro; a questo si aggiunge la caratteristica, molto apprezzata dai clienti finali e poco comune in prodotti orientati verso le PMI, per cui la determinazione del prezzo della soluzione scelta dal cliente avviene in base ai granuli acquistati piuttosto che in funzione del numero di utenti abilitati. Al momento dell’implementazione, al cliente viene installato tutto il prodotto, con la particolarità di lasciare “spenti” quei granuli che non sono stati acquistati e che quindi non risultano presenti nella licenza. Figura 9 ‐ Moduli funzionali di Microsoft Navision La varietà di moduli integrati che è possibile scegliere e includere nella licenza che si acquista sono: • Contabilità • Produzione • Acquisti e Vendite • Relationship Management • Gestione assistenza • Logistica • Commesse e progetti • E‐Business Collaboration • Analisi • Tecnologia e sviluppo 4.2. Installazione e personalizzazioni
Per migliorare l’efficienza e l’efficacia dei propri processi logistici di magazzino Univergomma, nell’ambito del progetto di implementazione del proprio ERP aziendale, ha deciso di rivedere tali processi, di informatizzarli e di migliorarne il supporto gestionale.
Il prodotto scelto per realizzare il nuovo ERP, Microsoft Dynamics Navision 4.0, mette a disposizione tutti gli strumenti necessari per implementare funzionalità avanzate a supporto della logistica di magazzino.
Dispone infatti di un modulo specifico denominato WMS, Warehouse Management System, che è stato concepito per aziende operanti nel settore della distribuzione per le quali è di fondamentale importanza:
• presentare le informazioni in funzione delle esigenze del reparto che le utilizza (per esempio, le informazioni necessarie all’ufficio vendite relative ad un ordine cliente sono diverse da quelle utilizzate dal personale di magazzino per l’evasione dello stesso);
• gestire i flussi di merce non solo in termini di trasferimento tra depositi, ricevimento da fornitori e spedizione a clienti, ma anche in funzione delle esigenze di prelievo, stoccaggio e movimentazione interna al deposito stesso.
L’installazione effettuata per Univergomma è standard. Sono state effettuate personalizzazioni mirate all’interno di singoli granuli per permettere l’interfacciamento degli specifici processi aziendali con l’ERP. Inoltre sono stati affiancati anche i moduli di:
• DocFinance: è un modulo applicativo per la gestione anticipata di tesoreria che integra i dati provenienti dal Corporate Banking. L’integrazione col sistema informativo aziendale ne caratterizza la completezza. Le funzioni che esso offre sono: gestione anticipata di tesoreria, gestione rischio cambio, ottimizzazione e simulazioni, statistiche lavoro bancario, integrazione sistema contabile.
• Web B2B: questo modulo permette l’interfacciamento con fornitori e clienti, garantendo un business‐to‐business di ampia portata e velocizzato grazie al Web
4.3. Punti di forza
Microsoft Navision possiede dunque numerose caratteristiche che ne fanno un prodotto valido a disposizione delle PMI. L’estrema velocità di elaborazione, ottenuta con procedure brevettate, sulle quali la Microsoft tende a mantenere il più stretto riserbo, è uno dei punti di forza principali. Tuttavia, a causa del segreto aziendale che copre queste procedure, non potremo addentrarci ad esaminare i motivi delle eccellenti prestazioni di questo prodotto.
Pertanto in questa sede è nostra intenzione porre in risalto da un lato l’architettura che è alla base del funzionamento di Microsoft Navision, dall’altro cercheremo di spiegare l’innovativo metodo di calcolo dei costi della merce in giacenza nei magazzini e quindi il motore con cui Navision permette ad un’azienda di gestire la logistica, grazie ai quali le aziende che implementano il granulo Warehouse hanno la possibilità di ottenere grandi vantaggi in termini di efficienza e qualità dei propri processi logistici, oltre che notevoli influssi sugli aspetti di management e di scelte operative e tattiche aziendali.
Non è sempre facile per un consulente informatico che va ad installare Navision in una PMI far comprendere come funziona il prodotto, a livello architetturale, ma ancora di più quali sono gli effetti del suo funzionamento sulle politiche gestionali. Nella maggior parte dei casi, soprattutto in realtà aziendali di ridotte dimensioni, le imprese sono restie a modificare il proprio asset gestionale e piegarlo al funzionamento del nuovo sistema informativo; tale difficoltà è legata in primo luogo ad
una mancata conoscenza delle diverse tipologie di management aziendale da parte dell’impresa, che spesso risulta ancorata ad un imprinting di vecchio stampo, talvolta artigianale o accentrato (come nelle piccole aziende), ma anche al fatto che in un’azienda, piccola o media che essa sia, il management non riesce a comprendere da subito la necessità di cambiare le proprie politiche di business anche se esse funzionano bene e ottengono i risultati sperati.
Ecco perché il lavoro di consulenza su prodotti con Microsoft Navision deve essere preceduto da un’ampia fase di dialogo con la committenza per capire sia le reali esigenze operative che devono essere realizzate, sia per far comprendere la portata innovativa che viene introdotta dall’implementazione del nuovo sistema informativo nei processi operativi, in quelli decisionali e in genere in tutti gli strati aziendali.
4.3.1. Aspetti architetturali e implementazione di MS Navision
Microsoft Navision è dunque un’applicazione integrata, che poggia tutto il suo funzionamento su un solido e potente database, che può essere nativo o esteso con Sql Server 2005. Le caratteristiche primarie di cui è dotato questo prodotto sono dunque la scalabilità e l’estrema flessibilità, indispensabili oramai in tutti i sistemi informativi attuali.
Oltre a queste caratteristiche, Navision possiede alcune funzionalità che lo rendono uno strumento davvero usabile: è multi‐company, cioè consente di raggruppare diverse imprese inglobandone la gestione (ad es. una filiera), è multy‐country, cioè consente l’utilizzo del programma impostando i settaggi per il paese desiderato, ed è multi‐currency, consentendo di poter utilizzare la valuta desiderata.
A tutto questo si aggiunge la semplicità dell’interfaccia, stile Microsoft Office, come si può vedere nella figura, che rende facile l’utilizzo anche per utenti non molto esperti; in questo modo il training è ridotto al minimo per i nuovi utenti, in modo da ridurre i costi di formazione per il personale. Inoltre le funzioni sono raggruppabili per processi consentendo una facile individuazione.
Dal punto di vista architetturale Microsoft Navision si configura come un grosso blocco centrale, che costituisce il nucleo elaborativo del programma, sul quale sono poi montati dei moduli applicativi (Demand Planner, PSA, CRM e Analytics) che vanno a completare il blocco base. Al livello superiore poi sono sviluppate le personalizzazioni di settore, cioè vengono rese disponibili quelle funzionalità specifiche di un determinato settore, in modo da accrescere i vantaggi e quindi il valore che il sistema ERP può garantire all’azienda che lo implementa. Inoltre ci possono essere dei processi o delle attività specifiche di ogni azienda che non è possibile mappare direttamente in Navision; sono dunque
necessarie delle ulteriori personalizzazioni per poter gestire tali attività. Figura 10 ‐ Dettaglio dell'interfaccia grafica di Microsoft Navision
Nella figura è possibile esaminare lo schema funzionale, definito “a ventaglio”, in cui è possibile notare ciò che è built‐in con Navision (in color bronzo) e le personalizzazioni che è possibile effettuare.
Figura 11 ‐ Schema funzionale a ventaglio di Microsoft Navision
Nella prossima figura, invece, si può comprendere l’architettura fisica e l’interazione con l’ambiente esterno di Microsoft Navision.
A livello fisico, Navision può essere visto come un assemblaggio di oggetti di diversa natura: in figura gli oggetti sono rappresentati dai quadratini che messi insieme vanno a formare un grosso oggetto; quelli più scuri indicano gli oggetti necessari al funzionamenti dell’ERP, mentre quelli più chiari indicano gli oggetti inseriti nel sistema per personalizzare la soluzione, rispettivamente le personalizzazioni relative alla nazionalità, al cliente e ai singoli processi di core business.
Figura 12 ‐ Architettura integrata di Microsoft Navision
Tutto ciò va a creare un ambiente integrato accessibile dall’esterno direttamente, attraverso la GUI (ad es. gli impiegati) oppure attraverso un application server al quale possono collegarsi utenti “esterni” come partners commerciali o fornitori. Alle spalle il tutto è sostenuto da un solido Database Engine che può essere sia quello built‐in di Navision che Microsoft SQL Server 2005.
Installare ed implementare una soluzione basata su Navision in un’azienda è un progetto costituito da diversi step intermedi.
In primo luogo bisogna capire quali sono le reali esigenze del committente e i motivi che lo hanno spinto a richiedere l’adozione del nuovo ERP. Poi si passa ad esaminare in dettaglio la situazione “as‐is”, cioè come funziona l’azienda nei minimi dettagli, cogliendo punti critici e segnalando aspetti da modificare. Questa fase è molto importante perché una corretta e approfondita analisi del funzionamento dell’azienda permette di avere un quadro chiaro e completo sin dall’inizio e di poter risolvere rapidamente eventuali problemi in fase di realizzazione.
Figura 13 ‐ Fasi di un progetto di implementazione Navision
Successivamente si procede al mapping, in cui si vanno a mappare le caratteristiche dell’azienda e i suoi processi all’interno di Navision, al termine del quale si ottiene un modello preliminare della business solution, che deve essere verificato e accettato dalla committenza. Il modello definitivo della business solution, invece, si ottiene soltanto al termine della fase di realizzazione. Se poi il sistema dovrà girare su una macchina diversa da quella su cui è stato realizzato si dovrà procedere alla migrazione alla locazione effettiva, con opportuni test di sistema. Una volta terminata l’installazione deve essere garantita una continua manutenzione. Per offrire un buon lavoro di consulenza è consigliabile costituire appositi team di sviluppo specializzati, che seguano tutto il processo di implementazione. Un team deve essere composto da persone complementari e interscambiabili ognuno con specifici compiti. Il team deve innanzitutto avere ben chiara sia la situazione “as‐is” che quella “to‐be” in modo da focalizzare le proprie sinergie sui punti critici; inoltre l’input per il team è costituito essenzialmente dai requisiti ottenuti dall’analisi dei processi di business opportunamente modellati e mappati.
Figura 14 ‐ Configurazione di un team di implementazione Microsoft Navision
Poi per ogni team devono esserci specifiche figure: in particolare è consigliabile avere un Modeler Consultant che si occupi della documentazione per le variazioni dei processi aziendali dovute all’implementazione del nuovo ERP, un Key User che sia da supporto per la formazione e il training all’interno dell’azienda e un Business Consultant che si occupi dell’installazione effettiva on‐site di Navision all’interno dell’azienda e del training per quanto riguarda i punti essenziali.
4.3.2. Principi di Inventory Costing
Quando si vanno a conteggiare gli introiti, il ruolo delle registrazioni di magazzino è quello di assegnare le voci di costo ai vari periodi contabili come spese. Il costo totale dei beni disponibile per vendite o utilizzazioni nell’arco di un periodo contabile deve essere allocato tra l’utilizzo del periodo corrente (costo del venduto) e l’ammontare portato avanti ai periodi successivi (fine periodo).
La seguente equazione rappresenta il modo in cui scaturisce la situazione inventariale al termine di un periodo:
I costi inclusi nel conto economico e nello stato patrimoniale sono di solito classificabili in 2 categorie:
• Costi capitalizzati: questi costi in primo luogo sono registrati come beni quando sono affrontati e si presume forniscano benefici futuri all'azienda. Quando sono effettivamente usati essi sono registrati come spese.
• Costi non capitalizzati: sono registrati come spese del periodo contabile in cui sono stati affrontati.
Inoltre i costi capitalizzati possono essere divisi in inventariabili e non inventariabili.
Secondo il glossario tecnico, la valutazione di magazzino è la determinazione del costo assegnato ad un articolo presente nel magazzino. A seconda delle procedure interne di registrazione e quelle generali del settore, le aziende scelgono di valorizzare il loro magazzino a seconda di una o più dei seguenti criteri di valutazione:
• Costo di acquisto: le singole unità di magazzino sono riportate sempre al loro costo storico di acquisto finquando esse non sono vendute, dunque le entrate sono modificate solo dalle transazioni di vendita. Qualsiasi cambiamento della valorizzazione di magazzino di un oggetto che avviene tra l’acquisto e la vendita non è considerato. • Costo standard: prevede una stima di quanto dovrebbe costare l’articolo di magazzino,
basata su cifre riguardanti i periodi precedenti. Le aziende di manufacturing utilizzano spesso questo criterio • Valore netto realizzabile: è l’ammontare che un’azienda potrebbe realizzare come una transazione tra un compratore disposto e un venditore disposto nel corso ordinario del business. • Costo di rimpiazzamento: è l’ammontare che una azienda desidererebbe ottenere per rimpiazzare i costi di acquisto di quel determinato bene.
Ma cos’è effettivamente il costo? Spesso viene definito come una “risorsa sacrificata o rinunciata per il conseguimento di uno specifico obiettivo”. In termini più convenzionali, i costi sono ciò che è necessario pagare per l’acquisizione di beni e servizi.
Le aziende in genere operano riferendosi al termine cost object, che è un qualsiasi oggetto per cui è richiesta una misura separata di costo, ad esempio in prodotto, un servizio, un dipartimento, un progetto etc. Per determinare il costo di un particolare object, e quindi per guidare eventuali decisioni esso riguardanti, le aziende devono assegnare i costi ai rispettivi object: generalmente i costi per ogni singolo object hanno doppia natura:
• Costi effettivi dell’oggetto (costi diretti) • Costi allocabili all’oggetto (costi indiretti)
In poche parole possiamo esprimere il costo totale di acquisto di un oggetto come
Costo totale di acquisto = Costo d’acquisto – Ev. sconti + Costi Addizionali + Costi Indiretti
Il principale problema della gestione di magazzino deriva dalle fluttuazioni lungo un arco temporale del costo d’acquisizione unitario. Tipicamente in un magazzino i prodotti appena arrivati si mischiano coi vecchi sugli scomparti e l’identificazione fisica diviene difficoltosa. A livello contabile il problema principale della gestione logistica viene sollevato perché come si può vedere nell’equazione di magazzino ci sono dei termini non noti:
Magazzino iniziale + Acquisti netti – Costo del Venduto = Magazzino finale
I valori di magazzino iniziale e acquisti netti sono conosciuti, mentre costo del venduto e ovviamente magazzino finale non sono noti. Dunque il problema si sposta sul valutare le unità di magazzino al termine del loro ciclo di vita oppure determinare il costo del venduto utilizzando una delle metodologie possibili tra costo più recente, costo più vecchio, costo medio e altri. Se per uno stesso articolo sono stati fatti ordini d’acquisto con differenti prezzi e non è possibile o disponibile un’identificazione specifica per quell’articolo, deve essere fatta qualche scelta preliminare sul flusso di costo, allo scopo di stimare i costi di acquisto applicabili alle unità rimanenti in magazzino. Ci sono 3 possibili scelte sul flusso di costo tipicamente utilizzate in questo àmbito:
Figura 15 ‐ Politica di costing FIFO in un magazzino • LIFO (Last‐in, first‐out): materiali e beni più vecchi vengono utilizzati per ultimo Figura 16 ‐ Politica di costing LIFO in un magazzino
• Media pesata: il costo del venduto assume il valore della media pesata di tutti gli acquisti di quel prodotto presenti in magazzino in un dato periodo
Figura 17 ‐ Politica di costing a media pesata in un magazzino
4.3.3. Inventory Posting e costo del venduto
In Navision le transazioni di magazzino (inventory posting) si concretizzano in 2 tipi di registrazioni: quantità (quantity posting) e valore (value posting). Il Quantity Posting descrive la variazione di quantità nel magazzino e il programma salva questa informazione nella tabella delle Item Ledger Entries. Il Value Posting invece indica la variazione di valore nel magazzino e tale informazione viene immagazzinata nella tabella delle Value Entries.
Come si può vedere dalla figura, le Item Ledger entries sono “applicate” l’una in corrispondenza dell’altra, cioè un incremento di magazzino è collegato ad un decremento, in modo da poter dire esattamente quale incremento è stato usato per quale decremento e viceversa. Ciò è possibile perché il programma salva queste informazioni nella tabella delle Item Application Entries. Inoltre alla fine del periodo contabile, l’utente può “riconciliare” queste transazioni di magazzino dirette, che non necessitano rettifiche di costo, con la contabilità generale facendo girare la procedura batch Post Inventory Cost to G/L. Tale procedura aggiorna le voci delle Value Entries e crea delle righe nella tabella G/L Entries relative ai movimenti contabili.
Pertanto per ogni riga generata da una variazione di quantità nel magazzino, Navision crea una Item Ledger Entry e una o più Value Entry e successivamente, al termine del periodo contabile, riconcilia i valori di magazzino con i valori contabili nel registro generale, come si evince dalla seguente figura.
Dunque il costo viene linkato dinamicamente al prodotto e associabile/modificabile finquando la riga relativa al movimento d’acquisto nella tabella Item Ledger Entry risulta aperta; un apposito flag infatti ci indica lo status di quel movimento e quindi anche di tutte le righe di altre tabelle associate ad esso. Facciamo un esempio. Al 1 Marzo acquisto 10 unità di un articolo, pertanto avrò una riga nella Item Ledger Entry per la registrazione della quantità acquistata, e una riga nella Value Entry per registrare il costo diretto. Dopo 30 giorni, e cioè ad Aprile, ricevo una fattura dal fornitore relativa all’addebito delle spese di spedizione per la merce acquistata. In tal caso Navision registrerà un’ulteriore riga nelle Value Entry relativa ai costi di trasporto, correlata però a quella determinata registrazione nell’Item Ledger Entry. Dopo altri 15 giorni ricevo una fattura relativi a costi aggiuntivi dovuti allo sdoganamento della merce, e anche in questo caso Navision aggiungerà una riga nelle Value Entry relativa sempre a quella riga della Item Ledger Entry. Alla fine per quell’ordine di acquisto avrò una riga nella Item Ledger Entry e 3 righe nella Value Entry. L’aggregazione di tali informazioni che di fatto sono spalmate su diverse tabelle ma in effetti sono relative ad una singola transazione d’acquisto avviene tramite la tecnologia SIFT (Sum Index Flow Technology), che consente di effettuare calcoli attraverso tabelle e datasources differenti senza particolari perdite in termini di prestazioni, efficienza ed affidabilità.
Esaminiamo ora come variano i costi durante il ciclo di vita degli articoli di magazzino, in particolare vediamo come Navision calcola il costo del venduto; facciamo un esempio pratico usando direttamente il programma.
Partiamo con la creazione di un nuovo articolo che ci servirà per provare il warehouse cost flow: lo chiamiamo ITEM e gli impostiamo il metodo del calcolo del costo a Medio, che corrisponde al Costo Medio Continuo, da non confondere con quello Medio Statico, che non tiene conto delle reali uscite di magazzino, bensì solo delle entrate.
Figura 20 ‐ Creazione dell'articolo di prova ITEM
Effettuiamo dunque un ordine di acquisto di 10 pezzi di tale articolo al prezzo di 10 euro al pezzo e carichiamo su tale ordine le spese relative al trasporto di tale merce.
Figura 21 ‐ Primo ordine di acquisto per l'articolo ITEM
Dopo il ricevimento della merce e la registrazione della relativa fattura Navision evidenzierà nel dettaglio dell’articolo la variazione di costo, come si può vedere dalla figura.
Figura 22 ‐ Costo medio dell'articolo ITEM dopo il primo acquisto
In tale schermata si può notare che l’ultimo costo diretto unitario attribuito all’articolo è ovviamente 10 Euro, mentre il costo medio è di 10,20 Euro perché vengono considerati anche i costi di trasporto. Facendo drill‐down sul costo medio per esaminare gli elementi che hanno generato quel costo otteniamo la seguente schermata.
Figura 23 ‐ Drill‐down sul Costo Medio dopo il primo acquisto
Qui si possono meglio vedere i costi parziali che hanno determinato il costo medio unitario totale e i movimenti a cui essi sono collegati.
Ora effettuiamo un altro acquisto dello stesso articolo, ma lo facciamo ad un prezzo differente: acquistiamo 10 pezzi a 12 Euro l’uno, con le solite spese di trasporto di 2 Euro. In seguito a questo acquisto il Costo Medio è mutato salendo ovviamente a 11,20 Euro.
Figura 24 ‐ Costo Medio dopo il secondo acquisto
Dopo aver acquistato, vendiamo 18 pezzi dell’articolo ITEM al prezzo di 15 Euro cad. Ecco l’ordine di vendita:
Figura 25 ‐ Ordine di vendita per l'articolo ITEM
Le due seguenti schermate mostrano rispettivamente la valutazione del costo medio di quell’articolo e la situazione di magazzino, sempre relativa all’articolo ITEM. Qui si può notare che per la logica FIFO, i 2 elementi rimanenti nel magazzino sono quelli relativi al secondo acquisto e il flag relativo a tale ordine di acquisto risulta dunque ancora aperto.
Figura 26 ‐ Costo Medio prima dell'Adjust Cost Item Entry
Dopo tale vendita è possibile notare, nel dettaglio dell’articolo, che è variato il Costo Medio. Ora in magazzino ci sono solo 2 pezzi di quell’articolo e il costo medio è salito a 22,00 Euro.
Perché? Navision ragiona in modo differente rispetto alla maggior parte delle aziende: quel costo così elevato infatti è dovuto al fatto che il movimento di vendita non è ancora stato collegato all’acquisto della relativa merce. Abbiamo visto in precedenza che in Navision un decremento di magazzino viene associato ad un incremento di quella merce di magazzino, in modo da mappare il movimento con la relativa merce. Ma quando viene effettuata questa importantissima associazione?
C’è una procedura, attivabile manualmente dall’operatore, che si chiama Adjust Cost Item Entry che ha proprio la funzione di effettuare tale associazione e di conseguenza aggiornare i costi, provvedendo a ricalcolare il costo del venduto ed eventualmente attribuire costi o crediti a livello contabile per la determinazione di tale costo.
Tornando al nostro esempio, se esaminiamo il dettaglio del costo medio dopo la vendita, possiamo notare la seguente situazione:
Figura 28 ‐ Drill‐down sul Costo Medio prima dell'Adjust Cost Item Entry
Nella fig precedente si nota che il costo del venduto è valutato a 10 Euro/pz che è il costo del primo acquisto. Per fare in modo che il costo del venduto, e di conseguenze il costo medio continuo dell’articolo, sia corretto in funzione della situazione reale contabile di magazzino è obbligatorio eseguire la Adjust Cost Item Entry per arrivare alla situazione seguente:
Figura 29 ‐ Drill‐down sul Costo Medio prima dell'Adjust Cost Item Entry
Qui si nota che al costo del venduto (che è negativo come convenzione perché decrementa il magazzino) viene incrementato di 21,60 in modo tale da aggiungere quella porzione di costi
diretti derivanti dalla quella quantità venduta ma prelevata a magazzino dal secondo quantitativo acquistato.
4.4. Vantaggi e cambiamenti
L’introduzione di Microsoft Navision ha sicuramente portato notevoli cambiamenti. In genere quando si installa un qualsiasi ERP in un’azienda, essa ne risulta sconvolta, perché non è l’ERP che si adatta all’azienda, ma l’azienda che prende forma implementando i propri processi come il sistema ERP le impone di fare.
Univergomma è passata da AS/400 a Navision, modificando radicalmente sia il proprio asset funzionale che quello organizzativo. E’ cambiato il modo di lavorare, è stato modificato il ruolo operativo di alcuni dipendenti, è stata concepita una nuova filosofia di gestione dell’azienda, basata su pianificazione degli acquisti mirata e precisione nella gestione del magazzino. I cambiamenti più radicali sono stati i seguenti: a. RIDUZIONE STOCK: • Prima: venivano lanciate campagne promozionali per ridurre stock di magazzino. Tali campagne erano basate sulle stagionalità (ad es. a luglio partiva la campagna promozionale per ridurre gli stock di pneumatici da neve) e si configuravano come indispensabili per la creazione di spazi logistici e l’eliminazione di giacenze di magazzino; talvolta tali campagne, seppur dispendiose, risultavano inefficaci, non conseguendo i risultati attesi.
• Dopo: la pianificazione degli acquisti effettuata con Navision e il modulo WMS consentono di ottenere stock già ridotti in partenza e dimensionati sulle reali capacità di vendita, in modo da rendere superfluo il lancio di una campagna promozionale che prima sembrava necessario. Ciò comporta, oltre all’effettivo vantaggio della riduzione degli stock desiderato, un abbattimento dei costi relativi al lancio e alla gestione delle campagne stesse.
b. CALL CENTER:
• Prima: il lavoro del call center era sovraccaricato dal fatto che, nella volontà di alleggerire il lavoro dei magazzini, già gravati da problematiche connesse alla logistica, si prendeva carico di compiti non naturalmente destinati ad un call center. Infatti gli addetti al call center, oltre che di prendere gli ordini e girarli agli altri reparti, si occupava anche di stampare i DDT per ogni singolo ordine e consegnarli ai responsabili di magazzino, e di gestire il trasporto della merce. • Dopo: la gestione spedizione è stata tolta dalle competenze del call‐canter ed è
stato creato un ufficio logistica che gestisce le spedizioni. Inoltre è stato cambiato il modo di concepire le spedizioni, che ora sono gestite in base al trasportatore: ad es. se alle ore 10 parte un TIR, vengono elaborati i documenti di trasporto di tutti i clienti serviti da quel trasportatore. L’alleggerimento del call center ha comportato il trasferimento di un dipendente dal call center al reparto Logistica.
Lo schema di seguito mostra il cambiamento nelle funzionalità di questi reparti derivante dall’installazione di Navision. Figura 30 ‐ Schema variazioni funzionali Call center e Logistica c. OUTSOURCING SPEDIZIONI: • Prima: il trasporto veniva gestito direttamente da Univergomma con un proprio parco automezzi, la cui gestione e manutenzione contribuivano sensibilmente alla crescita dei costi del servizio offerto. Tutto ciò non comportava nemmeno un incremento in termini di prestazioni poiché i problemi che contribuivano negativamente a time‐to‐customer alti erano a monte del processo di trasporto, per cui erano costi alti inutili per conseguire gli obiettivi fissati dalle politiche aziendali
• Dopo: la decisione di affidarsi a ditte esterne per il trasporto, quindi fare outsourcing servendosi di ditte specializzate del settore, quali DHL, Bartolini, TNT, ha contribuito notevolmente ad abbattere i costi di gestione dovuto al parco automezzi, ottenendo qualità del servizio uguale se non superiore a prima.
5. Business Intelligence
5.1. Cos’è la BI
Da anni gli strumenti di Business Intelligence sono diffusi nelle grandi aziende e costituiscono un indispensabile supporto alle decisioni, da quelle più strategiche a quelle più operative e quotidiane. Il valore aggiunto della Business Intelligence è dato dalla possibilità di prendere decisioni più efficaci e più rapide in base all’analisi dei dati necessari, integrati ed affidabili, provenienti dai diversi sistemi dove sono presenti, all’interno e all’esterno dell’azienda. Decisioni che vengono prese nella fase di pianificazione ma anche nella fase di controllo, della efficacia delle azioni pianificate, e che costituiscono il momento più importante nell’attività di gestione di un’azienda. Figura 31 ‐ Architettura di un sistema di Business Intelligence In passato, alcuni fattori hanno rallentato la diffusione della Business Intelligence (BI) nelle piccole e medie industrie (PMI): • L’elevato costo del software • La necessità di un presidio da parte di tecnici per la manutenzione dell’attività di raccolta e integrazione dei dati Oggi questi ostacoli appaiono superabili in virtù delle tendenze che si stanno imponendo nel mondo dell’informatica in generale e in quello della BI in particolare:
• La maturità del mercato del software per la BI spinge gli attori affermati ad una maggiore concorrenza sul prezzo (dopo che le funzionalità si sono allineate tra i diversi strumenti) e la necessità di esplorare nuovi mercati dopo che quello delle grandi aziende è ormai saturo. • La diffusione del fenomeno del software open source
• La trasformazione dell’informatica da industria di prodotti a industria di servizi (aspetto questo che caratterizza molto il software open source). Questa trasformazione ha portato alla diffusione di outsourcing e ASP che riducono o azzerano per le aziende la necessità di avere tecnici per la manutenzione dei sistemi informatici oltreché la necessità di immobilizzare capitali in hardware, software e infrastrutture correlate.
Decisioni e processi aziendali
Prima di apportare miglioramenti alle decisioni aziendali con investimenti in sistemi informativi, occorre comprendere meglio quale sia la natura delle decisioni e dei processi decisionali. I diversi livelli di responsabilità di un’azienda hanno esigenze diverse in termini di informazioni, che influiscono sui tipi di decisioni prese a ciascun livello, di supporto alle decisioni e gruppi differenti da servire con i sistemi informativi.
Possiamo individuare quattro gruppi decisionali di un’azienda:
• Senior manager: si preoccupano di avere informazioni generali ma tempestive sui cambiamenti dell’industria e della società
• Middle manager: si preoccupano di avere informazioni specifiche e puntuali sulle prestazioni dell’azienda, compresi gli obiettivi di fatturato e riduzione dei costi
• Manager operativi: si occupano del monitoraggio delle prestazioni di ciascuna unità secondaria dell’impresa
• Singoli dipendenti: cercano di soddisfare gli obiettivi dei manager sopra di loro, seguendo le regole e le procedure stabilite. Spesso si tende a responsabilizzare questo livello conferendo più fluidità ai processi decisionali e quindi a tutti i processi in genere
Le caratteristiche delle decisioni affrontate dai manager ai vari livelli sono piuttosto diverse. Le decisioni possono essere classificate come strutturate, semistrutturate e non strutturate.
Le decisioni non strutturate sono quelle in cui colui che prende le decisioni deve fornire giudizi, valutazioni e considerazioni sulla definizione del problema.
Le decisioni strutturate sono ripetitive e di routine, quindi i responsabili delle decisioni possono seguire una procedura ben determinata per trattarle.
Molte decisioni hanno elementi che appartengono ad entrambi i gruppi e sono quindi considerate
semistrutturate
