ZETA MIDDLE EAST

Office 1606, Opal Tower, Business Bay, PO Box No. 35634, Dubai, UAE.
+97142417117, +971557814450
sales@zetasoftwares.com

ZETA EUROPE

72A, London Road, London – CR44JB.
+44 738 8275 666
sales@zetasoftwares.com

ZETA ASIA

R K Chambers, Mamangalam, Palarivattom P.O, Kochi 682025.
+91-484-4852385, +91 9037070711
sales@zetasoftwares.com

ZETA AFRICA

Plot 1301, kings tower, 3rd Floor
Suite no 4, p.o . Box 11073
Nsambya Road, Kampala, Uganda.
+256 757 255310, +91 73063 89636
sales@zetasoftwares.com

ERP Customization

  • By admin
  • May 7, 2021
  • 854 Views

ERP solution providers in Kerala

Customization is one of the features companies consider when implementing a new ERP software. When you see a complex business process far from the standard ERP system, a knee-jerk reaction is to reach for customization tools and do the development.

For every inch a customization brings an ERP system closer to the way you do business, it makes it an inch farther away from what it really is: a named product you purchased in the first place. It might not matter to you at this point,here all you need is solving your business problems after all. But solving business problems can introduce new non-business problems, which cause you so much pain in the long run to become business-relevant.

Many ERP theorists say that ERP is only as good as it is an exact match for your processes. And they are mostly right about it. But majority of ERP systems are very generic (Microsoft Dynamics NAV, Sage, Zeta etc), and to exactly match your processes, they require customization. When it doesn’t work out-of-the-box, you customize it; it’s that simple, isn’t it?

Let’s take a look at few arguments for not customizing ERP for their specific requirements. According to Vjeko the top reasons why you should avoid customizing your ERP solution are as follows:

Regression

This is a fancy term of software development theory which is really used as an euphemism for “a screw-up”. That is when you do a small change to functionality A, and suddenly functionality B starts behaving funny. When you introduce a new feature, you must do the regression testing to make sure your new change didn’t mess something up with what was already there. With ERP, no matter what you do, there is a lot of the already there stuff to test. The more you customize, the more regression testing you have to do, and what consultants don’t find, the end users will, but after go-live. Hunting down these goblins goes on for months, and I’ve seen deployments which turned into a lifetime of regression issues.

Go-Live

Customizations prolong your go-live. The more you have, the longer it takes before go-live. Even though your initial budget might have covered for all the customization costs, time overruns can make your project unsuccessful. With ERP systems, go-live dates matter a lot: it is much easier, and less costly, to switch at the end of fiscal periods, preferably years. You miss the deadline and you might need to postpone the whole thing for another month, or another quarter.

Official support

When there is a problem, depending on your support plans, you might request official support from system vendor. When you do, first thing they’ll want to know if the problem repeats in the standard application. If it doesn’t, you are toast, because the support team can’t support your custom solution. For smaller issues, this might not be important, but imagine having a critical bug which puts your business to a stop.

Upgrade

A life cycle of an ERP application version is two to three years, while a life cycle of an ERP deployment is five to ten years, sometimes even more. This means that in a life of an ERP deployment, there will be between two and five (or more) versions of the same application released by its vendor. Upgrading to a new version can sometimes require re-developing all the customized functionality, making you have to pay for the same customization time and again. And then fight regression issues all over. Of course, you may opt not to do any upgrades, but that can mean locking your whole infrastructure to old versions of software (and hardware).

Know-how

People come and go, but the knowledge comes and goes with them as well. If you use standard out of the box applications to manage your business, you have a huge benefit of being able to hire power-users who have experience with the application. But if you have a Frankenstein, anybody who comes to your company with the knowledge of Zeta won’t be of much help. And when people who know the Frankenstein leave your company, Houston you have a problem. The same is true for your consultant: the people who developed your Frankenstein might leave, and new people who come, who might be world-class experts in Zeta might easily not be able to support and maintain your solution at all.

Vendor lock-in

One of the benefits of choosing a standardized ERP system is avoiding a vendor lock-in: if you are unhappy with one your dealer, you can switch for another one. Or can you? If your first partner developed a Frankenstein for you, you might have troubles switching partners. Companies are very cautious about accepting to support an application they didn’t develop, they have to learn something non-standard and then to maintain it; it might be too costly. If you have to switch partners, then it sometimes means re-implementing the system. Sticking with your old vendor might be one huge opportunity cost for you.

Help

You know that handy little F1 key? It often becomes worthless. Really, how many of consultancies update the help file with all the customizations and changes they did? Yes, they give you the operating manuals or end-user documentation, but how handy is it really? Users can’t tell what is standard and what is customization, and if there is help for their Customer Card, but there is no help for their Parcel Tracking List, and if the existing help for Customer Card explains only half of what is there, or when it explains something in a wrong way (because the developers decided to tap into existing functionality and invent a new purpose for it)—your end users will stop using the help file. And the moment they stop using the help file is the moment when they’ve given up. From that moment on, you’ll have them gradually stop thinking and turn into robots following cookbooks, which will cost you dearly in errors, rework, and lost productivity.

When you look at customizations from this perspective, it becomes obvious that customizations can turn your ERP system into a huge long-term cost generator.

Of course, it is not all black and white. Sometimes customizations can be totally necessary. All of the above doesn’t mean you should avoid all customizations, it only means that you should consider the alternative ways, and if you decide the customizations are the way to go, at least you know the risks, so you can better prepare for them.

Leave a Reply

Your email address will not be published. Required fields are marked *

LEAVE A MESSAGE