Process Engineering: A Process-First, System-Second Approach

Most companies start their digitalization journey by purchasing software: “Let’s install an ERP, and then adapt our processes to it.” This approach often results in half-finished projects, unused modules, and stories of “returning to the old ways.”

Process engineering offers the opposite path: first, map your processes, identify bottlenecks, design the target state, and then select the technology that fits that design. In this guide, we will explore the practice of process engineering with BPMN mapping, As-Is/To-Be analysis, swimlane techniques, bottleneck identification, and real-world scenarios.

What is Process Engineering?

Process engineering visualizes and optimizes all business workflows

Process engineering is the systematic analysis, design, implementation, and continuous improvement of business processes. Its primary goal is to visualize all steps from input to output, eliminate unnecessary activities, resolve bottlenecks, and optimize the value chain.

A classic definition: it is the systematic search for answers to the questions, “Who, when, where, according to which rules, with which data, produces which output?” These answers are materialized in flowcharts, role matrices, decision trees, and documentation.

Process Engineering vs. Process Management

Process engineering is more analytical and design-oriented; it questions the current state from scratch. Process management deals with operational monitoring, KPI tracking, and routine improvements. The former seeks to answer “how should it be,” while the latter answers “how is it going.”

Why is Process Engineering Important?

• Visibility: Nobody knows the entire process end-to-end; everyone sees only their own part.
• Standardization: Every employee performs the same task using a different method.
• Measurability: Time, cost, and error rates are not recorded.
• Automation Infrastructure: Manual processes are not ready for digitalization.

Process First, System Second Philosophy

The process architecture must be clarified before technology selection

The most common digitalization mistake is this: a company first buys software and then adapts its processes to the software. This approach is high-risk because software constraints force the company’s business model. For example, the ERP’s order approval workflow might have 3 stages, but your company requires 5 stages. You either change your process or develop custom extensions for the software.

What Does “Process First, System Second” Mean?

The correct approach is as follows:

1. Map Current Processes (As-Is): Document every process step, role, decision, and data.
2. Design the Target State (To-Be): Remove unnecessary steps, resolve bottlenecks, standardize.
3. Extract Technology Requirements: What is needed to automate the To-Be process?
4. Select or Develop Software: Choose the technology that meets the process needs.

This approach ensures the software fits your company, not the other way around.

Which Processes are Priority?

Instead of mapping all processes at once, start with the critical ones:

• Order management from order receipt to shipment
• Production process from raw material input to finished goods output
• Financial cycle from invoicing to collection
• Supply chain from supplier selection to quality control

BPMN and Swimlane Mapping Techniques

BPMN notation visualizes business processes with standard symbols

What is BPMN (Business Process Model and Notation)?

BPMN is the universal standard for graphically modeling business processes. All tools, from Visio to Bizagi, Signavio to Camunda, support BPMN. Basic symbols include:

• Event: Circle — process start, end, or intermediate event (e.g., “order received”)
• Activity (Task): Rectangle — a work step (e.g., “calculate price,” “await approval”)
• Gateway: Diamond shape — decision point, parallel path, merge
• Sequence Flow: Arrow — sequence between steps
• Message Flow: Dashed arrow — communication between departments or systems

Swimlane (Lane) Diagrams

Swimlanes separate process steps by roles or departments. Each role occupies its own lane. For example:

[Sales]        → Receive Order → Prepare Quote
[Finance]                    → Credit Approval
[Planning]                               → Plan Production
[Production]                                              → Produce
[Logistics]                                                  → Ship
            

This representation clarifies the question, “Who is responsible for which step?” If there’s a delay at a step, it immediately becomes clear which role is causing the bottleneck.

BPMN Tools

• Microsoft Visio: Most common, easy to use, integrates with Office ecosystem.
• Bizagi Modeler: Free, powerful simulation features.
• Draw.io (diagrams.net): Free, web-based.
• Lucidchart: Cloud-based, collaboration-focused.
• Camunda / Signavio: Enterprise-grade, integrates with BPM platforms.

As-Is / To-Be Analysis: Current and Target State

As-Is analysis defines the current reality, To-Be analysis defines the target state

As-Is Analysis: Mapping the Current State

As-Is analysis is a complete snapshot of a company’s processes today. The goal: to answer the question, “How is it really done?” Often, there is a significant difference between the official procedure and the actual practice.

As-Is Mapping Steps:

1. On-Site Observation: Observe processes live in the office or on the shop floor.
2. Interviews: Talk to process owners, operators, and managers.
3. Data Collection: Gather existing forms, Excel files, email chains, system logs.
4. Flowcharting: Draw each step, decision, delay, and handoff using BPMN.
5. Pain Points: Identify bottlenecks, unnecessary steps, error points, data deficiencies.

As-Is Deliverables:

• BPMN flow diagrams (swimlane)
• Process analysis: time taken for each step (minutes/hours)
• Role-responsibility matrix (RACI)
• Data flow map: which system holds which data
• List of pain points

To-Be Analysis: Designing the Target State

To-Be analysis is the optimized process design that resolves the pain points identified in the As-Is state. The goal: to answer the question, “How should it be?”

To-Be Design Principles:

• Elimination: Remove unnecessary steps (e.g., is 1 approval sufficient instead of 3?).
• Combination: Merge similar activities (e.g., 1 screen instead of 2 separate forms).
• Parallelization: Make sequential steps parallel (credit check simultaneously with order entry).
• Automation: Integration instead of manual data entry (ERP ← email order).
• Standardization: Same process steps across different regions.

To-Be Deliverables:

• Optimized BPMN flow diagrams
• Target cycle time: overall loop time objective
• Automation requirements: which steps will be digitalized
• Integration map: which systems will communicate
• Training and change management plan

As-Is vs. To-Be Difference Table

Bottleneck Identification and Process Optimization

Bottlenecks are the slowest links in a process and slow down the entire flow

What is a Bottleneck?

A bottleneck is the slowest or lowest-capacity step in a process. The entire process progresses at the speed of this step. For example, if a quality control station on a production line can only inspect 100 units per day, even if production makes 200 units and shipping can handle 500 units, the output is still limited to 100 units per day.

Bottleneck Identification Methods

1. Cycle Time Analysis

Measure the completion time for each step. The step taking the longest is a potential bottleneck.

2. Queue Analysis

Which step has a backlog of work in front of it? For instance, if there are 40 orders waiting for approval, the approval step is the bottleneck.

3. Resource Utilization

Which role or equipment is operating at 100% capacity? For example, if a CNC operator is never idle, the CNC machine is the bottleneck.

4. Throughput Analysis

Compare the process input and output. If the input is 200 and the output is 80, there is a bottleneck in between.

Bottleneck Resolution Strategies

• Capacity Increase: Add resources to the bottleneck (a second approver, a second CNC machine).
• Prioritization: Ensure critical tasks pass through the bottleneck first (urgent orders get priority).
• Parallel Processing: Split the bottleneck into parallel streams (two parallel approval flows).
• Automation: Digitize a manual bottleneck (automated approval rules).
• Elimination: Remove the bottleneck step entirely if it’s unnecessary.

Real-World Bottleneck Example

Situation: A metal processing workshop receives 50 work orders daily but completes only 18. The bottleneck is quality control. A single technician inspects all work, with an average inspection time of 40 minutes.

Solution:

1. A second quality control technician was hired.
2. A faster method for routine checks was developed (reducing time to 10 minutes).
3. An automated measurement device was acquired (reducing time to 5 minutes).

Result: Daily completed work orders increased from 18 to 42.

Process Engineering Implementation Steps

A process engineering project is typically implemented in 6 phases:

Step 1: Scope Definition (1 week)

Which processes will be analyzed? Which departments are involved? What are the project objectives? Example scope: “All processes from order receipt to shipment, within 3 months, with a 50% time reduction target.”

Step 2: As-Is Mapping (2–3 weeks)

On-site observation, interviews, data collection, BPMN flowcharting, bottleneck identification. Deliverable: As-Is report and BPMN diagrams.

Step 3: Analysis and Opportunity Identification (1 week)

Evaluate As-Is findings. Which steps are unnecessary, which are bottlenecks, which generate errors? Create a list of opportunities.

Step 4: To-Be Design (2 weeks)

Optimized process architecture, BPMN diagrams, integration requirements, role definitions. Deliverable: To-Be report and transition plan.

Step 5: Pilot Implementation (4–6 weeks)

Test the To-Be process with a single branch, team, or product group. Gather feedback, correct errors.

Step 6: Rollout and Continuous Improvement (3–12 months)

If the pilot is successful, roll it out across the organization. Monitor KPIs, regularly review process performance.

Real-World Example: Metal Processing Workshop

7 Common Process Engineering Mistakes

1. Designing the To-Be State Without Understanding the Current State

The approach: “We already know how it works, let’s design the target state immediately.” Result: Actual pain points are overlooked, and the design remains theoretical.

2. Not Listening to the Field

The process engineer draws BPMN in the office without listening to field employees. The actual process differs from the documented one; consider what they say in the field like, “We do it this way because otherwise it doesn’t work.”

3. Trying to Change Everything at Once

The To-Be design is perfect but involves changing 100 steps simultaneously. The organization cannot handle it, leading to chaos. Implement changes incrementally: first, resolve critical bottlenecks.

4. Overcomplicating BPMN to an Academic Level

Including every notational detail, drawing a 50-page flowchart. Most stakeholders cannot understand this complexity. BPMN should be simple and clear.

5. Not Defining Process Owners

The To-Be state is designed, but the question, “Who is the end-to-end owner of this process?” remains unanswered. If a process is left without an owner, it will revert to its old ways over time.

6. Not Measuring

Is there a difference between As-Is and To-Be? Has the time truly decreased? Without KPI tracking, success is merely a feeling.

7. Forgetting Change Management

The mindset: “This is the new process, everyone must comply.” People find it difficult to change their habits. Training, communication, and motivation are necessary.

Identifying mistakes in advance increases the success of process engineering

Process Maturity Metrics

Key metrics to measure process engineering success:

Process Maturity Levels (5 Stages)

• Level 1 (Initial): Processes are ad-hoc, undocumented; everyone works their own way.
• Level 2 (Managed): Processes are defined, repeatable, but not standardized.
• Level 3 (Defined): Processes are documented, standardized, roles are clear.
• Level 4 (Measured): KPIs are tracked, performance is monitored.
• Level 5 (Optimizing): A culture of continuous improvement, data-driven optimization.

Process Engineering Checklist

Frequently Asked Questions (FAQ)