After reading Thierry Crifasi’s blog post The implementation of SAP Cloud for Customer: Forget all things SAP – Part I, Configuration, I thought to myself, “SAP Cloud for Customer appears to have a swift roll-out potential however, I wonder how the infrastructure performs under a typical migration exercise”. So I thought I’d put my assumptions aside and dive deeper.
Admittedly, prior to my first experimentation with SAP Cloud for Customer, I was extremely sceptical as to what this new Cloud solution could offer. For me, it didn’t only just tick all of the jargon boxes from a Dilbert cartoon (“it’s all Big Data, running on HANA and it’s all in the Cloud”), but I was also concerned that this Cloud solution couldn’t offer the variety and flexibility of the on-premise SAP CRM. This belief was partially due to the existence of current cloud solutions such as SalesForce, and also due to something which SAP unsuccessfully attempted to build an uptake in a few years ago; SAP CRM OnDemand.
One thing I love (and hate) about the on-premise solution is that almost everything can be changed. One thing I’ve noticed with SAP Cloud for Customer is that it’s restrictive than its older brother. Which begs the question: Before attempting to migrate data to Cloud for Customer, will I need to shoe horn my business data to match a so called best practice approach? My experience through this exercise was very interesting.
Flat file creation
In my previous experiences with data migration, the beginning of the project normally follows three high level footsteps:
- The data
- The format of the data
- Building the flat file
Breaking these points into manual processes of:
- Identifying the required fields in the UI and noting the technical names
- Interrogating the database to identify the data types
- Identifying the minimum data criteria to create a transaction or master data
- Building conversion rules in CRM or if needs be in the spreadsheet
- Build the field mapping in the data migrating tool
- Multiple test loads into CRM to iron out any mapping or conversion issues.
So off to a great start as SAP Cloud for Customer provides an Excel template to use for the migration process for all standard master data and transaction objects. What’s included is a user guide for the data types of each field as well the minimum requirement for a master data or a transaction. This means one major thing, the whole of the first step of data migration has been done! It even includes the field mapping and flat file entries for all new extension fields added to standard objects.
Loading the flat file into SAP Cloud for Customer is fairly similar to previous migration exercises. However one thing which I would have really appreciated in previous projects is the reconciliation.
What you can see in the above picture, is a short report informing you of how many records it has detected, as well as the ability to edit/delete individual records directly if needs be.
The migration tool provides the opportunity for you to see how many records it thinks it is loading and the ability to amend the data in the tool. Having the ability to preview the data from this high level is important as it can help identify misaligned data, as well as accidental blank data caused by any VBA programs which could be in play. On many data migration occasions, I have used VBA to perform the collating of data which will insert blank records at the end of the data set, this would have been a massive time saver!
With previous data migration exercises, time was taken manually validating data through pivot tables. This is an effective method as you can very clearly see fundamental issues with your data set. However, if you have a wide flat file profile, this can often mean building many pivot tables, identifying your fail case for each table, and then finally identifying your record set. This is another aspect which SAP has thought through with a “Convert Value” stage in the migration process.
This enables the user to convert erroneous values to system values en masse. This can be changed via the SDK, however future interesting experiments will be to see just how far it can be pushed.
It is worth mentioning that even though SAP Cloud for Customer provides a built-in user friendly data staging, transformation and loading tool for data migration against a set of business rule, some projects will undoubtedly prefer the functionality found in SAP BusinessObjects Data Services for building flat files and validating data. However, the fact that this is an out of the box tool providing these staging and transformation areas is impressive.
The final stage in the process is the simulation, where you can see any fundamental reasons for failure (e.g. overlapping number ranges), and then of course the load itself. Finally one of the most useful parts of this process is not unpicking idocs or interrogating the database to identify what has loaded, but instead a very handy migration report.
I started this blog post asking “will I need to shoe horn my business process to match a so called best practice approach?”
The simple answer is no, because what is actually delivered is what SAP set out to originally achieve, which is the automation of business processes. SAP Cloud for Customer has offered the standard data migration process a much faster way of getting your data into a state where it can actually load and a set of tools to visually identify where revisits are required. These are things which you would have had to spend valuable hours building, testing and deploying yourself. The ease of use comes from the extensive use of guided procedures and contextual help throughout the process. Something why I find very refreshing in comparison to using the GUI and hitting the F1 key!
Instead, this solution gives you more time to give value back to the business by making sure the collected data that supports the business objective.