Master data management (MDM) is gaining traction in the South African business arena, but there are going to be casualties. Some companies are going to sink millions of rands into an apparently bottomless pit that never results in anything more than a gang of disgruntled employees, emptier coffers, and cynical executives.
But that's because some simply won't listen now, before the ball gets rolling, when the experts are calling for them to exercise caution and beware the pitfalls. Others will think they're smart and they've heard it all before. The really smart ones, the ones who will succeed, and subsequently drive their competition into the ground, will take some precautionary steps, make some simple operational adjustments, talk to the right people, bring the right message to their employees, and quietly get the job done properly, first time.
But what must they look out for?
Most companies, even today, believe MDM is a sub-function of every business unit. When the business embarks on a cross-departmental project, then accounting is responsible for its own master data, customer service for its own, and so on. There's no consolidated interest or ownership in master data, and that manifests quite poorly in ERP projects, for example. There needs to be single ownership and a separate budget. It's a recent development, it works, and we need to see more of it.
With the various pressures that corporates face in today's competitive marketplace, such as consolidations, new regulations, mergers, and acquisitions, they need MDM and particularly up-front assessment.
Unfortunately, when businesses embark on system consolidation projects, for example, they get the project team together, they get the budget, make the plan, and get cracking. But the minute they fall behind schedule - and, let's face it, that's almost inevitable - they immediately pinch back some time from another part of the project and the first casualty is usually the master data component. It's a culture issue that has to be sorted out because master data management underpins all the other processes and functions of the project and the business.
Making master data management an IT project is possibly one of the biggest mistakes a business can make - it's a guarantee for failure. It's not an IT project like an ERP upgrade. It requires business motivations, business drivers, business buy-in, business development, business deployment, and business use. There is a technology component but all that requires is a fulfilling service provider, be it internal or through consultants.
Manage change
You must manage change - it's one of those critical functions of the project that cannot be forsaken. MDM projects, often completed for governance reasons, compel people to follow processes. If they were accustomed to conducting free text purchases, those products not on a pre-approved list where users can simply fill in the blank description, then following a set process after a master data project is rolled out can be frustrating. They will have to apply for the product, it will be assessed then added to the list, finally they will order it and eventually it will be delivered. It can take a simple process from a day to five days, and it's that sort of frustration that drives employees to subvert corporate intent or lose interest. You can imagine that in an outsourced environment, lead times, and consequently frustration levels, rise dramatically.
An often neglected aspect of MDM projects is also to manage the change for middle managers. Hypothetically, you may have a new chief executive, with the business for a year or two, who understands the need for MDM and provides full endorsement. The project begins to unroll but soon meets resistance when a factory manager, already managing his own environment for 20 years, doesn't want to change his processes. He doesn't want to relinquish control of creating product master data records and updating them. Why should he? It's worked quite well for the past 20 years. But few people resist stoically once they understand why the change is necessary.
The final potential problem is the skills gap, which is hurting service providers who are selling systems because they don't have the skills to follow up with an implementation. They end up having to fly consultants in from abroad, but customers aren't happy with that. International consultants don't come cheap and they're seldom on hand when required. What customers need are local consultants, with local industry expertise, with the right business acumen, tailored by the right mentoring, and delivered at the right time.
Share