Yesterday, we began our Technology Trials 2012 series with a post that indicated that in order to get to the right decision, you have to start with the right question. And the first question you needed to answer is whether or not, if you have a current solution, was it supporting the process you need. If the answer was Yes, or No, but not enough time to get a new solution in place, then you stick with the current solution for the time being, and if the answer was No or Yes and No, you look for a new (partial) solution. (And if the answer was, we don’t currently have a solution, then, by default, the answer is an emphatic No.)

At this point, we’re going to assume that the answer is (at least partially) No, as the series would be over otherwise, so the next question you need to ask is:

(02) What part(s) of the process is not being supported?
This is critical to understand, because you can not select an appropriate solution unless you know what it has to do, and you typically can’t justify a new solution unless you have a gap analysis between what you have now and what you need. But you have to do more than just this. You also need to answer

(02.1) Which part(s) of the process must be supported by the system?
The system doesn’t necessarily need to do everything. For example, while it might be necessary to have a real-time conversation with multiple parties to resolve an issue, it doesn’t have to be through the system. As long as there is a way to import and record the solution determined after the fact, many of the “social media” features of consumer platforms are not necessary. For example, given the choice between “real time problem resolution” and “3-way match” in an e-Procurement system, I’d choose the latter. The first may be cool, but it isn’t going to prevent millions of dollars in over-spending (like the second will).

(02.2) Will any of the target functionality interfere or conflict with any other solution(s) currently in use by the organization?
This is often overlooked during a gap analysis, but can greatly impact how long it takes to get a new solution approved. If, for example, your problem is that your sourcing/procurement solution doesn’t store contracts (and associated meta-data), and you want to fix this, and there is a(n incompatible) contract management solution being used by Legal, you might get push-back from IT as they would have to support two CM systems (that they are unable to distinguish between) or the CFO who doesn’t want to spend more money (as he thinks you should just use the other system). While this should not deter you from identifying the right solution, if you don’t have all the facts, and the counter-arguments, up front, you could be considerably delayed in your quest for purchasing fire.

(02.3) Can the process requirements be integrated with the requirements for the existing system that are still current?
Don’t overlook that you are looking for an end-to-end process solution, and the RFP should specify the functionality required by the end-to-end solution, including that functionality, existing and not existing, that is critical.

In our next post, we’ll discuss what comes next.