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

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

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