Marketing Intelligence voor Managers – Stappenplan voor toolkeuze

Deze blogreeks valt binnen ons thema ‘Management & BI’. Dit thema is bedoeld voor managers die wat meer willen weten over Business Intelligence, maar dan alleen de essentie, in begrijpelijke taal en zonder alle technische termen en hypes.

Net als voor zoveel ICT geldt, is het ook voor Marketing Intelligence belangrijk om een gedegen toolkeuze uit te voeren. Spring niet gelijk met de eerste de beste softwareleverancier in bed, maar overweeg verschillende opties. Behalve dat elke tool bepaalde sterktes en zwaktes kent, moet je er vooral op letten dat een tool past binnen jouw bedrijf en in je bestaande applicatielandschap. Zoals eerder gezegd moeten de systemen voor kanalen, sales en marketing naadloos met elkaar communiceren om een goed commercieel inbound proces te faciliteren.

De beste tool kiezen voor jouw bedrijf doe je op basis van een aantal vastomlijnde stappen. Als je een groot bedrijf hebt, voer je elke stap uitgebreider uit - bijvoorbeeld door meer formele interactie met potentiële leveranciers - en kost dit daarom meer tijd en effort. Een klein bedrijf zal sneller door het proces heen kunnen lopen omdat de situatie meestal minder complex is - bijvoorbeeld minder stakeholders, minder applicaties - en meestal minder formeel. Maar…. klein of groot, de te nemen stappen blijven gelijk. Lees verder voor het stappenplan.

Stap 1: Starten met requirements voor de toekomst

Requirements inventariseren en analyseren is lastiger dan je denkt. Het opstellen van goede ‘SMART’ requirements is een vak, er bestaan dan ook aparte trainingen voor. Bovendien gaat het hier om requirements van een gewenste situatie of een verbeterde huidige situatie. Je kunt er dus zeker van zijn dat elke stakeholder in jouw organisatie daar een heel eigen beeld over heeft en vanuit zijn eigen belang redeneert.

Een tip die altijd werkt: vraag de requirements uit aan de hand van processen. Het is voor ‘business’ stakeholders makkelijker om over hun proces (huidig en toekomstig) te vertellen dan over gewenste functionaliteit. Vervolgens leidt de analist de requirements af uit de verhalen en laat deze in feedback verifiëren. Neem iemand die ervaren is in het inventariseren en analyseren van requirements. Dat geeft je veel sneller een goed resultaat.

Als de lijst met requirements uiteindelijk is samengesteld, kun je daar nog niet direct mee naar je beoogde leveranciers. Eerst moet je al die requirements vertalen naar een samenhangende situatieschets.

Stap 2: Maak een coherente voorstelling van de toekomstige situatie

Elke lijst met requirements kent inherent conflicterende statements, denk bijvoorbeeld aan ‘lagere kosten door standaard processen’ in combinatie met ‘een individueel klant gedreven verkoopproces’. Ook mist jouw lijst normaliter requirements, gewoonweg omdat je ze nog niet bedacht had.

Daarom is het van belang vanuit de lijst een schets te maken van de toekomstige situatie. Het liefst zowel bedrijfsmatig (bedrijfsarchitectuur) als IT-technisch (IT-architectuur). Deze ‘target architectures’ moeten een coherent beeld geven over hoe alle requirements in onderlinge samenhang een plek krijgen in de gewenste situatie.

• Bedrijfsarchitectuur
  

  Met behulp van bedrijfsdomeinen geeft dit beeld inzicht in bedrijfsfuncties, bedrijfsobjecten en bedrijfsprocessen en wie daarvoor straks verantwoordelijk zullen zijn. Zij zijn straks de eigenaren van de aan te schaffen tools, de ‘demand’-organisatie. Dit bedrijfsbeeld helpt ook om je zogenaamde ‘non-functional’ requirements aan te vullen. Deze worden namelijk hoofdzakelijk uit de karakteristieken van het bedrijfsproces afgeleid (denk aan systeembelasting, responsetijden, transactie-aantallen, enzovoort).

• IT-Architectuur
  

  De benodigde IT-functies en data worden in onderlinge samenhang in een functionele architectuur gebracht die goed aansluit bij de bedrijfsdomeinen die je hebt bepaald. De IT-matige schets vormt de basis voor je verdere toolselectie. Hiermee heb je inzicht in alle functies en data die de tool moet kennen en de precieze positionering van de tool in de rest van het applicatielandschap (en daarmee dus de benodigde interfaces met andere applicaties).

Dit lijken zware en uitgebreide stappen, terwijl het mooie software tooltje al in de etalage staat te schitteren. Toch is IT-architectuur onmisbaar in een goed toolkeuzetraject, omdat het je in staat stelt veel sneller en adequater het kaf van het koren te scheiden voor jouw specifieke situatie. En de business architectuur is niet alleen de opmaat naar de IT-architectuur, maar geeft je vooral eerst inzicht in de organisatorische veranderingen die nodig zijn om de toekomstige situatie binnen jouw bedrijf te realiseren. Alleen zo kun je de gekozen software optimaal gebruiken.

NB: Ook hier geldt: kleinere bedrijven zijn veelal minder complex, waardoor het realiseren van deze stap ook veel minder tijd en effort hoeft te betekenen.

Stap 3: Maak selecties van mogelijke softwareleveranciers

Inmiddels ben je zo ver dat je kunt gaan kijken naar beschikbare software en mogelijke leveranciers. Hiervan maak je een eerste selectie in de vorm van een long-list. Goede bronnen daarvoor zijn de uitgebreide research rapporten van bijvoorbeeld Gartner, Forrester of Butler-Bloor. Hierin worden softwareproducten benoemd en beoordeeld. Normaal gesproken zijn deze rapporten vrij duur, maar omdat leveranciers graag pronken met hun positie in de ‘Magic Quadrants’ van Gartner betalen zij Gartner voor het online mogen zetten van deze research. Dit maakt de informatie regelmatig beschikbaar voor kleinere bedrijven. Onderzoek vanuit Gartner cum suis, behelst meestal alleen de grotere leveranciers en heeft een zekere neiging naar inzicht voor grotere softwaregebruikers en dus duurdere tools. Maar zeker ook voor kleinere bedrijven is er online veel informatie over softwareproducten beschikbaar, daarover is alleen nog geen objectief oordeel uitgesproken.

Met de uiteindelijke long-list in de hand beoordeel je de software en reduceer je de mogelijkheden tot een shortlist:

• Functionele selectie: Stel vanuit de IT-architectuur vast welke functies het nieuwe tool moet gaan uitvoeren en welke data het moet beheren. Maak een matrix met functies/data versus tools en scoor alle tools voor hun functionele fit.
• ICT-Inpassing: De IT-architectuur geeft je de interfaces die nodig zijn met de rest van jouw applicaties. Veel leveranciers hebben tegenwoordig ‘standaard’ interfaces met tal van vaak voorkomende tools voorgedefinieerd in hun softwareproduct. Dit geldt zeker ook voor cloudoplossingen (Software as a Service). Scoor de door jou gekozen tools op hun verbindbaarheid met jouw andere applicaties.
• Performance selectie: Vanuit de geschetste processen in jouw bedrijfsarchitectuur hebben we ‘non-functional’ requirements afgeleid (bijvoorbeeld security, performance, etc.). Het is meestal veel lastiger om informatie te verkrijgen over de performance van de tools op de long-list. Maar als het lukt dan helpt dit zeker om het aantal mogelijke tools te reduceren naar een shortlist. Zo niet, dan niet getreurd, dan laten we de bewijslast bij de leverancier van de tool tijdens de volgende stap.

Stap 4: Voer een RFI, RFP en/of RFQ traject uit met de gekozen softwareleveranciers

Met de shortlist van tools in de hand, meestal zo’n vier of vijf, wordt het tijd om de interactie met de leveranciers te starten. We zijn immers inmiddels terdege voorbereid. Hierbij kun je verschillende wegen – eventueel in combinatie – bewandelen:

• RFI: Request For Information

  Stel een document op waarin je de context schetst, de gewenste IT-architectuur, de benodigde functies, data, interfaces en non-functional requirements beschrijft en stuur deze naar je leveranciers met de vraag of zij per item kunnen aangeven of en hoe hun tool hier adequaat invulling aan kan geven.

• RFP: Request For Proposal

  Stel een document op met de probleembeschrijving, de oplossingsrichting en oplossingsvereisten en vraag de leverancier hoe zij dit probleem met hun tool zouden oplossen binnen de vereiste oplossingsrichting.

• RFQ: Request For Quote

  Stel een document op waarin beschreven staat hoe de tool binnen jouw oplossing gepositioneerd wordt en vraag om een (voorlopige prijs).

In zijn meest uitgebreide vorm vindt de interactie met leveranciers ook in deze volgorde plaats, maar dat is – zeker voor wat kleinere bedrijven - niet altijd nodig. Kies een voor jou geschikte aanpak als je het korter en wellicht minder formeel wilt maken.

Over formeel gesproken; probeer om zaken formeel te houden. Jouw tools en leveranciers zijn concurrenten van elkaar, zij zijn dan gebaat (en jij ook) bij een zo objectief mogelijk en eerlijk selectieproces. Geef ze dezelfde informatie, creëer een moment voor alle leveranciers waarin zij vragen kunnen stellen en deel de antwoorden met de anderen, geef ze dezelfde deadline en koppel uiteindelijk formeel terug waarom ze wel of niet zijn gekozen.

Soms is er ook sprake van dusdanig gestandaardiseerde software dat er geen directe interactie met de toolbouwer mogelijk is. Denk bijvoorbeeld aan tools als Salesforce, Magento, Hubspot of Marketo. Vaak is er dan wel de mogelijkheid om een lokale leverancier (service provider) te vinden die de RFI, RFP en/of RFQ voor je kan beantwoorden. Als je hiervoor meerdere leveranciers kunt uitkiezen, dan wordt de tools shortlist een shortlist met tool/leverancier-combinaties. Zo kan een tool zelfs meerdere keren op je shortlist voorkomen. Hou hierbij rekening dat voor kleinere bedrijven met een beperkte ICT-bemanning, vaak de leverancier later ook als applicatiebeheerder gaat optreden.

Stap 5: Voer een Proof-of-Concept uit samen met een implementatieplan

Vanuit de vorige stap blijven er meestal één of twee leveranciers over. Met deze partijen kun je een Proof of Concept starten. Dat wil meestal zeggen: een proefopstelling van de tool binnen een door jou geschetste situatie. Ook hier zijn de opgestelde architecturen erg behulpzaam. Vraag ook direct om een implementatieplan, dan kun je zien hoe de leverancier zich de invoering van het tool in jouw organisatie voorstelt, ook qua tijd en kosten.

Een PoC zal zo werkelijkheidsgetrouw als mogelijk moeten zijn opgesteld en uitgevoerd. En dat is …. vrijwel onmogelijk! De werkelijkheid is immers een compleet geïmplementeerd tool samenwerkend met al jouw andere applicaties in jouw beheeromgeving. Dat kun je tijdens een PoC nooit bereiken. Het blijft dus een simulatie met al haar beperkingen, waarbij de leverancier tracht om zijn tool optimaal te presenteren.

Toch krijg je tijdens de PoC de kans om de tool eens in de praktijk te zien werken. En misschien nog belangrijker om de leverancier eens in de praktijk met de tool te zien werken. Het gaat immers vaak om de klik die je hebt, ook qua cultuur. Zeker als je daarna het applicatiebeheer ook bij die leverancier wilt beleggen.

Stap 6: Maak een keuze

Het is tijd geworden voor een keuze. Eén ding is zeker, je hebt er alles aan gedaan om zekerheden te verkrijgen om een goede keuze te maken. Meestal wordt hierbij een soort lijst van evaluatie-aspecten gemaakt met wegingsfactoren, waarbij diverse stakeholders een score zullen geven. Uiteindelijk tellen we alle scores met gebruik van de wegingsfactor op en dan komt er één als beste uit. Klinkt leuk, maar het werkt vaak niet zo in de praktijk. Degene die de scores bijhoudt of de baas van het toolkeuzeproces is, ziet die uiterst rationele score en denkt: “Ja, maar dat is niet de beste”. Gewoonlijk stelt hij dan de wegingsfactoren bij totdat de emotioneel gekozen tool ook de rationele keuze wordt.

Wat uiteindelijk beter is, is een goede vraag waarover neurowetenschappers boeken vol schrijven. De emotionele keuze komt uit ons onderbewustzijn waarin allerlei ongeformuleerde en onnavolgbare overwegingen een rol spelen. Maakt dat de keuze slechter of beter? Ik weet het niet, maar misschien is het raadzaam om je verstand alle mogelijkheden met hun voor- en nadelen naast elkaar te laten zetten en dan alles overziend met je gevoel te kiezen.

Hoe dan ook, als je alle stappen uit het toolkeuzetraject hebt uitgevoerd, ben je in ieder geval veel beter in staat om een juiste keuze te maken. Daarmee voorkom je desinvesteringen. 

Ben je nieuwsgierig naar de 10 wetenswaardigheden rondom Business Intelligence ? Download onderstaand eBook vol met tips en best practices. Beschreven vanuit het gezichtspunt van de manager en zoveel mogelijk ontdaan van technische ICT-termen.

Laat hieronder een opmerking achter als je een bepaald onderwerp rond Marketing Intelligence wilt aandragen. Dan kan het zomaar voorkomen dat jouw situatie of vraag in een dedicated blog binnen de reeks wordt besproken.