Category: Strategy

The Digital Enterprise - Digital Processes and Functionality

4/13/2025

As the business software is selected, the next step is to implement the described processes “your way of working” as digital equivalents in the business software.
These are the typical PLM, ERP, CRM, MES, EAM projects that are executed in organizations and that tends to create headlines like: “More than 50 percent of IT projects fail”

How do we avoid ending up in these statistics?
As for any kind of project it is important to define clear objectives. If we have, as per the “pyramid” image above, identified the business needs and defined the business processes, this part should be straightforward. However, be careful not to bite off more than you can chew. Then establish measurable objectives for the implementation.

Pay careful attention to involving the affected stakeholders. They need to be informed, engaged and consulted regularly during the implementation of the digital processes. They will also be very valuable in terms of feedback and guidance.

If your enterprise has history in terms of legacy data, some tough decisions must be made. Does it make sense to migrate all the data into the new system or systems? Is it even possible? What value will it bring to migrate all data compared to the cost?
Do we leave all legacy data in the old system and gradually phase it out? However, gradually might take a really long time depending on the lifecycle of your product or facility data managed in the system….
A third option would be to partially migrate data from the legacy system, meaning, that only the most important data will be migrated to the new system in accordance with the new data model and processes. This option will make the migration exercise less costly and time consuming, but it will still leave the need for a functioning legacy system containing the old data even if very few individuals in the organization need to use it.

Next, decisions will have to be made regarding how much configuration or customization of the business software compared to the needs of the business. In my view it is absolutely crucial that business is involved in this step and that they keep an open mind. Is it really important to our business execution to change the software process or would it be possible to run as per Out Of The Box? If the process is unique to you and gives you a competitive advantage, then I would say yes, it would probably be a good idea to customize. Just bear in mind that the cost is not just to implement the unique process, but also to maintain and upgrade it yourself.

For the execution of the implementation project there are several different schools. Personally, I lean towards an agile approach with SCRUM like frameworks. The main reason for this is that I’ve seen first-hand on multiple occasions the power of the “show and tell” at the end of a sprint where business stakeholders get to see the developed functionality and ask questions to the scrum team and the scrum team get to show what they have achieved as well as asking questions to business stakeholders. It facilitates a powerful “us” dynamic as opposed to “us vs them”, and it also means that the project is better equipped to capture misunderstandings and errors early.

As the system with the defined digital processes and functionality is ready to be deployed and put to real use in the organization the biggest pitfall of all is hidden in the shadows……

Rollout, training, and organizational change management. Tons of literature has been written regarding its importance, and virtually everybody agrees it is important, so why is it so hard?
Because it involves people, and even more difficult, people that must change the way they do things. People, we, do not like to change, we resist change.

Is it then hopeless? Not at all, it just means that attention and resources must be set aside to deal with this important phase of any business software project. As an example, SharePLM, offers a lot of great articles on this topic.

After the business software with its digital processes and functionality is put to good use in the organization, it will start to produce content and data. For a digital enterprise, what you do with this data will largely determine your level of success.

Bjorn Fidjeland

0 Comments

The Digital Enterprise - Business Processes

4/4/2025

0 Comments

Business processes should be formally described to convey the way we work in the company. Such process descriptions are typically found in the company’s management system.

Figure 1

There are different policies regarding granularity and how to break down high level processes to lower level processes with activities. A rule of thumb is that there should not be much more than 3 levels from a high level process until you find what activities you actually need to perform to fulfill the overall process.

Activities or tasks that need to be performed in a process must have clear descriptions of what the required input is to successfully complete the activity, what tasks need to be performed within the activity, by what role and discipline and what the expected outcome or output is from the activity (figure 2).

Figure 2

Furthermore, it must be clearly specified who should receive the output of the activity and why (figure 3).

Figure 3

When I interview organizations, especially during different elicitation activities, I very often hear that there are missing or insufficient feedback loops between different disciplines. Such feedback loops are easy to draw in a process, like the figure 4 below, but it is a whole lot more difficult in reality as it involves.............. People, departments (which is even more difficult as it involves a different "tribe of people" ) and possibly even other companies.

Figure 4

Hard as it may be, feedback loops are crucial for continuous improvement and learning, especially as the company grows to a size where it is hard to know what everyone is doing.

In my view, trying to measure or at least monitor that feedback activities are performed is of the utmost importance.

Bjorn Fidjeland

0 Comments

The Digital Enterprise - Business Needs

4/1/2025

0 Comments

In the article “What is a digital enterprise? And why should you care?” I wrote that “Business needs must be catered for by defined business processes (“the way we work”)”
The needs of the business may be in support of strategies, so plans for how we intend to achieve a certain goal or mission.
Such strategies are typically there so that we may reach some vision we have of what our enterprise should be in the future.
Furthermore, as business is also conducted in the digital realm, we need to capture business needs to support the enterprise’ policy for IT security. Such a policy or IT security strategy also influences budgets and resources.
Questions like: “Can we move to cloud to diminish the need for hardware and resources?”. The answer to this may depend on regulatory requirements as well as industry requirements.
We may see clear business needs that we wish to solve in the best possible way, however we are more often than not restricted by available budgets and resources.

But how do we identify business needs?
Even in well established organizations I’ve found that performing so called “business requirement elicitation” initiatives or projects regularly (at least every 3 years) across the departments of an enterprise is very useful. Not only to capture the business needs within departments, but also needs regarding what each department need from other departments to effectively do their work.

When the needs are validated, verified and communicated to all stakeholders it becomes a very effective way of communicating why for instance engineering need this and that information from sales, or why manufacturing desperately would like to have information they know engineering has, but is not provided.

I was once responsible for an enterprise-wide business requirement elicitation initiative regarding an end-to-end process for facility assets. The lifecycle of assets were defined as “from a need is identified in the facility to decommissioning of the physical asset” needless to say it spanned pretty much all departments and functions in the company from engineering through procurement, manufacturing, supply, installation, commissioning, operations, maintenance and ultimately decommissioning.
Some key stakeholders clearly voiced their discontent with the initiative saying it was a complete waste of their time, and that it was a classical case of shooting sparrows with cannons… Nevertheless, after a bit of persuasion they went along with it.
After the elicitation exercises, the business requirements from all departments and functions were verified, validated and mapped towards an overall end-to-end business process. The findings and recommendations based on the findings were presented to all stakeholders involved.

Interestingly the very same stakeholders who voiced discontent, now saw the benefit of the exercise and wondered why we had not done it sooner.

When the business needs are identified, it becomes a question of how we can fulfill them. How can we organize our way of working to fulfill the business needs?
This leads us to the next level in the pyramid, namely business processes.

Bjorn Fidjeland

0 Comments

What is a digital enterprise? And why should you care?

4/2/2024

0 Comments

Hallmarks of so called digital enterprise companies are that they are able to mirror and refine the real-world way of conducting business in the digital world, and in some cases even blur the boundaries between the two.

Such companies design their business processes (their “ways of working”), implements them digitally, executes, and measures their processes continuously. The measurements are then used to optimize and adjust the business processes both in the real and digital world.

Emphasis is put on company services being protected by cyber security measures to safeguard both the services and the company itself

Companies that have focused on this are more able to continuously improve as well as detect, adapt, and transform to changes, opportunities and threats in their business environment.

To make this work, as per the figure below, business needs must be catered for by defined business processes ("the way we work")

The defined business processes must be implemented by digital counterparts in enterprise business software

Data and content produced when executing the processes must be analyzed, measured and managed to provide actionable insight

Data exchanges must be interoperable to support cross cutting processes and data transfer or even better, linking of data, between enterprise business software when needed.

An infrastructure of hardware and software capable of running the enterprise business software is the foundation for it all

In my article series "PLM Tales from a true mega project" and more specifically in Chapter 8 - Digital Twin I wrote:

"The thing is…. In order to achieve what is described in this article series, most companies would have to change the way they are currently thinking and working across their different departments, which brings us to the fact that real business transformation would also be required. The latter is most of the time a much larger and more time-consuming obstacle than the technical ones because it involves a cultural change."

So while the "PLM Tales from a true mega project" and "Plant Information Management" articles focused on the information that needs to be managed and how this may be done, this and articles to come will focus on how the business may be transformed as well as the governance needed to make it happen.

Bjorn Fidjeland

0 Comments

Opportunities and strategies - Product Configuration Lifecycle Management

4/25/2021

0 Comments

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).

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).

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).

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).

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).

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.

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.

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

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

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?

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

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

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.

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.

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

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

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.

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).

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.

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.

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

Categories