Determining What You Need When Implementing an ERP | Velosio

This post is the fourth of our ERP implementation series. If you want to start from the beginning, or learn more about prior ERP implementation phases, take a look at:

Today’s ERP (Enterprise Resource Planning) systems, offer the user countless features and functionality. While ERP advances provide increased processing efficiency, greater control of business transactions and improved reporting capabilities, the inherent complexities require that the ERP implementation is completed in an organized and controlled manner.

The gathering and documentation of client requirements is a critical implementation task. Accurate, client approved requirements form the foundation of the Fit/Gap analysis and System Design which are the ERP implementation blueprints.

ERP implementations are controlled using a specific methodology. Many software publishers provide some type of implementation methodology for use by their VAR’s. An example implementation methodology appears below. The example consists of five phases. Requirements gathering is part of the “Requirements and Design” phase.

Client requirements gathering takes place after the implementation “Planning” phase.

Note how requirements gathering is tied into and supports the Fit/Gap analysis and the optional High Level System Design.

Best practices

In this post, we discuss some best practices to help ensure that you accurately gather ERP requirements. The document also identifies some “pit-falls” to be avoided, which often result in a less than optimal result.

Over the course of dozens of implementations, five top best practices have emerged that can positively impact the requirements gathering process:

Executive ownership
Use a quality requirements template
Understand current processes, workflow and reporting
Align your resources
Stay within yourself

Executive ownership

Visible executive ownership is the number one success driver across all ERP implementation phases. Employees look to company executives for both direction and a sense of the importance associated with company initiatives. If the Executive Team doesn’t take the project seriously, chances are that the Project Team won’t either.

To learn more about the value of executive ownership take a look at Preparing for ERP Implementation: Getting Started on the Right Foot.

Use a Quality Requirements Template

Requirements gathering is essentially a “knowledge transfer” between the client and the VAR’s consultants. This knowledge transfer results in a large volume of information and data being transferred back and forth. Data control and organization are critical attributes of an accurate information transfer.

Standardized requirements templates and worksheets should be used to control transferred knowledge. Quality documents and worksheets organize the process, are designed to identify detailed requirements and help make sure that the client and consultant do not miss anything and “are on the same page”.

Prior to the requirements gathering process, search the web and review one of the numerous requirements templates and worksheets available. These tools organize the requirements information that generally needs to be communicated, and can also help to reflect and focus on the requirements themselves. The tools are usually segmented by ERP module. To save time, review only the modules that you plan on implementing.

Find and save the tools you like, then ask to see the VAR’s requirements documentation samples during the pre-sale process. The VAR should be able to easily provide them. Compare the VAR documentation to the tools you selected.

A good rule of thumb here, is that if you’re unhappy with the VAR samples provided, have the VAR use your tools. If they resist, consider another VAR. In my mind’s eye, effectively gathering requirements is paramount to an implementation’s success, and you’ll likely be unhappy with the implementation result, if the requirements gathering process is not adequate.

Review the document to be used with the VAR and Project Team prior to the project kick-off and requirements gathering sessions.

Understand current processes, workflow and reporting

With the exception of an ownership transfer, or perhaps a discontinuance of application support, not many companies implement a new ERP because of their happiness with the current system. ERP’s are purchased and implemented to streamline transaction processing, increase functionality and control, and to improve reporting.

With that being said, you’re probably wondering why I’d recommend that a discussion and understanding of current processes and workflows is a good idea, when they may be replaced or modified by the new ERP.

On the surface, that logic seems to make sense. It’s essential though, that the consultants installing the ERP understand the current environment up front. Understanding current processes, workflows and reporting provide a firm foundation for requirements gathering Fit/Gap analysis and the system design tasks that follow.

Reviewing the current environment helps mitigate the chance of over-looking a key process or control. Reporting is a particularly vulnerable area.

Complete the review for critical processes and reporting only.

The most dangerous word in requirements gathering is “assume”. I’ve seen companies invest thousands of dollars implementing an ERP solution and then just assume that certain functionality, controls or reports are available out of the box. They find out too late that what they assumed the system provided out of the box is in fact not standard functionality at all. A good practice when documenting the current environment and gathering requirements, is to assume nothing and validate everything.

Align your resources

An ERP implementation utilizes resources from many different company roles. It’s important that each resource understands their role and that all resources are moving in the same direction. Setting goals and objectives prior to the requirements gathering phase assist in this process. If you haven’t set goals and objectives, see Preparing for ERP Implementation: Getting Started on the Right Foot for some insights on this topic.

Be sure to keep goals and objectives consistent with the actual need to achieve them. Let’s use the loading of historic data as an example of a misguided goal. A company may want to load a large volume of detailed historic data. What it forgets to consider, is that the data needs to be scrubbed, converted, tested, loaded and reconciled. All of these tasks need to be completed by the Project Team before “Go live” and can quickly become unmanageable.

Unrealistic goal setting results in budget overages and usually, the inability of the company to achieve its goals. Be open minded and think out of the box. There are usually alternatives that can be explored and used more efficiently.

Create Project Teams from each functional area. Assign goals and objectives to each team and designate a Team Leader (AKA Project Manager). Support the Team Leader with authority commensurate with the responsibility assigned. A Team Leader cannot be effective without equal levels of responsibility and authority. If you’re going to hold the Team Leader accountable, then supply them with the tools to be effective.

To learn more about effective project management see Project Management What level is right for your ERP project?

Team Members may differ between the requirements gathering process and other implementation phases. Match Team Member strengths to the assigned tasks.

Build your teams with members from different levels in the company. In many instances, staff level employees have a better understanding of day-to-day processing and issues than more senior personnel. Of course, managers and other executives are valuable team members, but I’ve regularly experienced situations where they are not up to speed on the current day to day situation. This can have a negative impact on the alignment of requirements to true company needs and often results in having to re-do completed tasks.

Stay within yourself

Anyone who has played an organized sport is probably familiar with the term “Stay Within Yourself”. Coaches use it all the time to remind players not to try to perform at a level beyond their capabilities. Trying too hard usually results in errors, poor decisions and a less than desirable outcome.

The same concept applies when defining ERP requirements. Be sure that you match the requirements to those which your company can reasonably support.

I can’t tell you how many times I’ve been involved in projects where the staff is small or inexperienced and obviously overwhelmed in their current environment. In spite of this, Project Leaders are defining requirements which couldn’t be achieved in the best of circumstances. The Project Leaders are not staying within themselves.

Most of the time cost, inexperience or “empire building” drives this behavior. While I understand how this comes about, I’m being totally honest when I say that in the vast majority of instances, this kind of thinking does not succeed. What usually happens is that so much time is spent on unrealistic requirements, things get overlooked, errors are made, and the system never gets built out to its full potential.

Here are some examples of not staying within yourself:

·        “Just install the software and train the IT department. They’ll complete the implementation”.

·        “We need 10 years of detailed transaction history loaded for the GL, AP AR and Inventory”.

·        “Just show us how the reporting tool works and we’ll write all of our own reports”.

·       “Our IT guys will “tweak” the code themselves to achieve that requirement”.

Stay within your skillset and capability! You’ll be happier in the end.

Conclusion

An ERP implementation is challenging, and the implementation doesn’t end with requirements gathering. However, accurately completed, client reviewed and approved requirements are an important first step in building an effective system design and keeping the project on track.

Streamline the requirements gathering process by using a controlled set of quality documents and processes, working smart and by considering some of this post’s best practices.