From Process Documentation to Process Modelling: A Model-Based Approach

Engineering organisations often define their processes using documents, flowcharts, spreadsheets and review templates. These artefacts are useful, but they often remain disconnected from each other.
A process may be described in one document. Responsibilities may be listed in another. Artefact templates may sit in a separate folder. Review expectations may be captured in a checklist or governance slide. Over time, this creates a familiar problem: the process exists, but the relationships between activities, roles, responsibilities and outputs are not always explicit.
This is where model-based approaches can provide value.
Model-Based Systems Engineering is normally associated with product architecture: requirements, functions, logical components, physical components and interfaces. However, the same principles can also be applied to the way engineering work is organised and delivered.
A process can also be treated as a system.
It contains stakeholders, activities, exchanged information, produced artefacts, responsibilities, dependencies and feedback loops. When these are captured in a model, the process becomes easier to analyse, communicate, reuse and maintain.
Many organisations already have defined processes. The challenge is rarely the absence of process documentation. The challenge is usually that process knowledge is fragmented.
For example:

• activities are described in one place;
• roles and responsibilities are described somewhere else;
• artefacts are stored as separate templates;
• review flows are understood informally;
• dependencies between teams are not always visible;
• updates to one part of the process are not consistently reflected elsewhere.

This can create ambiguity in delivery.

• Who is responsible for producing a specific artefact?
• Which activity consumes it?
• Which stakeholder reviews it?
• Which role requests an update?
• Which step depends on the completion of another activity?

These are not only documentation questions. They are architecture questions.
A model-based approach allows these relationships to be represented explicitly.

Treating the process as an operational system

In the example shown below, I used Capella to represent a modelling process as an operational system. The intent was not to describe the technical architecture of a product, but to describe how people, activities and artefacts interact during an engineering process.
The model captures several complementary views:

• a breakdown of process activities;
• the roles involved in the process;
• the exchanges between those roles;
• the artefacts produced or consumed;
• the behavioural scenario showing the sequence of interactions.

This is important because no single diagram can communicate the full process. A process has multiple dimensions. It has structure, behaviour, ownership and information flow.
The value of MBSE is that these views are not isolated drawings. They are different views of the same underlying model.

Modelling the roles involved in the process

A process is performed by people or organisational roles.
In the example, the stakeholder structure includes roles such as:

• Server Admin;
• Systems Engineering Manager;
• System Architect;
• Subject Matter Expert;
• MBSE Lead;
• Data Modeller.

This makes the process more explicit because it separates the work from the people or roles responsible for participating in it.

This view is valuable because many process issues are actually role-clarity issues. The process may define what needs to happen, but not always who initiates, performs, reviews or approves each step. By modelling roles explicitly, we can later connect them to activities and exchanges.

Defining the process activity structure

In this example, the process is structured around activities such as:

• Prepare for Architecture;
• Prepare Models Database;
• Define System Engineering Scope;
• Define Modelling Scope;
• Review and Agree Scope;
• Update Modelling Scope;
• Capture Architecture;
• Perform Model Review;
• Pre-release Model;
• Release Model.

This type of activity breakdown helps establish the scope of the process before adding detail.

This diagram is useful early in the article because it gives the reader a simple entry point. It says: “this is the process I am modelling.”
However, the activity hierarchy alone is not enough. A list of activities does not explain who performs them, how they interact, or what information is exchanged.
That requires additional views.

Connecting roles, activities and exchanges

The next step is to represent how the process behaves across roles. The operational activity view shows the interaction between the Server Admin, Systems Engineering Manager, System Architect and Subject Matter Expert.

For example:

• the Server Admin prepares the model database;
• the Systems Engineering Manager defines the system engineering scope;
• the System Architect defines the modelling scope;
• the Subject Matter Expert reviews and agrees the scope;
• the System Architect updates the modelling scope when required.

The important point is not only that these activities exist. The important point is that they are connected through exchanges such as:

• Acknowledges Model Database Ready;
• Requests Modelling Scope Definition;
• System Modelling Scope;
• Request Modelling Scope Update.

It shows the real value of modelling the process: relationships become visible. Instead of saying “the system architect defines the modelling scope,” the model shows the context around that activity:

• what triggers it;
• who requests it;
• who receives the output;
• who reviews it;
• what happens if an update is required.

This is where a model-based approach becomes more powerful than a conventional process flowchart.

Capturing the behavioural scenario

A process also has a sequence.
The scenario view shows the order in which activities or roles interact. This is useful because an activity breakdown may show structure, but it does not always show the execution logic.
In the scenario, the process begins with the model database being prepared. Once ready, the Systems Engineering Manager receives acknowledgement that the model database is available. The manager then requests the modelling scope definition from the System Architect. The System Architect provides the modelling scope to the Subject Matter Expert, who may request an update.

This diagram is useful for explaining process logic.
It helps answer questions such as:

• what happens first?
• who sends information to whom?
• when does review occur?
• when is an update requested?
• where are the handovers?

This matters because many project inefficiencies occur at handover points.

Modelling artefacts as structured information

In many organisations, artefacts are treated as static files: documents, templates, exports, spreadsheets or model files. However, in a model-based process view, artefacts can be represented as part of the system of work.
In the example, artefacts include:

• Model;
• Model File;
• HTML Model Export;
• Work Modelling Framework;
• Model Review Template;
• Model Scope.

This view is important because activities do not exist in isolation. They produce, consume, review and update artefacts.
For example:

• “Prepare Models Database” may create or enable the model file;
• “Define Modelling Scope” produces the model scope;
• “Review and Agree Scope” consumes the model scope and may trigger an update;
• “Release Model” may generate or depend on the HTML model export.

When artefacts are represented in the model, it becomes easier to maintain consistency between process steps and expected outputs.

Model-based process modelling

The value is not the diagram — it is the connected model. A key distinction must be made; the value of this approach is not simply that diagrams are produced, many organisations already have diagrams, the value is that the process information is captured in a structured model where relationships can be reused across views.
For example, the same activity can appear in:

• an activity breakdown;
• an interaction view;
• a scenario:
• a responsibility view;
• an artefact traceability view.

The same role can appear in:

• the stakeholder breakdown;
• the operational activity view;
• the scenario;
• the responsibility allocation.

The same artefact can be linked to:

• the activity that produces it;
• the role that owns it;
• the role that reviews it;
• the downstream activity that consumes it.

This is where model-based process modelling becomes different from traditional process documentation.
The model becomes a single source of structured process knowledge.

What problems does this solve?
This approach can help organisations address several common issues.

1. Ambiguous responsibilities
   • When activities and roles are disconnected, people may interpret responsibilities differently. A model-based process view makes it easier to show who is responsible for which activity and where handovers occur.
2. Disconnected artefacts
   • Templates and deliverables often exist separately from the process that uses them. By modelling artefacts as part of the process, it becomes clearer why each artefact exists, who produces it and how it is used.
3. Weak review logic
   • Reviews are often described as governance steps, but the inputs, outputs and update loops are not always visible. The model can show the review flow explicitly, including when updates are requested and which role performs them.
4. Poor process reuse
   • When process knowledge is captured only in documents, reuse between projects is difficult.
     A model allows the same structure to be tailored, extended or reused for different project contexts.
5. Difficult onboarding
   • New team members often need to understand not only what the process is, but how roles, activities and outputs relate to each other. A model-based representation gives them multiple views depending on what they need to understand.

Why this matters for MBSE adoption

Many organisations try to adopt MBSE by focusing immediately on tools, languages and modelling standards. That is understandable, but it can also create resistance.
Stakeholders may ask:

• Why do we need another tool?
• How does this help delivery?
• What does this improve compared with our current process documents?
• Will this create additional modelling overhead?

One way to address this is to use MBSE to model something stakeholders already understand: their own process, this makes MBSE less abstract. Instead of presenting MBSE as a technical modelling discipline only, it can be positioned as a way to make engineering work more explicit, consistent and reusable. The process itself becomes the demonstration.

From process documentation to process architecture

The approach can be summarised as a shift from process documentation to process architecture.

This does not mean that documents disappear. Documents, reports, templates and exports are still needed.
The difference is that they can be supported by a model that maintains the relationships behind them.

A practical consulting proposition

For organisations, this does not need to start as a large transformation programme. A practical starting point could be a focused process modelling pilot. For example, select one engineering process, review workflow or model governance activity and represent it using a model-based approach.

The pilot could deliver:

• a process activity breakdown;
• a role and stakeholder structure;
• an interaction view between roles and activities;
• a scenario showing the sequence of exchanges;
• an artefact structure
• a responsibility and traceability matrix;
• a short process architecture report.

This would allow stakeholders to see whether the approach provides value before committing to wider adoption. The goal is not to force an organisation to adopt a specific tool or notation. The goal is to demonstrate that complex engineering work can be represented more clearly when the relationships between activities, roles and artefacts are modelled explicitly.

Conclusion

Engineering processes are often treated as documents. But in practice, they behave like systems.

They contain roles, activities, artefacts, dependencies, decisions, exchanges and feedback loops. When these elements are disconnected, ambiguity increases. When they are modelled, the process becomes easier to understand, review, improve and reuse.
Using a model-based approach, it is possible to represent not only the architecture of a product, but also the architecture of the work required to produce, review and maintain engineering outputs.
The value is not in creating more diagrams, the value is in creating a connected representation of how engineering work actually happens.