You’ve just purchased a product lifecycle management (PLM) system or are planning to in the near future. One of your primary goals will be to migrate your existing product data into your new PLM system.
Arena’s cloud-based PLM solution is so easy to implement that many customers choose to implement the system themselves. No joke. If you don’t believe me, I’ll tell you a joke later so you can tell the difference.
One of the first steps in any PLM implementation is the art and science of migrating your existing product data into your new PLM solution; however, depending on the status and location of your current data — the migration of your data can be one of the biggest challenges to having PLM up and running. In this two-part blog series, we provide an intelligent step-by-step guide for smooth and smart migration of your data. Here goes:
Step 1 is to determine the scope of the data migration. This means two things:
1. What types of data to you want to migrate to PLM? This typically includes the following:
1. Item Master, which may include:
- Electrical parts
- Mechanical parts
- Finished goods
2. Bill of Materials (BOMs), which may include:
- PCB assemblies
- Mechanical, product, top-level assemblies
3. Item Sourcing, which may include:
- Item Manufacturer and Manufacturer part number (who makes the Item)
- Item Vendor and Vendor part number (who the Item is purchased from)
4. Supporting files, which may include:
- CAD files
- PCB build packages
5. Item Quotes and Costs
- Cost, minimum order quantity (MOQ), lead time, etc.
6. Supplier details, which may include:
- Contact names/emails
- Phone numbers
2. What products or projects will have their data migrated to PLM in the first phase?
Typically, the answer to this depends on the size of your company, how many products you have, and whether you will roll out PLM to everyone at once, or in phases. It is also possible you could have older products you no longer sell or support, and choose not to migrate that data to PLM.
If you plan to only migrate certain products to start, you will need to determine how you will separate out the product data for only those products.
Step 2 is to locate where all your current product data resides and determine the best way to gather or extract it. Here are some examples:
- ERP: If you have an enterprise resource planning (ERP) system, then your item master, BOMs, sourcing, and possibly costs may reside there. If your ERP only manages finished goods or SKUs, then you will also need to find the product details (BOMs and component items) elsewhere.
- Custom database: Your company may have developed a custom database application using, for example, Microsoft Access, to manage much of the data. Determine what product information resides there.
- Spreadsheets: The data could be managed in spreadsheets. This is most typical for BOMs. In this case, sourcing information is most likely included in the BOM rows. You may also have separate spreadsheets to manage your item master. It’s possible that sourcing and cost data could reside there.
- Supporting files: These are almost always found in network folders. The key will be how well organized they are and their naming convention. If you reference the file paths in one of the other systems above, that will help. Otherwise you’ll need to rely on that organization and naming to determine what files go with what items.
- Partners or Suppliers: You may have depended on design partners or contract manufacturers to manage your detailed product data. In this case you will need to request a copy of the data from them.
Step 3 is data gathering or extraction. This will be dependent on the system or location where the data currently resides.
- If the data resides in either your ERP system or a custom database, you will need to have someone with the expertise in extracting data from that system help.
- If the data resides in spreadsheets, it is just a matter of gathering the files that contain the data you want to migrate.
- If the data resides with a partner or supplier, you’ll need to contact them to get a copy of what you need.
Follow the aforementioned steps and you’ll be reassured of a quick and successful migration of your PLM data into a new PLM system. Tune in next week to discover best practices for setting up your PLM solution to best manage your existing data. And I promise to tell you a joke, too.