Enterprise resource planning (ERP), and the multimillion-dollar technology platforms that have become synonymous with it, are the stuff of which out-of-this-world management ambitions are born. The excitement generated from testing the technical boundaries of ERP is admirable, if only for what it implies about a company’s passion for innovation. Often, however, the excitement short-circuits rigorous analysis of whether such innovations may be appropriate targets.
My years as a process-reengineering consultant have revealed the danger in this impetuous overreaching. I’ve personally analyzed best-in-class ERP systems that have been online for more than a decade. Each instance--a half-dozen, all told--involved billion-dollar global enterprises, all of which were focused on very different industry sectors. In all those cases, heavy investment in ERP failed to deliver the initial liftoff in organizational transformation that was anticipated.
The reasons for these unsuccessful ERP launches are many and varied, yet they share some disturbing constants. By definition, an ERP system is meant to replace a legacy mainframe with something that synergistically integrates all enterprise data and process management in one platform. But time and again, what I saw were ERP platforms being corrupted by organizational inertia.
Within months of ERP liftoff, a kind of centrifugal drift in the process flow took hold. Cycle times on major backroom transactions became increasingly erratic, with everything from invoice payment to order fulfillment being completed at either ridiculously early or notoriously late rates of speed. As a result, financial, human, and physical resources were routinely allocated in an untimely, needlessly cost-consuming manner. The culprit wasn’t the technology, per se, but that various ERP user constituencies misapplied old, unlearned behaviors and perceptions about processes to a new technology. Master databases loaded with mission-critical information about employees, customers, product vendors, and service subcontractors also suffered from a not-so-benign neglect.
If my observations of this phenomenon are an indication, then 80 percent of procure-to-pay and customer-order ERP applications--directly affecting cash outflow and inflow, respectfully--are mismanaged or badly under managed. Again, the problem isn’t the technology but rather a lack of vigilance in its management by various user groups that fail to appreciate the importance of their new roles in information upkeep.
Admittedly, blind or willful ignorance about the need to change processes is partially responsible for these launch failures. The real saboteur, though, is outsized expectation. Too many ERP system designers and early users expected the technology to boldly take an enterprise where no one had gone before, and to do it virtually overnight (usually with little to no effort required on the designers’ parts). Over the long term, such a grandiose sensibility can be devastating on an organizational psyche. Inevitably, when the system fails to meet its moon-and-back target, users’ expectations plummet back to Earth in a hard free fall.
Buying into the blinding bright technological promise of ERP can prove both misleading and maddening. Many companies have been seduced by the technology’s all-things-to-all-people allure, and too many have been lured into hasty, high-priced gambits to harness its power before a bitter rival does. Baby boomers who recall the insecurity-laced hysteria that gripped the United States when the Soviet Union’s Sputnik circled the globe in 1957 know something of what I speak. Another 32 years would pass before the Berlin wall fell and we learned how unfounded the West’s fears of technological inferiority were. But the true lesson, for those MBAs paying attention, was that, ultimately, Soviet technological advances couldn’t mask--let alone redress--underlying process flaws that gradually crippled its highly centralized, stiflingly bureaucratic, captive-market economy.
Today, the world’s superpowers of business--also known as the Global 500--are in danger of being swept up in a similarly frenzied competition. Some, like latter-day Soviets, convince themselves that superior ERP power alone can magically resolve (or at least conceal) deep systemic problems of people and processes that they prefer not to confront with hard analysis and harder reengineering fixes. Others, like an ego-bruised Cold War United States eyeing the moon, fixate on exploring the outer reaches of an enterprise platform’s functional capability by pursuing a we-did-it-first mission of nominal strategic or commercial value.
Whether pushing for best-in-class ERP technology so that you can maintain denial about deeper systemic inadequacies, or pursuing it out of insecurity that the other guy has lapped you on the tech front, boldly going where no one has gone before is likely to win you bragging rights and little else. Either way, what follows such knee-jerk ERP commitments is an early overemphasis on building capability at the expense of due consideration for what the key mission objectives should be. Efforts end up centering first on power (with power defined as an ERP system’s flexibility to accommodate the needs of a broad base of local users); but the power programmed into the ERP platform (the flexible means of interconnecting the enterprise) is hardly as important as a simple, sharp focus on where you want to go, and the nonnegotiable ends you seek to accomplish.
By way of comparison, humankind’s primary focus in space no longer rests on a symbolic conquest of the moon. The empty posturing of that geopolitical power play has been replaced with something more meaningful and productive. Our current space agenda is now more globally focused. We’re still “out there,” but not too far out. For the most part, our gaze is turned inward--toward, say, precisely configuring an array of orbiting satellites to meet well-specified and extremely vital earthbound ends.
Likewise, the present-day ERP mission isn’t to “push the outside of the envelope” of our technological limits. The mission is to strengthen our logistical grasp on the everyday global business environment. It’s to geo-strategically situate, and continually resituate, people, processes, and platforms enterprisewide. It’s to see that those three Ps are always properly arrayed and squarely focused on the big blue marble that constitutes the enterprise’s operating and market footprint.
This unglamorous ERP mission is far easier to define than to accomplish. The most grounded organizational leaders can and still do become starry-eyed over grander ERP possibilities. It’s not uncommon for these leaders to be quietly encouraged in their overreach, especially by those who make a lucrative living selling ERP solutions. What should be continually emphasized is this: No matter how flexible, ERP systems can only accommodate so much connective variation country-to-country, function- to-function, vertical-to- vertical before they’re rendered dysfunctional. For purveyors of ERP, there’s money to be made by staying mum on this point. The result is an endless stream of follow-on ERP “refinement” work to support the implicit lie that the platform can be bent to every user preference.
You can’t have it all, however. When the nebulous ERP mission is to make every user infinitely happy, you make nobody remotely happy--with the possible exception of those constantly working on another myopic platform modification while their meters are running.
Sooner or later, an ERP fragmented by a host of constituency-satiating variation--a system that overreaches in every imaginable direction--devolves into a loose collection of subsystems only faintly resembling each other. From there, the promise of global connectivity begins to pull apart at the seams. By the time ERP champions and users inside the enterprise realize the error of their over-expectant ways, they feel too much at the mercy of momentum. Ironically, they usually sense the dire gravity of their situation without recognizing that an inability to manage a low-gravity environment lies at the heart of their troubles.
To understand the forces-- or, more accurately, the lack of force--pulling people, processes, and platforms apart, it’s helpful to know that ERP relies on a distributed computing framework. As such, the ERP platform lacks the hard center of gravity of old-school mainframe systems. This free-floating architecture is both highly flexible and extremely fragile. ERP’s flexible interface means that it can accommodate an ever-expanding galaxy of new information fields over time, but incessant ad hoc modification invariably destabilizes the flow of useful information. Too much of what’s reactively added is immediately relevant to only a minor subset of users and meaningless or confusing to the rest. Just as often, information that was once broadly relevant but now badly maintained ages into obsolescence.
The effect of so much nongeosynchronous or inert intelligence is an enterprisewide presentation that, at best, is only mildly serviceable for most local users, and at worst, useless to senior managers who’d otherwise derive the greatest benefit from it. Said another way, one satellite slightly out of sync seriously undercuts performance of the overall array. Several slipping a degree or two off-kilter, meanwhile, yield exponentially dysfunctional outcomes. Consider what happens when a network becomes bogged down with information about vendors that the enterprise hasn’t done business with for years, or that have changed addresses, been acquired, changed name via merger, or any combination thereof. Equally problematic is the possibility that the employee contact name listed as responsible for authorizing a vendor payment--or for a signing off on a time- sensitive customer service-contract renewal or product order--is outdated.
If you don’t know whom, specifically, to reach out to on the vendor or customer side, or whom they should work with on your company’s end, the global connectivity of your ERP will be seriously degraded. Digitally entered information may move swiftly at the start, but if it’s not presented in a way that’s clearly actionable to all user constituencies with a mission-critical need of it to do their jobs, or if the information is misdirected to the wrong person, it soon disappears into the void.
The ERP challenge is to make sure that people within the enterprise--and outsiders who interact routinely with those insiders--behave how you expect them to. One simple way of ensuring that behavior aligns with expectation is to give all employees the permission, training, and responsibility to refresh their own personal profile information within the ERP in real time. I’ve seen this cut down immensely on problems of misdirected process flow, particularly if vendor companies are encouraged to adopt a similar policy of real-time refreshment. The result is that everyone clearly knows who is responsible for what data and which aspect of process flow. This way, global connectivity can be maintained despite operating in a distributive ERP environment with a weak center of gravity.
Not all ERP synchronicity problems are so simply fixed. Take a current client of mine that relies on subcontractors to perform services at customer sites in 30 countries. The client was experiencing problems paying these subcontractors on time, chiefly due to delays in receiving their invoices. It turned out that 40 percent of late-arriving invoices were misdirected to the client’s local branch offices, then forwarded to a newer central-processing center. Also, one out of four invoices lacked a purchase order ( PO) number required to secure timely payment. Finally, 30 percent of the roughly 50,000 invoices audited were found to be duplicates reissued by impatient subcontractors. The aggregate result was a procure-to-pay ERP channel gummed up with copious amounts of unactionable information. This, in turn, produced confusion and lengthy delays.
Several steps were taken to get all internal and external process stakeholders reading from the same value scale and operating in alignment. Orientations (through webinars, print, and on-site formats) educated subcontractors and employees alike on how misaddressed invoices and omitted PO numbers delayed processing and payment. Early orientation efforts concentrated on the top five to 10 offending subcontractors and branch sites. Next, all stakeholders were informed that, going forward, invoices lacking PO numbers would be summarily rejected (rather than adding a number retroactively), and the “net terms” clock for payment would start only after a properly PO- annotated invoice was received by the central-processing unit.
Once on-the-ground people and process fixes were implemented, ERP-platform power could be made more value-driven. The audit revealed, for instance, that 16 percent of payments were delayed as processors awaited confirmation that all materials itemized on an invoice (and the corresponding PO) had been received. In response, a PO-driven application was created that automated e-mail reminders to those charged with confirming receipt. With the three Ps properly arrayed, median process-cycle time was halved and on-time payments increased from one in three invoices, to four in five. Seeing that improperly remitted invoices aren’t prematurely paid is expected to net annual savings of $2 million as well.
The ERP lesson? Don’t try to go too far too fast. Better to get the right resources correctly aligned at the start than attend to an in-orbit fix later. Before you begin an ERP launch countdown, think long and hard about your mission priorities. Check that you’re not unduly focused on getting the entire enterprise platform up and connected as fast as possible. You’d be better served thinking about how you want it all to fit together, and to what primary ends.
Prelaunch, think about how process steps, process flows, and process speeds may fundamentally change with digitization or transition to a distributive network. What are the unintended consequences? What’s your plan to mitigate or capitalize on these changes to maximize efficacy? How do you plan to get the platform’s profile high enough within the organization (and make it attractive enough) so that you can collect a critical mass of users? How will you educate users on the importance of leveraging current information in a common format, and using standard value scales to measure process performance? How will you hold them accountable if they don’t use these tools, and reward them when they do?
Process engineering is just that: engineering. The slightest defects can lead to process mismanagement and neglect, resulting in millions of dollars in negative cash flow. Like any other engineering discipline, good ERP system design should make the most of upfront modeling of expected data and activity flows. You won’t be able to account for every unintended consequence before the system leaves the drawing board. That’s why beta testing among key user constituencies--followed by slow and steady rollout to different functions, countries, and verticals--is also vital. So is real-time monitoring of how implementation is measuring up to expectations, both in terms of desired behaviors and anticipated results.
A well-designed ERP program allows you to readily ask and answer the question, “To what ends are enterprise resources being controlled--and is our control of the three Ps meeting these ends?” The stars don’t need to be perfectly aligned to achieve this degree of superior mission control, but your global reach and grasp certainly do.
© 2023 Quality Digest. Copyright on content held by Quality Digest or by individual authors. Contact Quality Digest for reprint information.
“Quality Digest" is a trademark owned by Quality Circle Institute, Inc.
