Recent debate on Tech4PD brought back one of my favorite topics in PLM – data vs. process. The topic isn’t new, but it is not diminishing the importance. I found first appearance of my debates with Jim going to back in 2009. Navigate to the following link and read my old blog – PDM vs. PLM: Is it about the process? Another perspective on data vs. process in PLM was presented in my blog post – PLM: controversy about process vs. data managemen. The last one was inspired by Bell Helicopter presentation made during Dassault Customer Conference back in 2011.
Take a moment of time and watch the debate. I gave my vote to Jim. I like his broad perspective on setting organization on the right path with their working procedures. Jim also “packaged” his process opinion together with “file management”, which made me assume that engineers will be able to identify right versions of a specific file/design. What made me feel sad a bit with regards to Chad’s position is his wiliness to focus on how to control all data in PLM – something I have hard time to believe as needed and even possible. To me PLM cannot control all data, but should rely on technologies to make data available for decision (and not only) processes.
The debate made me think about why Data vs. Process is probably a wrong dilemma in the context of PLM. In my view, the right focus should be on “lifecycle” as a core value proposition of PLM and ability of PLM to support product development. In a nutshell, product development is about how to move product definition (in a broad sense of this word) from initial requirements and design to engineering and manufacturing. If I go future, next stages of product definition will be related to maintenance and disposal. To define what represent product on every stage together with what is required to move product from one stage to another is a core value of product lifecycle and PLM.
What is my conclusion? After many years of debates about data vs. processes, I think time came to get to the next mature level of understanding how to get PLM work for companies. The focus on product definition for every stage of product lifecycle bundled together with procedures or requirements needed in order to move between stages can be a new way to define what PLM is about. Just my thoughts…
PLM is all about process management. This statement comes to the play when people explain the value of PLM in the organization. Usually, when you think about process management, your mind is switching to some kind of “workflow thinking” mode, which assumes you need to follow the process from state to state by accomplishing tasks and activities. In every PLM implementation, this is a moment of time, people ask – how do we manage engineering processes? What toolset we need to have to make it happen?
I can see, engineering people, are bad organized. In many situations to run processes among engineers is similar to herding cats. To manage process in an engineering organization is a challenge. This is a place where PLM vendors usually fails to provide a reliable and simple solution. Engineers are asking for additional flexibility and vendors have a tendencies to provide a complicated solutions. Many PLM tools are providing sort of Workflow designer to create a process model. Later on, you can discover that engineers tend to abandon these processes. Main reason – these processes are not reflecting the reality. I wanted to come with some ideas how to fix that. I came up with the three definitions – tasks, engagement and information context. Take a look on the picture below.
The overall engineering process is described as list of tasks (above). This is the simplest way to present what needs to be done. It easy to digest and follow up. At the same time, the activity around this task list is not linear. In order to accomplish the task, an engineer needs to engage with additional people. This a typical situation when a person who leads the process needs to communicate with other people and comes with the result. Often, it is ad-hoc communication that cannot be formalized resides in people’s mind. Another situation happens when an engineer needs to bring an additional set of information to accomplish the task or make a decision. To combine these activities together is not a simple thing. Workflow is a wrong tool to solve this problem. To support a simplified task management tools with the ability to manage external engagement and connect to information context can be a potential solution to the problem.
What is my conclusion? The simplification is a key word to summarize my thoughts. In many situations, engineers will prefer a simple task list to get things done. However, tools need to provide a collaborative capabilities to connect the engineer’s activity to other people and additional sources of information. Just my thoughts. I’m interesting to learn how you manage engineering tasks in your organizations.
Free is the best future price. If you follow my blog, you probably had a chance to read this post three years ago. The world of software is very different nowadays. Trends such as open source, software as a services (SaaS), freemium – this is only a short list of new business models. Earlier this year, I had a chance to run panel discussion – The Future of PLM business models at PLM Innovation conference in Munich. You can take a look on my slides here.
One of the interesting trends these days is a shift from ownership to share and services. It happens in different fields. My best non-software example is Michelin selling miles instead of tires and Zipcar share-car service.
The following blog post by Kenesto caught my attention couple of days ago – How to price PLM in the cloud? Kenesto believes to innovate not only in cloud process management technologies, but also in the way this technology will be sold.
We believe that the cloud encourages changes to the way process automation software can — and should be — priced. So, we started from a clean sheet of paper when we decided how to price Kenesto. We don’t have legacy “seats” to preserve or boxes to push. We’ve not only changed the way process automation software works and is delivered, we also hope we have changed (for the better) the way people buy it.
In a nutshell, Kenesto is proposing companies to pay per bundle of processes. Pricing plans are available from 100 processes/month and up to 8000 processes/month. This process model made me think a bit differently about PLM pricing and process management, specifically. Do you want me to sell processes “by gallons” as a gas? My expectation that process management software will streamline processes in the organization. What does it mean? Improve processes doesn’t say much if company has more processes or fewer processes. Who is responsible to set “valid amount of processes” for any organization? Another question that this model generated is how to make software cost predictable. Imaging tomorrow engineer cannot open ECO because of process limit. Does it sound crazy? Who knows…
What is my conclusion? The idea of PLMometer with customer credit card connected to processes counter is an interesting one. It sounds similar to Google pay-per-click model. You can print money based on the amount of processes used by engineering and other people in the organization. Pay per click worked for Google. Will it work for Kenesto? – a good question to ask. Just my thoughts…