（SAP Activate是整合GDPR的一个非常好的框架）

希望分享在GDPR支持项目准备过程中收集到的一些观察和思考。试图映射到这里描述的正确的变化水平和规模：

https://blogs.sap.com/2018/01/29/change-management-transition-transformation-and-level-of-disruption-in-sap-projects/

我发现，IT组织变革的最准确级别是"支持运营变革的转型"（列表中的第5项）。

所以不是只有从prem到云外包这样的技术转变——这更像是转移到共享服务中心，国内云服务器，通过使许多业务流程更加正式和结构化，对其产生一些影响。

这种"转变"似乎非常清楚，物联网操作系统，但在行为的背景下，它可以是什么？在这种特殊情况下，这意味着：我们所有人，尤其是一个组织的所有利益相关者，需要在考虑个人数据的情况下提升我们的认可度和尊重度。这很可能是清洁办公桌的政策——比如你出去一段时间，锁上屏幕，把所有文件放进抽屉里。现在我们需要通过关注个人数据来提升这种思维和行为。

接下来值得考虑的是，哪种方法最适合实施，哪种组织变革尝试最适合实施。GDPR在许多领域给出的建议不是很明确，淘客文案，他们更倾向于"继续做"，大数据时代是什么意思，而不是"已经做了"。

每个组织都是独一无二的，数据可能会以非常不正常的方式进行处理，就像前一篇文章中提到的候选人简历，以不受控制的方式作为电子邮件附件或硬拷贝共享。在这种特殊情况下，很难在保守的瀑布式方法中预先评估和设计所有需要的更改，因此增量方法似乎更有前景，并且可以带来许多积极的副作用。

GDPR带来的肯定是一种仍然有效的DPD的增量（加上当地法规）。它可以增量引入，然后以相同的方式持续维护。因此，换句话说，它甚至不能是一个项目，物联网技术，而只是继续服务变更（ITIL ish）作为获得和保持GDPR遵从性的一种方式。尽管如此，还是有很多理由以项目的方式来做这件事。

来到SAP项目SAP Activate似乎是一个很好的框架，可以将GDPR融入其中，特别是在按设计和默认原则的背景下。

我在这里做了一个有趣的观察，试图将GDPR活动放到SAP Activate地图上。我从"系统和数据迁移"工作流开始只是为了意识到这是不够的。我发现应用程序："设计与配置"工作流更合适。特别是在"符合标准分析"中，标准应被视为GDPR的模板。

上述观察在某种程度上表明，GDPR更多的是"保护"而不是"数据"本身。个人数据是非常明确的定义和明显的，所以这里的主要工作是关于如何保护它。对于像SAP这样的现代IT系统，技术保护已经到位，所以仍在等待重新设计的领域是周围人的行为。

更进一步，我会考虑两种方法：

a）如果GDPR是实施项目的一部分（如S/4HANA迁移），那么创建额外的"GDPR"工作流是值得的，而且在第一步复制"设计和配置"。

b）GDPR作为一个单独的项目，SAP Activate根据GDPR的范围定制，GDPR作为一种模板。

无论如何，如果迁移到S/4HANA的项目正在进行中，这是在几乎不增加任何成本的情况下包含GDPR的最佳环境和条件，因为数据迁移（包括平台转换）和GDPR之间存在许多协同效应。

我将很快继续进行SAP Activate扩展和数据治理的扩展…

将讨论日期：https://wiki.scn.sap.com/wiki/display/events/sap+Inside+Track+Wroclaw+2018年