I rischi della Robotic Process Automation (RPA) sulle licenze SAP®

Quando l’utilizzo dell’RPA può generare non conformità nelle licenze SAP® e come impatta sui costi

Con l’aumento delle applicazioni RPA (Robotic Process Automation) che accedono ai software gestionali (SAP®, ad esempio) per automatizzare attività, le aziende potrebbero rischiare violazioni di non conformità per non averne licenziato correttamente l’uso.

È un tema centrale nella digital age, vista l’importanza crescente di bot e automatismi “intelligenti” nella trasformazione digitale. Anche le realtà che non ne fanno ancora uso, vedono l’RPA nel loro futuro e studiano progetti per guidare l’innovazione in azienda.

Non considerare l’RPA nella gestione delle licenze potrebbe facilmente portare a costi imprevisti: un’attività di audit in una situazione non pienamente gestita porta il più delle volte al rilevamento di situazioni non conformi nell’assegnazione di licenze che, solitamente, si traducono in esborsi pesanti e soprattutto non inseriti a budget.

Nel 2018 SAP® ha introdotto il Digital Access, un nuovo modello di licenza per gli accessi indiretti che considera anche RPA. Poiché a fine dicembre scade l’adozione del programma finanziariamente agevolato per adottarlo (il Digital Access Adoption Program), abbiamo deciso di approfondire l’impatto di RPA sul licensing SAP® e sulle strategie da adottare per calcolare il proprio fattore di rischio.

Robotic Process Automation (RPA): cos’è?

Gartner dice che l’“iper-automazione” diventerà una “condizione di sopravvivenza” per le imprese.

RPA non è altro che l’automazione robotica dei processi grazie all’utilizzo di software “intelligenti”. Bot, interfacce, applicativi… essi possono eseguire parzialmente o totalmente in modo automatico attività ripetitive imitando il comportamento degli operatori e interagendo con i software gestionali esattamente come farebbe un essere umano.

Tornano utili in qualsiasi ambito (IT, vendite, servizio clienti ecc.), anche con obiettivi molto diversi tra loro. L’utilizzo di RPA ha come benefici:

  • meno costi perchè i dipendenti vengono liberati da attività ripetitive e a basso valore aggiunto
  • più qualità  per la riduzione di errori umani (ad esempio, l’inserimento dati)
  • più innovazione per l’accelerazione data ai piani di trasformazione digitale

Per quanto questi bot abbiano usi e modalità differenti (dal chatbot alle applicazioni per il completamento di transazioni), due sono gli aspetti fondamentali che hanno in comune:

  • la capacità di gestire anche dati non strutturati (immagini, video, testi di e-mail ecc.)
  • apprendimento adattativo, grazie alle tecnologie AI/machine learning con cui vengono costruiti: “osservano” l’operatore umano eseguire determinate task, per poi imparare a ripeterle in autonomia.

RPA e SAP: quale rapporto

Con ECC interagiscono applicazioni terze e, dietro queste interazioni (estrazioni, elaborazioni, inserimenti, ecc…), potrebbe esserci un utente umano, ma anche un bot o un sistema automatizzato che replica le azioni umane.

Ad esempio, possiamo avere un assistente digitale in grado di supportare il cliente nella vendita, oppure un sistema automatizzato EDI (Electronic Data Interchange) che inserisce automaticamente da più fonti gli ordini relativi ai materiali. In entrambi i casi, in presenza o meno dell’utente da cui è partita la richiesta, il bot entra in SAP®, sfrutta la capacità di elaborazione del suo software e aggiorna i valori per il rilascio delle fatture/conferme d’ordine.

Questi applicativi terzi potrebbero essere di proprietà dell’azienda ma anche di partner o altri stakeholder. Le regole di licenza di SAP® richiedono che qualsiasi interazione con SAP debba essere licenziata sia che essa sia diretta o indiretta.

Il tema è molto delicato: un errore contrattuale può costare tantissimo all’azienda. Ma considerando che a usare SAP sono dei bot di automazione, l’accordo di licenza come copre questi nuovi “utenti”?

RPA e SAP®: come vengono licenziati

In passato, la mancanza di chiarezza sul conteggio degli utenti indiretti ha creato situazioni in cui le aziende si trovavano a dover sostenere spese non previste per cifre di milioni di euro (un caso noto e discusso è quello di Diageo UK vs SAP®: qui sono riassunti i punti salienti).

Per agevolare i suoi clienti, SAP® ha introdotto nel 2018 il modello Digital Access, che identifica in modo più semplice le condizioni di licenza ponendo la differenza tra l’accesso umano diretto (il cui conteggio è ancora basato sul numero di utenti) e l’accesso digitale indiretto dove il costo si basa sul conteggio di alcune tipologie di documenti (9 per la precisione) elaborati all’interno del nucleo digitale di SAP®.

Fonte: documentazione ufficiale SAP®

E RPA come va inteso? All’interno del nuovo modello, SAP® considera i documenti che sono stati gestiti con l’assistenza di bot come “uso” del software. Uso è definito come “attivare le capacità di elaborazione, caricare, eseguire, accedere, utilizzare il software o visualizzare le informazioni risultanti da tale capacità”. Ogni “uso” deve essere adeguatamente licenziato all’interno del contratto SAP®.

Rimangono però dei punti aperti:

  • automazione assistita/non assistita

L’automazione RPA può essere assistita (attended) o non assistita (unattended). La prima è anche conosciuta come assistente virtuale, prevede che l’utente attivi l’elaborazione. Mentre nel secondo caso l’esecuzione di compiti e interazioni è indipendente dall’utente e il bot esegue l’automazione da solo.

Questa differenziazione è presente anche in Microsoft, che per alcuni suoi prodotti (Microsoft 365, Power Automate ecc.) prevede delle licenze specifiche per gli scenari “unattended”.

Fonte: documentazione ufficiale Microsoft

Introdurre in SAP questo paradigma, distinguerebbe tra bot collaborativi con l’utente (potenzialmente coperti da una licenza named user) e bot indipendenti. Ma la comprensione dei differenti paradigmi in uso non è possibile con gli strumenti di misurazione di SAP®.

  • lettura statica

Un altro tema da prendere in considerazione è l’“indirect static read” (lettura statica), ovvero quelle situazioni in cui i dati vengono esportati da un sistema SAP® a un sistema non SAP® senza che vi siano aggiornamenti/elaborazione sul nucleo digitale SAP®.

Durante la conferenza Sapphire del 2017, il CEO di SAP® Bill McDermott ha confermato che non è richiesta la licenza per la lettura statica da parte di sistemi terzi. Quindi questo tipo di interazioni andrebbero escluse. Tuttavia, anche qui ci troviamo di fronte alla difficoltà di tracciare quali siano le applicazioni RPA che interagiscono esclusivamente in modalità static read.

  • contratti legacy

Cosa qualifica un utente “named user”? Anche qui bisogna prestare attenzione al contratto che è stato stipulato, soprattutto se antecedente al nuovo modello di licensing. Alcuni contratti possono specificare che un utente è un utente “umano”, altri no.

Un cliente può decidere se mantenere il contratto legacy (se il numero di licenze concesse per utente copre gli usi da parte dei bot) oppure se aderire al nuovo modello Digital Access, in cui il numero di licenze indirette viene concesso sulla base della stima del numero di documenti prodotti.

Ma se il software viene dato in licenza tenendo conto un numero di licenze per utente e il contratto di licenza prevede solo utenti “umani”, l’uso della licenza da parte di bot RPA può esporre l’azienda a costi di licenza inaspettati e al rischio di sanzione.

RPA e SAP®: cosa fare

Queste situazioni “a rischio”, che non sono sempre ben definite, richiedono da parte dell’azienda una conoscenza approfondita del proprio ambiente e della contrattualistica SAP®. Quattro sono gli step che consigliamo di eseguire:

Strategia SAP

1. valutare tutte le applicazioni di terze parti interne ed esterneche accedono a SAP®

Questa analisi deve tenere conto dei seguenti elementi:

  • tipologia delle applicazioni RPA (sono attended/unattended?)
  • riconciliazione con gli utenti (se sono bot che agiscono in presenza dell’utente, sono già coperti da una licenza nominativa?)
  • comportamento dei bot (effettuano una lettura statica oppure compiono azioni che comportano un’elaborazione/aggiornamento dei dati all’interno del software SAP?)
  • quantità e tipologia dei documenti che producono

 2. verificare la conformità delle informazioni raccolte con il LAW e la contrattualistica in essere

Una volta raccolte queste informazioni, bisogna verificare se quanto dichiarato nel LAW (License Administration Workbench) consegnato a SAP in previsione dell’audit risulta essere corrispondente al vero.

Questo processo richiede anche l’analisi delle condizioni contrattuali definite con SAP®. Per poter effettuare questa comparazione in tempi rapidi e senza errori, ci vuole l’ausilio di strumenti SAM (Software Asset Management) certificati da SAP® e integrati al suo ambiente.

Snow Optimizer for SAP® rientra in questa categoria ed è in grado di dimezzare i tempi di produzione dei report da 6 mesi a mezza giornata.

3. negoziare da una posizione di forza

Con queste informazioni a disposizione, è possibile identificare duplicati, irregolarità, scoperture e risultare sempre conformi. Ma il vantaggio più importante è poter negoziare le licenze SAP® da una posizione di forza: la chiara conoscenza della situazione tecnica e contrattuale è determinante.

Grazie ad essa, infatti, il cliente, può decidere se mantenere il contratto legacy già stipulato (se il numero di applicazioni RPA può essere soddisfatto con le licenze utente già concesse), mantenendo lo status quo, oppure se aderire al nuovo modello Digital Access e avere già una stima precisa dei documenti prodotti, comprese le transazioni/interazioni effettuate dai bot RPA.

4. inserire il tema in una visione a medio-lungo termine

È vero che il cliente che non ha ancora attivato progetti RPA può mantenere lo status quo a livello contrattuale, ma per garantirsi le migliori condizioni future dovrebbe essere in grado di prevedere il possibile impatto di RPA sui suoi sistemi. Nel breve, ma soprattutto nel medio e nel lungo termine.

È per questo che nel determinare il modello di licenza più adatto consigliamo alle aziende di fare un’analisi dell’impatto di RPA sulle licenze. NETCOM è un’azienda di consulenza con un’esperienza pluriennale nella gestione delle licenze e dei contratti SAP, per cui se hai bisogno non esitare a contattarci.

Ne abbiamo parlato nel webinar “SOS licenze SAP“, dove abbiamo fatto il punto sullo stato dell’arte del licensing SAP tenendo conto l’imminente (per molti) consegna del LAW e (per tutti) la scadenza dei termini di adesione al DAAP.

GUARDA IL WEBINAR

*SAP® e altri prodotti e servizi SAP® menzionati sono marchi registrati
di SAP SE (o di una società affiliata a SAP®) in Germania e in altri paesi.

1 commento su “I rischi della Robotic Process Automation (RPA) sulle licenze SAP®”

  1. Pingback: Come abbiamo ottimizzato la verifica della compliance delle licenze SAP

I commenti sono chiusi.