Names, Numbers, & File-names (Oh my!)

[gchampoux]

As we get ready to migrate from Intralink 3.4 to 9.1, I need to a define a strategy on EPMDocument names, numbers, & file names.
I would be interested in how others have approached this.
Fortunately for me, this will not be PDMLink, so I will not have to deal with WTParts.

Currently in 3.4, the object names are the same as the file names. We didn't have to think about it.
But in 9.1, the EPMDocument name, number, and Pro/E file-name can be completely different.
The potential for error & confusion could be significant.
It appears that the only thing that absolutely must be unique is the object number. Is that correct?
Names & files names do not need to be unique?
Can I force them to be unique? Is this a good idea?

And we have never used the Pro/E Common Name (PTC_COMMON_NAME) when creating models & drawings.
Should we consider such now?
If I understand correctly, in 9.1 the Pro/E Common Name is automatically mapped to the EPMDocument name.

We do not want to use any auto-numbering, as our part numbers are predefined externally, in an independent ERP system.
The users will be required to enter the already-assigned name/number/file-name when they create them in Pro/E.

Currently, models and drawings use the same base name (ex: 12345.prt & 12345.drw).
We definitely want to continue this method.

I was thinking that we would want the EPMDocument name, number & file-name to be identical (including .xxx extension).
What are the advantages & disadvantages of this (including migration of 3.4 files)?
Can I enforce all three to be the same? (object initialization rules?)

Gerry

[avillanueva]

Filename and Number need to be unique. I have them set to the same in
the preferences and it makes sense. Why have two fields that have be
unique but different? As for name, let that be the description of the
part or item. Drawing title? Ok, you have 12345.prt but what is it? Look
at the name. These are not unique but that's ok. OIR rules would not do
it. I believe its all in the system preferences.

[HugoHermans]

Hi Gerry,

We moved from Intralink 3.4 to Windchill now 3 years ago. We discussed
this issue a lot upfront, and implemented your suggestion (three times
the same value). Users are used to it, now, so nobody is complaining,
but I don't feel to happy with it. One of the (minor) disadvantages is
that users have to enter three times the same value during a rename.
Since you aren't dealing with WTParts, and your ERP-system is
responsible for the unique identification, you could use the ERP-number
as the number in Windchill. The very big disadvantage of this approach
is that you have to have ERP-defined numbers before you can start your
creative process in ProE, for all your CADdocuments. Are your designers
going to like this? Or, you are going to rename your formally released
CADdocuments afterwards, and leaving the other CADdocuments in some grey
area?. Are you ending up in a situation where you have CADdocuments
with ERP-numbering, and other CADdocuments not identified by
ERP-numbers.
Second, filename is what your designers want to see in the model tree.
Can they read the model tree filled up with ERP-numbers? Everyone, also
the newbies? And regarding the first consideration, what will happen
with the readeability of the model tree when designers start renaming
their models, in order to allign them with the ERP-numbering?

What we have done, and I feel very comfortable with it, is that we
implemented the ERP-identification as a parameter in ProE, designated to
an attribute in Windchill. So, technically, in our Intralink 3.4 era,
our formal coupling with ERP is not driven by the CAD id, but with a CAD
attribute. And since you can add an attribute as an extra column in the
model tree, designers have filenames and ERP-numbers in ProE nicely next
to each other.
We continued this approach after the migration to Windchill, although we
implemented the WTPart-concept.

What I would do if I could revert back :
- I would implement autonumbering, and forget about this field in the
day-by-day business.
- Implement the ERP-number as an attribute in your CADdocuments and in
Windchill (so you avoid renaming and/or mixed naming strategies)
- synchronize filename and common name and use a composition of some
dominant words in the description of the object (so the name is a short
description).

Met vriendelijke groeten,
Kindest regards,

Hugo Hermans

-

NV Michel Van de Wiele
Michel Vandewielestraat 7
B-8510 Kortrijk (Marke) - Belgium
Tel : +32 56 243 211
Fax: +32 56 243 540
BTW BE 0405 450 595
RPR Kortrijk

[srector]

In 3.4 we followed the practice of naming theparts and assembliesbased on our part numbers (including dash number). Drawings just carried the base number (no dash).

When we transitioned to PDMLink, we mapped the file name to the "Name" and "Number" fields (minus the file extension). We have also recently begun having our userscreate a descriptive entry in the "Windchill Common Name" field, which gets mapped to the "Name" field in PDMLink. Whether you choose to use WTParts or not, this is kind of handy since it allows users to perform key word searches for documents when they don't know the number (our Program Management types like this).

It took a while for our users to adjust, but it seems to be working out well now.

[gchampoux]

Steven,

Thank you for responding.
We follow the exact same file-naming standard in 3.4, and expect to continue to do so in 9.1

We current do not use the common name in 3.4.
We too will probably start using it in 9.1.
We do not have have PDMLink, so WTParts are not of concern. (Out of sight. Out of mind.
We have Intralink 9.1 only, so we only have to deal with EMPDocuments.

Gerry Champoux
Lead Engineer
Information Technology

Williams International
2280 E. West Maple Road
Walled Lake, MI 48390-3828

' (248) 960-2816

7 (248) 960-2607

* -

þ www.williams-int.com <outbind: 123=" www.williams-int.com=">

[MikeLockwood]

I was completely confused about this at the beginning of planning migration to PDMLink from Intralink. Attached is what I created to work thru understanding it.

The mapping between what a user enters and what results is:

- Very clear for non-CAD Documents

- Very unclear for Pro/E, because of the use of "Name" and "Common Name" in the create UI

Seems like a lot of people miss out on a lot of value of having the Document Name be something meaningful in words (like Name = Bracket, Module2 for example).

Auto or manual numbering affects this in a relatively big way depending on how much significance is assigned to the Number. We have manual number in place for all documents in all contexts - definitely not efficient because it requires a separate number-assignment system, but seemed like the best choice. A new company may be able to choose auto-number, but pretty tough for an existing company with existing data.

[vmcdaniel]

We migrated from 3.4 to 9.1 and set NUMBER = NAME = FILENAME.

We are regretting that we did not set NAME = description for the objects.

Everything in Windchill embraces the use of NAME for a descritpion attribute; from the default table columns, to PSE, to thumbnail viewer, default promotion request naming.

NUMBER=FILENAME (preference), NAME=Description seems best.

We are currently investigating having the Drawing title block pull NAME (PTC_WGM_NAME i think), and some way to go set NAME to DESCRIPTION attribute to make this consistent with wtDocs.

Other options are to use preferences to set NAME = a Pro/E attribute, but I have found this only applies to populate NAME, not keep them insync.

[patrick.chin1]

When I worked at Psion Teklogix, we added some excellent customizations with the help of <u>www.najanaja.com</u> to Windchill for the issue of Windchill Name which has no history. PTC has yet to change this basic requirement since day one of Windchill. Najanaja customized the callout of Windchill Name to point to a custom IBA (history) called company_name for example. So with any function of Windchill Rename (reidentify object), save as, etc, the new value will both change Windchill Name (default at master level no history) and populate the IBA. Thus, when you browse the information pages of the objects of Windchill, the COMPANY_NAME will appear as the value of Windchill NAME. All the folders view NAME column has been switched with the new IBA company_name with a display value “NAME” so it looks like nothing has changed.

Here's what I wrote in response to blogger on the PLM space regarding issues with managing File Namesand a movement to completely ignore them:

File Names is old mentality of managing data in a Windows Explorer folder. Really your management should be separated into 2 different categories: metadata management and file management. Uniqueness architecture in a database should be according to these 3 rules:

1. Physical part objects metadata are uniquely managed according to number and organization
2. CAD object metadata are uniquely managed according to number, type, authoring application and organization.
3. CAD file names are also uniquely managed according to filenames, authoring application and organization.

The physical part objects form the BOMs (RBOM, EBOM, MBOMs, SBOMs, PBOMs). Since physical BOMs may and may not have CAD data/files, CAD objects should not be the primary focus of generating the BOMs. It should control/build the order that it drives but in essence CAD BOMs are functional (i.e. mechanical, electrical, software) specific. Some PLM tools don't have this distinction or separation.

One must always accommodate multiple CAD integration since most OEMs, OCMs, partners and vendors share or duplicate files in but use different CAD tools for the same physical part. Thus, the file names may be identified with the same number and even filename+extension (i.e. ProE and SolidWorks with .prt). The same can be said with ECAD and MCAD to number the meta data the same (faster identification with grouping and searches). The CAD objects can all then be associated to the physical object.

I don't think it is futuristic because I've been implementing this for the past 10 years. I don't hide file names because most CAD users are very file and tool centric. It all depends on the user's view and requirements. I'm using PTC Windchil PDMLink/ProjectLink now with complete data integrity and moving to a database managed metadata managed system but allowing a direct synchronization functional groups to associate their CAD data packages to the physical object. Thus maintaining then intended attribute mapping.

For non-CAD user, we can change the view/display to place FileName as on of the last column or not even show it at all with filters and table configuration. As a past aircraft engineer, I know how important it is to communicate to MFGs, partners and vendors from both a physical object BOM and CAD file perspective. In most cases, the only importance of CAD file is to make sure that it is the exact configuration of files that generated the BOM. Most of the functional groups outside your CAD domain are not really interested in the filenames. But, your peer functional CAD person comply relies on filenames and uses a different view of you PLM interface where filenames are the first column in their search results.

To add, most/all of your authoring tools for documents, drawings, BOM and CAD files do not exist within the PLM Tool. Also most PLM tools are metadata form generators which cannot author some required standard document formats. Hence you have the more expensive authoring tools for CAD, Arbortext/XML, etc. In order to have accountability of your product information, PLM tools must be able to manage and control these files from these complex authoring tools. Most business properly manage their documents with part numbers or drawing/document numbers with revision control. Like I said, there can be more than one file that describes a part. You have to take into account of all authoring tools involved.

See attached. I've been sending this out and it should help you.

Good luck with Windchill. I hope you are not using Windchill like Pro/I. It would be such a waste of a good PLM product just to manage ProE files. You have to open solution to a more enterprise solution than just ProE CAD vaulting. Windchill can bring much more ROI rather it being a pretty expensive Pro/I replacement.

[JosephCugini]

Gerry,

I am a little late to the discussion that you posted back in December.
We too are just starting down the Intralink 9.1 road and I have the same
exact question as you did. I saw the responses that were posted to the
message boards and I believe I understand the difference/limitation of
auto numbering and the various names within ProE/WIntrlaink.



From you description below it sounds like we have a very similar naming
convention. I intend on turning off auto numbering and training the
engineers to use PTC_COMMON_NAME as a description field. My question
is, during a rename task have you found a way to force the Intralink 9.1
number and file name to remain the same? Again, I don't care what the
PTC_COMMON_NAME is but I'd prefer that the name & file name match.
Assuming this can be done, am I missing something here? Is there any
good reason why you wouldn't want this to be the case?

[egifford]

Resurrecting and old thread, but I'm wondering if anyone has found a fix to this without extensive customization. We're in the final stages of migrating from Intralink 3.4 to Windchill PDMLink 10. We will be using the NAME field as the descriptive name for the Pro/E part / assembly - this is fine. The system is set such that Number is driven by the File Name of the Pro/E object. This is fine until the Pro/E file needs to be renamed. The rename function allows you to enter a new "file name", but the value for thefield "Number" does not get updated accordingly (doesn't stay in sync and use the new file name). In the rename function the Number field is not editable, so you can't even manually apply the same text for thenew file name / Number.

Any suggestions? I was tempted initially to avoid this by using AutoNumbering and let "Number" essentially be meaningless, but PDMLink tends to be very Number centric for searches etc.

[BenLoosli]

The Number field is editable on a file rename BUT only if done from the system side AND the file is not in any workspaces.

Thank you,

Ben H. Loosli
USEC, INC.

[Robert-Altman]

Erik,



Perhaps this document will help?





How to edit the New Number field when renaming a CAD Document in
Windchill PDMLink

[cc-2]

Hello

I know that every entreprise has its own legacy systems/processes/data to deal with when migrating to a new system. However, it should not be IT driven but business driven. Business processes should always be considered to be reviewed when adopting new technology, even if the change hurts, it will be bring huge benefits only months after Go Live. I have seen companies who used Autocad the same when they drew on paper. The result is that a autocad file will contain several parts. so it is very difficult to find the correct dwg file, as a consequence the company still work as if the autocad file were paper. What a waste and miss opportunity.

Usually companies have ERP before PDM/PLM and they tend to believe that ERP is the master in term of product data. IT IS NOT. In case of conflicts, the reference should always be PDM/PLM. Also as mentioned above by someone, if ERP is used to allocate number, it is usually because of a request for Sales and it is about a finished or assembled good. Therefore, either the product structure must also be defined in ERP first so the design team get all the numbers they need, or it means that components created in the PDM get their numbers past into the ERP and as a consequence ERP does not define the number.

I appreciate that, once again, due to legacy, it may seem the best approach but let's put into a different perspective.

If you had to start from scratch, you would surely implement your PDM first. This is where your product IP resides after all, and your PDM feeds your ERP. So even if ERP is already there when implementing PDM, this should be the goal. PDM feeds ERP regarding product data. The As Designed structure (eBOM) resides in the PDM and you can't make the As Built structure (mBOM) without the As Designed structure.

Finally, as I do not want to write an essay :), there are certain fundamentals which should always be followed:

avoid duplication, (ie Name is not a Number, Number is not a Name, therefore those two fields should always have a different value).

System parameters between systems should always be mapped 1 to 1 ie PDM Number = ERP Number, PDM Name = ERP Name/Description (some ERP call it Description)

Failling to comply to those basic rules can only add complexity into the systems, the process, and will reduce data quality and give more data admin and overhead. When carefully thinking about it, it is easier to change the way people work than dealing with the additional complexity in the medium and long term.

Future integration between the two will be very difficult, while there are more natural complex topics to consider (product structure transfer, change management).

What is your reason of having your ERP allocating product number ?

PS: This is a passionate topic, companies spend a lot of time and money about it when really, with a bit of willingness to change, it is quite trivial,

PDM Number = ERP Name

PDM Name = ERP Name

The business process should lead to adopt this

Best regards

[cc-2]

Hi Erik

all object orientated application are designed to work seamlessly with autonumbernig. At the end of the day a Number is just THE unique identifier of the object.

Obviously, for companies who used for decades descriptive numbering scheme (due to the old age where everything was paper), it could be quite scary to move to descriptive Number.

From my experience descriptive numbers always have a limit to how much meaning you put into it. As I always say a number is not a BOM. In addition, and this is the power of system like windchill you have all sort of very useful functionalities, some are automated (such as Where Used, Relationship reports, why do you want this info in your partnumber ?? when it is managed automatically per the system). also you can have as many soft parameters which are a lot more flexible and powerfull for searching, sorting, reporting, comparing than descriptive partnumbers.

We have 2 divisions, both used descriptive partnumber. The first to implement Windchill we kept our descriptive partnumbers, and we increased the overhead (as said many info carried per the descriptive partnumber which is very often generated manually and therefore can have mistake, contain info managed automatically per the system), so the 2nd division agreed to move to sequential numbers and they are fine with it. They understood they needed to adopt new working practices to make the most of the new system.

Hope this helps

Best regards

[MikeLockwood]

Very well written.
thanks

[HugoHermans]

I like it as well, but how to convince management that this point-of-view is not (too much) biased? After all, we are all super-experts and ditto enthusiasts in PLM, and try to make our way into a ERP dominated world.

Until now, I found these arguments:

- focus on business processes (see NacNac)

- PLM focuses on the flow of information around the product, ERP focuses on the flow of material

- heartbeat, or PLM is a more nervous then a ERP environment.

But ... I wasn't too successful yet ... maybe I need more/better ammunition ...

Best Regards,

Hugo.

From: Lockwood,Mike,IRVINE,R&D [

[mlocascio]

Load up...load up..load up the rubber bullets