Process Design Before Software Implementation
By Gabriel Baird
Process Design Before Software Implementation
Automating broken processes is a common, costly mistake.
A company identifies inefficiency, buys a large enterprise platform (ERP, CRM, EPM, or project management software) and expects the technology to solve the problem.
Months later the implementation is delayed, costs have doubled, and employees complain that the system is harder to use than the spreadsheets it replaced.
Software often gets blamed, but it’s rarely the root cauase.
The real problem is that the organization attempted to automate chaos.
The Hidden Rule of Enterprise Systems
Successful companies follow one of two paths when implementing major systems:
Path 1 — Design the Process, Then Build Software for It
or
Path 2 — Adopt the Process Embedded in Enterprise Software
Both approaches work.
The one that fails is the third path that many organizations unintentionally choose:
Customize enterprise software to reproduce a broken internal workflow.
This is the fastest way to turn a technology project into a multi-year operational problem.
The Concept of “Process Automation of Chaos”
Enterprise software does not fix unclear ownership, inconsistent data, or poorly defined workflows.
It simply executes those problems faster and at scale.
Consider a project approval process where:
- project ownership is unclear
- required inputs vary by department
- definitions of budget vs forecast differ
- approvals occur informally through email
When software is introduced without fixing these issues, the system becomes a digital version of the same disorder.
Instead of spreadsheets and emails, the organization now has:
- incomplete system records
- conflicting workflows
- inconsistent data definitions
- manual overrides and side spreadsheets
The chaos has not disappeared.
It has been formalized into the system architecture.
Why ERP and CRM Implementations Fail
This pattern explains why so many enterprise software implementations struggle.
Executives often assume the project is a technology problem.
In reality it is an operating model problem.
Enterprise applications embed structured assumptions about how organizations should function:
- defined entities and data objects
- consistent relationships between records
- standardized workflows
- clear ownership of data and approvals
When an organization has not defined its own process, the implementation team faces an impossible task:
They must configure the system while simultaneously discovering how the business actually operates.
The result is predictable:
- endless workshops to define requirements
- extensive customization
- unclear system ownership
- escalating implementation costs
By the time the project finishes, the company has effectively built a custom system on top of a standard platform—losing most of the advantages of the enterprise software.
Process Clarity Must Come First
The real prerequisite to system implementation is process design.
Before selecting software, leadership should be able to answer several basic questions:
Process Ownership
- Who owns the process?
- Who is responsible for maintaining it?
Inputs and Outputs
- What information is required?
- What outputs must the process produce?
Decision Points
- What approvals are required?
- Who makes those decisions?
Data Definitions
- What does each metric mean?
- Where is the source of truth?
These questions sound simple, but many organizations cannot answer them consistently.
When they cannot, the software implementation becomes an expensive process discovery exercise.
When to Build Software
Designing the process first does not always mean buying software.
In some cases, building software around a custom process is the right decision.
This approach works best when:
- the process is core to competitive advantage
- the workflow is unique to the business
- existing enterprise tools cannot support it well
- the company has technical capacity to maintain custom systems
When to Adopt Enterprise Software
In most cases, however, companies benefit from adopting the operating model embedded in enterprise applications.
ERP, CRM, and similar platforms represent decades of accumulated process design.
They include:
- predefined data structures
- standardized entity relationships
- built-in governance controls
- well-tested workflows
Organizations that succeed with these platforms typically do something counterintuitive:
They change their internal process to match the software.
This often requires organizational discipline and leadership support, but it dramatically reduces complexity and implementation risk.
The Customization Trap
The most dangerous implementation strategy is heavy customization.
It often begins with reasonable requests:
- “Our approval process is slightly different.”
- “Our reporting structure is unique.”
- “Our teams need a different workflow.”
Individually, these requests appear harmless.
Collectively, they transform a standardized platform into a fragile custom system.
The Insight
For senior leaders, the key realization is this:
Software projects are not technology initiatives.
They are organizational design initiatives.
Before any system is selected, leadership must ensure that the underlying operating model is clear:
- who owns processes
- how decisions are made
- how information flows
- how accountability works
If those fundamentals are not defined, the software will simply encode the confusion.
A Simple Rule for Leaders
A useful rule for executives considering enterprise software is this:
First design the process.
Then choose one of two paths:
- Build software to support the process.
- Adopt the process embedded in the software.
What organizations should never attempt is the third option:
Using software to preserve broken processes.
That approach does not modernize the business.
It simply automates dysfunction.