In our last post on enterprise software buying, we discussed the formation of a cross-functional team … critical to the identification of your true needs. In today’s post, we discuss the proper process for identifying and documenting your true software needs which helps you identify the solutions that are capable of meeting your fundamental needs and helps your negotiator avoid the “unnecessary modules trap” that we’ll discuss later in the series.
2. Document Your Needs
Once you have your selection team in place, the first task to accomplish is the documentation of what your organization needs the solution to do. This does not mean you document your current systems; this does not mean you document your current processes; and this definitely does not mean you use a “checklist” from a trade rag or a free RFP template. It means you sit down and spell out what your current problems are, what your preferred solutions are, and how you intend to functionally meet them with a new software solution.
It’s key to focus on process-oriented functional descriptions at this stage as “features” are irrelevant. It’s not how many features a product has, as you won’t use most of them anyway (consider Microsoft Word as an example), but how many functions it can perform relative to your business (and process) needs.
Some important points to consider at this stage of the selection process are:
- What are my current issues?
Software should solve problems, not create new ones. If you need to get your procurement process under control, but the new software doesn’t have any workflow management capabilities, you’ll end up having one more thing to manage. - What do I need the new system to do?
What are your big problems? Data collection? Analysis? Reporting? Order Tracking? Logistics and Network Management? That is what you need the new system to do, not what your vendor, trade rag, analyst, or even your favorite blogger tells you. - Who will be using the new system, who will be using the new system the most, and what are the most common tasks that will be performed in the new system?
Sounds obvious … but in reality, this important question is often overlooked. I see people buy systems time and time again simply because they have a “feature” that a competing product doesn’t have. What’s wrong with that you ask? Well, when the feature is only used once a month, or once a quarter, and could easily be accomplished in an external tool through a simple data export, and the “cost” of the feature is a significantly larger price tag or a lack of usability with respect to common functionality that is needed every day, an undue focus on a single “feature” becomes counter-productive. If a vendor is playing the “feature” game, chances are their “functionality” is lacking.
The only way to truly maximize value from any system you buy is to make sure it supports all of the common functions needed by all of your regular users. The “3-click” rule should apply just as it does in good web design. If a regular user can’t access a common function in 3 clicks, it doesn’t matter how easy it is for the manager who only logs on once a month to access what is likely, in effect, a stale and meaningless report. Remember, even the Harvard Business Review was quick to point out that “feature”-based “enhancements” don’t necessarily deliver results commensurate with costs. - What data do we need to collect, what information do we need to compute, and what knowledge do we need to get out?
If it’s a data intensive application, make sure it’s very simple to get large amounts of data into the system, using the native formats in which you are able to acquire the data. If it’s a decision support tool, make sure the analytics you need are present, easy to use, and templateable (as this is the best way to support junior users). - Where, and how, will our users be using the system?
If your only users are buyers and finance who will always be at their desks on their big-screen workstations with their high-speed connections, you can buy just about anything and it will work well. But if you need to support road warrior buyers who are always on the road visiting factories with intermittent internet access that’s sometimes restricted to slow dial up or cell-phone connections, you better make sure it has a stable off-line fat-client mode that only pulls down/pushes up new data, in a compressed format, on an as-needed basis. If it locks up for 30 minutes every time your user signs on to the network, it’s more useless than a brick (which can at least be used to prop the door open as you show the vendor out in a Jazz Style Exit). - What existing systems does the new system need to interface with?
If your organization just spent eight figures on an ERP, then even if it’s not a mandate, your new system will need to interface with the ERP. Buying a contract management system? It should interface with your e-Sourcing and e-Procurement systems. And so on. Equally important, don’t be fooled by vendors who create artificial dependencies between products that really don’t have any dependencies on each other. This legedermain is common in e-sourcing software, and forces you to buy more than you need. If the vendor has introduced an artificial dependency that requires purchase of an unrelated module, demand the unrelated module for free. - What are our operating environment constraints?
If your IT department can only support Windows, that’s a major limiting factor. You need to understand all of your limiting hardware and software factors (operating systems, databases, application servers, hardware environments, etc.) before you identify potential solutions, or you might get all the way to the contract signing only to find out IT can’t support the system, forcing you to go back to square one.
In our next post, we’ll talk about how you use these requirements to identify potential solutions appropriate for your organization.