In Vendor Evaluation, Don’t Shortcut the RFI Process

In some enterprise software selection projects, clients are tempted to skip the Request for Information (RFI) stage and go straight to a Request for Proposal (RFP). This is a mistake and often the result of not fully understanding the value of a well-written RFI.

What is the difference between an RFI and an RFP? In our software selection consulting services, we develop an RFI near the beginning of the vendor evaluation process. The RFI includes a description of the client’s organization and the client’s project. It also includes a list of key requirements for the new system—not an exhaustive list, but essential functionality or processes that are distinctive for the client. Vendors are asked to respond as to their ability to satisfy those key requirements. Vendors are not asked for a cost proposal at this time. We typically make the RFI available to as many vendors as we think are qualified to respond, or to those that express an interest in responding—usually five or more.

An RFP, in contrast, is published near the end of the evaluation process, after each finalist vendor (typically 2-3) has conducted its demonstrations or other proof-of-concept. The vendors are asked to provide a cost proposal, along with their proposed license/subscription agreements and a high-level implementation proposal with costs and schedules. The vendors’ RFI responses are incorporated as an attachment, which they can revise based on what they’ve learned since they first responded to the RFI.

Read the rest of this post on the Strativa blog: In Vendor Evaluation, Don’t Shortcut the RFI Process

Which Comes First, New Systems or New Processes?

Everyone agrees that business process improvement is a key success factor in enterprise system implementation. But, which comes first? Should organizations redesign their business processes before selecting and implementing new systems? Or should they first select a new software vendor and then redesign their processes to match how the new system does things?

This question comes up repeatedly in our vendor evaluation and software selection consulting services. Clients read about failed ERP or CRM projects, for example. They hear the warnings of executives from such companies, telling them to spend more time up front understanding their business processes. They hear about companies that go live but don’t achieve the desired benefits. They vow to do better. They don’t just want to implement a new system. They want to implement best business practices.

These are good reactions. When it comes to enterprise systems, anything that heightens the fear of failure is a good thing. The more business leaders are focused on business processes, the better.

But, how should business leaders deal with their business processes when implementing a new system?

• Should they improve their processes before implementing the new system, so that the new system is not automating broken processes?
• Or, should they choose the new system first, so that they can redesign their business processes using the best business practices that are embodied in the new system?

The answer is a little bit of both: the two should be done in parallel. In fact, doing all of one before the other—whether process first, or system first—will result in failure.

Read the full post on the Strativa website:
Which Comes First, New Business Processes and New Systems?