There has been a pattern trending in recent Infoverity projects which is worth discussion because it occurred without much of an overlap in terms of what the clients were trying to do. While two of the projects were related to data warehousing/reporting and the other was in support of a large ERP solution implementation, they shared common ground in that they were IT initiatives tackling a business problem. Each project was attempting to make sense of their enterprise data, and all were going to fail.
What’s interesting isn’t that they were going to fail, but rather why they were struggling in the first place. In their defense, they were all following prescribed implementation templates from respected experts in the space. In addition, they had sponsorship and involvement from both business and IT– a requirement and common point of project failure you’ve no doubt read many articles addressing.
So what was the common root cause?
All these projects had spent weeks to months evaluating the business processes they were affecting or reliant upon: you know, order to cash, procure to pay, etc. What they had not done in all the blueprinting and flow-charting was an evaluation and design of the master data setup and maintenance process as business processes themselves. That’s all? That’s right. The master data setup and maintenance processes are every bit as much business processes as taking a customer order or shipping a product out the door. As important as this is to understand, I’ve never witnessed an ERP project team place emphasis on this process when it occurs in more than just their ERP system, as is the case when a data hub or data stewardship application is involved.
The impact is ultimately felt during testing when the patchwork design exposes assumptions made among business handoffs, missing functionality in system interfaces, violated service response times and other unmet expectations. Welcome to the Land of the Project Change Request! They come at the worst possible time too as many interfaces are fully baked, the budget’s nearly exhausted and the delivery deadline is in sight. At that point, who in their right mind wants to crack open the design and have a do-over?
At Infoverity, we’ve become quite proficient at aligning with project teams who agree that MDM processes are complex and present risk but aren’t sure how to mitigate that risk. Our clients find value in what we bring to the table as they are usually not staffed with the expertise or capacity to deal with the intricate requirements of an MDM solution. We document systems interactions separately from business interactions, but in a manner that preserves the business context. Our work aims to integrate within the existing project plan without delays, having designed, prototyped and unit tested a package of business and systems interactions. This accounts for how a domain of master data (such as item data) is created, edited, queried and deactivated, inclusive of all the various business and systems exception scenarios.
Although there is no industry term for this strategy, it could be generally referred to as ‘Applied MDM’. It’s different than projects attempting to address enterprise data governance but seems to present a much more specific value proposition to the stakeholders and strategic project team alike. At the end of the day, that’s what it’s all about isn’t it?
I’d be interested in hearing your thoughts and experiences around this topic!
Matt Wienke
MWienke@infoverity.com
