File Management: Why Is It Such a Problem?
File Management has always been a problem. The earliest version of it was how to actually store paper drawings in file cabinets. You’ve got to assign a part number, and stack the drawings alphabetically. People built entire careers out of managing the drawing room, sorting large pieces of paper and even making the equipment for drawer systems and hanging drawing systems.
As the tools for product documentation became more sophisticated, the new solutions brought new problems, and now we have multiple electronic external file references. The solutions to that problem have been to store all the referenced documents in a database, and gain access to the internal metadata for reports and searches and even external BOMs.
We had separate CAD and PDM tools until a product like Onshape, where the CAD and file management tools are really unified. Onshape skipped a step, and your CAD data goes directly into a database. CAD and PDM are essentially built into a single application instead of separate tools. Is this the way all new CAD tools will be developed? Probably. CAD companies are trying to be more monolithic – a single integrated offering for all of your engineering and documentation needs instead of the piece meal “best in class” approach. This business plan is meant to be better for the developer, as it creates captive customers, but whether CAD customers are going to fall for it or not remains to be seen. Onshape has not been the runaway success that many have hoped for, and the reception of Dassault’s 3D Experience platform has been chilly at best.
Does it really matter if the CAD and the PDM are together or separate? Even when they are separate and made by separate companies, the goal has always seemed to be to make them look like a single seamless piece of cloth. So in that light, the Onshape functional integration development is less of a big deal, and you could make the argument that it is really more about the captive customer business plan than a technical or functional improvement. Especially because it hasn’t really changed the base concepts used in either CAD or PDM. In fact, some of the Onshape marketing materials still seem to be aimed at convincing people that they need PDM instead of ignoring the idea of PDM as an entity separate from CAD.
To me this says that PDM is still a problem, even when it has essentially been eliminated. So maybe it really hasn’t been eliminated, just absorbed, and the same old problems have been absorbed with it, and brought forward. So here is a list of the kinds of things you need to pay attention to with regard to file management, regardless of what it is:
- Unique Identifiers
Maybe you don’t call them filenames anymore where you’re from, but you have to have some unique way to identify the data that represents a part or assembly. The age-old arguments here still apply with regard to sequential or significant or intelligent names or some combination. I personally prefer sequential with maybe an intelligent suffix. The military had a method for creating significant descriptions and some people used those for file names. I think that was a disaster. - Fill Out Your MetaData!
Your organization and search systems are only as good as the information you put in. GIGO, (garbage in garbage out) as the old saying goes, and it’s still true. Make sure you identify what metadata you need – what are you going to use for searches, what do you need on BOMs, what kind of information do departments like purchasing, manufacturing, warehousing, shipping need to identify, work with, and associate your data with physical parts? - Storage Organization
Chances are that if you have a real PDM system (one that uses a database instead of Windows folders), you don’t have to worry too much about how to organize your storage. If you are trying to structure a system of folders, I recommend avoiding duplicating information in folder names. Here are some things you should avoid:
– folders for types of files (parts/assemblies/drawings). This can only cause trouble and break references.
– folder names based on ranges of file names
– I would recommend folders based on the function of the document (manufacturing, engineering, purchasing, etc.)
– I might also recommend folders based on project or customer, depending on how your company does business.
Recognize that ideally, you are going to find files using searches rather than browsing. Any storage structure should be set up so that it is browsable, but also such that searches can be done in a single step. Browsability generally is only practical when you are very familiar with the structure, and while some people are going to be this familiar with it, not everyone who needs access will be. Most people will be better served by searches. - Security
I know there are people who don’t believe this is necessary within a company of competent users, but it really is. If you have a folder system, and one person makes a mistake, they can move or delete an entire folder with all of its contents in a single move. This is one of the reasons to use a real database instead of a folder system.
(As a note, there are some low end PDM products that store the CAD data in Windows folders. To me, this is a risk you don’t need to take. Some people can be either inquisitive or otherwise motivated to get around the system. Windows folders provide a way for them to circumvent the process. One of the things PDM is supposed to do is to simply enforce the rules. Folders make enforcement more difficult.) - Non-CAD Data
Remember that you are going to need to store, control and access non-CAD data including images, spreadsheets, programming, and other types of information. Your PDM process needs to accommodate this kind of data. - Process Control
One of the advanced features of most PDM packages is workflow. This is really necessary for product documentation release, document change requests/approval, phase or gate approvals. I’ve worked in a place where this was done by moving a large package of drawings and forms from desk to desk. Things often get lost. Digital workflow control keeps track of everything, saves a lot of paper, allows multiple people to review documents simultaneously, and keeps a lot of clutter off of your desk. - Version Control
Yes, your parts and assemblies need revision levels as well as the drawings. The part revision doesn’t need to be the same as the assembly or the drawing. Just get used to it. Use numerical for pre-release, and alphabetical for released stuff. - Document Status
You should also have document status levels to let people know where documents are in the cycle. All of this should be written up and published, and you need to have a big training session on it. Maybe a big poster in the lunch room too. - Viewer with redline capabilities
You need to have a viewer for all the documents you put in your PDM. Not everyone who needs to see stuff in the vault is a CAD user. Purchasing people need access to your documentation and need to participate in approvals.
Implementing PDM is a big job. It has to be done right the first time. It’s hard to make changes to an existing vault. You might consider hiring someone to come in and do it, or at least help you make the right decisions.
Ken, are you using Teamcenter or something else?
Matt, Data Management really is a complicated issue because there are so many variables. The “file share” option is basically a ticking time bomb as it is not sustainable as the data grows, and it doesn’t support any automated process or status control, lacks dynamic security and has no version management.
One file management point I think you might want to add is “Relationships”.
I’m finding this is one of the most important management aspect of PDM/PLM as the digital thread continues to grow through an organization as it is no longer just Engineering using the data and not just a 3D CAD file and associated drawing. Now we have downstream data that is created from that CAD data in the way of CAM programs, CMM inspection routines, work instructions, process control, Quality docs, marketing collateral, service manuals, etc. This must all be linked through relationships both so change can be automated through them, but also so change impact can be known. Think of it as a line of dominoes and the first one is your model, once it falls it sets off a chain reaction through the others. Relationships insure that it happens, and it allows you to see what will happen.