Are ERP Workarounds a Terrific Way of Shooting Yourself in the Foot?


TEC Analyst Gabriel Gheorghiu says “There’s no way to avoid them. And yes, they’re a problem.”
TEC Analyst Jorge García says “No they’re not.”



Gabriel Gheorghiu, TEC Analyst
Here’s an example of a typical ERP workaround:

You need a field for purchase order types (you would be surprised how many ERP systems don’t have this) in order to differentiate between purchasing raw materials, assets, office accessories, etc. You could simply use a note or a “miscellaneous” field for each order and you’re done.

But later on, if you try to run a report showing how much you have spent for each type of purchasing, you might be facing a few challenges: Can the system search the fields you used and group data so it makes sense? Can you run a query or modify an existing report on how much you’ve spent on office accessories?

Or, my favorite example of a workaround: You’re selling a shirt that you produce in sizes S, M, and L, with an initial inventory of 250 pieces of size S, 100 size M and 400 size L.  Let’s say you decide to start manufacturing and selling size SX. When you add a new size range, some systems will not move the inventory for the other sizes “to the right,” and you’ll have the following inventory: 250 pieces of SX, 100 of S, 400 of M and nothing for L. You will have to transfer inventory from one size to the other to fix this problem.

My experience shows that ERP workarounds are common practice—and that while they may fix problems in the short term, they cause others in the long run.

Jorge García, TEC Analyst
Workarounds are extremely common, particularly in complex deployments, as there’s no such thing as an ERP system that perfectly accomplishes a complete match between functionality and requirements. Sometimes workarounds are even part of the evolutionary path of the software. Understanding workarounds as a factor in eventual code customization or process addition is simply part of the project management process.

A workaround in itself need not be a drawback (at least, not particularly damaging) if it is done correctly. In other words, problems derive from the analysis, design, and deployment of the workaround, not in the workaround itself.

From my experience as an ERP system trainer, a workaround is an ad hoc solution you find when you’re stuck because the system you're using cannot provide what you need, as in my examples above. End users in particular are prone to these workarounds, not IT people or administrators (who could probably customize or come up with a programming solution, unlike “regular” end users). That’s why “analysis, design, and deployment” of workarounds is not really the issue at hand.
Of course a workaround for an important problem is better than waiting for the vendor to fix it, but let's stick to ERP and end users. It's like parking in a space that blocks someone else: you’ve solved your problem, but the other guy is trapped.

Let’s not be simplistic about this. When deploying a new ERP, you have to ensure that all necessary functional requirements are addressed. Of course it happens that during production you may find an exception (error) on the system, and I agree that you may have to find an immediate solution, but that must trigger an alert to modify or adapt the system to solve the problem in a way that respects the development of ideal processes. End users should not be solving technical problems in the first place—that’s not their job.

Aren’t you contradicting yourself a little?

You say that there are no perfect ERP solutions, and I agree, as we both know that companies buy a specific solution based not only on functionality, but also on delivery model, cost, ease of implementation, etc. So decision makers will choose a solution that is far from perfect, and users will eventually discover missing or incomplete functionality, and resolve it in order to get their jobs done—often to the detriment of their colleagues.

No, I’m not contradicting myself. In an ERP system deployment project you should address the need for workarounds, customizations, or specific coding as part of the project, not after the fact, when the system is in production. I agree that you might come across problems when the system is already in operation, but in that case, it is necessary to establish a problem resolution strategy, which usually requires a combination of people or at least a user that has the knowledge to execute it—who in most cases is not an end user.

I really don’t think end users should be assuming responsibility for these problem resolution strategies. Again, issue is not the workaround itself, but in the way problem resolution is addressed. There are extreme risks in letting end users solve problems that way.

David Clark, Managing Editor
I had no idea that assigning this topic would get you two so hot under the collar. Are you still on speaking terms? Gabriel, your position seems to be that workarounds are a necessary evil, with equal emphasis on “necessary” and “evil.” Jorge, you’re taking the position that you can actually plan for workarounds and respond in a way that respects processes.

I know from offline discussions with you both that Gabriel’s perspective derives from his experience with SMBs, while Jorge’s stems from his experience with medium to large companies. So here’s my question for the two of you: 

What strategies can companies adopt to minimize or mitigate workarounds in the first place?

There are a few things you can do:

  • When using any type of workaround, you should try to understand how this will affect other users and departments.
  • User rights and securities should be defined so users cannot use fields they’re not supposed to, or interfere with operations they shouldn’t be part of.
  • Test a workaround before using it—either by using a test database or by creating transactions that you can remove afterwards.
  • Try to be consistent and make sure others are using the same rules as you are, by creating internal rules and workflows.

Here’s my take:

An essential step in the software selection process is to match your functionality requirements with product functionality offering. If this match is perfect (which is extremely unlikely), that’s great—but if not, it is necessary to consider workarounds as part of the process, and to be prepared to deal with them both during deployment and during production. Extensive functional testing during deployment, along with issue management, is part of the solution in order to detect the need for a workaround and then to apply the resolution with maximal benefit/minimal damage. That may be a cliché, but it works. 






comments powered by Disqus