Il problema dell’integrazione non riguarda solo applicazioni e processi interni all’azienda ma anche quelli dell’azienda e dei suoi clienti e fornitori,
cioè della sua supply chain. Nel precedente
post abbiamo descritto una soluzione low cost e flessibile per l’integrazione interna mentre qui ne viene descritta una per l’integrazione con i fornitori. Sul versante
della fornitura è ormai sempre più frequente trovare, anche laddove non vi siano espliciti ordini aperti o ordini quadro, delle situazioni in cui il fornitore produce più di quanto richiesto dal cliente con un determinato ordine, sapendo che il surplus verrà comunque assorbito da ordini successivi. Per il cliente il lead time
di approvvigionamento rilevato nel caso di spedizione di surplus di produzioni precedenti o di pezzi di nuova produzione è molto diverso e condiziona in modo
determinante la pianificazione
della produzione e le consegne ai clienti. Un modo molto pratico per gestire queste situazioni è modellare sull’APS il magazzino presso il fornitore (contenente le
produzioni in surplus) e impiegare il MRP multimagazzino dell’APS per gestire lead time differenziati per i semplici trasferimenti di giacenza o per le nuove produzioni.
La fonte dati usata dall’APS per le giacenze presso il fornitore può essere un foglio elettronico aggiornato periodicamente dal fornitore con i dati di giacenza per ogni
articolo. Questo foglio elettronico può essere trasmesso via e-mail dal fornitore ed inserito dal pianificatore presso il cliente
in un’opportuna directory in rete da dove è letto direttamente dall’APS. Oppure
si può usare un cartella condivisa tra cliente e fornitore contenente il foglio elettronico e sincronizzata automaticamente usando Dropbox.
Blog
Lean integration – parte seconda
Lean integration technologies
Nei progetti in cui un sistema dipartimentale deve essere integrato con il sistema ERP, il costo per la realizzazione
delle procedure di scambio dati (integrazione) tra i sistemi è spesso molto rilevante, addirittura paragonabile al costo del sistema dipartimentale. I motivi
di ciò sono legati al fatto che l’azienda che vuole dotarsi del sistema dipartimentale può rivolgersi solo ai
produttori dei due sistemi, soprattutto se le tecnologie di integrazione usate da questi non sono accessibili al dipartimento IT dell’azienda in questione
(perchè bisogna
metter mano al codice dei due applicativi o usare tecnologie proprietarie). Questo tipo di problemi affliggono spesso anche i progetti di inserimento in azienda
di un sistema di pianificazione e limitano la diffusione di questi applicativi solo ad aziende facoltose. Tutto ciò
vale soprattutto per gli APS più datati, i quali sono solitamente meno versatili in termini di tecnologie di integrazione supportate.
Tra le soluzioni più flessibili e innovative a questo problema vi è l’utilizzo di Sikuli, un tool
sviluppato dal MIT (e usato da aziende leader, da quanto si legge dal sito) e che ha raggiunto ormai la maturità. Si tratta di un applicativo che viene programmato non scrivendo
codice ma descrivendo le operazioni da eseguire con le immagini del pulsante su cui cliccare, della casella da riempire, ecc.
Per quanto riguarda i processi in cui sono coinvolti gli APS, questo tool permette di esportare i dati verso il sistema gestionale emulando un utente che interagisce
con l’interfaccia grafica del sistema gestionale. Si tratta di uno strumento che può essere usato sia per il data entry (l’abbiamo usato per caricare sul gestionale
delle nuove anagrafiche
da un foglio elettronico), sia per l’esportazione quotidiana di nuovi ordini di produzione o richieste di acquisto. Questo significa che l’azienda che vuole esportare
i dati generati
dall’APS verso il sistema ERP può crearsi le procedure in autonomia e rapidamente, riducendo il costo del progetto. Alcuni sistemi (e [[Cowry https://www.paneido.com/solutions]] è tra questi) permettono
di lanciare Sikuli
direttamente, dandogli
come input la lista degli ordini o degli altri dati da trasferire sul sistema gestionale. L’integrazione svolta in questo modo è più semplice da realizzare e
da testare e permette di abbattere i costi di progetto ed i tempi della fase di integrazione.
APS e MRP
Probabilmente questo post sarebbe dovuto essere il primo di questo blog, ma non è mai troppo tardi. Derek Singleton ci ha segnalato
il suo articolo riguardo le differenze tra sistemi APS e MRP e dopo averlo letto posso dire di essere d’accordo con lui sulle differenze tra i due tipi di sistemi dal
punto di vista del tipo di ambienti in cui possono essere utilizzati nel modo più proficuo. Il suo articolo è anche un’occasione per cercare una buona definizione di APS, per poter meglio comunicare l’utilità ed il ruolo di questo tipo di sistemi. La definizione del dizionario APICS non contribuisce molto a chiarire il concetto:
“Tecniche per gestire l’analisi e la pianificazione di processi logistici e produttivi nel breve, medio e lungo periodo. APS descrive ogni applicativo che impiega
avanzati algoritmi matematici o logica per svolgere ottimizzazione o simulazione su schedulazione a capacità finita, acquisti, pianificazione finanziaria, pianificazione
delle risorse, previsioni di vendita, gestione della domanda e altri. Queste tecniche considerano simultaneamente una serie di vincoli e regole per fornire in tempo reale
funzionalità di pianificazione e schedulazione, supporto alle decisioni, disponibilità alla vendita (ATP) e capacità di consegna (CTP). Un APS spesso genera e valuta più scenari. Il management poi seleziona uno scenario da usare come ‘piano ufficiale’. I cinque principali componenti di un sistema APS sono (1) demand planning,
(2) production planning, (3) production scheduling, (4) distribution planning e (5) trasportation planning.”
Questa definizione è basata principalmente su cosa gli APS fanno (lista di moduli) e meno su come lo fanno. La maggior parte degli applicativi disponibili sul mercato,
che solitamente sono considerati APS, non comprendono l’intera gamma dei moduli previsti dalla definizione APICS ma solo alcuni di essi ma non per questo non sono considerati
degli APS. Quindi c’è qualcos’altro che rende un applicativo un APS. Penso che una definizione dovrebbe evidenziare anche ‘come’ il sistema opera per facilitare le
attività di pianificazione. E le principali caratteristiche sono:
- elevata performance di calcolo (ottenuta mediante algoritmi matematici avanzati ma anche, spesso, impiegando database in-memory)
- potenti funzionalità di visualizzazione per facilitare l’analisi dei dati da parte del pianificatore
- strumenti per l’integrazione tra sistemi per accelerare la raccolta dei dati significativi per le attività di pianificazione e schedulazione.
Il motivo principale che indusse allo sviluppo dei sistemi APS fu che le procedure MRP sui sistemi transazionali erano troppo lente per consentire ripianificazioni frequenti. Dopo che questo vincolo venne significativamente ridotto, le funzionalità di visualizzazione e navigazione nei dati impedirono al pianificatore
di essere il nuovo collo di bottiglia nel processo di pianificazione. L’integrazione dei dati è un altro importante aspetto che consente al pianificatore di non perdere tempo nel recupero dei dati che servono per le sessioni di pianificazione.
Capacità finita su un orizzonte definito
Le pianificazioni a capacità finita e infinita possono essere combinate in una sessione di pianificazione in diversi modi:
possono essere applicate distintamente a risorse diverse (come descritto in un altro posto di questo blog) o possono essere applicate alla stessa risorsa (centro di lavoro,
attrezzatura o altro) contemporaneamente. In altre parole è spesso conveniente impostare il vincolo di capacità per una risorsa su un determinato orizzonte
temporale a partire dalla data corrente e pianificare a capacità infinita oltre tale orizzonte. In questo modo possiamo modellare la situazione in cui
nel breve periodo non possiamo incrementare la capacità mentre nel medio/lungo termine è possibile aggiungere risorse o capacità. E’ semplice impostare
ciò in Cowry.
