ERP and best practices

The IT industry initially adopted the phrase 'best practice' defensively to justify functionality gaps in their systems. For example, when their software was criticized for only offering standard costing, and not the actual costing that many companies prefer, they responded that standard costing was 'best practice'.

Likewise, when criticized because their software issued all materials and products on a FIFO (First in, first out) basis, they replied that doing so was the best practice (we will consider later whether they were right or not). With the emergence of SaaS (software as a service), the term has had a resurgence because it is in the best interests of ERP providers to promote it.

Most ERP systems have, over the years, developed many different options to widen their acceptance in different markets but doing so has made it more difficult to deliver the 'standard' system that SaaS needs. Take, for example, a pretty straightforward transaction: a purchase order receipt.

When that is processed, the system has to consider several possibilities:

• If it is an over-delivery; is that allowed?
• If it is an under-delivery; is it close enough that the order should be 'considered complete'?
• Can the items go straight to stock, or do they need to go through quality checks first?
• At which cost should they be entered into stock; standard or actual?
• If standard cost, is there a price variance to be posted?
• Are there outstanding backorders for the items?
• Is it necessary to receive to a storage location that doesn't currently exist on the system?

That is only seven questions but it is many more permutations, and this is only one transaction type. Building a system that offers so many choices is both time-consuming and expensive, so it is clearly in the best interests of ERP providers to encourage customers to accept a more standardized system and, with that, more standardized ways of working.

Ironically, the high-profile reports of ERP failures (Lidl, Revlon, Haribo, etc) strengthen their hand because it makes it easier for them to sell 'best practice' to companies who may be wary of traveling the ERP road.

It also has the added benefit of appearing to absolve ERP providers and their system integration partners of responsibility for failure. If customers ignored their advice to accept 'best practice', then any resultant failure is their fault, and not that of the software or software implementors!

Any discussion about best practices, even before considering whether they are a good thing, has to begin by first asking if they exist, or are even possible and, to do that, it is necessary to consider things in several business functional areas. Although ERP covers many departments in a company, it may be easier, to begin with its financial aspects because, although they typically make up only about 15% of a full functionality ERP system, they are the most standardized, to begin with.

Finance was the area initially targeted by the IT industry precisely because it is a business function that is, and has to be, highly standardized and regulated. All good ERP systems offer options, though, and individual customer companies need to check what they are.

They can expect systems to offer a choice of 12 or 13 reporting periods, and to handle transactions in foreign currencies (although it is always wise to check exactly how they handle them). In addition, some will offer better options than others for, e.g., supplier invoice processing by doing things like allowing tolerances to be set on invoice quantities and prices so that trivial variances, of a few pennies, don't trigger unnecessary manual intervention.

Other options may be more important and more complex; such as when companies do credit checks. Then the definition of best practice is something that they need to check before they buy. When a customer tries to place an order and they fail the credit check, should the order be rejected or should it be accepted but at 'held' status?

And what of existing orders? Should they be allowed to progress or should they be put on hold? And, in a manufacturing company, should production be halted? And what of costing? Is standard costing best practice (most distribution and process industries would agree) or is actual costing better (most engineer-to-order (ETO) companies and job shops would agree)?

The answer to all the above questions is, of course, “it depends”. When looking at credit checking, e.g., there are two types of failure. One is when customers have breached their credit limit and the other is when they are late with payments, and those are two very different things that require very different responses.

A good ERP system recognizes that, in this case, there is no one 'best practice' so any system that only offers one option cannot possibly be following best practice. Turning to Sales; it is hard to compare ETO companies to those that sell, for instance, consumer durables from stock; perhaps via a telesales team.

Additionally, from a pure ERP perspective, some companies price their products in their local currency and convert those prices into their customers' currencies using the published currency conversion rate current either at the time of order or of dispatch. Which of those is the best practice?

Likewise, when a new price list is being introduced, is the effectivity date of those new prices based on the order date or the anticipated dispatch date? And should sales be invoiced at the time of dispatch or should they await proof of delivery? Which is the best practice?

Looking at inventory control; it is obvious that such systems have been around for almost as long as accounting systems; and for very similar reasons. Both activities are transaction intensive and, because both are rules-driven, both are relatively easy to automate using computer systems.

Most systems will do most of what most companies want but, when it comes to interpretations of best practices in inventory management, there are some things that they would be wise to check. They should be able to expect, when looking at imposing traceability at an item or product level, that they will have the choice of batch tracking, serial number tracking, or, for some items, no tracking.

But when an item is identified as requiring QA/QC release before sale or use, does best practice decree that, if an item has not yet been checked, it cannot be allocated or even reserved, or that it can be but with a warning that can be over-ridden by an authorized person?

And what of items that are approaching their expiry date: does there need to be a warning? Moving to Purchasing, some systems say that it is best practice for all purchases, or at least purchases of items that are not normal stock items, to go through a formal requisition sign-off procedure but others do not.

And, when receiving, some say that it is best practice to disallow over deliveries without first amending the purchase order quantity, whilst others allow a percentage over delivery for certain categories of items. Which is the best practice?

Turning lastly to manufacturing; is it best practice that all materials for a particular job must be allocated and issued before the job starts to ensure that they are available? Or can some be issued as and when required or, indeed backflushed (i.e. retrospectively transacted at order completion)?

And is it best practice to allow issues of quantities greater than those specified on the item's bill of material to cope with expected wastage? Further: some systems insist that items are issued on a FIFO (first in, first out) basis but others recognize that different batches may come from different suppliers and allow FEFO (first expired, first out) issues. Which is the best practice?

And, whilst the job is in production, is it best practice to track it at every stage of the routing, or is it acceptable to track it at key points only? And if not all materials issued were required, can the excess be returned to stock under the original batch number (some systems, and some industries, say not)?

This blog is not intended to be a definitive list of all features that attract the label 'best practice' (nor indeed to specify what best practice is) but it is an attempt to explain why claims to best practice need to be viewed cautiously. The very phrase means different things to different people and, at the very least, companies should ask themselves just how qualified software providers and their implementation partners are to define best practices in their industry and their company.