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

Digitalization - sure, but on what foundation?

4/7/2017

2 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
2 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

3 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

3 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