Adding Value to your ERP Requirements

ERP Requirements Refinement

When you start a system selection, you first need to determine which business process are the “value add” processes. In other words, which processes in the business add to the value of the service or product you are providing to the market. The customer is only willing to pay for those activities that help you produce, ensure quality, or account for your product or service. All other activities are waste.
ERP Requirements

When defining your ERP requirements, you need to be cognizant of these “value add” activities. These are the activities that should be captured in your requirements. Non-value-add activities should not be included in your ERP requirements. These do not produce results that create additional value to the product/service and these are only distractions when it comes down to the actual implementation.

ERP Requirements and Lean

All of this comes from Lean Manufacturing or the Toyota Production method. Essentially, as stated above, you want to eliminate “Muda” or waste in the process. Many firms have successfully implemented this in their manufacturing processes, but a smaller group have implemented this Lean system in their business office processes.

Consider this example. When defining your ERP Requirements you determine that there is an accounting process that has people spending 2 man days per month reconciling the cost of keeping track of the tools used in manufacturing. Does this process add any value to the actual production of the product? Possibly, but it sounds like this process can be reworked and possibly using the new ERP system you can eliminate this process and drive the data down to the actual transactions on the shop floor. You don’t need accountants researching the transactions. What you might need is a system that tracks the tools and their usage as part of the production process and can give a report on what these transactions cost. These transaction costs can then be factored into the pricing of the product, without the overhead of 2 man days of reconciliation.

The time when you are defining your new ERP Requirements is the perfect time to start looking critically at your processes and keying in on what brings value to the process. Then you can design your new system (both process and software) around those items that bring value to not only the customer but also the bottom line.

Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated

Mapping your ERP requirements

When you are cataloging all of your ERP Requirements, you should write down all of your requirements (perhaps on a spreadsheet) and then give them an identifying number (such as R1, R2, R3, etc.) You can then evaluate each of these requirements with the business team to determine if the requirement is one that you want to carry forward into your deliverable of requirements that will be provided to the ERP software vendors. There is an excellent article on how to do this mapping, by author Brett Beaubouef, that describes this process.

He advocates that “Starting with the desired business results ensures that we drive to only those requirements that directly support true business value. First, it is an exercise that really puts into perspective the purpose of a business model (results). This exercise is not only useful to the project team but also the business stakeholders. Second, it is an approach that can help you justify why certain existing business activities are not being carried forward in the new business solution. Third, taking a business results oriented approach enables your project team to be more successful at focusing on the right business requirements and not wasting time on capturing requirements for non-value-add activities.

Another useful article that you may want to examine is the article 7 Ways to Fail in an ERP Selection

Keep in mind that some ERP Requirements that you identify may not seem valuable at first, but you need to review these requirements with the functional user team to ensure that key processes are not eliminated by mistake. There may be requirements that are a requirement because of a legal concern or perhaps a health and safety issue.

In the end, if you have successfully mapped out your business processes and defined these in your ERP Requirement list, then you will be a lot closer to selecting a system that actually functions in a way that brings value to everyone.

We hope that this will aid you in better defining your ERP Requirements.

Implementing ERP Systems begins with the Selection

Chris Shaul

There are two major parts to implementing an ERP system, the selection and the implementation. The selection of the correct software is key to implementation. Selecting the wrong software can kill an implementation or at least make the project very expensive and overrun the budget. Be careful when selecting a new system. There are basic steps to a system selection.

Systems selection entails first detailing your requirements. You can do this in a spreadsheet that is divided into various worksheets for each business function. Then identify the critical success factors that the system must meet in order to be successful. You will also want to document your basic business flow to get a product or service to the client. This should be from the initial contact to the client paying for the product or service. Once you have this criteria, then you can begin looking at software.

To find the best software, you can use google to search for the vertical market place of software that you belong to. For example, you can use the search “manufacturing erp” or “distribution erp” to find the candidate software systems.

Draw up a long list of about 10 vendors that sound like they have the modules and features that you are looking for. Then start calling these vendors and talk to them. You can even arrange web demonstrations for you to get a look and feel of the software. Of course every vendor will tell you that they are the best and that they can answer every one of your needs. The trick is to have them demonstrate your requirements through a business flow of your own design.

After discussing your needs, you should have a good idea of the capabilities of the vendor. Some you will be impressed by and some you will not want to speak to again. Develop a short list of 2 to 4 vendors. Then develop a scripted demo for them to provide to you. The key is for you to develop the demonstration, not the vendor. They will only show you their best features. You want to see them demonstrate your business process.

Once you have seen the vendor’s demonstration, then you can check references and negotiate pricing. The key things to remember is that you must have your own requirements defined and the vendor must demonstrate your business flow. If they are successful in meeting your requirements and showing you that it can work, then they can be a viable candidate and you can feel somewhat assured that you are going to implement a software that is compatible with your business.

Chris Shaul is a Sr. IT Consultant and specializes about ERP selections and implementations.