Baseball great Yogi Berra used to say, “If you don’t know where you’re going, you might not get there.” This quote has survived through the years because it holds an undeniable truth: you need to have a goal in mind, or you’re likely to miss your target.
This saying can be applied to countless circumstances in life, and an ERP implementation is no exception: before you commit your time, resources and money to an ERP project, you need to have a clear picture of where you want your business to be in the future.
The Beginner’s Guide to Digital Transformation
What are the 6 secrets to digital transformation that are helping organizations build competitive advantage?
The first step in determining where you want to be is to understand where you are. This necessitates the documentation of ERP requirements.
Contents
8 Benefits of Software Requirements Gathering
1. Risk Mitigation
Some companies expect that implementing an ERP solution out of the box will transform their business. However, our experience and research show that a contributing factor to ERP failure is a lack of focus on business process management.
2. Process Improvement
While many companies implement software systems with the intent of improving business processes, they often end up with an ERP software solution that replicates their legacy system’s inefficiencies.
When we work with clients to improve their processes, we emphasize the importance of understanding employees’ pain points. We also help clients identify inefficiencies by using Six Sigma, value stream mapping and other business process management tools and methodologies.
3. Documentation and Clarity
Another advantage of requirements gathering is process documentation. Many companies have little to no process documentation – no statistics, no process flows, not even job descriptions for the roles in each department.
This often happens as a result of having a highly tenured workforce. While a tenured workforce can be an overall asset, it can be difficult to document processes because everyone works from what’s in their brains.
Process documentation of current and desired state processes reduces the amount of time needed to train employees. We recommend documenting processes in a way that defines who is impacted and how, so you can define a training strategy and ERP communication plan.
Process documentation also can help you propose new processes to executives and end users. This helps you achieve organizational alignment around project goals.
4. Employee buy in
When employees start hearing about an upcoming ERP project, they generally become fearful. While resistance to change is a common phenomenon, you can mitigate it by involving employees in requirements gathering workshops. This can mitigate change resistance because employees are less likely to resist changes when they are allowed input into process changes.
We recently conducted process mapping workshops with a company specializing in government subcontracting. Employees and executives were so excited about the future state processes they designed that they turned the process maps into giant posters for display in executives’ offices. This is an example of how employee involvement can lead to employee buy-in.
Requirements gathering workshops also are an opportunity to document change impacts for specific departments and roles. This enables you to develop a comprehensive change management plan to prepare employees for change.
5. Competitive Advantage
While some processes, such as general ledger, are not sources of competitive advantage, other core functions may differentiate your organization from competitors. For this reason, it is not always advisable to adopt out of the box functionality that easily can be replicated by others in your industry.
Requirements gathering identifies processes that need to be maintained and protected from standardization. This is important information to have when headed into an ERP selection.
6. Successful ERP Selection
Many vendors oversell their software’s industry best practices. While their software may improve business processes, they still need to be defined in the context of your company’s operations.
Let’s say your company has found that the most efficient and cost-effective pick, pack and ship method is to print labels for customer orders, pick according to the labels and load shipments directly onto the truck.
However, the software you’re considering employs a “best practice” for pick, pack and ship that is quite different. Instead of being a best practice, this method would be a step backward for your organization.
The problem with gathering software requirements after purchasing software is you’re faced with a tough decision when the software can’t meet a must-have requirement:
1) Invest millions of dollars in reconfiguring your company to account for the vendor’s best practice
Or
2) Spend considerable time and money customizing the software to accommodate your requirements
To avoid this dilemma, we recommend gathering requirements before software selection and using those requirements to write ERP demo scripts.
7. Faster Implementation
Most modern enterprise systems are flexible, so even a simple workflow is likely to have multiple variations. In cases like this, it’s not enough to say you’re simply going to adopt the software’s processes.
If you do this, technical consultants or the software development team will have to make decisions for you, which is costly and time-consuming. It’s more cost-effective to make process decisions on your own dime.
8. Understanding of ERP Success
Requirements gathering is an opportunity to define key performance indicators that allow you to track your achievement of business benefits. This is important for tracking benefits during implementation, determining your ROI after implementation and continuing to realize benefits for years to come.
9 Tips for Requirements Gathering
1. Understand Your Business Goals
These often include goals regarding real-time data or the customer experience. Whatever your business goals might be, it’s important to define them. While you might think that all parties understand these goals, they should be clearly documented so everyone is on the same page.
When all stakeholders are aligned, this enables the project team to determine what process changes are necessary to achieve business goals.
2. Involve the Right People
The people involved in requirements gathering should be subject matter experts (SMEs) with an in-depth understanding of the processes within their own departments.
It’s important to remember that the SME is not always the manager. While a manager might tell you how a process should be done, an employee who has actually performed the process might have insight into what actually works best.
We recommend including SMEs from every functional area, so you can understand pain points and inefficiencies across the organization. A cross-functional group will ensure you don’t record repetitive requirements. This also helps you garner the perspective of different people with the same inherent issues.
Your requirements gathering team is an important part of your ERP project team and ideally will be involved in other implementation activities, so it’s important to choose a team with the right personalities and skillsets.
3. Develop Workshop Guides
Prepared participants result in productive meetings. As such, it’s important to create and deliver workshop guides that tell participants what to expect during the workshop and provide questions for them to mull over beforehand.
We use workshop guides with clients because they help establish a common goal and keep participants focused.
4. Start With Process Mapping
A process map for a particular process might look like this: “Receive order from website EDI > transfer order to picking > deliver product.”
Requirements, on the other hand, look like this: “The ability to integrate with third-party website EDI; the ability to display a list of products that need to be picked from the warehouse; the ability to mark products as picked; etc.
As you can see, the ERP requirements flow from the process map. You can’t document ERP requirements without first mapping your processes.
5. Don’t Forget About Process Improvement
As mentioned earlier, business process reengineering is an essential step before software selection. This is because ERP software is simply a tool used to enable process improvements, not force them.
While improving your processes, we recommend using Six Sigma tools to define your own best practices and competitive advantages that you don’t want replicated by industry peers.
While ERP vendors may provide best practices for your particular industry, you also should look at best practices from other industries. In fact, examining process improvement and technology trends in other industries may help you beat your competition.
For example, RPA software is effective across a variety of industries as it helps make repetitive processes more efficient. This type of software can be implemented into an existing business model to improve the functionality of semi-structured processes, like data migration.
It’s important to consider how different industries are using technology like RPA, so you can determine new ways to improve and scale your processes.
6. Prioritize Requirements
No ERP system will address all your requirements, so you must determine which are most important to your business.
There are many ways to prioritize ERP requirements, as described in an earlier blog post, but here are three useful categories:
- Must-have Requirement: This will provide significant business improvements.
- Value-added Requirement: This will be beneficial to improving processes but not critical.
- Nice-to-have Requirement: This will make employees’ jobs easier, but it won’t provide significant process improvement.
7. Allocate Adequate Time and Don’t Waste it
Requirements gathering can bring additional responsibility to already overworked employees. As such, it’s important to stay focused on the goal. There’s a fine line between being thorough and allowing a free-for-all discussion that wastes time.
Requirements gathering workshops typically take between two to three hours per functional area. It’s better to over-estimate the time necessary in order to eliminate the need for a follow-up session.
Follow-up sessions tend to break the flow of thinking and collaboration. This can result in weaker requirements. The exception is follow-up sessions conducted after all requirements have been gathered. These follow-up sessions are actually useful as they can bring more clarity to any confusing requirements.
8. Ensure the Right Level of Detail
Take a simple task, such as order entry, and ask questions about it to identify who will execute the work, what’s the expected outcome, etc.
Sample Questions to Ask About an Order Entry Process
- How do we receive orders (EDI, fax, hard copy, phone)? What percentages does each account for?
- How many orders do we receive every day?
- Who receives the orders?
- Are the orders edited?
- How many active customers do we have?
- How many orders do we receive from new customers?
- How many orders fail in EDI?
- How many orders cannot be entered without further research?
- How long does it take to enter an order?
- How many orders fail credit checks, and how long are they on credit hold?
- What is our processing time from receipt to shipment?
- How many orders have multiple lines?
- How many orders can be filled complete on the first pass?
- Can we promise ship dates at order entry time?
- Can we verify pricing at order entry time and match to the price the customer sent?
Essentially, you want to document the end-to-end processes, including all the handoffs and touchpoints. We recommend organizing processes into swim lanes according to the responsible employee or department.
9. Follow-up
A follow-up session need not be a lengthy session, but it should go through every technical and functional requirement to verify that each was understood correctly. All the same stakeholders should be included, so they can validate that what you put on paper is what they meant.
Business Requirements = Business Benefits
Companies that take the time to define their business requirements before ERP selection are more likely to realize measurable business benefits from their ERP projects.
However, requirements gathering is complex and time-consuming, so many companies forgo it to accelerate their selection. Still, some companies take the time to gather requirements and often hire ERP consultants to ensure a more seamless requirements gathering experience.
Panorama’s ERP consultants take the time to understand your company’s competitive advantages and business goals. We assist in mapping your current state and future state, and we make recommendations from not only your industry’s best practices but also other industries’ best practices.
Most importantly, we ensure ERP vendors understand your list of requirements and ensure they deliver ERP demos that help you select the best solution.
