PLM Cloud Customization and Online Code Editors

May 8, 2014

cloud-code-plm

One size doesn’t fit all. It very true especially when it comes down to PLM implementations. Once released as a toolkit, PDM / PLM systems did a long way from a system that requires special software compilation to be done for every customers to the current system with flexible data models and tools allowing to configure and customize almost everything. Flexibility (in data model and code) is one of the most demanded characteristics of modern PLM systems.

Customization is also special territory in PLM business. It brings complexity and requires special attention. PLM vendors spent lots of effort to reduce the amount customization required for PLM deployments. However, after all, every PLM implementation requires services. Part of these services is related to customer requests to develop special functionality.

Cloud brings some advantages and complexity to PLM customization-ability. Specific aspects of cloud technology and customization can be different for public and private cloud deployment. Multi-tenant architecture can apply some additional level of complexity. One of the aspects of complexity can be usage of development tools on the cloud.

TechCrunch Disrupt NY presentation by Codeanywhere caught my attention. Navigate your browser to read more Codeanywhere, The Google Docs For Developers, Rocks Startup Alley At Disrupt NY. The idea of Codeanywhere to serve as universal coding environment available on any device is compelling. Look here for more features. I specially liked the ability to manage and store code in different repositories. You can connect to your favorite 3rd party services like Dropbox, Github, Google Drive as well as move files and folders between services.

codeanywhereeditor_large

I have to say that Codeanywhere is not the only provider of coding environment in the cloud. Navigate here to see more tools available. My attention caught service called Runnable. Note, the broad support of languages and tools – C++, Java, Rails, Node.js, JQuery, PHP and more.

runnable-editor-options

Cloud code environments made me think about the opportunity integration (or even embedding) of such type of development environment into cloud PLM platforms. It can provide unmatchable capability to customize PLM systems regardless on location from both sides (customer and developer). The result – low development cost, flexibility to chose the location of service providers and lower customization expenses for customers.

What is my conclusion? Cloud puts some constraints on PLM system customization. To choose special and effective tools can be a game changer for efficient customization. Risk of broad errors and complex multi-tenant constraints raises the need to create a special customization environment. At the same time, cloud is an excellent opportunity to lower the cost of PLM customization by optimizing the overall customization process and, as a result of that, lower expenses. PLM service providers can work from remote locations as well as have much simpler way to re-use customization. Just my thoughts…

Best, Oleg

pic credit – codeanywhere.com and runnable


Six dimensions to customize PLM

April 24, 2014

plm-customization-six-dims

Ask two engineers about how to make stuff and you get at least three opinions about possible ways to do so. To find consensus in engineering, product development and manufacturing is hard. From my experience engineers and software developers is the group with largest diversity of opinions and custom requirements. I’ve learned it hard way implementing and developing PDM / PLM software. Large manufacturing companies are better organized and leaning towards well-established business processes and polices. PLM vendors are using so-called "business transformation" approach to implement PLM for large manufacturers. It proved to be efficient for many companies (not only largest OEMs, but also smaller companies). However, the TCO of existing solutions is still too high. It is very hard to convince small company to implement PLM. In addition to that, smaller companies are less influenced by corporate hierarchy, business processes and IT system governance. I put some of my thoughts about that here – Why PLM stuck to provide solutions for SME?

Software vendors and service providers are facing the problem how to customize PLM for large and diverse set of requirements. Software toolkit was the first way to solve customization problem. Only very large customers accepted toolkit approach. It was complicated and costly. The next answer provided by PDM / PLM vendors was flexible data modeling and configuration. Most of modern PDM / PLM software suites are providing set of configuration tools to do that. Nevertheless, PLM implementation is still long process taking weeks or months. In many situations, it still requires some customization to be done.

Vendors need to find another way to customize PLM system. Current customization approach is mostly focused on a company – industry, size, processes. It made me think about another way to customize the system by focusing on a specific user in a company. I can see some of these ideas in role-based and out-of-the-box approach in developing of enterprise systems. However, I can see it different by stepping down from holistic company-wide customization towards specific user-oriented goals. In other words, company was the customer before. Now, it is about individual users.

Below, I summarized six dimensions of customization that can help to identify customization directions.

1- Who. This is very similar to role-based approach. It can help to identify specific key people and their everyday needs. List their functions and pains. What is specifically different for each of them. How to personalize apps / service for every individual.

2- What. This dimension speaks about specific function. How to customize the system to a very specific operation. What do customers do differently with the system. Go to the level of person (not department)

3- Where. This is a dimension that helps you think about customized locations. How is your system different for every place. How customer can do the work everywhere and how is that different. How to provide system wherever customer wants.

4- When. There are two major aspects here – how to make system available 24×7 and how to make system available instantly (by eliminating long implementation cycles and preparation).

5- Why. One of the most critical customization factors. Why user needs your system? How to provide ROI and make system stick? How to add more value for every specific user and not "in general" for the company.

6- How. This dimension is about customization factors responsible for how to delivery the product to different customers. What delivery forms to use. How my customers are different and how to satisfy customers in every way.

What is my conclusion? Today, company policies, business practices and organizational structure are factors that impact the way PLM vendors are customizing their software. Nothing wrong with that approach. Future customization can move from holistic "company" wide customization towards specific "customer" (read – user) needs. PLM software should be more personal and, by doing that, to attach to specific user functions in a very unique way – to provide value, be available everywhere, anytime and in any form. This is a future for truly customizable PLM software. Just my thoughts…

Best, Oleg


How to eliminate PLM customization problems?

March 28, 2014

plm-customization

I’m following strategic visions of the major PLM vendors 2014+ publication by Jim Brown – well known analyst and my blogging buddy for last few years. It started as a publication covering Autodesk, Dassault, PTC, Siemens (vendors listed alphabetically). Last week, Jim expanded his PLM vision publications by adding Aras Innovator to the list. Navigate here to read about Aras 2014+ vision. Aras is well known by their Enterprise Open Source strategy. One of the interesting differentiation I captured in Jim’s article is related to Aras’ strategy to break rules of PLM customization. Here is the passage:

Aras has decided to break the rules [of PLM customization]. They aim to become the PLM company that defies the conundrum, allowing manufacturers to customize their software and still upgrade to future releases without major disruption. They can do this because customers can update the data schema, business rules, workflows, and forms without jeopardizing the integrity of the system. How does this work? Aras’ XML-based, model-oriented approach coupled with their willingness to provide customers with the business flexibility and tools to make it feasible. Aras has effectively morphed themselves into a PLM Platform with solid core functionality with a built in ability to be extended by customers and partners. To put this strategy into action, they have told me they are “putting their money where their mouth is.” They now include upgrade services as a part of their subscription service. I haven’t seen that from anyone else anywhere, particularly while encouraging people to enhance and modify the package. This is a clear differentiator and makes Aras unique in the PLM market.

PLM customization is a tricky deal. Honestly, nobody is dreaming to make PLM implementation with zero customization effort. It all starts from flexible data modeling, which imply certain level of data customization. Time ago, I posted – Is PLM customization a data management Titanic? Earlier this year, I’ve been discussing options and reasons on How to de-customize PLM? The story of PLM customization is tightly related to PLM system flexibility data modeling. Typically, every PLM implementation contains some portion of customization that usually done by service organization and/or internal IT department. Lifecycle rules, data import, workflows, integration with other enterprise systems – this is only a very short list of customizations done during PLM deployment. Another huge aspect of customization is related to system upgrades. That one is actually mentioned by Jim Brown in his Aras’ review.

So, is there a way to solve customization problem? In my view, the answer is – it depends. In my view, you cannot eliminate specific implementation activities. Adding of new features and infrastructure technologies (eg. RDBMS) will require certain upgrade activity to happen. However, if you are selling services, the interest will be to optimize this work. Cloud vendors have similar incentive to optimize infrastructure upgrades and maintenance, otherwise operational cost will go up. So, smart technology can optimize cost and customization efforts.

What is my conclusion? Business and technology are going together. To have good business incentive to optimize technologies is always helpful and can put pressure on development organization to optimize cost of infrastructure upgrades. Service based offering (open source and cloud) are two great examples where business interests of vendors and customers are going at the same direction. Just my thoughts…

Best, Oleg


How to Decustomize PLM?

December 24, 2013

plm-decustomize-easy

Customization is one of the most favorite topics in PLM. Back 20-30 years ago, product data management (PDM) was born as a toolkit. Earlier PDM implementations took months and required deep changes in PDM system code and behaviors. It was leading to a growing complexity of implementation, highly sophisticated implementation skills and time. What is even more important and dangerous it was a reason many PDM/PLM implementations stuck in the back and failed to upgrade to newer versions of PLM software. I expressed it in one of my old articles – Is PLM Customization a Data Management Titanic? My guess back in 2010 was that future flexibility of data management technologies should make future customization and updates easier.

Customization problem exists in other domains of enterprise software. I found an interesting example of how extensive customization can damage enterprise software deployment and implementations. CMSWire article 6 Predictions for SharePoint, Office 365 in 2014 speaks about adoption of SharePoint 2013. One of the prediction speaks about SharePoint customization or actually… decustomization. I found this passage interesting:

We’ve heard Microsoft strongly suggest not to customize SharePoint, that branding doesn’t improve user experience or make processes better. That migration to new versions is easier without a lot of customization. The new SharePoint 2013 app model is also a strong pointer from Microsoft to keep SharePoint as out of the box as possible and focus on using Apps for additional customizations.

I think this is a good thing. Many of the challenges we see with migration projects are the result of branding and customizations — some of which may not have been necessary. Part of the reason SharePoint has been customized in the past is that developers are learning to use the platform and trying new things. The new App model reduces much of this, putting the testing and learning outside of SharePoint directly.

It made me think again about PLM implementation and customization projects. For the last decade, PLM vendors put a lot of efforts in developing of out-of-the-box offerings and strategies. Marketing used different names for this activity – from "express solutions" to "industry offerings". In my view, the result was somewhat mixed – it simplified PDM implementations and some smaller PLM deployment. At the same time, many even relatively smaller PLM implementations are still far from go simple way. In my view, the best confirmation to that is growing interest in acquiring service and consulting companies by PLM vendors. The last one was Siemens PLM acquiring TESIS PLMWare focuses on PLM integrations.

What is my conclusion? Decustomization of PLM will be one of the most important elements in the future PLM infrastructure improvements. To make implementation cost effective and to support future cloud deployments, PLM vendors will have to invest in technologies and methods to simplify deployment, flexibility and speed of implementations. Just my thoughts…

Best, Oleg


The role of PLM in mass customization

August 21, 2013

Product customization is one of the trends that changing the manufacturing landscape these days. Mass production was a mainstream for many manufacturing companies and industries. The appearance of configurable products and manufactured end items was limited. One of the most visible examples of customization in production was Dell. However, even Dell had a very limited ability to configure products. Cost advantage was clear and customers dragged by affordable prices of predefined configurations.

However, business is getting different these days. The demand of customers for customization is getting higher. Technological changes, internet, cloud solutions, supply chain and many other factors are re-shaping manufacturing landscape. Earlier today, I was reading Mashable article – Why Large-Scale Product Customization Is Finally Viable for Business. The writeup presents an interesting perspective of why mass customization is finally getting affordable and desirable. Here is my favorite quote explaining customer demand for mass customization:

Consumers’ expectations are being shaped by their lives online. Customization plays a large and growing role in digital experiences, from Facebook to Pandora Internet radio to mobile applications like location-aware Google Maps.

One of the elements solutions for mass customization is customer facing product configurator. Here is another interesting passage from the article:

Today’s customer-facing technologies are cheaper and easier to deploy than ever. The price (and time requirement) for developing customer-facing configurators has dropped significantly in the past few years. It’s a fraction of the cost even compared to a few years ago (think $50,000, down from $1 million). And new uses –- like embedding configurators within Facebook — make configurators more accessible (and more social).

Mass customization and product configurator topic made me think about what is the role of PLM in manufacturing of configurable products. Traditional PLM was dealing with customization via heavy loaded engineering to order processes. For most of the cases PLM companies were partnering with companies making product configurators or used ERP-based products. The most complicated part was to integrate multiple systems in a single solution, which required lost of code “hard-wire” and data transformations. The integrated software product line of product configurator – ERP – PLM – ERP and back to the shopfloor and shipping was hardly achievable by most of the manufacturing companies and PLM software vendors.

What is my conclusion? I think customization is the future for many manufacturers these days. The percentage of “configurable” and flexible manufacturing facilities will be growing. It will include online configurators, flexible configuration platforms and integration with production and supply chain. In my view, PLM should play a role in this modernization. It is a huge opportunity and the way to re-shape the future of manufacturing. Just my thoughts…

Best, Oleg


Why do you need to ask PLM vendor about JavaScript?

August 10, 2013

Customization is a great deal in every enterprise software deployment. Despite all efforts of vendors to invent out of the box (OOTB) enterprise software deployment, most of systems are requiring significant customization and coding. This is not a healthy situations, but with absence of better choices, manufacturing companies need to look for systems that can be flexible enough and supporting easy customization. In one of my previous blogs – PLM customization is Data Management titanic, I’ve been talking about challenges of customization as well as mentioned example of customers migrating between heavy customized PLM systems.

A typical PLM customization includes variety of tasks including changes in data models, tailoring of user interface and integration with other enterprise systems. To make your hands dirty and write some custom code is almost unavoidable task in this situation. If you long enough, you probably remember, VB and/or VB script were king of the road in all implementations and customization for many years. You practically had no choice to make any changes and customization without knowing this language.

I have to say that situation changed since the last decade. Intensive development of web and mobile application made VB/VBScript usage going down. JavaScript becomes a new king on the road. The following ReadWrite Web article caught my attention earlier today – Why Javascript will become the dominant programming language of the enterprise? Read the article and make your opinion. I found the following passage interesting:

There are strong odds in favor of JavaScript becoming the dominant language ofthe enterprise. This isn’t to say every other language will atrophy overnight (they won’t; too many legacy systems count on them) nor that JavaScript is free of issues (no language is). But the gigantic efficiencies to be gained by having a lingua franca for the enterprise, especially when that lingua is easily learned and already in wide adoption, makes the case for JavaScript very strong. Even Microsoft has warmed to the JavaScript movement, promoting it to first-class citizenship in Windows 8.

All of this is good news for the enterprise. A simple, open language, equally adapted to building both client and server-side apps? There’s no such thing as technology utopia, but JavaScript looks like the next best thing.

I often use Google Trend to capture dynamics of people interest. The following chart presents some dynamics between VBscripts and JS.

What is my conclusion? The landscape of software development is changing dramatically these days. Cloud, web and mobile development are main driving forces together with open source software. It will impact enterprise tools and introduce new requirements for integrating PLM products (and not only) in the enterprise and beyond. Important. Just my thoughts…

Best, Oleg


BOM 101: How to modularize the Bill of Materials

February 14, 2013

I want to get back to my BOM 101. In my view, Bill of Material management is one of the fundamental processes in PDM/PLM and requires lots of attention. I want to take the feedback made by Jos Voskuil and turn the conversation to be more business oriented. One of the trends in manufacturing today is customization. And this is a big challenge for manufacturing companies. Life was good in mass-production world, when the goal was to provide large series of items with predefined configurations. Not anymore… Today, clients are interested to how customize everything. Companies dealing with ETO type of business are facing similar challenges.

Efficient Bill of Materials management system can solve this problem. If you have flexible BOM management system allowing you to manipulate BOM structures and integrated with you ERP environment, you are half way done. However, technology out of the box won’t help you. It requires to apply some best practices too. One of the practices I want to discuss is "modular Bill of Materials". Wikipedia provide a very short article about that, but I liked the definition.

Modular BOMs define the component materials, documents, parts and engineering drawings needed to complete a sub-assembly. While the terms BOM and modular BOM are most commonly used in association with physical products, the concept can be used in a variety of industries (e.g. software, medical records). Modular BOMs are used by modern information systems to serve a variety of purposes, such as defining the components needed to produce a sub-assembly, and providing cost information for each component and "rolled-up" cost information for the overall sub-assembly.

The core idea of modularization is to create a set of "modules" (aka sub-assemblies) that you can manipulate in order to create a final product. The product development process will be divided into two essential steps: create your modular bills and create a planning bill for a specific product. The last one will allow you to roll out cost and delivery time for a specific product order. Below I put five steps to follow in order to modularize the process of Bill of Material management in your company.

1. Identify family groups. This work can take time, but will allow you to make some steps to improve you product portfolio. Most probably you already have some portfolio management tools in house. Engineering has a tendency to complicate everything. So, you may find an overwhelming number of product families in your company. So, you must take some time and optimize that.

2. Identify options. These are elements of products and bill of materials that can be added to multiple product families. Usually represents additional features that can be added and can be replaced. The typical example of options is different configuration of car in-dash navigation and entertainment system. What is also important at this stage is to identify constraints between options (conflicts, incompatibilities, etc.)

3. Create Master Bill of Materials. This is a very important step. Master Bill of Materials represents all families and all options. This is "THE" bill of materials of all your products, which allows you to plan and to manufacture any product and configurations. In most of BOM management system you operate with ‘phantom’ feature to create an efficient master bill of materials. The reliability of BOM management system is very important at this stage.

4. Create planning BOM. Planning bill of materials represents a specific product, configuration, order, etc. You generate "planning BOM" out of your master BOM in order to create a specific delivery task for your manufacturing system. You practically derive your planning BOM out of Master BOM. Tools that allows you to copy/compare structures and BOM levels are absolute must to make it work.

5. End item bill. This is a final stage. End item bill represent the customer world and the way to translate planning bill of materials into the delivery. There are multiple ways to create end item bills – create bill for every SKU#, manually configure options or implement automatic rule based configurations. In my view, the last one is the most promising alternative. However, it requires additional efforts to implement. So, don’t be surprise many of customers are manually configuring end item bills.

What is my conclusion? Modern manufacturing practices require good technologies and best practices applied together. To me, BOM modularization is one of best examples. You need to have an efficient BOM management system with technologies and user experience allowing you to work collaboratively on BOM in a very granular way. At the same time, you need to apply some planning steps to rationalize and optimize the way you work with configurations, custom orders and product customizations. The cost is a fundamental driver in a modern manufacturing world. An efficient BOM modularization will allow you to follow demands of customers for customization and keep product cost down. Just my thoughts…

Best, Oleg

Image courtesy of Salvatore Vuono / FreeDigitalPhotos.net


Dogfooding and PLM APIs random thoughts

November 14, 2012

If you are long time enough in software business you should be familiar with the term "dogfooding" (or eat your own dog food). This term used to explain the situation or scenario in which company is using their own products to demonstrate their capabilities and quality. If you are not familiar with this process, navigate to the following Wikipedia article to read more. I liked some examples there, specifically, Apple one, which I wasn’t aware about -

Apple Computer president Michael Scott in 1980 wrote a memo announcing that "EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc." by the computer company, with a goal to eliminate typewriters by 1 January 1981.[9]

The following passage brings few more examples:

One perceived advantage beyond marketing is that dogfooding allows employees to test their company’s products in real-life scenarios,[3][5] and gives management a sense of how the product will be used, all before launch to consumers.[5] In software development, the practice of dogfooding with build branches, private (or buddy) builds, and private testing can allow several validation passes before the code is integrated with the normal daily builds. The practice leads to more stable builds[citation needed], and proactive resolution of potential inconsistency and dependency issues, especially when several developers or teams work on the same product. For example, Microsoft and Google emphasize the internal use of their own software products[citation needed]. For Microsoft, especially during the development stage, all employees across the corporation have access to daily Software builds of most products in development, including the Windows operating system.[citation needed]

Today, I want to speak about specific "dogfooding", which is related to PDM/PLM APIs or (Application Programming Interfaces). In the world of PLM implementations, the role of Open API becomes very important. Usually, when I’m working with customer requirements, I can see the following notes – external programming or customization as a way to resolve features or function absence available in the product. Yesterday, I had a chance to read the following TechCrunch article – 5 Rules for API Management. Even if you are not programmer or software engineer, have a read and make your opinion.

The article made me think of the complexity of API delivery in PDM/PLM as well as about "lifecycle". The latest is important – PDM/PLM products live very long period of time, and the development of stable APIs is a separate and almost "must have" a prerequisite. The 5 rules – design, documentation, analytics, universal access and uptime made a perfect sense to me. I found interesting note about the relationships between IT and business group (which is also very typical for many PDM/PLM implementations):

Enterprise API Management must include the entire Enterprise, not just the techies in IT. The SOA solution, and the other gateways as well, is focused on the IT person and not the business owner of the API program. This is reflected in the UI that they present in their free version as well as their language that includes things like “policies”; too much of the business rules are codified in complex policies that require a technical expert to really use.

However, I found the notion of analytics, mostly interesting, since it can address the idea and requirements of API management through the lifecycle of the product. Here is the passage to think about:

[how to] think about the collection and processing of all the statistics associated with the use of the API, with an eye toward supporting and encouraging effective usage and discouraging/limiting usage that is counter to your business or technology goals.

What is my conclusion? The days of single PLM platforms are almost gone. The future belongs to Networks. Data networks, product and cloud services networks. The ability to adapt a product to customer needs, to continue product development in a fast-changing customer environment and strategic goal for cloud, deployment set new goals in front of PDM / PLM developers. The importance of having agile and flexible API that can sustain many product releases and development cycles was never as important as of today. Just my thoughts…

Best, Oleg

Image is courtesy of TechCrunch article (Feature image courtesy of XPlane – under Creative Commons.)


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 Salesforce.com environment and specifically their Force.com 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


Is PLM Customization a Data Management Titanic?

February 26, 2010

PLM implementations are not simple. At the time when PLM vendors are working how to improve their out-of-the-box product offerings, PLM customization plays a very significant role. According to the analysts, customizations and services can be estimated as about 40-50% of total revenues in PDM/PLM domain.

What is behind these numbers and why it happens? In order to understand it, I think, we need to get short round-trip in the history of Product Lifecycle Management. The roots of PLM are in the first implementations made by large aerospace, defense and automotive manufacturers. This is the birth place of PLM and origin of PLM ideas. Since then, PLM started their journey downstream by proliferating ideas, software products and implementations. I can identify the following three trends in Product Lifecycle Management these days:

Maturity of the basic product offering
The PLM core functionality came to the stable form and mostly represented by product data management, lifecycle components and additional modules related to the business process activities – requirements, program, project, services and other processes. Interesting is that PDM and Lifecycle are considered as the most mature components of these portfolios.

Industry specialization
Initially, PLM started in aero/auto domains. However, nowadays it is moving towards all industries. In order to play industry game well, PLM vendors decided to invest into industry orientation. This trend can be characterized by a wide range of options starting from industry marketing and ending by providing packaged PLM solutions for the specific industries (i.e. Apparel, CPG, Food and Beverage, etc.)

Emerging trends
I can identify two main emerging trends – SaaS / OnDemand and Open Sources. Both are focused on how to satisfy needs of customers differently utilizing new software technologies  and deployment as well as by investing in the alternative form of business models.

When PLM industry focused mostly on providing out-of-the-box functionality, I didn’t find any technological trends focused on core data management capabilities of existing and future PLM systems. This is a very bad sign, in my view. Looking backwards, I can see significant improvements that were made in PLM software by the introduction of flexible data modeling. It allowed to decrease cost of PLM implementations, but created the huge amount of today’s customizations and implementations based on existing PDM/PLM platforms.  And this is a growing conflict between customized PLM software and upgrades to the coming releases of PLM portfolios.

I found the following Develop3D’s article as a very interesting. Al Dean is writing about replacement of highly customizable instance of MatrixOne by Open Source PLM Aras. There is more information about this event on Aras website. Read it. It looks like customer made the decision in favor of Open Source because of absence of alternatives to move to the next version of out-of-the-box MatrixOne version. I want to point out on the discussion about PLM software upgrades – PLM, Cloud, SaaS and Software Upgrades. My conclusion was simple – technology and architecture matter. If PLM data management capabilities could manage the upgrade event from highly customizable solution, I doubt the customer’s decision was to dump out existing vendors. Does it mean Aras has such technology? I don’t know. However, coupled with Open Source business model it crushed existing PLM implementation.

So, what is my conclusion? My hunch is that PLM vendors forgot to invest into data management technologies. PLM data management technologies were created 10-15 years ago. Since then, industry developed huge amounts of customized implementations. I see these implementations as Titanic pushing forward… Do you think they will be able to achieve port of destination or will die in front of icebergs of upgrades? I see it as a real and dangerous problem.

Just my thoughts…
Best, Oleg

Share


Follow

Get every new post delivered to your Inbox.

Join 239 other followers