cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Creating Products vs. One Company product with folders

DamianCastillo
1-Newbie

Creating Products vs. One Company product with folders

Not sure if this question is crazy or not, but I figured I need to ask the pro's.


When looking at Windchill 10.1 Products, is it best to create products for each of our product lines vs. creating one Product as a container for all products and mange the various products with folders inside that container?


Not sure what problems that would cause with context sharing, etc.


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

10 REPLIES 10

Damian,

Does the product structure change in 10.1? We are still in 9.1 but our products are broken down by Customer teams then the customer’s products below that. The reason being is during the change process those involved in initiating or approving any configuration activity will be in that product.

Bob Lohbauer
Jacobs Vehicle Systems
AL_ANDERSON
5-Regular Member
(To:DamianCastillo)

I would not consider this as a function of product lines so much as a
function of teams and access control over the objects associated with
those product lines. If all of your users work on one big, happy team
that shares equivalent access over all objects in the product context,
then one product context makes sense. If, like us, you have people more
territorial about their product data, then you will want to divide up into
product contexts for access control and data management purposes. It may
turn out to be one product context per product line. Or it might be one
context per product family. Or whatever works for your organization. I
really think this is a data ownership and control question when
considering the number and purpose of your contexts.

Al




Damian,

We have only one “product” but use multiple Products to control access to different projects. Long story…

Anyway, the teams work across the Product containers without issue as long as they have the appropriate access. The past limits of working between Product contexts I think is pretty much gone since 9.1 if not earlier.

So, think of the Product containers in terms of teams, access, and workflow members.

Ah, see Al Anderson’s reply.

There are many possibilities and questions here


1) Are there common modules / platforms reused across these product lines? Or are they distinct? (I would assume that things like common hardware is a separate discussion)

2) As others have discussed - is there a need to segregate them for needs of access control or team, or other business constraints - they are run by different units that might have different numbering, life cycles, etc.

3) Are they short lived or long lived relative to each other? Do you expect to have to cycle them in and out of use based upon their product "lifecycle" - eg no longer sold or used?

4) Are there any customer or design partner needs that would hint at segregating the data?

Lots more questions. It's hard to say there is a single right answer, although I would avoid one large monolithic product.

z

We are currently NOT WC users, but are in an active evaluation of 10.1.



Jeff, I definitely respect your opinion, and I'm curious about one
statement that you made:



"..although I would avoid one large monolithic product."



If I had to answer your questions, these would be my answers:

1) Yes - common modules, much sharing amongst platforms

2) No - we have "teams" but teams are allowed to share / revise
anything. Any team can change any other teams work

3) Longer lived with respect to each (years, not months/days), but
they will eventually NOT be sold, and be replaced

4) No



It feels like the answers to these questions put us in more of a situation
where we have a larger product structure. Actually, breaking it down by
product is a little bit problematic for us, because the lines between
products is very very gray.



Our current layout is like this:

Product Context

- PRODUCTION CAD (all released parts, totally shared between
products) <this is=" a=" folder=">

- NON PROD CAD (not in production) <this is=" a=" folder=">

o Proj1 <these are=" all=" folders=">

o Proj2

o Etc.



Our current plan, then is to move from these "proj" directories to PROD
CAD during the release process, because the data is cross used across
platforms once it's released, and the concept of project that "created"
the data is somewhat irrelevant moving forward for us.



Because of that, our PROD CAD folder is going to large over time, and
really become almost a monolithic product.



What are the downfalls to having this monolithic product? If there are
unforeseen pitfalls that we might encounter, now is the time for us to
consider changing and doing something differently




We utilize products to separate our "programs". Product contexts work well if ACLs, workflows, OIRs, and teams differ. This is the case with our programs though there are many commonalities. Downside, we have over 150 product contexts. Some have very little data in them. I have considered removing some and just renaming them for other purposes. This model seems to work for project based, A&D work.
RussPratt
5-Regular Member
(To:DamianCastillo)

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

Russ,



Thanks for post. We're new to this, and trying to learn, so please bear
with me! So let me clarify a little bit on what we're doing, and what I
think you're saying.



First off, this is what our structure CURRENTLY looks like in our test

Hi Darrin, this is good info that you laid out. I think one of the biggest disconnects going into Windchill is that your Team access per product is entirely focused on checkin/out/revision capabilities. Hence this is all common amongst all of your users.

Now moving forward in Windchill, you now have a "Team". This team is for access control but ALSO the big deal is the workflow team. This where the monolithic model falls out the window.

Simple Example:
You promote an object and it has to go through a design reviewer (specific for your product line). In the monolithic you cannot designate someone in the team proactively but that team is for ALL the products. If you product lines were broken out into various Windchill Products this problem is non-existent as you can simply dump that reviewer into a role and it's done.

Now that is a simple example not the defector standard for promoting by any means. Change Management is really where it gets nasty with a monolithic product. Either way there are a number of things in Windchill that rely on the team beyond just simple access control.


[cid:image002.gif@01CE1BDA.3E4FA2F0]

Steve Vinyard
Senior Solution Architect

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"

Top Tags