Document Management, in Real Life
As a structural drafter in a large consulting engineering firm, I most often work on large, usually government-related, infrastructure projects. These projects are normally set up using document management system software, to take care of the myriad files pertaining to the project. The files would be loaded, stored, and are ever growing on a central server for use by many parties working on the project.
The parties involved usually include:
- Design consultants
- Project managers
Each party accesses the same server, which will have an organised array of folders and subfolders where documents are created, worked on, saved, copied, issued, reviewed, and filed.
There are individual logins to the system to ensure security and there will be project-specific standard methods in place for document creation and mutual sharing of designs from different consultants. Its success really lies with all parties using the system equally.
It's a perfect world of free access to relevant, instant, and necessary information to make your own part of the design easier and more efficient. Or is it?
Although it sounds like there is common workspace, technology does not always make this equally accessible – the less direct you are from the server, the less efficient it becomes and the more problems and frustrations encountered.
As a result, a solution is required in dealing with working from remote locations. Can we use components of the software in a different way, which will improve its efficiency and reduce our frustrations?
Here is one option, which is also a minimal cost alternative for overcoming difficulties (and I have tried and tested it).
If an individual PC is dedicated to connect to the remote server, then files can be taken and passed on to an individual to work on at his or her computer. The individual's computer would not be loaded with the document management software; therefore, the user can work at normal speed. The project server can then be updated as necessary to make sure that the main project office has current files.
The main reason for doing this in my view is that when the powerful third-party software is installed on an individual PC, it seems to take over accessibility and speed of the machine, sending information from local to remote and then back to local. This has a terrible result of slowing everything down.
The Central server also is the caretaker for all working emails and it is usually seen as compulsory to copy sent mail into the system. However, when working remotely, that central repository sometimes cannot be accessed. The remote office has to set up its own way of saving any correspondence. A possible solution to this could be to ensure that Outlook.pst files are named appropriately and stored on a local drive, which will be backed up each night.
The software application also has various idiosyncrasies. For example, there is occasional difficulty with ownership of checked-out documents and the reasons for this remain unknown. When a file is checked out and taken ownership of, software marks it as such. After the document is exited, it should be checked back in.
During the drawing session, however, sometimes the status of the file and who has it locked to their name alters. This results in having to find someone with additional privileges to manipulate the system and allowing release of the file. It looks as if the configuration of the software sometimes gets corrupted and we are hampered by delays in getting issues resolved. A possible solution would be to ensure that there are at least two people with full access rights to quickly correct the situation.
Another problem I have encountered is losing pathing for attached x-referenced files and is usually caused by the project office moving files to a new folder. The logic behind this is as the folder grows, the system developers try to make it less complicated and cluttered by splitting files up into separate folders. But this leaves no regard for the impact on the pathing of the files. Many hours can be lost returning the files to their original condition. There is no real solution to this, other than by advance planning where the required folders are set in place at the outset and to stick with this structure, unless of course it is vital to change the setup again.
These are just a few points about our relationship with the document control system. I’d certainly be interested in hearing from AUGI members about similar issues they have had and how they worked around them. Email me at firstname.lastname@example.org with your solutions.