Van afwachten naar vooruitkijken: waarom wij Business Central-support proactief zijn gaan doen

Lange tijd werkte support bij ons zoals bij vrijwel elke ERP-partner: er komt een melding binnen, wij pakken hem op, we lossen het op. Dat werkt, maar het heeft één groot nadeel. Tegen de tijd dat een gebruiker belt of een ticket aanmaakt, heeft hij of zij al last gehad. Een boeking die niet lukte, een scherm dat hing, een order die niet doorkwam.

De afgelopen maanden hebben we dat omgedraaid. We kijken nu dagelijks mee in de telemetrie van de Business Central-omgevingen die we beheren. Elke avond ligt er een dagrapport dat de afgelopen 24 uur vergelijkt met het gemiddelde van de week ervoor. Valt er iets op, dan gaan wij erop af. Vaak voordat de klant zelf doorheeft dat er iets speelt.

Het opvallende is: de meeste dingen die we zo vinden, waren nooit als klacht binnengekomen. Gebruikers wennen aan een traag scherm of een foutmelding die “er nu eenmaal bij hoort”. Juist daar zit de winst.

Wat is telemetrie eigenlijk?

Business Central houdt op de achtergrond bij wat er in het systeem gebeurt: welke processen lang duren, waar tabellen op elkaar wachten (locking), welke foutmeldingen gebruikers zien en welke integraties falen. Die gegevens zijn er altijd, maar bijna niemand kijkt ernaar. Wij wel. Niet als eenmalige analyse, maar elke dag, met vaste controles en signalen die ons mailen zodra er iets afwijkt.

Hieronder een paar voorbeelden uit de praktijk van de afgelopen periode.

Voorbeeld 1: iedereen tegelijk transferorders boeken

Bij een klant met een groot magazijn zagen we op één dag 61 database lock-timeouts. Bijna allemaal (54) op dezelfde plek: het registreren van magazijnjournaalregels. De oorzaak was simpel. Het magazijndagboek werd overdag intensief gebruikt om transferorders te boeken, door meerdere mensen tegelijk. Die boekingen strijden om dezelfde regels in de database, en dan moet iedereen op elkaar wachten.

Niemand had hierover een ticket aangemaakt. Maar de hele operatie merkte het: andere gebruikers die op hetzelfde moment iets wilden boeken, liepen ook vast.

Ons advies was om deze boekingen te bundelen en waar mogelijk in te plannen, buiten de drukste uren. Het gesprek daarover voerden we samen met de kerngebruiker van het magazijn. Geen technische ingreep, maar een andere werkwijze die het systeem voor iedereen sneller maakt.

Voorbeeld 2: de voorraadwaardering die steeds langer duurt

Kostprijsaanpassing (Adjust Cost, Item Entries) is een standaard batch in Business Central die de voorraadwaardering bijwerkt. Bij een klant zagen we dat die batch steeds meer tijd kostte en tijdens het draaien tabellen vasthield waar het dagelijkse werk ook op boekte. Gevolg: lock-timeouts op willekeurige momenten.

Toen we de werkvoorraad van de batch analyseerden, bleek bijna 85% te bestaan uit service-artikelen zonder kostprijs. Denk aan voorrijkosten, toeslagen en contractartikelen. Daar valt niets te herwaarderen, maar de batch rekende ze bij elke run opnieuw door, sommige al sinds 2023. Daarbovenop hielden oude, nooit gefactureerde ontvangsten en retouren de keten open.

De oplossing was verrassend klein: één instelling op de juiste artikelen aanzetten zodat ze buiten de kostprijsaanpassing vallen, en een opschoonactie voor de oude ontvangsten. We legden vooraf een nulmeting vast (ruim 10.000 openstaande posten), zodat het effect zwart op wit te zien is. De reactie van de klant zei genoeg: het was wel bijzonder dat dit pas na drie jaar boven water kwam.

Bij een andere klant liep het andersom. Daar stond de kostprijsaanpassing op handmatig, terwijl uit de data bleek dat er geen enkele achterstand was. We konden de instelling dus zonder risico naar automatisch zetten, waarmee een dagelijkse handeling verviel. Tegelijk vonden we tientallen inkoopontvangsten die nooit gefactureerd waren, waardoor orders en voorraadposten onnodig open bleven staan. Na het opschonen van circa 2.700 oude inkooporders werden zowel de kostprijsberekening als het ophalen van regels op inkoopfacturen direct sneller.

Voorbeeld 3: foutmeldingen die nooit gemeld worden

Op een zaterdagochtend zagen we dat één gebruiker binnen een paar uur opvallend veel foutmeldingen kreeg. Vijf keer werd het boeken van een inkoopfactuur tegengehouden. Tien keer achter elkaar verscheen “Geen grootboekrekening in het filter” bij het zoeken naar een grootboekrekening. En in de bankreconciliatie stond een regel met een rekeningnummer dat niet als leverancier bestond.

Er was niets structureel stuk. Maar iemand zat op zaterdag te worstelen met zijn administratie. In plaats van te wachten tot er op maandag een ticket kwam, stuurden we zelf een korte mail: we zagen dit, liep je ergens op vast, zullen we even meekijken?

Dat is precies het verschil. De gebruiker hoeft niet uit te leggen wat er misging, want wij weten het al.

Voorbeeld 4: de integratie die “geslaagd” meldde terwijl hij faalde

Bij een klant met een koppeling tussen planningssoftware en Business Central bleek een planningsupdate niet verwerkt. Bij het uitzoeken vonden we in de telemetrie dat dit in de afgelopen 30 dagen 15 keer was gebeurd op bijna 4.000 updates. Dat is 0,4%. Klein, maar vervelend, omdat de integratie de stap ten onrechte als geslaagd meldde. Niemand zag het, totdat een monteur bij de klant voor de deur stond op een ander tijdstip dan afgesproken.

De vraag van de klant was terecht: hoe houden we dit ’s avonds en in het weekend in de gaten? Ons antwoord: met een controle die elk uur, 24/7, kijkt of deze specifieke fout is opgetreden en dan direct mailt, met het ordernummer erbij. Ondertussen bouwen we de structurele oplossing.

Wat het oplevert

Proactieve support gaat niet over meer tickets oplossen. Het gaat over minder last voor gebruikers. Wat we de afgelopen maanden zien:

• Problemen worden kleiner opgelost. Een instelling aanpassen of een werkwijze bijsturen is goedkoper dan een maand later een grote verstoring uitzoeken.
• Stille fouten worden zichtbaar. Processen die “succes” melden maar niets doen, vallen in een foutteller niet op. In de telemetrie wel.
• Het gesprek verandert. We komen niet meer alleen met antwoorden op vragen, maar met inzichten over de eigen omgeving van de klant: waar het knelt, waarom, en wat het kost.
• Meer vertrouwen in het systeem. Een klant vertelde ons in een maandoverleg dat juist het proactief werken aan stabiliteit en snelheid het vertrouwen in Business Central verbetert. Dat is voor ons de belangrijkste uitkomst.

Reactief of proactief?

Reactieve support blijft nodig. Er zullen altijd vragen en meldingen zijn die alleen een gebruiker kan stellen. Maar als het enige moment waarop uw partner naar uw omgeving kijkt het moment is waarop er iets mis is, dan mist u veel.

Daarom de vraag aan u: wilt u voor uw Business Central-omgeving reactieve ondersteuning, of proactieve? Wachten tot er iets misgaat, of iemand die meekijkt en u belt voordat het zover is?