7 Veelvoorkomende fouten bij de implementatie van CPQ-software

deel dit artikel

In mijn rol als R&D Director en Software Architect ben ik betrokken geweest bij verschillende stadia van een aantal software implementatie projecten. Ik begon met kleinere projecten in Italië, en naarmate mijn carrière vorderde in de afgelopen 20 jaar, werden de projecten steeds groter en verspreidden ze zich naar de VS en Europa.

Uiteraard spreek ik als R&D Director bij KBMax al dagelijks met developers en system integrators. Ik ben er ook sterk van overtuigd dat ik rechtstreeks met bestaande en potentiële klanten moet praten om hun behoeften te begrijpen en vervolgens de beste oplossing te vinden voor hun unieke reeks uitdagingen. Daarom vraag ik ons verkoopteam soms om mij te betrekken bij hun klantbijeenkomsten.

Wilt u meer informatie over hoe u aan de slag kunt gaan met uw CPQ-implementatieproject?

Krijg meer inzichten en best practices om uw CPQ-oplossing op de kaart te zetten...

Ontvang onze volledige CPQ-implementatiegids

 

Fouten bij de implementatie van CPQ-software

EEN CPQ project is vaak de 'laatste software' omdat het bedrijf over het algemeen al systemen heeft zoals: CRM, ERP, PLM, enz. KBMax is over het algemeen de 'lijm' voor al deze systemen en de 'fil rouge' van vele afdelingen: Verkoop, offerte kantoor, technische afdeling en werkplaats.

Ik beschouw mijn standpunt als een beetje een externe waarnemer van een projectuitvoering, maar nog steeds heel dicht bij alle 'actoren'. De volgende lijst is niet uitputtend, maar fungeert als een verzameling valkuilen waarvan ik getuige ben geweest, en vaak zijn ze te voorkomen voordat ze volledig werden gerealiseerd. Zoals het boek 'The Art of War' zegt: "De ultieme kunst van oorlog is om de vijand te onderwerpen zonder te vechten" - in dit geval zijn onze vijand deze implementatievalkuilen.

1. Voorrang geven aan technologieselectie boven processen en mensen

Een van de meest gestelde vragen die mensen mij stellen is. “Wat past het beste bij het kiezen van een configurator of? CPQ-oplossing?” Eerlijk gezegd gaat het er niet om welk product je kiest, maar om welke mensen en bedrijfsprocessen je het hebt.

Er zijn producten die perfect geschikt zijn om 'geconfigureerd' te worden, maar bedrijven hebben ofwel geen proces, of hun proces is nodeloos complex. Dit gebeurt meestal omdat er in de loop van de tijd meerdere lagen zijn toegevoegd. Het is vaak erg moeilijk om het proces te vereenvoudigen, omdat het betekent dat deze lagen van complexiteit en de kracht van sommige mensen of teams in het bedrijf die ermee bezig zijn, moeten worden verminderd. Als het verkoopteam bijvoorbeeld wil verkopen wat de klant wil, zal dit gebrek aan beperkingen ongetwijfeld een puinhoop veroorzaken in de rest van het bedrijf, op het gebied van engineering, inkoop, productie, enz. Deze problemen kunnen niet worden gecontroleerd als er is geen proces (en hopelijk ondersteund met software) dat dit risico kan helpen verminderen.

I sometimes see products that the technical department has practically made as ‘custom’, but might landed here because they’ve introduced a number of completely unnecessary options. As you try to understand why there are so many options, you discover that they exist because many years ago, a potentieel customer asked for them. It seems to some teams that by creating options and making the process complex, it communicates to their other teams and leadership, “Hey, look how smart we are!”.

Ik denk dat je nu de uitdaging ziet: een proces vereenvoudigen betekent niet inferieure service aan de klant, maar in plaats daarvan vechten binnen het bedrijf om de ego's van elke afdeling onder controle te houden. Je herkent deze strijd misschien als: verandermanagement. Deze herformulering van het kritieke bedrijfsproces van verkoop en productie zou de juiste focus op het bedrijf in het algemeen moeten houden, in plaats van op afzonderlijke afdelingen of individuen.

As these existing processes are discovered, and new, optimized ones conceptualized, often the idea of automation will come to mind.  But be careful not to introduce this concept too early, before a process is fully thought through. Automating a bad process only makes a bad process run faster. If a CPQ software implementation begins replicating existing, ego-driven processes, it is easy to foresee a disaster where automation is simply more quickly compounding your problems.

2. Te veel procesaanpassing

Helemaal gerelateerd aan het punt hierboven: soms hebben bedrijven hele rare processen. Het blijkt dat ze het wiel opnieuw hebben uitgevonden, maar daarmee het wiel opnieuw hebben uitgevonden als een vierkant. Vaak heb ik bedrijven met trots horen uitroepen dat "we nooit software hebben kunnen vinden die ons bevredigt, dus moesten we onze eigen software ontwikkelen." Dit kan het geval zijn voor zeer gespecialiseerde verticals zoals technische berekening. Als er echter een hele softwarecategorie op de markt is waarvan u denkt dat die niet op u van toepassing is, kan dit een indicatie zijn van iets groters dat verkeerd is en hoogstwaarschijnlijk wordt aangedreven door iemands ego.

When a customer asks for a customization in CPQ software, one should really go to the root to find why they think it is required. Generally, we find that the needed customization is most often hiding a process problem. Software customizations are very expensive for all parties and can add fragility. So, never give a blanketed “yes” to a software customization without asking first, “why”?

3. Gebrek aan betrokkenheid van belanghebbenden om adoptie te stimuleren

Het betrekken van alle stakeholders is erg belangrijk, maar kan ook gevaarlijk zijn. De uiteindelijke stakeholder is het bedrijf. Het niet plannen van de gebruikersadoptie of het verkrijgen van de buy-in van de eindgebruiker als onderdeel van het besluitvormingsproces zal echter tot mislukking leiden.

Tegelijkertijd kun je de gebruikers ook niet eenzijdig laten beslissen over de oplossing. Zoals Henry Ford zei: "Als ik mensen had gevraagd wat ze wilden, hadden ze snellere paarden gezegd".

De sleutel hier is: evenwicht. Leidinggevenden, afdelingshoofden en teamleden moeten allemaal een stem hebben bij het ontwerpen van het nieuwe proces. Balans is vaak wat een succesvolle CPQ-software-implementatie onderscheidde van een mislukte.

4. Niet op zoek naar het beste MVP-product

Je kunt de definitie van MVP (Minimum Viable Product) overal vinden, dus ik wil hier niet veel benadrukken door een andere definitie toe te voegen. Het meest complexe product in het bedrijf is geen goede kandidaat zoals het geen goede kandidaat is, een triviaal product. Waarschijnlijk is de beste kandidaat een nieuw product van gemiddelde complexiteit, omdat het het product is met minder vooringenomenheid.

5. Onderschat de hoeveelheid inspanning

Deze valkuil is meestal te wijten aan het niet zorgvuldig verzamelen van de projectvereisten. Als technicus denk ik dat het heel gemakkelijk is om de benodigde tijd te onderschatten. Over het algemeen vermenigvuldig ik wat ik denk dat de inspanning is met een factor twee. Waarom? Ik voeg dit toe als 'politieke tijd'. Het is heel gemakkelijk om te verdwalen in discussies en vergaderingen die informatie uit mensen trekken, in plaats van vooraf goed gedocumenteerde vereisten te verstrekken. Mensen houden van lange, onproductieve vergaderingen en ik weet niet waarom.

6. De bedoeling en grenzen van toepassingen niet begrijpen

Wanneer er veel softwareapplicaties bij betrokken zijn en verbonden zijn als onderdeel van een proces, afdeling of bedrijf, is het vaak moeilijk te begrijpen 'wie wat doet'. Ik heb het niet over simpele grijze gebieden. Ik stel voor dat elke softwaretoepassing moet worden gebruikt waarvoor hij is ontworpen. Het is bijvoorbeeld heel gebruikelijk om het doel van een ETL-tool (Extract Transform Load) te vergeten en te doen alsof elke software verantwoordelijk is voor het pushen en ophalen van gegevens. Wanneer er veel toepassingen worden gebruikt, zult u merken dat sommige flexibeler zijn, terwijl andere dat niet zijn. Het is natuurlijk gemakkelijker om flexibelere software te buigen om taken uit te voeren waarvoor het niet bedoeld is. Dat betekent echter niet noodzakelijk dat u dat zou moeten doen.

7. Oververkopen van verkopen

Hier heb ik het over ons – KBMax als softwarebedrijf. Wij verkopen geen droom. We constateren dat het overselling-probleem aanzienlijk is verminderd sinds onze overgang van traditionele eeuwigdurende licenties naar een cloudmodel (SaaS).

Wanneer een verkoper een eeuwigdurende licentie verkoopt, is hij doorgaans geïnteresseerd in het voltooien van de softwaretransactie en het succesvol lanceren van een eerste succesvol project met zijn klant. Daarna is de klant niet langer 'het probleem van de verkoper'. In een SaaS-model moet de verkoop echter zowel een eerste als een blijvende overwinning zijn. Alleen klanten met sterke software die een succesvolle implementatie uitvoert, komen terug voor verlengingen, wat de enige manier is waarop SaaS-bedrijven winstgevend kunnen zijn.

Andere klassieke projectmoordenaars

Er zijn tal van andere implementatieproblemen waarmee een CPQ-software-implementatieproject kan worden geconfronteerd: lage/verschuivende budgetten, slecht projectbeheer, ontbrekende onderhoudsplannen, slechte kennis van de technologie, slechte softwarekwaliteit, enz. Deze zijn gevaarlijk en belangrijk om op te letten omdat ze gemakkelijk een project kunnen laten crashen, maar ze zijn naar mijn mening vrij duidelijk en gemakkelijk te herkennen. Ze zijn in ieder geval niet specifiek voor de implementatie van CPQ.

Een betere manier delen om CPQ-software te implementeren

KBMax heeft een aantal geweldige bronnen om u op weg te helpen in uw CPQ-project. We hebben een geweldig eBook en een reeks blogposts die licht werpen op enkele best-practices om u op weg te helpen:

Geplaatst in: CPQ
 
nl_NLDutch