What I learned as a follow up to my report on Product Data Accessibility is that there is a lot more angst about finding product data than I ever realized. I was amazed at the discussion generated by my blog post about accessing all product data regardless of how it is stored. In particular, there as a lot of PDA discussion on LinkedIn. For those that can’t access it (I was told you have to join the group) I decided to share some of what I learned from it here.
What I Learned
One of the key findings of the report was that “accessing product data and centralizing it are not absolutely linked.” That really seems to resonate with people. One person I spoke with (Skype, not in the LinkedIn thread or my comments) reiterated that point, saying that “you need control, but regardless of where you are with that you have to be able to find data.” That brings up some interesting thoughts about PDM. My report on the business value of Product Data Management highlights controlling/securing data, 
finding/reusing data, and sharing data as primary benefits of PDM. There is clearly overlap in finding/reusing data between PDM and PDA. My view is that PDM and PDA are complementary solutions, and the discussion seems to indicate that there is no requirement to have one in place before the other, either can help regardless of whether the other is in place. One example brought up in the LinkedIn group is how useful search can be after an acquisition, and not having to wait for systems to be migrated. This need (and opportunity) was echoed by others.
Time for a Maturity Model?
I have seen maturity models for PDM and PLM (among others), but given a lot of the comments and the research for the report about the need for product data accessibility I thought I would take a stab at a few levels of accessibility:
- The Wild, Wild West – No formal accessibility strategy. From the discussions I have had, this is very common. Searching on document names and looking for things where they are “supposed to be.”
- Basic Search – Ability to search for information in known locations based on known parameters, perhaps with some full text search thrown in.
- Advanced Search – A formal strategy based on an index, most likely including helpful capabilities like saved and shared searches. One comment mentioned Zakta.com that offers guides for searches, although I am not familiar with the solution (but I guess I should be). I am feeling a matrix might be applicable here, though, because there are different approaches that include text, attributes, metadata, or shape (like what ShapeSpace or Siemens PLM’s Geolus solution offers), and I am sure others.
- Access and Aggregate – Accessing disparate data and pulling it together to get a more full view of the product. Perhaps this is two levels, depending on the intelligence behind the aggregation, or maybe there is another matrix forming here. For example, using semantics to intelligently discover relationships like Inforbix does is more powerful than simply aggregating on part numbers.
- Search Based Applications – Accessing, aggregating, and acting on product data. This would include Search based applications (SBA) such as Dassault Systemes’ Exelead (focused more broadly products) and Inforbix xApps. Perhaps another capability that belongs here (or another level?) is the ability to develop composite applications that can both access and update underlying data? Or maybe that belongs somewhere else, not sure.
Implications for Manufacturers
I am not suggesting that the above is ready for prime time, it needs some work in order to really be robust. And no maturity model should really include a level called “the Wild, Wild West.” 🙂 But I hope it serves as a way to get people thinking about the different ways companies can access, aggregate, and use their product data to drive more business value.
I don’t see this as a replacement for centralizing and controlling product data. One commenter even mentioned it would be nice to link data to workflows. That starts to sound like PDM and PLM to me. In fact, I think we will see incorporation of these capabilities in PLM, as well as offer independently. The value is clear, and there are options to pursue, so it’s time to take a look.
So those are some thoughts on product data accessibility, I hope you found it interesting. Who knew? I didn’t, if you did let us know about it. Another good resource on the topic is the Inforbix product data space blog. For full disclosure, Inforbix is a client, but they didn’t ask for this mention and I bring it up because Oleg has really taken the time to explore this issue and communicate about it. Let me know what you think.
The added complication in the world of outsourcing is, where, oh where, is that data? Think about the supply chain that Boeing has set up for the 787 Dreamliner, and the problems that that has caused, or the recently discovered proliferation of counterfeit parts in DoD equipment. No wonder there is angst!
Rick, I understand your point about outsourcing leading to a proliferation of data. There is also the issue in a complex supply chain like Boeing’s as to who really owns the IP because the suppliers are not just manufacturing, they are engineering solutions. I think cloud solutions offer the ability to separate whose data center the data is in and let various people collaborate, but then who owns the data is a business (and legal) concern.
I am not sure I see the tie to obsolete parts. From what I heard from the recent congressional hearing the biggest culprit is actually electronic waste (old computers, monitors, etc.) being illegally re-purposed (breaking down boards, taking the chips, and relabeling them). Does outsourcing further complicate it?
Thanks!
The added complication in the world of outsourcing is, where, oh where, is that data? Think about the supply chain that Boeing has set up for the 787 Dreamliner, and the problems that that has caused, or the recently discovered proliferation of counterfeit parts in DoD equipment. No wonder there is angst!
Rick, I understand your point about outsourcing leading to a proliferation of data. There is also the issue in a complex supply chain like Boeing’s as to who really owns the IP because the suppliers are not just manufacturing, they are engineering solutions. I think cloud solutions offer the ability to separate whose data center the data is in and let various people collaborate, but then who owns the data is a business (and legal) concern.
I am not sure I see the tie to obsolete parts. From what I heard from the recent congressional hearing the biggest culprit is actually electronic waste (old computers, monitors, etc.) being illegally re-purposed (breaking down boards, taking the chips, and relabeling them). Does outsourcing further complicate it?
Thanks!
Jim, it’s great you got this conversation started.
The range of replies, I think, demonstrates that there are numerous tasks out there where the lack of appropriate tools to access and retrieve product data inhibits good decisions and process improvement – not just in engineering, but also (perhaps more so) in ‘out-of-engineering’ functions.
The key observation is “accessing product data and centralizing it are not absolutely linked.” The ‘management’ bit of PDM or PLM is vital in many instances (but not all), however it tends to be ‘heavy’ to set up and run. Indeed it may not be immediately possible as in the acquisition example. Once we recognise that product data access and retrieval is separate (though complementary) to product data ‘management, then we can look for new technologies, most likely from other domains such as the web or semantic search, to solve these problems.
What those technologies are, and what the use-case sweet spots are, is up in the air at the moment. That’s what has made this discussion so interesting…
Drew,
I do think it makes sense to think about managing data and retrieving it separately. In an ideal world, there would be a single, integrated solution that does both equally well. And perhaps those that didn’t need to invest in the level of control that PDM can offer could focus on what they do need without the overhead of the rest. Today, however, the discussion clearly shows that product data accessibility is a big issue that is slowing companies down and making them inefficient. It looks like in the short term 3rd party data accessibility solutions (like ShapeSpace) will be a necessary element of a product data strategy.
Thanks for sharing.
Jim, it’s great you got this conversation started.
The range of replies, I think, demonstrates that there are numerous tasks out there where the lack of appropriate tools to access and retrieve product data inhibits good decisions and process improvement – not just in engineering, but also (perhaps more so) in ‘out-of-engineering’ functions.
The key observation is “accessing product data and centralizing it are not absolutely linked.” The ‘management’ bit of PDM or PLM is vital in many instances (but not all), however it tends to be ‘heavy’ to set up and run. Indeed it may not be immediately possible as in the acquisition example. Once we recognise that product data access and retrieval is separate (though complementary) to product data ‘management, then we can look for new technologies, most likely from other domains such as the web or semantic search, to solve these problems.
What those technologies are, and what the use-case sweet spots are, is up in the air at the moment. That’s what has made this discussion so interesting…
Drew,
I do think it makes sense to think about managing data and retrieving it separately. In an ideal world, there would be a single, integrated solution that does both equally well. And perhaps those that didn’t need to invest in the level of control that PDM can offer could focus on what they do need without the overhead of the rest. Today, however, the discussion clearly shows that product data accessibility is a big issue that is slowing companies down and making them inefficient. It looks like in the short term 3rd party data accessibility solutions (like ShapeSpace) will be a necessary element of a product data strategy.
Thanks for sharing.
Great start to a maturity model.
I think shape based searches are at a different level from basic and advanced searches. Geolus for example promotes reuse and classification of parts which have a similar shape.
I would consider level 2 as keyword based searches which includes both basic and advanced capabilities.
Thanks for the thought Datia (or do you go by Srini?),
What would you consider basic and advanced keyword searches? Would you break that by the ability to save and share searches? Or the ability to do compound searching? Guided search? As I think more about this, the model probably has a few more sub-levels than I may have initially thought.
Thanks for your feedback!
Great start to a maturity model.
I think shape based searches are at a different level from basic and advanced searches. Geolus for example promotes reuse and classification of parts which have a similar shape.
I would consider level 2 as keyword based searches which includes both basic and advanced capabilities.
Thanks for the thought Datia (or do you go by Srini?),
What would you consider basic and advanced keyword searches? Would you break that by the ability to save and share searches? Or the ability to do compound searching? Guided search? As I think more about this, the model probably has a few more sub-levels than I may have initially thought.
Thanks for your feedback!
Jim, Your Maturity Model is a step in the right direction to better understanding of Search Based Applications. We must be clear that an SBA is not PDM or PLM. There may be some confusion here. However, they certainly play in the PDM/PLM spaces, particularly when it comes to ready accessibility of product data. Generally speaking, PLM systems offer good search alternatives, but, they depend on properly structured and consistent data formats and they can only search within their own system.
Anything less than systems that meet the SBA criteria are undesirable and uneconomic, including systems that require re-purposing of data in some manner. Therefore, one criterion would be ability to forego the expense of re-purposing data into new structures.
Eventually, the Gartner Hype Cycle may come into play as a frame of reference regarding maturity. Unlike experiences with ERP and PLM, I predict (fearlessly, of course) that SBAs will not suffer the over-hyping, disillusionment and maturity that defines the Hype Cycle. It’s fair to say, nevertheless, that we need more definition of the criteria for SBAs.
In your SBA criteria, some alternatives are identified; others are gaining recognition and should be identified in the interest of fairness, for example, Alcove9 (www.alcove9.com).
I hope you will continue development of the Maturity Model and expand your report “Issue in Focus: Product Data Accessibility.”
Jim, Your Maturity Model is a step in the right direction to better understanding of Search Based Applications. We must be clear that an SBA is not PDM or PLM. There may be some confusion here. However, they certainly play in the PDM/PLM spaces, particularly when it comes to ready accessibility of product data. Generally speaking, PLM systems offer good search alternatives, but, they depend on properly structured and consistent data formats and they can only search within their own system.
Anything less than systems that meet the SBA criteria are undesirable and uneconomic, including systems that require re-purposing of data in some manner. Therefore, one criterion would be ability to forego the expense of re-purposing data into new structures.
Eventually, the Gartner Hype Cycle may come into play as a frame of reference regarding maturity. Unlike experiences with ERP and PLM, I predict (fearlessly, of course) that SBAs will not suffer the over-hyping, disillusionment and maturity that defines the Hype Cycle. It’s fair to say, nevertheless, that we need more definition of the criteria for SBAs.
In your SBA criteria, some alternatives are identified; others are gaining recognition and should be identified in the interest of fairness, for example, Alcove9 (www.alcove9.com).
I hope you will continue development of the Maturity Model and expand your report “Issue in Focus: Product Data Accessibility.”
Coming from engineering I do see the a linkage between PDA and PLM/PDM, because the data is required in the context of getting your work done and it exists in many places in separate systems some structured some not. The data retrieval criteria for PDA in my opinion is a direct function of the process context. If your doing an engineering change then the search criteria is different than looking for concept during the concept phase. I think its going to evolve PLM/PDM, the standard process brings with it efficiency, consistency and good data retrieval adds even more efficiency and clarity because people can find what they need when they need it to make better decisions. This is a really good discussion and I look forward to seeing how this all evolves.
Thanks for weighing in on this David. I guess one of the criteria that you could use for determining whether a tool like this should be part of an application like PLM is whether it only acts on the data in that application. Your point about a concept design is great. How many times is that actually in PLM? Or how often do we need bits of information that are in ERP, or even in a spreadsheet somewhere? Or how often do people work in multiple PDMs?
PDA (or Search-Based Applications, SBA, as it is being called in a large LinkedIn conversation I am in) needs to have broader access than PDM/PLM. Of course that doesn’t mean it can’t come from a PLM vendor, but the value-add coming from the vendor is when it is tightly integrated into their own data model.
Thanks for commenting.
Jim yes I agree very much that SBA/PDA must be broader than just the data in the PDM/PLM and IF the suppliers get that point (Open vs Closed) then the industry will evolve. Its critical we farm the non-structured data and be able to quickly narrow down that data in the context of a process. SBA will really add value to the process if we can accomplish an advanced search function and then feed the PLM Engineering Change Process GUI as an example. This is much easier said than done…. but that was a point I was making.
David,
I totally agree with you about search and feeding the right information into processes. That brings up the next level of integration – composite applications.
Now, once we have all of the data from different places and pull it into a common place to act on it – how do the actions get executed? For example if I have an ECO that impacts the design and inventory, I probably need to update PLM and ERP. What you suggest not only pulls the data together, but pulls the process together. Just the data would be nice for most people, but integrating processes with the data is a big value.
The next step (in my ideal world) would be that the ECO GUI is a composite application that could not only take the information and allow someone to make a decision, but also make the updates in one place and have those updated in the respective systems. Of course you could integrate the PLM ECO process to ERP – but the PLM ECO process typically doesn’t have enough information on what to do with inventory, open orders, and all of the execution-oriented things ERP (and possibly MES in some environments) address.
But to be honest, if we can find a way to let people access all of their data it would be a huge step all by itself.
Thanks, I appreciate your perspective on this.
Coming from engineering I do see the a linkage between PDA and PLM/PDM, because the data is required in the context of getting your work done and it exists in many places in separate systems some structured some not. The data retrieval criteria for PDA in my opinion is a direct function of the process context. If your doing an engineering change then the search criteria is different than looking for concept during the concept phase. I think its going to evolve PLM/PDM, the standard process brings with it efficiency, consistency and good data retrieval adds even more efficiency and clarity because people can find what they need when they need it to make better decisions. This is a really good discussion and I look forward to seeing how this all evolves.
Thanks for weighing in on this David. I guess one of the criteria that you could use for determining whether a tool like this should be part of an application like PLM is whether it only acts on the data in that application. Your point about a concept design is great. How many times is that actually in PLM? Or how often do we need bits of information that are in ERP, or even in a spreadsheet somewhere? Or how often do people work in multiple PDMs?
PDA (or Search-Based Applications, SBA, as it is being called in a large LinkedIn conversation I am in) needs to have broader access than PDM/PLM. Of course that doesn’t mean it can’t come from a PLM vendor, but the value-add coming from the vendor is when it is tightly integrated into their own data model.
Thanks for commenting.
Jim yes I agree very much that SBA/PDA must be broader than just the data in the PDM/PLM and IF the suppliers get that point (Open vs Closed) then the industry will evolve. Its critical we farm the non-structured data and be able to quickly narrow down that data in the context of a process. SBA will really add value to the process if we can accomplish an advanced search function and then feed the PLM Engineering Change Process GUI as an example. This is much easier said than done…. but that was a point I was making.
David,
I totally agree with you about search and feeding the right information into processes. That brings up the next level of integration – composite applications.
Now, once we have all of the data from different places and pull it into a common place to act on it – how do the actions get executed? For example if I have an ECO that impacts the design and inventory, I probably need to update PLM and ERP. What you suggest not only pulls the data together, but pulls the process together. Just the data would be nice for most people, but integrating processes with the data is a big value.
The next step (in my ideal world) would be that the ECO GUI is a composite application that could not only take the information and allow someone to make a decision, but also make the updates in one place and have those updated in the respective systems. Of course you could integrate the PLM ECO process to ERP – but the PLM ECO process typically doesn’t have enough information on what to do with inventory, open orders, and all of the execution-oriented things ERP (and possibly MES in some environments) address.
But to be honest, if we can find a way to let people access all of their data it would be a huge step all by itself.
Thanks, I appreciate your perspective on this.