I'm starting to dig into Connect (ORD) and I'm trying to wrap my head around how this will work in the least disruptive way.
Currently, we have all of our standards (configurations, DGNLIBs, cell, resources) on the M: drive. There's a Bentley directory, and then each client has a directory under that. My PCFs contain the variables necessary to load the standards for that client. Since each client has any number of design projects, that made more sense than trying to create a PCF for every project we're going to work on - the list would have been hundreds of projects long if there were a PCF for each project.
Project design files are stored on a different network drive (S:). Everybody knows where they are, and all of the departments have equal access to any project they are a part of. Most people working on a project know which client that job is for, so when they open Microstation, they select their Project (PCF) User (them) and they navigate to the S: drive and open their files.
It's not super technical, but it's been effective enough. Any project manager can create a design project, and there's nothing really technical to it because the CAD just kind of floats on top. It's not an integral part of project creation.
That has me thinking about the new Connect workspaces and worksets - I'm not entirely sure how that would shake out over our network.
The way I understand it right now (and feel free to enlighten me!) is that, for our purposes, workspaces could be essentially what our client PCFs are now. Those would go onto our M: drive, similar to now.
But what about worksets? Those would seem to be the actual design project directories on the S: drive...and that sounds like a lot of overhead to keep managed. That sounds as if the person who creates the project directory would also need to know how to generate a workset to go along with it. Or they would need to remember that a workset needed to be requested to go along with the directory before anyone starts working. Both of which are a bit much to expect our project managers to remember...And the list of worksets would be dozens and dozens long. Can I even store my worksets in a place separate from the workspace?
Is it possible to have more than one workspace, but then just one "generic" workset? I can see the benefit of having a workset for each project, but I'm concerned that creating them all might be too restrictive or complicated for "anyone" in the company to do. How essential is it to have only data for a specific project locked into a workset? Can a workset span multiple projects?
I understand that there will have to be some rethinking about how best to manage data with the new Connect-type configurations, but I want to disrupt the company process as little as possible. I can appreciate that I could be missing out on some neat features by sticking as closely as possible to the established way we have here, but I really don't want to turn everybody upside down, or tell them that Transportation has to have something special.
Does anyone have suggestions, experiences, things NOT to do?
Other than the location of the "CAD data" what other stuff is really needed ?
Like you - all of our standards are the same for every project under that client.
What I have done is create a "generic" workspace and then under that I have the workset that contains the standards. So essentially now my users pick a workspace/workset for the project they will be working on. Since the workspace is required (which I don't agree with) I simply just make it a pointer to load the workset and nothing more.
So if I have 6 clients and 60 projects (10 each for example) I will have 6 workspaces and each will contain a workset (so 6 worksets). I load all the standards in my worksets and point to the "S" drive where the working files are. At that point the users can browse to the needed sub folder on the "S" drive for the files.
Tim's approach is a good one. What you use will be pretty site specific to meet your needs. For me, a workspace is simply a certain type of work, a workset is clients, or any group really, then within that are multiple projects, by folder.
Connect r14 10.14.00.109 self-employed
Except that our projects aren't stored by client - they are stored by contract year, regardless of client.
I fear that I will end up missing out on a lot of potential workset properties because I won't be allowed to disrupt the company project storage just for OpenRoads.
Microstation 08.11.09.829Power GeoPak 08.11.09.878Power InRoads 08.11.07.615
we store our project data by year as well. This is why I point the workset to the top folder (S:) for this data and let them browse to the needed files. I simply control the "standards" (level symbology, styles, fonts, etc...) and not the actual working data from the workset.
Client standards are on my M: drive and the working data stored by year is on the S: drive.
My only issue is the sheet index file. We currently are not using this because of the way it is implemented by the software. Hopefully Bentley will change this.
If you want to leverage workset properties, then you are not using it as you need to. Workset properties like location, projectname, billing number, etc... are going to change per project, so the client standards may remain the same, but the actual project properties are not.
The choices I see here would be 1.having a workset for each project and then use the workset properties or 2. set up items for each individual set of properties needed for that clients projects. I would look into the second choice and leave the workset as you have it (same for all client projects)
An example might be:
Have the scenario I mention above with a generic workspace and then put the client standards in the workset. With this you will not be able to leverage the worksets properties for project specific things (IE: Billing number, locations, etc..) So what you could do is create a DGNLIB file with Items in it that pertain to that specific project. Put this DGNLIB file in the same location as the DGNs being used for that project. So you will have multiple DGNLIB files in multiple project folders where the DGNs are located and each will have project specific items in it.
Then in the workset configuration file add: MS_DGNLIBLIST > $(MS_DEF)*.dgnlib
This will essentially add the DGNLIB with the project specific items based on the design file opened for that specific project. In each of these DGNLIB files it will contain the needed items that can be used.
If not and you still want to leverage the workset properties, you will need to create a workset for each project.
Yes, you'll come up with what works best for your. Play with it. Contract year should not enter into WorkSpace or WorkSet set-up, but it can if you like.