Follow us at
plmPartner
  • Home
  • About
  • Blog
  • Archive
  • Contact
  • Video Log
  • Learning Center
  • Privacy Policy

Opportunities and strategies - Product Configuration Lifecycle Management

4/25/2021

0 Comments

 
Picture

This time an article that aims towards the more traditional Product Lifecycle Management domain and especially towards configurable products or so called Configure To Order (CTO) products. This article is a direct result of discussions I’ve had with Henrik Hulgaard, the CTO of Configit, on Configuration Management in general and Product Configuration Management in particular. Configit specializes in Product Configuration Management, or as they prefer to call it Configuration Lifecycle Management.
 
Most businesses that design, manufacture and sell products have a system landscape in place to support key areas during the lifecycle of a product pretty much as in the image below (there are of course differences from company to company).

​
Picture
Figure 1.

This works well as long as the product lifecycle is linear, like it has mostly been in the past. However, as more and more companies strive after being able to let customers “personalize” their products, (so, to configure them to support their individual personal needs), harvest data and behavior from “the field” through sensors to detect trends in usage as well as being able to offer new services while the product is in use (operational), the lifecycle cannot be linear anymore in my view. This is because all phases of the lifecycle need feedback and information from the other phases to some degree. You may call this “a digital thread”, “digital twin” or “digital continuity” if you will (figure 2).
Picture
Figure 2.

Such a shift puts enormous requirements on traceability and change management of data all the way from how the product was designed, through to how it is used, how it is serviced and ultimately how it is recycled. If the product is highly configurable, the number of variants of the product that can be sold and used is downright staggering.
Needless to say, it will be difficult to offer a customer good service if you do not know what variant of the product the customer has purchased, and how that particular instance of the product has been maintained or upgraded in the past.
 
So, what can a company do to address these challenges and also the vast opportunities that such feedback loops offer?

If we consider the three system domains that are normally present (there are often more), they are more often than not quite siloed. That is in my experience not because the systems cannot be integrated, but more as a result of organizations still working quite silo oriented (Figure 3).

​


Picture
Figure 3.

All companies I’ve worked with wants to break down these silos and internally become more transparent and agile, but what domain should take on the responsibility to manage the different aspects of product configuration data? I mean, there is the design & engineering aspect, the procurement aspect, the manufacturing aspect, the sales aspect, the usage/operation aspect, the service/maintained aspect and ultimately the recycling aspect.
 
Several PLM systems today have configuration management capabilities, and it would for many companies make sense to at least manage product engineering configurations here, but where do you stop? I mean, sooner or later you will have to evaluate if more transactional oriented data should be incorporated in the PLM platform which is not a PLM system’s strongpoint (figure 4).
Picture
Figure 4.

On the other hand, several ERP systems also offer forms of configuration management either as an addition or as part of their offering. The same question needs to be answered here. Where does it make most sense to stop as ERP systems are transactional oriented, while PLM systems are a lot more process and iteratively work oriented (figure 5).


Picture
Figure 5.

The same questions need to be asked and answered for the scenario regarding CRM. Where does it make sense to draw the boundaries towards ERP or PLM, like in figure 6.

​
Picture
Figure 6.

I have seen examples of companies wanting to address all aspect with a single software vendor’s portfolio, but in my experience, it only masks the same questions within the same portfolio of software solutions. Because, who does what, where and with responsibility for what type of data when, is not tackled by using a single vendor’s software. Those are organizational, and work process related questions, not software questions.
 
Another possible solution is to utilize what ERP, PLM and CRP systems are good at in their respective domains, and implement the adjoining business processes there. Full Product Configuration Management or Configuration Lifecycle Management needs aspects of data from all the other domains to effectively manage the full product configuration, so a more domain specific Configuration Management platform could be introduced.


Picture
Figure 7.

Such a platform will have to be able to reconcile information from the other platforms and tie it together correctly, hence it would need a form of dictionary to do that. In addition, it needs to define or at least master the ruleset defining what information from PLM can go together with what information in ERP and CRM to form a valid product configuration that can legally be sold in the customer’s region.

As an example, consider: What product design variant that meets the customer requirements can be manufactured most cost effectively and nearest the customer with the minimal use of resources and still fulfill regulatory requirements in that customers country or region?
These are some of the questions that must be answered.

More strategic reasons to evaluate a setup like in figure 7 could be:
  • As the departmental silos in an organization is often closely linked to the software platform domain, it might be easier to ensure collaboration and acceptance by key stakeholders across the organization with a “cross-cutting” platform that thrives on quality information supplied by the other platforms.
  • It poses an opportunity for companies with a strategy of not putting too many eggs in the basket of one particular software system vendor.
  • It could foster quality control of information coming from each of the other domains as such a CLM solution is utterly dependent on the quality of information from the other systems.
  • Disconnects in the information from the different aspects can be easily identified.

I would very much like to hear your thoughts on this subject.
​
Bjorn Fidjeland 


​The header image used in this post is by plmPartner
0 Comments

Digitalization - sure, but on what foundation?

4/7/2017

5 Comments

 
Picture
The last couple of years I’ve been working with some companies on digitalization projects and strategies. Digitalization is of course very attractive in a number of industries:

  • Equipment manufacturers, where digitalization can be merged with Internet Of Things to create completely new service offerings and relationships with the customers
  • Capital projects EPC’s and operators, where a digital representation of the delivery can be handed over as a “digital twin” to the operator , and where the operator can use it and hook it up to EAM or MRO solutions to monitor the physical asset real-time in a virtual world. The real value for the operator here is increased up-time and lower operational costs, whereas EPC’s can offer new kinds of services and in addition mitigate project risks better.
  • Construction industry, where the use of VDC (Virtual Design & Construction) technology can be extended to help the facility owner minimize operational costs and optimize comfort for tenants by connecting all kinds of sensors in a modern building and adjust accordingly.
But hang on a second: If we look at the definition of digitalization, at least the way Gartner views it

“Digitalization is the use of digital technologies to change a business model and provide new revenue and value-producing opportunities; it is the process of moving to a digital business.” (Source: Gartner)

…The process of moving to a digital business….

The digitalization strategies of most of the companies I’ve been working with focuses on the creation of new services and revenue possibilities on the service side of the lifecycle of a product or facility, so AFTER the product has been delivered, or the plant is in operation.
There is nothing wrong with that, but if the process from design through engineering and manufacturing is not fully digitalised (by that I do not mean documents in digital format, but data as information structures linked together) then it becomes very difficult to capitalize on the promises of the digitalization strategy.
​
Consider 2 examples
Picture
Figure 1.
​
Figure 1 describes a scenario where design and engineering tools work more or less independently and where the result is consolidated in documents or excel before communicated to ERP. This is the extreme scenario to illustrate the point, and most companies have some sort of PDM/PLM or Engineering Register to perform at least partial consolidation of data before sending to ERP. However I often find some design or engineering tools operating as “islands” outside the consolidation layer.

So if we switch viewpoint to the new digital service offering promoted to end customers. What happens when a sensor is reporting back a fault in the delivered product? The service organization must know exactly what has been delivered, where the nearest spare parts are, how the product  is calibrated etc. to quickly fix the problem with a minimum use of resources in order to make a profit and to exceed customer expectation to gain a good reputation.
​
How likely is that to happen with the setup in figure 1?

​
Picture
Figure 2.
​
The setup in figure 2 describes a situation where design and engineering information is consolidated together with information regarding the actually delivered physical products. This approach does not necessarily dictate that the information is only available in one and only one software platform, however the essence is that the data must be structured and consolidated.

Again let’s switch viewpoint to the new digital service offering promoted to end customers. What happens when a sensor is reporting back a fault in the delivered product?
When data is available as structured and linked data it is instantly available to the service organization, and appropriate measures can be taken while informing the customer with accurate data.
​
My clear recommendation is that if you are embarking on a digitalization journey to enhance your service offering and offer new service models, then make sure you have a solid digital foundation to build those offerings on. Because if you don’t it will be very difficult to achieve the margins you are dreaming of.
​
Bjorn Fidjeland


The header image used in this post is by kurhan and purchased at dreamstime.com
5 Comments

Linking vision with strategy and implementation, but prepare for disruption

6/24/2016

2 Comments

 
Picture

​
​Over the years I’ve seen the importance of defining a vision for where one would like to get.



Picture

​Such a vision should serve as a guiding star.
This is true for full corporate visions as well as for smaller areas of the enterprise.

It could be for our product lifecycle management and the internet of things, how we see ourselves benefitting from big data, or harnessing virtual design and construction.
Picture
​
​The strategy is our plan for how we intend to get to the promised land of our vision. It should be detailed enough to make sense of what kind of steps we need to take to reach our vision, but beware:

Don’t make it too detailed, the first casualty of any battle is the battle plan.
​Prepare, but allow for adjustments as maturity and experience grows.

​An important part of the strategy work is to acid test the vision itself. Does it make sense, will it benefit us as a company and if so, HOW.
​
During the strategy work, all stakeholders should be consulted. And yes both internal and external stakeholders. The greatest vision in the world with a good strategy and top notch internal implementation won’t help much if you have external dependencies that cannot deliver what you need according to your new way of working…..
​Business processes will simply come grinding to a halt.
Picture
​The implementation rarely takes the same path as the strategy intended it to do. There are usually many reasons for this.
My best advice regarding implementation is to take it one step at a time and evaluate each step. Try to deliver some real business value in each step, and align the result towards vision and strategy. Such an approach will give you the possibility to respond to changing business needs as well as external threats.

But as we come closer to the promised land of our vision, we can simply sense the feel of it and can almost touch it…. Then, disruption happens........

Picture
​Such a disruption might present itself in the form of a merger and acquisition where vision, strategy and also implementation must be re-evaluated.
The “new” company might have entered another industry where strategy and processes need to be different and old technical solutions won’t fit.

Today everybody seems to be talking about disruptive technology and or disruptive companies. Most companies acknowledge that there is a real risk that it will happen, but the problem is, since most disruptive companies haven’t even been formed yet, it is difficult to identify where the attack will come from and in what form.
​
This leads back to vision, strategy and implementation. Vision and strategy can be changed quickly, but unless the implementation is flexible enough and able to respond to changing needs, the company will be unable to respond quick enough to meet the disruption.

Bjorn Fidjeland

The header image used in this post is by Skypixel and purchased at dreamstime.com
2 Comments

The journey of PLM vs the journey of PDM

3/28/2015

0 Comments

 
Picture
Inspired by the blog post: “Is PLM a Journey? Follow (or Join!) the Blogfight!" in "The PLM Dojo" group at LinkedIn I started thinking about the topic of “PLM as a journey”. In my previous company I wrote the post “PLM – Tool or Mindset”, and a PLM implementation is in my view a journey pretty much as Jos Voskuil describes it. If and there is an if, you think about the scope of PLM (Product Lifecycle Management) then I think it is crucial to have a vision, strategy and a clear commitment from business in order to be able to execute. This is because the initiative involves several different departments, and in bigger organizations also multiple sites on different continents. Such a project becomes a journey, because in order to eat that particular elephant it is very important to do it one bite at a time, and in between each bite, business and the organization needs to digest and mature.
This is where organizational rollout and communication comes in as a very important factor. IT must in this case work very closely with business to deliver functionality after each bite has been swallowed…. A lot of eating here, but I think the analogy is good.


 I’ve been fortunate enough to be a part of a few such PLM projects, but in the beginning I must say that it was the proverbial catfight between business and IT. 
But, as healthy group processes were promoted and everybody tried to see it from the other party’s perspective they became ONE team with ONE goal. 

This could happen because there were external personnel present to mediate and translate the language of business to IT and vise versa.   

After a few months it was impossible to tell who was business and who was IT!
I  would describe this process as an important part of the PLM journey. Then, as business gets more and more of their processes implemented in the PLM system and the solution matures, more and more bites can be introduced and devoured. 
Picture

So what about PDM (Product Data Management)?
Well PDM is where PLM originally came from, and it primarily addresses the needs of product engineering and design. Mostly a one department effort, although such projects can also span multiple sites on different continents. 

However if we face the facts, most PLM projects today are STILL abut implementing PDM functionality in a full blown PLM platform. 

Why is that? 
Well in my view it is because:
a.       It started as an engineering or IT effort without appropriate business vision and strategy. 
b.      The PLM project, with business involved and strategy developed, got constipated because they bit over more than they could chew.

If the PDM project started as an IT or engineering department only effort, then there seems to be a glass ceiling preventing the project to get acceptance from business to grow the scope into a full PLM implementation.
I cannot really explain why, so feel free to comment!
My hunch though, is that it has to do with a certain “Not invented here” syndrome…. 
But I seriously doubt that business would say that out loud......

Some points to ponder
Bjorn Fidjeland

0 Comments

Integration strategies

3/7/2015

4 Comments

 
One of the things that still strikes me after having been part of big Product and Plant Lifecycle Management projects during the last decade is how little focus there is on integration strategies. By integration strategy I mean decisions on how information should flow between authoring tools, PLM platform, procurement and supply chain. In other words between different departments within the company as well as external companies in the value chain.

In my view you may have the perfect platform for managing engineering information across engineering disciplines, but it still isn’t worth much if the information flow to and from project execution, procurement and supply chain is severely hampered.

Essentially there are 3 main strategies for integration
  • Point to point integrations: Each system integrates through an adaptor to whatever system needs information from it (traditionally this has led to so called spaghetti issues. Lots of integrations that are hard to change since it is very difficult to foresee how a change in one system will affect the processes in other systems).



Picture

  • Data warehouse (Enterprise Service Bus):  Solves the point-to-point mapping issues by converting all data flows to a common, neutral, format and storing them in a data warehouse. When a system publishes information, it publishes it in its own structure to its own adaptor and the adaptor changes it to the structure of the data warehouse. Each system acts like it is the only one in the world.



Picture
  • Dictionary approach: If a common dictionary (or Rosetta stone if you will) is built on an industry standard or even a proprietary company dictionary, then changes in one system only needs to be mapped to the dictionary, not to attributes in other systems. Changes in one system will not affect any of the other systems in terms of their integration since everyone maps to the dictionary. This is the approach promoted by standards like ISO 15926 to solve interoperability issues.
Picture

I’ve often heard the following: Of course we’re not doing point to point anymore. We’ve got an Enterprise Service Bus that takes care of it…… But then, what goes on behind the scenes?
The Enterprise Service Bus has a nice Graphical User Interface for creating integrations where you simply drag and drop attributes from one systems adaptor and maps it to attributes from another systems adaptor…

Consequence: Point to point issues are re-created in the Enterprise Service Bus, even if the exchange format is completely neutral.

A clear integration strategy could also yield considerable business benefits even outside solving internal integration issues. What would happen if a dictionary approach was selected, and the dictionary was an industry standard?
Well, then information could be supplied to other companies, like operators, customers or suppliers on that industry standard format without having to develop special integrations for interoperability with other companies in the value chain.


Some points to ponder
Bjorn Fidjeland

4 Comments

    plmPartner

    This is where we share our thoughts, ideas and experiences with you

    RSS Feed

    View my profile on LinkedIn

    Categories

    All
    AEC
    BIM
    Data Management
    Digital Twin
    ERP
    Facility Lifecycle Management
    Integration
    Internet Of Things
    IOT
    Platform
    PLM
    Process
    Product Lifecycle Management
    Strategy
    Structured Data
    Technical Information Management
    VDC
    Virtual Design And Construction

Contact us:
plmPartner AS    Lyngfjellveien 14    4580 Lyngdal    Norway    +47 99 03 05 19    info@plmpartner.com