Author: Next

On the third business day of January, the controller of a $120 million food manufacturer emailed the board pack. Three years earlier, that same pack went out on day 12, and everyone had accepted it as normal.

Here’s what sat between those two numbers. None of it was about buying better software.

Where the twelve days actually went

We timed it. Not guessed — timed, with a simple log of who was waiting on what.

Four days went to building the inventory valuation in a spreadsheet because the system’s report didn’t match how the plant counted. Another three went to matching supplier invoices by hand, mostly freight bills with no purchase order behind them. Two more disappeared into accruals, because the same six entries were rebuilt from scratch every month by one person who took vacation in July.

That’s nine days of rework before anyone had analyzed a single number. The close wasn’t slow because accounting was slow. It was slow because transactions entered the system late and unclean.

The close doesn’t start on the 1st

This is the mental shift that made the difference. A three-day close is decided during the month, in the plant and on the dock, not in the finance office on the last weekend.

1. Set a hard cutoff for goods receipts: anything received after 2 p.m. on the last working day goes into the next period, no exceptions, and the plant knows the rule in advance.
2. Move invoice matching to the receiving clerk who actually knows what arrived, with a 48-hour turnaround. Finance only handles exceptions, which dropped from 400 a month to about 60.
3. Lock the six recurring accrual templates once, with amounts reviewed monthly instead of rebuilt monthly. One afternoon of work, roughly two days back per close.
4. Assign one named owner per sub-ledger reconciliation. Shared ownership is why nobody notices a $40,000 variance until audit season.

The fifteen minutes that fixed the handoffs

During close week they run a 15-minute standup at 8:30, plant controller, AR lead, AP lead, inventory clerk. Each person says one thing: what they’re waiting on. That’s it.

It sounds too simple to matter. In the first month it surfaced a blocked receipt that would have pushed the close by two days. The whole conversation took eleven minutes.

If you’re bringing in ERP Consulting to fix a slow close, watch whether they spend their first week in the finance office or on the shop floor. The answer tells you a lot about whether you’ll get a real result or a nicer-looking report.

What to do this month

Before you change anything, log one close. Write down every day, who was waiting, and on what. Most controllers find two-thirds of the delay sits in three or four repeat offenders, and half of those are outside finance entirely.

Fix the top one first. Don’t redesign the whole close in a single heroic project — that’s how you get a beautiful process map and no behavior change.

“How many of these do we actually have?” The warehouse manager looked at the screen, then at the shelf, then back at the screen. The system said 240 units. The shelf held 61.

That was a Tuesday in March. The company is a building-products distributor doing about $85 million a year out of two warehouses. Nobody thought they had an inventory problem — until that one SKU turned out to be one of about 1,900 that were wrong.

The 18% nobody budgeted for

We ran a blind count of 400 SKUs. Blind means the counter gets a blank sheet and a shelf, with no system number to copy down.

The result: 18% of counted SKUs were off by more than 5%. One in five. Finance had been closing the books on those numbers for years without knowing it.

The cost wasn’t abstract. Roughly $310,000 of stock sat in bins the system called empty, so nobody sold it. At the same time the system showed 900 units of a fast mover that didn’t exist, so sales kept promising delivery dates on air.

Stop counting everything, count the right things

A wall-to-wall annual count feels responsible and fixes almost nothing. You shut the warehouse for a weekend, find a variance, adjust the number, and three months later it’s wrong again — because nobody asked why it drifted.

Here’s what actually worked:

• Split all 4,800 SKUs into A/B/C by annual dollar movement. The 380 A items got counted monthly, B quarterly, C once a year.
• Count 15 to 25 SKUs every morning before the first truck leaves. One person, about 40 minutes, no shutdown.
• Log the reason, not just the variance. Pick errors, receiving short-ships, unrecorded returns and wrong units of measure accounted for nine out of ten errors we found.
• Recount any A item that’s off by more than 2% within 48 hours, and read the transaction history before touching the number.

The awkward part: it was never the software

By week six the pattern was obvious. Two-thirds of the errors started at receiving, on a dock where product arrived faster than anyone could key it in. People were typing quantities from memory at 5 p.m. because the line was already backing up.

The fix was a scanner at the dock and a hard rule that nothing gets put away before it’s received. It cost less than the value of one miscounted pallet, and weekly variance dropped by roughly 60%.

This is where ERP Consulting engagements either earn their keep or waste your money. Software holds the record; it doesn’t create the discipline. Buy a new system and change nothing about how the dock works, and your numbers stay wrong — just faster.

Where they landed at day 90

Accuracy on A items went from 82% to 97.4%. Write-offs on dead stock fell by $190,000 over the next two quarters, and the buyer stopped padding safety stock on items that were never actually short.

One detail is easy to skip and matters more than it sounds. They now write the accuracy number on a whiteboard in the warehouse every Monday. Not to shame anyone — as a score. People got better partly because they could finally see the number move.

Tomorrow morning, pull 20 SKUs that sell every week and count them blind. If more than two are off by 5% or more, you now know exactly where next quarter goes.

Sixteen months after go-live, a 300-employee specialty chemicals maker finally ran a benefits review. The result was uncomfortable. They had spent $1.4 million and could prove $310,000 in savings.

The rest was not wasted. It was simply never measured, because nobody had written down a baseline before the project started.

The mistake happens in month one, not month twelve

If you do not record today’s numbers, you cannot claim credit later. Before any configuration work begins, write down six to eight measures with their current values.

• Days to close the books each month.
• Inventory record accuracy, measured on a fixed sample of 100 items.
• On-time delivery percentage.
• Order entry time per order, timed with a stopwatch.
• Number of manual spreadsheet handoffs in the order-to-cash cycle.
• Overtime hours in finance and the warehouse during the last week of each month.

Twelve numbers on one page, dated and signed by the sponsor. That page is worth more than any status report you will ever produce.

What the chemicals maker found at month 12

Close time fell from 11 days to 6. Order entry dropped from 14 minutes to 5. Inventory accuracy rose from 78% to 94%. Real, provable gains.

But nobody had tracked expedited freight, which had quietly doubled over the same period. A benefit you do not measure is a cost you will discover later. Most ERP Consulting value disappears in the gap between go-live and the first honest review.

How to run the review in one afternoon

1. Pull the baseline page and recompute every number exactly the way it was first measured.
2. List every result, including the ones that got worse. The bad numbers are the reason to run the review at all.
3. Pick the three largest gaps and assign each an owner with a 90-day target.
4. Give the sponsor a one-page summary, not a slide deck. One page gets read.

Schedule this review before go-live. Put it on the calendar for month 12 with the sponsor’s name on the invitation, so it cannot quietly disappear.

Today, open a document and write the six numbers you can measure this week. It takes 20 minutes, and it is the difference between running a project and proving a result.

A 90-person distribution center went live in March. By April, three of the four warehouse leads were writing quantities on paper and typing them in at the end of the shift.

The project sponsor called it resistance. I called it survival. The new system asked for 11 extra steps per receipt, and nobody had explained why any of it mattered.

What training looked like versus what was needed

Two days of classroom sessions, three weeks before go-live. A 120-page manual in a binder. One super-user per shift who was also expected to hit their normal picking numbers.

People do not forget how to use a system. They forget why the new step exists. That is a different problem, and it needs a different fix.

Four changes that actually shifted behavior

1. We rewrote every procedure as a one-page card with the reason at the top: scan at the dock so receiving disputes stop taking four days.
2. We moved training to the week before go-live, in 45-minute sessions on the floor, using real pallets and real scanners.
3. We named one expert per shift and pulled them off normal work for two weeks. Not a volunteer — a named person with a backup.
4. We tracked one metric per week, receipts scanned at the dock, and posted it on a board everyone walked past.

Within five weeks, dock scanning hit 96%. The paper notes disappeared on their own, because paper no longer solved a problem anyone cared about.

The ten minutes that matter most

Every shift start, the lead spends ten minutes on one question: what is still slowing you down in the system? Answers go on a whiteboard and someone owns each one within 24 hours.

That single habit does more for adoption than any training budget. It tells your team the system is not finished until their workday gets easier. I have never seen an ERP Consulting engagement succeed on classroom hours alone, and I have watched a lot of them try.

Tomorrow morning, stand at the busiest workstation in your building for 30 minutes and just watch. Ask what they still write on paper. That paper is your real training plan.

The CEO of a 200-employee equipment rental business said something I hear on almost every project: the data is messy, but we will clean it after go-live. They went live on a Monday.

By Wednesday, four branches were renting equipment that did not exist in the system, and two customers had been invoiced twice. Data problems do not wait for a cleanup phase.

Myth 1: We will clean it later

There is no later. Once people start transacting on bad data, every new record inherits the mess. Their duplicate customer list grew from 1,900 records to 2,600 in five weeks because nobody could tell which record was real.

Cleaning it afterward cost $230,000 in overtime, temporary staff, and customer credits. Doing it before go-live was quoted at $48,000. Same work, different timing, five times the price.

Myth 2: Our data is not that bad

Every company believes this. Then you run three simple checks and the belief quietly dies.

• Duplicate check on customer and item master. The rental company found 22% duplicates.
• Orphan check: records with no owner, no location, or no cost attached. They found 1,400.
• Unit of measure check: how many items are bought in cases and sold in single units? They found 340 mismatches.

Myth 3: IT will handle the migration

IT can move files. IT cannot decide whether Acme Rentals and Acme Rental LLC are the same customer. That call belongs to sales and credit, and it always will.

Data ownership belongs to the department that lives with the consequences. Assign one business owner per data group: customers, items, vendors, employees, pricing.

Myth 4: We only need the last two years

Maybe. But sales will want three years for trend reporting, and legal may need seven. Decide the cut-off in writing, with the people who will complain later, before anyone starts extracting.

Here is what I would do this week. Pick your customer master and your item master. Run a duplicate count and a blank-field count. That one-hour exercise tells you more about go-live risk than any project plan, and it is the cheapest piece of ERP Consulting you will ever buy. Any ERP Consulting team that calls migration a technical task has never sat through a credit hold meeting.

I need a $200 part to fix a machine that is down. It has been three days. That was a maintenance supervisor at a 75-person construction supplier, and he was not exaggerating.

His request needed a supervisor, a plant manager, and the controller — in that order, and only when each was at their desk. The machine sat idle for 62 hours.

What the approval matrix actually cost

We pulled 12 months of purchase orders. Of the 8,400 orders raised, 71% were under $500. Those orders consumed 58% of the plant manager’s approval time.

He was spending nearly three days a month approving bolts. That number changed his mind faster than any process theory. When I run ERP Consulting assessments, this approval chain is always the first place I look — it is the one nobody has questioned since 2016.

The three-tier rule that fixed it

• Under $500: the buyer approves alone. Recorded automatically, reviewed monthly by exception report.
• $500 to $10,000: one manager approval, with auto-approval after 24 hours of silence.
• Above $10,000: manager plus finance, with a required written reason.

The auto-approval caused the loudest argument. Six months later it had fired 340 times and produced two poor purchases worth $11,000. It saved roughly 200 manager-hours. You can decide for yourself which number matters more.

What to check before you loosen anything

1. Pull the last 12 months of purchase orders and count them by value band.
2. Find the band with the most orders but the least total spend. That is your bottleneck.
3. Set the threshold there and replace daily approvals with a monthly exception report.
4. Give the controller authority to reverse the change if the report shows abuse two months running.

Start with the data pull. One analyst, one afternoon, one spreadsheet sorted by amount. Most approval matrices were written years ago for a company that no longer exists.

The maintenance supervisor got his part in 40 minutes after this change. That is what useful ERP Consulting looks like on a shop floor: a machine running, not a signature collected.

Ask a controller what they did last weekend and the answer is usually close. A 260-person food producer finished its month-end close on day 14, every month, for six years. The finance team had stopped calling it a problem.

It was a symptom, not a schedule. Here is the timeline we found on day one of the review.

Where the 14 days actually went

• Days 1 to 3: waiting for the warehouse to count inventory and email a spreadsheet.
• Days 4 to 6: three people reconciling that spreadsheet against the general ledger by hand.
• Days 7 to 9: chasing 40 open purchase orders with no receipt recorded.
• Days 10 to 12: manual journal entries for freight, rebates, and production scrap.
• Days 13 to 14: rework. Something broke on day 10 and got fixed on day 13.

Notice what is missing from that list: accounting judgment. Almost two weeks went to moving data between people.

Three changes that cut nine days

None of them required new software. All three required someone to own the process and keep owning it.

1. Receiving started scanning against the purchase order the moment a truck arrived. Days 7 to 9 disappeared because open receipts stopped existing.
2. Inventory moved to weekly cycle counts of 60 items instead of one giant month-end count. The warehouse stopped being the bottleneck.
3. Freight and rebate accruals became rules that ran every night. Three days of journal entries turned into a 20-minute review.

By month five the close finished on day 5. By month nine, on day 4. Nothing about the accounting changed — only when the data was captured and who was accountable for it.

Where most companies stop too early

The team wanted to declare victory at day 5. I pushed for one more habit: a 30-minute review on day 6 where every close task owner says what broke and what they did about it.

That is the part of ERP Consulting companies underinvest in — process ownership, not configuration. A close that finishes in four days but breaks forty times is a fragile close.

Pick your three biggest close bottlenecks and write them on a wall this week. Assign one owner and one deadline to each. Six years of frustration usually comes down to three tasks nobody owned.

The plant manager was proud of his list. One hundred forty-seven change requests, gathered from every department over four months. He called it making the system fit how we work.

Fourteen months later they went live with 61 of them, and those 61 nearly broke the company. Every customization is a small promise you keep forever — through upgrades, new hires, and audits. Custom code does not retire when the person who asked for it does.

We sorted 147 requests in two hours

Three piles on a whiteboard. The result surprised everyone in the room, including the plant manager. I have run this sort on every ERP Consulting project for over a decade, and the ratio is almost always the same.

• 89 requests were workarounds for a process that was already broken. The software was never the problem.
• 40 were reporting preferences — one more column, a different label. Those belong in reports, not in the core workflow.
• 18 were genuinely specific to the business, like tracking customer-supplied tooling through the shop floor.

The honest number was 18. Not 147. That is an eight-fold difference in what you maintain for the next ten years.

The question that kills most requests

Ask the requester: if this screen looked different but the outcome stayed identical, would you still need it? Most people say no. They were describing a habit, not a requirement.

Then ask: what happens if we do nothing for 90 days? Anything that can wait 90 days usually reveals itself as a preference. Requirements that survive both questions go to the steering committee, not to a developer’s queue.

How to run change requests after go-live

1. One form, one inbox, one weekly review meeting. No hallway requests, no emails to the IT manager.
2. Every request states the business problem in one sentence and the cost of not solving it.
3. Approved changes ship in a quarterly bundle. Nothing goes in alone.
4. Every approved change gets an owner who confirms the benefit 60 days later.

Budget 20% of your project time for post-go-live changes and treat that budget as fixed. When it runs out, new requests wait for next quarter.

The most valuable thing ERP Consulting delivers is rarely the configuration. It is the discipline to say no. Apply the two questions above to your next change request before it reaches anyone’s backlog — that single habit saves more money than any technical decision you will make this year.

Three weeks before go-live, the operations manager at a 42-person industrial parts distributor told me the system was ready. Then I asked one question: how accurate is your on-hand inventory right now? He guessed 95%.

The physical count said 71%. That gap is why the first month on the new system was chaos. Pickers walked to empty bins, customer service promised parts that did not exist, and the sales team spent its mornings apologizing. Every wrong number in the system came from a wrong number on the shelf, not from the software.

The number that predicts your go-live

Before you move a single transaction into a new system, count your top 200 SKUs by hand. Not a comfortable sample. The top 200 by movement.

If accuracy lands under 90%, stop the go-live date and fix the warehouse first. A 71% accurate warehouse produces a 71% accurate system, no matter how much ERP Consulting money you pour into configuration.

• Freeze the warehouse for two days. No shipping, no receiving, no exceptions for urgent orders.
• Count in teams of two — one counter, one recorder. Single-person counts hide errors.
• Tag anything without a barcode location before the count starts, not during it.
• Recount every variance over 5 units the same day, while people still remember what happened.

Why counting is cheaper than cleaning up

The distributor spent four days counting. The alternative was six weeks of expedited freight, credit memos, and a sales force explaining shortages to 300 accounts.

Expedited shipping alone ran $18,000 in the first month. The count cost about $6,000 in labor and lost shipping time. One of those numbers prevents the other. Do that math before you argue about the schedule.

What to do the Monday after the count

1. Post the corrected quantities in your current system, even if you replace it in 60 days. Your people need a clean starting line.
2. Write down the top five reasons for variances — receiving shortcuts, unrecorded scrap, wrong units of measure. Fix the top two this month.
3. Set a weekly cycle count of 40 items and hold one named person accountable for posting results every Friday.

Good ERP Consulting starts in the aisles, not in the conference room. If your accuracy sits above 95% for three straight weeks, you are ready to go live. If it does not, move the date. Nobody remembers a delayed go-live. Everybody remembers a month of wrong shipments.

Start with the ending. A 90-person specialty food distributor built a custom pricing screen in year one. Three years later they shut it off and rebuilt the same capability using standard features. The traceable spend was $274,000, plus a nine-month delay on every reporting improvement the company wanted.

The original quote was $40,000. Everyone in that meeting thought it was reasonable. Here is what the next three years looked like.

How forty thousand became two hundred seventy-four

• $40,000 to build the screen, as quoted.
• $11,000 in bug fixes during the first year, mostly around edge cases in customer-specific pricing.
• $62,000 to rewrite it when the company upgraded versions — the custom code had to be rebuilt, and the upgrade stalled for seven months.
• $54,000 in elevated support fees across three years, because custom code sits outside standard coverage.
• $38,000 of two employees’ time rekeying pricing that the custom screen failed to apply correctly.
• $47,000 in regression testing across three releases to confirm the custom screen had not broken anything else.
• $22,000 to eventually tear it out and rebuild with standard pricing rules plus one report.

The rebuild took six weeks and worked better than the original. It also required no testing at the next upgrade.

Why the request felt reasonable at the time

Customer service had a real problem. They were quoting specialty pricing from a spreadsheet, and mistakes were costing margin. A screen that showed contract price and current margin next to each line would fix it.

The request was fine. The delivery method was the mistake.

How to say no without losing the room

1. Write the requirement in plain language first: “Show contract price and margin on the order entry screen.”
2. Ask three people, separately, to describe how they would solve it in the current system. You will usually get one workable answer.
3. Price both paths out loud: the custom build plus a three-year support estimate, next to the standard approach plus a report.
4. Ask the requester which one they would pick if it were their budget.
5. If you still customize, put a named owner and a yearly review date on it. Custom code without an owner becomes permanent.

The rule I give managers is simple: customize when it creates revenue, not when it saves someone four clicks. Most of the requests I see fall into the second bucket, and the second bucket is where budgets quietly die.

That distinction is the heart of good ERP Consulting. The best ERP Consulting advice on a customization request is often a question: what would you do if this feature did not exist? The answer usually costs nothing and ships in a week.

Next time a custom request lands on your desk, ask for the three-year number, not the build number. Then decide.