Frequently Asked Questions

Three things, and they are structural, not marketing.

First, we separated advice from software. Staudt Advisory is a distinct division that sells no ERP. It cannot. That means when Advisory tells you the system you already own is salvageable, or that the fix is process rather than software, there is no commission riding on the answer.

Second, we assess before we quote. We do not price an implementation off a discovery call. Anyone who does is pricing assumptions.

Third, we only do discrete manufacturing. Multi-level BOMs, engineering change that never stops, traceability you have to prove. We are not a generalist firm that also does manufacturing.

No, and this is exactly why the two divisions exist.

Staudt Services is an Official Odoo Partner. That is real and we are good at it. But Advisory does not sell Odoo, does not earn on Odoo, and is not measured on Odoo. If you engage Advisory for readiness or selection work, the recommendation may be a different platform, a fix to the system you already own, or no system project at all this year.

We would rather tell you the truth and lose the implementation than sell you a project that fails in month nine. Failed implementations are how firms in this industry lose their reputation, and we intend to keep ours.

The dividing line is the system you already own. If you do not have an ERP yet, you start with Services. If you already have one and it is not doing what you were told it would do, you start with Advisory.

There is one crossover. If a readiness assessment comes back no-go, Advisory can take the remediation work and stay with you until you are ready — and because Advisory sells no ERP, you are free to buy any system you want when you get there.

Lee Stout conducts the assessments personally. Every one of them.

The background behind that: 25 years running MRP and ERP inside discrete manufacturing operations, and IT-side business systems work since 2014. This industry was part of my life long before it became my profession, which gives me a practical understanding of manufacturing that is hard to fake and even harder to replace.

You are not paying for a methodology deck built by someone who has never stood in front of a router with a revision problem on it.

Because ERP success is decided upstream, before a system is ever selected.

Most operational problems are not software problems. They are business problems that eventually show up in the numbers. If your BOMs are wrong, ERP will plan against wrong BOMs faster and more confidently than your spreadsheets ever did. If nobody trusts the inventory count today, a new system inherits that distrust on day one.

The assessment tells you which problems are process problems, which are data problems, and which are genuinely system problems. Those three categories have completely different price tags and completely different timelines. Skipping that step is how a scoped project turns into a change-order project.

That is stage one of three. What It Costs lays out all three stages, what each one includes, and which fees credit back.

This is a Services engagement. We look at six areas:

You get three things:

No obligation attached to any of it.

Then we tell you that, in writing, and you save a great deal of money.

A no-go is not a dead end. It is a sequence. The report tells you what has to be true before a system project makes sense — usually BOM cleanup, an inventory process that holds, and clarity on who owns which data. Those are fixable, often in a quarter or two, often with your own people once someone tells them what to fix and in what order.

From there you have two paths. Some clients hand the plan to their own team and run it themselves — a legitimate outcome and we are fine with it. Others engage Staudt Advisory to do the work with them and stay engaged until they are ready.

The second path is worth understanding. Advisory sells no ERP. So when the remediation is done and you are ready to buy, you can select any system you want — Odoo, or anything else on your list. Nothing about that engagement obligates you to us or to a platform.

Because I do not know what your data looks like yet, and neither does anyone else who quotes you on that call.

Any vendor who gives you a firm implementation price without first assessing your data, your processes, and your integration needs is pricing based on assumptions, not your actual business. That number is not a price. It is an opening position, and the change orders arrive later.

For context: the manufacturers we work with, generally $12M in revenue and up, implementing core Inventory, Manufacturing, Purchasing, Accounting, Engineering, and Sales, typically land in the upper-five-figure to low-six-figure range for services. Where you land inside that depends on scope, data condition, and integrations. That is what the assessment settles.

We work with discrete manufacturers. Machining and fabrication shops, build-to-print and close-tolerance work, electro-mechanical and PCBA assembly, molding and forming, and contract manufacturers running multi-customer routings and customer-owned inventory. Regulated shops included — AS9100 aerospace and ISO 13485 medical device.

The common thread is deep BOMs, constant engineering change, and traceability you have to prove to somebody. On size, the practice is built for manufacturers from roughly $12M in revenue up.

We are not the right fit for process manufacturing, pure distribution with no production, or retail. There are good firms for those. We are not one of them, and saying so up front saves us both a month.

Fair. Here is the concrete version. You are ready when:

None of that requires software. All of it determines whether software works.

Start with why they are wrong, not with a wall-to-wall count. A count fixes today’s number and changes nothing about tomorrow’s.

In almost every shop we walk into, inaccurate inventory traces back to a small number of process breaks: material moves that never get transacted, scrap that gets thrown away and not reported, issue-to-job happening at the wrong point, receiving that lags the physical dock by days, and BOM quantities that do not match what actually gets consumed.

Find which of those you have, fix the transaction points, then count. Otherwise you will be back to distrust within two months and you will have spent a weekend proving it.

Usually not. It is a data-capture problem that ERP will expose but not solve on its own.

Job cost lands late for three common reasons: labor is not being reported against the job in anything close to real time, material issues are batched and posted at month-end, and your standards are stale so the variance tells you nothing useful anyway.

The uncomfortable part is that if you cannot see cost until after shipment, you are quoting the next job blind, and your margins are being decided by data no one trusts. That is not a reporting inconvenience. That is a pricing problem with a direct line to cash flow.

You can. It is the single most reliable way to fail an implementation, and we will tell you so before you spend the money.

The BOM is the spine. Planning, purchasing, costing, scheduling, and traceability all read from it. Load bad BOMs into a good system and the system will confidently generate wrong demand, wrong purchase orders, and wrong standard costs — at speed, with authority, and with a report attached that makes it look official.

BOM cleanup does not require the new system. It requires deciding who owns revision control and then doing the work. Start it now and it runs in parallel with everything else.

Often, no. This is ERP recovery work and it lives in Advisory, which sells no ERP — so the answer you get is not shaped by what we would rather sell you.

Most underperforming systems we look at are not the wrong software. They were configured against processes nobody had defined, loaded with data nobody had cleaned, and handed to a team nobody had trained past the first two weeks. Ripping it out and buying a different logo reproduces all three conditions at full price.

Recovery starts by separating what the system genuinely cannot do from what it was never set up to do. That distinction is usually worth six figures, and it takes about two weeks to establish.

Because we would start by finding out why the last one failed, and most people never do that.

The failure was almost certainly not technical. In our experience it is one of these: the process was never defined before it was configured, data was migrated dirty because the deadline was fixed, ownership was never assigned so no one maintained it after go-live, or leadership treated it as an IT project and stopped attending after the kickoff.

Adoption is decided before go-live, not after. If those conditions are still in place, the next attempt fails the same way. If they are addressed, it does not.

Size is the wrong test. Complexity is the test.

A shop with deep multi-level BOMs, constant engineering change, serialized traceability, and customer-owned inventory has outgrown spreadsheets well before anyone says so out loud. A larger shop building three configurations to stock may not have.

The real signals are these: the spreadsheet that runs your business has one author, month-end takes longer every quarter, two departments report different numbers for the same thing, and you have started hiring people primarily to move data between systems. When you can name three of those, the question is no longer whether, it is when.

Close is a mirror. It takes three weeks because the data did not get captured correctly during the month, so finance spends the first three weeks of the next month reconstructing what happened.

Look for these: WIP that has to be estimated because job status is not current, inventory adjustments booked at close to force a match, labor allocated by guess, and receipts sitting unmatched against POs. Every one of those is an operations event being fixed in accounting.

You do not shorten close by working harder in finance. You shorten it by fixing the transactions upstream. Shops that do it well close in days, and it is the same accounting staff.

Understand first that the workaround is almost always rational. Every ERP has a shadow system running next to it, and it exists because the official path is slower, harder, or does not reflect how the work is actually done.

People do not resist systems. They resist systems that make their day worse for someone else’s benefit.

So we go find the shadow spreadsheets and ask why they exist. Sometimes the answer is a configuration problem we can fix in an afternoon. Sometimes it is a training gap. Sometimes the workaround is smarter than the designed process and the process should change. Fix the reason and adoption stops being a discipline problem.

The assessment takes very little — a handful of hours across two weeks, mostly conversations and a look at your existing data. It is designed not to disrupt production.

An implementation is different and I will not soften it. You will need real hours from the people who know how the work is done, and those are always your busiest people. Anyone who promises otherwise is setting up the change order.

What we control is the sequence. Cleanup work that does not require your team’s decisions gets done off to the side. Their time gets spent on decisions only they can make. That is the difference between a project that costs your team eight hours a week and one that costs them thirty.

You cannot compare them, because they are not pricing the same work. That is the honest answer.

Ask each vendor these four questions and the spread explains itself:

The cheap quotes usually assume clean data, minimal training, and no integrations. The hidden costs in this industry are consistent: data cleanup, change orders from soft scope, post-go-live support during a hot production month, and training that has to be repeated once people are actually using the system.

Blunt answer: if two departments are looking at different numbers and both believe they are right, that is not a system problem.

Systems enforce decisions. They do not make them. If leadership has not decided what a finished good is, when a job is considered complete, or who owns the item master, no software will decide it for you — it will just record the disagreement in a more expensive format.

This comes up often enough that we do fractional operations work for it, separately from any system project. Sometimes what a shop needs is not an ERP. It is someone senior owning operations for two days a week until the decisions get made and stick.

Short version: a conversation, then an assessment, then a decision you make with real information.

There is no pressure to reach step four. A meaningful share of assessments end at step three, and that is a legitimate result, not a lost sale.