In the Pulitzer-Prize winning book Grapes of Wrath, author John Steinbeck chronicles the heart-wrenching struggles of a family of farmers that migrates from the wasteland of an Oklahoma dust bowl to California in hopes of a brighter future. Likewise, many companies that have endured painful struggles and hardships of spreadsheets to manage product data realize they must eventually migrate to a modern product lifecycle management (PLM) solution; however, unlike the brutal migration described in the Grapes of Wrath, the migration of your PLM data, which admittedly can be high risk and high reward, can be easy to achieve if you follow best practices.
In last week’s blog post, we focused on identifying and gathering the data you need to migrate to your new PLM system. Now with your data “in hand”, it’s time to set up your PLM system to import and store that data in the most useful and efficient manner.
To do this, you will need to ask yourself several questions:
1. What fields in my existing data do I need in my PLM system and which fields can I ignore?
Review all the data types you have to migrate, e.g. item master, bill of materials (BOM), sourcing data, etc. Identify which fields are important to migrate to PLM. This is a good time for “housekeeping”. If there are fields that are no longer useful, leave them off the list. Depending on where the data currently resides, like ERP, there may be fields that are only useful to that system, and NOT useful in PLM.
2. Does my PLM system have standard, “out of the box” fields to support all the data I want to migrate?
For this data mapping exercise, you will need to be familiar with the data model of your PLM system. For the fields identified in #1, identify the standard PLM fields they should populate. Some common examples of standard fields are:
3. If I don’t have standard fields, what additional “custom” fields do I need to set up in my PLM?
When you finish mapping your standard data field set, you will have some existing data fields that don’t currently have a good “home” in your PLM system. For these, your PLM system should allow you to create custom fields. Document the additional fields you need, along with its other features, such as field type (text, number, list, etc.), default value, and field requirements (does it need to be populated?).
4. How should I categorize and define item data in PLM?
Your PLM system should have a feature to set Item and File “categories” for data. Examples are Resistor, Fastener, Fabricated Metal, Subassembly, Finished Good, etc. Categories in PLM allow you to search for specific types of data, control which custom fields appear, drive auto Item numbering, and may also be used by computer-aided design (CAD) and enterprise resource planning (ERP) integrations.
You may already have an inferred category scheme in your existing data by how you assigned Item Numbers. It may be documented in a company procedure. Regardless, this is the time to formally document the scheme you want in PLM and configure it there. You will need to have the category “assigned” to each Item and File in your existing data before it can be imported to Arena PLM. This may be done by adding an additional column in your data spreadsheets, for example, and populate it as appropriate.
Ta-dah. Follow the aforementioned steps and you can be assured of smooth and correct migration of your PLM data. Thanks to the amazing Arena Solutions Consultant Mike Sullivan for his help in putting together data migration best practice tips for this blog post. Also, readers please feel free to share your own implementation experiences in the comments below.
As promised last week, here’s a joke: Why was the baby strawberry crying?
Because his mother was in a jam.
Be sure to subscribe to our blog in the right column for more great jokes, along with PLM & QMS content.