You are currently browsing the category archive for the ‘PLM’ category.

As I am preparing my presentation for the upcoming PDT Europe 2017 conference in Gothenburg, I was reading relevant experiences to a data-driven approach. During PDT Europe conference we will share and discuss the continuous transformation of PLM to support the Lifecycle Model-Based Enterprise. 

One of the direct benefits is that a model-based enterprise allows information to be shared without the need to have documents to be converted to a particular format, therefore saving costs for resources and bringing unprecedented speed for information availability, like what we are used having in a modern digital society.

For me, a modern digital enterprise relies on data coming from different platforms/systems and the data needs to be managed in such a manner that it can serve as a foundation for any type of app based on federated data.

This statement implies some constraints. It means that data coming from various platforms or systems must be accessible through APIs / Microservices or interfaces in an almost real-time manner. See my post Microservices, APIs, Platforms and PLM Services. Also, the data needs to be reliable and understandable for machine interpretation. Understandable data can lead to insights and predictive analysis. Reliable and understandable data allows algorithms to execute on the data.

Classical ECO/ECR processes can become highly automated when the data is reliable, and the company’s strategy is captured in rules. In a data-driven environment, there will be much more granular data that requires some kind of approval status. We cannot do this manually anymore as it would kill the company, too expensive and too slow. Therefore, the need for algorithms.

What is understandable data?

I tried to avoid as long as possible academic language, but now we have to be more precise as we enter the domain of master data management. I was triggered by this recent post from Gartner: Gartner Reveals the 2017 Hype Cycle for Data Management. There are many topics in the hype cycle, and it was interesting to see Master Data Management is starting to be taken seriously after going through inflated expectations and disillusionment.

This was interesting as two years ago we had a one-day workshop preceding PDT Europe 2015, focusing on Master Data Management in the context of PLM. The attendees at that workshop coming from various companies agreed that there was no real MDM for the engineering/manufacturing side of the business. MDM was more or less hijacked by SAP and other ERP-driven organizations.

Looking back, it is clear to me why in the PLM space MDM was not a real topic at that time. We were still too much focusing and are again too much focusing on information stored in files and documents. The only area touched by MDM was the BOM, and Part definitions as these objects also touch the ERP- and After Sales-  domain.

Actually, there are various MDM concepts, and I found an excellent presentation from Christopher Bradley explaining the different architectures on SlideShare: How to identify the correct Master Data subject areas & tooling for your MDM initiative. In particular, I liked the slide below as it comes close to my experience in the process industry

Here we see two MDM architectures, the one of the left driven from ERP. The one on the right could be based on the ISO-15926 standard as the process industry has worked for over 25 years to define a global exchange standard and data dictionary. The process industry was able to reach such a maturity level due to the need to support assets for many years across the lifecycle and the relatively stable environment. Other sectors are less standardized or so much depending on new concepts that it would be hard to have an industry-specific master.

PLM as an Application Specific Master?

If you would currently start with an MDM initiative in your company and look for providers of MDM solution, you will discover that their values are based on technology capabilities, bringing data together from different enterprise systems in a way the customer thinks it should be organized. More a toolkit approach instead of an industry approach. And in cases, there is an industry approach it is sporadic that this approach is related to manufacturing companies. Remember my observation from 2015: manufacturing companies do not have MDM activities related to engineering/manufacturing because it is too complicated, too diverse, too many documents instead of data.

Now with modern digital PLM, there is a need for MDM to support the full digital enterprise. Therefore, when you combine the previous observations with a recent post on Engineering.com from Tom Gill: PLM Initiatives Take On Master Data Transformation I started to come to a new hypotheses:

For companies with a model-based approach that has no MDM in place, the implementation of their Product Innovation Platform (modern PLM) should be based on the industry-specific data definition for this industry.

Tom Gill explains in his post the business benefits and values of using the PLM as the source for an MDM approach. In particular, in modern PLM environments, the PLM data model is not only based on the BOM.  PLM now encompasses the full lifecycle of a product instead of initially more an engineering view. Modern PLM systems, or as CIMdata calls them Product Innovation Platforms, manage a complex data model, based on a model-driven approach. These entities are used across the whole lifecycle and therefore could be the best start for an industry-specific MDM approach. Now only the industries have to follow….

Once data is able to flow, there will be another discussion: Who is responsible for which attributes. Bjørn Fidjeland from plmPartner recently wrote: Who owns what data when …?  The content of his post is relevant, I only would change the title: Who is responsible for what data when as I believe in a modern digital enterprise there is no ownership anymore – it is about sharing and responsibilities

 

Conclusion

Where MDM in the past did not really focus on engineering data due to the classical document-driven approach, now in modern PLM implementations, the Master Data Model might be based on the industry-specific data elements, managed and controlled coming from the PLM data model

 

Do you follow my thoughts / agree ?

 

 

Advertisements

At this moment there are two approaches to implement PLM. The most common practice is item-centric and model-centric will be potentially the best practice for the future. Perhaps your company still using a method from the previous century called drawing-centric. In that case, you should read this post with even more attention as there are opportunities to improve.

 

The characteristics of item-centric

In an item-centric approach, the leading information carrier is an item also known as a part. The term part is sometimes confusing in an organization as it is associated with a 3D CAD part. In SAP terminology the item is called Material, which is sometimes confusing for engineering as they consider Material the raw material. Item-centric is an approach where items are managed and handled through the whole lifecycle. In theory, an item can be a conceptual item (for early estimates), a design item (describing the engineering intent), a manufacturing item (defining how an item is consumed) and potentially a service item.

The picture below illustrates the various stages of an item-centric approach. Don’t focus on the structure, it’s an impression.

It is clear these three structures are different and can contain different item types. To read more about the details for an EBOM/MBOM approach read these post on my blog:

Back to item-centric. This approach means that the item is the leading authority of the product /part. The id and revision describe the unique object in the database, and the status of the item tells you in the current lifecycle stage for the item. In some cases, where your company makes configurable products also the relation between two items can define effectivity characteristics, like data effectivity, serial number effectivity and more. From an item structure, you can find its related information in context. The item points to the correct CAD model, the assembly or related manufacturing drawings, the specifications. In case of an engineering item, it might point towards approved manufacturers or approved manufacturing items.

Releasing an item or a BOM means the related information in context needs to validated and frozen too. In case your company works with drawings for manufacturing, these drawings need to be created, correct and released, which sometimes can be an issue due to some last-minute changes that can happen. The above figure just gives an impression of the potential data related to an item. It is important to mention that reports, which are also considered documents, do not need an approval as they are more a snapshot of the characteristics at that moment of generation.

The advantages of an item-centric approach are:

  • End-to-end traceability of information
  • Can be implemented in an evolutionary approach after PDM-ERP without organizational changes
  • It enables companies to support sharing of information
  • Sharing of information forces companies to think about data governance
    (not sure if a company wants to invest on that topic)

The main disadvantages of an item-centric approach are:

  • Related information on the item is not in context and therefore requires its own management and governance to ensure consistency
  • Related information is contained in documents, where availability and access is not always guaranteed

Still, the item-centric approach brings big benefits to a company that was working in a classical drawing-driven PDM-ERP approach. An additional remark needs to be made that not every company will benefit from an item-centric approach as typically Engineering-to-Order companies might find this method creating too much overhead.

The characteristics of Model-Centric

A model-centric approach is considered the future approach for modern enterprises as it brings efficiency, speed, multidisciplinary collaboration and support for incremental innovation in an agile way. When talking about a model-centric approach, I do not mean a 3D CAD model-centric approach. Yes, in case the product is mature, there will be a 3D Model serving as a base for the physical realization of the product.

However, in the beginning, the model can be still a functional or logical model. In particular, for complex products, model-based systems engineering might be the base for defining the solution. Actually, when we talk about products that interact with the outside world through software, we tend to call them systems. This explains that model-based systems engineering is getting more and more a recommended approach to make sure the product works as expected, fulfills all the needs for the product and creates a foundation for incremental innovation without starting from scratch.

Where the model-based architecture provides a framework for all stakeholders, the 3D CAD model will be the base for a digital thread towards manufacturing. Linking parameters from the logical and functional model towards the physical model a connection is created without the need to create documents or input-files for other disciplines. Adding 3D Annotations to the 3D CAD model and manufacturing process steps related to the model provides a direct connection to the manufacturing process.

The primary challenge of this future approach is to have all these data elements (requirements, functions, components, 3D design instances, manufacturing processes & resources to be connected in a federated environment (the product innovation platform). Connecting, versioning and baselining are crucial for a model-centric approach. This is what initiatives like Industry 4.0 are now exploring through demonstrators, prototypes to get a coherent collection of managed data.

Once we are able to control this collection of managed data concepts of digital twin or even virtual twin can be exploited linking data to a single instance in the field.

Also, the model can serve as the foundation for introduction incremental innovation, bringing in new features.  As the model-based architecture provides direct visibility for change impact (there are no documents to study), it will be extremely lean and cost-efficient to innovate on an existing product.

Advantages of model-centric

  • End-to-end traceability of all data related to a product
  • Extremely efficient in data-handling – no overhead on data-conversions
  • Providing high-quality understanding of the product with reduced effort compared to drawing-centric or item-centric approaches
  • It is scalable to include external stakeholders directly (suppliers/customers) leading to potential different, more beneficial business models
  • Foundation for Artificial Intelligence at any lifecycle step.

Disadvantages of model-centric

  • It requires a fundamentally different way of working compared to past. Legacy departments, legacy people, and legacy data do not fit directly into the model-centric approach. A business transformation is required, not evolution.
  • It is all about sharing data, which requires an architecture that is built to share information across Not through a service bus but as a (federated) platform of information.
    A platform requires a strong data governance, both from the dictionary as well as authorizations which discipline is leading/following.
  • There is no qualified industrial solution from any vendor yet at this time. There is advanced technology, there are demos, but to my knowledge, there is no 100% model-centric enterprise yet. We are all learning. Trying to distinguish reality from the hype.

 

Conclusions

The item-centric approach is the current best practice for most PLM implementations. However, it has the disadvantage that it is not designed for a data-driven approach, the foundation of a digital enterprise. The model-centric approach is new. Some facets already exist. However, for the total solution companies, vendors, consultants, and implementers are all learning step-by-step how it all connects. The future of model-centric is promising and crucial for survival.

Do you want to learn where we are now related to a model-centric approach?
Come to PDT2017 in Gothenburg on 18-19th October and find out more from the experts and your peers.

During my summer holidays, I read some fantastic books to relax the brain. Confessions from Jaume Cabré was an impressive novel, and I finished Yuval Noah Harari’s book Sapiens.

However, to get my PLM-twisted brain back on track, I also decided to read the book “The Death of Expertise” from Tom Nichols, with the thought-provoking subtitle” “The Campaign Against Established Knowledge and Why it Matters.”

I wanted to read it and understand if and how this would apply for PLM.

Tom Nichols is an American, so you understand he has many examples to support his statement from his own experience, like the anti-vaccination “experts”,  the climate change “hoax” and an “expert” tweeting president in his country who knows everything. Besides these obvious examples, Tom explains in a structured way how due to more general education and the internet, the distance between an expert and a average person has disappeared and facts and opinions seem to be interchangeable. I talked about this phenomena during the Product Innovation conference in Munich 2016: The PLM identity crisis.

Further down the book, Tom becomes a little grumpy and starts to complain about the Internet, Google and even about Wikipedia. These information resources provide so often fake or skin-deep information, which is not scientifically proven by experts. It reminded me of a conference that I attended in the early nineties of the previous century.  An engineering society had organized this conference to discuss the issue that finite element analysis became more and more available to laymen. The affordable simulation software would be used by non-trained engineers, and they would make the wrong decisions. Constructions would fall down, machines would fail. Looking back now, we can see the liberation of finite element analysis leads to more usage of simulation technology providing better products and when really needed experts are still involved.

I have the same opinion for internet, Google, and Wikipedia. They rapidly provide information. Still, you need to do fact checking and look at multiple sources, even if you found the answer that you liked already. Usually, when I do my “research” using the internet, I try to find different sources with different opinions and if possible also from various countries. What you will discover is that, when using the internet, there is often detailed information, but not in the headlines of these pages. To get down to the details, we will need experts for certain cases, but we cannot turn the clock back to the previous century.

What about PLM Expertise?

In the case of PLM, it is hard to find real expertise. Although PLM is recognized as a business strategy / a domain / an infrastructure , PLM has so many faces depending on the industry and its application. It will be hard to find an expert who understands it all and I assume headhunters can confirm this. A search for “PLM Consultant” on LinkedIn gives me almost 4000 hits, and when searching for “PLM Expert,” this number is reduced to less than 200. With only one source of information (LinkedIn), these figures do not really give an in-depth result (as expected !)

However, what is a PLM expert? Recently I wrote a post sharing the observation that a lot of PLM product – or IT-focused discussions miss the point of education (see PLM for Small and Medium Enterprises – It is not the software). In this post, I referred to an initiative from John Stark striving for the recognition of a PLM professional. You can read John’s follow up on this activity here: How strong is the support for Professional PLM?  Would a PLM Professional bring expertise?

I believe when a company understands the need for PLM, they have to build this knowledge internally. Building knowledge is a challenge for small and medium enterprises. It is a long-term investment contributing to the viability of the company. Support from a PLM professional can help. However, like the job of a teacher, it is about the skill-set (subjects, experience) and the motivational power of such a person. A certificate won’t help to select a qualified person.

Conclusion

We still need PLM expertise, and it takes time to build it. Expertise is something different as an (internet) opinion. When gaining PLM expertise, use the internet and other resources wisely. Do not go for the headlines of an internet page. Go deeper than the marketing pages from PLM related companies (vendors/implementers). Take time and hire experts to help you, not to release you from your responsibility to collect the expertise.

 

Note: If you want to meet PLM Experts and get a vendor-independent taste of PLM, join me at PDT Europe 2017 on 18-19 October in Gothenburg.  The theme of the conference: Continuous transformation of PLM to support the Lifecycle Model-Based Enterprise.  The conference is preceded on 17th October by CIMdata’s PLM Roadmap Europe 2017. Looking forward to meet you there !

 

 

PLM holiday thoughts

July and August are the months that privileged people go on holiday. Depending on where you live and work it can be a long weekend or a long month. I plan to give my PLM twisted brain a break for two weeks. I am not sure if it will happen as Greek beaches always have inspired for philosophers. What do you think about “PLM on the beach”?

There are two topics that keep me intrigued at this moment, and I hope to experience more about them the rest of the year.

Moving to Model-Based processes

I believe we all get immune for the term “Digital Transformation” (11.400.000 hits on Google today). I have talked about digital transformation in the context many times too. Change is happening. The classic ways of working were based on documents, a container of information, captured on paper (very classical) or captured in a file (still current).

As every stakeholder in a company (marketing, engineering, manufacturing, supplier, services, customers, and management) required a different set of information, many pieces of information all referring to the same product, have been parsed and modified into other documents.  It is costly and expensive to get a complete view of what is happening in the business. Meanwhile, all these information transformations (with Excel as the king) are creating an overhead for information management, both on IT-level and even more for non-value added resources who are manipulating information for the next silo/discipline.

What we have learned from innovative companies is that a data-driven approach, where more granular information is stored uniquely as data objects instead of document containers bring huge benefits. Information objects can be shared where relevant along the product lifecycle and without the overhead of people creating and converting documents, the stakeholders become empowered as they can retrieve all information objects they desire (if allowed). We call this the digital thread.

The way to provide a digital thread for manufacturing companies is to change the way they organize the product development and delivery processes. A model-based approach is required. I wrote about in a post: Digital PLM requires a Model-Based Enterprise a year ago. The term “Model-Based” also has many variations (67.800.00 hits on Google today). Some might consider the 3D MCAD Model at the center of information both for engineering and manufacturing.A good overview in the video below

Others might think about a behavior/simulation model of the product for simulating and delivering a digital twin often referred in the context of model-based design (MBD).

And ultimately a model-based approach integrated with systems engineering into Model-Based Systems Engineering (MBSE) allowing all stakeholders to collaborate in a data-driven manner around complex products based.

You can learn a lot about that during the upcoming PDT Europe conference on 18-19th October in Gothenburg. Concepts and experiences will be shared, and my contribution to the conference will be all about the challenges and lessons learned from the transformation process companies are embarking on becoming model-based.

PLM and ALM

A second topic that becomes more and more relevant for companies is how to combine the domains of product development and application software empowering these products. The challenge here is that we have no mature concepts yet for both domains. It reminds me of the early PDM implementations where companies implemented their PDM system for MCAD software and documents. All the electrical stuff was done disconnected in separate systems and somewhere in the product lifecycle information from MCAD and ECAD was merged in the bill of materials and documents. Mainly manually with a decent overhead for people consolidating the data.  Modern PLM systems have found best practices to manage a combination of mechanical and electronic components through an EBOM even connecting embedded software as an item in the BOM.

Now more and more the behavior and experience of products are driven by software. Sensors and connectivity of data are driving new capabilities and business models to the market. Customers are getting better connected, however also the companies delivering these solutions can act much faster now based on trends or issues experienced from the field.

The challenge, however, is that the data coming from the systems and the software defining the behavior of the products most of the time is managed in a separate environment, the ALM environment. In the ALM environment delivery of new solutions can be extremely fast and agile, creating a disconnect between the traditional product delivery processes and the software delivery processes.

Companies are learning now how to manage the dependencies between these two domains, as consistency of requirements and features of the products is required. Due to the fast pace of software changes, it is almost impossible to connect everything to the PLM product definition. PLM Vendors are working on concepts to connect PLM and ALM through different approaches. Other companies might believe that their software process is crucial and that the mechanical product becomes a commodity. Could you build a product innovation platform starting from the software platform which some of the old industry giants believe?

PLM combined with ALM concepts are the ones to follow, and I am looking forward to meeting the first company that has implemented a consistent flow between the world of hardware and software. So far there are many slide solutions, the reality and legacy at this moment are still inhibitors for the next step.

Conclusion

There is still a lot to discover and execute in the domain of PLM. Moving to a data-driven enterprise with all stakeholders connected is the challenging journey. Can we build robust concepts taking accuracy, security, and speed into account? I believe so, in particular when dreaming at the beach.

 

Bye for now

Does history repeat itself even in the PLM domain? The last week I have read various blog posts related to PLM and Small and Medium Enterprises (SME). A good summary of these thoughts can be found in  Oleg Shilovitsky’s post: How PLM vendors can find a formula to serve midsize manufacturing companies. Usually, the conclusions are:

  • Smaller enterprise cannot afford the “expensive” PLM solutions
  • Existing PLM systems are too complex to implement
  • Lack of usability
  • PLM systems are not flexible enough to implement
  • PLM should be cloud-based (reducing IT costs and efforts).

Jim Brown from Tech-Clarity published an e-book Finding PLM to Fit Mid-Sized High-Tech Companies and Oleg chimed in on that post as Jim talks about Core PLM, which was more design-oriented than BOM-oriented. Read these two posts as they give a good insight into PLM vendor thinking.

In 2006, Oleg and I worked @ SmarTeam where we defined and built a “Core PLM” solution, targeting mid-market companies. This core PLM solution called the SmarTeam Engineering Express (SNE) contained both pre-configured CAD-integrations as well as BOM practices (EBOM-MBOM).  Combined with documented best practices, pre-configured methodology, and workflows this environment could be implemented relatively quick (if the implementer did not want to earn extra money on services ).

There was even ROI provided by a launching customer:  A PLM success story with ROI (2012)

As part of the SME focus, SmarTeam people interviewed small and medium enterprises to understand in detail their needs. They mentioned the obvious points:

  • Easy to Use (Usability)
  • Quickly Deployable (Best Practices – pre-defined processes)
  • Easy & rapid Configurable and low IT-costs.

Interesting enough SmarTeam’s enterprise customers requested the same capabilities. It makes you realize there is no unique difference in PLM for mid-market companies and large enterprises. I believe the major difference is due to education, the company’s culture and where the PLM decision is made. Let’s explore

Lack of education

Small and Medium Enterprises usually lack resources who can spend time on planning or think about a new business strategy. The work needs to be done first. SME companies hire experts for their skills that bring immediate value, strategic thinking comes second. An engineering department does not hire a strategist; they hire a qualified and promising engineer.

These new hires are normally not educated on standard PLM concepts like ECR, ECO, Configuration Management, PLM-ERP best practices (EBOM/MBOM). For an engineering study, these practices/processes are not considered as critical as it is about collaboration and not about skills. The PLM capabilities engineering students learn are the basic functionalities they need master when working with their (CAD) tools.

SME’s use their own best practices based on years of experience (before PLM existed) and when they select a PLM system, it is mostly more a data management tool than an infrastructure to streamline processes. Combined with the fact that every PLM vendor has its own definition for PLM, it is hard to have a unified way of thinking for bring in new ways of working supported by a best in class PLM-system. The lack of standards and education is illustrated by a recent post from John Stark: Should PLM become a profession?

Of course, you can educate yourself on PLM. CIMdata is well-known for its training program, John Stark and others can educate you on PLM. Have a look at this interesting new startup SharePLM. PLM is about sharing, and I try to share PLM experiences too, by coaching or lecturing or through my blog posts. My most read posts over the past years are ECO/ECR for Dummies, The importance of a PLM data model: EBOM – MBOM and Bill of Materials for Dummies – ETO. Illustrating people around the world want to be educated on PLM but can the influence their (non-educated) management?

SME management considers PLM as an engineering tool. They want their employees to work with the best tools, and the management’s focus is on reducing costs and improving efficiency. Different ways of working or different business models, enabled by digitalization are not necessary on the SME management agenda. However, with the digital revolution is on its way, strategical thinking becomes crucial for survival. In that context, a recent post from Beth Stackpole on Digital Engineering says it all: PLM Knowledge Gap Hampers New Engineers.

Difference in culture

Small and Medium Enterprise often rely on close collaboration between people all working with their best in class tools per discipline. Collaboration is done through email, personal relations, and Dropbox-like sharing tools. They know their peers and people rely on intrinsic knowledge.

 

Large enterprise often consists of a collection of business units that could be considered as Small and Medium Enterprises. To create synergies and gain IT-benefits, management from large enterprises want to standardize on processes (naming and steps) and tools. Standardized processes allow the management to compare and benchmark the Business Units. Standardized tools, of course, reduce the overall IT costs.

Large enterprises usually have staff with a strategic task to work on standardized and optimized processes for the future. These people will discover and have time to be educated on the values of PLM, supported by strategic advisors that know the value of PLM. In these companies, the decisions made for PLM are top-down decisions. Usability, functions/features and costs are usually crucial for bottom-up decisions. For a top-down decision an aligned vision, matching roadmap, management value and costs are usually the main topics.

Conclusion

Ten years ago I believed Small and Medium Enterprises would benefit from a special offering with a focus on usability, pre-configured environments and providing best practices. I believe this is now on the agenda for all PLM vendors, some perhaps struggling with their legacy. However, cloud offerings will become more and more similar. Therefore, PLM education is in my opinion still a missing point in SME. Educated management and educated students could increase the value delivery of PLM by understanding the right target and managing the expectations correctly.

What do you think? Will there ever be the best-in-class PLM offering for SME or do you believe the human factor where education and understanding are crucial?  Looking forward to your opinion !

Last week I published a dialogue I had with Flip van der Linden, a fellow Dutchman and millennial, eager to get a grip on current PLM. You can read the initial post here: A PLM dialogue.  In the comments, Flip continued the discussion (look here).  I will elaborate om some parts of his comments and hope some others will chime in. It made me realize that in the early days of blogging and LinkedIn, there were a lot of discussions in the comments. Now it seems we become more and more consumers or senders of information, instead of having a dialogue. Do you agree? Let me know.

Point 1

(Flip) PLM is changing – where lies the new effort for (a new generation of) PLM experts.  I believe a huge effort for PLM is successful change management towards ‘business Agility.’ Since a proper response to an ECR/ECO would evidently require design changes impacting manufacturing and even after-sales and/or legal.  And that’s just the tip of the iceberg.

 

You are right, the main challenge for future PLM experts is to explain and support more agile processes, mainly because software has become a major part of the solution. The classical, linear product delivery approach does not match the agile, iterative approach for software deliveries. The ECR/ECO process has been established to control hardware changes, in particular because there was a big impact on the costs. Software changes are extremely cheap and possible fast, leading to different change procedures. The future of PLM is about managing these two layers (hardware/software) together in an agile way. The solution for this approach is that people have to work in multi-disciplinary teams with direct (social) collaboration and to be efficient this collaboration should be done in a digital way.

A good article to read in this context is Peter Bilello’s article: Digitalisation enabled by product lifecycle management.

 

(Flip) What seems to be missing is an ‘Archetype’ of the ideal transformed organization. Where do PLM experts want to go with these businesses in practice? Personally, I imagine a business where DevOps is the standard, unique products have generic meta-data, personal growth is an embedded business process and supply chain related risks are anticipated on and mitigated through automated analytics. Do you know of such an evolved archetypal enterprise model?

I believe the ideal archetype does not exist yet. We are all learning, and we see examples from existing companies and startups pitching their story for a future enterprise. Some vendors sell a solution based on their own product innovation platform, others on existing platforms and many new vendors are addressing a piece of the puzzle, to be connected through APIs or Microservices. I wrote about these challenges in Microservices, APIs, Platforms and PLM Services.  Remember, it took us “old PLM experts” more than 10-15 years to evolve from PDM towards PLM, riding on an old linear trajectory, caught up by a new wave of iterative and agile processes. Now we need a new generation of PLM experts (or evolving experts) that can combine the new concepts and filter out the nonsense.

Point 2

(Flip) But then given point 2: ‘Model-based enterprise transformations,’ in my view, a key effort for a successful PLM expert would also be to embed this change mgt. as a business process in the actual Enterprise Architecture. So he/she would need to understand and work out a ‘business-ontology’ (Dietz, 2006) or similar construct which facilitates at least a. business processes, b. Change (mgt.) processes, c. emerging (Mfg.) technologies, d. Data structures- and flows, e. implementation trajectory and sourcing.

And then do this from the PLM domain throughout the organization per optimization.  After all a product-oriented enterprise revolves around the success of its products, so eventually, all subsystems are affected by the makeup of the product lifecycle. Good PLM is a journey, not a trip. Or, does a PLM expert merely facilitates/controls this enterprise re-design process? And, what other enterprise ontologism tools and methods do you know of?

Only this question could be a next future blog post. Yes, it is crucial to define a business ontology to support the modern flow of information through an enterprise. Products become systems, depending on direct feedback from the market. Only this last sentence already requires a redefinition of change processes, responsibilities. Next, the change towards data-granularity introduces new ways of automation, which we will address in the upcoming years. Initiatives like Industry 4.0 / Smart Manufacturing / IIoT all contribute to that. And then there is the need to communicate around a model instead of following the old documents path. Read more about it in Digital PLM requires a Model-Based Enterprise. To close this point:  I am not aware of anyone who has already worked and published experiences on this topic, in particular in the context of PLM.

 

Point 3

(Flip) Where to draw the PLM line in a digital enterprise? I personally think this barrier will vanish as Product Lifecycle Management (as a paradigm, not necessarily as a software) will provide companies with continuity, profitability and competitive advantage in the early 21st century. The PLM monolith might remain, but supported by an array of micro services inside and outside the company (next to IoT, hopefully also external data sets).

I believe there is no need to draw a PLM line. As Peter’s article: Digitalisation enabled by product lifecycle management already illustrated there is a need for a product information backbone along the whole (circular) lifecycle, where product information can interact with other enterprise platforms, like CRM, ERP and MES and BI services. Sometimes we will see overlapping functionality, sometimes we will see the need to bridge the information through Microservices. As long as these bridges are data-driven and do not need manual handling/transformation of data, they fit in the future, lean digital enterprise.

Conclusion:

This can be an ongoing dialogue, diving into detailed topics of a modern PLM approach. I am curious to learn from my readers, how engaged they are in this topic? Do you still take part in PLM dialogues or do you consume? Do you have “tips and tricks” for those who want to shape the future of PLM?


Let your voice be heard! (and give Flip a break)

 

elevator_thumb.jpgRecently I connected with a fellow countryman, Flip, through LinkedIn and we had a small dialogue related to PLM. Flip describes himself as a millennial thinking loud about PLM and shared some of his thoughts trying to define “the job of PLM.” Instead of keeping it a Dutch dialogue, I would like to open the dialogue to all (millennials), as we need a new generation of PLM consultants

Point 1

observation_thumb.png(Flip) You cannot automate design activities easily, but the rest you can. Isn’t PLM an evolution of 3D Design tooling (and with that the next step in design – theory)

think_thumb.pngYou are right. Historically PLM originated from managing 3D design in a collaborative manner, although at that time we would call it cPDM (Collaborative Product Data Management).  PDM was very design focused. However, PDM also supported the connection to an Engineering Bill of Materials (EBOM) and connected engineering change processes (Engineering Change Request / Engineering Change Order – read more: ECR/ECO for Dummies)

PTC’s Windchill was the first modern cPDM software that still exists. At the same time, Dassault Systemes and Siemens extended the support for design towards the manufacturing planning and execution, introducing the term PLM (Product Lifecycle Management). In the following years, PLM systems started to support the full go-to-market lifecycle as the figure shows below.

lifecycle

This linear go-to-market process is currently rapidly changing because PLM is changing.

plm_txt_thumb.pngThe P standing for Product now represents a System (hardware & software interacting with the environment). The L standing for Lifecycle is also under change.

Support for the Lifecycle of a “product” has changed in two ways. First, the lifecycle is no longer going to be a linear process, but also be more iterative and incremental for the same “product.” Secondly, the lifecycle is stretched to support the “products” in the fields thanks to feedback from sensors (IoT – Internet of Things). That’s why PTC now claims IoT is PLM. Read more: Best Practices or Next Practices.

Finally, the M from Management is under change as thanks to a data-driven approach we should be able to (semi-)automate processes using algorithms. Favorite buzz words here are machine-learning, cobots (collaborative robots) and preventive actions thanks to data analysis & trends.

Point 2

observation_thumb.png (Flip) Storing data in a structured manner creates more complexity (you need to choose what to store). With simulation, complexity could be reduced to make meaningful (design) decisions, so PLM is about clever data hoarding?

image_thumb.pngI believe there is always a challenge with managing structured data for two reasons. People often only create the data they require.  Adding more context more data or a richer context is often considered “extra work,” for with the department is not rewarded or adding more data is not known as these persons do not know the future use of their information. This is a typical exercise for companies now engaging in a digital transformation. (read more: The importance of accurate data)

think_thumb.pngWhen you talk about simulation, I immediately thought about the current trend to work towards a model-based enterprise, where the model is the center of all information. And with the model, we do not only mean the 3D Model but also the functional and logical model which we can simulate. (Read more: Digital PLM requires a Model-Based Enterprise)

Point 3

observation_thumb.png(Flip) Automation from manufacturing with more and more resources requires new ways to drive manufacturing so a team of 8 people can do the work of 80 people through a PLM system?

Industry4Here you are addressing exactly the point that initiatives like Industry 4.0 or in the Netherlands Smart Industry are addressing. Instead of a linear, document-driven process, where each step new versions of information need to be created, the dream is to work around a model (the model-based enterprise).

The idea is that data is flowing through the organization – digital continuity / digital thread – without conversion and by using algorithms and machine learning, the data is consumed and created during the manufacturing process in an automated manner. Indeed, reducing the amount of people involved drastically.

think_thumb.pngI am not sure of we still would call this PLM, it is more a digital enterprise, where digital platforms interact together. PLM could be considered the source for the Product Innovation Platform, but there will also be Execution platforms (ERP and MES as the main source) and customer related platform (CRM as a source). As vendors from all these platforms will provide overlapping functionality, it will be hard to draw exact lines. The main goal for a company will be that the data is flowing and not locked into a proprietary format or systems. And here we still have a lot of work to do,

Conclusion

No conclusion this time as it is an on-going dialogue. Feel free to comment or send your questions, and we can all learn from the dialogue (always better than a monologue).

Your thoughts?

This time a post, imagining the future of a PLM infrastructure for companies embracing the concepts of a digital enterprise. When you read (marketing) posts on the internet a lot of well-known companies are proud about their digital customer platform in the cloud. These platforms are a typical example of how companies transform their business to be closer connected to their customers. And to be as close as possible to the client, the apps they provide on the platform provides the customer with “delightful” experiences, information and usability they never have seen before. Meanwhile, the hosting company benefits from collecting all the data from their customers to better understand the behavior and use cases of their clients. A win-win situation, don’t you think so?

Microservices and APIs

In order to enhance and enrich the customer experience and the internal efficiency, companies are digitizing their back office processes too. Connecting their suppliers and vendors in a digital manner, optimizing processes from paper-based, through file-based towards a digital, data-driven process. The advantages: “high-speed” and “high quality and rich context” delivered with a lower cost than currently.

As it is not easy to change existing enterprise business systems. A service oriented architecture (SOA) based on web-services is used to connect enterprise business systems in a structured manner. A SOA-architecture is used when the systems and processes are stable.

However, all companies are discovering the modern digital enterprise, and here nothing is permanent and most likely nothing with remain stable. You will see companies making data available from various systems through APIs (Application Program Interface). In the past the meaning of API was directly tied to one system, now it is a wider concept, read for example  APIs for Dummies)

The usage of Micro Services allows companies to provide consumers (internal and external) with an experience based on an API layer with data coming from various sources. The user does not care and benefits from almost real-time information in the right context of the microservice. For more detail read: The difference between microservices and web services

Where it is easy for companies to create new experiences for their customers and internal employees through Apps on a platform and the usage of Micro Services, it is natural to extend this thought process toward the world of product data, the PLM domain. When I visit companies with an excellent digital image towards their customers, I am most of the time surprised to see their PLM environment still based on previous century’s concepts. And there is a reason for that, read my recent post: Why PLM is the forgotten domain in digital transformation.

PLM services?

Five years ago there was an interesting debate on engineering.com following upon a discussion between Jim Brown and Chad Jackson with the theme: Granularity vs. Integration: Suites vs. Best-in-class PLM. The power of this episode comes from the discussion afterwards that it is clear two different viewpoints exist, which will not easily merge. Read the comments if you have time.

Now the discussion has become similar for future PLM. Should you use best-of-breed, powerful cloud PLM-services to build an end-to-end connected PLM journey for the customer and the company?  Or should you still need one platform with apps (ideally coming from the best-of-breed vendors)?

You can find examples of cloud-based services popping up since a few years. I wrote about them in the past: The Netherlands and PLM. 2 events – 2 extremes – 1 future. In this post from 2015 I was pessimistic about the progress in the construction industry and confident about the startups I met to build an end-to-end customer experience through cloud solutions (KE-works, TradeCloud integrated with traditional PDM (Autodesk based) through web-services. Others like Kimonex, BOM management for product design, did not get enough momentum. And of course at this moment, OnShape (full cloud CAD) and OpenBOM (cloud-based Bill of Material management), For sure there are more if you do your research a little further.

On the other side, PLM-platforms can be found from the classical PLM vendors, Dassault Systemes, Siemens PLM and PTC have their platforms coming from the classical PLM world, all with some different variations in focus. Aras and Autodesk do not rely necessary on the classical engineering environments and position themselves as a new, modern PLM.

And of course there are other platforms that provide PLM functionality, like traditionally SAP and Oracle, but also Propel on Salesforce. These platforms come from an ERP / CRM side of the business and can be interesting for companies too, depending on their primary business processes.

We will discover in the next 5-10 years how these various offerings will evolve and survive, knowing the PLM world is extremely slow. Read also; PLM and Cultural Change Management. Too Expensive ?

IP and Traceability questions

What I am curious to learn from the new PLM-services providers is how they will manage their customer’s data with IP protection and Traceability.  Companies are always worries about their IP and their IP can be in various domains, not only design or engineering. It can be manufacturing IP or even customer relation’s IP. How would a company maintain an overview of all its IP? Do they need to add a new “service”, called IP Services? (Perhaps an idea for a next startup ?)
Besides IP protection many manufacturing companies have the duty to keep their data available for 5 – 10 – 25 – 50 years, depending on their industry. Here I am also curious to learn what is the exit strategy for using a PLM service. Imagine the PLM service company is purchased by a company you cannot work with (new prices / new polices). How easy is it to step out and stop your subscription? And what is the alternative? Falling back on a classical PLM platform?

To my opinion you can divide these PLM Services in two groups:

  • PLM services that perform clever activities (algorithms / analysis) on your data and provides the company with feedback. This could be BOM compliance services, automated workflows, configurators or simulation services. This group of PLM services provide process support to be more efficient and scaleable, but they leave the data under control of the company.
  • PLM services that store data from the customer, CAD Models, Bill of Materials, Manufacturing Operations, Issues, Workflows. What happens when you stop using these services? Is there an “easy” exit strategy through standards? Are there standards?

Conclusion

The PLM domain is a different domain than other enterprise data as is deals also with data that needs to remain available for IP protection and traceability. Using an analogy of Micro Services or APIs is an unexplored already for PLM service provides, with serious risks for the customer. We are no longer worried about up-time of the cloud, but more worried about who owns the data and how can I maintain my ownership as company.

cloud.jpgLooking forward to your point of view !

Although I have a PLM-twisted brain, I try to read in my free time books and articles that have no direct link with PLM. My main interest goes to people. How do they behave and decide in a society, in a company? What makes them decide to change an existing business?

SapiensI am currently reading the book from Yuval Noah Harari, called Sapiens: A Brief History of Humankind. I still have to finish the book but got intrigued by the following text when he tried to explain why homo sapiens was able to motivate and mobilize larger groups than a tribe:

How did Homo sapiens manage to a critical threshold, eventually founding cities comprising tens of thousands of inhabitants and empires ruling hundreds of millions? The secret was probably the appearance of fiction. Large numbers of strangers can cooperate successfully by believing in common myths.

Here my PLM-twisted brain woke up. What if we could create a  digital PLM myth? Currently, a lot of the PLM arguments are about functions and features, technical capabilities and perceived Return On Investment (ROI). For a digital transformation ROI is hard to estimate as the future state is not known and stable. What if the future state is a myth?  I will think about it when I finish the book and write the myth 🙂

Meanwhile, the rest of this blog post will be a reprint of a post I wrote almost five years ago in a similar context. PLM (old and new) are concepts against our evolution history. Enjoy and discover.

Our brain blocks PLM acceptance (Aug 2012)

tacit_logo.pngThe brain has become popular in the Netherlands in the past two years. Brain scientists have been publishing books sharing their interpretations on various topics of human behavior and the brain.

The common theme of all: The brain is influencing your perceptions, thoughts, and decisions without you even being aware of it.

clip_image005.jpg< added this post: in April 2013 Daniel Kahneman published his book Thinking Fast and Slow I referred in my post from May 2014 to this book – PLM is doomed, unless …>

Some even go that far by claiming certain patterns in the brain can be a proof if you have a certain disorder. It can be for better or for worse.

“It was not me that committed this crime; it was my brain and more…”

Anyway, this post will be full of quotes as I am not the brain expert, still giving the brain an important role (even in PLM)

Our brain blocks PLM acceptance

“My brain? That´s my second favorite organ” – Woody Allen

It is good to be aware of the influence of the brain. I wrote about this several times in the past, when discussing PLM vendor/implementer selection or when even deciding for PLM. Many of my posts are related to the human side of justifying and implementing PLM.

As implementing PLM for me primary is a business change instead of a combination of IT-tools to implement, it might be clear that understanding the inhibitors for PLM change are important to me.

In the PLM communities, we still have a hard job to agree between each other what is the meaning of PLM and where it differs from ERP. See for example this post, and in particular, the comments on LinkedIn (if you are a member of this group): PLM is a business process, not a (software) tool

Moreover, why it is difficult for companies to implement PLM beside ERP (and not as an extension of ERP) – search for PLM and ERP and you find zillions of thoughts and answers (mine too).

Charles_Roxburgh.jpgThe brain plays a major role in the Why PLM we have ERP battle (blame the brain). A week ago I read an older publication from Charles Roxburgh (published in May 2003 by McKinsey) called: Hidden flaws in strategy subtitle: Can insights from behavioral economics explain why good executives back bad strategies.

COULD read, hear and download the full article when you are a registered user. Unfortunate the link has been broken now>

The article has been written long before the financial and global crises were on the agenda and Mr. Roxburgh describes 8 hidden flaws that influence our strategic decision making (and PLM is a strategy).  Note all quotes below are from his publication.

Flaw 1: Overconfidence

We often make decisions with too much confidence and optimism as the brain makes us feel overconfident and overoptimistic about our own capabilities.

Flaw 2: Mental accounting

Avoiding mental accounting traps should be easier if you adhere to a basic rule: that every pound (or dollar or euro) is worth exactly that, whatever the category. In this way, you will make sure that all investments are judged on consistent criteria and be wary of spending that has been reclassified. Be particularly skeptical of any investment labeled “strategic.”

Here I would relate to the difference in IT-spending and budget when you compare ERP and PLM. ERP spending is normal (or strategic) where PLM spending is not understood.

Flaw 3: The status quo bias

People would rather leave things as they are. One explanation for the status quo bias is an aversion to loss—people are more concerned about the risk of loss than they are excited by the prospect of gain.

Another reason why adopting and implementing PLM in an organization is more difficult than for example just automating what we already do.

Flaw 4: Anchoring

Anchoring can be dangerous—particularly when it is a question of becoming anchored to the past

PLM has been anchored with being complex and expensive. Autodesk is trying to change the anchoring. Other PLM-like companies stop talking about PLM due to the anchoring and name what they do differently: 3DExperience, Business Process Automation, …..

Flaw 5: The sunk-cost effect

A familiar problem with investments is called the sunk-cost effect, otherwise known as “throwing good money after bad.” When large projects overrun their schedules and budgets, the original economic case no longer holds, but companies still keep investing to complete them.

I have described several cases in the past anonymously; where companies kept on investing and customizing their ERP environment to achieve PLM goals. Although it never reached the level of acceptance and quality a PLM system could offer, stopping these projects was impossible.

Flaw 6: The herding instinct

This desire to conform to the behavior and opinions of others is a fundamental human trait and an accepted principle of psychology.

Warren Buffett put his finger on this flaw when he wrote, “Failing conventionally is the route to go; as a group, lemmings may have a rotten image, but no individual lemming has ever received bad press.”

A quote in a quote but so true. Innovative thinking, introducing PLM in a company requires a change. Who needs to be convinced? If you do not have consensus (which usually happens as PLM is vague) you battle against the other lemmings.

Flaw 7: Misestimating future hedonistic states

Social scientists have shown that when people undergo major changes in circumstances, their lives typically are neither as bad nor as good as they had expected—another case of how bad we are at estimating. People adjust surprisingly quickly, and their level of pleasure (hedonistic state) ends up, broadly, where it was before

A typical situation every PLM implementation faces: users complaining they cannot work as efficient anymore due to the new system and their work will be a mess if we continue like this. Implementers start to customize quickly, and we are trapped. Let these people ‘suffer’ with the right guidance and motivation for some months (but this is sometimes not the business model the PLM implementer pushes as they need services as income)

Flaw 8: False consensus

People tend to overestimate the extent to which others share their views, beliefs, and experiences—the false-consensus effect. Research shows many causes, including these:

  • confirmation bias, the tendency to seek out opinions and facts that support our own beliefs and hypotheses

  • selective recall, the habit of remembering only facts and experiences that reinforce our assumptions

  • biased evaluation, the quick acceptance of evidence that supports our hypotheses, while contradictory evidence is subjected to rigorous evaluation and almost certain rejection; we often, for example, impute hostile motives to critics or question their competence

  • group-think, the pressure to agree with others in team-based cultures

Although positioned as number 8 by Mr. Roxburgh, I would almost put it on the top when referring to PLM and PLM selection processes. So often a PLM decision has not been made in an objective manner, and PLM selection paths are driven to come to the conclusion we already knew. (Or is this my confirmation bias too )

Conclusion

As scientists describe, and as Mr. Roxburgh describes our strategic thinking is influenced by the brain, and you should be aware of that. PLM is a business strategy and when rethinking your PLM strategy tomorrow, be prepared to avoid these flaws mentioned in this post today.

simpleMy recent posts were around the words Simple (PLM is not simple) and Simplicity  (Human Beings, PLM and Simplicity).  Combined with a blog dialogue with Oleg Shilovitsky (Small manufacturers and search of simple solutions)  and comments to these posts, the theme Simple has been discussed in various ways. Simple should not be confused with Simplicity. The conclusion: A PLM implementation should reduce complexity for an organization, aiming for increasing simplicity. The challenge: Achieving more simplicity is not simple (the picture related to this paragraph)

What does simplicity mean in the context of PLM?

My definition would be that compared to the current state, the future state should bring measurable benefits by reducing or eliminating non-value added activities. Typical non-value added PLM activities are collecting data from various disciplines to get a management understanding, conversion of file formats to support other disciplines or collecting and distributing data for change and approval processes.

If you can reduce or eliminate these steps, significant benefits can be achieved: reducing iterations, increasing quality and (re)acting faster to changes. These benefits are the whole idea behind Digital PLM. See Accenture’s explanation or read my post: Best Practices or Next Practices.DigitalPLM

Simplicity comes from the fact that the user does not need to depend on intermediate people or data formats to have an understanding of “the best so far truth.” Empowered users are a characteristic of modern digital processes. Empowered users need to have different skills than persons working in a traditional environment where exchange and availability of information are more controlled through communication between silos.  Some people can make the change, some will never make the change.

What can you do?

On LinkedIn, I found some good suggestions from Peter Weis in his CIO article: The most painful, gut-wrenching part of leading transformation. Peter’s post is about the challenges within a company going through a transformation and to keep the pace. My favorite part:

For me, the most difficult and gut-wrenching part of leading our transformation was not the technology involved. It was making and acting on those tough decisions about who was not going to succeed. In some cases, people had been with the company for decades and had been rewarded and encouraged for the very work they were no longer required to do. These were good people, skilled talent, who provided a great service to the company – but the technology and the cultural gap were just too wide for them to bridge.

Peter describes a dilemma that many of us consultants should face when implementing a business change. Keeping on board all employees is a mission impossible. But what if you want to keep them all on board?

Reducing complexity by making the system rigid?

One of the companies, I am currently working with, decided to keep all employees on board by demanding for a PLM system that is so rigid and automated that a user cannot make mistakes or wrong decisions. For example: Instead of allowing the user to decide which approval path should be chosen, the predefined workflow should be started where all participants are selected by automation. The idea: reducing the complexity for the (older) user. The user does not have to learn how to navigate in a new environment to decide what is the best option. There is always one option. Simple isn’t it?

I believe it reduces any user to a person that clicks on buttons and writes some comments. It is not about real empowerment.

There are two downsides to this approach

  • To make the PLM system, so incredibly rigid additional customizations are needed (which come with a cost). However more costly will be the upgrades in the future and the maintenance of every change in business process which is hard coded currently.
  • The system will be so rigid that even future, more digital native users, will dislike the system as it does not challenge them to think. Implementing the past or pushing for the future?

My challenge:

  • A rigid system creates the illusion that the system is secure and simple for the existing employees (who you do not want to challenge to change)
  • A rigid system leads by default to complexity in the future with high costs of change.

I am curious to learn how you would approach my challenge (a PLM consultant’s challenge)
Making the customer happy or being the “bad news” guy who creates fear for the future?
I assume a topic many PLM consultants should face nowadays – your opinion?

%d bloggers like this: