Configuring ERP Systems

When computer systems started to be developed for business purposes, they were written by large organizations for their own use; making them expensive and inflexible. When companies began commercializing software, there were clear advantages to making systems more flexible, both in terms of increasing the potential market and in future-proofing the product.

Modifying software remains an expensive option, so the drive to make the software more flexible by configuring it continues to this day. Some systems offer great potential for configuration but all have limitations: so what should prospective customers be expecting and demanding when they peruse the market?

• Finance
• Sales
• Purchasing
• Inventory
• Manufacturing

1. Finance

The finance area is usually the most straightforward part of implementation because, being a highly regulated area, most companies work in pretty much the same way simply because they have no choice. Unfortunately, that can cause some companies to believe that differences between systems are primarily cosmetic or relate to peripheral things like the ease of transferring data to and from spreadsheets.

But configurability exists in good systems because there are decisions that have to be made and things that have to be checked.

Moving to a new system is the perfect time to review the Chart of Accounts and the structure of account codes. In all but the most basic of systems, companies can choose how many elements to have in the overall account code and how long each of those segments should be. Companies are able to choose between 12 and 13 accounting periods but also need to decide and specify how many prior periods can be open for transaction posting.

On the Accounts Payable side; they need to decide if they need payment authorization routines so that large amounts can only be authorized by C-level staff. In Accounts Receivable, they need to specify the credit checking rules that are to be applied during sales order entry. Should they just consider the outstanding customer balance, or should it also consider outstanding sales orders? And how many days can invoices be overdue for payment before action is taken, and what should that action be?

2. Sales

The ability to link different customer/product combinations to different General Ledger sales accounts helps with sales analysis but the main configurability relates to how products are sold. For example; a distribution company may have depots in multiple locations but will probably want to configure the system to ensure that product in its Los Angeles depot is not routinely transacted by staff in its Boston depot, and they can do this by linking customers to particular dispatch locations.

Different companies will also have differing discount structures that will have to be set up; perhaps at the customer level or even at the customer/product level. They need to specify whether the discount is to be calculated at the order level or the order line level and whether there are breakpoints for differing discount percentages or prices. And some will need to specify that period special offers, such as “Buy two of product A and get a free product B”, will be applied.

And what can get overlooked when evaluating sales order processing systems is how new prices are to be applied; does that mean that the product ordered before that date will be at the old price or just the product delivered before that date?

Also, when selling internationally, companies will need to specify whether sales will be in their native currency only, whether those prices are to be translated into the customer's currency at a given exchange rate, or whether discrete prices will be held separately for each currency.

Finally, when dispatching orders to customers, is there a percentage delivery after which the order should be 'called complete' unless the user overrides it? And does this percentage vary by product type?

3. Purchasing

'Calling complete' is also an issue in purchasing. Should the system expect the balance to be delivered if 1000 items are ordered and the supplier delivers 990? And, considering the Accounts Payable and Sales Order Processing aspects also (because ERP systems are, by definition, integrated); what tolerances should be applied (both in terms of quantity and of price) when matching supplier invoices to recorded receipts?

It usually doesn't make sense to put the payment on hold and to trigger a resolution procedure if the value of the difference is pennies.

And lastly; when a purchase order is raised, is there a formal authorization routine that limits different levels of purchasing staff to differing purchasing value caps, beyond which orders should go on hold until released by more-senior staff?

4. Inventory

A basic option is to link different categories of inventory to differing GL account codes.

Beyond that, companies need to specify the different options that they need for ordering different types of material: are some to be under reorder point (ROP) control, are others to be bought or made to order only, are minimum order quantities (or values) to be considered, how is stock to be costed (another article will discuss the main costing options: Standard, Actual and Weighted Average), and do serial number and lot tracking need to be applied to certain groups of items?

Finally, considering tolerances again; what levels of tolerance should be set against different types of stock items during stocktaking so that only significant count variances are flagged for rechecking (it doesn't make sense to send a count team back to verify a discrepancy that is insignificant).

5. Manufacturing

Unlike the financial area, where most organizations operate in much the same way, manufacturing is a spectrum, from Engineer-to-order (ETO) at one end, all the way through to continuous process at the other, and different tools are required by different companies.

Some will use MRP (Materials Requirements Planning) but that is itself highly configurable. For instance, should it take demand from actual sales orders, forecast sales orders, reorder points, or a mix of these, or from an MPS (a 'master production schedule' or production plan)?

And, when considering sales forecasts, companies will need to specify also how the system is to deal with the unconsumed forecasts – should the forecast be ignored if the anticipated sales orders haven't appeared, or should production continue and excess be held in stock to nett off against future forecasts?

They also need to decide whether the forecast for each time period (day, week, or month) is the forecast of orders expected to be received during that time period or expected to be delivered during that time period.

Another consideration, for some companies only, is Work in Progress (WIP) control. Process companies and those that operate production lines may well be happy to assume that any job started will be finished, but others may need to track jobs through different processes. These companies can have complex manufacturing routings (files that specify how items are made and what resources are required to make them) but they need to decide whether to track progress at every stage or just at critical points.

Overlapping with Accounts Payable and Sales Order Processing again: the system needs to be configured correctly to know how to react when customers breach credit limits. Should production be allowed to continue, although despatch may be blocked, or does it need to be halted?

Conclusion

Modern systems have great configurability in order to be able to adapt to different customer requirements, both on the initial implementation and later, as requirements change. So much so, that companies that are unhappy with their ERP systems are frequently actually just unhappy with the way those systems have been configured.

However; no system is totally configurable and companies are encouraged to check, in detail, before signing any contracts, that their chosen system can do all that is required of it both today and for the foreseeable future. Other articles on this site give useful and practical advice on how to achieve that.