How Big Is Product Lifecycle Data?

July 6, 2010

Product-related data is one of the most important aspects of any PLM implementation. When you talk about PLM implementation, the topic of product-related data (or IP) is very often becomes a center of the conversation.  There are multiple sources of this type of data in the organization. In my view, one of the PLM goals is to have a control of this data and provide tools to manage the overall lifecycle. One of the PLM implementation challenges is to provide wide support for product-related data. The topic I want to discuss is related the ability of PLM product to handle full scope of this product lifecycle data.

I read the article Oracle, SAP working on Exadata support. The core of this conversation is about how to scale up and provide extensive support for big data handling in the organization. Have a read of this article and make you opinion. Mine is simple – both Oracle and SAP understood the size of the potential problem (data size). They are working in multiple directions to find a solution for data sizing in transactional enterprise application. Should PLM care? This is a very good question in my view…

PLM and Product Lifecycle Data Problem
One of the challenges PLM is having for many years is getting control of product-related data. My observation shows that product-related data is not completely controlled by PLM systems in the majority of PLM implementations. Even with a very successful PLM implementation, data is scattered between multiple data sources and PLM is only one of them. In addition to that, product-related data can be located in the diverse set of applications used for product development.

Product Data, Size and PLM value
The full value of Product Lifecycle Management is directly dependent on how what scope of product-related data is covered by PLM. The wider scope can maximize PLM value for organizations. With all current developments, PLM is looking on starting from design to manufacturing strategies and development of social-oriented application, sizing can easily become one of the potential bottlenecks related to the ability to support large scope of data.

What is my conclusion? I think, to understand sizing of product lifecycle data is important in order to build right operational and strategic plans related to data management. Data is growing fast. Future PLM implementation can suffer from problems related to data sizing. How to scale up PLM implementation in terms of size can be one of the most important questions in the future. Just my thought…

Best, Oleg


PLM and A Single Point Of Disagreement

June 25, 2010

When you talk to a sales person from one of the PLM companies, you for sure will be exposed to a “Single Point of Truth” vision. On the surface, you can see it as a very powerful message. What can be wrong with having a single point of truth on all design, requirements, engineering bills, manufacturing plans, support materials and customer calls? Sound a great opportunity finally to organize all you have related to your product development. However, is it really true?

View of the World from 9th Avenue

There is a legendary New Yorker magazine cover by Saul Steinberg called “View of the World from 9th Avenue.”It comprises a “map” of the world from a “New Yorker’s” point of view. Looking west from 9th Avenue in Manhattan is the Hudson River. Beyond that is  a flat view of the rest of United States. Then you see the Pacific, Japan, China and Russia. If you think about manufacturing and product development, you can find a very similar picture, depends on who is the person you are talking to. My conclusion is there is NO single point of truth. Everybody sees the problem or product data differently.

Single Point Of Truth Process

So, what happens when PLM implementation comes to the company? In the nutshell, every PLM implementation is trying to create a single point of truth for the organization. It means to go all the way from a data mess to the agreement about how to manage product data in the organization. The most typical process is when a company is taking PLM vendor’s blueprint of a data management schema and starting to customize it. This is a main reason why the process of PLM implementation is long and painful. You need to have different people in the organization to agree about data management principles. This is a very painful process. People in company departments have different goals and priorities. This is similar to New Yorker’s view from 9th avenue. There are multiple PLM methodology to deal with this called “Role-based views”, but technologically they based on the assumption to have a single model of everything.

The New Goal: Single Point Of Disagreement?

One of the possible ways to start doing PLM differently is to stop applying this painful “agree on a single model” process. People need to have a way to work in the world where their views are different, but their views can be synchronized and integrated. This is a not trivial task. It seems to me as a more appropriated way to solve this problem in comparison to what we have today. What need to be done is to find what are differences between people view on data in the organization. It can help to create an integrated product development data landscape.

What is my conclusion? To create an integrated and balanced way to manage product development is not a simple task. PLM is missing this point and assumed the actually data model integration will be created during PLM implementation and will be driven by customers. I can see it as a mistake that makes an implementation process lengthy and implementation costly. To resolve this problem will help to bring a desired simplification into PLM world. Just my thoughts…

Best, Oleg


What Is The Future Of CAD and PLM Standards?

June 3, 2010

I had chance to read the following publication on Develop3D – A New Common Data Standard. The author is discussing how life of CAD can be impacted and potentially improved by developing of a single CAD standard. In addition, I figure out that I used word “standard” many times commenting on last posts on my blog. It made me think about standards again. Standards are rising so many questions. It always sounds as beneficial. However, standard related activities create too many political and organizational issues. I decided to make a try and figure out if standards are our future in PLM.

Standards and Users
Companies and Individuals can belong to a group that potential may have huge benefits from standards. Your systems expected to work more smoothly, you can move between applications, you can benefits data sharing, etc .. However, at the same time, standards can stand on the way of innovation. Some of them may really prevent people from innovation.

Standards and Industries
I know many examples of industry oriented standards. In general, industry standards may indicate an industry health. The more standards industry develops- the more additional businesses and solutions can be created on top of that. In general, standards can bring industry on the next level.  In most cases, standards that emerged from industries are very stable.

Standards and Vendors
Do you think vendors need standards? The right answer – it depends, in my view… If it brings economical benefits, it can be really beneficial for a specific vendor. However, it is not clear and in most of the case to support a standard vendor need to put an additional effort. So it means additional expenses. In some cases (i.e. Supply chain), vendors can be interested in standards in order of work simplification between users in a supply chain.

What is my conclusion today? Standards are fascinating. However, standard activity is a very expensive. An additional work need to be done by vendors to support standards. So, behind standards, we can see a very simple economical use case. On the other side, users can have benefits from standards. Maybe we need to think about different business models, that less impacted by lock-in customers on their data? Thinking about pros and cons, I’d like to re-phrase my question as following now- Who Will Pay for future CAD/ PLM standards?

Just my thoughts…
Best, Oleg


PDM/PLM and Customization

April 21, 2010

Customization is a topic in Product Lifecycle Management that always raises discussions. There are multiple aspects related to customization of PLM systems, and I decided to explore them. In my view, the nature of PLM system customization is deeply related to engineering and product development aspects that in most of the manufacturing organizations are related to their core competencies and touch many processes in the organization. To be able to support them PLM systems are providing various customization capabilities. On the other side, the total cost of PLM systems and especially cost of changes becomes crucial for many companies and implementations. When it comes to implementation cost, need to customize PLM system becomes a negative factor.

Early Monsters
In the early beginning, PDM started as a completely customizable toolkit-oriented systems. In order to implementation and customize them, the significant amount of work needs to be done. For most of the early cases, vendors provided unique production builds of the systems dedicated to a particular customer. PDM was considered as 1M dollars project.

Flexible Data Models and API
Since demand on PDM/PLM systems started to grow, vendors looked how possible to deliver PDM system that will not require a significant effort in order to be customized and tailored to customer needs. The concept of “a flexible data model” was born and few very innovative systems were introduced to the market in late 80s and early 90’s. They provided set of customization tools to modify data schema and additional parameters as well as advanced APIs to support customer-oriented environment. Later in the mid of 90s, more PDM systems were created under significant influence of Microsoft Windows environment.

Out-Of-The-Box PLM
Next step in the PDM customization story was so called “out-of-the-box” system, yet fully customizable. Most of these systems were born as a modification of “a toolkit”-oriented implementations and providing their configuration tuned with a specific parameters and data schema. In my view, it was a beginning of “PLM industrialization” bubble. When systems still provided all options to be flexible configured and customized, the marketing story always emphasized their ability to be ready-to-implementation AS IS. Unfortunately, because of a significant emphasizing of out-of-the-box, technological and  development focus shifted from innovation in providing of flexible, customizable systems towards “packaging” and selling of boxed PLM for industries.

Cloud and PLM
Customization is considered as one of the most significant risks and problems related to PDM/PLM systems in what called ASP model in the beginning and later became OnDeman/Cloud systems. I don’t think, there is a Cloud/SaaS PDM/PLM system today that can provide the same level of customization as a system-on-premise. I think, an effort need to be made to learn environment and specifically their platform in order to understand the “secret sauce” of their success story.

What Is Next?
I have a feeling, we are in the middle of debates about flexibility and customization vs. out-of-the-box flavors of PLM. When it became clear, out-of-the-box systems cannot provide what customers need, industry is still continuing to promote ready-to-go solutions, industrial verticals and other sales and marketing oriented speeches. Nevertheless, I can hear strong voices to revise experience of the past 4-6 years and focus on technological development that can provide a platform for the future flexible and customization PDM/PLM system.

What is my conclusion today? Product Lifecycle Management is in the critical situation. It started as a complete customizable environment and, since 1990s moved towards out-of-the-box packages and non-customizable solution. The last happened based on the strong message about making implementation faster and cost reducing. It seems to me that out-of-the-box PLM is a marketing and sales dreams. Engineering and product development cannot be done “out-of-the-box” and even so, companies are doing similar things, their strong believe in the uniqueness and benefits of the engineering and manufacturing environments. The key word for me in PLM customization today is a granularity. To make it work is hard. How to bring it up remains a completely technical topic.

Just my thoughts…
Best, Oleg

6 Questions About Your Future Cloud CAD/PLM

April 16, 2010

Cloud is trending topic these days. During the last few months we had chance to see quite many examples of CAD/PLM vendors starting to speak about cloud computing, cloud applications and services. Autodesk, SolidWorks made a cloud related statements and announcements on their past user conferences. Large infrastructure providers are promoting different type of “cloud paradigms” such as “private”, “public”, “applications” and other clouds. In addition, I need to mention companies that are doing software OnDemand (such as Arena PLM, PTC, IBM) in the PLM field and basically saying “cloud” and “OnDemand” is about the same.

The cloud-related presentations are not always simple to understand. It is hard to predict how today’s desktop CAD application will move to the new “cloud” paradigm or how rich database oriented apps will start to provide cloud services. So, I decided to outline set of questions, that I think, every customer can ask about cloud apps when talking with potential cloud apps provider.

This is the primary concern for most of users today. For some reasons people feel very secured when  data is located on your hard drive as a bunch of CAD and Excel files. However, what happens when you move this data on the cloud? In some cases, and it can be a surprise to you, the cloud solution will be more secured. You can ask you potential vendors how a cloud solution can prevent massive copy of the information out of cloud location? CAD/PLM data is normally very large. Vendor can increase the ability to secure data, for example, by recognizing significant data movement in/out cloud account with patterns different from normals.

Access and Device Support
This is a very important question, in my view. One of the biggest advantages of cloud apps is the ability to use it on any device – desktop, laptop, mobile, etc. So, don’t forget to ask if a cloud solution is supporting relevant mobile platforms as well as newcomer’s devices such as Apple’s iPad. It will allow you to make your engineering stuff visible to your bosses on their cool iPhones and other new devices.

Customization and API
This is one of the key questions. PLM software needs to be flexible. You need to be sure, that it is not only out-of-box product you cannot change, but also customizable service you can configure, combine with our services in your company, etc. Good example is to review all information related to platform provided by as an example of customization capabilities. Another option, to see how customization capabilities are compatible with programming cloud solutions such as Microsoft Azure or Google can provide.

Backup, Upgrade and Compatibility
Cloud applications are different from what you are familiar on your desktop. This also can be not similar even to client-server paradigms. You need to think how you secure your future for the long term. Important aspect here is a backup, so you can be able to extract and keep your information in the safe place. It is not less important story of upgrades and compatibility between different versions of software. You need to know what is your provider policy with regards to data compatibility and customization compatibility. These are not simple questions for cloud/SaaS based software providers.  The solution here is hard, in my view.

Application Cost
One of the advantages of cloud/SaaS software is a low entrance barrier. You can start doing business using application subscription. However, you need to be prepared with questions about how much will cost you to increase a number of people that can access application and also, how much will cost storage capacity? When the first question is trivial, second one may be not so simple. You will need to estimate a scale of the data you are going to manage using this app and make appropriated cost estimation.

Vendor Risk Assessment
You need to make an assessment of your vendor. In the early days, the development cost of enterprise software was pretty high. So, company making enterprise business, in most cases, considered as a solid and financially backed. This is not true nowadays. The development cost of cloud/web apps dropped significantly and not requires significant investment. So, you need to check what is the chance your future PLM cloud provider will go out of business.

These are just my thoughts… I’m sure this list is not complete. It will be interesting to hear what do you think? What concerns and issues do you have when thinking how to migrate to your next solution on cloud? What are your questions? Where do you see problems and what advantages do think cloud apps will bring you?

Best, Oleg


Cloud and PLM Solution Evaluation

April 15, 2010

I think, Enterprise Software is not simple. And Product Lifecycle Management is not an exception and even one of the most complicated pieces of enterprise software. I had chance to discuss how to simplify PLM. However, today, I want to talk about how possible to evaluate PLM solution. Cloud computing, in my view, can change a lot of things in how enterprise software can be development, implemented and deployed. In addition, it made me think about cloud as a possible “evaluation” option for PLM.

Few weeks ago, I came across the publication by Lawson software availability on Amazon EC2. You can take a look on details here. The interesting piece of announcement is the following:

[...Lawson External Cloud Services also features Lawson Test Drive, which begins to change the way Lawson demonstrates its products and how customers purchase ERP software. Lawson Test Drive allows Lawson customers to test real products for up to 14 days using their own business processes and data before committing to the actual software purchase. Lawson Test Drive increases enterprise customers’ confidence that a demonstrated product will match the eventual installed product. Lawson Test Drive is being launched with two of Lawson’s newest, most innovative products...]

In my view, providing possible test drive in the virtual testing environment can be an easy option for customers to evaluate PLM software. I can see the following advantages:

1. Customer doesn’t need to invest into local infrastructure and  IT work
2. Environment can be tuned and optimized by software vendor
3. Evaluation can be shorter and more efficient.

A big question is how to load such a testing system with customer data? This can be complicated task. However, if you think about a pilot project it can be possible, in my view.

What is my conclusion? Evaluation of enterprise software is a very interesting space. Cloud solutions are probably in the beginning of their development in the such areas like CAD/PDM/PLM. However, to use cloud for evaluation can be an interesting option to make an evaluation simpler and in the end to improve customer’s adoption rate. It is always easy when you can test and see how it works…

Just my thoughts..
Best, Oleg


PLM Data, Identification and Part Numbers

April 9, 2010

I’d like to follow my yesterday post about PLM data modeling and talk about one of the issues that in my view are very important in PLM systems and implementations. The issue of identification or how it sometimes called “numbering system” is fundamental when you start thinking how to organize you product data. This is not a new problem, in my view. It comes all the time in the beginning of each implementation, when you start thinking about how to identify literally everything in your system. It normally starts from Part Numbers but spread out later.

The identification is a very complex problem. In the beginning, you can easy underestimate the size of this issue. However, as much you will be going forward you can easy come to the conclusion that this is one of the most important issues to decide before doing any implementation. I’d like to put few of the challenges that I think important to mention when you think about identification.

Multiple Systems
In the situation when you run many systems, you need to synchronize numbering and identification schema between them. This can be a not simple task and require significant effort and time.

Global Design and Manufacturing
Product development is going global these days. You want to design, build and support your system on a global scale. Product design and manufacturing are often happening in different countries and locations. In many cases, your local manufacturing facilities will be using local ERP system with local numbering and identification schema. At the same time, global product design will be interested to rely on the single identification worldwide.

Manufacturing and Supply Chain
The product development activity can be split between different parties – OEM’s and suppliers. OEM and suppliers are using separate and often different systems. To synchronize or coordinate numbering systems between them is another challenge on a global scale.

Company Mergers and Acquisitions
This is another type of the activities when you will face identification problems. Mergers and acquisitions happen and, in this case, you need to make an effort to create a single common identification schema from two or more separate systems.

This is not a full list, but figure out the most critical aspects that need to be taken into account. Recently, I came across a very interesting write-up about Part Numbering on the ZeroWait State blog. I think you can get some ideas about possible Part Numbering options such as – intelligent, semi-intelligent, automatic.

What is my conclusion today? I think the problem of the identification will become more urgent very soon. Most of the systems in product development and manufacturing were designed 15-20 years ago and considered problem of the identification as a number in a local database. Growing exchange in design and manufacturing information on a global scale will introduce new types of identification problems. In my view, enterprise systems in general, but PLM specifically will need to learn some lessons from internet systems development to find a right solution to this problem.

I’m interested to hear about your practice and experience with implementation of identification systems in your organization and during the implementation you made.

Best, Oleg


Why Do We Need PLM Data Model?

April 8, 2010

I’d like to come with questions about the topic of PLM and Data Modeling. The idea of this discussion came out of some comments and conversation made on PLM Think Tank. Since, it was presented as a significant differentiation in the capability of PLM system(s) to make their job, I decided it important enough to discuss.

Image by Mediawiki_dbschema

Fundamentally, PLM Data Model is the heart and the core of any PDM/PLM implementation and system. The ability to model design, engineering and manufacturing data as well as processes around, obviously comes as a very important. However, since the topic of modeling is about company products and process, it is always coming as something unique in the organization. In the early beginning of PDM, systems were not flexible and requires physical change (re-build) to handle specific product and process data. Nowadays,  PDM/PLM systems are claiming sort of flexible data modeling capabilities that make them possible to apply to any customer situation. At the same time, cost of this “application” is sometimes very expensive.

PLM Data Model Uniqueness
What make PLM Data Modeling so unique? Why do we need it? Maybe we can avoid this process, by supplying something generic and not requiring change for every customer? There are two extreme examples I want to bring in the context of these questions. One is about Excel (or spreadsheets). Basically, we can model almost everything in the spreadsheet these days. It is absolutely good, since it is damn flexible and can run out-of-the-box. However, to understand these models, you need to keep Chief Excel Officer in your organization for full time job. As an opposite – why we cannot make “the universal PLM data mode”. Since, this is all about engineering and manufacturing, we can finally identify what to put there. It may work, but every time, your customer will ask you about “small changes” to be made in order to support their requirements.

Standards and Best Practices
I can see these two options as a industry try to deliver a compromise between Excel and One-PLM-Model. Standard activities were very popular (and may be still popular) in the engineering and manufacturing world. Standards for product data exchange, supply chain, industry standards, etc. In parallel with that, big software and service vendors tried to come with so called “best practices”- a simplified way to delivery data model for a specific segment of customers, industry vendors. The fundamental difference between standards and best practices, in my view, was at the level of “agreement” achieved between parties involved into this activity.

Where I want this discussion to go? I think, PLM (or engineering and manufacturing) data models are an interesting topic and real problem. In many cases, it defines the success of the implementation or PLM software in general. This is a technical and marketing issue at the same time. At the same level data modeling influence implementation and product architecture, it is always used as part of the marketing story. Do you think a PLM data model is a key of the future success of PLM implementations? Conversely, maybe you think it is a technical term, and it should dissolve into “real conversation about functions and value of PLM systems”?

What is my conclusion today? I want to listen to your opinions. From my side, I’ve seen this topic touched hearts of many people involved into discussions. In my view, PLM Data Model defines the level of flexibility (or new word – “granularity”).

Just my thoughts…
Best, Oleg


PLM Challenges In The Global Product Development

April 7, 2010

I had chance to read The Practice of Global Product Development at MIT Sloan Management Review. You can find  the link to this article here. The original research was published back in 2006. The current article is dated November 2009. In this new work author Steven D. Eppinger and Anil R. Chitkara, examined state-of-the-art and emerging best practices in global product development (GPD). I think Global Product Development has a very co-planar vectors of development with PLM. In my view, in the global organization, PLM has an opportunity to become “the backbone” system. Since in many cases, ERP deployment is country specific, PLM will have an advantage to integrate product development activity on the global scale.

I’d like to figure out some essential key success factors of GPD that need to be in the focus of PLM-minded people.

2. Process Modularity To enable PD activities to be carried out in different locations, there must be a methodology to segregate the work packages for global distribution. For example, where a remote center will be handling tasks in a process that continues to be owned by the “central” PD location, a modular process is needed. The process must be broken down into clear steps, the steps distributed to different locations and the process reconfigured to allow for the necessary handoffs, reviews and approvals.

3. Product Modularity Modular product architecture is very helpful for GPD in which development of complete subsystems or components is to be carried out by teams in different locations. Clearly defined interfaces between modules facilitate their separate development and eventual integration into the product. Without such modularity, more intense collaboration across design interfaces is necessary.

5. Intellectual Property As critical product data, designs and technologies are shared more widely outside the company, protection of IP becomes more difficult. Defining products and processes in a modular structure not only can help with the distribution of activities, but also can help protect IP.

6. Data Quality The availability, accessibility and auditability of data become key challenges when many locations contribute to the PD process, often using different tools and databases. Teams may be working on different aspects of the product with similar “source data.” As these data change during the process, all users of the data must be aware of the changes and the implications for their work. One system or database must be used as the “source of truth.”

In my view, these success factors present important challenges to any PLM implementation for the organization during deployment and implementation of Global Product Development practices. Below is my take on the top PLM challenges in GPD.

Global Product Data Modeling
The big organization has their own rules in organization product data. Most of the global organizations already have a product development process which organizes product data in a certain way. When it comes to implementing PLM vision, the question of “how to model product data” is one of the first questions that implementing team is going to discover. Despite the fact PLM vendors developed and acquired technologies and tools for flexible data modeling, in my view, this is still not a simple task. The biggest challenge is to get people in the global organization to agree on a meaningful way to represent and model data. These are current PLM practices, and unfortunately they require significant investment from the organization to make it happen.

Distributed Data and File Share
Data in a global organization need to be distributed between multiple locations. This simple statement means very not trivial implementation. How to plan your data location globally, how to move files and other pieces of data, how to protect IP when you work offshore? All these questions need to be answered by PLM implementation. I believe each organization is going through their own path in the organization of their distributed data and file management practices.

Change Management
This is last, but definitely not least. At the time that job done and system is up and running, the next step is… change! Global organization will be requesting on going changes in the way data need to be managed, located, accessed, etc. All this to support organizational business performance. To be able to support on going changes timely and without product development is a huge challenge for PLM deployment.

Just my thoughts… I’m sure, I didn’t cover all challenges, and I’m awaiting your comments. I’m very interested if you can share your experience and practices related to global product development and PLM deployment.

Best, Oleg


Manufacturer Priorities and PLM Integration Lock

March 21, 2010

I have chance to listed AMR’s Mike Burket interview during Siemens PLM Innovation Summit. It seems to me as a very interesting talk and slides about current PLM priorities. You can see it on this link. Thanks Dora Smith for this nice blog post, video and slides. One of the key requirements coming from manufacturers today are around cost reduction, better integration operation and product development as well as improvements in a supply value chain.

I counted two issues that, in my view, can be considered as very old requirements and demanded by many customers long time:
1. Design to Manufacturing Processes
2. Supporting of segmentation in Supply Chain.

On the one side, you can think about them as two separate issues. However, these two issues share one common fundamental problem of PLM systems. The problem is how to organize  integrated cross organizational processes. If you will take a look on the following slide presented by Mike, the need for integration is something that I see as a must requirement to link demand insight, product development and supply networks.

Listening Mike it becomes almost clear that process integration will become the next PLM challenge. However, here is my point. Unfortunately, integration is a very expensive job. All integrated projects I know, took a lot of time, resources and, in my view, doesn’t fit IT budgets. The issue of reduced IT budgets makes this problem even more important and critical. Many of today’s PLM integrated projects were possible only due to result of long and dedicated work done by vendors, services providers and organizations.

What is my conclusion? There is no magic outside of powerpoint slides. Integration is hard. Nobody can do it easy today. Big PLM systems provide a comprehensive product development environment, but they are not adaptable for lean cross-organizational process integration. How to find a way to reduce PLM integrated project cost and improve the agility of product development environment? This is sounds as a deadlock and the biggest challenge for manufacturers and PLM vendors in coming future.

Just my opinion.
Best, Oleg



Get every new post delivered to your Inbox.

Join 244 other followers