Wie een tijdje een supportwachtrij voor Dynamics 365 Business Central of Finance and Supply Chain Management heeft beheerd, herkent het patroon: dezelfde tien of zo probleemtypen zijn goed voor het merendeel van de tickets, en een groot deel daarvan komt steeds terug. Dit artikel somt de gebruikelijke verdachten op, legt uit waarom ze terugkeren 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 de organisaties waarmee wij werken 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 boekt omdat een artikel geen boekingsgroep heeft, of een voorraadcorrectie die wordt geblokkeerd door een afgesloten periode. Dit zijn bijna altijd gaten in de configuratie of stamdata die opduiken bij de maandafsluiting, als de druk het hoogst is.
Inconsistente stamdata
Een artikel met de verkeerde kostprijsmethode, een klant zonder betalingsconditie, een leverancier die onder twee nummers bestaat, een locatie zonder ingerichte opslaglocaties. Het symptoom verschijnt in een proces; de oorzaak zit in de data.
Problemen met rapport- en documentlay-outs
De factuurlay-out toont voor één bedrijf de verkeerde bankgegevens, een aangepast rapport breekt na een update, een Power BI-dataset ververst niet meer omdat een API-pagina is gewijzigd.
Integratiefouten
Webshoporders die niet binnenkomen, afgewezen EDI-berichten, bankbestanden die niet importeren, ontbrekende magazijnbevestigingen. Vaak is de integratie uren eerder al stilletjes uitgevallen voordat iemand het merkte.
Rechten- en rolproblemen
Een nieuwe medewerker ziet de pagina's niet die hij nodig heeft; een langzittende gebruiker heeft veel meer rechten opgebouwd dan zijn functie vereist. Beide zijn symptomen van rollen die ad hoc worden beheerd in plaats van ontworpen.
Prestatieklachten
Trage pagina's, langlopende boekingsroutines en time-outs. De oorzaken lopen uiteen 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. Onderzoeken eindigen vaak bij een processtap die is overgeslagen of in de verkeerde volgorde is uitgevoerd.
Waarom ze terugkomen
Terugkerende incidenten zijn een teken dat support alleen in oplosmodus werkt. Een boekingsfout wordt verholpen 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 dit mogelijk maakte, blijft ontbreken.
Drie omstandigheden houden de cyclus in stand:
- Geen grondoorzaakstap 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 opnieuw gesteld, vaak door iemand anders.
- Support en verbetering concurreren om dezelfde uren. Als alle capaciteit naar incidenten gaat, wordt de configuratiefix die ze zou voorkomen nooit ingepland.
Een supportafspraak die incidentafhandeling scheidt van probleembeheer en maandelijks capaciteit reserveert voor structurele oplossingen, doorbreekt de cyclus. Dat is het ontwerpprincipe achter onze Application Management Services.
Een sjabloon voor supportverzoeken dat de oplostijd verkort
De snelste manier om de oplostijd te verkorten zit 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 ze worden verzameld. Gebruik deze structuur voor elk verzoek.
Sjabloon supportverzoek
- Samenvatting in één regel. Wat faalt, waar. "Boeken verkoopfactuur mislukt voor bedrijf NL02 met dimensiefout."
- Exacte melding. Kopieer de volledige foutmelding of voeg een schermafbeelding toe waarop die staat. Geparafraseerde meldingen kosten tijd.
- Waar en wanneer. Bedrijf, omgeving (productie of sandbox), pagina of rapport, document- of recordnummer, en de datum en tijd waarop het gebeurde.
- Stappen om te reproduceren. De volgorde die u volgde, vanaf de eerste handeling. Als het af en toe optreedt, zeg dat en geef twee voorbeelden.
- Wie is geraakt en wat is geblokkeerd. Eén gebruiker of iedereen? Kan het proces op een andere manier doorgaan? Loopt een deadline (maandafsluiting, verzendtijd) gevaar?
- Wat is er veranderd. Nieuwe gebruiker, nieuw artikel, nieuwe release wave, nieuwe integratie, gewijzigde inrichting? Alles wat de afgelopen dagen is gebeurd.
- Wat u heeft geprobeerd. Filters gewist, opnieuw aangemeld, bij een collega nagevraagd, in de sandbox geprobeerd.
- Gevraagde prioriteit en waarom. Zie de volgende paragraaf.
Acht punten klinkt als veel. In de praktijk is het drie minuten typen die een dag wachten bespaart, en het is precies de informatie waar een goede consultant anders om zou vragen.
De impact op de business eerlijk beschrijven
Supportprioriteiten werken alleen als beide kanten ze op dezelfde manier gebruiken. Een eenvoudige, eerlijke schaal:
| Prioriteit | Betekenis | Voorbeelden |
|---|---|---|
| Kritiek | Een kernproces ligt stil voor veel gebruikers en er is geen workaround. | Er kunnen geen facturen worden geboekt; het magazijn kan niet verzenden; de integratie is uitgevallen en orders stapelen zich op. |
| Hoog | Een kernproces is verstoord, of een deadline loopt gevaar, maar er is tijdelijk een workaround. | Maandrapportage geblokkeerd voor één bedrijf; een van twee EDI-partners faalt. |
| Normaal | Een functie werkt niet zoals verwacht; de business gaat door. | Fout in rapportlay-out; rechten van één gebruiker; af en toe traagheid. |
| Verzoek | Een wijziging, verbetering of vraag, geen storing. | Nieuw veld op een pagina; nieuw rapport; "hoe doe ik"-vragen. |
Alles "kritiek" noemen maakt het niet sneller; het maakt echte noodgevallen trager. Reserveer de hoogste niveaus voor stilliggende processen, en uw supportpartner behandelt ze ook zo.
Wat u controleert voordat u een ticket aanmaakt
- Treedt het probleem ook op bij een andere gebruiker, of in een ander bedrijf? (Dat vernauwt het tot rechten, inrichting of data.)
- Werkte het vorige week nog? Zo ja, wat is er veranderd: een release-update, een nieuwe extensie, een gewijzigde inrichtingspagina?
- Staat er een filter, weergave of 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 te reproduceren in de sandbox? Zo ja, dan kan support onderzoeken zonder productie aan te raken.
Geen van deze punten vereist technische kennis, en elk ervan haalt een heen-en-weer uit 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 grondoorzaaknotitie ontvangen als een probleem wordt gesloten; en maandelijks een overzicht van trends krijgen met aanbevelingen voor structurele oplossingen. U moet weten welke vaste consultants aan uw systeem werken en wie het senior escalatiepunt is. En u mag verwachten dat release waves op regressie worden getest voordat ze productie bereiken, zodat "het is kapot na de update" een zeldzaam ticket wordt in plaats van een kwartaaltraditie.
Als uw huidige afspraak dat niet biedt, ligt het probleem niet bij uw gebruikers of het platform. Het ligt bij het supportmodel, en dat is op te lossen.
Verder lezen: Business Central optimaliseren: waar organisaties meestal de snelste winst vinden en twaalf vragen om een ERP-supportpartner te stellen.