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

PLM and disconnected corporate processes

7/19/2015

2 Comments

 
Picture
How many times have you seen flashy corporate “blue books” with impressive process maps of how an organization do their business and perform their work?

I’ve seen quite a few. It’s not that I have anything against them, it’s just…. Is this really how the organization work? Are the corporate processes updated to actually reflect how work is performed, or are the processes really enforced in the organization? Are the processes adjusted based on feedback from the project organizations? And last but not least, are projects measured against the processes?
To my experience this very rarely happens, if at all.

I have however seen one company take drastic measures to do something to bridge the gap between the corporate processes and how the organization actually worked. This company decided to visualize their corporate processes in a PLM platform for use across all countries they were involved in. Due to regulatory differences between countries they managed variants of the processes in each country as well.
So how is this different from any other process map you might ask. Well, they not only visualized the processes, they also instantiated the processes, so when a particular project were to be executed the project manager would select the appropriate process and got an instantiated project with template WBS (Work Breakdown Structure) together with all document deliverables that were expected for such a project related to tasks and milestones.

This way they forced the organization to follow the defined processes….. As you might expect there was an outrage, because the instantiated processes was not at all how the organization worked. The project organization had through experience figured out where the corporate process did not work in the real world and had found ways to overcome the problems. This was however the intention, because now there was a very clear feedback loop so that the processes could be adjusted to reflect how the organization actually worked, and since the processes were instantiated in real projects, they could now also be analyzed, measured and improved across the entire organization through dashboards in the PLM platform. This practice became a competitive advantage, and it also allowed processes to be verified and tested in one country before being rolled out in other countries.

I’ve also seen examples of what typically happens when there is only a loose coupling between the corporate processes and how projects are executed and measured. In one company they had very impressive process maps with clearly defined input, output, description of responsibility and activities to be performed within each process step. However, the processes were not really instantiated and measured in the projects.

The obvious question then became: “How is it possible to measure and improve the processes if they are not instantiated and measured in actual projects?”

Well, it worked as long as the company was fairly small and key persons managed to have an overview of most projects. Mostly the projects were executed based on experience and a functioning culture at the main site. The challenge then became apparent when trying to replicate this for other sites where the culture was different. Those other sites tried to execute their projects solely by the process maps….

And that led to some very real problems

In such cases it is of paramount importance to harvest all experience from such projects, analyze, validate and update the process maps accordingly.

So where am I going with this?

In my view companies should work hard on closing the gap between their corporate processes and how the organization actually perform their work. Creating feedback loops from the project organization is one way of doing it. Another way is to actually instantiate the processes for use in projects and thereby making sure that the processes are followed. If the latter approach is selected it becomes very important to have an organization in place to collect feedback, analyze and adjust the processes as the company evolve and develop over time.


Some points to ponder
Bjorn Fidjeland
2 Comments
Jos Voskuil link
7/27/2015 02:08:35 am

Bjorn what you describe might be particular for a certain industry, I assume a project-driven industry, as I have seen companies with well described processes, executing them and improving them.

There is no disconnect between the processes and the execution, however it is an analogue process, meaning people have to do the job to check and collect deliverables and statuses. This is too costly for competitive markets, in particular if the wages in your country are relative high.

And this is indeed the benefit PLM can bring. By embedding these processes in the product lifecycle you ensure all necessary steps are done without having people to collect data and review. This already saves significant labor costs.

Next as the processes have become digital you can audit and measure them solving bottle-necks or removing non-value added steps. And because the processes are digital you know immediate the status of what is happening where.

Main challenge for digital processes is that it is a cross-department exercise, which implies that the PLM implementation is accepted across all disciplines in the company

Reply
Bjorn Fidjeland
7/27/2015 04:13:53 am

Hi Jos, and thank you very much for your comment!

The two examples are actually both from project driven industries. I think you are right that the intention in the second company mentioned was that the processes should be analogue, and that people should execute them manually just as you describe. However as time went by, the processes actually being executed at the main site started to diverge from the process maps due to optimization and more experience, but the process maps were not sufficiently updated.

This meant that other sites could not benefit from the main site’s experience. Basically it became an organizational communication and collaboration issue as the company grew globally. The way it was remedied was to have experienced project managers transported from the main site to other sites to help and share knowledge in order to get projects back on track. So a way of treating the symptoms (failing projects) whereas the root cause (processes not updated) was not treated.

Your comment regarding the benefits PLM can bring is in my view spot on, but it does, as you point out, raise the challenge that processes must be agreed upon across disciplines and departments.

Reply



Leave a Reply.

    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