Implementation Phase
As with major construction projects that always run long and over budget, underestimating implementation time for e-procurement projects is a chronic problem. One of the most important guiding principles to maintain is to always set proper expectations. It is to a large extent an effective early test of the proposing consultants to see exactly how they approach the issue. Ask them to help you to understand how much time you should allot for implementation, including system installation and training. Software vendors will often wave a dismissive hand and claim that implementation can be accomplished in as little as two months, but they may well be talking about a “slam-in-a-system” approach that will ultimately require a good deal more time, money, and rework to achieve the ROI that you are hoping for.
Try to judge how well your proposed supplier or consultant understands your business requirements. Do they focus on your specific business area, or do they specialize in certain commodity groups? Have them load several examples of your current data into the proposed system—an example PO or invoice—and have them walk you through a day-in-the-life scenario to see how well they know the procurement process and their own system’s functionality. You may be surprised to find out just how inexperienced and unsure the consultants (who, after all, in this economic climate have probably been rushed through a certifying training course and dropped directly onto a project proposal) really are about the functionality of their systems.
It is important also to understand whether your proposed software vendor will implement the system themselves or whether they will have a VAR (value-added reseller) or service provider do it for them. If they are proposing a VAR, or for that matter an ASP, understand their approach to implementation, their previous record for similar implementations, and examine their financial standing. Many VARs, anxious to take advantage of the high margins, are rushing to call themselves ASPs these days, and if you do consider choosing that route, again, you will want to consider issues such as performance history, scalability, reliability, and penalty provision for violation of service level agreements.
Customer Support
In this same vein, and given the complexity and mission-critical nature of the software, it is important to understand the availability of technical support and the standards for service that the company has when resolving more difficult and time-consuming system problems. Consider, for example, the numbers of customers that the vendor currently has, its customer support infrastructure, and the nature of its service level agreements, support desk, and issue resolution offerings.
Future Viability of the Group
Finally, try to make a considered judgment on the mid-term viability of the software itself. This is not going to be easy to do, given the volatility of the marketplace, but try to develop an algorithm that gives value to a weighted scoring of key variables, such as
Scalability
Vision
Development plans
Vendor’s history of adhering to announcement dates
Future integration and/or operability plans
Major changes to functionality that may make the vendor vulnerable to takeover or other risks
Size, financial strength, market position, and a stable management structure are all good indicators of future performance, but even these variables, as we have seen, cannot be guaranteed to give you an absolute assurance of future viability. In the end, you may be able to use the exercise only to identify and eliminate potentially dangerous liaisons with niche-platform providers, and will, like the rest of the business community, still be forced to make a decision based on functionality, service level histories, and total cost.