Author: gerard

It appears to be an unalterable truth: in SAP Programs, the Data Management team is red, going red, or not reporting status accurately. Why is that, and what can you do about it?

What is Data Management?

In SAP programs, there is usually a Data Management team responsible for some combination of transformation tasks, specifically:

• Master Data Design: the definition, data model and architecture for things like customer data, vendor/supplier data and material/product/item data.
• Data Migration or Conversion: orchestrating and developing tools and programs for moving and transforming data to the new systems
• Data Cleansing: standardizing, correcting, verifying and enriching existing data before loading them into new systems.
• Master Data Governance: design of the processes and organizational constructs to maintain and manage quality of the master data

The team may go by different names like Master Data team, Data Conversion Team, or the Team-Causing-Most-Defects. The team’s responsibilities may be some variation of the above and may also include things like Data Verification or Validation.

Unique Data Management Challenges

So, why is the Data Management team always behind? In a future series of articles, I will explore some of the unique challenges of Data Management. I know of no silver bullet, but we can take action to prevent Data Management to become cause for delay. Or to turn things around if it already has.

Shared Responsibilities

The organizational principal of unique, unambiguous responsibilities is difficult to establish between the Data Team, Functional or Process Teams, and business data owners.

Cross-Team Task Management

Many Data Management tasks and deliverable require collaboration, but they show up in one team’s work plan or task list. As a result, collaborating teams will prioritize the task differently. Specifically, the Data Team may find themselves begging for time from a Process Team to get ‘their’ assigned functional specification or data design document completed.

High Degree of Inter-Dependencies

When the rubber hits the road during a Mock Cutover, dependencies between data loads lead to a cascade of decreasing success. For instance, if the Customer Data load is 75% successful, the success rate of Customer Specific Pricing load may only be 40%, leaving the Sales Order load with a meager 15% success.

Latest Start, Earliest Finish

Functional Teams will require to have some level of process / solution design done before they feel they can write meaningful specifications for data conversions. At the same time, the converted data is required to do meaningful testing, so the programs and data have to be ready even before the functional solution is ready to test.

Extremely Expensive to Test

A fully orchestrated test conversion is too expensive and time consuming to do too often. It is also very visible. Consequently, when doing one, expectations should be managed and the team should make it count.

What To Do About it?

Preventing or resolving issues caused by these challenges is doable but will take some work – no silver bullets. In summary:

• Don’t expect it to solve itself: These team dynamics are complex and not intuitive. It will take a leadership effort to get everyone to understand how they will work together.
• Focus on Data Management leadership: it takes a special type of talent and empowerment to unleash the unique collaborative micro-management work required.
• Duplicate Data Management work plan tasks and deliverables: when a collaborative tasks is behind, make sure it shows behind for each of the collaborating teams (duplication of tasks may not be required to accomplish this, depending on the work planning method).
• Set realistic expectations: team morale and program credibility will suffer if unattainable expectations are set. A first mock cutover or test conversion probably won’t be great…
• Plan for iterations: start with a technical conversion with mostly plugged values. Track improvements over time.
• Make Data Conversion everyone’s accomplishment: plan for orchestrated tests and celebrate its successes across teams

Need Help?

If you are still reading, the above probably resonates. You are not alone. Let’s have a conversation to see if Great Landings Consulting can help you get it turned around.

What Are My Responsibilities?

Shared responsibilities is one of the challenges of SAP Data Management. Unfortunately, the principle of unambiguous roles and responsibilities just doesn’t work here.

Why? Because multiple groups must collaborate to the outcome of properly designed, converted, cleansed and verified data:

• The Data Team – accountable for making the overall process of data migration and cleansing work within the project timeline. This team may also be responsible for establishing Data Governance.
• Functional or Process teams – accountable for the data design. This includes determining the appropriate types of content in conjunction with the business process and solution design.
• Business data owners – responsible for the data itself. This translates into definition of transformations and providing data cleansing and enrichment content. As a rule, they also sign off on the loaded data.

Project Dysfunction

For people in these roles, this is not simple to understand. Until they do, there is likely to be confusion and delay in progress – in short: project dysfunction.

How do you resolve or prevent the impact of this complexity?

• Don’t assume it will sort itself out. It will take effort and perseverance by program leaders to get all groups to understand how they will work together.
• Create a cross-team project work plan for the data related work. Tasks that require collaboration must show as accomplishments for all teams involved when completed. If behind, they should show as behind for all.
• Establish a data score card appropriate for the project phase.

Solving SAP Data Management Shared Responsibilities

As a program leader, understanding the dynamic of shared responsibilities and investing time in making it work is essential. And it must be done early in the project. As a guideline: if not in control at the half way point between launch Integration Test Cycle 1, you’re in trouble. Data will likely become a cause for project delay. Indications of Data being in control could be:

• Data conversion scope for each test cycle is well defined, plausible and understood across teams.
• Functional, business and data teams are working together against one plan.
• Functional and data teams are delivering useful functional specifications for data conversions. This in spite of unknowns and open questions.
• The data team reports status, not just on their own progress, but also on data tasks of functional and business teams. If the reported status is Green, that should be a red flag for the program manager.

In a high paced systems integration project, Data will rarely be green. But with a bit of work, the shared responsibilities of the SAP Data Management work can be controlled and managed towards success.

If the above resonates and you need more input: make an appointment for free, no obligations consultation session or drop us a line.