|
|||||||||||||||||||||||||||
|
June 30, 2008
CAD Migration – The “Killer App”?Please note that contributed articles, blog entries, and comments posted on MCADcafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
CAD Migration was a main focus topic at this year’s Collaboration & Interoperability Conference. In fact, it’s a subject of intense conversation and debate everywhere in manufacturing these days. It just may be the killer application, but not in the way we’re accustomed. It’s killing budgets, it’s killing lean initiatives… it’s killing productivity. Over the last 20 years, 3D has emerged as a powerful product development tool. And it has led to a huge proliferation of new technologies, applications – and an explosion of product data! Industry consolidation further complicates the problem, as each new company bought or sold brings another data mine and toolset. There are about 3 Tb of data and 1 million parts in a ship. The F35 aircraft consists of 1.5 Tb of CATIA V4 data in 200K unique drawings. In all, almost 40 Tb of data were migrated last year (creating a $5.5 Bn market for about 150 service providers worldwide). And much of this data must move forward
with business. Globalization, competitive pressure time to market pressure, and the need to leverage and reuse existing product are all driving the need to migrate product data. So what can you do to maximize your future potential to remain flexible in today’s ever changing, unpredictable environment? Formulate a strategy, then develop, standardize and execute a migration methodology. Start by characterizing your data. What types? How much? This is very complex job, because some data are easy to migrate and other, well, impossible. Do you need to migrate feature data? Do you need 100% of your feature data? These questions are the subject of whole white papers, but consider the following… collaborative design is usually accomplished by designers working on equal terms with all the data they can get their hands on. It can easily be crippled (translation: cost a lot more!) by a lack of design information like features. Manufacturing engineers and analysts, on the other hand, often remove many of the design features and create their own representations. In short, some stakeholders need more design features than others and you can never
predict in a complex design and supply chain. The common denominator is fully featured models. So rather than maintaining multiple representations and incurring the cost and complexity in your version management system, your best bet is to make full-featured models available to any trusted partner who wants them, and provide a good, multi-tiered security mechanism so your data doesn’t end up places it’s not supposed to. And if you need 100% of your feature data, manual re-mastering is rarely a good strategy. There are good tools out there that consistently deliver 75% to 85% of your feature data, and leave you with very clear information about what didn’t migrate correctly, along with tools to help complete the task. Any manual process introduces errors. It is also extremely important to consider how you will validate your data after it’s migrated. If you re-master, who will be there to assure your users and suppliers that the data is correct? How will you know, weeks or months later in some downstream supplier, what was
changed or introduced into your data. With a software-based solution, you have good tools to validate your results and maintain change logs. At the least, you have a known situation. What about embedded product knowledge? Not just features and PMI data. What about macros, spreadsheets, embedded relationships like parametrics, evaluators and other accessory data? And what about other applications that were custom built in CAD languages like UGS GRIP? Part associations tell you how a product was built, and are often are maintained in EBOM, MBOMs and PDM systems. All this data is critical to future total usefulness of the data, and all must be considered for migration. Consider future uses of the data. Who will use it? For what? Why? Designers usually want all the product knowledge they can get, but manufacturers often don’t. Consider how you will validate the results of a migration. How do you know the results match the original data, and who is responsible for changes? There is huge risk and cost of problems appearing downstream, later. How much automation of migration is necessary and possible? Some migrations are custom projects, and other can be automated. If you choose custom services, remember the need to validate results. What to do with data that did not migrate? How do you find data that didn’t migrate? Excellent software tools exist to help guide the completion process. For each general class of data migrated, determine a best approach. Define your methodology and assess potential low and high ranges of potential cost. Get executive support. Define success in advance and build budgets around these goals. Then you have a plan. Data migration is complex and difficult, but achievable. Many projects have proven that success, as usual, will depend foremost on planning and preparation, and then on good old execution. By David Prawel David Prawel is founder, president and principal consultant at Longview Advisors Inc. David has enjoyed a 25 year career in the manufacturing software business, during which he has developed rich, hands-on experience in all aspects of the business and a keen insight into the manufacturing software industry and its constituents. CONTACT: Westlake Business Park 4420 North Monroe Avenue Loveland, CO USA 80538 Phone: 970.667.9232
Microsoft Deploys IBM iDataPlex in High Performance Computing Labs
Hexagon Acquires Machine Tool Probe Manufacturer in Germany
BCP Engineers Bring Dassault Systèmes’ DELMIA Software to Xcel Energy’s Monticello Nuclear Plant
You can find the full MCADCafe event calendar here. To read more news, click here. -- David Prawel, MCADCafe.com Contributing Editor.
|
|
||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
October 09, 2008
October 09, 2008
