Waarom support na de go-live faalt en hoe u ziet of het bij u misloopt

Het project wordt op tijd afgesloten. De stuurgroep krijgt haar laatste groene slide en de implementatiepartner wordt bedankt in een mail aan het hele bedrijf. Zes weken later houdt finance een schaduwspreadsheet bij voor de maandafsluiting, bellen twee mensen in het magazijn weer naar kantoor, en heeft niemand ingelogd op het klantenportaal waarvan u de configuratie hebt betaald. Er is niets stuk. Het systeem draait, de integraties lopen, het beschikbaarheidsrapport is foutloos. De organisatie draait gewoon slechter dan in de laatste maand van het project.

Wanneer dat gebeurt, kijkt men instinctief naar de software. Het ligt bijna nooit aan de software. De grootste bedreiging voor de go-live van een ERP of CRM is organisatorisch: wie eigenaar is van het proces zodra het projectteam uit elkaar gaat, waar de kennis zit, en wat er gebeurt met een probleem dat voor de derde keer opduikt. Systemen falen luid en worden hersteld. Organisaties falen stil en er wordt omheen gewerkt. Een workaround geeft, anders dan een storing, nooit een alarm. Hieronder staan de zes patronen die we het vaakst zien bij middelgrote bedrijven in België en Nederland, en een korte lijst waarschuwingssignalen die u naast uw eigen situatie kunt leggen.

Support na de go-live wordt verkocht als fase, niet uitgebouwd als vaste functie

Implementatiecontracten bevatten bijna altijd hypercare: een periode van verhoogde aandacht na de go-live, doorgaans gemeten in weken en niet in maanden. Dat is nuttig, maar het is geen support. Het is de staart van een project, bemand door projectmensen en geprijsd binnen het projectbudget. Wanneer het afloopt, wordt wat erop volgt meestal omschreven als business as usual: een uitdrukking die in de praktijk betekent dat niemand iets heeft beslist. De vraag stopt niet aan het einde van de hypercare; ze verandert van vorm. De eerste weken worden gedomineerd door mensen die een knop niet vinden. De maanden twee tot zes brengen de vragen die echt geld kosten: de afsluiting waarbij de cijfers niet meer aansluiten, de prijsregel die zich voor één klantengroep anders gedraagt, de intercompanyflow die niemand heeft getest omdat de overname laat rond was. Daarvoor is iemand nodig die het bedrijf begrijpt, en die vragen komen precies wanneer de mensen die het begrepen van het project zijn gehaald.

De context vertrekt met de implementatiepartner

Tijdens een implementatie bouwt een kleine groep een enorme hoeveelheid ongedocumenteerde kennis op. Waarom de kredietlimietcontrole vóór de orderbevestiging zit en niet erna. Van welke velden in de klantenstamgegevens de logistieke interface echt afhangt, in tegenstelling tot de velden waarvan ze volgens de specificatie afhangt. Waarom de Nederlandse entiteit een uitzondering heeft in haar belastingbepaling. Bijna niets daarvan staat op papier, want zolang het project loopt, zit iedereen die het nodig heeft in dezelfde ruimte. Bij de overdracht zijn de deliverables documenten: configuratiewerkboeken, testscripts, trainingsslides, een autorisatiematrix. Ze beschrijven wat het systeem doet. De dure kennis is waarom het dat zo doet, en dat waarom staat niet op de lijst met deliverables. Wanneer de partner vertrekt, verlaat die kennis het gebouw, en anders dan bij een ontbrekend document merkt u de afwezigheid pas op de dag dat u ze nodig hebt.

Een service desk die een wachtwoord kan resetten, maar geen workflow kan lezen

Support wordt vaak gekocht als service desk: geprijsd per gebruiker of per ticket, bemand door mensen die getraind zijn op het algemene gedrag van de software en niet op uw configuratie ervan. Binnen die scope is het team bekwaam. Toegangsproblemen, licenties, afdrukken, een rapport dat niets teruggeeft, een gebruiker die een extra rol nodig heeft. Allemaal afgehandeld, en snel. Dan komt er een ticket binnen: sinds dinsdag krijgen de orders van één klantengroep de verkeerde leveringsvoorwaarden mee. Dat is geen softwarevraag. Het is een vraag over een prijsconditie, een wijziging in de klantenstamgegevens en een verzendregel die op elkaar inwerken binnen uw order-to-cashproces, en om ze goed te beantwoorden hebt u iemand nodig die weet hoe dat proces hoort te lopen. Een generieke desk stuurt het door, escaleert het en sluit het uiteindelijk af met een manuele correctie. Die manuele correctie wordt daarna het proces, en niemand registreert dat als een fout, want het ticket werd binnen het afgesproken serviceniveau afgesloten.

Iemand is eigenaar van het systeem. Niemand is eigenaar van het proces.

Bijna elke organisatie stelt na de go-live een systeemeigenaar aan, meestal binnen IT. Die rol omvat beschikbaarheid, upgrades, autorisaties, integraties en kosten. Allemaal nodig, maar niets daarvan gaat over de vraag of order-to-cash of procure-to-pay van begin tot einde echt werkt. Bedrijfsprocessen lopen over afdelingen heen; systeemeigenaarschap niet. Wanneer de fout tussen sales en logistiek zit (en daar zit ze meestal), is er niemand wiens taak het is om de knoop door te hakken, dus bouwt elke afdeling een lokale oplossing en wordt de kloof ertussen groter. In een Benelux-bedrijf met 200 mensen is dat scherper dan in een groep met 5.000, want er is geen procesbureau om op terug te vallen en geen vrije capaciteit om er een op te richten. Het eigenaarschap valt dan toe aan de key user die het hardnekkigst klaagt, bovenop het werk dat die al deed. Dat is geen governancemodel, en het overleeft niet dat die persoon een nieuwe functie opneemt.

Ticketwachtrijen meten hoe snel iets wordt afgesloten, niet of het terugkomt

Supportcontracten worden gemeten op reactietijd en oplostijd. Beide zijn makkelijk te tellen, beide zijn makkelijk te rapporteren, en geen van beide vertelt u of dezelfde fout volgende maand terug is. Een wachtrij die geoptimaliseerd is op afsluitsnelheid, kiest steevast voor de workaround boven de structurele oplossing, want de workaround kost twintig minuten en sluit het ticket af, terwijl de oplossing een procesdiscussie, een testcyclus en een wijzigingsvenster vraagt. Het cijfer dat u wel iets zou vertellen, is welk aandeel van de tickets van deze maand herhalingen zijn van iets wat al eerder is gezien. Weinig organisaties meten dat, want daarvoor moet u tickets indelen volgens het bedrijfsproces dat ze raken in plaats van de module waarop ze werden geregistreerd. Wie het begint te meten, is meestal niet blij met het antwoord: een klein aantal onderliggende procesfouten dat stilletjes, jarenlang, een onevenredig groot deel van het volume veroorzaakt.

Elk terugkerend incident is een procesfout die een ticketnummer draagt.

Niets leidt een terugkerend incident naar een blijvende oplossing

Dit is de fout die de andere vijf omvat. Zelfs waar de kennis overleeft en iemand eigenaar is van het proces, hebben de meeste organisaties geen mechanisme dat “dit blijft maar gebeuren” omzet in een wijziging die ook echt wordt doorgevoerd. Incidenten leven in een servicedesktool. Wijzigingen leven in een projectpijplijn die pas opengaat bij een budgetronde. Daartussen zit een gat, en terugkerende problemen vallen er voorgoed in. De weg eruit hoeft niet verfijnd te zijn. Hij moet kort en saai zijn. Een maandelijkse review van herhaalde incidenten, gegroepeerd per proces. Eén benoemde persoon met de bevoegdheid om iets een procesfout te noemen in plaats van een gebruikersfout. En een vast budget voor verbeteringen die te klein zijn om projecten te zijn, want zonder budgetlijn moet elke verbetering verantwoord worden alsof het een nieuw initiatief is, en geen enkele haalt ooit die lat.

Waarschuwingssignalen om deze week na te gaan

Geen van deze signalen bewijst op zich dat uw support faalt. Drie of vier samen meestal wel.

• Uw key users beantwoorden meer vragen dan uw service desk, en dat staat nergens in hun functieomschrijving.
• Er zijn weer spreadsheets opgedoken voor een stap die het systeem zou overnemen.
• U kunt de eigenaar van het ERP of het CRM noemen, maar niet de eigenaar van order-to-cash.
• U kunt rapporteren welke modules de meeste tickets opleveren, maar niet welke bedrijfsprocessen dat doen.
• Het eerlijke antwoord op “waarom is het zo ingesteld?” is dat de consultant het zo heeft opgezet.
• Het opleidingsmateriaal beschrijft het proces nog zoals het werd ontworpen, niet zoals het nu echt loopt.
• Wijzigingen gebeuren alleen wanneer er budget komt voor een nieuw project; tussen projecten door verbetert er niets.
• De laatste drie dringende ingrepen waren tijdelijke workarounds, en ze zijn er alle drie nog.

Wat goed werkende support na de go-live echt nodig heeft

Het zijn niet meer uren, en zelden een grotere service desk. Het is een klein aantal structurele zaken. Een benoemde proceseigenaar aan de kant van de business voor elke end-to-endflow, met de bevoegdheid om tussen afdelingen te beslissen. Support bemand door mensen die uw proces kennen, niet alleen de handleiding van de leverancier. Een beslissingslogboek dat u van de implementatie overneemt en dat bijgewerkt blijft wanneer de configuratie verandert. Herhaling gemeten naast oplostijd. En een vaste route van herhaald incident naar blijvende oplossing, met een bescheiden budget eraan gekoppeld, zodat kleine verbeteringen niet hoeven te concurreren met investeringsprojecten.

Die functie kunt u intern opbouwen of extern inkopen, en bij de meeste middelgrote bedrijven in de Benelux wordt het een mengvorm: intern eigenaarschap van het proces, externe handen voor configuratie, ontwikkeling en het lastige integratiewerk. Wat niet werkt, is ze als bijzaak inkopen, tegen een prijs die door het ticketvolume wordt bepaald, bij wie het goedkoopst is nadat het projectbudget op is. Het beste moment om support na de go-live te ontwerpen, is vóór de go-live, zolang u nog onderhandelingsruimte hebt bij uw partner en de kennis nog in de ruimte zit. Het op één na beste moment is nu. Begin met de waarschuwingssignalen nog eens te overlopen en eerlijk te zijn over hoeveel u er herkent.