top of page
Search
  • Writer's pictureJeff Stevens

Defining Business Requirements Prior to Software Evaluation. Mission Critical?

Updated: Jul 31, 2018

You’ll often hear or read about the importance of defining key business requirements prior to evaluating or selecting new ERP software. But how crucial is it to fully process map and define your business requirements prior to selection? The answer is “it depends” which is a bit of a controversial opinion. Understanding your business requirements is always going to be important. You don’t want to end up with a four-cylinder engine when you need a V8. On the other hand, time is money and process mapping means defining the steps, inputs and outputs of each process in intricate detail. The answer of whether to take this path depends on different criteria, but let’s consider and focus on the following three:

· How many truly critical business requirements does your organization have?

· Do you fully understand the capabilities of newer ERP software?

· Will you need to engage software vendors in a detailed request for proposal (RFP) or a take a path that focuses more on just critical business requirements?


Focusing on Critical Business Requirements

This approach directs everyone’s efforts, including vendors, on only what’s important to the organization. The “less is more” approach can be very effective when laser like focus can be directed to a smaller number of more specifically articulated requirements. This allows vendors to strategically target solutions to address your needs and tests their ability to accommodate your critical needs. The choice to focus on a smaller number of key requirements and the specificity that is built into each one, will undoubtably allow for improved differentiation between vendor demos and offerings.

So, what defines or makes a business requirement “critical” or “important”? Typically, think of requirements falling into one or more of three following broad categories:

1) A differentiating service attribute or product or manufacturing spec that sets you apart from your competition giving you marketplace advantage

2) Requirements due to industry regulations or business mandates (must-haves needed to run the business)

3) New process requirements to facilitate a new business process/offering having significant different future state implications (think large-scale change or transformation)

Focus on what’s truly important and evaluate solutions on the most critical requirements and you’ll likely find your path to a clearer final consensus decision.


Understanding the Capabilities of Newer ERP Software

If you haven’t researched ERP software in several years plan to do homework or get a crash course from a qualified consultant. We often find that businesses commonly go 10 or more years between doing major updates/changes to their ERP systems. Expect big improvements in both flexibility and functionality of newer software.

This topic could be a blog on its own, but let’s just touch on a couple of major points to consider. New ERP software is flexible in ways you might not expect. New software can handle things your old system might have had a tough time performing, or you would have had to customize. With this flexibility come “choices.” Bottom line, modern ERP software is highly configurable. To that point, you’ll need to know how you want your business processes to run on the new software. There will be decisions to be made. You don’t want to be making these decisions when your VAR is configuring your software and the money clock is ticking. The takeaway point … you’ll need to understand both what the software can do as well as how you want your business processes to work.

A second consideration is the realization that new software will often come in encompassing packages. In the past you may have had to link disparate software together to form your ERP system. Today’s software is wider reaching. As an example, many software packages will come with an Accounts Receivable (AR) Module. The AR module may not look like your current system, but in our opinion, it may be a best practice to use it. In this example your business process will be defined by the software. That’s not a terrible thing because the software will accommodate invoices, ending periods, transactions, etc. AR is pretty consistent among businesses and an unlikely differentiator for your business. Save your software customization dollars for those functional areas that will grow and differentiate your business.

To recap, new ERP will have some decision forks where you’ll need to know how you want your business processes to work within the framework of the new software. Additionally, there may be modules that you may want to adopt “as is” because they are offered as part of the software and already thoroughly vetted.


Will You Need an RFP?

An RFP by design is intended to provide a comprehensive definition of an organization’s business and related requirements. This approach is designed to broadly document the volume of requirements to effectively achieve an evaluation comparison using an analytical approach. When designing an RFP, organizations should prioritize each defined business requirement based on relative importance ranging from critical to nice-to-have. Typically, this tool is used to define as many requirements as possible across functions, including technical requirements. The result can often equate to hundreds or thousands of individual business requirements. This brings up some valid questions. Does your company understand the actual cost of designing and running a detailed RFP? Do you have the internal expertise to ask the right questions and know if you are getting straight forward answers?

Vendors also face challenges when completing RFPs. When answering an RFP, a vendor is challenged with consuming, understanding and appropriately responding to an intricate level of detail. There is also a considerable time investment required to build very detailed solutions to be used in demos. So, depending on the size of your company and engagement, be realistic that you may have vendors that will decline to respond.

For your company, this deep level of detail can be a struggle to effectively understand and differentiate between vendor offerings. Communication can easily get muddy as your primary focus may also be to run your business. It’s not unusual for key requirements to get lost in the demonstration or only get partially addressed. Does the currently available software really do the function as demoed, or is the vendor showing a simulation which may require customization? It’s not uncommon for software vendors to show software that is under development but may not be available in a current release. While narrowing the scope of your RFP can help, if you choose to go this route consider employing the help and guidance of a software selection consultant. In doing this you will be augmenting your internal bench strength with an unbiased ERP expert that only has your company’s best interest in mind.


In Conclusion

Is defining detailed requirements before choosing software mission critical? Organizations either on their own or with help of a third-party consulting partner will continue to tackle this question in a way that best fits the business. Hopefully this blog has given you some additional insights into the pros and cons.

To schedule a live conversation about defining business requirements within your company reach out to us via our website www.SMBERPConsulting.com. We’d love to talk with you.

Flight Project Considerations

59 views0 comments
bottom of page