📚 New Blog Posts
1. Why Formula Management Is Critical for Process Manufacturers?
2. How SIPCO Innovations Cut Procurement Planning Time by 50%
3. MPS and MRP in Process Manufacturing ERP: Differences, Planning Process, and Best Practices
Most ERP implementations don’t fail because the software is wrong. They fail because organizations underestimate what the scope of what they’re taking on. A new ERP represents a fundamental shift in how the business operates, and projects that get treated as a routine technology upgrade tend to run into trouble fast.
We sat down with Anuj Saxena, Delivery Manager and Solution Architect at BatchMaster Software with 13 years of hands-on ERP implementation experience, to talk through what separates successful rollouts from costly ones. The patterns he’s seen repeat across industries are worth paying attention to, whether you’re evaluating your first enterprise system or replacing one that’s outgrown in your business.
The insights below carry weight for process manufacturers. Businesses built around formulas, recipes, batch production, lot traceability, shelf life, or regulatory compliance face higher stakes during implementation than most generic software guides account for.
The Four Foundations of a Successful Implementation
Across successful implementations, four characteristics show consistently. The absence of any single one of them puts the entire project at risk.
1. Clear business objectives defined upfront
Before a single configuration decision is made, leadership needs to know what success actually looks like after go-live. “Better visibility” and “fewer spreadsheets” aren’t objectives. Concrete outcomes are reduced batch cycle times, full lot traceability from raw material to shipment, automated regulatory reporting, real-time inventory accuracy. These give the implementation team something to build toward and give leadership something real to measure against.
2. Active executive sponsorship throughout the project
Not just at kickoff. Not just at go-live. The whole way through. When an executive sponsor is visibly engaged, two things happen: decisions get made faster, and teams across departments take the project seriously. The moment executive attention starts to drift, the project drifts with it.
3. Dedicated subject matter experts in every department
Every department that touches the ERP needs to own its piece of the process. That means a named individual responsible for learning the system, cleaning and validating their department’s master data, and training their colleagues for go-live. Without that ownership, the “someone else’s problem” dynamic quietly kills momentum.
4. A process improvement mindset, not a replication mindset
This is the one that trips even seasoned leadership teams. The pull toward replicating what the old system did is powerful because familiar processes feel safe. But an ERP implementation is a chance to rethink how work gets done. Companies that treat it as “move our old processes into a new system” consistently underperform those that treat it as “design better processes and let the system support them”.
The operating environment is shifting from: how leadership engages, how resources get allocated, and how the team makes decisions when obstacles come up.
What Actually Derails Implementations
Implementation failures are rarely a surprise in hindsight. They almost always trace back to four interconnected problems:
1. Unclear requirements during discovery
Ambiguity at the start compounds throughout the project. When the system is being configured around requirements that are still being debated, every downstream decision becomes uncertain. Scope creep follows, timelines stretch, and the frustration builds on both sides.
2. Decisions that don’t get made on time
Requirements only matter if the decisions they generate actually happen. When a configuration choice needs executive sign-off and that sign-off takes weeks, the entire project team is stuck waiting. Slow decisions are one of the most common and least talked-about causes of implementation delay.
3. Departments that don’t feel ownership
When a team feels the ERP is being done “to” them rather than “with” them, engagement drops. Data quality suffers. Training participation falls. Day-one adoption becomes a real risk. Ownership doesn’t happen on its own. It has to be built deliberately from the beginning.
4. Poor data quality and too many customizations
These two tend to show up together. When legacy data is messy, teams often reach customizations to work around the problem instead of fixing it at the source. The result is a system that costs more, takes longer, and is harder to maintain than a cleaner implementation would have been.
One pattern worth calling out specifically:
When the customization list keeps growing through an implementation, that’s often a sign that something is misaligned earlier in the process, not that the software is lacking. More customization is rarely the answer. Going back to the underlying business need and asking whether a standard workflow can address it usually is.
Before You Kick Off: The Groundwork That Determines Everything
The quality of an ERP implementation is largely determined before it officially begins. The prep work is unglamorous but skipping it is exactly what creates the delays and frustrations that organizations later blame on the software.
Appoint a project sponsor with real authority, not a figurehead. The sponsor needs the authority to make decisions, resolve cross-departmental conflicts, and hold teams accountable from discovery through go-live. A sponsor who is too junior, too stretched, or too disconnected from day-to-day operations creates a vacuum that no implementation team can fill from the outside.
Identify departmental SMEs before kickoff, not after. These individuals need to be named, briefed on their responsibilities, and given protected time to do the work. Their job is straightforward but demanding: learn the system well enough to represent their department’s needs, ensure their area’s master data is accurate and complete, and prepare their colleagues for the transition.
Document your current processes, but not to copy them. Process documentation has one purpose here: to start a conversation. What is the business doing today, and how does the new system’s standard workflow handle the same need? That conversation often reveals that the legacy process was a workaround built around an old system’s limitations. There’s no reason to carry it forward.
Why Executive Involvement Is Not Optional
Executive involvement in an ERP project isn’t a formality or a courtesy. It’s a structural requirement for the project to actually work.
When senior leaders are genuinely engaged, three things happen. Roadblocks get cleared faster because decisions that would otherwise sit in a queue for weeks get resolved quickly. SME accountability goes up because people behave differently when they know leadership is paying attention. And cross-departmental alignment holds because there’s someone at the top who can step in when departments start pulling in different directions.
When that engagement fades after the kickoff meeting, which happens more often than most teams admit, the project loses its center. Decisions slow down. Accountability softens. Departments start optimizing their own comfort rather than the shared outcome.
Where Manufacturers Get the Balance Wrong
ERP budgets and attention consistently flow toward the wrong places. The work that actually determines day-one success gets underfunded, while effort piles up on things that add cost without adding much value.
Where manufacturers under-invest:
1. Cleaning legacy master data
Dirty data going in means dirty data coming out. No configuration decision compensates for inaccurate formulas, wrong unit-of-measure mappings, or incomplete item records. Data cleanup is slow, unglamorous work that doesn’t feel like progress, but it’s progress nonetheless. It’s probably the most important technical task in the entire project.
2. User training
Users who understand the system adopt it. Users who don’t, find workarounds, and workarounds inside an ERP create problems that compound over time. Yet training is almost always the first thing cut when a project runs behind schedule, meaning it gets deprioritized at exactly the moment it matters most.
3. Change management
The human side of an ERP rollout is consistently underestimated. People have spent years doing things a certain way. A new system asks them to let that go. Without deliberate change management, clear communication, early involvement of skeptics, and visible commitment from leadership, resistance builds quietly until it surfaces as low adoption after go-live.
4. Internal resource commitment
ERP implementations need dedicated time from key people inside the business. When those people are expected to carry their full operational workload, quality or timelines suffer. Companies that carve out protected implementation time for their key people consistently get better outcomes.
Where manufacturers over-invest:
1. Over-customization
A growing customization list is rarely a software problem. More often, it signals that teams are trying to recreate their old system inside the new one, whether that’s replicating Excel workflows or rebuilding legacy logic. That instinct is understandable, but every customization adds cost, extends timelines, and complicates future upgrades. The right question to ask is simple: can a standard workflow handle this need? In most cases, it can.
2. Over-documentation
A clear, concise SOP is enough for most process documentation needs. When teams spend weeks creating exhaustive documentation for every edge case and sub process, they’re using up time and attention that would do far more good spent on data quality, testing, and training.
Process Manufacturing Implementation Works Differently from Discrete Manufacturing
This distinction doesn’t get enough attention, and conflating the two is one of the more common sources of scope confusion early in an implementation.
Discrete manufacturing is built around bills of materials, routings, work orders, and assemblies. The logic is additive: parts come together to make a finished product.
Process manufacturing works differently. The core operational elements are formulas and recipes, batch production, end-to-end lot traceability, quality checks at multiple stages, shelf life management, and regulatory compliance. Variables don’t snap fixed quantities; they scale, adjust, and vary across batches. A single formula change can ripple into cost, labeling, and compliance implications that a discrete-focused system simply wasn’t built to manage.
For food and beverage manufacturers, nutraceutical producers, personal care companies, and specialty chemical operations, this isn’t a theoretical concern. It’s the daily reality of running the business. An ERP built specifically for process manufacturing handles these needs as standard functionality: formula and recipe management, batch production scheduling, lot traceability from incoming raw materials through finished goods shipment, quality management embedded in the production workflow, shelf life and expiry tracking, and the compliance documentation that regulatory bodies and retail customers require.
Trying to make a generic ERP fit these requirements through configuration and customization is possible, technically. But it’s expensive, time-consuming, and produces a system that will need significant support every time the business changes or the software needs an upgrade.
What Separates Successful Transformations from Disasters
Organizations that get ERP right aren’t always the most technically sophisticated or the best funded. What they share is a willingness to treat the project as a business transformation, bring the right people in from the start, do the unglamorous work that determines adoption, and resist the urge to use a new system to recreate what the old one did.
For process manufacturers specifically, that also means choosing a platform built for the way operations actually work. Formulation, batch production, lot traceability, quality management, and compliance aren’t add-ons or edge cases. They’re the core of the business, and the ERP should reflect that.
The software matters. But it’s not the deciding factor. The difference between a successful implementation and an expensive lesson is almost always found in the decisions made long before the first configuration screen opens.