GDPR triggers behavioral transition as consequence of the principles of data protection (privacy) by design and by default – Part 1
(SAP Activate is a very good framework to incorporate GDPR)
Would like share some observations and reflections gathered up on the course of preparation to GDPR enablement project. Trying to map onto right level and scale of change as described here:
I have found that the most accurate level of IT organizational change will be “transition enabling operational change” (item no. 5 on the list).
So not only technical transition of a kind like from on-prem to cloud outsourcing – this will be much more like moving to shared service center with some impact on many business processes by making them much more formal and structured.
The “transition” seems to be quite clear but what it can be in context of behavior? In this particular case it means: we all, especially all stakeholders of an organization, need to upgrade our recognition and respect considering personal data. It most likely clean desk policy – like if you go out for a while lock your screen and put all documents into a drawer. Now we need to upgrade out thinking and behaviors of this kind by taking care of personal data.
Next it is worth considering which approach is the best to implement and which attempt to Organizational Change is the most optimal. GDPR gives in many areas not very clear pieces of advice, they are more towards “keep on doing” instead of “having done”.
Every organization is unique and data may cruise (be processed) in a very unformal way like CVs of candidates mentioned in the previous article that are shared in an uncontrolled way as emails attachments or hard copies. In this particular case it was difficult to evaluate and design all the needed changes within conservative waterfall approach in advance so the incremental approach seems to be more promising and can bring a lot of positive side effects.
Definitely what GDPR brings is a kind of delta to still valid DPD (plus local regulations). It can be introduced incrementally and then continuously maintained the same way. So, in other words it cannot be even a project but just continues service change (ITIL-ish) as a way to get and persist GDPR compliancy. Nevertheless, there are great reasons to do it in a way of project.
Coming to SAP projects SAP Activate seems to be very good framework to incorporate GDPR especially in context of by design and by default principle.
I have made a kind of interesting observation here trying to throw the GDPR activities onto SAP Activate map. I started with “System & Data Migration” Workstream just to realize that this is not adequate. I found that Application: “Design & Configuration” Workstream is much more suitable. Especially in view on the “Fit-to-Standard Analysis” where standard should be GDPR treated as a template.
The above observation shows in some extent that GDPR is more about “protection” and not “data” itself. Personal data is quite clear defined and obvious so the main effort here is about how to protect it. With modern IT systems like SAP the technical protection is on place so the area still waiting for redesign is behavior of the people around.
Going one step further I would consider two approaches:
a) if GDPR is a part of implementation project (like S/4HANA migration) it is worth creating additional “GDPR” work stream and it makes sense to make a copy of “Design & Configuration” in the first step.;
b) GDPR as a separate project with SAP Activate tailored to the scope of GDPR and with GDPR as a kind of template.
Anyway, if the project of migration to S/4HANA is on the way this is the best environment and conditions to include GDPR at almost no additional cost as there are many synergies between data migration (including platform transition) and GDPR.
I will continue soon towards SAP Activate extension and an extension of data governance…
Will talk about on: https://wiki.scn.sap.com/wiki/display/events/SAP+Inside+Track+Wroclaw+2018