I have been delivering SAP Data Migration projects from Design phase to Deployment phase and for last 8 continuous years on Australian clients. These clients have been in Mining, Industrial Gas manufacturer, Banking, Operations, maintenance and construction services business and couple of Government organisations. During these 8 years I have had a varied but enriching experience on Data Migration challenges. If I try to draw out a common trend of challenge across all these places, one things was uncannily coming out stark - How do we build predictability, repeatability in exposing legacy data to the business so they can take corrective actions well in time for the Cutover into the target SAP system.
I will try to walkthrough the process I have used and I am not, by any means, stating that this is the best approach but something that has worked for me. I will be keen to get responses in this forum from others who have done different and this will help us all grow as consultants helping the clients achieve their goals and outcomes.
The challenge with Data Migration project is multi-fold, as many would agree. Key questions to answer would be -
1) What is the Data Migration schedule and how does it fit in the overall Programme Schedule?
2) Which business teams will be involved and how?
3) What is the scope of Data Migration? How many Data Objects?
4) What is the Trial Conversions schedule, how to manage delivery in each Trial Conversion?
5) What is the objective of each Trial Conversion?
6) How to build detailed workplan for each Trial Conversion and how to manage and control this plan?
7) How to report Data Migration progress to the Programme Management?
I will focus on some aspects of the above questions and try to illustrate how I have managed the answers to these questions.
As a SAP Data Migration project manager, I typically start with understanding how the overall go-live is scheduled in the Programme level Planning documents. Data Migration should typically cover Trial Conversion schedules at high-level identified in this plan document. There should be a few Trial Conversions atleast before the User Acceptance Testing and Go-Live. Once I have understood this timeline, I jump on to understand what is the Design, Build, Test phase of the core solution on which the Data will be migrated to. Data Migration will depend heavily on the core solution design, build and test completions. A typical challenge I have encountered in this space has been the staggered core solution delivery thus making it more complex for the Data Migration. As if that was not enough, Data Migration schedule almost runs in parallel to the core solution!! There is no straight answer to the above challenge and I have worked out various surgical ways out when delivering a SAP Data Migration on a staggered core solution. This is another whole discussion in itself.
When I have focussed on the Scope of Data Migration, I have developed a inventory list of what data objects are needed by the business to get their business running smoothly on the target SAP system. This would typically comprise of but not limited to Materials, Vendors, Customers, Assets, Projects, WBS and transactional data like Accounts Receivable, Payable, GL Balances etc. As you have more meetings with Business teams and using relevant tools to data profile the legacy system, you would start compiling and enriching this inventory list with volume of data expected to migrate, source data information etc. This information is key to planning and strategising Data Migrations. These will either fed into or will be a validation of the Data Migration Strategy document.
I have often built a dependency chart for these Data Migration Objects from the inventory list. This will not only help you but the entire programme management to identify and understand dependencies within the data objects and the sequence of data loads. The most important outcome of this that I have extensively focussed on is the Critical Path. To illustrate this I have a partial snapshot of one of my dependency chart. You can then derive the critical path from the dependency diagram and be able to focus on this path to manage schedule during Trial Conversions.
Then comes the Trial Conversion detailed workplan. As a SAP Data Migration project manager I am a strong believer in developing detailed workplan in MS Project. This is extremely handy to get details out of the several hundred tasks to manage in Data Migration, to develop What-If scenarios of schedule impact due to new / existing programme level constraints etc. It also helps develop reporting progress to the stakeholders. When I start developing a detailed workplan, I often do not have anything but the Data Migration Object Inventory List and the dependencies. But I have always gone ahead and built this and progressively you can achieve a much detailed work plan to be ready for Trial Conversions. Snapshots of one of the Project Plan I had developed is as shown here -
The detail within each data object may look like this, which typically covers for me, the ETLR(Extract, Transform, Load, Reconcile) processes, resources, durations and any other tasks which are needed to load the data object.
In the next blog, I will explain more on how to monitor, control this project plan during Trial Conversion, how to report on it, how to leverage this project plan on the reporting aspect and what pitfalls to avoid during Trial Conversions. Watch this space...
- SAP Managed Tags:
1 Comment
