Author: Mark DiGiovanni
It’s time for your business to deploy a new enterprise software package—perhaps it’s an ERP or CRM solution, or maybe it’s time for a new field service, human resources or project management platform. No matter which type of solution you need, the path to selecting the right enterprise software solution contains many potential road blocks. The route you choose can make or break the project’s success, so it’s critical to work with a valid map.
The key to charting your journey is the paradigm you apply as to how you will manage the evaluation process. It’s vital to take an agnostic approach with respect to the software solutions as well as the solution implementation partners you are considering.
Due to the natural bias that every business has about the solutions it offers, if you allow a software vendor or reseller to direct your evaluation, you risk getting boxed into the solution that works well for them—and not necessarily for your business. Even if a vendor or partner offers multiple solutions, they may be influenced by margins and available resources as to what they recommend.
Once you commit to taking an agnostic approach—where you drive the process or bring in an independent consultant to help you—there are two main phases to selecting an enterprise software solution—Requirements Definition and Solution Evaluation.
Requirements Definition starts by assessing the overarching business factors:
- The business strategy—the objectives and vision with respect to the application; why are you making a change?
- Projected growth—do you expect the company to grow in the next five years? (this determines if the application will need to handle increasing volumes). If you do expect to grow, by how much? (revenue and head count)
- Geographical footprint—do you have multiple offices across a wide geographical spread that will need to use the application? Any international offices?
- Business entities—does the application need to provide services to more than one business or business unit? Will they each run their own instance? Do the numbers need to roll up into one corporate-wide report?
- Accountability—do you anticipate new regulatory changes or market trends requiring greater accountability to the management and presentation of key data?
In addition to answering these questions, take a look at the challenges your current software solution presents. What business process problems are you trying to solve? What new functionality do you need?
Another aspect to consider is the ROI that will justify deploying the new system. Consider not only the cost to purchase and implement the software and the hardware to run the application, but also the amount of time your internal resources will need to put in. Do you need to recoup those costs and start producing an ROI within one year? Three years? A longer time period?
The last step in the Requirements Definition phase is to determine the “knock-out” requirements—the functionality and the benefits you absolutely must get out of the solution. In other words, if a solution can’t do either X, Y or Z, it’s out of the game!
Identifying knock-out requirements is key as you move into the Solution Evaluation phase. Among your narrowed-down list of potential candidates, you will discover that they provide 80% of the same functionality. It’s the 20% difference that you want to analyze closely, and your knock-out requirements will likely be found or missing from that 20% difference among the solutions.
After completing the Requirements Definition phase, you then move into the Solution Evaluation phase. Here are the steps to follow:
- Identify five or six potential solutions based on initial research and references from colleagues.
- Issue an RFI to each vendor to collect detailed information on the functionality that each solution provides as well as the system requirements.
- Evaluate each RFI response against your knock-out requirements to reduce the list two or three potential solutions. (Working with more than three will make it too confusing to compare solutions).
- Create a scorecard with weighted measures for each attribute you want to measure during the demos.
- Produce a script for the demos that covers all the major processes your end users will need to utilize—with a particular emphasis on the knock-out requirements.
- Run the demos back-to-back (or in a short time window, if possible) while utilizing a copy of real business data; this allows you to see how the solutions compare, and it gives you a more realistic sense of how each solution will work for your particular business needs.
- Evaluate the functionality of each system per the scorecard categories.
In addition to evaluating the functionality of each solution you run through the demo step, also consider the general characteristics of the vendor and the software:
- Is it a stable company that will be around for years?
- Are they likely to be acquired?
- Can they provide you with a product roadmap?
- Do they have experience in your industry?
- Do their customers look like you size-wise?
Key characteristics of the software to consider include whether it matches your preferences for running in the cloud, on-premises or a hybrid environment. Also consider if you require software that runs on open standards, or if a closed architecture is acceptable. This will determine how easy or difficult it will be to integrate the solution with other enterprise applications.
Going back to our comments earlier in the blog, the need to conduct an agnostic formal evaluation and eliminate bias towards one particular solution cannot be overemphasized. Vendors and solution implementers are likely to only show you the “shiny objects” that are meant to dazzle you and close the sale.
Your focus should be on objectively determining if and how a solution can solve your primary business challenges and provide the answers to your knock-out requirements. This can only be done by following scripted demos that are based on your particular needs.