I have spent the majority of my professional career working on enterprise resource planning (ERP) projects, most of which have not gone well. With that it mind, it was with great interest that I read the results of a recent survey about the death of ERP.
From the piece:
ERP is an outdated, almost meaningless piece of IT jargon that crudely attempts to encompass all that enterprise systems have become and will be for today’s and tomorrow’s large, midsize and even small companies, but falls woefully short: No one does just ERP anymore.
While the reasons for the atrocious success rates of back office IT projects are multifaceted, I’d like to offer a particularly underrated one: the complete dearth of data governance (DG) at most organizations in the midst of major system implementations such as ERP.
Data Governance is No Elixir
This is certainly not to imply that a dysfunctional organization implementing a powerful ERP with minimal resources and an unrealistic time line can immediately find lightning in a bottle with DG. It can’t. Nor is DG a silver bullet. DG isn’t an “on switch.”
Think for a moment about the cultures at most organizations struggling with the introduction of new payroll, materials management, and financial systems. Odds are that these organizations have long resisted–if they ever even attempted–a DG program. I’ll bet you a Coke that at least eight out of ten have nothing in place vis-à-vis DG.
Organizations should not undertake most system initiatives without first doing some type of data profiling or audit. As an example of what not to do, consider what I saw on a recent consulting engagement.
An Example
The software vendor submitted a proposal that the client accepted, to my knowledge, solely on the basis of cost. No one on the client or vendor sides mentioned anything about the state of the organization’s data. This was a glaring omission; it affected the time, resources, and expense of the project. It should be no surprise that the client’s culture lacked any semblance of DG.
Data-oriented issues imperiled the entire project, causing major delays and cost overruns. To make up time, the client insisted on a “package slam”, resisting any efforts to clean up its data. The culture just didn’t t accept DG–or data quality, for that matter. Plain and simple.
The importance of organizational culture with respect to DG cannot be overstated. In a recent article, Jill Dyché and Kimberly Nevala write extensively about the mistakes made by organizations while attempting to implement a DG structure. The two write that:
…changing entrenched organizational paradigms and behaviors is perhaps the biggest obstacle for any governance effort. Examples include a corporate culture that stresses consensus over clear accountability, the absence of decision-making protocols, individuals unaccustomed to making decisions, or poor communication and planning. Common organizational constraints can derail governance before it begins.
Simon Says
Dysfunctional cultures can kill even simple IT projects, much less complicated ones such as ERP implementations. Some DG measures are necessary–but not sufficient–conditions for successful IT projects, particularly at large organizations. Vendors, system integrators, and clients need to be mindful of the latter’s culture prior to beginning a major IT project and adjust project plans, budgets, and resources accordingly.
Feedback
What are your experiences? Can a dysfunctional culture and true data governance coexist?
#1 by Charles Blyth at February 4th, 2010
Great post Phil, perhaps we do need to get out the ‘requirements gathering peace pipe’ and get everyone, vendors, system integrators, and clients around the camp fire. And start with the question, “What is your data management culture?”
#2 by Phil Simon at February 4th, 2010
I’ll bring the matches.
#3 by Jim Harris at February 4th, 2010
“Calumet Culture” is the term I use to describe the need to bring together the vendors, system integrators, and of the organization’s “tribes” together to discuss the complexities of business, technical, and (most important) people related issues that shape the enterprise environment.
Calumet was the Norman word used by Norman-French Canadian settlers to describe the “peace pipes” they witnessed the people of the First Nations (referred to as Native Americans in the United States) using at ceremonies marking a treaty between previously combative factions.
I like using the term Calumet Culture, not just because of my affinity for alliteration, but also to warn about the disingenuous way that I have witnessed these requirements gathering “ceremonies” carried out on enterprise information initiatives – when they are in fact done at all, which I agree is sadly not very often.
Simply gathering everyone together around the camp fire is an empty gesture – just like non-Native Americans mimicking a “peace pipe ceremony” and using one of their words (Calumet) to describe what was in fact a deeply spiritual object used to convey true significance to the event.
Most organizations don’t want to deal with “cultural issues” and just as troublesome, most organizations ignore the importance of at least having a sound business justification for their enterprise information initiative.
Unfortunately, failure hasn’t yet become “an outdated and almost meaningless” philosophy. For many organizations, it seems like failure is the only option.
(Wow, I just depressed myself with my own comment –
)
#4 by Phil Simon at February 4th, 2010
Leave it to Mr. Harris to take it to the next level and make me feel culturally illiterate.
First Praust, now this… Somebody stop him before he invokes Nietzsche.
All kidding aside, I completely agree with you. Ceremonies in and of themselves aren’t going to change cultures and individual mindsets.
#5 by Julian Schwarzenbach at February 5th, 2010
Phil,
Agree with your observations on Jim’s literary and cultural additions. Sounds like there could be the basis of a good game here – come up with the most obscure author/literary style and challenge Jim to write another of his excellent posts in that style…
Anyway, to more serious points. I fully agree with your sentiments about ERP and large enterprise systems, namely that organisations often appear to confuse activity (expensive when ERP is concernced) with appropriate activity and the delivery of business benefits (which often involve data, cultural or organisational changes).
I sometimes challenge people over whether they are aware of any organisation who was able to demonstrate a positive cost/benefit argument for implementing an ERP system (or similar enterprise system). From what I have observed, the replacement system typically delivers incremental benefits, often comes at significant cost and results in a dip in output performance during the implementation phases. This results in a shaky benefits case, at best.
One manufacturer I am aware has a policy that, whenever they are aware of a component supplier implementing an ERP system, they will ensure they have an alternate supplier for that component to cover the two years of poor performance they typically see from the supplier implementing the new system.
I would be interested if you were aware of any cases where an ERP system delivered a positive cost/benefit ratio.