BIM and the case for Teamwork: schedules

[Christiaan]

This is hopefully one in a series of threads to document various concrete examples of why we need Teamwork capability.

My first example is the ability to work on window and door schedules:

In a typical 2D workflow in our office somebody would get on with the door/window schedules while someone else continued working on plans or elevations for instance.

In a single-model BIM scenario we're faced with having to juggle the model between ourselves.

No longer can I carry on working on plans while someone works on the door schedule. They need the model in order to edit the doors and data fields.

So this is an example of where using a BIM workflow in Vectorworks is actually slower than a 2D workflow. Because we don't have teamwork capabilities.

"Sorry boss, can't hit that deadline for the elevations (or sections, or plans...) if we want to get on with the door schedule...." "Shall we buy Archicad now?"

[Stan Rostas]

The only way to solve this workflow bottle neck is to split the model up with the shell of the building in one file and the interior model in another file with both referenced together. If during the process of design the model is all in one file as there is only one working on the model then we have found the best way is to save a copy of the one model file and deleting in each the Design Layers pertaining to either the exterior shell or the interior. This then creates the issue of doors, exterior and interior in two different locations and possibly with windows if the design has some interior windows. What this does is create greater complexity of file and model management as well as some graphic interface issues between exterior objects and interior objects. While possible to solve the issue not very elegant.

[Christiaan]

Inelegant indeed and not something I would want to try, especially given that a simple workgroup referencing setup already gives us a load of pain (incl. rendering bugs and the like).

In any case, where do you stop? For instance this might solve the problem for internal doors but what about external windows? With this split I still won't be able to work on the elevations/sections while somebody else works on the window schedule.

[bcd]

yes, it's a conundrum that doesn't seem to have a solution, unless perhaps a conflict aware Show/Snap/Modify Others feature for Referenced Design Layer Viewports is developed.

[Christiaan]

A delta teamwork server is the solution:

http://www.graphisoft.com/products/archicad/ac15/teamwork.html

[Christiaan]

Tick this one up as a #BIMfail shall we?

[bcd]

very interesting.

a couple of points I take from the video that Delta Server seems to address:

difficulties and bottlenecks in implementing bim model accessibility/workflow management.

only the changes are transmitted via small package uploads

the server manages data integrity

conflict management / ownership request. This seems like a manual transaction each time and way too polite. It also looks like the system isn't truly dynamic but a cumulation of static states. I'd like to be able to move a wall at the same time someone else is dropping a door in there at the same time someone is changing its height without the need for three transactions. The more well established and certain an object of the design becomes the less casually a user can edit it until it becomes locked in.

All in all it sounds like this all works very well. But from four steps up the hill it seems like this sort of connectedness and interoperability is almost humdrum today (thinking of the giant gaming networks & real time collaboration).

It would be great to see VW taking the Delta challenge to improve on it and create its own simplified, enhanced and visionary solution.

[Stan Rostas]

Christiaan,

Another method we have used is with all doors and windows as symbols all placed in a common file with those symbols then referenced into the Building Model and referenced into the Window & Door Detail and Schedule file. An individual can then be working in both files both effecting windows and doors in all locations. The user at times will have to export a symbol they have created and then reference that symbol back from this common resource file to the working file. Also a bit inelegant but has worked for us with little issues at the moment. The only issues we have seen is naming consistency by users for symbols and folder placement for the symbols in the common resource file.

Regards,

Stan

[Christiaan]

Thanks Stan, but we use plugin window objects rather than symbols.

[Stan Rostas]

We use the PIOs also, just place them in a symbol but our schedules may a bit different than yours.

Regards,

Stan

[Christiaan]

Yeah I'm loath to wrap them in symbols. Too many other things stop working as expected when you effectively hide objects in symbols.