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.
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.
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.
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.