Veelvoorkomende Dynamics 365-supportproblemen, en hoe u een supportverzoek schrijft dat sneller wordt opgelost

Wie een tijdje een supportwachtrij voor Dynamics 365 Business Central of Finance and Supply Chain Management heeft beheerd, herkent het patroon: een stuk of tien probleemtypen zijn goed voor het merendeel van de tickets, en een groot deel daarvan zijn herhalingen. Dit artikel benoemt de gebruikelijke verdachten, legt uit waarom ze terugkomen, en geeft u een eenvoudige structuur voor supportverzoeken waarmee u sneller tot een oplossing komt, wie uw support ook levert.

De supportproblemen die blijven terugkomen

Bij mkb- en middenbedrijven vallen de terugkerende incidenten in een handvol groepen.

Boekings- en periodefouten

"U heeft geen rechten om in deze periode te boeken", dimensiefouten op een dagboekregel, een verkoopfactuur die niet geboekt kan worden omdat een artikel geen boekingsgroep heeft, of een voorraadcorrectie die wordt geblokkeerd door een gesloten periode. Dit zijn bijna altijd gaten in configuratie of stamgegevens die bij de maandafsluiting aan het licht komen, precies wanneer de druk het hoogst is.

Inconsistente stamgegevens

Een artikel met de verkeerde kostprijsmethode, een klant zonder betalingsconditie, een leverancier die onder twee nummers voorkomt, een locatie zonder inrichting van opslaglocaties. Het symptoom verschijnt in een proces; de oorzaak zit in de data.

Problemen met rapporten en documentlay-outs

De factuurlay-out toont voor een van de bedrijven de verkeerde bankgegevens, een aangepast rapport gaat stuk na een update, een Power BI-dataset ververst niet meer omdat een API-pagina is gewijzigd.

Integratiestoringen

Webshoporders die niet binnenkomen, afgewezen EDI-berichten, bankbestanden die niet importeren, ontbrekende magazijnbevestigingen. Vaak is de integratie al uren eerder stilletjes uitgevallen voordat iemand het merkte.

Rechten- en rolproblemen

Een nieuwe medewerker ziet de pagina's niet die hij nodig heeft; een medewerker die er al jaren werkt, heeft veel meer rechten verzameld dan zijn functie vereist. Beide zijn symptomen van rollen die ad hoc worden beheerd in plaats van ontworpen.

Klachten over traagheid

Trage pagina's, langlopende boekingsroutines en time-outs. De oorzaken variëren van zware maatwerkcode tot inefficiënte rapporten tot een sandbox die als productie wordt gebruikt.

"Het systeem klopt niet" (maar het is het proces)

Voorraad die niet overeenkomt met de stelling, marges die er verkeerd uitzien, intercompany-saldi die niet aansluiten. Onderzoek eindigt regelmatig bij een processtap die is overgeslagen of in de verkeerde volgorde is uitgevoerd.

Waarom ze terugkomen

Terugkerende incidenten zijn een teken dat support uitsluitend in reparatiemodus werkt. Een boekingsfout wordt opgelost door de periode te openen; de vraag waarom het periodeschema niet werd bijgehouden, wordt nooit gesteld. Een dubbele leverancier wordt samengevoegd; de ontbrekende validatie die de dubbeling mogelijk maakte, blijft ontbreken.

Drie omstandigheden houden de cirkel in stand:

• Geen oorzaakanalysestap in de ticketworkflow. Als het ticket sluit zodra de gebruiker verder kan, is niemand eigenaar van het onderliggende probleem.
• Geen kennisbank. Dezelfde diagnose wordt elke keer vanaf nul gesteld, vaak door een andere persoon.
• Support en verbetering concurreren om dezelfde uren. Als alle capaciteit naar incidenten gaat, wordt de configuratiefix die ze zou voorkomen nooit ingepland.

Een supportregeling die incidentoplossing scheidt van probleembeheer, en maandelijkse capaciteit reserveert voor definitieve oplossingen, doorbreekt de cirkel. Dat is het ontwerpprincipe achter beheerde applicatiesupport.

Een sjabloon voor supportverzoeken dat de oplostijd verkort

De snelste manier om de oplostijd te verkorten ligt aan uw kant van het ticket. De meeste vertraging ontstaat bij de eerste uitwisseling: de supportconsultant heeft drie of vier feiten nodig die het verzoek niet bevatte, en er gaat een dag voorbij terwijl die worden verzameld. Gebruik deze structuur voor elk verzoek.

Acht punten klinkt als veel. In de praktijk is het drie minuten typen die een dag wachten besparen, en het is precies de informatie waar een goede consultant anders om zou vragen.

De bedrijfsimpact eerlijk beschrijven

Supportprioriteiten werken alleen als beide partijen ze op dezelfde manier gebruiken. Een eenvoudige, eerlijke schaal:

Alles als "kritiek" markeren maakt het niet sneller; het maakt echte noodgevallen trager. Reserveer de hoogste niveaus voor stilgevallen processen, en uw supportpartner zal ze ook zo behandelen.

Wat u controleert voordat u een ticket aanmaakt

• Treedt het probleem ook op bij een andere gebruiker, of in een ander bedrijf? (Beperkt het tot rechten, instellingen of data.)
• Werkte het vorige week nog? Zo ja, wat is er veranderd: een release-update, een nieuwe extensie, een gewijzigde instellingenpagina?
• Staat er een filter, een weergave of een opgeslagen instelling op de pagina die verklaart wat u ziet?
• Is het document of record waaraan u werkt compleet (boekingsgroepen, dimensies, datums, locaties)?
• Is het reproduceerbaar in de sandbox? Zo ja, dan kan support onderzoek doen zonder productie te raken.

Geen van deze controles vereist technische kennis, en elke controle scheelt een heen-en-weer in het ticket.

Wat u van uw supportpartner mag verwachten

Goede support is zichtbaar. U moet van elk ticket de status, prioriteit en historie kunnen zien; een oorzaaknotitie ontvangen als een probleem wordt gesloten; en maandelijks een overzicht van trends krijgen met aanbevelingen voor definitieve oplossingen. U moet weten welke consultants bij naam aan uw systeem werken en wie het senior escalatiepunt is. En u mag verwachten dat release waves worden regressiegetest voordat ze productie bereiken, zodat "het ging stuk na de update" een zeldzaam ticket wordt in plaats van een kwartaaltraditie.

Als uw huidige regeling dat niet biedt, ligt het probleem niet bij uw gebruikers of bij het platform. Het ligt bij het supportmodel, en dat is op te lossen.

Verder lezen: Business Central optimaliseren: waar mkb-bedrijven meestal de snelste winst behalen en twaalf vragen aan een ERP-supportpartner.