Ignoring Data Quality on an SAP Migration - What are the pitfalls of ignoring best-practice?
Tuesday, August 5 I'm
just starting on a project to replace our banks core transactional
system, along with a number of subsystems. We are currently in the
initial stages of determining our data migration strategy to move data
from these legacy systems into the SAP banking platform.
As we
determine our strategy to do this we are trying to justify the
importance of data profiling, data quality, etc. We are receiving some
resistance in regards to the necessity of doing this work. The
consulting company we have hired has suggested the approach of simply
migrating the data and letting SAP take care of the DQ issues.
We
are trying to build a case around the importance of performing data
profiling, data cleansing, data quality, etc as well as using a toolset
to assist us in this work. In our research and talks with various
vendors we have been getting a lot of warnings and horror stories about
moving dirty or bad data into SAP and more importantly how hard this is
to rectify or remove once it has been migrated.
Aside from the
obvious reasons NOT to move dirty or poor data into the new system, are
there any resources or information about the pitfalls of doing this
with SAP and how difficult it is to resolve once the data has been
migrated?
Any information would be greatly appreciated!
Thanks!
Reader Comments (4)
This is a really tough question, which is truly unfortunate.
I mean, is there a reason pharmaceutical companies first test drugs on rats before giving them to the patients. Why bother with all the costs and hassle? After all the mad professor who designed the medicine is pretty certain it will work.
Or, is there a reason to check planes before every flight. Keeps passengers waiting, drives them crazy. Why bother? Hadn't the plane just arrive safely? It must be fine.
The reason we do it is because the cost of not doing it is prohibitive (in money and other values).
The horror stories you have heard about data migrations are all true. It is not just because the source data is bad, but simply because you have no way of knowing what it really is. The legacy systems are black boxes, with real data far different from what you expect it to be. Without data profiling and data qualtiy assessment the conversions from legacy systems often fail miserably. The data quality typically deteriorates. The consequences may be unbearable.
Here is the Catch-22. Your management may not listen to you under the premise: "our data is fine and we do not have time and budget to monkey around with it". The famous last words...
The only way to really prove them wrong is either to perform data profiling/data quality assessment, or to do the project without it and probably add your story to the horror library.
This is not really specific to SAP conversions, but common to all conversions, especially conversions from legacy systems. I have written some about it in various articles and in my book (you can find a few links on my website) and banged my head at the wall quite a bit. But at the end of the day, unfortunately I never found reasons beyond obvious.
Arkady Maydanchik
Data Quality Group
www.dataqualitygroup.com
This issue is at the very heart of why the data migration failure rate is so high.
Here we have a company who has quite rightly sought the assistance of a specialist consultancy who is now advising them to “fix it in the target”.
For me, this is why Data Migration Pro was created, to prevent this type of situation arising.
Arkady has summed this up perfectly.
Sometimes things are so obvious it beggars belief that consultancies can simply ignore the wealth of experience, research and sheer common sense in favour of what are perceived to be quick wins.
Now that my anger has subsided, let’s take a step back and focus on what really matter – customers and profits.
The business has taken the decision, rightly, to consolidate their legacy landscape for a unified platform (SAP). They have probably done this for some of the following reasons:
• Time – they want to deliver new services faster and they also want to reduce existing lead times on services and internal processing
• Income – they want to identify ways of cross-selling, up-selling and generally accelerating and increasing revenues
• Risk – Having distributed systems with variable quality makes risk management and corporate governance a nightmare, consolidation helps reduce this risk
• Expenditure – Lots of systems, complex processes, manual hand-offs – all add up to increased operating costs, moving to a unified platform can cut labour costs, license and infrastructure costs dramatically
So, your data migration project has to guarantee that these conditions will be met.
If it doesn’t, it has NOT BEEN SUCCESSFUL.
I cannot stress this point enough, if people in your organisation or the consultancy believe that shunting dirty data from point a to point b means migration success the project will fail.
So the first thing I would do is clarify what the business wants to achieve with SAP (eg. greater automation, better reporting, single customer view, faster lead-to-cash, compliance, SOX, cross-selling/marketing etc.).
These are your performance measures which will be impacted by a cavalier approach to DQ.
You are also moving data from a legacy environment to a new target environment. This will actually require INCREASED levels of data quality to support the new services, so the fact that your organisation has no idea whatsoever of the levels of current quality means that the final level of quality will probably be far lower than required to support these new services.
Additionally, because you are linking systems together there is a major chance the data might not be able to physically migrate.
(In a recent engagement I analysed the levels of quality in 3 legacy systems. All were reasonably good in the context of their own legacy business services. When correlated together with the target in mind, we found that less than 5% of the data could be migrated without significant DQ improvements. Ironically the customer had refused for several months to carry out data quality analysis but once they had seen the results they were extremely grateful. It meant that we could plan a more appropriate route forward).
So, the consultancy in charge of your migration should be identifying what business services you wish to achieve with the target environment and analysing the data quality levels against those measures. This should have been done way before implementation because you need this knowledge to plan your strategy.
Ironically, another member asked us how to critique service providers (see the earlier blog post). In my comment there is a checklist, you will see that providing an approach to DQ occurs at several points. The consultancy on this project would have failed the assessment.
In the meantime, the survey in the following link highlights some of the common failure points in migrations, DQ is one of the most prevalent: http://www.bloor-research.com/research/survey/876/data_migration_survey.html
I will follow this situation closely and ensure you get the appropriate advice moving forward.
There is a good deal of synergy between this question and an article I wrote for DM Pro:
Problem with Data Migration Scoping
Within it I thoroughly recommend the approach you are already taking. There is a clear pitfall for some data professionals in making a business case in partially technical terms.
Instead the business consequences of failure should be starkly expressed in terms the business will understand as direct impacts of a systems failure. I list some of these in the article and have added some more below:
Worst Case:
In a “big bang” single migration and turn on event there will be a go/no-go decision. Of these the single biggest danger to the business is to select “go” with flawed data. This will cause the business to restart and new transactions to become laid down over the migrated information and worse new data will become intermingled with the old. That will be compounded by the very benefit the SAP system introduces, which is to link business areas more thoroughly than before in concepts such as a single end to end view of the supply chain. So that the ‘infection’, if I may call it that, will run through and/or disrupt the new joined up processes causing difficulty not just in the area of impact but across the organisation.
This leaves a “broken” business in terms they would understand where an entire process flow can grind to a halt causing extensive periods of non supply and customer dismay. Unfortunately the business cannot go back to the old system without discarding and re-entering every transaction created during the malformed start up period. They may struggle on in the new but there will be operational consequences such as having to terminate processes while the data is fixed so that no more is added Sorcerer’s Apprentice style to the issue. (Those data buckets just keep on coming!)
I am aware of a specific instance in which one of UK’s largest manufacturing companies executed a ‘go’ with a flawed MRP system and were unable to ship any stock from that division for an entire month. I mean literally zero trucks came and went. In a weaker player with less unique market offerings customers would have gone elsewhere triggering complete organisational failure.
I hear the word “bank” in your question so you won’t be doing MRP (manufacturing). But consider instead being unable to sell or manage a complete class of financial products because doing so would drive the data problem deeper, make it harder to fix or impossible for the bank to lay off to the wider market because the interfaces involved will not transmit the information without error. If that analogous situation to a supply chain failure occurs (let’s call it an “information chain failure” instead) the products may have to be suspended completely while the system is fixed.
Second Worst Case:
Final trials fail and overrun because the data will either not load or breaks processes. It becomes clear that a ‘no-go’ must be called. What is the direct financial impact? One very easy way to model this is to take the project contractors workforce, say 30 people and multiply that by their rate, say £800 times an entire quarter, as in a bank there is no doubt you would wish to align go-live to a financial reporting boundary and there is only one every 3 months. 60 days x 30 consultants x £800 = £1.5 million. Add the permanent staff secondment and backfill costs and you are well on your way to £3M to 5M, because not enough preventative care was taken on the data at the outset. ...Which would have cost how much in comparison?
SAP “Gung-Ho” is bad in several areas, not just in data:
Although we like to think “it’s always us” in data migration that carry the risk, your gung-ho client should similarly take care to ensure training, interfaces and IT infrastructure are all in place as well, as these are approximately culprits 2, 3 and 4 in ERP failures – which is easily achievable if a go/no-go becomes subject to group think or wishful thinking.
I can’t overemphasise how dangerous ERP projects are. When they go wrong they can cause entire stock market listed companies to dip and fail or become subject to takeover.
And finally:
My parting word is much as the first. Keep talking business consequences and processes. Avoid dipping into your home ground of systems, tables, keys and so on. IT is not the domain where the consequences of failure are most keenly felt.
John Platten
Principal Consultant
Vivamex Limited
www.sapdatamigration.co.uk
Stephen Mills says...
Posted 13 August 2008
I would start with some along the lines of a "Preliminary Data Assessment" that would assess your source systems data, execute a target assessment and then produce some level of harmonisation reports.
This would provide you with an early indication to the quality of your existing data and how much time and effort you need to apportion to cleansing and standardising your data. It also provides you with a better insight into the challenge that lies ahead and helps build your case with the business - you'll have some hard evidence to put in front of the stakeholders!
How to execute this? Well it should be done as part of the blueprint phase of the project. If you don't have a enterprise wide integration tool yet then a number of the vendors would execute this assessment as part of a sales cycle in order to provide you with early visibility of their tools.
Stephen Mills
IBM Global Business Services