In the past few weeks, I have been concerned with a number of companies starting a new CRM project. In a surprising number of cases the process has been something like this:
- Check the internet for possible suppliers
- Download product descriptions and request informations from suppliers
- Watch online demonstrations
- Attempt to read the mass of information gathered
- Give up, prepare a list of requirements and start over
This is evidently not the right way to go about it. Not only is it time consuming and unproductive but it can also lead to false results. It is absolutely essential to determine requirements before looking at any products at all. Products are around to improve and optimize business processes, not to define them.
The process could look like this:
- Define the requirements
- Build a business case
- Prepare a document describing the required processes (NOT functions)
- Select a number of potential suppliers on the basis of product reputation and market positioning
- Ask these suppliers to show how the processes could be implemented with their products
If you have no resources for defining the requirements, then go to a qualified consultant (preferably not a potential supplier). This may be appear costly, but time saved will more than compensate this. Even reading this blog may help!
Tags: crm, RFP, Sales, Vertrieb
Reading a proposal for a CRM solution may sound easier than it is. Suppliers may supply visually attractive documents loaded with text or limit their offer to a bare description of the project steps and prices. Of the two extremes, the second has distinct advantages. Long texts may look good, or may even make interesting reading, but have the tendency to hide the really important facts amongst the many trees in the wood. The shorter texts are easier to read and have less danger of embedded pits.
No proposal can contain a full description of a standard product, the information can be found anyway in product documentation which should be supplied or form part of the proposal. The document must contain a full description of the project steps, all costs related to the project, and what happens if parameters change during the project. If the standard product is to be customized, then a detailed description of the modifications must as a separate document be identified.
Many companies underestimate their requirements. Functions are either overseen because they are part of everyday routine or because it is assumed that they are naturally part of a standard solution. This makes life easy for suppliers to make a low bid, well knowing that there will be no difficulty in changing the terms of the contract later when the hidden processes are unveiled.
Tags: Proposal, RFP
In the past few years, I have been responsible for evaluating an immense number of RFPs for CRM systems of all shapes and sizes, a necessary but often frustrating task. Why frustrating? The RFP must be constructed in such a way that product differences really become visible. This is very often not the case. Several approaches are recognizable.
- The RFP has been prepared by external consultants who have a clear interest in a particular product, but need to make their recommendation appear objective (frustration level high)
- Consultants have been involved who do not have vested interests in a product but prefer a solution which enables them to continue consulting while the product runs (frustration level medium)
- Consultants have been involved who are assisting the company to find the best fit solution as objectively as possible (excellent but seldom, no frustration)
- Listing all possible CRM functions in order to choose the product with the most functionality (frustration level high, since most suppliers can tick the boxes with a little imagination)
- Describing the current situation and asking for suggestions (frustration level low, but usually difficult due to lack of adequate information)
This sounds hard on consultants, but to be fair, the selection task is not easy. Recommending a product without product experience is risky, but at the same time experience cannot cover all products available and will limit the choice to a small number of major suppliers. Most suppliers will form an opinion regarding the type of RFP and will invest effort accordingly. In order to receive a maximum of information, the RFP must not be weighted towards a specific solution and must allow comparative strengths and weaknesses of suppliers and products to appear.
A good RFP will contain a clear statement of the current position, the reasons for the introduction of a new and will ask for information on
- Technology
- Functionality
- Interfaces
- The manufacturer
- The project partner
- Project methodology
In each section questions are separated into “must have”, “should have” and “nice to have” questions. This is not so easy as it sounds, since most products allow customization which makes it difficult to make a yes/no answer possible. A “must have” could be for example an interface to Lotus Notes. The above list will be extended in much more detail in later posts.
Better than a list of functions is a list of business processes with a brief description. This enables suppliers to take a clear position. Take care to ensure that each step in a process is simple enough to allow a simple answer. Details follow in the next posts!
Tags: RFP
CRM Auswahl