ERP Selection and the RFP Process

ERP Solutions and the RFP Process

I was reading a news article that a friend had forwarded me; a note about a recent court ruling. The English High court had ruled that a software liability clause was not ‘reasonable’. (http://www.channelregister.co.uk/2010/05/12/red_sky_liability_ruling/). Seems the software company had inserted a clause into the contract that said the customer could not take action against the firm for poor application performance.

While the customer has an expectation that the application would perform well, one would wonder what expectations were set for performance and by whom? The court ruling focused on the applicability of the clause and correctly (at least I think) ruled in favor of the customer in this case, it is not reasonable to require a customer to live with a poorly written application when trying to run a business.

Now, what has this to do with the RFP process?

Plenty.

Under the traditional RFP process, the customer should ask to see a demonstration of the software running in an environment comparable with their current environment, if possible. That is, if Joe’s Manufacturing Company was going through a refresh of their ERP, they should be able to see the proposed solution running within a similar environment with similar data they are running with currently.

Based on my experience, this key task is either omitted or glossed over quickly. Vendors don’t want to invest the time and effort to prepare such a test and most customers don’t understand how to go about creating a test sample of current data.

In the referenced case, there was a vendor demonstration that was attended by several employees from the customer’s organization. The documents don’t indicate who was in attendance (what role did they play in the execution of the job?) nor where the demo was hosted (did it run on a vendor provided server or was it installed on the customer’s servers?).

Vendor demonstrations are frequently scripted affairs that are designed to highlight the end user experience. I’ve sat through many of them over the years and have seen some vendors put the applications through the paces while other stick to a script and do their best to control the “show”. I’ve also seen demonstrations that were truly smoke-and-mirrors; the demonstrated app was a set of screens that looked like the app but were not much more than a slide show.
I’ve written a few RFPs over the years and have found the most effective way to manage the demonstrations is to write the rules in the RFP. If the vendor doesn’t want to participate, he’s taken himself off the list.

John’s RFP Tips - The Demo –

You need to add a statement in the RFP that ways that, in order to be considered, the potential vendor will need to participate in demonstrations at 3 levels:
1) System overview may be conducted on vendor provided servers. The customer will bring in end users from the applicable departments to view the demonstration, which needs to cover all major elements that are part of the core package.
2) Subsystem demonstrations using customer provided questions, scenarios and sample data. For example, if the application handles payroll, the potential customer will need to experience the set up, update and paycheck processing for sample employees.
3) Total system demonstration. The customer needs to provide a sample set of data that would be required to work through all components of the app. The system needs to be exercised to the point where reports and results can be compared to expected results.

I use 3 levels as it provides a convenient way to stop, review results between demonstrations and eliminate those vendors that don’t have a product that would be a fit.

Unless the vendor either has something to hide or doesn’t think their application can do the job, there is no reason they’d not want to participate. The results from all demonstrations and tests needs to be documented and used to support the eventual decisions on selection.