Categorie
Informatica aziendale

Gestione dei rischi nelle implementazioni SAP

Se state pianificando o siete gia nel mezzo di una implementazione SAP ed avete già letto SAP consigli utili per l’implementazione, sappiate che ci sono una serie di rischi di cui tener conto e dalle molte implementazioni vissute vi posso dire quali siano quelli piu comuni.

Negli anni recenti guardando a S/4HANA rispetto quello che era ECC, dovete sapere che la business suite si può dire ancora in sviluppo in alcune aree e con prodotti non integrati nativamente ma provenienti da altre acquisizioni: gia solo questo dal lato tecnologico può rappresentare sfide in specifici ambiti dove sarai costretto a personalizzazioni per soddisfare le necessità reali del business e mettere mano profondamente alle integrazioni, dovrai avere una grande preparazione e una buona strategia su come affrontare questi punti perchè non rapresentino un rischio.


Un rischio poco visibile nelle metodologie di implementazione di SAP, è quello di tenere sempre conto che le soluzioni SAP sono così integrate e complesse che è fondamentale dedicare del tempo per rivedere in dettaglio i processi end-to-end e magari affrontare più di un ciclo nello studio e test della soluzione pilota, nella fase dell’integrazione dell’architettura e nella migrazione dei dati: questi sono esempi di aree che nel tempo ho trovato deboli e su cui devi fare molta attenzione se vuoi avere successo, dovrai rafforzarle al di fuori delle classiche metodologie di implementazione se vuoi che non rappresentino un rischio.


L’entità e il volume del cambiamento in una implementazione di SAP sono molto grandi quindi è importante riconoscere che uno dei rischi maggiori non riguarda solo la tecnologia ma il fatto che l’organizzazione sarà influenzata in modo enorme, devi sapere che è molto importante riconoscerlo e come tale pianificarlo mettendo insieme una strategia e una tabella di marcia condivisa, un piano di gestione del cambiamento organizzativo molto solido, efficace e soprattutto completo. Si deve fare molto di più che formazione e comunicazione, devi entrare profondamente nella cultura aziendale e organizzativa per fare acquisire l’ampiezza del cambio, devi assicurarti della comprensione delle “best practices” che a volte portano a cambi nel processo cosi come è sempre stato, devi fare in modo che il flusso di lavoro sia compreso nei sui benefici.
La mancanza di mitigazione del rischio nei progetti SAP è nota per portare a impiegare troppo tempo, troppi soldi e il motivo è che manca una mitigazione del rischio efficace, agnostica e oggettiva rispetto la situazione attuale dell’azienda, quindi devi anticipare in modo proattivo i rischi potenziali e iniziare a mitigare questi rischi prima che diventino un problema.

Un rischio con le implementazioni SAP puo essere anche dal lato del partner di progetto, le aziende di consulenza hanno spesso una dimensione maggiore della nostra azienda, sono partner di SAP che necessariamente proteggono per il proprio interesse quindi a volte non ti fanno notare tutti i rischi dall’inizio del lavoro per poi fare bella figura e rafforzare il fatto che hai preso la decisione giusta assumendoli. Devi tener conto che hanno bisogno di proteggere il loro flusso di entrate quindi il dimensionamento del team di progetto, il numero di consulenti e la durata dello stesso progetto ha importanza fondamentale, devi avere accordi chiari e trasparenti circa i carichi di lavoro e le fasi di stand-by (come nel momento di test della soluzione dove i tuoi team interni saranno piu interessati) .

Devi assicurarti che capiscano bene fino in fondo la tua attività e il tuo obiettivo, che abbiano una visione ed un piano realistici per massimizzare davvero il valore aziendale restando il piu possibile nel budget: ti posso assicurare che è facile andare fuori budget di molto non mitigando e non scegliendo bene la parte tecnologica, è bello avere soluzioni complete ed all’avanguardia ma dapprima bisogna sempre che ti spieghino bene e realisticamente a cosa puoi andare incontro, valutare costi benefici è essenziale perchè lo stack tecnologico a disposizione della suite SAP è enorme e fa presto a fagocitare importanti risorse per un addin in piu.

Concentrati sempre prima sull’end to end del tuo business e sul valore aziendale e vantaggi aziendali, molte volte il valore dell’implementazione è gia solo nell’avere un unico sistema nel caso di piu acquisizioni o business diversi e nell’implementazione dello standard SAP e delle sue “best pratices” di settore nel passaggio da sistemi legacy.

Quello che raccomando sempre è assumere internamente un project manager SAP con esperienza o una terza società di consulenza esperta nella gestione di tali progetti ( non dal lato tecnologico) che possa indirizzare tali rischi e fare da tramite nella valutazione dei costi/benefici guidando il progetto. Devi assicurarti di avere persone con esperienza in questa complessa trasformazione digitale che non siano affiliate al system integrator o al fornitore di software SAP: il motivo è che hai bisogno di qualcuno che sia obiettivo e distaccato dall’interesse di quest’ultimo, che ti dia un quadro oggettivo di garanzia della qualità e della mitigazione del rischio cosi da poter scoprire tali rischi durante tutta la trasformazione.

Categorie
Informatica aziendale

Controllo ATP vendite in ABAP

Per il controllo ATP su ordini di vendita esistono report e BAPI specifiche da utilizzare ma certe volte vi potrebbe capitare di dover eseguire un controllo all’interno di un flusso dell’ordine o addirittura eseguire il controllo in un altro processo particolare per aggiornare la disponibilità.

Le funzioni centrali del server ATP sono nel gruppo programmi SAPLATP, questo è il core del calcolo sui segmenti, quelli che eseguono la disponibilità sull’ordine di vendita sono all’interno del gruppo programmi SAPMV45 e nello specifico si tratta dei form FCODE_BVFP per ATP sull’intero documento e form FCODE_PORE per il singolo item.

Se siete all’interno dell’elaborazione dell’ordine di vendita ( VA01 o VA02) e quindi avete gia caricato in memoria le tabelle potrete semplicemente richiamare queste due funzioni tenendo sempre in grande considerazione il flusso del programma.

Per poter eseguire la disponibilità al di fuori dell’elaborazione dell’ordine di vendita dovete sapere alcune regole nella logica SD di SAP, come ad esempio il fatto che la disponibilità è sempre una condizione sottostante ad un controllo credito positivo del BP e che il credito impegnato totale standard è calcolato sulla merce che ha conferma di disponibilità.

Per questo per poter eseguire con successo l’ATP su un documento o un singolo item al di fuori dell’elaborazione ordine di vendita, dovreste prima caricare i dati del documento di vendita e poi fare sempre il controllo credito che predispone il server ATP, una volta fatto questo potete caricare i dati dell’item in memoria per poi eseguire il controllo su quest’ultimo.

Questo un esempio di esecuzione:

IF lv_vbeln NE '' AND lv_posnr NE '000000'
     CALL FUNCTION 'SD_SALES_DOCUMENT_READ'
        EXPORTING
          document_number = lv_vbeln
        IMPORTING
          evbak           = vbak
          evbakkom        = vbakkom
        EXCEPTIONS
          error_message   = 01.
      IF sy-subrc NE 0.
        CHECK 1 = 0.
      ENDIF.
      
      IF vbakkom-lifsk EQ '01'.
        CALL FUNCTION 'SD_SALES_DOCUMENT_PERFORM'
          EXPORTING
            in_program    = 'SAPFV45K'
            perform       = 'KREDITLIMIT_PRUEFEN_BEI_CALL'
          EXCEPTIONS
            error_message = 01.
        IF sy-subrc NE 0.
          CHECK 1 = 0.
        ENDIF.
      ENDIF.
    ENDON.

    CALL FUNCTION 'SD_SALES_ITEM_READ'
      EXPORTING
        item_number         = lv_posnr
      IMPORTING
        evbap               = vbap
        evbapkom            = vbapkom
      EXCEPTIONS
        error_message       = 01
        item_number_missing = 02.
    CALL FUNCTION 'SD_SALES_ITEM_TABLES_READ'
      EXPORTING
        item_number         = lv_posnr
      TABLES
        exvbep              = xvbep
      EXCEPTIONS
        error_message       = 01
        item_number_missing = 02.

    IF vbakkom-lifsk NE vbak-lifsk.
      da_save = charx.
    ENDIF.

    " ATP sulla posizione
    IF vbak-lifsk EQ ' '.
      CALL FUNCTION 'SD_SALES_DOCUMENT_PERFORM'
        EXPORTING
          in_program    = 'SAPMV45A'
          perform       = 'FCODE_PORE'
        EXCEPTIONS
          error_message = 01.
      IF sy-subrc NE 0.
        IF p_spool = abap_true.
          CLEAR ls_pos_log.
          MOVE-CORRESPONDING ls_pos_odv TO ls_pos_log.
          ls_pos_log-type = 'FCODE_PORE(SAPMV45A)'.
          ls_pos_log-id = sy-msgid .
          ls_pos_log-number = sy-msgno.
          MOVE 'Errore disponibilità ATP' TO ls_pos_log-message.
          APPEND ls_pos_log TO  p_t_pos_odv_log[].
        ENDIF.
        CHECK 1 = 0.
      ENDIF.
      da_save = charx.

  ENDIF.
Categorie
Informatica aziendale

Sviluppo SAP con SAPGUI o ADT ?

Nel mondo SAP il linguaggio di sviluppo principale è ABAP, Advanced Business Application Programming : questo linguaggio è stato ideato per manipolare e rappresentare dati, il codice dell’ERP è stato scritto sin dalla nascita in questo linguaggio che è stato continuamente migliorato fino ai giorni nostri, release 7.55 e ABAP 2022 con S/4HANA.

Intorno al 2004 con la piattaforma NetWeaver e l’avvento dell’architettura orientata ai servizi gli si è affiancato Java, una scelta naturale visto l’ambito di utilizzo di questo linguaggio: l’application server SAP è quindi formato da due stack, uno ABAP e uno Java integrati fra loro.

Per anni lo sviluppo è stato circoscritto agli strumenti della SAPGUI, l’interfaccia grafica proprietaria che incorpora tutti gli strumenti necessari allo sviluppo e che finchè lo stack era solo ABAP era sufficiente a qualsiasi sviluppatore SAP. Gli strumenti della SAPGUI sono stati continuamente migliorati fino ad arrivare alle potenti transazioni che conosciamo oggi, solo alcuni esempi: la SE11 per la creazione e gestione delle strutture dati, la SE38 e ancora meglio la SE80 per la gestione del codice, SE10 e STMS per la gestione dei cambiamenti e dei trasporti. Chi come me sviluppa su SAP da più di un decennio conosce a menadito questi strumenti e posso dirvi che non sono proprio intuitivi, prevedono uno sforzo iniziale importante nella curva di apprendimento che va colmata con tanti concetti dietro le scene ma una volta sorpassato il picco iniziale si ottiene un’ottima produttività, direi la produttività massima possibile quando si arriva a padroneggiarli

Per lo sviluppo dello stack Java invece è stato preso Eclipse come riferimento, inizialmente sviluppato da IBM e poi sostenuto dalla comunità open source : su questo sono stati sviluppati nel tempo dei plugin per la gestione e programmazione del database e dello stack NetWeaver, Developer Studio copre l’intero ciclo di vita di un’applicazione Java in SAP ed Hana Studio è specifico della gestione del database.

Negli ultimi anni visto che solo l’ambito ABAP era rimasto fuori da Eclipse ,l’azienda ha pensato bene di accorpare tutto in questo software dando vita a ADT – ABAP Development Tools . ADT come la SAPGUI, offre gli strumenti di syntax check ed highlight, code completion, code refactoring e pretty printing con una interfaccia grafica semplice e personalizzabile che permette di editare e tenere sotto controllo contemporaneamente piu oggetti di implementazione, gestire le nuove view database chiamate Core Data Services, tenere sotto controllo il sistema di trasporto e molto altro.

ADT è uno strumento molto potente che sarà continuamente migliorato, offre una notevole produttività e migliora ambiti come l’auto completamento e l’introspezione, la generazione automatica di classi e metodi locali, il re-factoring del codice ma ancora c’è qualche aspetto dove la SAPGUI è superiore, come il debugging avanzato specialmente quando si cerca di andare nel punto di interruzione dopo che è cambiata la struttura di un metodo piuttosto che si voglia editare contemporaneamente ad altri utenti una stessa classe ( intendiamoci a breve anche queste piccole cose saranno sanate).

Quindi i due strumenti praticamente si equivalgono, i pro ed i contro sono veramente pochi e molto personali, dipendono piu che altro dal bagaglio di esperienza sull’uno o sull’altro e quindi dalla conoscenza che si ha di esso.

Secondo il mio modesto parere, se si sviluppa solamente ABAP oppure se si è abituati a sviluppare e testare sulla SAPGUI non è conveniente passare ad ADT, non c’è nulla in meno e comunque ne avremo bisogno per testare i programmi.

Pensando a chi scrive solamente codice magari nei due stack oppure ad un nuovo nuovo sviluppatore ABAP che magari ha gia esperienza in Eclipse passare ad ADT sarà naturale.

Il vero punto di forza di Eclipse è la potenza dell’interfaccia grafica, intesa nel veloce passaggio ad altri oggetti o task e di alcuni strumenti come il refactoring, ADT è molto piu vicina all’idea di un’IDE di programmazione.

Per chi non abbandona mai l’ERP o ABAP comunque le possibilità della SAPGUI la rendono piu produttiva e soprattutto piu completa, ci vorrebbero anni prima di arrivare a tanto con ADT.

Buon ABAP a tutti!

Categorie
Informatica aziendale

Le basi dell’MRP e dell’ATP

In qualsiasi sistema gestionale esistono due funzioni per la supply chain che sono essenziali per produzione e logistica:

Master Resource Planning : la pianificazione dell’approvvigionamento generale delle risorse necessarie alla vendita, sia di produzione interna che esterna, abbreviata MRP.

Available To Promise: la pianificazione della disponibilità delle merci in uscita rispetto le quantità gia impegnate da altri fabbisogni, in generale in vendita e per consumo.

L’MRP è una funzione di calcolo in INPUT e riguarda la parte iniziale dei processi logistici e produttivi: si occupa degli acquisti delle materie prime, della produzione dei semilavorati e delle lavorazioni esterne necessarie a produrre la merce che poi andrà in stock pronta per la vendita.

L’ATP è una funzione di calcolo in OUTPUT, cioè riguarda la parte finale dei processi e precisamente il calcolo delle quantità ancora a disposizione per l’uscita quindi alla vendita per i clienti finali o per i consumatori interni.

SAP per quanto riguarda l’MRP reperisce dall’anagrafica articolo le impostazioni sul tipo di approvvigionamento, per primo guarda se questo è interno o esterno: se è esterno guarda il periodo di approvvigionamento, la quantità dello stock di riordino, le impostazioni del lotto e del suo arrotondamento, guarda se esiste un fornitore abituale o lo determina tramite la lista sorgente.

Se SAP riesce a determinare il fornitore, legge le impostazioni del record info acquisti che lega in modo piu specifico il materiale al fornitore ed al prezzo concordato: a questo punto può calcolare con il tipo di funzione selezionata (deterministica, basate sui volumi, euristica, ne esistono molte) le quantità generando le richieste di acquisto. Queste possono essere rilasciate anche in modo automatico creando veri e propri ordini di acquisto che possono essere trasmessi telematicamente al fornitore: se SAP non è riuscito a determinare il fornitore lascerà all’utente la richiesta di acquisto pronta da elaborare inserendo i dettagli di fornitore, prezzi, destinazioni e modalità secondo accordi.

Nel caso di approvvigionamento interno SAP puo generare la richiesta di trasferimento del materiale dal plant produttivo: in quest’ultimo caso SAP deve effettuare la pianificazione della produzione dove va a esplodere le liste dei componenti necessari, se non disponibili dovrà rieseguire l’MRP sulle componenti, e controllare le versioni di produzione del materiale per calcolare la linea di schedulazione delle date degli ordini di produzione in base alle capacità disponibili sulle risorse.

L’ATP invece controlla lo stock disponibile, cioè le quantità già impegnate per la vendita o per altri scopi e le quantità di cui potete ancora disporre, non ancora promesse a nessuno come sta a significare l’abbreviazione anglosassone. Pensate al vostro stock in magazzino, se avete già degli ordini cliente che state processando o spedendo quanto stock ancora disponibile alla vendita vi rimane ? Questa è la quantità disponibile che ad esempio possiamo promettere su ordine di vendita al cliente, al netto delle quantità gia impegnate: capite che in questo caso il sistema gestionale deve memorizzare ogni singolo impegno di vendita del materiale e calcolare ad ogni nuovo impegno se questo può essere soddisfatto o meno.

Fin qui nulla di complicato se non fosse per il fatto che la disponibilità deve essere calcolata anche per materiali che non vanno solo in vendita ma su cui si basano altri prodotti magari in modo personalizzato o combinato: pensate al singolo articolo che potete vendere sfuso direttamente o su cui andate a creare dei kit assieme ad altri articoli. Questi articoli diverranno dei componenti dell’articolo assemblato e su questi componenti avrete sia impegni da ordini di vendita che impegni da ordini di produzione di assemblati.

In questi casi MRP e ATP si incrociano e lavorano a stretto contatto in INPUT e OUTPUT sullo stock magazzino: MRP determina quante sono le quantità del componente necessarie alla produzione dell’assemblato e quindi le quantità da approvvigionare ma è ATP che decide in base alle vostre regole a chi assegnare lo stock del componente.

ATP infatti deve memorizzare ogni impegno su ordine di vendita sia di assemblato che di prodotto sfuso, nel caso della produzione dell’assemblato prenderà come riferimento gli impegni delle esplosioni BOM sui componenti generate dall’MRP. ATP sommerà le quantità controllando che la quantità totale degli ordini di vendita, sia di componenti per assemblati che di componenti singoli, non arrivi alla quantità totale in stock del componente: nel caso la quantità totale a stock disponibile venga superata non permetterà piu di allocare ordini di vendita. Naturalmente nel frattempo MRP controllerà le quantità in stock e nel caso sia impostata con calcolo basato sul volume di consumo ( ad es. V1 o V2 ) terrà conto dei volumi in vendita ed in produzione e aumenterà il lotto di riordino in approvvigionamento di conseguenza.

In questo articolo ho spiegato in modo abbastanza sintetico le due colonne portanti di ogni gestionale ma ricordate che la bontà del comportamento del sistema dipenderà poi dai dati e dalle configurazioni che sceglierete di adottare: queste devono essere “cucite” sul processo di business per come deve funzionare nella realtà, scomponete i processi e pensando alle best practices capite quale è il migliore scenario da utilizzare, concordatelo con il cliente, poi da li sceglierete la miglior configurazione validata dai test effettivi, poi dati accurati per farlo funzionare al meglio.

SAP mette a disposizione una infinità di scenari e relative configurazioni per tenere conto di ogni particolarità, nei prossimi articoli ne parleremo in modo piu specifico assieme ad alcune particolarità di MRP e ATP, buon SAP a tutti!

Categorie
Informatica aziendale

SAP, consigli utili per l’implementazione

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 😉

Categorie
Informatica aziendale

SAP EWM embedded in S/4HANA

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.

Categorie
Informatica aziendale

IOT open source per uso industriale

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.

Categorie
Informatica aziendale

Connected factory

In questo articolo faremo una sintesi di alto livello delle azioni necessarie per raggiungere l’obiettivo dell’integrazione nelle fabbriche: parole come “connected factory”,”smart factory” o “smart manufacturing” fanno tutte riferimento all’obiettivo della fabbrica digitalmente interconnessa dove i dati delle macchine e gli impianti di produzione e di logistica sono integrati fra loro e con i processi aziendali dell’ERP.

Come base di partenza per avere processi completamente integrati dovremo sviluppare per prima cosa l’infrastruttura di rete, dal nostro data center verso le nostre linee di produzione e le macchine che compongono la linea o i sistemi di supervisione.

Abbiamo gia trattato in altri articoli come e dove dare le priorit?, valutando il ritorno economico, il budget a nostra disposizione e l’impatto che avremo sui fermi dei processi, .

Per essere interconnesse, il PLC della macchina o il sistema SCADA dovranno avere un secondo punto rete con cui comunicare verso i server di integrazione e la nostra rete aziendale: quello della scheda di rete o router di integrazione e relativa messa in opera ? il primo costo che dovremo affrontare.

Per un fattore di sicurezza informatica diamo per scontato che l’interconnesisone sia fisica con cavo di rete e che la nuova scheda di rete o device usato sulla macchina/impianto non abbia il routing abilitato al suo interno: questo nuovo punto rete infatti dovr? segregare le comunicazioni verso il nostro data-center dalle comunicazioni interne della sottorete della macchina/impianto.

  Se non abbiamo reti ethernet locali ed abbiamo i dati di nostro interesse su un singolo PLC o PC convogliatore, ci converr? dotarlo di una seconda scheda di rete dedicata alla rete aziendale, se invece abbiamo gi? una rete locale dedicata all’automazione della linea o del processo oppure una sua supervisione, potremo usare un router interno a questa sottorete per eseguire il NAT dei dispositivi voluti verso la nostra rete aziendale ed i nostri server. Se non abbiamo un router industriale capace di NAT nella sottorete dell’impianto dovremo installarlo e sostituire lo switch/router/hub gia presente.  

Dovremo dedicare una o piu VLAN alle comunicazioni di questo tipo segregate dalle altre e opportunamente controllate da firewall.

Sui server dovremo avere un middleware capace di “parlare” i dialetti dei PLC e SCADA che abbiamo sulle nostre linee, come detto in altri articoli,  prodotti come Matricon, KepWare, Wonderware OI Server sono in grado di tradurre ed esporre i dati su protocolli OPC – standard aperto per la comunicazione industriale.

Se installiamo poi la suite Wonderware System Platform avremo molto di piu di un middleware capace di esporre dati in OPC, oltre che parlare con l’automazione questa suite ci permetter? di elaborare i dati provenienti dal campo implementando dei veri e prori sistemi MES o WMS completi, fornendo feedback delle operazioni sempre all’ERP. 

Una volta disponibili in rete i dati di processo su protocolli aperti come OPC possiamo sfruttarli in mille modi, utilizzarli sui pi? differenti sistemi, storicizzarli per vederne e capire gli andamenti, fare report ad hoc su prodotti da ufficio come Excel o meglio PowerBI.

Il beneficio maggiore ma anche piu costoso sarebbe integrarli con l’ERP tramite degli appositi connettori e sistemi dedicati alla comunicazione con il factory floor come ad esempio gli end point SAP MII, a questo punto abbiamo dedicato un’altro articolo vista la sua estensione analizzando le possibilit? di integrazione del gestionale SAP .

Capite che si apriranno molteplici opportunit?, le dovremo prioritizzare e implementare a seconda della consueta analisi costi benefici: nella figura sotto abbiamo rappresentato una tipica integrazione con alcuni esempi delle soluzioni pi? diffuse e vantaggiose, vi invito a scrivermi per analizzare assieme a voi costi, tempi e possibili piani di progetto.

Una volta realizzata l’interconnessione e configurato il sistema middleware di automazione possiamo rendere semplice il passaggio ad una vera e propria “connected factory”: pensate solamente ai vantaggi per l’ERP, questo pu? diventare la colonna dorsale aziendale che estende le sue terminazioni nervose sino alle linee di produzione allineandosi con tutti i sistemi intermedi di produzione e logistica.

I sistemi di automazione processo possono configurarsi e operare a seconda della pianificazione dell’ERP e al tempo stesso l’automazione pu? fornire feedback sull’esecuzione all’ERP cosi che questo possa lavorare veramente in real time.

Capite che in questo modo viene favorita oltre l’integrazione verso l’alto anche l’integrazione orizzontale fra sistemi eterogenei: attraverso un middleware capace di trattare standard aperti come OPC o xml, gli impianti di automazione e i sistemi scada di diversi fornitori potranno comunicare e lavorare in modo integrato scambiandosi dati su tutto il processo.   

i4.0schema.png
Categorie
Informatica aziendale

L’importanza di una buona pianificazione

La pianificazione aziendale come la pianificazione personale è un’attività importantissima per poter raggiungere un obiettivo nel tempo e nel modo che ci siamo prefissati. Per gestire la pianificazione aziendale SAP mette a disposizione tutta una serie di strumenti che ci consentono di mappare le nostre attività e calcolarne date, tempi, quantità. Questo riguarda tutti i processi ma in particolare modo quello logistico e produttivo: partendo dalla pianificazione generale potremo organizzare le operazioni aziendali fino alle micro attività, potremo alleggerire il nostro personale di operazioni ripetitive e soprattutto reagire alle inefficienze in modo integrata fra i vari reparti, evitando sovraccarichi, problemi di disponibilità, ritardi in operazioni seguenti.

Che sia un servizio o un bene materiale, di solito tutto parte dalla domanda del cliente, si stabilisce qualità, prezzo e tempi per poi organizzare le operazioni necessarie. Dovremo mappare queste operazioni nel sistema SAP cosi che poi questo ci aiuti a calcolare e stabilire la linea di pianificazione secondo le impostazioni e parametri che avremo configurato: impostazioni sui materiali, sui tipi di documenti, sulle modalità e tipi di gestione si tradurranno in continue operazioni di persone e macchine nella linea di pianificazione. Una volta configurati i parametri principali andremo ad affinarlo sempre piu scendendo nelle impostazioni di dettaglio nelle varie aree.

La data di consegna al cliente è il primo cardine di una linea di pianificazione, per prima cosa dovremo capire se schedulare in avanti o all’indietro per fissare i nostri tempi. Questo dipende in gran parte da come vogliamo lavorare e come fissiamo la data nel contratto di vendita col cliente, se promettiamo la merce ad una data questo ci obbligherà a schedulare a ritroso per tutte le altre operazioni, se offriamo la nostra migliore data potremo calcolare in avanti in base alle nostre capacità: questo implica capire come organizzare e gestire il nostro processo aziendale.

In uno scenario MTS (make to stock) dovremo fare particolare attenzione allo scenario produttivo ed alle capacità, il calcolo sulla nostra distribuzione sarà molto importante ed ancora di più saranno le nostre previsioni di vendita e quindi il punto ottimale di accumulo di stock nel tempo per evitare rotture. Se siamo in uno scenario MTO (make to order) conterà molto la stabilità dei nostri processi perché il calcolo sarà su una unica linea di pianificazione dove tutte le operazioni sono concatenate e dovremo calcolale al meglio per rispettare le date: dall’approvvigionamento delle materie prime alla produzione fino alla distribuzione della merce.

In SAP possiamo concertare e poi propagare la nostra linea di pianificazione su tutti i moduli sino ad arrivare al dettaglio nelle varie di processo ( acquisto, qualità, produzione, logistica): ricordate di stabilire dei punti di buffering nel flusso per fare fronte agli imprevisti e alle rotture, purtroppo la realtà non è mai perfetta…. La velocità del business deciderà poi la cadenza dei job di di pianificazione a sistema, cioè ogni quanto ripianificare le operazioni per il periodo seguente, potrebbe essere giornaliero, settimanale o addirittura mensile.

Questa è la teoria del macro processo aziendale, dovremo implementare con gli strumenti che SAP ci mette a disposizione queste logiche ponendo enfasi sul coinvolgimento dell’azienda in ogni suo livello, SAP è lo strumento ma sono le persone che fanno la vera produttività .

In SAP, ad alto livello, per la pianificazione generale della supply chain troviamo lo strumento principe, APO – Advanced Planner and Optimizer che con la tecnologia di database in memory HANA consente l’integrazione di un’infinità di dati in real-time da tutti i processi applicativi interessati.

APO è una soluzione che si basa su un insieme di integrazioni specifiche con gli altri moduli SAP eliminando la necessità di utilizzare diverse soluzioni per ogni area: diciamo che APO è il nodo centrale della pianificazione che estende poi le sue influenze sin nelle operazioni più basse dell’ERP.

La pianificazione con APO consente alle aziende di tenere conto di innumerevoli fattori come la disponibilità delle risorse, i tempi logistici (di consegna dei fornitori, di trasferimento in ogni processo), la domanda dei clienti e moltissimi altri fattori utilizzando algoritmi di ottimizzazione avanzati: in questo modo APO può generare un piano ottimale e influenzare le varie aree per massimizzare la disponibilità delle risorse e ridurre i costi.

APO comunque non è sempre necessario, se le dimensioni del business sono ridotte gli strumenti di pianificazione standard come MRP e ATP sono più che sufficienti, magari unite anche alla gestione delle capacità e delle risorse che ormai in S/4 sono implementate ovunque, oltre che nella produzione anche in gestione del magazzino, qualità e trasporti.