Business Case for Introducing WTParts

Forum|Forum|14 years ago
April 10, 2012
6 replies
1179 views

Hi All,

Have you implemented WTParts in your organization? If so, would you be
willing to share any information that helped your team decide to use
these objects? Specifically, I am looking for the pros and cons of using
WTParts?

Thank you for your time,

Dax Williams
Engineering E-Tools Administrator
GE Healthcare OEC

Surgery

Other

S

SteveVinyard

1-Visitor

This is a great talking point. I'm also interested in how other people have leveraged these as well as Pros/Cons.

[cid:image001.gif@01CD1732.72BEC140]

Steve Vinyard
Application Engineer

D

ddemay

1-Visitor

Well for many who are moving from Intralink or just have not implemented the
WTPart have likely done so for one or three reasons:

1.) They have some kind of part representation in another system

2.) They do not understand the WT Part in the context of how it makes
product data management viable (engineering) and eventually matures in a
single product lifecycle management system where QA, manufacturing,
suppliers, and purchasing get involved.

3.) ERP system has some kind of part (it is okay to have a part here),
but a lot of this data belong or should be controlled in a PDM system such
as lot numbers and effectivity data or dual sourced parts.

Most of the reason is either they rely on old adages related to the drawing
/ title block or treat the CAD files (EPMDocuments) as "parts". This
however keeps the rest of the business isolated.

Over the past couple years, I think if they were called PDMParts instead of
WTParts, it might make the definition more meaningful.

For WTParts, where it gets creative is classification, searching, via
PartsLink (or manual classification), and soft typing and other business
metadata that doesn't represent CAD specific data.

This is always a topic that can get passionate real quick, so I am sure
there might be some interesting responses, publicly and privately.

H

HugoHermans

12-Amethyst

Hi Dax,

Yes, we have implemented WTParts. But it was not an easy job to convince all stakeholders about the benefits.

You don't need WTParts when the output of your design department is only sets of drawings. When your Windchill is only ment to manage your CADdata (and derivatives) , WTParts are useless.
I can imagine that don't need WTParts when your model structure maps 100% to a BOM. There can be business contexts with very simple modeltrees so that the modeltree is representative for the manufacturing BOM.

But generally speaking, the assumption that the modeltree should be the basis for rigorous mapping between CADdocuments and articles, could be limiting to the design process. The design process should be a creative process. At the end of it, a transfer has to be arranged from the design department to manufacturing/purchasing. Think about auxiliary levels in the assembly structure, or the lack of levels in the assembly structure because the design process didn't need it. Think about auxiliary parts (e.g. for your TopDown setup), or the lack of some parts. Manufacturing/Purchasing need a product structure that reflects their business (=logistic) processes. In most cases, this does not fit with the resulting structure from a creative design process.

So, the solution is an intermediate object, the WTPart.

Brief, the WTPart is the intermediate between the engineering environment and the manufacturing environment. Without WTParts in your PLM system, you can't store article related information into it.

In our case, we set up a drawing release procedure that enforces the existence of a WTPart, and the correct linking. We advised designers to add additional models to the WTPart if appropriate (think about design intents, generics, etc.), but that is not enforced. Nevertheless, we see designers using the WTPart concept more and more as a tool to ease their work.

Further, we postponed the implementation of product structures in Windchill. Mainly because we are not ready to synchronise a structure from PLM to ERP. It makes sense (more or less) to implement WTParts, but leave the relationships between them the domain of ERP.

Does this shed a light on the topic?

Met vriendelijke groeten, Best Regards,

Hugo.

D

dwilliams

Author

1-Visitor

Thank you to all who replied. I appreciate your time and expert advice.

I worked with WTParts at my previous employment and I've seen how if
implemented well, they allow the organization to quickly and easy find
the product related data and changes. We have a need for WTParts here at
GE for multiple reasons but as Hugo mentioned, it's not an easy job to
convince all the stakeholders about the benefits. Hopefully I now have
enough information to build a solid business case.

Have a great week,

Dax

S

SteveVinyard

1-Visitor

Another thing to consider Dax is the cost of maintaining additional systems to handle this data and the processes around it when Windchill can do the same if not better.

Each additional system costs in the following ways typically:

1- IT staff support

2- Backup costs

3- Client support and admins

4- Software maintenance and upgrades

5- Database license costs

6- Server support and maintenance.

I know guys that have pushed past the bureaucracy and taken an IT budget alone from 450k to 200k by simply displacing duplicate systems.

[cid:image001.gif@01CD1BE9.33838680]

Steve Vinyard
Application Engineer

M

MikeIbosh

1-Visitor

Dax,
I'm also facing the same situation at my current company. Like you , at my last job we implemented WTParts, integrated EBOM/MBOM with the ERP system and had complete closed loop change management systems working nicely. Now I'm being asked to do the same thing in a much larger global company where process changes are hard to sell, and of course, not all are buying into the process. Would you mind sharing the information you gathered for your business case for implementing WTParts?

Mike Ibosh

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.