Having trouble implementing best file organization practices at new company 3

[DaveDGuy]

Hello all,

As the title states, I recently started at a new company as one of the only M.E. among all other software engineers. The company has an existing product line of machines, which often require custom add-ons or configuration designs depending on the application/job at hand. We are using Solidworks for all part/assembly design.

There is currently not a great file organization system in place. Some project folders have different file structures than others, which have all been managed by a single engineer who has been there for quite a long time, and it seems they have been trying different things between projects but it's clear that everything looks 'experimental' and all over the place. I would like to clean all of this up to something that is reasonable and consistent based on what I have seen at past companies in my career, but am receiving considerable backlash any time I make suggestions. I would like to have the folder structure match the structure of subassemblies in the design, so organize the parts/drawings/related files for each subassembly and place them into their own subfolders, so when needing to find a drawing or previous revision for a particular part, you know what subassembly it belongs to and therefore can do easily navigate to that subassembly folder in the file explorer. This is how things were done at my previous company, and it worked great in practice as I've seen over many years.

The argument I'm receiving against this is that it would take too much effort to 'have to think about how things are organized when designing', even though in practice, this has been a pretty effortless and 'good enough' method to work for all types of design structures in my experience. I'm now trying to logically answer the question of why can't one just use the search tool in file explorer, why should one have to know where it is in file explorer if it takes longer to set up that folder structure in the first place. That it would take longer to click through some folders rather than just using the search tool or by finding it within the 3D software environment. I've tried arguing the importance of consistency and keeping things organized in the file explorer, not just in the 3D environment, but cannot seem to change any minds. Is there any advice out there on how I can argue how important it is to keep your files organized, so that you don't have to messily search through folders to find a part? I thought I was quite experienced in my career thus far... but this is a whole new learning experience... regarding standing up for what I really know will be best, but I can't tangibly prove it without putting in the work to change everything first

 

[TheTick]

I would like to have the folder structure match the structure of subassemblies in the design, so organize the parts/drawings/related files for each subassembly and place them into their own subfolders

This is a bad idea. Whoever is resisting this idea deserves praise and/or raise and/or promotion.

 

[DaveDGuy]

This is a bad idea. Whoever is resisting this idea deserves praise and/or raise and/or promotion.

If you're assuming that I mean literally every single subassembly in an entire assembly, I do not mean that. I mean to say that there are different subassemblies that are modularly assembled for these systems. Would it not logically make sense to sort these into subfolders, to attempt to match how they are organized in an ERP system? These are the 'top level' subassemblies I'm referring to, as they have some nested subassemblies within them, but those nested ones should also be grouped in the same folder as their parent modular 'puzzle piece', not in further subfolders (unless they are common files between projects, which I believe should be stored in a common library folder). Otherwise, what do you believe would be the best way to compartmentalize files? I can't be the only one who thinks a single folder filled with thousands of part, assembly, and drawing files is a nightmare of a solution...

 

[rb1957]

"I can't be the only one who thinks a single folder filled with thousands of part, assembly, and drawing files is the best solution..." ... is that what you meant ? A single file containing thousands of details ? or several files containing dozens (or hundreds) of details ?

"Hoffen wir mal, dass alles gut geht !"
General Paulus, Nov 1942, outside Stalingrad after the launch of Operation Uranus.

 

[DaveDGuy]

"I can't be the only one who thinks a single folder filled with thousands of part, assembly, and drawing files is the best solution..." ... is that what you meant ? A single file containing thousands of details ? or several files containing dozens (or hundreds) of details ?

I realized I mistyped and edited the post. I meant to say that a single folder with all files for a project is not a great solution.

 

[3DDave]

What is great about a wiki - the information can be inserted in small sections and the sections joined up in any fashion one wants. Entirely different views of the data can be made and operated side-by-side.

More important is that it gives a place not only for files, but also a way to record information about the files - why was a part selected? What other designs were rejected? Why were they rejected?

Since a wiki can reference external files, you can create a structure in a wiki that doesn't require rearranging anything in existing file folders. Even better - one can create product structure in the wiki before any files exist, identifying all the parts that will be required and not just a list of folders that maybe are used.

While a wiki isn't a release control mechanism neither are folders.

 

[GregLocock]

On a clean sheet project the PM wanted a filing system based on the WBS. About a year in we looked at what was happening and how many drawings were involved, and decided a pancake (flat) was better for the CAD files, which were numbered sequentially, no attempt at an intelligent file name. There was a master BOM that listed the drawings and that could be filtered to WBS, or material=steel, or chronological, or whatever. Admittedly this was a fairly simple product , but it did include tooling, probably 400 files all up. I can't remember how we handled revisions.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[DaveDGuy]

On a clean sheet project the PM wanted a filing system based on the WBS. About a year in we looked at what was happening and how many drawings were involved, and decided a pancake (flat) was better for the CAD files, which were numbered sequentially, no attempt at an intelligent file name. There was a master BOM that listed the drawings and that could be filtered to WBS, or material=steel, or chronological, or whatever. Admittedly this was a fairly simple product , but it did include tooling, probably 400 files all up. I can't remember how we handled revisions.

Thank you for the input based on your experience. I feel that we may need to focus more on getting a part numbering scheme in place before touching the various file structures that exist.

 

[Nescius]

My honest advice is this: Take a step back and do some reading to get a handle on the modern prevailing notions of how part data should be organized. Focus on principles.

It is not a discussion about software packages or flowcharts, not for a while, at least. It is a philosophical discussion about what is robust and extensible.

Keep in mind that two different companies may implement the same principles in very different ways; they each have different needs. You say that you are new at your company; even if you were well versed in the "philosophy" we're discussing here, it's probably wise to take it slow.

All that said, as a starting point, here are two principles that are quite accepted:
1. As TheTick points out above, the folder structure of a bunch of files is not a good way to encode the relationships between those files. Don't do it.
2. A part numbering "scheme" or "smart" part numbers are not a good way to encode information about a part. Don't do it.

 

[AZPete]

Top level folder with top level assembly, followed by next level or all levels below folder is useful. It at least partitions the main file being utilized from all of the supporting filler files being created and/or deleted below it.

Top level can contain ancillary data to accompany the assembly. Keeps it neat, orderly, and all the junk is in the junk drawer, not the top drawer. BOM can be created and placed there to allow a review of product structure without having to open the master assembly.

As far as intelligent part numbers...recommend don't. There are reasons for it, but it requires ABSOLUTE adherence. Otherwise, the philosophy is undercut and the utility loses its 100% effectiveness. On top of which, it drives part numbers into higher digits, as you lose whole swaths of number lots that can't be used.

 

[CWB1]

Agreed with above, flatter is better with folder structures to help prevent folders from becoming hidden within others. IME standard parts are typically divided among a single level of folders by commodity type.

"Intelligent" p/ns are one of the dumbest ideas bean-counters have ever foisted on companies. Rather than a half dozen digits that are easily and accurately remembered/written you end up with excessively long p/ns and needless human errors/cost for no practical reason.

 

[zeusfaber]

Intelligent Part Numbers.

Could that be the system which allowed a customer to order, and an OEM to manufacture and supply, aero engine parts that had never been qualified for flight - all off the back of a single mistyped digit in the part number?

No names, no pack drill.

A.

 

[CWB1]

That would be a release status or material control process issue. Regardless of part numbering or what the customer tries to order, only production-released parts should ship. Obviously certification is a necessary step in the production release process before status is rolled to production released.

 

[Gr8blu]

With the (relative) complexity and part count necessary to produce larger rotating machines (think synchronous hydro generators, large DC machines for metal rolling applications, etc.), the companies I've worked for have basically used a 4-pot approach to filing design data. Pot 1 = top level assembly, which contains the complete bill, rating information, and has the "oddball" accessories specific to a particular job. It also contains three sub folders. Pot 2 = subfolder 1 = stationary part of the electric machine, including core construction and winding. Pot 3 = subfolder 2 = rotating part of electric machine including core construction, winding, and shaft. Pot 4 = subfolder 3 = all other parts associated with the build, including support structures (i.e. bedplates or soleplates), coolers, fans, terminal connections, "normal" accessories such as temperature sensors, bearings, etc.

Note - no "smart" part numbers EXCEPT the identifier for the main job folder. No massive "subfolder within subfolder" approach.

Converting energy to motion for more than half a century

 

[TheTick]

My employer keeps all the important paper documents in cardboard boxes in a damp basement. Should I put the documents in new cardboard boxes before I move them to a drier part of the basement?

Get a PDM system! If something is valuable, treat it like it is valuable. Each CAD model or drawing represents dozens of man-hours and hundreds if not thousands of dollars' worth of knowledge.

 

[IRstuff]

Get a PDM system! If something is valuable, treat it like it is valuable. Each CAD model or drawing represents dozens of man-hours and hundreds if not thousands of dollars' worth of knowledge.

It's not "valuable" until it is. We had a case where we ran out of digital storage space, so the manager decided to dump some extraneous files; including the PC board Gerber layout files needed to recreate our production configuration. Weeks of reverse-engineering our own production boards later, we cranked out a new set, only to have to fix half of them because of missed features

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[flash3780]

Oh geez... managing data is really hard to do well.
I think the only sane way to manage large amounts of technical data is with some kind of a database.

For engineering, a PLM system like TeamCenter is quite common, and a good way of maintaining associations, revision control, etc.
I have experience with TeamCenter and it is quite powerful.

That said, it's always seemed like a bad idea (to me) to tie up all of your intellectual property in some closed-source database software which requires an expensive license.
For that reason, you might consider using an open-sourced solution instead. There are a couple of popular ones... I haven't tried it, but DokuDocuPLM looks promising.
(

https://www.youtube.com/watch?v=s5ojFBJOaGo)

Whatever you do, you need to train employees to enter the data properly. Assigning appropriate references for data could be considered the most important part of entering it into the database (e.g. which machine, technical requirements, submodule, part numbers, etc. are associated with a design report). A good PLM will organize all of these references and make it easy to find related, version controlled, information.

If I do a finite element analysis of a component, I probably referenced some operating conditions, some assembly, some parts, some material properties, and some requirements. Ideally, a PLM would be able to link all of that data together. You'd like your PLM software to point you to the relevant version of all of the references, and perhaps even show you if some have newer versions available.

It seems to me that choosing PLM software is pretty important for a modern technology company.
I'd shy away from trying a simplified nested directory approach for that reason. A lot of things you work with are cross-linked and versioned. You need a bit more of a sophisticated tool to handle that.

 

[IRstuff]

The argument I'm receiving against this is that it would take too much effort to 'have to think about how things are organized when designing', even though in practice, this has been a pretty effortless and 'good enough' method to work for all types of design structures in my experience.

You've kind of answered your question here already; go with "best in show" of the configurations you already have and create a set of empty folders that people can use as a template and modify the template as needed, when needed.

That said, what's really needed isn't the stuff you've already saved, it's the stuff you didn't save in the first place, like WHY the design changed and WHY is the design the way it is. THAT could be way more important than the design information that is recorded; we had a case where someone modified the process flow, but didn't document nor justify the change, and the resultant yield hit wasn't even discovered until 5 years later when a component that stressed the process had so crappy a yield that the entire corporation's top engineers got involved. Only then did they discover that the process change was detrimental and clearly contraindicated in a journal article from 10 years earlier. Had the process engineer been forced to justify their process change, someone might cited the journal article and nixed the change, possibly saving thousands of dollars and possibly even the future of the division, since that was a bread and butter component whose low yield caused low production margins in a division that was losing money in the first place.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[DaveDGuy]

I certainly didn't expect to open a can of worms with this thread, but have taken note and appreciate all of the insight from members of this forum.

I've since decided to put a hold on altering the base folder structure, but at the very least have tried to 'flatten' some of it by bringing many of the random parts/subassemblies out of the seemingly endless sets of nested subfolders and grouping them based on the top level subassembly structure in the machine design. My end goal here was to attempt to sort these folders by 'chunks' of the machine, similar to what Gr8blu has described with the method of separate pots for each folder.

After reading some of the replies, I believe I didn't communicate my intentions accurately as I want to reiterate how I'm currently trying to cleanup what seems like endless subfolders into a hierarchy where each folder is roughly on the same level of detail with respect to the design. I'm trying to get away from having many sets of nested subfolders, that is what is currently in place and it has snowballed into a meaningless structure.

 

[TheTick]

Hat's off to you for making the effort. I've been through it more than once, with varying degrees of support and success.

One strategy that worked well was to place projects in the main vault structure incrementally. If a project was old and dormant, we left it lie. If it became active due to revision or new design effort, it was moved to the vault.

Meanwhile, lock everything down and back it up.