ERP Is A People Problem

InformationWeek Green - Sept. 30, 2013

InformationWeek Green

Enterprise resource planning projects are difficult, time consuming, potentially perilous to the business -- and frequent. In fact, among respondents to our 2013 InformationWeek Enterprise Applications Survey, 77% of business technology professionals with direct or indirect responsibility for enterprise applications said there is some likelihood they'll invest in on-premises ERP by June 2015; for 34%, investment is somewhat or very likely.

I wish them luck, because in ERP, failure is expensive. In addition to astronomical up-front licensing, expert services can cost at least three times the price of the license. Poorly planned or executed implementations have the potential to run far more. And that doesn't include capital and operational costs around wasted productivity, staff reallocation or software maintenance, which typically runs 20% to 30% of the purchase price of licensing.

It's tempting to hedge your bets against failure by focusing closely on the technology. Resist. ERP success is 75% about people.

The No. 1 mistake I see: believing ERP is an IT project. Line-of-business executives have an unfortunate tendency to see ERP as something the IT staff should "just handle." For teams with very full plates, the technology-specific portion of these projects alone is daunting: Infrastructure upgrades and auxiliary hardware devices, like bar-code scanners or specialty printers, must be ordered without breaking the budget. Software has to be installed, configured, tested and integrated with existing systems. Just migrating data from the legacy ERP system can be extraordinarily time-consuming.

Straight To The Top

ERP systems touch, and potentially change, every aspect of a business' daily operations. The staggering level of detail required to understand and document how things are done demands a structured process review. I'm not talking about scheduling a few meetings with department heads -- dig deeper. Tribal knowledge tends to accumulate with the middle managers who control functional areas and trickle down to the people in the trenches. Someone who's doing a focused task every day will have critical input on inefficiencies that you won't get from higher-level managers.

And the greater the disorganization of any department, the less likely mid- and high-level managers even know what's going on. I've been with executives in process review meetings that ground to a halt while an assistant hunted down someone with a clue.

If the interview (and by extension the ERP upgrade) isn't a high priority for the department in question, delays in acquiring information can jeopardize the whole project. It's even worse when someone actively tries to sabotage the effort, which happens more than you'd think.

Taming the human element takes some of those "soft skills" you've hopefully been working on. End users fight change. Bet on it. That translates into major resistance to ERP projects, which by definition require minute scrutiny of business processes. Because ERP systems often derive their ROI from automation-related labor savings and better or timelier intelligence at all levels of the business, job responsibilities have a way of shifting post "go live." Employees who invested many years learning the ins and outs of one product don't care that the new system consolidates financials across 16 subsidiaries and allows for a 40% downsizing in accounting staff, or provides real-time intelligence of inventory locations, or improves time to ship by 30%. They just know that their favorite screen is missing.

Foot-dragging increases costs, but not as much as turf wars stemming from ERP's extremely interconnected nature. How sales inputs orders or updates customer records affects how accounting works, just as the way that warehouse staff manages stock has an impact on how purchasing buys materials. Process choices can breed bitter disputes between departments that must be arbitrated fast, without souring people on the project.

Translated: Establish an executive sponsor with broad authority. IT pros hear a lot about "getting a champion," but with ERP it's nonnegotiable. This person should be as high on the org chart as possible, thoughtful but decisive, convinced of the need for the project and capable of jumping in on short notice to arbitrate disputes and quell resistance. Pair this person with a project manager, internal or external, who has experience on the ERP platform, good communication skills and a strong grasp of project management methodology. This person is responsible for noting and managing tasks, negotiating and setting due dates, guiding the project from objective to objective and ratting out, er, identifying teams or individuals who are creating delay.

Also consider a lead implementation consultant; these people are usually, but not always, hired guns with a thorough knowledge of ERP in general and the new platform specifically. Finally, identify subject-matter experts who are intimately familiar with one or more areas, such as finance or warehousing.

Arm your team with tools commensurate with the volume of information that needs managing. An issue-tracking system is a must, and a schedule built in Gantt form will help head off problems. One lead consultant I worked with used a Livescribe pen to record not only notes but voices in every meeting where decisions were made. Let's face it -- people tend to forget what was settled on because of information overload, a problem this consultant solved by playing voices back later; that clearly showed when and by whom any major decision was made.

Having key personnel map processes at a high level is only the first step. Once you know how things are done today, the hard part begins: matching existing processes to ones supported by the new system and figuring out how to do a task in a new framework. And because ERP implementations are almost always based on real or perceived inefficiencies, as you discuss and map processes, people begin to ask, "Should we be doing something differently?"

Unfortunately, this can cause "paralysis by analysis" that leads to extraordinary delays as system experts work with decision-makers across departments to analyze, test and model alternative processes. While this is basically constructive, it pushes due dates and can create enormous additional costs.

No matter how creatively business leaders and system implementers work, there will be cases where employees must either change their behavior or IT will be forced to customize the ERP system. The canned behavior of a given system simply may not work for your organization -- or, stakeholders may decide it won't work, which is where things can get dangerous and expensive, fast. Customizations to ERP systems by professional services firms can range from 20 or 30 hours for minor stuff up to thousands of hours for major integrations with other systems or for dramatic changes in core functionality.

Every change injects delay that even further magnifies cost.

I'm not saying to shoehorn your business into the stock ERP system. Customizations may be needed to realize the ROI and improved efficiency that are the business drivers behind the whole ordeal. But insist that people keep an open mind -- users often ask to replicate functionality that wasn't very good to begin with, at significant delay and expense, instead of leveraging the better (but different) functionality available on the new platform. Shoot down these requests unless the functionality in question is absolutely essential to operations.

Choosing whether to customize is a balancing act. On one hand, customizations add delay, cost and complexity to an already complex project and system. But on the other, a judiciously justified customization can make all the difference in the world for an organization with unique pain points.

There's one more wild card to consider when deciding to customize: ERP systems will be updated, and customizations do not play well with updates. Vendors fix bugs, which are common in systems with the hideous level of complexity found in ERP, and may also add core features that you'll want to leverage. Upgrades mean that you pay for your customizations up front in time and money and then pay again to fix them every time you upgrade -- which should be at least annually.

If you take on an ERP project and complete it on time and on budget without serious problems on "go live" day, you've done better than 99% of the pack. Still, when the project is done and the system is live, people central to the deployment process are often in for a rude awakening. ERP is so pervasive and the change may be so stark that people will take awhile to get used to the new system, and until they do, they'll often complain loudly and to whomever will listen. This can be discouraging to the implementation team, but don't take it personally. People will come around.