Nell’ultimo blog di questa serie vi ho parlato delle aspettative dei consumatori in merito al trattamento dei loro dati da parte delle aziende, in particolare in riferimento agli accessi “guest”. Quando verranno rimossi definitivamente i dati?
Chi avrà accesso prima che ciò avvenga? Con che livello di sicurezza vengono conservati i dati?
I dati degli ordini di utenti “guest” sono solo un esempio di quello che potremo definire un “debito di privacy” che riguarda i dati accumulati, insito nella maggior parte dei sistemi ERP. Si tratta di dati conservati senza una palese motivazione legale, e che generalmente non sono stati eliminati solo perché ripulire il sistema ERP da questi dati risulta troppo complesso. Lo stesso potrebbe valere per i sistemi CRM; ma nella maggior parte dei casi questi sono progettati con la consapevolezza che alcuni dati sono per loro natura temporanei e pertanto i sistemi CRM includono meccanismi per rimuovere i dati non più necessari.
I sistemi ERP, e di certo SAP ERP, si fondano invece da sempre sui principi opposti, ossia piena integrazione e tracciabilità costante di tutti i dati. Ho espresso questo concetto nelle primissime fasi di introduzione del GDPR e della sfida che esso poneva relativamente al “diritto all’oblio”. Ciò significa che la maggior parte delle aziende che utilizzano SAP si ritrovano con una quantità di moduli e dati che non possono nemmeno giustificare di avere ancora nei loro sistemi.
Naturalmente esistono anche altri esempi di “debiti di privacy” sui dati accumulati, che riguardano, ad esempio, i dipendenti che hanno lasciato l’azienda già da molto tempo. Meno stretto è il rapporto con l’azienda, più breve è il periodo per il quale i loro dati andrebbero conservati. Ne sono un esempio i collaboratori stagionali del commercio al dettaglio che potrebbero o meno tornare l’anno successivo, o anche le ditte esterne di cui un’azienda si avvale per progetti a breve termine.
Un altro esempio molto diffuso per i settori in cui acquisizioni e cessioni sono all’ordine del giorno, è costituito dai dipendenti/clienti/fornitori di attività liquidate già da tempo. O anche i dati contenuti in un sistema adottato nel quadro di un’acquisizione, ma che non è stato mai parte dell’attività acquistata. Dieci anni fa, quando si realizzava un’acquisizione, non ci si preoccupava più di tanto della questione della privacy. Il solo scopo del progetto era trasferire i sistemi e i dati necessari per lo svolgimento dell’attività e, a chi interessava se il passaggio coinvolgeva anche una piccola quantità di dati in più? Ai giorni d’oggi, nei progetti di fusione e acquisizione, la protezione dei dati è un aspetto da tenere rigorosamente in considerazione, esattamente come dovrebbe avvenire in qualsiasi altro progetto -
“By default e by design”.
Sono due le sfide principali associate alla rimozione dei dati dai sistemi ERP e in particolare da SAP:
Cosa sarebbe un blog SAP senza nemmeno un accenno a S/4HANA? In effetti, quando si avvia o si prepara una migrazione a S/4HANA, in genere si parla di pulizia e archiviazione dei dati. Ma non confondiamo queste semplici considerazioni con l’affrontare veramente il problema del debito di privacy sui dati accumulati. La pulizia dei dati raramente ha a che fare con l’eliminazione mirata di dati indesiderati, a meno che non si tratti di un progetto greenfield in cui questo debito che riguarda i dati accumulati può essere semplicemente ignorato. Normalmente si tratta di processi CVI (Customer/Vendor Integration) per i quali si procede ad eliminare i duplicati presenti nei dati anagrafici o a correggere errori di formattazione. Per i progetti brownfield l’archiviazione viene presa in considerazione per ridurre le dimensioni potenziali del futuro database di sistema, e il maggior risparmio di spazio si ottiene togliendo grandi quantità di dati transazionali piuttosto che di dati anagrafici obsoleti.
Se eliminando i dati accumulati che ci espongono a questo “debito di privacy” non si ottengono grandi risparmi di spazio, e comunque questa procedura comporta sfide anche più complicate, come il rischio di eliminare preziosi dati non sensibili come la distribuzione geografica dei clienti o le capacità statistiche di genere nello storico dei dipendenti, possibile che non ci sia un’alternativa valida? Se l’azienda interviene cambiando i dati per rimuovere gli elementi identificabili, il problema resta perché la modifica stessa viene tracciata. Se invece accediamo noi direttamente a livello di tabella e sostituiamo tutti i dati sensibili o identificabili, possiamo intervenire all’origine dei dati, anziché come modifica a partire da oggi.
Ma tutte le informazioni correlate che potrebbero ancora essere utili per la reportistica verrebbero mantenute. Anche tutte le dipendenze da relazioni chiave esterne nei dati transazionali e i riferimenti legati a dati anagrafici correlati (ad esempio, indirizzi, dati WSB, persone di contatto, ecc.) resterebbero intatti.
Qui vediamo lo stesso fornitore di prima, ma adesso i campi sensibili LFA1, LFB1, ADRC sono stati mascherati (redacted) in modo programmatico.
Con tutti i documenti di modifica eliminati (perché potrebbero contenere i valori originali)
In questo esempio, i dati anagrafici in KNA1, ADRC, ecc. che vengono aggiornati tramite XD02, sono visibili nella transazione Ordine di vendita (VA03) per la presenza del link nella tabella VPBA. In questo esempio non serve che apportiamo nessuna modifica all’ordine. Tutti i dati personali sono ripuliti. Le modifiche – simili a quelle che abbiamo fatto nel primo esempio per il fornitore, ma adesso riferite all’anagrafica clienti – garantiscono anche che gli ordini per quel cliente non mostrino più informazioni personali.
Nel blog precedente, mi sono soffermato sul topic degli indirizzi personalizzati o adattati nel quadro del processo di acquisto come “guest” o nel caso in cui l’indirizzo ereditato dal record anagrafico sia stato adattato per questo particolare ordine. Ora qui vediamo un record di indirizzo diverso collegato all’ordine in VPBA in cui, invece, abbiamo offuscato in modo programmatico quei dati in ADCR.
Abbiamo sviluppato un software che le organizzazioni possono sfruttare per eseguire internamente le operazioni di offuscamento, sia in risposta a specifiche richieste che nel quadro dell’applicazione automatica e periodica di un periodo di ritenzione. Offriamo inoltre servizi e indicazioni per assistervi nelle prime e più significative operazioni di “ripulitura” del debito di privacy che riguarda i vostri dati accumulati. Contattateci se desiderate ottenere l’assistenza dei nostri esperti.
Intervento minimo per soddisfare i requisiti di riduzione dei dati storici per finalità di compliance.