Customizations Part 1: Why, When, and What to Look For

Sometimes, none of the application options available in the marketplace, are sufficient to meet a company’s needs or support a specific process. In this case, the customer may need to consider a customization.

Today’s Enterprise Resource Planning (ERP) systems offer the user countless features and functionality. ERP’s provide increased processing efficiency and data capture, greater control of business transactions and improved reporting capabilities.

Nearly every ERP has a number of “add on” applications which are used to enhance or extend base ERP functionality. These products are known under a variety of names such as 3^rd party and ISV applications. The number of these applications is staggering, and nearly any business need can be met using these products.

While application functionality options are expansive, in certain instances, the required functionality is not available. In that case, a customization may be needed.

Methodology

ERP implementations are controlled using a specific methodology. An example implementation methodology appears below. The example consists of five implementation phases.

Customization needs are usually identified in the pre-sale discovery and documented in the requirements gathering phase. The actual customization is coded in the configure and data load phase and tested in the training and testing phase.

Best practices

Over the course of dozens of projects, three top best practices have emerged that can positively impact a customization project:

• Executive ownership
• Researching all alternatives before building a customization
• Staying within yourself

The document also identifies some “pit-falls” which often result in a less than optimal outcome.

Executive ownership

Visible executive ownership is the number one ERP implementation success driver, including identifying, defining and building a customization. Employees look to company executives for both direction and a sense of the importance associated with company initiatives. If the Executive team doesn’t take the project seriously, chances are that the project team won’t either.

Discuss the customization with the project sponsor if one has been assigned. If there is no project sponsor, be sure to review the customization with the executive team. Be sure they understand the need for the customization and its costs, both initial and on-going. Include customization “soft costs” such as additional reconciliation tasks and error handling processes.

In addition to actual customization costs, be sure you understand any associated on-going costs.  For example, custom code development may require a re-do of the coding each time the system is upgraded. These costs can be significant. Essentially, you’re paying multiple times for the same effort.

Also remember, when interfacing data between systems, additional system maintenance and reconciliation is usually required, resulting in additional labor requirements.

If you can, build and present a simple ROI to support the customization. Also, if you’ve identified customization alternatives such as a process change, system workaround or an ad-on application, present them at this time as well.

Finally, be sure to get executive team sign off on the customization budget to avoid any issues later on.

Research all alternatives before building a customization

The customization need is usually identified in the pre-sales or requirements gathering phase. In either case, be sure that you review all of the available alternatives before going down the customization path.

Sometimes, all that’s needed is to make a change to the actual business process itself. When considering this option have the proposed change demonstrated and be sure that you don’t negatively impact productivity or control.

For example, a company may have a transaction or process currently completed via a single step. However, the proposed process change now involves 2 steps to achieve the same result. While the change may be a non-issue for an infrequent transaction or process, it may not be suitable for high volume transactions.

When the customization need involves the capture and reporting of specific information, there are a couple of options which may work. You may be able to use an existing static screen field and merely change the field label. Also, many ERP’s have additional screen fields available, which are sometimes called “user defined fields”. If the ERP you’re considering uses the concept of “dimensions” take a look at them, as they are very powerful, and if used correctly, may also resolve the issue. If you need to include this information in reporting, test it prior to signing off, as some fields aren’t visible to the reporting function.

As I discussed in the introduction, there are a large number of “add on and standalone” applications which can be used to extend the ERP to meet specific business needs. The salesperson is good research resource for identifying these applications. They may know of products which they’ve implemented in the past, and can vouch for their effectiveness. One of them may suit your needs.

You may also find the application you need using the web. For example, Capterra is an application search resource. A web-search will easily direct you to their site.

Remember that when going down the “add on and standalone” application road, be sure to complete the necessary due diligence. Be sure to check references and participate in a product demo.

The most dangerous word when completing due diligence is “assume”.  I’ve seen companies invest a lot of money purchasing and implementing an application and just assume that certain functionality, controls or reports are available out of the box. They find out too late that what they assumed the system provided out of the box, is in fact not standard functionality at all. A best practice here is to assume nothing and validate everything.

Staying within yourself

No matter the blog topic, it’s a pretty safe bet that I’ll be reminding you to stay within your capabilities. Don’t bite off more than you, your team, or your company can chew.

Let me explain what I mean by way of an example. I was involved in a supermarket chain project awhile back. Every product vendor directly servicing the store (e.g., bread vendors) generated a separate invoice for each store, after the servicing was completed. This resulted in a large number of AP invoices being entered for the same vendor.

The legacy system supported entering multiple vendor invoices in the same voucher screen with the invoice number being entered in the line detail. The ERP purchased, supported a concept of a header and detail record for AP invoice entry, with the invoice number included in the header. That means you needed to set up a new header for each invoice being entered. So, for twenty invoices the number of entry steps went from twenty-one to over forty. The need for a customization became apparent to support this high-volume situation.

When we initially spoke to the client about the issue, we explored several options at various levels of complexity and cost:

• The client’s AP staff would enter all of the invoices into a spreadsheet and then import a file into the ERP. While this was the simplest and least costly option, there were concerns related to duplicate payment testing, vendor code issues, GL account coding and spreadsheet/GL reconciliation.
• A customization which would allow the users to enter the invoice number in the detailed line section of the AP invoice entry screen. Prior payment testing and vendor selection controls would still be enabled. This was a reasonably priced option and not real complicated to code and test.
• Building a vendor invoice portal into which the vendor would enter or load their invoices. The portal would capture the invoice data then load each invoice entered into AP as a separate transaction eliminating some data entry functions. This was an expensive option and very complicated to code and test.

In the beginning, the client was leaning towards the portal option based on the prodding of the IT manager. However, it was obvious that they didn’t have the IT staff to support this type of functionality. The IT department consisted of one technician type person (Manager) who had no accounting knowledge and was already “up to his ears” in daily support issues. By pushing this option, the IT manager was not staying within himself.

Since we were already experiencing other implementation task completion issues, this didn’t seem like a good choice. While it took some cajoling, the client finally agreed to the customization. As it was, the client was barely able to test and reconcile the customization properly. In the end, everything was completed satisfactorily, and the customization effectively resolved the processing issue.

The portal option would have been a very expensive and, in my opinion, a failed initiative.

Conclusion

Customizations should be used only when absolutely needed. Explore all other options before going down the customization path. Choose the option that best suits your needs. Test and reconcile until you’re sure everything is OK and remember to stay within your company capabilities.