Category: Technical Information Management

Plant Information Management - Installation and Commissioning

1/27/2017

I realize that the last post “Handover to logistics and supply chain in capital projects” went quite a lot further in the information lifecycle than the headline suggested, so here is a brief recap on how structured and linked data can support processes during construction/installation and commissioning.

This post is a continuation of the posts in the Plant Information Management series of:
“Handover to logistics and supply chain in capital projects”
“Plant Engineering meets Product Engineering in capital projects”
“Plant Information Management - What to manage?”

Let’s jump in and follow the journey of the manufactured physical products as they move into installation and commissioning phases.

Figure 1.
Provided that the information from the different structures and their context in relation to each other is kept, it is possible to trace perfectly what physical items should be installed where, corresponding to the tag requirements in the project (note: I’ve removed the connections from tag to EBOM in this figure for clarity).

We are now able to connect the information from tag: =AB.ACC01.IS01.VS04.EP03, the one in the safety classed area to the physical item with serial number S/N: AL11234-12-15 that contains the documentation proving that it is fit for purpose in a safety classed area.
As the other two tags are not in a safety classed area, and have no special requirements, any of the two physical pumps can be used to fulfill the tag requirements, however we still want full traceability for commissioning, operations & maintenance.

Figure 2.
Since we now have a connection between the tag requirements and the physically installed individuals, we can commence with various commissioning tests and verify that what we actually installed works as intended in relation to what we designed (the plant system), and furthermore we can associate certificates, commissioning documentation and processes to the physical individuals.

The reason for this split between tag object and physical item object I’d like to come back to in a future post regarding operations and maintenance.

Bjorn Fidjeland

The header image used in this post is by Satori13 and purchased at dreamstime.com

Handover to logistics and supply chain in capital projects

12/12/2016

This post is a continuation of the post “Plant Engineering meets Product Engineering in capital projects” and “Plant Information Management - What to manage?”

As the last post dwelled on how EPC’s and product companies are trying to promote re-use in very Engineer To Order (ETO) intensive projects, we will focus on the handover to supply chain and logistics in this post.

The relationship between the tag containing the project specific requirements, and the article or part containing the generic product design constitutes a project specific demand that supply chain and logistics should know about. If both the tag and the connected part is released, a “signal” is sent with information regarding both the tag’s requirements and the part’s requirements.
An exception to this rule is typically Long Lead Items (LLI). I’ve seen this handled via a special process that allows transfer of the information to supply chain and logistics even if the specific tag has not been released.

Figure 1.
As the project specific information regarding all three tags and the intended use of product design is sent to logistics and supply chain it is possible to distinguish what tags need special attention and what tags can be ordered “off the shelf”.

Let’s say that tag: =AB.ACC01.IS01.VS04.EP03 is in a safety classed area and the other two are not. Information in the purchase order for the safety classed tag must then contain information to the manufacturer that documentation regarding the manufacturing process must follow the produced individual that will be used to implement this specific tag, whereas the other two deliveries can have standard documentation.

Figure 2.
Figure 2 depicts that all three manufactured products or physical items with serial numbers come from the same Engineering Bill Of Material, but that the individual with serial number S/N: AL11234-12-15 has some extra information attached.
This is because since it is to be used in a safety classed environment, proof must be produced from the manufacturer’s side that the product fulfills the safety class requirements given on the tag. This could for instance be X-Ray documentation that all welds are up to spec or that the alloy used has sufficient quality.
As you can see, If the information is kept as information structures with relationships between the different data sets detailing what context the different information is used in, it becomes possible to trace and manage it all in project specific processes.
There are some other very important information structures that I mentioned in the post “Plant Information Management - What to manage?” like the Sales BOM (similar to manufacturing industries Manufacturing BOM), the Supply BOM and warehouse management, however I would like to cover those in more detail later in later posts.

For now let’s follow the journey of the manufactured products as they move into installation and commissioning.

Figure 3.
Provided that the information from the different structures and their context in relation to each other is kept, it is possible to trace perfectly what physical items should be installed where, corresponding to the tag requirements in the project (note: I’ve removed the connections from tag to EBOM in this figure for clarity).

We are now able to connect the information from tag: =AB.ACC01.IS01.VS04.EP03, the one in the safety classed area, to the physical item with serial number S/N: AL11234-12-15 that contains the documentation proving that it is fit for purpose in a safety classed area.
As the other two tags are not in a safety classed area, and have no special requirements, any of the two physical pumps can be used to fulfill the tag requirements, however we still want full traceability for commissioning, operations & maintenance.

Figure 4
Since we now have a connection between the tag requirements and the physically installed individuals, we can commence with various commissioning tests and verify that what we actually installed works as intended in relation to what we designed (the plant system), and furthermore we can associate certificates and commissioning documentation to the physical individuals.
The reason for this split between tag object and physical item object I’d like to come back to in a future post regarding operations and maintenance.

Bjorn Fidjeland

The header image used in this post is by Nostal6ie and purchased at dreamstime.com

Plant Engineering meets Product Engineering in capital projects

9/30/2016

This post is a follow up of “Plant Information Management - What to manage?”.

It focuses on the needed collaboration between Plant Engineering (highly project intensive) and Product Engineering which ideally should be “off the shelf” or at least Configure To Order (CTO), but in reality is more often than not, Engineer To Order (ETO) or one-offs.

More and more EPC’s (Engineering Procurement Construction companies), and product companies exposed to project intensive industries are focusing hard on ways to re-use product designs from one project to the next or even internally in the same project through various forms of configuration and clever use of master data, see “Engineering Master Data - Why is it different?”.

However, we will never get away from the fact that the product delivery in a capital project will always have to fulfill specific requirements from Plant Engineering, and especially in safety classed areas of the plant.
If you look at the blue object structure, it represents a consolidated view of multi-discipline plant engineering. The system might consist of several pumps, heat exchangers, sensors, instrumentation and pipes, but we are going to focus on a specific tag and it’s requirements, namely one of the pumps in the system.

At one point in the plant engineering process the design is deemed fit for project procurement to start investigating product designs that might fulfill the requirements stated in the plant system design.
If the plant design is made by an EPC that does not own any product companies, the representing product is typically a single article or part with associated preferred vendors/manufacturers who might be able to produce such a product or have it in stock. If the EPC does own product companies, the representing product might be a full product design. In other words a full Engineering Bill Of Material (EBOM) of the product.

This is where it becomes very interesting indeed because the product design (EBOM) is generic in nature. It represents a blueprint or mold if you will, used to produce many physical products or instances of the product design. The physical products typically have serial numbers, and you are able to touch them. However, due to requirements from the Owner/Operator, the EPC will very often dictate both project and tag specific documentation from the product company supplying to the project, which in turn often leads to replication of the product designs X number of times to achieve compliance with the documentation requirements in the project (Documentation For Installation and Operations).

So, even if it is exactly the same product design it ends up being copied each time there is a project specific delivery. This often happens even if let’s say 40 pumps are being supplied by the same vendor to the same project, as responses to the requirements on 40 different tags in the plant design……
Needless to say it becomes a lot of Engineering Bill Of Materials in order to comply with documentation requirements in capital projects. Even worse, for the product companies it becomes virtually impossible to determine exactly what they have delivered each time, since it is different Engineering Bills Of Materials all the time, yet 97% of the information might be the same. The standardized product has now become an Engineer To Order product.
So how is it possible to avoid this monstrous duplication of work?
More and more companies are looking into ways to make use of data structures used in different contexts. The contexts might be different deliveries to the same project or across multiple projects, but if one is able to identify and separate the generic information from what information that needs to be project specific it is also possible to facilitate re-use.

The image above shows how a generic product design (EBOM) is able to fulfill three different project specific tags or functional locations in a plant. Naturally three physical instances or serial numbers must then be manufactured based on the generic product design, but since we have the link or relationship between the project specific requirements (the tags) and the generic (the EBOM), one can generate project specific data and documentation without making changes to the generic representation of the product (the EBOM).
This approach even enables the product company to identify and manufacture one of the pumps which happens to be in a safety classed area in the plant design according to regulatory requirements without having to make changes or duplicate the product design, however more on that next time.

Bjorn Fidjeland

The header image used in this post is by Nostal6ie and purchased at dreamstime.com

Managing Documentation For Installation and Operations

5/1/2016

In one of my previous articles “Plant Information Management - What to manage?”
I wrote about different information structures needed in a plant project from early design through commissioning and operations.

The article left some questions hanging. One of them was: how can all this information be consolidated, managed and distributed to the various stakeholders in a plant project at the right time and with the right quality?

Traditionally this has been called LCI or LifeCycle Information, at least in Norwegian oil & gas industry, DFI/DFO internationally or Documentation For Installation / Documentation For Operations. In short it is the operator’s requirements and needs for information from early design through engineering, procurement, construction and up to and including commissioning. The requirements are safety, regulatory and also requirements for information the operator finds important in order to control, monitor and guide progress of the project executed by the EPC.

As the figure describes, the operator drives expectation of deliveries in terms of standardization, safety & regulatory and expected documentation needed to operate and maintain the plant after commissioning. All stakeholders in the value chain must abide to these requirements, and it is the EPC who usually has the task of coordinating and consolidating this mountain of information. A successful commissioning includes that the operator confirms that it has received all documentation and information required to operate the plant in a safe and regulatory compliant manner. At this point the EPC is excused from the project.

In theory, the documentation handover would look like the figure above, however operators experience has told them that this seldom works well. Therefore a much more frequent information exchange is required between EPC and operator leading up towards commissioning. The main reason for this is that it enables the operator to monitor, check and verify the progress in the project. It also makes for a more gradual build-up and maturing of documentation in the project. For the EPC it means frantic activity to secure all required documentation from its own engineering disciplines, and all external companies in the projects value chain (see the pyramid in figure 1.) at each milestone.

Traditionally a whole host of LCI Coordinators has been needed both on the EPC side, and on the operator side to make sure that all documentation is present, and if not, to make sure it is created…. The very “best” LCI coordinators on the EPC side manage to produce the information without “bothering” engineering too much. It has largely been a document centric process separated from the plant & product engineering process.

As long as EPC’s are only active in one country, this approach is manageable for them, however once they turn global, they find themselves having to deal with many different safety standards, regulatory standards and last but not least varying requirements and formats from different operators. Even product companies and module suppliers delivering to projects in different parts of the world experience the same thing.

In later years I’ve experienced more and more interest in leaving the document centric approach for a more data centric approach. This means that data is created and consolidated from various disciplines in data structures as described in the article “Plant Information Management - What to manage?”, and that the LCI process becomes an integral part of the engineering, procurement, construction and commissioning processes instead of being a largely separated one.

Of course there are varying strategies among companies when it comes to how much to manage, and how to hand it over.

Some create data structures in PLM like platforms, consolidates them, manage changes and transfer data to other stakeholders in the projects via generated transmittals. This is more similar to the document centric approach only more automated.
Some companies target re-use from project to project in addition to the aspects mentioned above by creating data structures in catalogs that can be selected in other projects as well. The selected data structure is then replicated in a project specific context and gets auto generated project specific information like tags and documentation.
Others again removes or reduces the need for transmittals and document handovers by letting the project stakeholders directly into their platform to work and deliver information there instead of handing over documents.
One approach was to not hand over documents at all, but simply give the operator access to the platform, link the information from the data structures as deliverables to the milestones the operator required, and then handing over the entire platform to the operator as Documentation For Operations after successful commissioning.

Bjorn Fidjeland

The header image used in this post is by Norbert Buchholz and purchased at dreamstime.com

PLM platforms, the difficult organizational rollout

3/6/2016

What is PLM really about? In my view it is about tying relevant information to business processes, you know, the stuff that makes your company truly unique and then tying your employees to those very same processes throughout the life of a product.

So it’s about information, processes, people and an IT platform, in this case a PLM platform.

To be successful, ALL areas must intersect.

It does not matter if you have the perfect PLM system with perfectly defined processes if the information you need to manage is bad.

Just as little as it will help to have good quality data with perfectly defined processes and an organization ready to adopt it if the PLM platform is unable to scale to your needs.

It will not help to have good quality data tied to perfectly defined processes and a state of the art PLM system either if nobody is using it….

So going back to the headline: PLM platforms, the difficult organizational rollout.
I’ve seen far too many PLM implementations underperform due to unsuccessful rollout in the organization.
I find it strange that although the projects are often run iteratively to develop or customize smaller chunks of functionality in each iteration to ensure success, one expects the end users to devour the full elephant of the project in more or less one big bite…

In my view a rollout of such a large and business critical platform should also be considered iterative and with time for the end users to come to terms with what they have learned after each iteration before the next iteration starts.
I would compare it to building a house.
You would never start erecting the walls before the concrete slab is sufficiently cured.
The same is true for an organization. If more functionality and new processes are put on top before the previously learned functionality and processes has had time to settle, you get resistance, and the foundation becomes weak.

Another important factor is to not only train the end users in a classroom environment and then expect them to perform well in their new system… Because they won’t.
They’re still afraid to do something wrong, and they will struggle to remember what they learned in the classroom.
Then they will try to find solutions in the manuals, and growing more and more frustrated by the minute.

If this frustration is allowed to continue for too long, you can be sure that the end result is that they feel that the system is too difficult to use and basically suck. It might sound childish, but holding hands work! Have some super users or trainers available in the everyday work situation to help and guide the users the first few weeks.
That will mitigate the fear factor of doing something wrong, and steadily build confidence and ability.

Bjorn Fidjeland

Challenges when going from entrepreneur to industrialized manufacturer

1/3/2016

In my neck of the woods there are a lot of very talented engineers, and a lot of entrepreneurial spirit. My region (South Western part of Norway) is very much exposed to oil & gas industry and the delivery of products to plants, oil platforms etc. This means that it is very project focused and ETO (Engineer To Order) intensive.

The entrepreneurial spirit I mentioned has led to a whole host of startups with good ideas of how to solve some problem with a new product in better and more cost effective ways.

One story I keep hearing from such product companies, not only in Norway, but also in other countries and project intensive industries goes something like this:
So we won our first contract and the customer is really impressed with our product and our technology. It became a bit more expensive to deliver the project than we thought, but we managed and we were sure we would have better returns on the next project.

As time progresses we expect our cost in the projects to drop significantly.

But what happens in a lot of such product companies?

There is nothing strange in expecting such a development. One would instinctively think that one would be able to shorten the project execution time as one gains experience and have successfully delivered such a product before. The organization knows what suppliers can deliver and which cannot. Engineers and employees in installation and commissioning are becoming more and more experienced etc.

It becomes very, very hard to drive down the cost of delivering projects, even if the product delivered from project to project is very similar. The transition from entrepreneur to industrialized manufacturer becomes hard for a lot of these companies.

Why is that?

Personally I think there are several factors

It was too hard to say no to those small insignificant changes that the client required in the next project….. That for engineering or manufacturing turned out to be not so insignificant.
Product development is constantly being performed in the projects. Engineers will always search for the perfect and most elegant solution. That does not mean that it is the best or most cost effective way to manufacture the product.
Clients or operators documentation requirements in terms of LCI (LifeCycle Information) deliveries. If the product company is unable to define a process to deal with shifting requirements from operator to operator, this becomes a manual nightmare that constantly diverts resources. Such a process should be an integrated part of the project execution process, and not as it mostly is today, a separated process.
It is in my view paramount that smaller parts of the product at least, is standardized and modularized in such a way that the engineering information can be re-used from project to project (You can read more about my views here: “Engineering Master Data - Why is it different?” and “Can PLM help industrializing Oil & Gas projects?” )
Last but not least there is a screaming need to manage project specific engineering data (Tag structures, P&ID’s, D&ID’s, electrical) together with, but NOT in a one to one relation with more generic product development data

I’ve seen the three last bullets addressed with PLM platforms at various companies, however the technology itself is just one factor. The organizational processes and how they are enforced in the platform is of far bigger importance.

The first two bullets are a lot harder, as they require a shift in mindset from entrepreneur to industrialized manufacturer of the organization. This includes going from quick and nimble to more standardized processes, and continuous process improvement. If you consider PLM as a mindset rather than just a technology, you will also harvest benefits here, but it is hard work.

Bjorn Fidjeland

Plant Information Management - Information Structures

11/8/2015

Plant or Facility projects are demanding and require enormous volumes of detailed information from various information sources, information structures from different stakeholders, and in most cases also different companies.
This blog post is an attempt to describe the different information structures and how they tie into each other on a high level. I would be very happy if you could comment, state your views, and maybe help me complement the picture

Information structures throughout a plant project:

The project execution structure or WBS (Work Breakdown Structure) is key to plan, staff, execute and measure the progress of the project. It is usually developed in a solution like Primavera or Safran.

The functional structure or tag structure represents the functional decomposition of the multi discipline plant design which includes design from process engineering, mechanical, piping material & installation, electrical, instrumentation and civil. The information from these disciplines are usually 2D process flow diagrams (PFD), piping and instrumentation diagrams (P&ID), general arrangement drawings (GA), ducting and instrumentation diagrams(D&ID), material lists etc. In addition there is usually a more or less multi discipline 3D model of the plant as well. All of this information needs to be consolidated and monitored against the project execution plan (WBS)

Information in the functional structure is usually classified according to some kind of standard to better aid consolidation of data and interoperability between disciplines and/or companies in the supply chain

The location structure represents the physical location (where stuff is supposed to be installed). This structure is typically an area structure divided in areas and zones, or buildings, floors and rooms. By separating the functional location structure (tag structure) and the location structure it becomes possible to trace the tag for a cable that spans multiple locations like multiple floors, rooms or areas.

The more civil & structural or conventional facilities there are in a project, the more important this structure becomes as they to a lesser degree have tag information in their deliverables to the project but a lot of location centric information.
Already now the number of information structures and their interaction becomes quite complex, and we’ve still only covered plant engineering and execution.

As the plant design is starting to mature, discussions are started with equipment vendors and service providers who can supply equipment that fulfills the requirements stated in the plant design (functional structure). This can be pure off the shelf products or engineer to order (ETO) products. What they all have in common is a product design or engineering bill of material (which is far more detailed than both the EPC and ultimately the operator is interested in, but vital to the product development). Right now there is a debate regarding how much project specific information is really needed (in Norway), as even off the shelf products need to be documented quite rigorously for each delivery (tag) to a project. This has led to an explosion in cost.

Based on the product design, a commercial structure or Sales BOM is devised from the product manufacturer. This structure includes what needs to be procured and how the company intends to sell the product in question. If it is an off the shelf product this structure is along with the engineering bill of material quite generic, but if it is an engineer to order product they are quite specifically tailored to each project delivery.

The result of a product sales in a project will from the product manufacturer mean that a more or less structured Supply BOM is created. This information structure captures how the product is intended to be supplied. This includes whether it should be assembled in the product manufacturers workshop and then shipped to site, or if the product needs to be shipped in crates and assembled at the site itself

The warehouse structure or system at the project site must be populated with information from the product suppliers regarding what product deliveries are scheduled for installation, and what products are going into the warehouse as spares.

The physical devises with serial numbers are recorded (usually in a MRO system) and “mated” with the tag or functional location they are supposed to fulfill in the plant. The physical delivery for the product to be installed includes supplier documentation, product documentation, spare parts lists and certificates.

The relationships between functional structure (tag) and physical structure (serial numbers) constitutes the basis for installation and commissioning procedures. Each product delivery (serial number) undergoes mechanical completion tests to make sure it fulfills the requirements set by the tag requirements. As the plant is more and more finished, subsystems are tested and undergoes commissioning procedures, then bigger and bigger systems until hot commissioning is performed on the entire plant.
All the information represented by the functional structure and the physical structure in the end represents the documentation for operation (DFO), and is the basis from which the operator can operate and maintain the plant in a regulatory compliant and safe manner.

Now this all looks very sequential and nice, but the reality is that information needs to flow back and forth between operator, EPC and product companies all the way from early design through installation, commissioning and ultimately operations & maintenance.

So how can all this information be consolidated, managed and distributet to the various stakeholders in a plant project at the right time and with the right quality?

Some points to ponder
Bjorn Fidjeland

The header image used in this post is by Nostal6ie and purchased at dreamstime.com

Can PLM help industrializing Oil & Gas projects?

8/18/2015

For a long time it has been clear that oil & gas projects on the Norwegian Continental Shelf (NCS) are way too expensive, and that the costs must come down. Our main operator in Norway, Statoil, has been talking about the need for an industrialization of oil & gas projects for years, but at the same time contributing to even more Engineer To Order or one-offs due to very detailed and project specific requirements in the different projects.

It has therefore been very interesting to see what has come out of Statoil’s STEP program (Statoil Technical Efficiency Programme ). One of the six pillars of this program is standardization, industrialization and re-use of engineering and technical documentation wherever possible.

Historically however there have been limited drivers for EPC’s and product companies to deliver standardized solutions, as they have earned more money from tailor made solutions that was even required by the operators (See Resistance to change, a PLM tale from Oil & Gas), but I think that the incentives for change might be strong enough this time.

Interestingly there are examples of companies that have managed to move from pure Engineer To Order to more standardised solutions in comparable industries. A few EPC's have done exactly this. The incentive to change was brought forward by competition from low cost countries, and of increased and unsustainable use of engineering hours to get and to execute contracts. It was not uncommon to create more than ten different designs (or mini FEED's) for the same project in order to be awarded the contract.
This created a need to go from strictly Engineer To Order projects to a situation where technical documentation and designs could be re-used from project to project while at the same time generating project specific information like tags, functional requirements and how they were to be fulfilled by product deliveries.

One important part of the solution to achieve this was to create a globally accessible catalog of generic products and modules. This catalog had different aspects for each individual product or module:

The product specific aspect
The project specific aspect (tag/plant)
The supply aspect

The size and complexity of the products and modules varied from pump size to modules of several stories in height.
A PLM platform was used to manage the catalog with its different aspects, the off the shelf product structures (EBOM), the project specific product structures (if needed) and all the project specific plant/tag structures.

The products in the catalog was built as object structures with both meta-data (attributes) and generic technical documents associated with the objects in the structure. If a product was needed in a project specific context (a plant design/tag structure) it was simply picked from the catalog and then the project specific structure for that product or module was automatically created and tagged based on the project specific aspect of the catalog, and the context it was used in in the tag structure. Since this company also did EPC, they had to manage different tagging requirements coming from different operators. The way this was solved was to have one universal tagging methodology for internal use across all projects, and one external or custom tag for exposure to the operator, if the operator required a different tagging methodology.

The catalog became a crucial part of managing the entire company’s intellectual capital and was managed globally by Master Data groups responsible for each and every product / module and their aspects.
Of course this approach did not eliminate the fact that each project is unique, but it allowed for massive re-use and improvements across the entire portfolio of products and modules used across all projects.

This kind of solution also balanced the need for standardization with the need to make project specific additions to the plant design/tag structure in individual projects.

Maybe similar concepts could be used in oil & gas?

Some points to ponder
Bjorn Fidjeland

The image used in this post is by Satori13 and purchased at dreamstime.com

PLM and disconnected corporate processes

7/19/2015

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

From digital archive to intelligent data

6/7/2015

A lot of companies these days are working hard to turn their big digital archives into more intelligent data. These initiatives usually comes from some kind of digitalization strategy that has been formed to support a vision.

We see it every day, data is power, data can be analyzed, used in different contexts to support end customers, to sell new services or support internal processes in the company.

However, for this to happen it is not enough so simply store and manage data in digital format. The data must be “connected”, stored in object or information structures that represents the data used in different contexts. Coming from a PLM background, some of the aspects are quite easy to identify. From a product perspective you’ve got a requirements breakdown structure, maybe a model configuration or variant structure, an engineering bill of material that represents the design intent and supporting CAD structures from various design tools. All of the structures mentioned are being managed today as digital information, but very few companies have structured the information and put it all in context of the other information structures to achieve full traceability and change consequence control.

Note, I’ve so far only touched the product design aspect, so when considering the manufacturing intent (the manufacturing bill of material), the manufactured product, the sold product and the installed product the complexity grows, but so does the benefits of managing it all as connected data structures stored in context of each other. This data can be used to sell services to the end customers.

Examples could be a pump manufacturer who has full traceability on all pumps sold to different facilities. The pump manufacturer could offer services for maintenance of the pumps, and if the pump contains different sensors, the manufacturer could also analyze operational data to schedule preventive maintenance. This data could then serve as valuable input to the design processes of new and even better pumps. As a consequence of the fact that all data structures are connected, the pump manufacturer knows the location of all pumps sold, and can offer the new and improved model not only to all customers, but to all customers and all the locations for each customer.

All of a sudden we are touching one of the biggest fashion words these days “the Internet Of Things”, because what would happen if a large portion of the pumps were installed on ships and they contained sensors? The pump manufacturer could set up maintenance offices in large ports. Knowing exactly what pumps would arrive in what ports, at what times and what maintenance need they have would allow the manufacturer or service provider to order the right spare parts just in time and to reduce the maintenance time. This would minimize the risk of fines by the ship owners because the ship had to stay in port longer than scheduled or even worse, having the service personnel performing the service at sea and thereby leaving the service office in the port severely under manned.

This is only one example of the power of “connected data” or digitalization. Quite a few companies have similar business models as our pump manufacturer, but very few have the opportunity to utilize the services by “connected data”. Instead there are a lot of manual work, interpretation and searching for data in different digital archives. This in turn leads to errors, misunderstandings and lost business opportunities.

Some points to ponder

Bjorn Fidjeland

All images used in this post are purchased at dreamstime.com