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.
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:
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?
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.
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.
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.
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.
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.