There's an old coaching adage: practice makes permanent, not perfect. Repeat a motion enough times, good
or bad, and it stops feeling like a choice and starts feeling like the only way to do it. Business
processes work the same way. Run a broken process long enough and nobody questions it anymore, they just
get faster at running it wrong. That's what business process engineering is designed to interrupt, before
an ERP system locks that same process in for good.
Business process engineering is the work of mapping how your business actually operates today, evaluating
which of those processes genuinely add value and which just create waste, and redesigning the future
state before any new system gets built or configured around it. Implementing ERP on top of processes no
one has examined doesn't fix inefficiency, it just automates it and makes it more expensive to unwind
later. Reviewing the process first means the new system supports how work should get done, not just how
it happens to get done today.
60 Seconds on Business Process Engineering
Business process engineering is the discipline of mapping your current processes, evaluating which ones
add real value versus which create waste, and redesigning the future state before new technology gets
implemented around it. Done before an ERP project, it makes sure the system is built around a
streamlined process rather than an inherited one.
Featured: Elliot Lowe
at Business Consulting Leader.
Business Process Engineering vs. Implementing Without It
Implementing Without Process Review
The new system gets configured around old, unexamined processes
Existing inefficiencies and waste carry straight over into the new environment
No one can say which processes actually add value versus which are just habit
Technology gets selected before the workflows it needs to support are understood
The end result is you've got a shiny new environment, with the same baggage you had before
Business Process Engineering First
Current processes are fully mapped before any configuration begins
The future state weighs the effect on people, value-add, and waste directly
Technology features get matched to processes that are actually worth keeping
Implementation is built around a streamlined process, not an inherited one
The 6-Step Business Process Engineering Process
Before any process gets touched, we define what the business actually needs to achieve, so every
later decision has a clear target.
An honest, complete picture of how work actually happens today, not the version everyone assumes
is happening.
The redesigned process gets built with its effect on people, value-add, and waste weighed
directly, not as an afterthought.
Once the future-state process is defined, we identify exactly which technology features actually
support it, rather than picking features first and fitting the process around them.
Where the current state falls short of the future state gets named specifically, with a plan
attached to close it, the same discipline behind our
gap analysis work.
Everything above gets sequenced into a concrete rollout plan, so the redesigned process moves into
the new system deliberately, not all at once.
Signs You Need This Before ERP
1
You're about to implement or upgrade ERP without reviewing your existing workflows first
2
Manual workarounds and duplicate work are common, but there hasn't been an honest attempt to get to the root cause of those inconveniences
3
No one can say which current processes actually add value versus which are just habitual, "it's just the way we do things" can sometimes be a hindrance, not a help
4
A past implementation ended up automating the same inefficient process you already had, practice made it permanent, not better
5
Different departments handle the "same" process differently, with no shared standard
It's the discipline of mapping your current business processes, evaluating which ones add real
value versus which create waste, and redesigning the future state before new technology gets
implemented around it.
They overlap, but business process engineering focuses specifically on evaluating and redesigning
how work actually gets done, weighing its effect on people, value-add, and waste. Solution design
is the broader planning exercise that also covers risk, integrations, and phasing.
Implementing new technology on top of unexamined, inefficient processes just automates the
inefficiency. Reviewing and redesigning the process first makes sure the new system supports how
work should be done, not just how it happens to be done today.
It depends on how many processes and departments are in scope. The clearest answer for your
business comes from a discovery conversation with our team rather than a generic estimate.
Stakeholders from every department whose workflows are in scope, working alongside our team through
the same collaborative discovery approach we use in solution design.
Redesign the Process. Then Implement.
Map what's actually adding value before you build a new system around what isn't.
Elliot is an Acumatica consultant whose path to ERP ran through biomedical research, including work at the National Institutes of Health. That scientific rigor shapes how he approaches problem-solving for clients. Outside work he writes and records music and enjoys the beach and frisbee golf.
