En el blog anterior de esta serie, expliqué cómo esperan los consumidores que una empresa gestione sus datos, especialmente en el contexto del acceso de ‘invitado’. ¿Cuándo se eliminarán definitivamente esos datos?
¿Quién tendrá acceso a ellos antes de su eliminación? ¿Cómo se almacenan los datos de forma segura?
Los datos de pedidos de ‘invitados’ son tan solo un ejemplo de la ‘deuda de privacidad retroactiva’ que reside en la mayoría de los sistemas ERP. Se trata de datos que claramente no tienen motivos legales que justifiquen su conservación y que, por lo general, no se han eliminado debido a la complejidad de purgar estos datos en el sistema ERP. Esto también podría aplicarse a los sistemas CRM, aunque en la mayoría de los casos estos se han diseñado teniendo en cuenta que algunos serán temporales e incluyen mecanismos para su eliminación cuando ya no sean necesarios.
Los principios básicos de los sistemas ERP, y desde luego de SAP ERP, eran en realidad opuestos: plena integración y trazabilidad de todos los datos en todo momento. Me refería a esto cuando se implantó por primera vez el RGPD y el reto que suponía para el ‘Derecho al olvido’. Esto significa que la mayoría de las empresas que utilizan SAP acumulan algunos datos cuya permanencia en sus sistemas es sencillamente injustificable.
Naturalmente, también hay otros ejemplos de ‘deuda de privacidad retroactiva’, como los empleados que dejaron la organización hace tiempo. Cuanto más laxa sea la relación con el empleado, menor será el periodo durante el cual debemos conservar sus datos. Podrían citarse como ejemplo los trabajadores temporales de los sectores minoristas que pueden volver o no al año siguiente, o los contratistas que se han contratado para un proyecto específico a corto plazo.
Otro ejemplo típico de sectores en los que las adquisiciones y desinversiones son frecuentes es el de los empleados/clientes/proveedores que forman parte de una empresa que se vendió hace mucho tiempo. O incluso los datos de un sistema que se adoptó como parte de una adquisición, pero que nunca formó parte de la empresa adquirida. Hace diez años, cuando se realizaban adquisiciones apenas existía concienciación sobre la privacidad de los datos. La transferencia de sistemas y datos necesarios para el rendimiento de la empresa era el único objetivo del proyecto técnico y si se incluían algunos datos adicionales, ¿a quién le importaba? Ahora los proyectos de fusiones y adquisiciones deben tomarse muy en serio la privacidad de los datos, al igual que en cualquier otro proyecto: ‘Por defecto y desde su diseño’.
La eliminación de datos de sistemas ERP, y en particular de SAP, plantea dos grandes retos:
¿Qué sería de un blog de SAP si no mencionara S/4HANA? Pues bien, al emprender o preparar una migración a S/4HANA, se suele plantear tanto la limpieza como el archivado de datos. Esto no debe confundirse con la gestión de la deuda de privacidad retroactiva. La limpieza de datos rara vez se ocupa de la purga de datos innecesarios, a menos que el proyecto sea un escenario nuevo en el que esta deuda retroactiva pueda simplemente dejarse atrás. Por lo general, se trata del proceso de integración de clientes y proveedores y de la eliminación de la duplicación de registros maestros, o de la corrección de errores de formato. En proyectos con infraestructura previa, el archivado se contempla para reducir el tamaño potencial de la base de datos del futuro sistema, y la mayor parte del ahorro de espacio se consigue eliminando grandes cantidades de datos transaccionales en lugar de datos maestros históricos.
Si la depuración total de nuestra deuda de privacidad retroactiva no supone un gran ahorro de espacio y el proceso plantea muchos y difíciles retos, además de la posible eliminación de datos valiosos no confidenciales, como la distribución geográfica de los clientes o la capacidad de elaboración de informes por género de los empleados históricos, sin duda hay una manera mejor. El problema de dejar que la empresa se limite a cambiar los datos para eliminar los valores identificables es que el mismo cambio es objeto de seguimiento. Si en cambio nos dirigimos al nivel de tabla y reemplazamos cualquier dato confidencial o identificable, podremos hacerlo desde que los datos existen, no será un cambio a partir de hoy.
Ahora bien, toda la información adyacente que puede seguir siendo útil para la elaboración de informes podrá conservarse. Y cualquier dependencia de las relaciones externas clave en los datos transaccionales, o incluso las referencias de los datos maestros relacionados (por ejemplo, direcciones, datos de estructura de descomposición del trabajo (EDT), personas de contacto) seguirán intactas.
En este caso vemos el mismo proveedor que hemos analizado anteriormente, pero ahora se han redactado los campos confidenciales de LFA1, LFB1 y ADRC mediante programación.
Todos los documentos de cambios se han eliminado (ya que los valores originales pueden seguir estando ahí).
En este ejemplo, los datos maestros de KNA1, ADRC, etc. que se actualizan a través de XD02 pueden verse en la transacción de pedidos de venta (VA03) debido al enlace en la tabla VPBA. En este ejemplo, no es necesario realizar ningún cambio en el pedido. Todos los datos personales son transferidos. Por tanto, los cambios, similares a los realizados en el primer ejemplo respecto al proveedor, ahora se realizan en los datos maestros del cliente y garantizan además que los pedidos de ese cliente ya no muestren valores de datos personales.
En el blog anterior, me centré en el tema de las direcciones personalizadas o a medida, ya sea como parte de un proceso de compra de ‘invitado’ o cuando la dirección heredada del registro de datos maestros se ha adaptado para este pedido específico. Ahora vemos un registro de direcciones distinto vinculado al pedido en VPBA y, en su lugar, esos datos se han redactado en ADRC mediante programación.
El reto de configurar sus propios programas de redacción es la cantidad de lugares en los que pueden residir los datos. Encontrarlos todos es posible, pero es algo que debe revisarse también si los procesos empresariales cambian y se actualiza SAP en el futuro. Algunos ejemplos son:
Hemos desarrollado un software que las organizaciones pueden utilizar directamente para realizar sus propias redacciones, ya sea de forma interactiva a peticiones individuales o como parte de una aplicación periódica automática de un período de retención. También ofrecemos servicios y asesoramiento de ayuda para la gestión de una importante depuración inicial de la deuda de privacidad retroactiva. Si desea recibir asistencia de expertos, póngase en contacto con nosotros.
Se trata de realizar unas actividades mínimas para cumplir con los requisitos de minimización de datos históricos a efectos de cumplimiento de la normativa.