Skip to content
Request a quote

Model-based collaboration

In the traditional way of working everyone works on their own machine and sends files. Three problems follow:

  1. Version clash: which state each person is working from.
  2. Delay: by the time the file arrives it is out of date.
  3. Untraceability: nobody knows what changed and when.

The answer is for the current state of the project to sit in one place, accessible to everyone, with changes logged.

That does not necessarily mean a single shared model: each discipline may keep its own model, but they are accessible in a common space, always in the current state.

On larger projects this live, shared model replaces file versions sent around by email.

One group of elements should have one owner.

Daily or weekly — but predictable.

What changed, why, whom it affects.

Native models within a discipline, IFC between disciplines. IFC and data exchange.

Which version can be referred to.

If there is no decision, the model stays empty at that point too.

The model shows the state but does not explain it. Coordination is still a conversation.

A drawing in a shared space still belongs to somebody.

Here the model is not only a coordination tool but a manufacturing input. So closing the shared state matters particularly: manufacture starts from a specific, fixed state, and after that change costs money. Coordination between disciplines.

A common data environment is not a technological luxury but the prevention of version errors. Most “but I had a different version” problems end here.