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

Creating Products vs. One Company product with folders

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

Creating Products vs. One Company product with folders

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

Creating Products vs. One Company product with folders

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




Creating Products vs. One Company product with folders

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.

Creating Products vs. One Company product with folders

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

Creating Products vs. One Company product with folders

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




Highlighted

- Creating Products vs. One Company product with folders

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.

RE: 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

Creating Products vs. One Company product with folders

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

- Creating Products vs. One Company product with folders

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