Why has SAP been so successful for so long? Because they designed a massively powerful – and scalable – ERP system, which could be installed from the same CDs/DVDs/Files (delete as appropriate depending on your age) at almost any organisation in the world. From there it could be quickly/slowly/glacially (delete as appropriate depending on your industry/project scope etc) tailored to fit a very wide variety of business processes, just by making settings in the IMG. No need for custom code or tables in the database unless you really wanted to bring your own processes to the system, and even that wasn’t too hard to do.
Read on to find out about:
Many years ago, when we decided to go beyond copying one or two data types with Data Sync Manager 2, our clever developers realised that hard coding what data should be copied would limit our ability to grow with SAP. And so they developed the Business Object Workbench (BOW) as a repository where we could define ‘objects’, customers could extend those delivered objects (e.g. adding Z tables), or even define their own objects. They then built an engine that could copy an ‘instance’ of the object from one system/client to another. Over the years, more engines for Data Sync Manager have been added, and they can all use the objects defined in the BOW (of which there are now over 1000 delivered by us).
So when GDPR landed on our desk and we wanted to provide the functionality for disclosing and redacting data, we weren’t building on a completely new foundation. We leveraged the Business Object Workbench and a particular DSM engine: Data Secure, which is used to mask test systems. It has to use a mapping database to make sure that when an instance of a Customer master in ERP is masked to a new value, the corresponding instance of a Business Partner in CRM gets the same new value. That means a capability to index and look up instances of data. Data Disclose then has the logic from the Business Object Workbench to be able to relate the data – e.g. is this Address for a Business Partner or a Customer – and find the key of the instance it relates to for disclosing that data and/or queuing it up for redaction.
For a time this dependence upon the core of DSM was inhibiting because it meant we couldn’t move as quickly on our SAP GDPR apps as we wanted to, because we needed releases of DSM to carry the functionality to the customers. But now we’re really seeing the benefits of leveraging that technology. When a customer has extended a business process with their own tables, it is very simple to add their Z/Y tables to our objects and integrity maps that link all the places a semantic type of data is used. In some cases, they may have a completely bespoke process where we need to define a custom object in the Business Object Workbench so that it can be available to be configured in Data Disclose and Data Redact but it’s a very quick job. This flexibility wasn’t an afterthought.
DSM was specifically designed to cater
for the fact that SAP can be customised
in an almost infinite amount of ways.
A recent example of this is for our client MAPA, which is part of a group of companies which share the same SAP systems. They have a completely bespoke ordering process for babies’ dummies (known as pacifiers in the US). This allows someone to go online and choose bespoke images and colours, or even upload images to be printed on the dummy, potentially along with the baby’s name and or/date of birth. See the first video here. Although the data is stored in SAP, its not a standard customer master and some of the additional information is stored in a combination of custom and standard SAP tables. We were quickly able to build a new Legal Person Type and link it to a new custom business object for the ‘One time orders’, and make this available for Data Disclose. We were also able to use Data Redact for sensitive data including names, email addresses, dates of birth and more.
There were also custom tables used to store employee information, such as the use of a cashless canteen system which we included in Data Disclose and Data Redact. And we added some more common requirements like summarising the amount of pay history stored for someone.
As these additional requirements came from the users testing the solutions, it was not a problem for us to add them. This wasn’t luck, this was because the underlying DSM base that our SAP GDPR apps use was specifically designed to be extended and added to on customer sites. It provided a lot of the linkages I needed to leverage already, such as joining address records to orders.
MAPA was kind enough to present their project for our German user group event, and on the day presented me with this:
My very own custom-made dummy with a Redacted name and date of birth!
If you would like your own more personalised version, they’re now also available via Amazon.