September 5, 2011 04:07:37
Posted By Christine Longwell
Have you ever noticed that when it actually comes time to migrate your CAD data, you wake up one morning all alone? On one hand, it’s your data. You made it. You allowed it to grow organically into the amorphous amoeba, or set of amoebas, it has become. The structure, integrity, and complexity of the data set is a direct result of a company’s historical design process. This is always the wildcard in the time, complexity, and cost if a successful integration. Realistically, asking a PLM vendor to tell you if your data is a mess is like asking a hospital photographer if your baby is ugly. Unfortunately it is their place to point out inconsistencies, poor practices, and lapses in data discipline. These data disciplines may not have even made strategic sense until you have gone to the precipice of “implementing a system”.
A realistic data migration plan requires a team effort. It needs experts in the actual data as well as independent data experts that know how this type of information is handled in the target system. Given a certain number of records, and qualifying and quantifying those errors will lead to a realistic action plan for sterilizing the data before it is fed to your new system. No matter how sweet that mountain stream looks, it’s still a good idea to use a trusted filtration system...
A good, lightweight version of one of these audits can be found from Razorleaf…
On the other hand, even with the best migration plan, you will never realize exactly what you have stepped into until you’re knee deep. This is where pilot projects, development environments, and staged deployments are crucial. As a general rule, product development cannot stop to accommodate data cleaning and, this is a great opportunity to leverage vendors.
A few ideas I have to continue this thought in the future are:
· Fix it up front, or just load the crap?
· Who is going to use this stuff anyway?
· Establishing a Realistic Data Migration Plan
· What’s in a name? “Files” vs. “Items”
· Data structures… “one of these things is not like the other one”