Why PLM should friend Chief Data Officer?

October 23, 2013


Technology space is good about inventing new jobs, titles and responsibilities. Until now, we knew about CEO, COO, CIO… The last one was a very important guy when it came to the decision point about enterprise software. PLM included. The dream of every PLM vendor and implementer was to get closer to CIO to influence company software strategies.

The explosive growth of data in companies influenced the creation of new jobs and new roles. Have you heard about "data scientist" job? If not, you better learn about it now. According to HBR, data scientist becomes the sexiest job of 21st century. I stumbled on an interesting write up from Guidware blogChief Data Officer vs. Chief Scientist Officer. Read the article and draw your opinion. What became clear to me – people are paying more attention on what happens with information in an organization these days. The following passage from the article is actually explaining it very well.

It’s good to finally see appropriate attention paid to the power of information across the insurance value chain, particularly in atypical areas and through non-traditional means. Though, there is still an opportunity for data capabilities to mature significantly across the industry.

You can tell me "insurance" examples may not apply to manufacturing. Actually, I can see it even more applicable in manufacturing companies. Think about outsource design and suppliers contracts. How many anomalies you can find there? What about strange usage of components, reducing the overall number of component parts, suppliers, ECO processing time and many others. The article brings an interesting list of responsibilities of Chief Data Officer. Some of them sounds very related to product development processes, product data management and PLM. Here is the list –

Oversees Data Management Office (DMO) and related shared services
Accountable for Data Governance
Defines data standards and policies
Manages standard business taxonomy and data dictionary
Provides common tools and platforms
Responsible for data quality monitoring and management
Drives prioritization, provides budget, and oversees execution for related business and technology initiatives
Oversees data audits and largely supports regulatory compliance requirements

It made me think that people responsible for product lifecycle management, product development processes are actually should be very much interested in this role and related opportunities. Since CDO could be responsible for overall data management services, it can be very much connected to how product data can be managed by multiple applications (PLM included). Topics like data audit and regulation can be even more connected to product development processes.

What is my conclusion? Companies are getting more and more data driven these days. The new roles of data scientists, chief data officers, etc. are just a confirmation that people put lot of focus on the value data can bring. The role of PLM is traditionally very focused on integration of data and processes across organization. This is where making good friendship between PLM and DMO make a lot of sense and potential to bring value. Just my thoughts…

Best, Oleg

The Complexity of Product Lifecycle and Google’s Blindspot

September 6, 2013

The power of search giants like Google is enormous these days. Think about the amount of information Google, Twitter and Facebook are processing and you will be knocked down by the numbers. Consumerization is a significant trend these days and everybody are thinking how we can apply well proven web and open source technologies in the enterprise field. Think about product designs, engineering documents, Bill of Materials – things that we commonly considering as product data. Eventually, the dream could be to see how Google’s engineers are recommending best parts to use or cracking Bill of Materials with 100s levels of data. Not so fast…

When it comes to a product data you can discover that this type of information processing is different from what we got to know on the web. It starts from the diminished importance of ranking mechanism based on other people discoveries. For example, if you happen to be searching for “Part CHI-93939-STD” it may not come up on the first pages of a search. But it may be found more directly via a connection to an existing assembly that references it. Data semantics in this case is more important than data ranking.

I recently came across the following study – Top Google Result Gets 36.4% of Clicks. Have a look at the charts, you’ll get my point quickly: if you are out of first five (5) page results, you essentially don’t exist. So if you’re “Lady Gaga”, you are certain to appear and ranked in the top pages. These days "social ranking" is adding some additional flavors to the overall search results. Nevertheless if you are “Part CHI-93939-STD”, then chances are, you don’t exist!

Another interesting blindspot of Google search – lifecycle data. Few days ago, I caught an interesting study – Filling a Search Engines Blindspots. Here is the passage describing lifecycle blindspot:

Today, Christian von der Weth and Manfred Hauswirth at the National University of Ireland in Galway identify one blind spot in Google’s coverage and describe their vision for how to fill it. This information blackspot consists of location-specific information that is only useful for people for short periods of time. An example would be a question such as whether an advertised bargain is still available at a particular shop. Another is to ask whether parking spaces are available at a public event such as an air show, music concert or such like. There is no way that a search engine like Google can index that kind of information that is specific to a particular location for just a short period of time.

What is my conclusion? Product data is extremely complex. It contains lots of relationships, dependencies and semantics. However, it is not everything. The most important element of product data is lifecycle information. Since product data is changing as a result of product development, use, maintenance, etc. systems need to be able to capture this product lifecycle data in a real time to provide a correct data representation for people in manufacturing companies and extended eco-system. It is not a trivial tasks and very interesting problem to crack. PLM software architects and other techies – be aware about complexity of product data lifecycle management. Just my thoughts…

Best, Oleg

PLM and Data Reuse Focus

May 24, 2013

Product data is one of my favorite topics. People in product development and manufacturing organizations are surrounded by digital data these days. The life 20 years ago was much easier. I remember the story about how people collaborated before CAD systems came to aerospace industry. Engineers were gathered in a single room, drawing boards were setup in the way similar to functional scheme of jet engine or aircraft. As a result of that, people were able to collaborate with their colleagues working on related parts and systems.

Fast forward to 21st century. The life is much more complicated. Engineering and product data are scattered among multiple systems and data sources. 3D models, drawings, CAE files, suppliers data, ERP systems, released archives, etc. Earlier this year, during PI Congress event in Berlin, I captured the following slide from Gartner’s presentation – Navigating the Shifting Product Design and Lifecycle Management Software Landscape made by Marc Halpern.

Scattered product data creates lots of complication in a manufacturing organizations. Gartner research speaks about 7 sources of mistakes in product data. The following two are specifically resonated to me – inaccurate data entry and incorrect data flow between applications. One of the ways to solve this problem is to foster data access and data reuse. It is still not unusual to see how people cut/paste or re-enter data between applications. Various point-to-point integrations create a mess in terms of ability of people (and systems) to use data located in other systems.

What is my conclusion? Data Reuse. This topic should be in a focus on people implementing engineering and manufacturing information systems. Variety of data management systems, PDM, PLM, ERP, CRM… All these systems should be focused on how to make data searchable, accessible and re-usable across the value chain. Just my thoughts…

Best, Oleg

Top 3 Reasons Why Data Sharing is Important for PLM

July 15, 2011

I want to talk today about data sharing. The interest of engineers and other people in manufacturing organization in data sharing is obvious. However, I think demand is much higher than available tools. It doesn’t mean there are no tools that can help you to share some elements or your 2D, 3D, Bill of Materials or other product data. At the same time, tools in the market are very vendor oriented and specialized to support different formats and applications.

What Tools Are Around?

The top question I had been asked many times when visiting customers – can you export data to Excell? The question is not simple, but very important. Customers are looking for ubiquitous tools that can help them to share any data. Excel is well understood. Almost every PDM/PLM tool supports some elements of data share. The complexity is probably another question. However, Excel is the kind. When it comes to 2D/3D, questions become more complicated – type of data, CAD system, purpose of share, precision, etc. – this is only a short list of questions.

I have no intent to provide a full list of data share or collaborative tools. Even so, I wanted to mention few last updates in this space. Few days ago, Autodesk made available their next product allowing instant and easy share of DWF files – Autodesk QuickShare (QS). Navigate your browser to the following links – It is alive in the Lab by Autodesk’s Scott Sheppard to read more details. You can try it on Windows, but as I understand, technologies (webgl) limiting to use 3D on Mac. Another project recently released by Dassault / SolidWorks is n!Fuze. This product is available on the cloud. However, if Autodesk has a strong focus on DWF format, n!Fuze is more focused on SolidWorks files (however, the tool is not supposed to limit usage of other files). To point of one of the tools that not belongs to top CAD/PLM vendors, I wanted to point on CadFaster. CadFaster provides product to collaborate, supports multiple CAD platforms and provides mobile applications as well. Navigate to the following link to see what CadFaster viewer can support.

Data Sharing and PLM Strategies

Here is my take on top three reasons why you need to invest in data – sharing tools and how it can be related to PLM strategy in your company.

1. Decision Making. This is probably the most important and easy thing. You need to have an access to the data in order to take decisions. Project review, Change request, Maintenance, Support Call, Design review, etc. – you better be able to have an access to your information.

2. Process Streamline. Your organization needs to work in a most efficient way. Which means – you need to focus on process and communication. The efficient communication and process organization is the must be here. If you have a tool to share data, you probably going to spend less time in communication.

3. Global development support. The time when all people in your organization were located in the same building is over. Now, people can be located everywhere globally. To have an easy access to the data from multiple places is another must requirement these days.

What is my conclusion? Even if it sounds simple, don’t underestimate the importance of data sharing. Like a lifeblood, data sharing can help you to work or die in a modern product development and manufacturing environment. What should be your choice? My take – the simpler solution is probably better. CAD/PDM/PLM world is full of complicated tools. Choose two factors – format support and simplicity as a first priority. The third one is probably system support. You cannot go wrong, with these three factors. Just my thoughts…

Best, Oleg

PLM Migration and Product Data Rock-n-Roll

December 29, 2010

I read The PLM State: PLM Migration, No Data Left Behind on Zero-Wait State blog. Read it and make your opinion. Stephen Porter is discussing a very important topic of data migration. I found it interesting. This is my favorite passage:

…leaving data behind is not necessarily a bad thing since it can corrupt and handicap your new system. Spending time up front to fully assess your information is time well spent. Segmenting data and moving it over in portions is a viable strategy for facilitating cleanup and assessment. Using the target PLM system as a filter and cleaning mechanism can be an effective way to manage migration.

The conclusion made by Stephen made me think about product data value and data migration problems.

Data Value

Most of the companies I have seen for the last year are dying in the ocean of product data. Company creates data every day. It comes out of the company design and engineering, manufacturing, support, sales, marketing and service. In my view, data is one of the biggest company assets. Companies are accumulating data for a very long period of time. In some industries, legacy data retention is part of the regulation rules and requirements.

Product Data Rock-n-Roll

According to the latest survey of Cyon Research, the majority of customers are dissatisfied with PDM software. Companies are looking how to improve the way to manage product data and thinking about how to optimize and consolidate PDM packages. Here is the quote from Cyon Research 2010 Survey of Engineering Software User:

Among the major classes of software, customers are most dissatisfied with their PDM systems. More than 25% of SMBs and 30% of large firms were either in the process of switching PDM systems or had just switched within the past two years, about twice the rate of change for CAD or CAE systems. 45% of large firms are going through or have just gone through a consolidation of PDM software.

The consolidation of PDM software will obviously raise the question of data migration and potential losses of companies due to their inability to move data from a previous system. Another practice is to continue using an old system in parallel with a new system to access data. The last option often becomes a much more cost effective for a company compared to the investment needed to migrate data between systems. The result is a lot of legacy data sources and systems. In the past, I wrote about different aspects of legacy data handling. The importance of legacy data for a company is absolute and very undervalued in modern PDM/PLM systems.

What is my conclusion? The complexity of product data management systems created a situation when migration of data between systems can cause a significant loss of value. Competition between software vendors in this domain adds additional difficulties. In my view, to clean the historical data record, as a result of multiple system migrations, is a very bad idea. To have an ability to migrate product data from one system to another can be a significant product differentiation factor. Just my thoughts…

Best, Oleg

Introducing Inforbix Product Data Apps

November 2, 2010

I’d like to take an opportunity and introduce a new company, I founded together with my colleagues – Inforbix. Our vision is to revolutionize the way people in manufacturing companies are accessing heterogeneous product data. Please, visit Inforbix website to get more information about the company, people and our ideas. Also, I’d like to introduce a new blog – Product Data Space. Inforbix is a social company, so you’ll be able to find us on LinkedInFacebook and Twitter.  You are also invited to subscribe to our YouTube Channel.

Inforbix and Beyond PLM

I’d like to say few words about my blogging activity. For the last couple of years, PLM Think Tank and, lately, Beyond PLM shared my opinions about engineering and manufacturing software, CAD, PDM, PLM, industry and technological trends. This activity was absolutely independent of my employment in the past and will remain independent of my future role in Inforbix. PLM Think Tank remains daily, and I’m looking forward to sharing new information, thoughts and opinion about what is going on in Engineering and Manufacturing Software Beyond PLM.

Best, Oleg

Product Data Formats for the 21st Century

July 21, 2010

Data formats is an interesting topic in the context of engineering and manufacturing. Manufacturing is relaying on a significant amount of information that resides in the organizations. I had a chance to write in the past – 3D CAD Future: How To Liberate Data? I think, the topic is actually much wider than 3D and CAD. Engineers are using multiple applications and – CAD, CAE, Office, various databases driven applications. In addition to 3D CAD formats, organizations deal with multiple public and proprietary formats. Some of them are specific for the existing applications. However, formats like CSV are generic and used by multiple applications. I read an article Is JSON the CSV of the 21st century by Martin David on the Line.ar th.inking blog. Martin is discussing what are the perspective to have JSON-like formats to have wider expansion in the next decades and replace CSV and similar formats.

I decided to put some of my thoughts about the history of product data formats and share some ideas about what may happen in the 21st century.

Technology and Interoperability
The story of data formats and interoperability is going together very often. Time ago, all application developers saved data into proprietary file formats. The interoperability was very poor. Then, the idea of relational databases invented by Edgar Codd came in to solve an interoperability problem. Everything is in relational tables and all applications supposed to use SQL. Nevertheless, multiple proprietary data models caused an interoperability problem again. Later in 1990s, XML was introduced as the next magic thing that will solve the problem of the interoperability. Since the first introduction in 1996, lots of different XML formats were developed. Some of them were developed in CAD, PDM and PLM space. However, the problem of interoperability is still with us.

Product data formats make their origins in hundreds and thousands of applications developed for engineering and manufacturing space. From the technological standpoint, I can classify them in the three groups: design related, database oriented and office applications.

Design related applications (CAD, CAM and CAE) are impacted by the development of major CAD systems. CAD applications are continuing to be very protective with regards to the formats. However, the adoption of geometrical kernels (Parasolid, ACIS and others) maintain today’s status quo in this space. Many “integration service” companies are dealing with multiple translation of all possible and impossible CAD data formats.

Office tools became part of engineering application and continue to make a significant influence on the product data because of wide adoption of MS Excel. Excel files are everywhere and you can find complete data management systems developed on top of the Excel and corresponded to the Excel data formats. Whatever will happen in the future, Excel legacy will continue to dominate for a very long period of time in everything related to product data formats.

The majority of engineering and product data related application is using database technology. This is what we have today in the industry. Relational databases and SQL-driven data development continues to dominate in this space. These applications created a huge amount of legacy data in engineering and manufacturing organizations. In most of the situations, companies continue to use data in relational databases even after application themselves becomes useless.

Product data format in CAD and other applications are tightly related to the issue of standards. My favorite association related to standards is tooth brush. We, obviously, need them. However, everybody wants to use their own tooth brushes. During the last 25 years, there are multiple attempts to create standards for CAD, PDM, PLM and other engineering applications. Some of them were more successful and adopted such as STEP and IGES. Some of the vendors related standards succeed on the level of visibility that can make them very close to become de-facto industry standards.

Product Data Ownership
The question of data ownership is an important one. Many organizations are using software to create various types of product data. It resides in application files and databases. Who owns these data? The reasonable answer – data belongs to the people and organizations that created these files. However, an absence of agreed and open standards created the situation when organizations are dependent on applications to access data.

Product data Format in the 21st Century
So, what will happen with product data formats in the visible future? I think, industry will need to find an answer on this question. The situation we have today was created by the business strategies of software vendors, existing technologies and specific application dominance. In my view, there is no “silver bullet” solution that can solve the problem of product data format in the short term. However, introduction of new web technologies, data standards and product data ownership can create a demand for the future innovation in this space.

These are just my thoughts.. I’m interested to know what is your take on the product data formats?
I’m looking forward to having a discussion around this topic.

Best, Oleg


Get every new post delivered to your Inbox.

Join 287 other followers