People often take their ERP selection criteria for granted. They gather functional requirements put them into an organized list and then blast it out to ERP vendors as a Request for Proposal (RFP). The problem is that while they have collected the shopping list of requirements for their company’s new ERP Software, they have not defined exactly what it is that they are trying to get out of the software.
With an ERP selection (or any business software for that matter), the team needs to gather the functional requirements and document them. However, today’s software is sophisticated and can typically handle a majority of things that companies need. There is the age-old rule of Pareto’s Principle that 80% of the effects come from 20% of the causes. Applied to selections efforts, 20% of the requirements you have are key to the successful outcome of your selection.
Let’s look at this in application. If you go to each department in your company and ask, “What do you need in a new system?” you will get a laundry list of wishes and good ideas. So then you write them all down and send it off to the software vendors to decipher. The vendors then have to spend a week or more deciphering, interpreting, and answering all of these requirements. It is a burden to them and does not bring value to the process.
Using the Pareto Principle, we can see that 80% of what is gathered adds no value. For example, you ask for a system requirement such as “The new software must be able to process Accounts Payable checks.” This is a worthless and time wasting question. A key function of an accounts payable system is to process payments. Have you ever seen an Accounts Payable system that could not process checks?
The real question in gathering requirements is “What makes your business unique and successful?” What do you provide in your process that adds to customer value? This comes from the Toyota Production Method (TPM or Lean Manufacturing principles) that states that a process needs to add value to the product or service that the customer pays for (or for safety or to fulfill a regulatory requirement). If a process does not add value, then why are you doing it?
Using the example above, a better question would be “The new software must be able to process electronic payments to shorten the procure-to-pay cycle.” By using electronic payments, you can get your vendors paid faster that then shortens the time between purchasing the materials and paying the vendor. This then allows you to speed up your procurement process. Shortening the process can result in higher inventory turns and ultimately reduce costs. Ideally, these costs are passed along to the consumer resulting in more value in your product.
If you gather your requirements with this concept of added value and the uniqueness of your business process, then you will glean more effective requirements and more than likely you will not have a shopping list, but rather a targeted set of requirements that define who you are as a business. Another TPM concept is the idea of “muda“. This means waste. In your processes, where can you drive out waste? This holds true to your software selection criteria. Where are there wasted questions that provide no added value to your search?
If you wish to save time and money in defining your selection criteria, then approach the questions from the perspective of defining your unique processes that make your company successful. You ultimately want to drive value to the customer in your business processes. This is where a new system can help you. Additionally, you will eliminate a lot of time-wasting questions in your RFP. This will make the vendor’s job a lot easier, but more importantly; you can start having meaningful conversations with the vendor around how their software can continue to add value to your business processes.