Categoria: Informatica aziendale

In quest’articolo raccoglierò alcuni consigli utili alle aziende e relativi reparti IT che si approcciano per la prima volta all’implementazione del gestionale SAP: sono semplici linee guida raccolte durante un’esperienza ventennale in questo campo che possono essere utili per restare nei costi, nei tempi ed avere un’installazione di successo.

Partiamo dal concetto che SAP è il software gestionale aziendale integrato per eccellenza, la Ferrari dei gestionali, come tale offre una moltitudine di moduli che coprono la maggior parte dei processi aziendali sia verticali che orizzontali, il software è pensato per essere configurato per qualsiasi esigenza secondo le buone pratiche di business.

La prima scelta da fare è il tipo di software SAP che andremo ad usare, dovremo capire in base alle dimensioni dell’azienda e al numero di utenti totali se orientarci su un prodotto come SAP Business One o SAP S/4.

Il primo è consigliato per aziende sino a 100 utenti, naturalmente non offre tutte le funzionalità di S/4 ma copre le necessità principali di una piccola media impresa, è estremamente configurabile e il costo degli sviluppi o dei pacchetti aggiuntivi è più contenuto.

Il secondo è il discendente della famosa suite SAP ERP, una suite enterprise che ha una vastità di pacchetti per ogni tipo di settore e processo: l’uso è rivolto alle medie e grandi aziende fino alle multinazionali. Si tratta di un software impegnativo che per la sua complessità prevede dei costi più alti sia di sviluppo che di gestione.

S/4 può essere installato inizialmente nei pacchetti core e poi espanso a seconda delle necessità, al contempo Sap Business One comprende già nella sua installazione base la maggior parte delle funzionalità di una piccola o media impresa: queste sono valutazioni che dovrete fare in base alla vostra strategia aziendale ed al budget che prevedete facendovi mostrare una demo dei due prodotti ipotizzando una configurazione vicina ai vostri processi core.

Una volta scelto il tipo di prodotto SAP dovrete effettuare una mappatura dettagliata dei vostri processi aziendali, partendo dall’end-to-end del business sino ad arrivare alle singole operazioni nelle varie aree: si partirà quindi con le configurazioni sino per arrivare il più vicino possibile al vostro desiderato, a questo punto potrete identificare i gap, cioè le parti che non sono coperte dalla soluzione per capire come implementarle.

Vi consiglio di coprire sempre i processi nevralgici della vostra attività – il cosiddetto core business – adattando accuratamente la configurazione, la forza di SAP è nella stabilità del suo codice e nelle “best practices” di processo e di settore che questo incorpora, analizzate le infinite possibilità di configurazione prima di cambiare un processo e mettere mano al codice: fatevi mostrare i benefici e cercate di capirne il funzionamento, pensate sempre che se le “best practices” seguono una certa logica e se nel codice il processo informatico è gestito in un certo modo, probabilmente quello è il modo migliore di gestirlo a parte casi eccezionali.

Il cambiamento non è mai semplice da affrontare, specie in progetti dove si è passati a SAP da gestionali precedenti: gli utenti preferiscono il loro modo di lavorare consolidato negli anni, sono generalmente avversi a cambiamenti nelle modalità operative perché risultano ostiche finché non se ne è capito bene il funzionamento. Cercate di fare entrare gli utenti fino in fondo alle logiche applicative, agli oggetti ed ai processi cosi che per loro sia chiaro sia il flusso funzionale e l’integrazione fra le varie parti: cercate di fare capire l’ingegneria gestionale che sta dietro alle logiche cosi che queste vengano comprese e abbracciate dagli utenti, alla fine loro sono la parte più importante del processo informatico aziendale!

La migliore strategia con SAP dal lato prettamente tecnologico IT è il giusto bilanciamento fra sviluppo e configurazione con quest’ultima preponderante: l’imperativo dovrebbe essere “adottare” la soluzione e le “best practices” di settore perché questo vi permetterà di mantenere quanto più possibile la soluzione vicino allo standard, lavorare dettagliatamente con la configurazione vi permetterà di avere dei costi bassi sia nell’implementazione che nel passaggio alle nuove release, vi garantirà un ottimo funzionamento su milioni di righe di codice testati da anni, insomma vi permetterà di concentrarvi dal lato IT sul vostro business e non sull’analisi, sviluppo ed ottimizzazione di codice custom.

Sviluppate solamente la piccola percentuale di processi e funzioni che non sono coperte dalla soluzione, ricordatevi che un reparto IT non è una software house quindi valutate se già esistono Add-On gia pronti che soddisfano i vostri requisiti, cercate di usare le Business API standard e di integrare gli sviluppi nella logica applicativa con il resto dei processi.

Passare a SAP significa abbracciare questa filosofia, ogni nuova release ingloberà sia miglioramenti tecnologici che di ingegneria gestionale e ve li ritroverete nel vostro business senza che dobbiate voi implementarli.

Buon SAP a tutti 😉

In questo articolo parleremo della soluzione SAP per la gestione del magazzino Extended Warehouse Management integrata in S/4Hana, chiamata normalmente eWM embedded perchè parte dell’installazione, vedremo cosa offre nei suoi processi principali.

Rispetto alla soluzioni storica gia comprese nell’ERP, la soluzione eWM permette un livello di dettaglio, controllabilità, tracciabilità e soprattutto automatizzazione dei processi non disponibile nelle altre soluzioni, si tratta dell’ultima generazione della gestione magazzino SAP che copre le esigenze di qualsiasi moderno centro di distribuzione logistico.

EWM è nato come una soluzione stand-alone decentrata ma la versione embedded non necessita del trasferimento di dati anagrafici tramite Core Interface (CIF) perché comunque si appoggia sulle tabelle anagrafiche centrali dell’ERP – MARA, MARC e MARD – ed il loro uso è esteso direttamente all’anagrafica del prodotto magazzino, cioè alla tabelle specifiche di eWM ( il materiale si chiama prodotto).

Le transazioni come le tabelle sono le /SCWM/XXXX del sistema eWM stand-alone, si possono utilizzare le app Fiori, l’interfaccia Webgui su tablet e portatili o SAPGUI sui pc windows, la RF UI sui terminali RF con le funzioni specifiche del Radio Frequency Framework per lo scarico lo e stoccaggio tramite scanner e codici a barre (EAN 128). Tramite le interfacce web si possono effettuare tutte le operazioni di magazzino.

In Embedded eWM si è cercato di mantenere lo scambio dei dati piu snello rispetto al sistemi stand-alone, non viene più generata una notifica di consegna e la sua replica avviene automaticamente tramite l’interfaccia qRFC (chiamata di funzione remota coda), queste si possono monitorare con le specifice transazioni SMQ1-2: ogni scambio con ERP è governato da un documento in ingresso, uscita o regola di modifica.

Il processo di entrata merci inizia con la consegna in inbound, la fornitura: possiamo mantenere la fornitura dal Monitor Magazzino (/SCWM/MON) contrassegnando la riga del documento e selezionando in sequenza i pulsanti [Scarica + Salva], [Entrata merci + Salva], [Crea attività di magazzino] e [Conferma attività di magazzino]. Le merci a questo punto sono ora nell’area di ricevimento, se è pianificata la qualità, verrà creato automaticamente un lotto di ispezione in background e sarà possibile utilizzare la transazione QA32 (se QIE è integrato con l’ispezione esterna) per inserire i risultati dell’ispezione e prendere una decisione sull’utilizzo. Ciò modifica il tipo di stock, da qualità a stock libero o bloccato.

Dopo aver inserito il tipo di processo di magazzino che si vuole eseguire si procede alla successiva collocazione e stoccaggio: sempre dal Warehouse Monitor possiamo fare clic sul pulsante [Crea + Salva] selezionando le righe del materiale e le merci verranno inserite secondo e logiche configurate in ordini di magazzino e relative task per le attività di stoccaggio finale. L’archiviazione fisica dovrà essere confermata nei vari passaggi, anche dal Monitor confermando le selezioni dei singoli ordini in attività di magazzino.

Per il processo di uscita merci, la consegna puo essere creata a partire da un ordine di vendita, (è possibile comunque creare consegne senza riferimento d’ordine) con le consuete transazioni VL*: una volta distribuita la consegna questa può essere gestita in eWM.

Possiamo guidare il processo di consegna in uscita eWM sempre attraverso Warehouse Monitor, da qui possono essere creati gli ordini di magazzino e le attività di magazzino. Ciò include il prelievo e l’imballaggio negli appositi centri di lavoro : da qui poi gli operatori potranno creare le unità di gestione, le HU, che saranno caricate nelle unità di trasporto (camion, rimorchi, ecc.) e procede nell’uscita merci.

Nei processi interni infatti è possibile mappare varie fasi del processo utilizzando i centri lavoro: lo scarico, il controllo qualità, il conteggio e il deconsolidamento, il kitting, i servizi logistici a valore aggiunto, il packing, packing e attività di uscita merce.

Il reso fornitore deve seguire l’esito del controllo qualità negativo o trasferimento stock di reso tramite ordine di reso. Il reso del cliente può passare dal controllo qualità alla rilavorazione. I resi sono attività quotidiane comuni nella vendita al dettaglio motivo per cui i processo resi è di solito compreso fra i processi principali. L’inizio del reso cliente è un ordine di reso, che deve essere completato con il credito.

L’inventario deve essere effettuato almeno una volta all’anno al fine di compensare le deviazioni fra stock fisico rispetto allo stock di sistema, si deve effettuare ogni volta che si riscontra un disallineamento visto che porta a notevoli sprechi di tempo. Si può distinguere tra l’inventario relativo all’ubicazione di stoccaggio (raccolta di tutti i prodotti o HU per il documento di inventario dell’ubicazione di stoccaggio) e l’inventario relativo al prodotto (documento di inventario per un prodotto specifico che viene conteggiato tra differenti luoghi di stoccaggio).

L’esecuzione dell’inventario fisico inizia da “Crea inventario” per generare un documento di inventario, questo deve essere attivato per procedere al “Conteggio inventario” e la registrazione dei risultati del conteggio per poi procedere con “Analizza differenze”: se è necessario si registrano le differenze inventariali che creano differenza contabile di magazzino.

Il cockpit o Monitor Magazzino (/SCWM/MON) è una app potente che ci offre una panoramica di tutto il magazzino, ingressi, uscite, inventario, documenti posizioni di stoccaggio, risorse, prodotti, avvisi, disponibilità delle scorte: da qui possiamo avere l’indicazione di come funziona il magazzino, il grado di riempimento, le attività di magazzino aperte, ecc.

Nel “layout grafico del magazzino” possiamo rappresentare il magazzino compreso l’inventario, le posizioni di stoccaggio, le risorse, ecc. come grafico bidimensionale. Questo è molto utile se si è configurato il magazzino tramite la configurazione di layout del magazzino: questo tipo di configurazione permette infatti di ottimizzare le operazioni basandoci sul layout fisico delle ubicazioni e delle attività.

Possiamo comunque configurare il magazzino per processo se ci interessa il flusso di attività sui materiali fra le varie aree di lavoro: questo permette di configurare scenari complessi come il deconsolidamento (identificazione e imballaggio merci all’ingresso), l’imballaggio delle merci in uscita, la gestione del packaging multi materiale, l’aggregazione di unità di magazzino e di unità di trasporto, gestione delle risorse puntuale degli operatori e delle singole task di attività di magazzino.

Come abbiamo visto in altri articoli, per fare della nostra fabbrica una fabbrica interconnessa che punti al paradigma di Industria 4.0 dobbiamo per prima cosa mettere a disposizione sulla nostra rete i dati dei processi.

Ma che fare quando non abbiamo i dati di processo e dobbiamo quindi inserire nuovi sensori? Pensate alla conta dei pezzi buoni piuttosto che altri controlli qualitativi….Oppure che fare quando vogliamo monitorare e gestire processi con l’aiuto di intelligenza artificiale nel cloud ma abbiamo bisogno dei dati di input? Pensate alla manutenzione predittiva o ai controlli prodotto tramite algoritmi specializzati piuttosto che alla logistica controllata da remoto…

Quando ci servono dati semplici potremo sfruttare il PLC gi? a bordo della linea o della macchina, magari gi? integrato sulla nostra rete e piattaforma di automazione, nulla di pi? facile ed economico… Ma che fare quando non abbiamo un PLC interconnesso che pu? catturare il dato ed abbiamo allo stesso tempo bisogno di funzionalit? leggermente pi? avanzate che difficilmente sono disponibili su PLC oppure logiche che comunque necessitano di linguaggi di alto livello per essere implementate?

Come sempre non c’? una risposta valida per tutto, bisogner? vedere di volta in volta in base ai nostri bisogni, ma dobbiamo tenere conto di un nuovo settore in forte espansione, il settore delle schede Arm e della sua regina incontrastata, Raspberry Pi.

Nata per rendere disponibile un mini computer economico a sviluppatori e makers con lo scopo di diffondere la programmazione in tutte le fasce d’et? ( Pi sta per Python), da qualche anno sono esplose anche nel settore IOT industriale, prima usate solamente come punto di accesso ai dati e come gateway verso i server, ora si sono evolute in veri e propri computer industriali con moltissimi add-on di svariati produttori (provate a cercare con google per vederne la vastit?).

Naturalmente vanno fatte importanti considerazioni, non potete confrontare un PLC studiato per applicazioni industriali con una scheda Arm come Raspberry Pi:

• in primis per una questione di costi le single board computer non possono avere l’affidabilit? di un PLC, la loro qualit? costruttiva ? ben lontana da un PLC delle marche piu blasonate.
• i tempi di esecuzione di un PLC sono quasi irraggiungibili da parte di una SBC anche se esistono diversi kernel real-time per questo, ma senza mai avere l’affidabilit? di esecuzione di un PLC.
• soprattutto dovrete valutarne bene la resistenza in ambito industriale, le sbc Arm non sono resistenti alle condizioni di lavoro industriali come lo sono i PLC.
• altro fattore importantissimo ? la rapidit? di evoluzione di queste piattaforme e quindi la loro rapida obsolescenza, importante per la reperibilit? dei ricambi
• la mancanza di un adeguato supporto sia dal lato hardware che software potrebbe essere un problema nella fase di sviluppo e poi in manutenzione.

Non possiamo usare quindi le SBC Arm alla stregua di un PLC per controllo processo avanzato o applicazioni critiche ma possono essere di molto aiuto in ambito IOT:

• per sopperire alla mancanza di sensori sui nostri processi offrendo tipologie di sensori praticamente infinite,
• offrendo capacit? audio e video, sicuramente come encoder e gateway verso i server ma anche come unit? di processing seppur limitato (openCV, openCL, Tesseract,ecc..)
• offrendo un solido aiuto dove abbiamo bisogno di integrazione con protocolli ed input/output di ogni tipo
• offrendo un tipo di programmazione open source alla portata di tutti, con capacit? logiche avanzate e con curve di apprendimento e resa sul campo rapide,
• essendo economiche possono essere una ottima scelta per la prototipizzazione o fornire una buona soluzione se possiamo usarle in ambienti controllati e in scenari non critici

Le schede Arm vengono quindi in aiuto in casi specifici al di fuori delle semplici automazioni di processo e tutte le caratteristiche sopra le rendono una miscela vincente in molti casi, siete pronti a dare libero sfogo alla vostra creativit??

Io per ora posso solo dirvi che le ho trovate utili in diversi applicazioni industriali, la meglio riuscita ? forse una soluzione basata su Raspberry Pi per il controllo di prodotti ma anche una economica soluzione distribuita per il controllo presenze e accessi.. .Maggiori particolari delle implementazione nei prossimi articoli.

In questo articolo facciamo una panoramica dei middleware di integratione SAP negli scenari di fabbrica. Lavorando su sistemi SAP avrete sicuramente sentito parlare di SAP XI o Exchange Infrastructure, SAP PI o Process Integration e dell’ultimo nato, SAP MII o Manufaturing Integration and Intelligence. L’utilizzo di questi strumenti dipende dallo scenario e dall’obiettivo che che si vuole ottenere: da un livello molto elevato tutti sembrano supportare scenari di integrazione simili ma nella realtà sono progettati tenendo conto di casi d’uso specifici.  

SAP XI è la piattaforma tecnologica di information integration nello stack Netweaver server sin dalla versione 2, è alla base della Service Oriented Architecture dalla versione 7 e SAP PI si puo definire la sua evoluzione funzionale che comprende anche un motore Java dedicato oltre altri componenti.  

Quando parliamo di XI o PI stiamo parlando praticamente della stessa cosa, uno visto dal lato tecnologico e sempre presente come integration server nella piattaforma Netweaver mentre l’altro che incorpora componenti piu sofisticate (system landscape directory, integration repository e integration directory) si estende sul piano funzionale per organizzare al meglio l’integrazione dei sistemi SAP e non SAP nell’intero processo aziendale. SAP PI è un framework di comunicazione solido ed affidabile basato su elaborazione Java, protocollo HTTP/HTTPS e file XML, un sistema basato su standard aperti e linguaggio XML capace di raggiungere qualsiasi altro sistema nelle fabbriche tramite gli end point di comunicazione ( i cosiddetti adapter come XLink).

SAP PI ad esempio viene usato nelle grandi industrie che necessitano dell’integrazione di svariati sistemi specializzati o verticali rispetto al business estendendosi sino ai sistemi dei clienti e dei fornitori oltre che su diversi siti produttivi o logistici con i loro particolari sistemi eterogenei (la cosiddetta Process Orchestration).   Si tratta quindi di uno strumento di integrazione dedicato alla comunicazione che non supporta direttamente l’interazione utente e che quindi non può essere usato in fabbrica per integrare le persone con i processi o fare analisi e reportistica.

A questo scopo è stato creato SAP MII, per l’integrazione delle applicazioni di fabbrica in un ambiente decentralizzato sincrono/asincrono che oltre alla messaggistica comprende interfacce utente capaci di usare le funzioni dell’ERP decentrate e può integrarle ai dati presenti nella messaggistica in modo complementare ai dati provenienti dai sistemi locali.  SAP PI funzionerà dal lato ERP come istanza centrale della process integration mentre SAP MII come istanza distribuita nella fabbrica.

SAP MII può funzionare come client PI o come client ERP diretto , può scambiare i dati con i sistemi produttivi e con le interfacce utente bufferizzandoli in code dati locali per resistere a interruzioni della rete, outage dell’ERP o vincoli di larghezza di banda: lavorando in MII infatti non noterete mai rallentamenti o inefficienze per le transazioni di sua competenza.

SAP MII è quindi un prodotto mirato alle fabbriche e alle esigenze decentrate:

1. fornisce un’interfaccia comune per tutte le operazioni e interfacce agnostiche rispetto ai sistemi sottostanti,

2. può supportare scenari di sopravvivenza – business continuity – in cui è richiesta solo l’interazione con i sistemi di fabbrica e l’immissione dei dati locali.

SAP PI invece si concentra sulle esigenze dei dati globali e sull’integrazione di un più ampio spettro di sistemi nell’intero processo aziendale: SAP ERP può trasmettere messaggi a PI che a sua volta può fornire routing e messaggistica ad altri sistemi oltre che istanze MII remote, questo anche in modo asincrono utilizzando un endpoint HTTP in PI e  Messaging Services su MII.  

Quando usare SAP PI ?

Per tutta la messaggistica aziendale verso sistemi decentrati SAP e non SAP, come spina dorsale dell’architettura orientata ai servizi dell’azienda – SOA – con il beneficio di avere una configurazione centralizzata, completa tracciabilità, monitoraggio e manutenzione dei messaggi dai siti e oltre che avere un repository dei servizi aziendali e un flusso completo di molteplici standard aperti per l’orchestrazione dei processi, strumenti BPM, comunicazione asincrona.  

Quando usare SAP MII?

Quando abbiamo bisogno in un nostro sito di un ambiente di integrazione per sistemi eterogenei che quindi possa anche essere interattivo, che possa essere composto con i dati inseriti da interfacce utente e sia capace di dialogare con gli impianti cosi da sviluppare applicazioni composite per la produzione e la logistica capaci di interagire con l’ERP  in real time e in store & forward quando la connessione è inattiva. Si tratta di un sistema che offre connettività verso il basso ai sistemi di produzione e logistica e verso l’alto al gestionale aziendale, che ha strumenti di facile utilizzo per acquisire i dati dal campo e dai più popolari modelli di messaggistica aziendale, che è ricco di capacità analitiche con strumenti di aggregazione e trasformazione dei dati, il suo ambiente di composizione consente di costruire interfacce utente praticamente senza scrivere codice e capaci di dialogare verso i sistema di fabbrica in modo snello e graficamente uniforme. 

 

Extended Warehouse Management fà parte della strategia che SAP ha stabilito per l’esecuzione della supply chain, questo significa che SAP svilupperà ed espanderà le funzionalità WMS tramite EWM, il WM standard ECC sarà solo mantenuto, nessuna nuova funzionalità verrà implementata ma continuerà ancora per qualche tempo ad essere un’opzione valida per molti clienti.

SAP EWM offre numerosi vantaggi rispetto ECC WM, supporta più Industries, consente di incorporare nelle attività di magazzino strumenti di best practices del settore come ad es. weight management, cross docking, servizi a valore aggiunto, offre la capacità di gestire grandi volumi di transazioni con tempi più veloci, offre continui miglioramenti per tecnologie all’avanguardia che consentono al business di crescere più velocemente, come ad esempio eliminare i middleware per l’integrazione dei sistemi MFS, eliminare necessità di middleware per fare il voice picking,  sfruttare SAP HANA per innalzare la velocità di elaborazione delle transazioni nel gestire enormi volumi di dati aumentando la capacità di analisi predittiva.

Le funzionalità saranno solo uno dei fattori di decisione per implementare EWM, si può affermare infatti che i DC meno complessi non hanno bisogno di tutte le funzionalità offerte da EWM ma è necessario considerare altri fattori nella decisione come le esigenze della vostra attività nei prossimi anni. Ci sono fattori (acquisizioni di nuovi business o espansione con nuovi clienti) che potrebbero portare a cambiare il modo di lavorare in modo rapido ed efficace. Se avete bisogno di integrare nuova tecnologia nel vostro ambiente quanto dovrete spendere per cambiare? Quanto è il costo per espandere i requirement di oggi e sostenere i nuovi volumi di domani? Tutti questi fattori devono essere considerati da chiunque voglia cambiare o implementare EWM: una prima implementazione di base permette di avere comunque molteplici possibilità di espansione delle funzionalità.

Per chi gia conosce le soluzioni SAP WM, vediamo in poche parole le principali differenze di EWM nel contesto della nostra installazione:

• Si tratta di un sistema scalabile che può essere stand-alone o integrato, comunica tramite remote function calls (qRFCs) per i movimenti ed i documenti (deliveries, goods movements), usa core interface (CIF) per quanto riguarda i master data.
• Tutte le funzioni di ingresso e uscita sono condivise con l’ERP e sono gestite tramite documenti interni EWM triggerati su replica degli ordini dell’ERP ( auto creazione consegne configurabile), dalle inbound e outbound delivery vengono create le cosidette Warehouse Request, raggruppate in Wave e basate su Warehouse Task. Tutte le task vengono processate  a seconda delle regole e template impostati nel Warehouse Order Creation diventando Warehouse Order – possono contenere item di piu consegne.
•  L’interfaccia QM implementata permette l’attivazione di un inspection document in EWM, il QIE innesca la creazione di un lotto di controllo in QM ERP. Il processo di ispezione viene eseguito nel sistema ERP QM. ERP QM rinvia la decisione di utilizzo per la QIE dopo l’ispezione.
  
• L’interfaccia PP e la gestione dell’approvvigionamento di produzione funziona come in WM con PSA e CCR per la generazione delle consegne e relative task con aggregazione per PSA, il ricevimento della produzione viene gestito tramite “IDPD – Inbound Delivery from Production” ed è altamente configurabile, prevede la gestione delle nested HU e molte altre funzionalità.

Per chi volesse approfondire tecnicamente l’argomento EWM vi prego di consultare le relative guide nella sezione download.