Drie eisen die bijna elke CRM-selectie scheeftrekken

In vrijwel elke CRM-eisenlijst die wij zien, staan een paar eisen die op papier redelijk zijn en in de praktijk het verkeerde pakket laten afvallen. Niet omdat de eis onterecht is, maar omdat er iets in de zin zit waardoor er geen eerlijk antwoord op te geven valt. Dit zijn de drie die het vaakst terugkomen bij CRM, met de versie die wel werkt.

1. "Het CRM koppelt met ons financiële pakket"

De klassieker. Bij CRM raakt bijna elke selectie hieraan, want de klantgegevens, de offertes en de facturen wonen zelden in hetzelfde systeem.

Het probleem is niet de eis, het is de onuitgesproken helft. Bedoelt u dat het CRM zelf een kant-en-klare connector heeft met uw AFAS, Exact of Dynamics? Of is een koppeling via een integratieplatform ook goed? Of accepteert u dat de leverancier de koppelcomponent levert, zolang hij daar als hoofdaannemer verantwoordelijk voor is en u niet tussen twee partijen in komt te zitten?

Dat laatste is een belangrijk onderscheid dat vaak wegvalt: "door u te leveren" is iets anders dan "door u te bouwen". Levert de leverancier het als onderdeel van zijn aanbieding, dan heeft u één aanspreekpunt. Bouwt hij het, dan is het maatwerk en heeft u een onderhoudspost.

Laat u dit open, dan wordt de eis in de praktijk beantwoord door wie het antwoord opzoekt. Die vindt online altijd wel ergens een integratiepartner die iets soortgelijks doet, en u krijgt een groen vinkje voor een koppeling die in de demo nergens te zien is. Of het omgekeerde: een uitstekend pakket valt af omdat de standaardconnector ontbreekt, terwijl u een middleware-oplossing prima had gevonden.

Beter: "Het pakket wisselt klant-, offerte- en factuurgegevens uit met AFAS Profit. Een standaardconnector van de leverancier of van een door de leverancier geleverd integratieplatform voldoet. Maatwerkontwikkeling voldoet niet."

2. "Meerdere rechtspersonen onder één hoofdaccount, met gescheiden nummerreeksen"

Hier staan twee, soms drie eisen in één zin. Meerdere rechtspersonen kunnen beheren is één vraag. Gescheiden documentnummerreeksen per rechtspersoon is een tweede. En vaak zit er impliciet een derde in: een gedeelde klantkaart over die rechtspersonen heen, of juist strikt gescheiden.

Wie deze eis beoordeelt, moet drie dingen uitzoeken en één antwoord geven. In de praktijk wordt het eerste gevonden, en verdwijnt de rest. Bij een knock-outeis betekent dat: een pakket valt af of komt door op grond van een derde van de vraag, en achteraf kan niemand meer reconstrueren welk derde deel dat was.

Beter: drie losse eisen, elk met een eigen antwoord. En bepaal per stuk of het echt een knock-out is. Meestal is de eerste dat wel en zijn de andere twee zwaarwegend maar niet fataal.

3. "Het CRM is ISO 27001 gecertificeerd"

Een eis waar niemand tegen kan zijn, en precies daarom een gevaarlijke knock-out.

Stel uzelf één vraag: wat gebeurt er nu in uw organisatie als een leverancier dit niet heeft? Heeft inkoop ooit een aanbieding hierop afgewezen, dan is het een echte knock-out en hoort hij hard te zijn. Draaien er nu drie systemen zonder deze certificering, dan is het een sterke wens die u niet als knock-out moet opschrijven, want dan schiet u kandidaten af op een norm die u zelf niet handhaaft.

Hetzelfde geldt voor single sign-on, voor Nederlandse hosting en voor bewaartermijnen. Stuk voor stuk redelijke eisen. Stuk voor stuk knock-outs die selecties onnodig smal maken als er geen handhaving achter zit.

Beter: houd de eis, maar zet hem op zwaarwegend in plaats van fataal, tenzij u de vraag hierboven met een concreet voorbeeld kunt beantwoorden.

Waarom dit bij CRM harder aankomt dan elders

CRM-pakketten lijken functioneel meer op elkaar dan leveranciers u willen doen geloven. Contactbeheer, kansen, offertes en dashboards heeft iedereen. Het onderscheid zit in de randen: de koppelingen, het autorisatiemodel, de meertaligheid, de branchespecifieke stukken. En dat zijn precies de onderwerpen waarover eisen worden geschreven met een "of", een "en" of een onuitgesproken aanname over waar de functie mag zitten.

Het gevolg is dat de scherpte van uw formulering meer invloed heeft op de uitkomst dan het verschil tussen de pakketten. Dat is een oncomfortabele gedachte, en het is de reden dat wij bij een selectie beginnen met de eisenlijst en niet met de pakketten.

Wij beoordelen pakketten niet op wat leveranciers zelf invullen, maar op informatie die per eis wordt onderzocht. Per eis worden de score en het bewijsniveau vastgelegd. Daarbij hoort de leveringsgrens uit punt 1 tot de vaste beoordelingsregels: er wordt onderscheiden of de functie in het pakket of een inbegrepen bundelapplicatie zit, via configuratie of een eigen uitbreiding beschikbaar komt, via een bewezen standaardconnector of commerciële middleware wordt ontsloten terwijl de werkstroom in het pakket blijft, dan wel alleen buiten het pakket of via een workaround realiseerbaar is. Uniek maatwerk geldt daarbij niet als volwaardige invulling van de eis.

De volledige aanpak, met zes regels om uw eigen eisenlijst mee door te lopen, staat in het achterliggende artikel: De eis die uw beste kandidaat uitschakelt.