Insights
Technical write-ups and anonymised problem breakdowns, from work that shipped.
Everything here is written from problems that actually occurred, and everything here is anonymised. No client or employer is named, no client data appears, and identifying details are removed rather than disguised. What is kept is the part that transfers to anyone running the same class of system.
Where to start by platform
Epicor P21 & Kinetic Reporting and Integration
The platform-specific side: the four data-model traps that make P21 reports quietly wrong — open versus posted living in different tables, undated lines counted as successes, flags that exist on only one side, and identity that resolves through a fallback chain — plus what changes when the schema belongs to the vendor. Read this one if the question is which rows count.
What a Prophet 21 Upgrade Does to Your Reporting
Three different projects get called “the P21 upgrade” — a version upgrade, the desktop-to-web transition, and replacing Prophet 21 with Epicor Kinetic, which is a different product and not an upgrade at all. What each one breaks in the layer built on top of the schema, why none of it raises an error, and the two things worth capturing before the window opens because they cannot be recovered afterwards.
SQL Server Performance for ERP Reporting
The diagnostic method, independent of which ERP sits on top: the two patterns behind most slow reports, why logical reads beat runtime as a measure, and why applying the fix needs more care than finding it. Read this one if the question is why is this slow.
Technical articles
Why Your ERP Report Is Fast on Today and Times Out on Month-to-Date
The most common performance complaint in ERP reporting and the most consistently misdiagnosed. Short and long date ranges frequently read different tables, and if the history table has no index on the column you filter, the database reads all of it. Covers how to confirm it in about ten minutes, how to design the index, and what to check before adding one to a vendor schema.
The config was mine and the fix on paper was still wrong
A delivery and configuration audit run against this site, written up for the finding that the auditor was wrong rather than for the ones that held. Reading the config produced a defensible remediation item; three requests against the running system showed there was no defect, and that the item would have caused an outage-class fault. What config review can and cannot establish, and what a live probe still cannot tell you.
Case studies
A KPI console for people who were reading the operation from memory
Receiving and picker productivity metrics, including purchase price variance and on-time and in-full rates. Most of the work was deciding which rows count as evidence and which are absence of evidence — and keeping cost figures off screens that face a public floor.
The report that worked on Today and timed out on Month
Reported as “the dashboard is slow.” It was one unindexed date column on a table that shipped with the ERP. The diagnosis took minutes; applying the fix safely took the planning.
One label service instead of a label program per label
Several unrelated paths to a printer, each grown separately, layouts drifting apart. Replaced with one service where label sources are rows in a configuration table rather than new programs.
What tends to get written up here
Operational software problems where the request describes the symptom accurately and the cause not at all. “The dashboard is slow” that turns out to be an access path. “We need another label program” that turns out to be a missing abstraction. “We need a report” that turns out to be a disagreement about which rows count.
If you are running into one of these, the case studies show the shape of the work and operations modernization covers the larger engagement they sit inside.
Recognise one of these?
The first conversation is short and costs nothing.