Elsewhere on this site we have described Enterprise Resource Planning (ERP) systems, sometimes described as Supply Chain systems, and their evolution. We have also explained the key issues relating to the implementation of such systems.

One aspect of such an exercise that is worthy of further consideration relates to the selection of such a package. How should we set about deciding the correct ERP solution for our business? Are there systems with a higher reputation in the market, perhaps with a greater track record of success? Should we undertake particular activities in-house before beginning to evaluate potential suppliers’ offerings?

One complication that can arise is that although many suppliers provide implementation support for their product, some of the more sophisticated solutions are actually supported by third party specialists. The selection process in such cases has to involve evaluation of both the package and the provider – with the proviso that there will probably be the option to identify a preferred package and find an alternative source of support. (This is now an accepted fact of life with some major systems, though this doesn’t prevent the situation being less than ideal from a procurement standpoint. In other areas of business we promote the ‘one stop shop’ approach to avoid the situation where problems can lead to separate suppliers pointing fingers at each other.)

Defining System Requirements

One of the first steps in any selection process is a Statement of Requirements (SoR).

In the description of the elements essential for success in the adoption of an ERP system elsewhere on this site we emphasise one point above all others. This is not a computer, or Information Systems, project. It is an exercise in changing the way the business operates.

• After all, if we keep on working with a new system in the way that we’ve always worked with its predecessor we have made no change. As the phrase has it: “keep on doing what you’ve always done and you’ll keep on getting what you’ve always got”. In other words, the investment in the new system will bring no improvement.

• Implementing such a system is a business change project. The selection must be business-driven.

Therefore the key step in selecting a system is to define the requirements in terms of business functionality. Over the years there has been a relatively common approach to this, perhaps arising from the fact that many such selection exercises have been supported by, or even led by, management consultants. Analysing the business needs (in terms of the intended way of working) and then converting this into system terminology has traditionally been a task for consultants so it may not be a surprise that this step has been promoted. Such system terminology has included statements such as “the system must provide multi-bin location recording” and “Material Requirements Planning (MRP) must provide full sales order pegging”.

Our recommendation is not to define the system in these terms. For one thing, all such terminology is open to some interpretation and a package supplier may have a different perception of a functional description than that intended in the SoR. This means we run the risk of establishing what the business needs in terms of how we intend to operate, converting this into technical terminology and leaving potential suppliers to translate this before deciding if their package would meet the needs of our business.

So, what is the way forward? Quite simply, define how the business will operate. The second of the examples cited above may be interpreted by some package suppliers as the ability when looking at a component requirement to drill into the system to establish which finished product demand (sales order or Master Production Schedule record replenishing warehouse stock) will ultimately be satisfied by the planned component supply order (often called ‘soft’ pegging) or it may be taken as the requirement for the system to allocate (or ‘hard’ peg) the component order to a particular end requirement.

Why leave this open to translation? Why not just say “we make finished products from castings where the customer may attend non-destructive testing sessions at the supplying foundry and take away the certification for the item in question; we therefore need to ensure that the purchase order record for the casting can carry the sales order details and that thereafter the casting used on the customer’s order is the one for which the customer has the certification”. The potential package suppliers can then ask themselves how their offering could meet this requirement. Some will say “yes, our hard-pegged, contract-specific MRP meets this need”, others may propose a work-round involving the creation of a unique part number for the order in question and others will decline or at least admit that they can’t meet the requirement.

(The way that package vendors respond to such business-based statements can also be used as part of the evaluation process. If their team look blank while such matters are being debated then this raises questions about their ability to support the implementation. Sadly, while many people now recognise ERP implementations as exercises in business process improvement, there are still suppliers whose consultancy / support teams come with an IT background and whose interests lie in the bits and bytes of the software rather than in its business application.)

Education & Training

Is the first step therefore the definition of business requirements?

Actually, probably not. This may sound strange until we ask ourselves how we intend to define these requirements, bearing in mind that we are defining the future rather than the present. (Once again, we are undertaking an exercise to change the way the business operates. We must resist the temptation to define how we currently operate and hold to the more difficult task of defining how we wish to work in the future.)

So, who will define the requirements? Hopefully as broad a forum as possible, with ownership clearly established within the key players in each process area. This means that we need a critical mass of people fully knowledgeable on what constitutes best practice. Evaluation of many organisations reveals that the number of people who really are fully aware of the latest techniques and their implications – pros and cons, areas of suitability or otherwise, resource requirements and inter-dependencies – is less than ideal. A natural extension of this is that before asking people to specify how the business should operate, they should be brought up to speed.

We would suggest there are, in general, three areas to be considered:

• The detailed elements of ERP. In a business using the system to manage demand and supply, planning procurement and production, this will run from master planning (Sales & Operations and Master Production Scheduling) and Sales Order Management through MRP or other component planning approaches to detailed scheduling, capacity planning and management of work and purchase orders together with inventory control and any other elements of the system that may be under consideration. This may include financial ledgers and their interfaces with sales orders, purchases, shop floor bookings and the fixed asset register. The Human Resources (HR) module may also be under consideration and the owner of the processes in that area will need to be aware of the tools available.

• Lean. Many aspects of Lean operations – in particular, Lean manufacturing, if the business is in that sector – may present apparent alternatives to the approaches offered by ERP or, for example, Advanced Planning and Scheduling (APS). The most obvious questions for the team responsible for defining the approach to scheduling are firstly “can we lay out an area in simple cells that can be managed entirely using the methods of ‘drumbeat’ and ‘Kanban’?” and then “if we need a system-based scheduling tool, should we adopt order dating in MRP followed by (infinite) Capacity Requirements Planning or do we need a finite scheduling tool?” (Other elements of Lean, such as 5S, TPM and SMED have little or no impact on ERP – but the people in the appropriate areas should still be knowledgeable.)

• Business Process Improvement / Management. As described elsewhere on this site we would contend very strongly that the majority of elements of best practice promoted heavily within BPI, then under the Reengineering banner and more lately as BPM, are simply the application of Lean under another name. However, many approaches to Lean are viewed as being limited to manufacturing areas and where this is the case the determinants of success cited within, for example, Reengineering The Corporation, have to be fully taken on board. This leads to questions like “how many steps do we want in the function of moving from a finished product being booked into stock to the despatch being processed? Do we want a report telling us which sales orders can be picked, followed by a ‘pick’ transaction and automatic creation of despatch notes, or do we want to use a copy of the despatch note to initiate picking?” The goals of reengineering, such as minimised numbers of steps and handovers have to be borne in mind by the team defining the future.

• Development of this ‘future vision’ is not a task to be rushed. Workshops, in which the various members of the team and other key players in the business map existing and future processes and consider the implications, need to be carefully managed. When people question the amount of effort allocated to these workshops they need to remind themselves that this is a great opportunity to radically improve processes. It will be very difficult (if at all possible) and expensive later.

Selecting Potential Vendors

There are a number of ways of running through the current supply base for ERP solutions. The Evaluation Centre provides the latest information on a range of system categories, of which ERP is one. Articles in magazines such as Works Management and Manufacturing Computer Solutions can also provide valuable information as can publications of professional bodies such as the Institute of Operations Management and the Chartered Institute of Purchasing and Supply.

There are also a number of events at which software vendors set up stands to demonstrate their offerings – though fewer in times of recession. Project teams attending events such as ‘Manufacturer Live’ and the ‘Computers in Manufacturing’ show can learn a lot, but must be warned not to expect to be able to move towards a solution. Some software companies are better at setting up for a forum to promote their package and they will highlight what they believe to be the selling points of their systems; delegates have to recognise that the selection of a system has to be based upon the vendors’ response to their own requirements and not on the slickness of a standard demonstration.

Producing The Invitation to Tender (ITT)

The ITT should comprise a general introduction to the business and the approach being taken over package selection and contract negotiation, together with the SoR. It should explain the format to be taken with tenders in order for offerings from different vendors to be compared relatively easily.

The potential vendors should be told very clearly that their response should certainly include formal ‘yes, our system does that’ statements - or ‘qualified’ confirmation where the system could meet the requirement through customisation or could meet the business need through a different approach. In the case of the approach being proposed differing from that in the SoR the vendor should expand on this, explaining how the business process upon which the system design is based meets the vendor’s perception of the business need.

Some package vendors will respond with a proposal clearly aimed at addressing the business issues presented to them and this should be recognised as a strength. Others may quickly drop into promoting technical features of their offerings – things such as XML, open source databases and SQL – rather than business functionality. While up-to-date technical features are, of course, essential, this may indicate a vendor whose understanding of ‘best practice’ business functionality is less than perfect. Some systems utilise the absolute latest in database, transaction, display and other technical elements but impose inappropriate ways of working. ‘Tail wagging dog’, perhaps?

System Presentations

Only a limited number of potential offerings should be taken to the presentation stage, quite simply because the evaluation process is demanding upon in-house resources – the project team and all key managers should be involved in this, fully understanding the systems under consideration and playing their part in the final selection. These presentations should be thorough (and thus time-consuming affairs) with the potential vendors demonstrating to the in-house team how the organisation’s requirements are met and with the approach under consideration being subject to fairly extensive exploration.
Again, some package suppliers will try to use these presentations as the opportunity to highlight what they see as strengths of their system. This has to be avoided – as a family selecting a car to cater for regular camping trips with three teenage offspring and two Labradors would want to see practical, usable space rather than paddles for gear shift in a short wheelbase coupé. Changing gear like a Formula One driver may appeal and a salesman may promote this idea but if the car in question fails to meet the basic requirement then the buyer would not waste time exploring such a feature.

As noted earlier the system presentation is also a good opportunity for the project team to evaluate the package provider. If the team presenting the software demonstrate the ability to quickly grasp the business need and engage in debate around the key requirements then this sends a signal that the supplier will probably be able to provide good support.

Obtaining References

As with most selection activities, references are an essential feature. Ideally this would involve the opportunity to visit and see the package in use in an organisation with similar requirements to our own. This should then involve discussions with key players in the other organisation on the quality of services provided throughout the implementation and on subsequent support. Visits should be made to businesses that have completed their implementation some while ago and have surfaced through the problems; it matters little if this is not the latest version.

Contract Negotiation

Most package vendors have standard supply contracts and are reluctant to make concessions on key terms of supply. To be fair, we have rarely seen terms which are particular unfairly to the customer, but as with all contracts, the detail needs to be examined.

• One example in our experience related to a deal with one of the software ‘first division’, a household name, who included a clause that if our client recruited one of the software consultants they would have to pay the software company three months’ salary for the person concerned as a hiring fee. While in practice this wouldn’t happen (our client would be unlikely to be able to afford a highly-paid software consultant and would certainly struggle to absorb someone at that sort of salary level without causing a mass walk-out of all but the senior management team) the point of contention was that there was no equivalent constraint on the software company. We added a reciprocal clause (“you can’t pinch your customer’s staff without paying 25% of his or her salary”) and they objected – the sales manager thought three months was reasonable but 25% excessive . . .

• In fact at that time such restraints on the movement of staff were already illegal under EU law. When the software company did offer one of the project team a role some time later we secured such an arrangement not by the threat of going to law but by asking what sort of signal we would send by explaining to the wider world how one of the major problems in implementing this package was the fact that the project team would be disrupted at key points in the exercise by the vendor taking project team members away. “Might this have a detrimental effect on new business?” we asked.

Every effort should be made to ensure that the contract is as clear and unambiguous as possible (within the constraints of legal communication). Although the vast majority of implementations begin with the ‘sales contract’ from the supplier (after all, they do this thing all the time; customers do not have standard system purchasing contracts to hand) the contract submitted should always be referred to the in-house legal team or the company’s external lawyer. The implementation of a business system of this nature is one of the most important exercises any organisation can face and the supply contract is one of its foundations. The supplier’s standard document will normally be a good basis but annexes covering such issues as Service Level Agreements, timescales, price schedules and so on may be of value.
A key point in package supply is to achieve as close as possible to fixed costs for implementation support and, should it be necessary, customisation. One of the important factors in this is to examine areas of possible weakness with regard to the business requirements before entering into a contract. Basically, all such issues will be resolved by package specialists debating the process requirements and exploring options within the package to meet the needs. The goal has to be to have as much as possible of this work undertaken as a (non-chargeable) pre-sales activity.