Drie redenen om die mooie marketingsoftware nog even niet aan te schaffen

Waarom je je contentproces pas moet automatiseren als de pijn ondraaglijk wordt

Op het gebied van marketingsoftware is het internet inmiddels een soort luilekkerland. Je kunt het zo gek niet bedenken of er zijn 27 verschillende tools voor, met allemaal hun kwaliteiten en hele aantrekkelijke gratis proefversies waar je makkelijk hele dagen mee kunt prutsen. Maar welke tools heb je nou écht nodig? Het is voer voor eindeloze discussies en dure consultancytrajecten. Drie redenen om die shiny software-tool nog even niet aan te schaffen.

Werk je in marketing of communicatie, dan leef je in een technologiegedreven, omnichannel wereld. Je moet steeds meer kanalen bedienen en er wordt van je verwacht dat je met concreet bewijs komt voor de ROI van je inspanningen. Dat stelt hoge eisen aan de inrichting van je content-, data- en rapportageprocessen. Om die processen te ondersteunen zijn IT-systemen onmisbaar. Marketing en communicatie zitten, kortom, midden in hun eigen digitale transformatie en het aanschaffen van software is voor veel organisaties een soort standaardreflex geworden als processen niet optimaal lopen.

“Je kunt het zo gek niet bedenken of er zijn 27 verschillende tools voor”

Maar welke tools heb je nou echt nodig? Ik merk dat heel veel organisaties op zoek zijn naar een manier om deze vraag te beantwoorden. Daarom was ik extra blij toen Joe Pulizzi en Robert Rose het in hun recent weer opgestarte podcast ‘This Old Marketing’ over dit probleem hadden (luister op Spotify of op Apple Podcasts). Hun techniek om te zorgen dat je nooit meer geld weggooit aan IT die niet werkt? Pijn lijden.

Om te laten zien hoe dit werkt, geef ik je drie redenen om het aanschaffen van je volgende shiny software-tool nog even uit te stellen.

1. Draagvlak

Waarom falen IT-projecten? Daar zijn bibliotheken over volgeschreven, maar bovenaan de lijst staan meestal scope creep (het geleidelijk ‘uitdijen’ van de eisen aan een project) en gebrek aan betrokkenheid van de organisatie. En volgens mij hebben die twee met elkaar te maken.

Kijk er eens naar vanuit het perspectief van een drukke marketingprofessional. Waar heb je meer zin in: een ‘strategische’ cloud-migratie die vooral betekent dat je drie nieuwe wachtwoorden krijgt en niet meer bij je netwerkschijf kunt? Of de invoering van een tool waardoor je nooit meer handmatig socialmediaberichten hoeft in te plannen? Klinkt dit als een no-brainer? Waarom kom ik dan zo veel softwareprojecten tegen waarvan volstrekt onduidelijk is welke pijn ze proberen op te lossen en waar werknemers voor hun gevoel alleen maar last van hebben?

In het eerste geval is er misschien wel een noodzaak, maar wordt die op de werkvloer niet gevoeld. Deze top-down implementaties missen meestal ook een scherp afgebakende scope. Door hun organisatiebrede insteek moeten ze ook aan (vaak tegengestelde) eisen en wensen voldoen van allerlei afdelingen en raken ze processen waarvan de bedenkers van het project niet eens wisten dat ze bestonden.

“De meest succesvolle software-implementaties zijn die waarbij er een dringende, breed gevoelde noodzaak is”

Door het aanschaffen van software (en de implementatie die erbij hoort) uit te stellen tot iedereen gestoord wordt en de afdeling in elkaar dreigt te storten, loop je veel minder risico dat je investeert in oplossingen die eigenlijk niets opleveren. De meest succesvolle software-implementaties zijn die waarbij er een dringende, breed gevoelde noodzaak is.

Iedereen heeft – dankzij diep gevoelde frustraties over het huidige proces – een scherp beeld van wat het probleem is. Je kunt je dus richten op het oplossen van acute, serieuze problemen die het hele proces raken en die een frustratie zijn voor het hele bedrijf. Dat geeft het project draagvlak en een momentum wat je niet ziet bij veranderingen die vooral ‘van boven’ komen. Ook wordt snelheid een factor. De nood is immers hoog. En voor een snelle implementatie is het belangrijk om de scope te beperken en strak te bewaken. Juist scope creep is een belangrijke reden dat projecten falen.

Als je slim bent, laat je strategische implementaties meeliften op dit soort snelle, strakke projecten. Door er eentje als pilot te nemen voor je nieuwe cloud-architectuur, bijvoorbeeld.

2. Kosten

Investeren in goede software is prima – soms zelfs bittere noodzaak – maar uiteindelijk moeten de kosten terugkomen in hogere productie en/of kwaliteit.

In vroeger tijden moest je in één keer een paar duizend euro aftikken voor een softwarepakket, waarna je een verhuisdoos met cd-roms opgestuurd kreeg. Dat betekende dat je budget moest aanvragen en een businesscase moest schrijven. Tegenwoordig wordt vrijwel alle software als dienst geleverd: SaaS, of Software as a Service. Het voordeel is dat je per gebruiker en per tijdsperiode betaalt, en dus geen grote investeringen hoeft te doen. Geen businesscase nodig. Als je toegang hebt tot de corporate creditcard kun je je team van licenties voorzien.

“De kosten van implementatie en beheer van een applicatie zijn vaak hoger dan de licentie- of ontwikkelkosten”

Maar de kosten van zo’n tool kunnen aardig oplopen. Het maandbedrag per gebruiker mag er dan vriendelijk uitzien, als je uitrekent wat vijftien gebruikers je per jaar kosten, is het al een veel serieuzer bedrag. En dan zit die ene feature die je eigenlijk ook nodig hebt, altijd net in dat duurdere abonnement. Ondoordacht aanschaffen van ‘handige’ tooling kan je op deze manier veel geld kosten, terwijl het volstrekt onduidelijk is wat het je eigenlijk oplevert. Gebruiken je mensen de tool ook echt? Of heb je je gewoon te snel laten verleiden door een mooie interface en een paar gladde webinars? Je zou niet de eerste zijn, dat garandeer ik je.

De kosten van IT zitten trouwens voor het overgrote deel helemaal niet in licenties of bouwkosten, maar in implementatie, migratie en organisatieverandering. Sterker nog: de kosten van implementatie en beheer van een applicatie zijn vaak een orde van grootte hoger dan de licentie- of ontwikkelkosten.

3. Proceskennis

Een derde serieuze bedreiging voor het succesvol ‘binnenrijden’ van nieuwe software is gebrek aan kennis van de eigen organisatie en het proces. Je kunt nou eenmaal geen dingen automatiseren waarvan je niet weet hoe ze werken. Toch proberen veel bedrijven dat, vaak ‘op weg geholpen’ door de salesmensen van de softwarefabrikant. Die vinden het namelijk helemaal niet erg om wat extra consultancy te verkopen, als blijkt dat de processen niet helemaal helder zijn.

“Het voordeel van wachten tot de frustratie hoog oploopt, is dat frustraties leiden tot discussie”

Het voordeel van wachten tot de frustratie bij je mensen hoog oploopt, is dat frustraties leiden tot discussie. In die discussie komt vaak een groepje luidruchtige key users naar voren, dat precies weet hoe de processen lopen en waar de problemen zitten. Samen met die gebruikers kun je meestal snel tot een set procesbeschrijvingen en requirements komen, zonder meteen met een duur team externen aan de gang te gaan. De voorsprong die je neemt door eerst zelf in kaart te brengen hoe je processen lopen, waar de verbeterpunten zitten en hoe je die met IT ondersteund wilt zien, betaalt zich in de implementatie dubbel en dwars terug.

Draagvlak, proceskennis en businesscase

Een pakket-implementatie is, kortom, een project met allerlei risico’s, waar je alleen aan moet beginnen onder strikte voorwaarden:

1. Er is binnen de organisatie een breed besef dat de status quo niet houdbaar is
2. Je hebt een goed beeld van hoe je marketingproces er nu uitziet en hoe het er uit zou moeten zien
3. Het nieuwe pakket biedt aantoonbaar grote voordelen op het gebied van efficiency en effectiviteit van je marketingorganisatie

Draagvlak, proceskennis en businesscase. Heb je deze drie dingen niet? Dan is het een goed idee om die software-implementatie toch nog even uit te stellen.