top of page
Search

Process Systems in the Digital Practice: A Practical Guide

This article explains what a process system is, how to draw its boundaries, and how that helps connect standards, integrations, and day-to-day work.


Process systems sit at the heart of how a digital practice, or any practice, functions. They describe not only the flow of work, but the frameworks that let information move, how decisions get made, and how teams collaborate.

Unlike a procedural “how-to”, a process system is about the larger connections between elements: the relationships between platforms, the policies, and the value streams that link tasks to the outcomes.


This article reframes the concept of process systems using examples from cloud collaboration, construction RFIs, ISO 19650, common data environments (CDEs), and data flows. It shows where a process begins and ends, and why boundaries matter.


What Process Systems in the Digital Practice Are

A process system isn’t about describing how to click a button or how to complete a specific task. Instead, it focuses on the connective tissue between multiple elements of a practice. Think of it as a map of the landscape, and not the turn-by-turn directions.


Some general examples include:

  1. How teams collaborate in the cloud.

  2. How an RFI moves from initiation to close-out.

  3. How separate platforms integrate and exchange data.

  4. How information flows through an ISO 19650 project.

  5. How value streams create meaningful outcomes outside the collective tasks.


When you look at systems at this level - level 3 - you have the following outlines to really think about:

  • The boundaries of the process.

  • The start and end states.

  • The key connection points.

  • Subsystems sit within the bigger system.

  • The logic of the steps taken.

Boundaries: A rule that decides whether an activity belongs inside the process or in another one.

States: The condition something must reach before it can move on.


Why boundaries matter

Boundaries define what is inside the system and what is outside it. You decide. Without boundaries, the system can become overloaded with too many activities and actions.


Let’s look at the RFI workflow as an example:

Flowchart showing an RFI process system in a digital practice. The process begins at “Start,” moves through “Review,” “Assign to Responsible,” “Generate Tasks,” “Generate Drawings,” “Compile Response,” “Send Email,” and “Receive Feedback.” If approved, it ends; if not, it loops back for review, showing how decisions and corrective steps connect across the workflow.

  • Start: RFI received or initiated.

  • End: RFI close-out. (approved or not)

  • At the Approved/ Rejected connection:

    • Approved: Continue to close out.

    • Rejected: Return to the previous state, OR a “corrective” process kicks off as a subsystem.


The process system doesn’t give instructions on the types of drawings to be produced or how a person should respond. Those are task-level systems. The system, in its simplest form, shows what the journey looks like and what happens when decisions are made.


ISO 19650 as a Process System in the Digital Practice

ISO19650 is a perfect example of a process system. It defines what must happen to information (states and responsibilities) as it moves through project stages, but not how individual tools achieve this. Your CDE makes those real through permissions, reviews and approvals.


Hierarchy of Systems

  1. ISO19650: The overarching information management process.

  2. CDE (Common Data Environment): The focus system where ISO principles are operationalised: A CDE may be:

    1. Single-source.

    2. Multi-source.

    3. Distributed ecosystem.

  3. CDE Implementation (e.g. Autodesk Construction Cloud): The tool-level definition of how information is managed through reviews, shared, and authorised states.

  4. Tasks.Such as:

    1. How to create a central cloud model.

    2. How to link consultants' models.

    3. How to issue or share packages.


This stack mirrors the relationship between systems, subsystems, and task workflows.


How integration fits.

Integration is a process system of its own. It defines how platforms interconnect, how data flows, and where responsibilities overlap between platforms.


Example: Microsoft Teams and Autodesk Construction Cloud


Teams hold the discussions and decisions. ACC holds the approved documents. Syncing files isn’t the same as defining authority.


  • Teams and ACC serve different purposes.

  • Information responsibilities intersect: communication, document access, status updates, decisions, approvals, etc.

  • The integration system defines where those overlaps live and how the platforms must communicate:


Types of integrations are:

  • Light integrations (folder syncs, document sharing).

  • API integrations (trigger-based events, auto-validation, background task system operations).

  • SharePoint connectors or automation logic that path files based on naming standards or metadata.


The system explains what connects to what and why.

The task explain how to build, configure, or operate those connections.


How process, value stream, and task systems link together

A process system is not a checklist. It is closer to a value stream: a path where value is created, formed, or transformed.

  • Process system: the high-level logic and boundaries.

  • Value stream: where the value is created along a path.

  • Task: the nodes along the stream that deliver the value.


This means that:

  1. Process systems describe the flow.

  2. Value streams describe the meaning.

  3. Tasks describe the actions.


A practice must understand them and how they interact - value streams have a higher purpose, and the process systems describe the flow.


What to do next

Process systems keep the complexity of the digital practice together. They give shape to the complexity by defining where things start and end, how information moves, and how different platforms, people, and responsibilities connect. They are not the step-by-step instructions.


When a practice defines its process systems clearly, everything downstream becomes easier. System constraints will become more visible, and task systems can be designed to resolve those. Automations are no-brainers, and templates and standards are obvious. Platform integration actually supports the way the practice operates.


A well-designed process system supports the practice and makes observations easier.


How well are your process systems mapped out?


The idea, arguments and writing, with errors, were developed by me. PlaudAI was used to record my thoughts and transcribe, and ChatGPT was used to create a structure for my thoughts to reference in the writing of this article.


Comments

bottom of page