Best Practice to remediate parts with different suffix in Agile PLM.

We receive parts in Agile PLM from different PDM/ERP system and they are suffixed with that system name. 
For example : 11234-PM , 11234-GLP, 11234-PROD 

Each parts are having different set of information ( Change Orders , Affected item , Cover Page). 

Now user wants to remove all the parts suffixed with system name and keep one part as master data . 

Could you please suggest what are the possible solutions for this.

Add Comment
3 Answer(s)

So Malaku, as I understand you have, in this example, three source records, each likely containing different metadata and attachments.  And you want to compress all the information into a single record.  Is this a one time occurrence (or are all source systems connected to the said Agile instance)?  Do the multiple records already exist in the Agile PLM app?  Do they need to segregate the data i.e. attachment folder for PM, another for GLP and a third for PROD in the event all three have different attachments?  Please elaborate on this business process so we can understand if it is abnormal or needs to be a standard process.

Agile Angel Answered on October 1, 2018.

Thanks Patrick for your response . 
Please see my comment below. 

Is this a one time occurrence (or are all source systems connected to the said Agile instance)?  We still receive duplicate parts from different systems and we are working to remove the code which creates parts with system suffix name , which will solve the problem for future parts. 

Do the multiple records already exist in the Agile PLM app?  Yes we need solution for existing parts. How can we do this with little effort . 

Do they need to segregate the data i.e. attachment folder for PM, another for GLP and a third for PROD in the event all three have different attachments? Attachment segregation is not needed but we need to import the BOMs and Change datas.

Business Process:

Agile system was built to receive parts from different systems let’s say PDM and ERP . We receive medical device related details from PDM and finance details from ERP system . To allow these information to flow in Agile ,  team have used the suffix logic to differentiate between the parts from different system we receive . Now this has created the problem is system as the part number with suffix is not understandable to supplier with actual part number . To solve this we need to clean system for all parts which are suffixed and create a master record for each part . 

on October 3, 2018.
Add Comment

You would have 2 distinct solutions, one for existing parts and one for new parts. Unless you want to run the solution to “fix” existing parts every week or so (NOT recommended).

 The solution to fix existing parts would be to have a program or script create a new part record (no suffix), and then take data from existing records and copy or move it to the new part record. Not very simple, but doable. And probably lots of logic to decide whether something should move or not, given that there are very likely to be overlaps in what each part has. So the programmer will need to know precedence for how to resolve issues.

 The solution for new parts would be to have the integrations between the PDM/ERP systems and Agile not add a suffix to the part number, and always check to see if it exists in Agile first. If it is already there, add data as needed. Otherwise create the part and then add the data that you have. 

 Neither solution will be easy, and each could be rather difficult, depending on what your business rules are for getting the data into Agile and which system has precedence in terms of the data. And there are no easy nor hard-and-fast rules for what needs to be done. A lot of it depends on your business rules for how things should be handled. Start there, and then ask the question again, providing those business rules so we have an idea what needs to be done.

Agile Angel Answered on October 1, 2018.

Thanks kevin for your response. 
Yes i am looking for solution to fix the existing parts . Regarding the solution to take data from existing record and copy to nee one . How can we copy the BOMs changes with revisions and Change Orders data .

on October 3, 2018.

You cannot do this through the application. As in, you cannot assign a part to a change that has already been released using the SDK or in the application itself. It cannot be done, except at the database level.  But unless you know what you are doing, it will get messy very fast. And you might corrupt your database. Any solution would require full testing on a non-production environment before doing anything to the production database.
  You must have clear rules of what gets moved and what does not, and which system has precedence over the others in terms of the things to be moved (attribubtes, revs, changes, BOM, AML, attachments, history, etc.). And these rules must be put together by you and the business before you start doing anything else. You most likely do not want duplicates or other data issues to be in the data for the new part. So these rules have to account for what to do if 2 of the system parts both have BOM which is different, because you cannot simply merge them together as you might end up with duplicates and other data issues. Do the various “system” parts all share the same changes? Or do they sometimes have different changes that did the same thing? Or might one have a change from its system that is not in any of the others? If that happens and it is linked to BOM data, you could very well have problems integrating it with everything else.
 You first have to assign the new part to the change(s)/revision(s) from each of the “system” parts, and then move the BOM (or AML, or attachments) that relates to those changes/revisions to the new part. There are a LOT of things to be done inside the database here, and all involve changing ID values, and not just item number text values. And as such, there is a LOT that can go wrong.

 Bottom line, I strongly suspect you are going to need help.  First and foremost, is the business able to handle keeping the old parts the way they are (for historical purposes only) and move forward using the new integrations? If so, then you are done – update the integrations and move on. And eventually the old system parts can be deleted and therefore removed.
 If not, then I can assist in letting you know what needs to be changed in the database, but the rules for deciding what needs to be done (and what does not) must be known first, especially for the BOM data. Simply moving BOM records over from multiple source parts would create a VERY confusing BOM tab for the destination part, even allowing for combining revisions from the various systems.

on October 7, 2018.
Add Comment

Hi Malaku,

I’m not sure how many degrees of freedom you have to solve your puzzle, but I’d like to suggest you to think about in the possibility to redesign the item creation process. What I mean is, instead of all items converge to Agile, I´d build a process to create items in PLM and than spread these items to all the systems those need these records. Agile is flexible enough to you create all the attributes need and also build ECO to handle all the steps needed to create a acceptable items to all the legacy systems.
My best

Agile Angel Answered on October 2, 2018.

Thanks Carlos for your response . 
Yes we know how to stop the future part creation with this suffix logic , but i was looking for a solution for existing part which already is in system with different suffix name .

on October 3, 2018.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.