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...
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.
Producten die de technische dienst praktisch heeft gemaakt zie ik wel eens als 'Op maat', maar zou hier terecht kunnen komen omdat ze een aantal volledig onnodige opties hebben geïntroduceerd. Terwijl je probeert te begrijpen waarom er zoveel opties zijn, ontdek je dat ze bestaan omdat vele jaren geleden, a potentieel klant vroeg ernaar. Het lijkt voor sommige teams dat door het creëren van opties en het maken van het proces complex, het communiceert naar hun andere teams en leiderschap: "Hé, kijk eens hoe slim we zijn!".
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.
Naarmate deze bestaande processen worden ontdekt en nieuwe, geoptimaliseerde processen worden geconceptualiseerd, zal vaak het idee van automatisering in je opkomen. Maar pas op dat u dit concept niet te vroeg introduceert, voordat een proces volledig is doordacht. Door een slecht proces te automatiseren, verloopt een slecht proces alleen maar sneller. Als een CPQ-software-implementatie begint met het repliceren van bestaande, ego-gedreven processen, is het gemakkelijk om een ramp te voorzien waarbij automatisering uw problemen simpelweg sneller verergert.
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.
Wanneer een klant om maatwerk vraagt in CPQ-software, moet je echt naar de wortel gaan om te ontdekken waarom ze denken dat het nodig is. Over het algemeen vinden we dat de benodigde aanpassing meestal een procesprobleem verbergt. Software-aanpassingen zijn erg duur voor alle partijen en kunnen kwetsbaarheid toevoegen. Geef dus nooit een algemeen "ja" aan een software-aanpassing zonder eerst te vragen "waarom"?
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:
Bouwen versus kopen - Een productconfigurator bouwen
Dutch 
English 
French 
Italian