Creating Products vs. One Company product with folders

Generally, you would never want to use a single monolithic product with folders acting as "sub-products". A version of this was attempted by one of my customers and it led to an administrative and access control management nightmare. Look at Products (and Libraries) this way.

A Product is an administrative context. It is designed to manage several items in a discrete manner, particularly: Information (Data), People (Teams) and Business Rules (Processes and Access Control). The key to understanding this is to consider that a Product should exist at the INTERSECTION of COMMON Information, Common People and Common Business Rules. In any individual case, this could be around a single product, a product line, or even a product sub-system, among other possibilities. And, in a single company, there could be each of these used to determine a Product - again, it is at the intersection of commonality.

Why is a Folder not the same? The short answer is; a Folder is not designed to provide the same level of commonality management acrosst the three areas. In particular, it does not allow for common People management without a great deal of complex administrative burden. In addition, for Business Rules, while it does allow the Access Control management, it doesn't really allow for the Process managment. As I mentioned at the beginning, I have seen a large customer attempt this, and while it is almost possible, it simply isn't practical, and workable over the long run.

Russ

First I want to thank all the people who provided and continue to provide input and different perspectives on this topic. I honestly did not know if this was something others were battling with or considering at all.

We have two teams but we can cross collaborate between them. This means that any Engineering can work on any product, at any given time. My concerns with the single product and multiple folder model has more to do with flexibility than if it will work for the way we currently structure things.Today we use a network folder that contains all our products and they are split by stock number series. This means a folder can be called 1000-3000 and you would find all product stock numbers in that range inside of that particular folder. We do share parts across other products but it's minimal.

What I found is that as these folders started to grow in size, my users started creating sub-folders to split the products out by product line. This started to become a trend because the original folder started to get extremely large.This is why I was thinking of using the Product context as Windchill teaches in the book, to control the product lines in a similar fashion to what we ended up doing on the network. Some of our products have different product lines for different applications. This again will allow us to create the folders to break down these product lines to a more manageable size.It seems we started with a monolithic folder structure but as we grew, we later started to create sub-folders to better manage the growing data.

We are implementing change management and I don't pretend to know or understand the pitfalls or challenges with either structure. What I want is flexibility for the future. Although we may not create teams and users access controls per product, does it hurt to have that flexibility and not use it? I can't think of a reason why it would hurt us. But on the other hand, if we went with a monolithic product that contained hundreds of folders and later decided that we do want to add user control access, it may not be possible then.Flexibility for future growth is what matters to me. I rather have options and not use them than to later need options and not have them.Since a product context can be shared across another product, I don't see an issue with parts that can belong to more than one product. We simply would create the product inside the product context of the original project that required it's creation and then share it out to other products as needed.

With a global search function, I don't think it matters so much on where things are located as long as we can find them. What may matter is to have flexibility that may become useful in the future rather than assuming we don't need the flexibility and find that we do later.Hope that makes sense. I am leaning toward using the Product context as the Windchill manuals suggest just to insure we have flexibility later if needed.I am still learning and appreciate all the input from those who are further down the road and can prevent me from hitting a dead end.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"