BPM in engineering: process thinking meets technical complexity

Engineering teams are trained to optimize systems, reduce inefficiencies, and rely on data to guide decisions. Yet, many organizations still run their most critical workflows on informal habits, scattered knowledge, and undocumented processes.

This gap becomes more visible as engineering environments grow more complex. Multiple teams, tools, and disciplines must work together, but without a shared process structure, coordination often depends on experience rather than clarity.

Marco Turchetto, Product Manager of VOLTA at ESTECO, has spent years at the crossroads of engineering simulation and Business Process Management (BPM). In a recent conversation, he shared how BPM and BPMN 2.0 (Business Process Model and Notation) help engineering organizations move from implicit workflows to structured, data-driven processes.

Rather than acting as documentation overhead, process modeling becomes a way to manage complexity, improve collaboration, and build a foundation for continuous improvement.

Why BPM matters in engineering beyond documentation

Why engineering processes remain undocumented

Engineering teams are trained to keep systems under control. However, this becomes increasingly difficult as processes extend across multiple people and departments.

Q: Engineers are trained to optimize systems. How do you see BPM fitting into the engineering mindset? Is it just documentation, or something more structural?

This is where many engineering organizations start to lose visibility. The process exists, but it is spread across teams, tools, and individual experience.

For Marco, BPM starts as documentation — but that framing undersells it. Writing down a process gives engineering teams a full picture of every interaction, every dependency, and every data handoff between people and departments. For engineers, that visibility is not a luxury. It is a precondition for control.

The real value, however, emerges when that process becomes a shared and analyzable model.

Managing multidisciplinary workflows without oversimplifying them

Engineering processes are inherently complex. They involve multiple disciplines working in parallel, with precise coordination points and data exchanges.

Q: In engineering environments like those around VOLTA, complexity is a given. How can BPM help manage multidisciplinary workflows without oversimplifying them?

Engineering processes — especially in simulation-driven organizations — routinely involve specialists from structural analysis, CFD, electronics, software, and systems engineering, all working in parallel and exchanging outputs at precisely defined handoff points.

The challenge is not to simplify this complexity, but to make it understandable and manageable.

This is exactly where BPMN (Business Process Model and Notation) earns its place. BPMN 2.0 is a standardized graphical notation designed to represent complex processes with precision — including parallel tracks, conditional branches, and cross-team interactions — without flattening the nuance that engineering teams depend on.

Marco's go-to example is multidisciplinary simulation:

"When you have different teams who are experts in different disciplines and they need to interact with each other, BPMN helps you put clarity into the process. It lets you understand how to manage the complexity — not remove it."

Instead of reducing complexity, BPMN creates a shared structure that helps teams navigate it.

What BPM enables in a multidisciplinary engineering workflow:

• A clear, shared view of who does what, when, and with which data
• Explicit modeling of data flows between teams and systems
• A notation (BPMN 2.0) precise enough for engineers and readable enough for managers
• The ability to include simulation service tasks directly inside the business workflow model.

The hidden risk of undocumented engineering processes

In many engineering organizations, processes are not missing. They are simply invisible. Teams follow them every day, yet they are rarely documented, shared, or standardized.

Q: From your experience, what is the biggest difference between process thinking in engineering and in traditional business departments?

"When you have to design a component, you will always know where the CAE model is coming from, what kind of simulation you need to do, and who is receiving the output. Everyone on the team knows this — but nobody has ever written it down. The process exists only in people's heads."

This highlights a gap that many organizations don’t immediately recognize. Engineering companies almost always have internal processes — but they are unofficial, uncodified, and lived rather than written.

As long as teams remain stable, this way of working can seem efficient. However, it quickly becomes a limitation when new people join or when processes need to scale across teams.

Process thinking, then, means translating that institutional knowledge into a codified BPMN process — one that can be shared, audited, improved, and followed by people who were not present when the informal rules were first established.

In practice, this shift brings a few immediate benefits:

• Consistency — the process does not depend on individual memory
• Faster onboarding — new team members understand how work is done more quickly
• Transparency — everyone can see how tasks and data connect
• Continuous improvement — processes can be analyzed and refined over time.

In traditional business departments, process documentation is often already expected as a matter of compliance or quality management. In engineering, it is a cultural shift — and a significant one.

From process visibility to optimization in engineering

Engineering organizations don’t improve processes all at once. They move through a progression—from making processes visible, to understanding them through data, and finally to optimizing them through simulation.

The following sections break down this progression.

Business transformation in engineering: what it actually means on the ground

“Transformation” in engineering often sounds abstract. However, in practice, it comes down to something very concrete: making processes visible, structured, and measurable.

Q: When we talk about business transformation in engineering, what does that actually mean on the ground?

"The biggest transformation is having the process codified and written down so you can monitor it and actually see where the process is in its execution. The value I see most among our customers is not just the idea of process modeling — it is the clarity and governance that a well-modeled process brings to the organization."

In other words, transformation is not about introducing new tools alone. It is about turning informal workflows into governed, trackable systems.

A codified BPMN process transforms engineering operations across several concrete dimensions:

• Repeatability — the same process runs the same way every time, regardless of who is managing it
• Traceability — every task, every data input, every output is recorded and attributable
• Accountability — it is always clear who is responsible for what, and when
• Governance — the process is no longer dependent on individual memory or informal managerial oversight

This shift allows organizations to move from reactive coordination to controlled execution.

Why data drives change in engineering organizations

Q: Engineers trust data. How can process modeling and simulation help make change management more evidence-based and less opinion-driven?

This distinction is important. In engineering environments, decisions are rarely accepted without evidence. However, many process-related decisions are still based on assumptions rather than measurable insights.

Change management often stalls not because people resist change in principle, but because proposed improvements lack a clear data foundation.

This is where BPM creates a shift. Once a process is modeled and executed, it becomes a source of measurable data. In engineering, this goes beyond tracking task durations or bottlenecks. The data managed by the process carries the value associated with the process itself — including the engineering simulation outputs generated at each step. A simulation result, a design parameter, a validated model output: all of these flow through the process, are captured by it, and become part of a growing, structured knowledge. This is what makes BPM in engineering uniquely powerful — the process doesn't just orchestrate work, it becomes the container for the technical knowledge the organization produces.

Instead of debating opinions, teams can focus on observable facts:

• Where are the delays? The process model surfaces it.
• Which step is the bottleneck? The structured mapping reveals it.
• Would parallelizing two tasks reduce lead time? Model it, simulate it, and the data will show it.

This moves process improvement from discussion to validation.

Would you run your own life on a BPMN workflow?

We asked Marco off-script: as an engineer, would you organize parts of your own life with a BPMN workflow? His answer was immediate:

It sounds like a joke — but it is not. For engineers who internalize process thinking, this is simply how the world works.

Test before you transform: applying simulation thinking to processes

Q: How can simulation-based thinking — so familiar in engineering — be applied to business processes to test scenarios before implementing change?

"The only way to know if a process modification works is to run it — which disrupts how people are used to working. But if you had a simulation of the business process, you could modify it and test whether your changes are likely to work in the real environment before actually implementing them."

Engineers already rely on simulation when designing products. They test, validate, and compare scenarios before making decisions. Applying the same logic to business processes creates a powerful advantage.

Instead of changing a live process and hoping for the best, teams can evaluate improvements in advance.
The difference between a traditional approach and a simulation-based one is clear:

• Decision basis — traditional process changes rely on experience and intuition; simulation-based management uses data and scenario testing
• Risk level — traditional changes are high risk, as they affect live workflows before their impact is known; simulation keeps risk low by testing changes before implementation
• Speed of iteration — traditional methods are slow; simulation allows multiple scenarios to be tested rapidly
• Confidence — traditional approaches leave teams with limited certainty; simulation delivers what engineers trust most: evidence-based conclusions

This approach turns process improvement into a controlled, repeatable cycle. Teams can test ideas, compare outcomes, and implement only what proves effective.

Coordinating complex engineering processes across teams and decisions

Engineering processes rarely stay within a single team. They span multiple disciplines, external partners, and decision layers. This creates challenges not only in execution, but also in alignment and governance.

The following sections explore how BPM helps organizations coordinate work, support decision-making, and maintain control without adding complexity.

BPM across teams and stakeholders: reducing friction

As engineering products become more complex, the number of teams, tools, and stakeholders involved also grows. This makes coordination one of the biggest challenges organizations face today.

Q: In engineering-heavy environments, processes often span multiple teams and external stakeholders. How can BPM improve coordination and reduce friction?

Marco reaches for the example of a modern car — and it lands perfectly. The 1957 Fiat 500 was a mostly mechanical product. The most affordable car on the market today is a rolling software platform, packed with sensors, electronics, firmware, and connectivity systems.

"Today's products are very complex. They include mechanical systems, electronics, software, and so on. This reflects directly into the complexity of the organizations producing them — and into the interactions between many, many different teams working together to build one single product."

This product complexity directly translates into organizational complexity. More teams means more handoffs, more dependencies, and more opportunities for misalignment.

The organizational challenge this creates is real:

• Multiple specialist teams that rarely share the same vocabulary or toolset
• External suppliers and partners embedded in core design workflows
• Handoff points where data, models, and decisions can be lost or misinterpreted.

Without a shared structure, these interactions often rely on assumptions rather than clear coordination.

BPMN process modeling brings all of this into a single, shared representation. It makes visible not only the sequence of operations but also how information moves between teams — which turns process governance from a management aspiration into an operational reality.

From engineering execution to strategic decisions

Q: Can BPM help bridge the gap between technical execution and strategic decision-making? If so, how?

One of the most valuable roles of BPM is connecting what happens on the engineering floor with the decisions made at a strategic level.

The answer here circles back to data — and to the relationship between engineers and their managers.

When processes are modeled and monitored, they generate a continuous stream of performance data. This creates a shared foundation for decision-making across roles.

BPM becomes the shared language between the engineering floor and the boardroom. Technical teams gain a structured way to surface performance insights upward; strategic leaders gain a transparent, evidence-based view of how engineering operations are actually performing versus how they are supposed to perform.

In this sense, a BPMN model is not just a representation of work—it is also a communication tool that aligns technical and business perspectives.

Process governance without bureaucracy

Q: What does effective process governance look like in a software company for engineers? How can BPM tools support it without creating bureaucracy?

Process governance is often associated with additional layers of control. However, in engineering environments, adding overhead can slow teams down rather than support them.

ESTECO, the company behind both Cardanit and VOLTA, operates at a particular intersection: it is a software company that builds tools for engineering companies in automotive, aerospace, and defense. Its own internal processes are therefore both a product and a proof of concept.

Effective process governance, in Marco's view, is not about adding layers of approval or documentation requirements. It is about making the process model itself the governance mechanism — so that structure is built into how work is designed, not bolted on afterward.

And in engineering, this principle carries an additional dimension: the data generated or linked by the process is as important as the process structure itself. Every task completed, every simulation run, every design decision made within a governed process produces data that belongs to that process — traceable, attributable, and available for analysis.

What effective governance looks like in practice:

• Shared standard — processes are modeled using BPMN 2.0 as a common reference
• Built-in clarity — ownership, data dependencies, and decision points are defined within the model
• Continuous visibility — governance is transparent and auditable without extra effort
• Easy updates — processes evolve by updating and sharing the model, not by adding new layers of control.

This approach keeps governance lightweight while ensuring that processes remain structured, consistent, and adaptable over time.

The cultural barrier: “we’ve always done it this way”

Even when the benefits of BPM are clear, adoption in engineering organizations is rarely immediate. The main obstacle is not technical—it’s cultural.

Q: What are the main cultural barriers when introducing BPM in engineering organizations, and how can they be overcome?

Marco names the barrier without hesitation:

It is a cultural shift, not a technical one. And it is the most common obstacle he encounters.

Established ways of working often feel efficient because they are familiar. However, they can also hide inefficiencies and limit scalability.

But he is seeing the resistance erode. The shift happens, he explains, when people experience the practical benefits of having a clearly modeled, shared process — not just the abstract promise of process improvement.

"What people are enthusiastic about is the ability to have the process clearly defined — to know exactly what is expected of them, and to have the right data in the right place at the right time."

In other words, the adoption happens when BPM stops feeling like documentation overhead and starts delivering clarity in day-to-day work.

The strategies that work for overcoming cultural resistance:

• Lead with clarity, not compliance — show people what it feels like to work within a well-designed process, not just to document one
• Connect BPM to data — engineers respond when they see metrics on process performance and improvement over time
• Start with one process — prove the value, let the adoption grow organically from there

The future of engineering: BPM, simulation, and AI

As engineering platforms evolve, BPM is becoming part of a broader ecosystem that connects processes, data, and decision-making. AI is the next step—but it depends entirely on the data foundation behind it.

Q: How do you see platforms like VOLTA and BPM solutions like Cardanit shaping the future of digital engineering enterprises — especially with AI in the equation?

For Marco, the convergence of engineering platforms and BPM is already underway — and AI is the natural next layer. But there is a prerequisite.

This creates a continuous improvement loop where processes, data, and AI reinforce each other.

How the next-generation engineering loop works:

1. Model processes using BPMN
2. Capture structured data from execution
3. Simulate scenarios to test improvements
4. Apply AI insights to identify optimizations
5. Validate changes before implementation
6. Continuously improve based on results.

"Without data, AI is not effective," Marco concludes. "It cannot draw the important conclusions it is now capable of drawing. Data supports the AI. BPM and process simulation are how engineering organizations build that data foundation."

Key takeaways

For business analysts, process consultants, and BPM specialists working with or inside engineering organizations, Marco's insights point to a clear set of principles:

• BPM in engineering is not just documentation — it is the infrastructure for process governance, visibility, and continuous improvement
• BPMN 2.0 provides a notation precise enough for engineers and clear enough for business stakeholders — it is the lingua franca of multidisciplinary process modeling
• Data-driven change management is not a nice-to-have in engineering organizations — it is the only kind of change management engineers will accept
• Process simulation extends the engineer's instinct to validate before committing — from product design to organizational design
• The convergence of engineering simulation platforms and BPM modeling tools is creating a new category of digital engineering enterprise — one where AI can finally operate on a sufficient data foundation

About VOLTA and Cardanit

Cardanit is ESTECO's BPMN 2.0 modeling tool, enabling engineering teams and business analysts to map, govern, and continuously improve complex multidisciplinary processes with precision and clarity.

VOLTA is ESTECO's digital engineering platform for simulation process and data management (SPDM) and multidisciplinary design optimization (MDO).