PLM and Selling Data

February 10, 2012

Manufacturing companies aggregating a lot of data these days. Data is coming from many places. For many years, product development, manufacturing and supply chain was major sources of data in companies. Nowadays, data is coming from outside of a company. Internet, social network and communication created new source of information. The intersection of data from inside of a company and outside data is a very interesting place. I’ve been reading Forester blog – Mo’ data mo’ problems few days ago written by Clarence Villanueva. The publication discusses a potential value of data created during marketing campaigns. Here is a quote:

…a client was looking to have a marketing company take its point-of-sale (POS) data to prepare email campaigns. Upon closer review of the contracts, data ownership was ambiguously defined and nested in three separate areas: the Master Services Agreement (MSA), SOW, and an addendum. When you trace the definition through the various documents, the only thing made clear on data ownership was that the campaigns resulting from the ETL (extract, transform, load) process were owned by the client. What about the POS data that was sent over to the marketing services company?

This example made me think about multiple cases when manufacturing companies as well as outside companies such as suppliers, service providers and many other entities can create an interesting value from the combination of the data owned by them – product information, sales information, contracts, customer data, etc. Imagine PLM software will be able to combine these pieces of data into valuable assets.

What is my conclusion? I think PLM has an opportunity to convert data into valuable assets. I can see more companies adopting PLM these days. Cloud PLM will provide an additional opportunity to connect data coming from multiple sources – supply chain, subcontractors and customers. Sounds like an important topic and cool opportunity. Just my thoughts…

Best, Oleg


PLM, RDBMS and Future Data Management Challenges

January 5, 2012

It is not unusual to hear about problems with PLM systems. It is costly, complicated, hard to implement and non-intuitive. However, I want to raise a voice and speak about data management (yes, data management). Most of PDM/PLM software is running on top of data-management technologies developed and invented 30-40 years ago. The RDBM history is going back to the invention made by Edgar Codd at IBM back in 1970.

I was reading Design News article – Top automotive trends to watch in 2012. Have a read and make your opinion. One of trends was about growing complexity of electrical control units. Here is the quote:

As consumers demand more features and engineers comply, automakers face a dilemma: The number of electronic control units is reaching the point of unmanageability. Vehicles now employ 35 to 80 microcontrollers and 45 to 70 pounds of onboard wiring. And there’s more on the horizon as cameras, vision sensors, radar systems, lanekeeping, and collision avoidance systems creep into the vehicle.

It made me think about potential alternatives. Even if I cannot see any technology these days that can compete on the level of cost, maturity and availability with RDBMS, in my view, now it is a right time to think about future challenges and possible options.

Key-Value Store

These types of stores became popular over the past few years. Navigate to the following article by Read Write Enterprise -Is the Relational Database Doomed? Have a read. The article (even if it a bit dated) provides a good review of key-value stores as a technological alternative to RDBMS. It obviously includes pros and cons. One of the biggest "pro" to use key-value store is scalability. Obvious bad is an absence of a good integrity control.

NoSQL (Graph databases)

Another interesting example of RDBMS alternative is so-called noSQL databases. The definition and classification of noSQL databases is not stable. Before jumping into noSQL bandwagon, analyze the potential impact of immaturity, complexity and absence of standards. However, over the last 1-2 year, I can see a growing interest into this type of technology. Neo4j is a good example you can experiment with in case you are interested.

Semantic Web

Semantic web (or web of data) is not a database technology. Opposite to RDBMS, Key-value stores and graph databases, semantic web is more about how to provide a logical and scalable way to represent data (I wanted to say in "semantic way", but understand the potential of tautology :) ). Semantic web relies on a set of W3C standard and combines set of specification describing ways to represent and model data such as RDF and OWL. You can read more by navigating to the following link.

What is my conclusion? I think, the weak point of existing RDBMS technologies in the context of PLM is a growing complexity of data – both from structural and unstructured aspects. The amount of data will raise lots of questions in front of enterprise IT in manufacturing companies and PLM vendors. Just my thoughts…

Best, Oleg


PLM: Controversy About Process vs. Data Management

November 16, 2011

Process vs. Data. I think, this topic not requires a special introduction. In my view, every PLM implementation is facing this discussion and requires to take a decision about how to proceed. Few conversations with customers during DSCC 2011 last week and some articles I read on the long flight from Boston to Europe during the weekend made me think again about this process vs. data controversy, and I wanted to share my thoughts with you.

I was reading Capgemini blog post Business process management and mastering data in enterprise by Nicholas Kitson. Nicholas is talking about interesting aspects in failure of Business Process Management (BPM) implementations he experienced with customers. In the beginning of the artcicle, Nicholas quoting Gartner analyst Michael Blechar: “A failure to address service-oriented data redesign at the same time as process redesign is a recipe for disaster.”

I found this notion of “recipe for disaster” as something very important. In people’s mind, PLM system was a recipe for disaster. Even today, after the value of PLM was confirmed by many organizations and implementations, lots of people are still questioning about how to approach PLM in a right way. To continue with Capgemini article, I found the following passage very interesting:

While BPM tools have the infrastructure to do hold a data model and integrate to multiple core systems, the process of mastering the data can become complex and, as the program expands across ever more systems, the challenges can become unmanageable. In my view, BPMS solutions with a few exceptions are not the right place to be managing core data[i]. At the enterprise level MDM solutions are for more elegant solutions designed specifically for this purpose.

I found an interesting connection between this statement, and the presentation made by Bell Helicopter during Dassault Customer Conference last week in Las Vegas. Bell Helicopter embarked on the journey to implement Dassault newest V6 platform, and I was impressed by the presentation they made. You can see the following slide introduced one of the biggest problems in Bell’s organization back in 2005 was a significant need to modernize processes in the organization. They found that processes are too fragmented, and 467 legacy systems create a significant data and enterprise complexity.

The critical strategic decision made by Bell was to make PLM implementation first. Part of this strategy was so-called “get the core [product] data right first”.

PLM – Focus on Process

Since the industry focus move from PDM to PLM over the past 5-10 years, the question about what is the focus of PLM implementation emerged as something important. Until that time, most of the companies understood the value of PDM. Even despite PDM implementation complexity, the value of having the ability to vault CAD data and manage changes was mostly not disputable.

At the same time, I cannot say the same about management of product development processes. Let’s take Item / BOM and Change Management. Many PLM systems were “pushed” to manage BOM and Changes. However, in practice, it creates many problems. Bill of Material data (especially if you think not only about BOM from your CAD drawing) normally spread out multiple systems- PDM/PLM, ERP, Supply Chain Management. ECO is a process which clearly crossing multiple departments and data islands in an organization.

So, PLM system was pushed to be “focusing on processes”, and this push was very problematic. Sales and marketing were focused on promoting of the values of PLM to the companies. In practice, many organizations faced significant level of complexities to have, for example, change management process implementation across the entire organization. Why so?

PLM: How to streamline the data access

In my view, every manufacturing organization experiences a complexity of data. Data is overwhelmed. According to some industry researches, the amount of data volumes in organizations will be growing x44 times for the next 10 years. The question of managing data is long time in the spot of all PLM implementations. Very often, this question presented as “who owns part, BOM, etc.?”. The same question, but asked in a more intelligent way can sound like “who is mastering Part, BOM, etc. information”. The hidden question, I hear is the need to streamline data access related to these processes. This is a vital part of every PLM implementation.

The latest trend in this space is “unification”. PLM vendors are trying to push everybody to so-called “unified PLM platform” that will consolidate all data in a single place. For PLM vendors like Dassault, PTC, Siemens, it was “all except ERP”. For ERP-based PLM providers it gives even stronger voice of why PLM-ERP bundle may have an advantage.

The question, “how to streamline access to data” in the organization before you embark to the journey of process improvements is the key question that needs to be asked by all manufacturing companies. Without that, most of the “process improvements” and implementation will stack forever or will turn to a nightmare.

PLM and the promise of cloud applications

Cloud is hyping these days. It is not unusual to hear that cloud will solve the problem of complexity related to existing software in the enterprise. Here are few examples:

Dassault is talking about their V6 platform as a unique cloud platform (last week Bernard Charles, DS CEO mentioned $2B investment made into re-architecture of Dassault platform).

Another large company in engineering domain – Autodesk is just a week before making a significant announcement (see more details here). I found this quote interesting: Autodesk will forever improve the way you manage your business processes and workflows when we unveil a modern, zero deployment solution that makes collaboration, data, and lifecycle management accessible to anyone, anytime, anywhere.

Another new comer in this market – Kenesto (according to COFES 2012 registration, Mike Payne is CEO of Kenesto) promising to “revolutionize process automation“.

What is my conclusion? I think the failure to design data access in organizations, was a recipe for disaster for many PLM implementations. PLM programs were focused on “how to improve processes” and forgot about how to put a solid data foundation to support cross-departmental process implementations. So, I’d like to put a quote from Bell Helicopter’s presentation during DSCC 2011 as something PLM vendors and customers need to remember – “to get the core data right first”. Just my opinion, of course. YMMV.

Best, Oleg


PLM Migration to… Text?

February 21, 2011

Sometime data management Q&A looks funny. World Online Review published the following solution on the request about how to migrate data into the text. Hit thislink to read a simple instruction:

1. In sql enter the command SQL>spool
Then enter the required select statment.The entire output is
transfered into the speficied file.The file’s default extension
is LST.Then enter SQL>spool off
2.You can also transfer the contents using utl_file utility.

Migration of PDM/PLM environment is a very complicated task. It is not as funny and simple like SQL recommendation. Think about the option to spool data out of PLM system and get it back in another system. Sounds complicated? However, wait a minute and think one more time… Data is in your PDM Oracle database. You just spool data out of your database. Do you think it is wrong? Not as wrong as you are thinking now. Just my thoughts, of course… YMMV.

Best, Oleg


PLM: Share Data or Die

January 22, 2011

I’m still digesting a huge amount of information I learned from PLM Innovation Congress earlier this week in London. However, there is one trend that I can identify that struck me as a major one coming across all presentations and talks. I can call it “integrate and share” trend. The problem of integration and share of data is not new in manufacturing organization. The need for integration of various elements of data for product development, manufacturing and supply chain is clear. Software vendors and customers are working for on this for years. However, something new happens now that allow me to have a fresh look on this.

Integration Processes

The sound of integration needs is very loud, and you are able to see it in presentations. I put few examples of pictures I made during the event to show how customers explain their critical business issues related to integration of data and processes in organizations. In a nutshell, inability to provide smooth integration prevents streamlining of organizational processes. It appears in communication between engineering and manufacturing, sales and production, support and sales.

Share Data

The need to share data is obvious. However, data sharing was never realized in an easy way. There are multiple reasons for that. Some of them are including the nature of people (keep my data close to me), company organization (departments, hierarchy, etc.) and competition between vendors (lock-in data inside of proprietary formats and data structures). At the same the value of data sharing is obvious. Organizations are losing money, projects are going out of schedules just because of that. PLM aimed to solve this problem during the past decade. I have to note a significant success in multiple implementations I had a chance to see. I personally participated in some of them. However, the ability to share data efficiently is still more science that ordinary process.

What is my conclusion? The need to integrate and share data is urgent. However, the way organizations are doing it, reminds me space shuttle programs. There is a need to downgrade and simplify these integration efforts to become more similar to transatlantic flights or even car trips. Just my thoughts…

Best, Oleg


PLM Cloud Future: Back to Database?

December 30, 2010

I was reading Salesforce.com announcement made earlier this month during Dreamforce 2010 conference about introduction of a new database.com platform. I found it as an interesting turn in the future cloud platform development. You can take a look on a short video introducing the new element of Salesforce.com platform.

What is database.com is about? The main driver behind this is how to solve a problem of fast application development and deployment. Before that introducing, Salesforce spent time introducing multiple clouds- basically imitating product portfolios in a traditional application form. However, the limit of such an approach and the ability of 3rd party developers are very critical. So, database.com is coming to solve the problem.

I read Michael Fauscette’s report about Dreamforce 2010 conference. Here is an important, in my view, piece of this report Michael is talking about database.com:

Database.com and the database cloud is an interesting announcement on several fronts. In the simplest form, developers should find the offering of interest since many are looking to deploy apps that provide ubiquitous access, multi-device, multi-OS, etc. Having a cloud ready database to use for development could speed up that process. Database.com is the latest in Salesforce utilizing assets that they already had developed by putting a public front end on the asset and offering it as a product. If you think about it, when Salesforce.com started in 1999, building applications for SaaS was new and they had no available cloud platforms including the database tier. They had to develop all of these assets and now that they are mature Salesforce is opening them up for other ISV’s to use, starting with the Force.com platform and now with the Database.com offering. Database.com supports any development platform, any development language and any device. With the offering ISV’s get a scalable multi-tenant database with automatic upgrades, tuning and backup.

Platforms, Cloud, Data

Data is playing a significant role in every computing platform. We can see multiple efforts of platform players to provide data management solutions on cloud. The most significant players in this space, in my view, are Amazon, Google, Microsoft. Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. SQL Azure is a highly available, scalable, multi-tenant database service hosted by Microsoft in the cloud. Google and some other vendors are rolling out their own proprietary data management and database technologies.

PLM Cloud Data

Earlier in 2010 CAD and PLM vendors made some announcements and introduced applications and researches leveraging cloud. However, a very small emphasize was made in the context of how data will be places and management on the cloud. The most prolific statements were made by Dassault and SolidWorks. DS V6 platform was mentioned as a future cloud platform. In my conversation with Jeff Ray of SolidWorks, he mentioned the first cloud V6 enabled product (the current name – SolidWorks Connect) to be available later in 2011. PTC and Siemens PLM are keeping neutral positions with regards to the availability of their product on cloud.

What is my conclusion? Data becomes an important piece in the next step of cloud platform development. In my view, Salesforce.com is proving that by introducing database.com cloud layer. This data layer takes us back to a very fundamental point of granular and flexible data management introduced in PDM back 15 years ago. To manipulate data on cloud can be a next serious differentiation characteristic of future PLM cloud platforms. Just my thoughts…

Best, Oleg


CAD Data and PLM

October 5, 2010

The following blog article drove my attention yesterday: CAD File Management ≠ PLM. The short blog post published by Peter Schroer of Aras. The summary of this post, in my interpretation, is simple. CAD Files and design represent a small portion of business problems in a manufacturing company. So, when you are going to make your PLM decision, think about a full scope of business problems – not only about CAD data. I specially liked the following passage from Peter’s post:

I’m not saying don’t let the CAD guys use what they want. Let them use their system of choice for CAD file management. That’s no problem – today’s enterprise PLM systems can move data in and out of it easily. But you’ve got bigger business issues than CAD file management, like LEAN, configuration management, workflow processes, quality, compliance, supply chain integration, FMEA, etc.

Peter is referencing deelip stating the following – "CAD geometry is 1/20 of what it takes to produce and maintain a part" and making straight conclusion "If CAD only accounts for 1/20 of your product, don’t let it drive 100% of your decisions."

In my view, the discussion raised by Peter raises a very interesting question. How much attention PLM should allocate to CAD-related problems? How it is important for PLM to be deeply connected to CAD systems and CAD data?

CAD Roots and PLM

PLM, as a software, was born as a natural extension of CAD businesses. It initially started as data management for design and engineering, it grew as an important function to manage product development processes. Connection to CAD (design) data provided an important information to drive product lifecycle in an organization. However, this deep connection, also made a bad service for PLM. On a system level, it created an additional level of complexity and increase product dependencies. On a business level it, some of vendors started to use CAD-PDM/PLM dependencies in order to realize their competitive advantage strategies.

CAD-Rootless PLM?

Is it possible to create a PDM/PLM software disconnected from CAD and design roots? Companies were looking for answers on this question for the last two decade. Many of these companies went out of business or were acquired by CAD or ERP vendors. The idea of focus on product development processes without having deep roots in CAD, seems attractive to people these days too. I can see a kind of renaissance of these ideas influenced by modern technologies (the Internet, SOA, etc.).

Importance of CAD / PLM integrations

However, I can see a problem in a significant disconnection between design and rest of product development processes. The last release of Oracle Agile PLM 9.3.1 announced on Oracle Open World last week, stated the importance of multi-CAD integrations. It represents a clear path for PLM product to stay connected with CAD. In addition, the last paper from CIMData – Ten Questions to Ask PLM solution supplier presented the importance of PLM system ability to stay integrated with multi-CAD and ECAD data.

What is my conclusion? PLM is focusing on solving manufacturing business problems. The key manufacturing problems are related to how to control a product cost and optimize business. When 70% of a product cost defined during the design stage, the reliance on the design data becomes more than important. This is a strong point behind CAD driven PLM decisions. However, if your system becomes locked in the engineering department, you are barely able to drive a complete view on how to control a product cost and optimize business. The connection between design/engineering and rest of the business is the most challenging piece of a successful PLM implementation.

Best, Oleg


Should PLM Disconnect Data from Process?

August 27, 2010

I had a chance to read an article byebizQ related to Cordys BPM. For those who is not aware - Cordys is a relatively new outfit in the enterprise software market. The wizard name behind this company is Jan Baan. If you are a long-time citizen in the enterprise software domain, you need his first ERP company - BAAN. These days Jan Baan is very active and Cordys is one of his new babies. In his interview, Jan is discussing his long project related to decoupling of processes. The following quote seems to me interesting:

… ending the data-process dependency is easier said than done. Suppliers attempted it using extremely fat clients at one extreme and sophisticated distributed data with replication at the other.

Process Decoupling

For a very long period of time the concept of “a process needs data” were dominant. Multiple BPM vendors claimed that the only way to make BPM successful is to bring meta-data (and other data) into BPM product suites. I can agree, this strategy seems to be successful if you plan is to create integrated enterprise software suites. However, thinking more about Internet technologies and lean architectures it makes much more sense to make a disconnection of data and process.

PLM: Process vs. Data

In my view, PLM Software vendors are definitely moving towards better vertical integration. Users are asking PLM companies for a better integration between products, and PLM (and not only PLM) companies are starting to couple products and solutions together to ensure customers will spend fewer resources tailoring these solutions.

What is my conclusion? I think, enterprise software vendors can miss the dangerous point of data and process connection and interplay. When most of the enterprise companies use data to lock-in customers in their product suites, the addition of processes seems to them as a natural continuation of this strategy. The real danger of these strategies is a large complicated software products and extremely high cost of changes. Just my thoughts…

Best, Oleg


PLM Architecture, Cloud and Design Versions

August 11, 2010

I’ve been reading Ray Kurland interviewing Rich Allen of Dassault Systems SolidWorks Corp. about the future of SolidWorks’ cloud solutions. To read this article, follow this link. Have a read and make your opinion. This interview made me think about some fundamental PDM/PLM paradigms related to management of data. Sometime, new technologies can change old and cumbersome paradigms. Let me think if managing product data on the cloud can make some difference in patterns we use to do it now.

Workspace – Server
A very old pattern started in the early days of PDM. You keep your design data locally to access by CAD and other desktop tools. You PDM app is actually transferring these files/data to secured PDM server. Last trends show that workspaces are moving to users-dedicated spaces on corporate servers. Many of PDM problems are actually started from workspace-server paradigm. Synchronization of user workspace and PDM file servers without burden CAD user flow was a key to success in integration of CAD and PDM together.

Veritcal PLM Integration
One of the options to simplify workspace-server problems is to bundle CAD system with a server back-end. In my view, this process started to happen, and all major CAD/PLM vendors are working to improve their vertical integrations. Unfortunately, customers are the biggest problem in vertical integrations. For multiple reasons, customers are not working with a single CAD system and preventing total unification and vertical integration.

CAD Data Cloud and Design Version
How we can fix old paradigm by shifting patterns of workspace/server data management to something more straightforward. Let just keep CAD documents somewhere on the cloud. Do we really need local file workspace? Actually, we do. All desktop CAD systems are designed to work with files located somewhere. Can we change this behavior by allowing them to get the same data from cloud location? Maybe we can reduce a complication of revision management in CAD/PDM/PLM and will make it as simple as Google Docs Revisions?

]

PLM Cloud Architecture
I found the following quote from Rich Allen’s interview interesting. It seems to me the paradigm shift already started, and vendors are thinking how to apply existing and modified technologies to a new cloud paradigm.

We will base all of our future cloud applications on the ENOVIA V6 infrastructure. This will help us leverage our own technology across all the brands. It should be noted that with cloud computing, the engine is on the cloud –- end-users only will be concerned with the client they use to access the application, so we don’t expect users to have to install ENOVIA servers at their site to benefit from cloud computing.

What is my conclusion? Cloud technologies can bring a paradigm shift. The biggest advantage is to simplify user’s workflow. The design revision workflow is one of the most problematic in CAD/PLM world. Cloud thinking can help, in my view. Vendors will try to optimize existing CAD and PLM infrastructures. However, to realize this paradigm shift is not a simple job. Just my thoughts…

Best, Oleg


PLM and Legacy Data

July 26, 2010

When I’m thinking about any PLM project, I can clearly see the step when data available in the organization need to be loaded into the system. This step is often underestimated from different standpoints: ability to gather and load information, availability of data definitions, availability of APIs and system performance. I had chance to write before about “legacy data import” as a one of the three major factors impacting mainstream PLM deployment.

Data Sources
I’d make a try to break down legacy data you can face during the implementation.

1. File Legacy
Existing document, drawings, CAD models, Office documents. In most of the cases, these are “un-managed data resources”, that need to be collected, analyzed, imported and stored into the system

2. Relational Databases
In today’s enterprise landscape, lots of data are located into RDBMS system. You can find lots of legacy data here – starting from early dBase tables and going up to various versions database formats and systems Connections to these systems in most of the cases is very straightforward via SQL-compliant driver or software.

3. Computer and Application Legacy
Often, you have systems that were implemented and used or continue to be used by company now. For some reasons, the access of their data storage is problematic. In this case, the only way is to access these applications via an available API or reverse engineer such data sources. Sometime, you can face old, but still functioning computer systems (mainframe is one of the best examples) that continue to operate and keep lots of valuable for organization information.

Import vs. Federation
These are two separate strategies about how to handle legacy data. You can keep the data in the original form and systems. You PLM system will be accessing the legacy data sources to get data, connect and transform it into a new form. The alternative option is to import data in a single shot into a new system. In this case, your legacy data becomes irrelevant, and you move into a new system. It is hard to say what is the best strategy. The situation needs to be estimated and assessed based on the system analyzes. However, I found legacy systems as something that very painful during implementation.

What is my conclusion? Legacy data is important. The amount of data is growing in the exponential manner. To handle legacy data and systems is a very painful task. Each time we come with new systems, the problem of legacy data comes up again. PLM needs to learn to handle foreign lifecycle data or lifecycle data produced by previous versions of PLM systems. It seems to me as a very important functionality that almost missed today. What is your opinion?

Best, Oleg


Follow

Get every new post delivered to your Inbox.

Join 73 other followers