Enterprise Software Selection: Defining Requirements

In our previous post on enterprise software selection, we took a look at the first phase of the process, the Discovery phase. Though our examples are specific to ERP software selection, the concepts we explore apply more broadly to other kinds of enterprise software as well.

The second phase of the enterprise software selection process is the Defining Requirements phase.

The IEEE defines a software requirement as a condition or capability needed by a user to solve a problem or achieve an objective. Unsurprisingly, the second phase in the selection process, then, is identifying and defining those conditions and capabilities that are specific to your organization.

Requirements come in four broad categories:

• Functional
• Technology
• Solution
• Partner

If the discovery phase was about using the SWOT analysis and as-is process mapping to look at the organization at the 30,000-foot level, defining requirements is about getting more granular. For the purpose of this post, we’re simply going to define these four categories of requirements so that we have a common vocabulary to use are we move forward in future posts.

Functional

Functional requirements are those that a particular business function needs in order to achieve its objectives. Accounts Payable is an example of a function within an organization that has both general requirements (that are common to nearly all businesses) and specific requirements (that apply to a subset of businesses in your industry or only to your business). Invoicing is a common business function that your organization likely shares with other businesses. However, things like foreign currency translation and ACH or wire transfers might only apply to your particular business. Identifying and defining those as software requirements, then, is very important to your organization—the software you choose has to be able to handle those kinds of transactions.

Technology

When we talk about technology requirements, we are generally referring to hardware rather than software. This broad category takes into account everything from on-site servers to cloud-based services, cabling to wireless networks, desktop computers to mobile devices, and everything in between. For example, is a cloud deployment important for your organization? Or does it make more sense for your organization to have a solution installed locally? Is your workforce distributed, or do you all work out of the same location? Is it necessary that the solution run on mobile devices or not? These types questions help identify and define an organization’s technology requirements.

Solution

Solution requirements are those that pertain to the software solution that you are selecting. It takes into account your organization’s functional and technological requirements by demonstrating that a specific solution can meet those requirements. Questions to consider when identifying and defining solution requirements include: How long has the enterprise solution existed? Is it strongly supported? When was the solution last updated? And, how extensive is the userbase? Popular examples of solution providers include Microsoft (Microsoft Dynamics), SAP (SAP S/4HANA, Cloud ERP, etc.), Epicor (Epicor ERP), and many, many more.

Partner

Finally, partner requirements are those that must be met by your solution partner. Your solution partner (sometimes referred to as a value-added reseller or VAR) is a third-party company that sells, implements, customizes, and supports industry-specific enterprise software, usually built on one of the solutions listed in the section above. For example, JustFood (an Aptean company) sells JustFood ERP, an industry-specific ERP solution built on Microsoft NAV that is popular with food and beverage manufacturers. Questions to include when defining your partner requirements include: How long have they been around? How many people do they have on their team? How much experience do they have? What part of the country are they in? What area of expertise do they focus on? How much will this cost?

Now that we have defined our terms, we’ll focus on the third phase of the software selection process in our next post: identifying solutions and partners.

Up until now, the way we’ve described the software selection process has been linear. First, the SWOT analysis. Then the “as-is” process mapping. Third, identifying and defining requirements. However, when it comes to the next phase, identifying possible software solutions and solution partners, it’s helpful to envision a funnel. The point of the next phase is to narrow the possible solution providers to the two or three that best fit your organization and meet your needs.

Are you planning on implementing a new enterprise software solution? Do you need help identifying and defining your requirements? Contact us. We can help.

– – – – – – – – – – – – – – – –

Photo by rawpixel on Unsplash