The scanning decision that wasn't really about scanning

We sat in on a call with a client recently where finance and the production floor were both asking for exactly the same thing: better warehouse scanning. They just wanted two completely different versions of it.

Finance wanted the standard solution. Fast to deploy, proven, done. The production floor wanted something built specifically around how their line actually runs, with the exceptions their process throws up every day. Both requests were reasonable. Neither side was wrong. This is exactly the kind of SYSPRO customisation decision most manufacturers wrestle with, not because either choice is bad, but because this is not one decision, it's actually two.

Two reasonable requests aren't a disagreement

It would have been easy to read this as finance being cost-conscious and the shop floor being demanding. That's not what was happening. Finance was asking the right question for the parts of the business that look like everyone else's: does this need to be built from scratch, or is there already a proven answer? The production floor was asking the right question for the part of their operation that doesn't look like anyone else's: does the proven answer actually fit how we work?

Both questions deserve a real answer. The honest one is that they weren't competing for the same decision. They were describing two different jobs.

Where SYSPRO customisation actually happens

We implement standard SYSPRO modules as often as we build bespoke solutions, and which one fits best differs case by case. Getting it right matters, because the wrong call either costs more than it needed to, or leaves a gap in your process that never actually closes.

Standard SYSPRO scanning, in this case riteSCAN, is a proven, plug-and-play warehouse management tool built for SYSPRO that our team implements for clients who need reliable scanning without reinventing it. It covers receiving, picking, moving and shipping the way most warehouses need it covered, maintained and improved by a vendor whose only job is that one product. We implement riteSCAN as often as we build bespoke Tempo solutions, and we're just as capable on this side of the decision as the other. That matters here: our recommendation isn't shaped by which route pays us more, it's shaped by which route actually serves the client's process. Where riteSCAN genuinely fits, that's what we'll say. It's the kind of quick win we've written about before for manufacturers starting their digitisation journey.

The tailored route runs through our Tempo family. For this client, the likely direction is a Tempo customisation module, built specifically around how their line runs. Neither route touches SYSPRO's core: the financial records, the transactional integrity, the guardrails that need to stay standard for every customer. That's worth naming clearly, because the risk most manufacturers worry about with customisation, the upgrade pain and maintenance burden that comes from altering the system of record, was never actually on the table here. riteSCAN and a bespoke Tempo build both sit in the layer around SYSPRO, connected to it, never inside it.

Key takeaway: the decision in front of this client was never "customise SYSPRO or don't." Both routes already respect the one boundary that actually matters: keep the ERP core standard, build around it. The real decision is standard or tailored within that safe space, and it deserves the same care either way.

What's tipping it toward tailored, this time

The production floor's case looks like the stronger one so far, and it comes down to something we've seen play out often enough to trust: every time a process throws up an exception the standard tool doesn't handle, the instinct is to bolt on another small app to cover it. One exception, one workaround. It feels cheap in the moment because each individual fix is small.

It doesn't stay small. SYSPRO's own research describes manufacturers typically running five to ten systems stitched together through exactly this kind of one-off, point-to-point integration, and estimates that the accumulated technical debt from that pattern adds roughly 10 to 20 percent on top of every project that follows.¹ That's not a scanning-specific number, but it names precisely the pattern we've been watching form, here and in similar conversations with other clients right now: not one bad decision, but a slow accumulation of small ones.

Key takeaway: a standard tool that covers most of your process well isn't something to walk away from lightly, and a real remaining gap isn't something to ignore either. Every exception the standard tool doesn't handle is a decision: absorb it as a manual workaround, bolt on a quick fix, or move to a tailored build shaped around the process. That's a genuine trade-off between upfront cost and the competitive edge a better-fitting process delivers, and it's worth weighing carefully rather than defaulting either way.

A tailored build shaped around the actual process, from the start, avoids that accumulation. It costs more upfront than accepting the standard tool's gap. It costs less than the version of the future where several small workaround apps are each fighting the next upgrade. That's the trade worth thinking through properly: more cost now for a process-shaped fit, or a lower-cost standard tool with a gap you manage by hand.

The cost that's easy to miss

None of this makes tailored the automatic right answer, and we'd be doing this client a disservice if we framed it that way. riteSCAN's real advantage isn't only that it's faster to deploy. It's maintained by a team whose whole business is that one product, tested against every new SYSPRO release before it reaches customers, improved for every business running it, not just one.

Build something bespoke, even built the right way, in the layer around SYSPRO rather than inside it, and that maintenance now sits with us and the client, not spread across a vendor's whole customer base. That's a real, ongoing cost, and it's the honest trade the production floor's team is weighing: more control over exactly how the tool matches their process, in exchange for owning its upkeep going forward. We won't recommend that trade if riteSCAN genuinely covers what a client needs. The only way our advice is worth trusting is if it's sized to the client's actual value, not to which route costs more.

"The standard tool is maintained by a vendor whose only job is that product. Build bespoke, and that job is now yours."

What this means for your operation

The question worth asking isn't whether to customise your scanning, or anyone else's process. It's narrower and more useful: for this specific process, is the gap between the standard tool and how you actually work small enough to live with, or big enough that it'll keep generating workaround apps for years?

Finance's instinct to reach for the standard answer first is the right default for most of what a warehouse does. The production floor's instinct to push back on it for their specific process is also worth taking seriously, because they're the ones who can see the exceptions accumulating. Neither team needs to be talked out of their position. The question just needs reframing, so both answers can be true at once, for different parts of the same operation.

Before you reach for a standard tool or a bespoke build, ask:

• Does this process look like everyone else's, or has your team learned to do it differently for a real reason?
• If you accept the standard tool's gap, what's the smallest workaround app someone will build to cover it, and how many of those can you tolerate?
• If instead a tailored build is on the table, is the extra cost worth what you get in process fit, or would a standard tool with a manageable gap serve you just as well?
• Whichever route you choose, does it stay in the layer around SYSPRO, or does it touch the core?

The next step

In reality this is a broader decision than just scanning software. Like most SYSPRO customisation calls, it is a decision about which parts of one client's operation look like everyone else's warehouse, and which parts don't. Once that is clear, both answers, standard for one part, tailored for another, can be right at once, for different parts of the same operation. Each individual call is still binary: for that specific process, is it riteSCAN or is it tailored.

That's exactly the kind of call we help clients make: not defaulting to standard because it's simpler for us, and not defaulting to custom because it's worth more to us, but weighing each case on what it's actually worth to you.

If you're weighing a similar call on your own shop floor, the question to start with isn't just which tool to buy. It's whether the gap you're looking at is one your team can live with, or one that's already generating its own workaround apps.

References

1. SYSPRO (2026). "The Hidden Cost of Integration Sprawl in Manufacturing," citing McKinsey's 2025 research on enterprise technology economics. syspro.com/blog/the-hidden-cost-of-integration-sprawl-in-manufacturing