The amount of data around us is growing. The same applies to engineering and manufacturing companies. Our ability to collect data is astonishing. But we are failing to bring the right data in the right form and at the right time to people. Product lifecycle management software is often recognized as a glue that should bring information about product and its lifecycle to everyone in a company.
Here is the thing – legacy data import is one of the most painful projects in PLM implementations. Few years ago, I came with a blog post – Who will take on legacy data in PLM? Guess what? Not many candidates in the list… Typical PLM implementation project is trying to allocate time to import existing data, but usually it is done as customization project by service organization and always requires additional resources.
Zero Wait State blog – The PLM State: Drain Your Data Swamp speaks exactly about the problem with existing data in organization. I like "swamp" metaphor, because it is really looks like a swamp. Think about legacy databases, tons of Excel files, existing PDM and PLM systems. What else? Emails, SharePoint website, wikis and many others…
The following passage from the article is a great value proposition for creating a system that will make existing data usable.
Data that isn’t used is data that isn’t profitable. All data should add value, whether by contributing to strategic decisions, marketing, process improvements, or regulations (data kept due to regulatory retention policies adds value by allowing your business to operate in a regulated environment). You paid for, and are paying for it already, so why wouldn’t you put that data to use?
But how do you drain a data swamp? The first step is to identify what data is likely to have been swamped. Identifying misplaced or forgotten data would seem like an insurmountable task, but look to those processes in your organization that generate data. I’m not talking about just test data or formal analyses, but all the data. That RoHS-compliant capacitor? That’s a data point. Device master records (DMR) and device history records (DHR) are obvious datasets. That prototype from CAD cost a lot to develop, so include that data where it can be leveraged for other designs rather than being ignored after its initial use.
Enterprise resource planning (ERP), project lifecycle management (PLM), laboratory information management system (LIMS), document management system (DMS) software and others can play a role in draining your data swamp, associating and linking disparate datasets and providing a means for their use.
Unfortunately, I see a very little progress with a process of drying data swamps by PLM systems. It made me think about reasons why is it hard to do. Here are 3 reasons why existing PLM platforms cannot do so.
1- Limited data modeling. Although all PLM systems have some kind of "flexible data modeling" capabilities, it is a lot of work to get data modeling done for all legacy data. Just think about converting all existing data structures into some sort of data models in existing PLM systems. It can be lifelong manual project.
2- Limited flexibility of relational databases. Majority of PLM architectures are built on top of relational databases, which provides almost no ways to bring unstructured or semi-structured data such as emails, PDF content, Excel spreadsheets, etc.
3- Absence of data transformation and classification tools. Existing PLM platforms have no tools that can allow you re-structure or re-model data after it is already imported into the system. Think about importing data and "massaging" it afterwards.
What is my conclusion? Companies are failing to bring existing data into PLM system because it is hard. Although, PLM vision is to provide a glue between variety of product information sources, in practice, it is very complex and expensive to achieve. Typical company is operating with number of siloed applications developed by different people and implemented to solve specific situational problems. It leaves holistic approach in product data management outside of scope in most of PLM implementations. Just my thoughts…
Image courtesy of jscreationzs at FreeDigitalPhotos.net