Come deve essere un ERP aperto al futuro

Introduzione

L’ERP di domani sarà un gestore di processi sempre più automatizzato che potrà dialogare in modo aperto e interattivo con tutte le entità, un Information Provider che, grazie alle tecnologie WEB SERVICES REST, consentirà di dialogare in senso verticale e orizzontale con qualsiasi dispositivo o apparato e con qualsiasi forma di interfaccia, estrarre valore dalle informazioni di processo tramite il deep learning, integrare reti neurali di intelligenza artificiale per robotizzare operazioni a zero valore aggiunto, e dialogare con qualsiasi software eterogeneo secondo le logiche Industry 4.0 in tutta la catena del “Supply Chain”.

Il futuro della gestione aziendale sarà infatti sempre di più orientato all’interoperabilità verticale e orizzontale all’interno della supply chain, dove l’automazione e la trasmissione dell’informazione sarà sempre più gestita attraverso web services attivati da sistemi esperti basati su AI , analogamente a quello che avviene e avverrà sempre di più con l’IOT di fabbrica e di prodotto, creando così una base dati idonea per estrarre valore attraverso il Machine Learning (o addirittura il Deep Learning).

In stretta collaborazione con l’ERP potranno operare i Robot software (RPA , Robotic Process Automation) ossia quei sistemi che, interagendo con gli applicativi informatici e riproducendo le azioni umane, sono capaci di automatizzare i processi lavorativi, in particolare le attività ripetitive.

Come dovrà essere l’ERP del futuro

Quale sarà l’evoluzione delle imprese con la trasformazione digitale?

Le aziende di un paese come l’Italia, in cui le filiere produttive sono costituite soprattutto da aziende medio piccole, e sono pertanto più lunghe e ramificate rispetto ad altri paesi, devono assolutamente riuscire a creare una gestione coordinata e organica, che opera in modo sincrono, con una intelligenza complessiva di filiera che trae la sua forza dalle intelligenze distribuite sulle singole entità aziendali, e questo è possibile solo se i sistemi informativi delle aziende della filiera dialogano in tempo reale tra di loro, oltre che con il mondo esterno.

 

I tempi per attuare questa progressiva trasformazione devono essere rapidi, perché la velocità con cui il resto del mondo si trasforma è impressionante.

Per raggiungere questi obiettivi si deve operare in 3 direzioni.

1. È necessario aprire prima possibile i propri sistemi informativi verso l’interazione con il mondo esterno, ad es. con sistema gestionale dotato di “web server rest”, per poter dialogare in modo agevole con tutta la filiera e fare sistema

2. È necessario integrare o interfacciare i propri sistemi informativi con sistemi di Intelligenza Artificiale (AI) e con tutte le applicazioni digitali rese disponibili dalle tecnologie.

3. È necessario digitalizzare anche tutti i processi interni non gestibili con l’ERP, perché sarà impossibile ottenere un’efficienza aziendale completa se prima non sono digitalizzati anche tutti i micro-flussi interni, ossia non solo i processi generalmente definiti come “strutturati”, gestibili tramite un sistema di gestione aziendale (ERP), ma anche i processi definiti “non strutturati”, che oggi possono essere gestiti tramite ulteriori strumenti software (sistemi BPM , DMS , ecc.) integrati con l’ERP.

Nel prossimo futuro alle imprese che fanno parte di una filiera produttiva verrà richiesto anche quali WEB SERVICES saranno in grado di mettere a disposizione, perché l’utilizzo del tempo umano sarà consentito solo per operazioni e processi ad alto valore aggiunto; nessuno vorrà più mandare una mail o fare una telefonata per sapere, ad esempio, una data di consegna, ma sarà un WEB SERVICES che potrà rispondere immediatamente ai sistemi informatici dei clienti per conto dei fornitori.

L’intelligenza nelle filiere (porte aperte all’evoluzione)

Uno dei problemi principali nell’industria è quello di integrare applicazioni informatiche sviluppate in maniera indipendente e con un altissimo numero di tecnologie eterogenee.

L’integrazione applicativa può essere considerata a diversi livelli: all’interno della stessa azienda, tra partner dell’azienda, verso utenti generici (clienti, fornitori, ecc.).

L’integrazione è in ogni caso necessaria quando un processo coinvolge diversi sistemi informatici: sfruttare Internet come piattaforma globale di integrazione è un’opportunità notevole, soprattutto per l’integrazione tra diverse aziende. Lo sviluppo di Internet e delle Intranet rende utile creare applicazioni che comunicano e si scambiano informazioni attraverso la rete.

L’integrazione è però resa più difficile dalle politiche di sicurezza (firewall aziendali, restrizioni d’accesso, etc.), ed è per questo motivo che riveste grande importanza la tecnologia dei Web Service.

Lo scopo primario di un Web Service è fornire una via estremamente semplice e versatile per far comunicare componenti software attraverso la rete.

La vera chiave è l’interoperabilità: i “web service”, e in particolare i “web service rest”, non sono dipendenti da architetture software/hardware particolari, possono essere implementati praticamente con qualsiasi linguaggio, il client e il server possono essere basati su linguaggi e tecnologie diverse.

A cosa servono i web service

Un Web service (servizio web), secondo la definizione data dal World Wide Web Consortium (W3C), è un sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su una medesima rete oppure in un contesto distribuito, quindi un sistema software in grado di mettersi al servizio di un’applicazione comunicando su di una medesima rete tramite il protocollo http. Un Web Service è pertanto essa stessa un’applicazione messa a disposizione (pubblicata) da una macchina e accessibile attraverso protocolli standard su Internet (http e porta 80 per evitare i firewall).

I WS fanno quindi da tramite per i messaggi che sono scambiati tra computer e computer all'interno di una rete, e l'utilizzo del codice XML è fondamentale poiché è l'unico ad assicurare la corretta trasmissione dei dati da un capo all'altro della connessione.

Gli standard utilizzati per i WS sono tutti dialetti di XML:

SOAP (Simple Object Access Protocol): descrive un protocollo basato su XML che definisce i meccanismi con cui un WS è invocato ed il formato dell’input e dell’output

WSDL (Web Service Definition Language): descrive l’interfaccia esterna di un WS affinché uno sviluppatore possa creare un client capace di accedervi

UDDI (Universal Discovery, Description and Integration): descrive registri contenenti informazioni per la scoperta e l’accesso ai WS

Quali protocolli usare

Esistono diversi standard per la codifica e la trasmissione delle chiamate e delle risposte: CORBA, RMI, .NET, ... Invece di usare complicati bridge per tradurre un protocollo in un altro, quando due framework diversi devono comunicare tra loro, SOAP (Simple Object Access Protocol) si era proposto come protocollo universale per la trasmissione dei dati, ossia come sostituto per tutti questi protocolli. Il SOAP era pertanto un protocollo per l'implementazione di servizi Web con una struttura e uno schema ben preciso che si basa sull'XML, attraverso cui avviene lo scambio dei dati e la gestione delle risposte Il protocollo SOAP definisce una struttura dati per lo scambio di messaggi tra applicazioni, riproponendo in un certo senso parte di quello che il protocollo HTTP faceva già. SOAP utilizza HTTP come protocollo di trasporto, ma non è limitato nè vincolato ad esso, dal momento che può benissimo usare altri protocolli di trasporto. A differenza di HTTP, però, le specifiche di SOAP non affrontano argomenti come la sicurezza o l’indirizzamento, per i quali sono stati definiti standard a parte, nello specifico WS-Security e WS-Addressing.

L’approccio dei SOAP Web service ha mutuato un’architettura applicativa denominata SOA, Service Oriented Architecture, a cui si è recentemente contrapposta l’architettura ROA, Resource Oriented Architecture, ispirata ai principi REST.

REST (Representational State Transfer) , è invece definibile come uno “stile architetturale” per sistemi distribuiti, un sistema di trasmissione di dati su HTTP senza ulteriori livelli, quali ad esempio SOAP.

Mentre SOAP è un protocollo con requisiti specifici, come la messaggistica XML, REST è un insieme di linee guida per un'architettura con un'implementazione flessibile, e pertanto a differenza dei web services basati su SOAP, non esiste alcuno standard ufficiale per le API web RESTful.

Vantaggi e svantaggi di Web Service basati su SOAP e REST

È evidente che l’approccio adottato dai Web Service basati su SOAP è derivato dalle tecnologie di interoperabilità esistenti al di fuori del Web e basato essenzialmente su chiamate di procedura remota, come DCOM, CORBA e RMI. In sostanza questo approccio può essere visto come una sorta di adattamento di queste tecnologie al Web.

SOAP, quindi, non sfrutta appieno il protocollo HTTP, ma lo utilizza come semplice protocollo di trasporto. REST invece sfrutta HTTP per quello che è, un protocollo di livello applicativo, e ne utilizza appieno le potenzialità.

L’approccio REST tende a conservare e a esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere una piattaforma per l’elaborazione distribuita. Quindi, non è necessario aggiungere nulla a quanto è già esistente sul Web per consentire ad applicazioni remote di interagire.

In conclusione, i Web service basati su SOAP costruiscono un’infrastruttura prolissa e complessa al di sopra del Web per fare cose che il Web è già in grado di fare. Il vantaggio di questo tipo di servizi è che in realtà definisce uno standard indipendente dal Web e l’infrastruttura può essere basata anche su protocolli diversi.
REST invece intende ripristinare il Web ad architettura per la programmazione distribuita, senza aggiungere sovrastrutture non necessarie.

Le API - (Application Programming Interface)

API (Application Programming Interface, Interfaccia di Programmazione di un’Applicazione), è un insieme di definizioni e protocolli per la creazione e l'integrazione di software applicativi. ossia un insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l’espletamento di un determinato compito all’interno di un certo programma. Spesso con tale termine si intendono le librerie software disponibili in un certo linguaggio di programmazione.

La finalità è ottenere un’astrazione a più alto livello, di solito tra l’hardware e il programmatore, o tra software a basso e quello ad alto livello semplificando così il lavoro di programmazione. Le API permettono infatti di evitare ai programmatori di riscrivere ogni volta tutte le funzioni necessarie al programma dal nulla, ovvero dal basso livello, rientrando quindi nel più vasto concetto di riuso di codice. Le API stesse rappresentano quindi un livello di astrazione intermedio: il software che fornisce una certa API è detto implementazione dell’API.

 

L'API REST, o API RESTful, non è altro che un'API che segue i principi REST e che per funzionare ricorre ai comandi dell'HTTP, ovvero GET, POST, PUT e DELETE. È quindi un'interfaccia di programmazione delle applicazioni (API o API web) conforme ai vincoli dello stile architetturale REST, che consente l'interazione con servizi web RESTful. Poiché sono ottimizzate, le API REST sono adatte ai contesti più innovativi come l'Internet of Things (IoT), lo sviluppo di applicazioni mobili e il serverless computing.

La nuova versione di SAM ERP2 aperta al futuro (vers. 6.0)

La nuova versione 6.0 ha fatto fare agli ERP di Centro Software, in particolare a SAM ERP2, un salto tecnologico con cui il software si è aperto completamente al futuro. SAM ERP2, che rappresenta da tempo il più completo sistema di gestione e pianificazione di tutte le risorse dell’impresa, è ora anche in una piattaforma in grado di accompagnare le imprese nel lungo processo di digitalizzazione dei prossimi anni.

Approfondisci QUI gli highlights dell’ultima versione dell’ERP.