Low code: l’evoluzione dei software ERP secondo smeup

Ecco quindi che la domanda sorge spontanea: qual è la soluzione per supportare queste imprese a semplificare la complessità?
Per noi di smeup la risposta è: LOW CODE.

Ovvero: far evolvere la tecnologia senza scrivere nuovo codice, o scrivendone il meno possibile, e utilizzando dei linguaggi che non necessitano alte competenze a livello di programmazione.

Come lo facciamo? Ve lo spieghiamo subito, ma prima è doveroso fare un passo indietro per spiegare qual è il nostro approccio per il software del futuro: un sistema custom costruito con componenti standard.

Software custom con componenti standard

Software custom e software standard.
La differenza tra un software standard e un software custom è che quest’ultimo è costruito sulle esigenze del cliente ma è rigido nella sua evoluzione: una volta costruito è più difficile farlo evolvere e soprattutto farlo con costi ridotti.
Un sistema software standard, invece ha costi minori, resta sempre aggiornato. Ma non è costruito sulle esigenze specifiche dell’impresa, è uguale per tutte le aziende e quindi di fatto non permette di differenziarsi dalla concorrenza.

La nostra risposta: un ibrido
Noi ci poniamo nel mezzo costruendo un software custom con componenti standard. In particolare il nostro focus è sugli oggetti. I componenti sono una parte tecnologica importante, ma in questo momento il focus sono gli oggetti.
Sviluppiamo il software standard in laboratorio, poi dal cliente andiamo a sviluppare le parti custom dove servono, con l’obiettivo di minimizzare il total cost of ownership della soluzione software. Alla fine della vita del software in azienda, circa 10 anni, il costo totale sostenuto dall’azienda per ottenere i risultati desiderati è inferiore rispetto ad altri software.

Technology evolution e la logica Low Code

Punto focale di smeup data platform è il fatto che è costituita da una serie di strumenti definiti foundations, ovvero i blocchi elementari su cui si vanno a costruire le applicazioni, che sono scritte con una logica low code, che significa utilizzare il più possibile dei linguaggi ad alto livello come DLS (domain specific lanuage) che non necessitano di alte competenze a livello di programmazione, ma che si rivolgono anzi il più possibile ai non-programmatori.
Il low code ci da il vantaggio di far evolvere la tecnologia mantenendo il software che è già stato scritto. Perché se ad esempio il software è stato scritto con un DSL, evolvendo la parte che sta “sotto” ovvero la tecnologia su cui appoggiano gli script, lo script può rimanere uguale. Noi garantiamo proprio questo: che lo script rimanga uguale mentre la tecnologia evolve, mentre invece sviluppando software con linguaggi classici, bisognerebbe riscrivere tutto.

Vediamo un semplice esempio nel concreto: supponiamo che uno dei mattoncini mostrati nello schema sia la parte di CRM del nostro gestionale, e che il CRM abbia al proprio interno una funzione di Notify, scritta in modo tale inviare l’input di creare un documento in formato pdf e poi inviare un’email con il pdf a “oggetto.email_address”, ovvero l’attributo “indirizzo” di un oggetto generico.
Nel momento in cui si facesse ipoteticamente il passaggio da AS400 AD AWS, useremo sempre la funzione send_email, che però invece che appoggiarsi all’SMTP di AS400, che è il modulo AS400 adibito all’invio delle mail, si appoggerà al sistema Amazon di invio delle mail da AS400. Ma il codice iniziale sarà rimasto esattamente lo stesso.

Business Object Framework

Abbiamo parlato di oggetti, ma come funzionano esattamente?
Gli oggetti sono rappresentabili in una gerarchia, in cui è presente l’oggetto applicativo generico (il nostro business object) che possiede degli attributi che vengono ereditati da oggetti che sono meno generici. Ad esempio, il contatto che è un oggetto più specifico erediterà gli attributi dell’oggetto generico come ad esempio la data di creazione, il nome del responsabile, l’eventuale immagine, la cartella di riferimento, ma poi avrà anche dei suoi attributi specifici come contatto come ad esempio l’indirizzo, il numero di telefono e così via. A scendere all’interno della gerarchia ci saranno altri oggetti che seguiranno la stessa logica, in cui alcuni attributi e alcune funzioni verranno ereditati da altri oggetti.

Supponiamo di avere due clienti: Electronic LCC e DWC Corporation. Entrambe hanno smeup erp. La prima però ha i contatti di smeup che comprendono anche funzione Notify di cui parlavamo, che ha un oggetto “.email_address” per cui si può applicare l’invio email a qualunque oggetto abbia un attributo “email_address”.
I contatti che hanno questo attributo possono quindi avere la funzione di notifica, che in questo caso sarà appunto una notifica via email con un pdf. Facciamo l’esempio in cui il cliente DWC Corporation vuole creare un nuovo tipo di contatto, che esiste solo nella sua installazione di smeup, ad esempio creando il tipo di contatto “banca” e definisce che è un sottocaso di contatto. Siccome è un sottocaso di contatto , eredita l’ attributo “email_address” e anche la funzione notify, senza necessità di scrivere codice .
In sostanza, semplicemente perché abbiamo definito il nuovo oggetto, avremo in automatico anche la funzione Notify che è compatibile nonostante l’attributo “email_address” della banca sarà naturalmente diverso dall’attributo “email_address” del contatto generico.

Un’altra casistica è quella in cui abbiamo sempre la funzione Notify e la funzione email_address. Nell’azienda Electronic LCC l’indirizzo email dell’oggetto banca è scritto direttamente dentro al database di smeup. Nell’azienda DWC corporation, invece, l’indirizzo mail è remotizzato su Google Contacts. In questo caso, la funzione Notify rimarrà uguale e verrà utilizzata da entrambe le aziende senza dover riscrivere il codice, ma semplicemente cambiando la configurazione dell’attributo email_address, indicando dove andarlo a prendere.

Questi sono due esempi di come gli oggetti migliorano la fruibilità del software e consentono di operare degli avanzamenti tecnologici senza dover scrivere altro codice.

La navigazione

Un’ altra parte importante è la navigazione: all’interno di smeup c’è una navigazione automatica derivante dal fatto che è presente un reticolo di oggetti.
Un esempio è il funzionamento del cancello della nostra sede di Erbusco, che si apre leggendo la targa dei dipendenti. Il sistema è infatti in grado di associare la targa a un proprietario che è di tipo dipendente. Il dipendente ha poi associata una residenza che è di tipo indirizzo. L’indirizzo fa riferimento a una città che è di tipo località. Il dipendente ha un suo responsabile che è a sua volta di tipo dipendente e che quindi a sua volta ha indirizzo, città …. In questo modo è possibile navigare all’interno del sistema in modo libero attraverso degli hyperlinks.
Questo percorso di navigazione viene sfruttato da algoritmi interni automatici che sono in gradi di navigare per andare a reperire i dati di cui hanno bisogno e prendono decisioni sempre con lo stesso principio.
siccome la targa appartiene a un impiegato di smeup, allora il sistema invierà l’input di aprire il cancello. In questo caso, non c’è navigazione dell’utente, ma c’è un collegamento logico svolto dal sistema all’interno del software.