Archive

Archive for the ‘Background and Structural’ Category

In search of efficiency for pipeline integrity management…

December 23, 2009 Leave a comment

A different approach to IM…

I think that a dashboard is needed.

Think about an airplane cockpit.  In a mature aircraft, like a 737, there are tons of instruments, controls, and warnings.  In contrast, the simplest planes may only have an airspeed indicator, altimeter, and a compass.  These three basic instruments are technically very simple to build, but they provide tremendous value to the pilot.

Airspeed is measured by a pitot tube, which is essentially a hollow tube that is inserted into the air rushing around the plane.  Altitude can be measured with a barometer.  Direction with a magnet on a bearing.  It doesn’t cost a lot to build these instruments, but it could be argued that they are the three most useful instruments on the plane. [cite – conversation with Jerry H on Dec 21]

Imaging trying to fly a plane without these instruments.  Pilots would not know how fast they are going, how far they are from the ground, or which direction they were headed.  It can be done, but  it is stressful.

Integrity managers are stressed.  Could it be because they don’t have the basic instruments they need to navigate their integrity programs?

Clearly this must be the case.  There is a lot of energy being spent trying to make the integrity manager’s life easier.  I know of operators who are doing additional data integration, or installing workflow engines to try to give the integrity manager a bit more visibility and control.  The PODS committee is feeling this need in the form of requests for new functionality. [cite PODS march meeting]

Vendors have picked up on this.  I know of four US companies who specifically address the integrity manager’s concerns.  There are countless other vendors who claim to make a portion of the integrity manager’s life easier.

It is my observation that much of the energy being spent on solving the integrity manager’s visibility and control problems is being wasted.

Some efforts, like additional data integration, are too narrowly scoped.  These projects are spending too much money building messaging systems that go into unneeded detail.  Other efforts, like full-blown BPM systems are too broadly scoped.  These efforts are trying to build the complex control systems of the 737 without taking the time to identify the essential instruments.

I think we need a dashboard.[cite – business week]  I think we need to identify the critical instruments the integrity manager needs and build them.  We need to identify the critical controls they need and build those too.  Let’s get these instruments into the hands of those who need them.

Who are the integrity managers?

In every company that operates a pipeline, there is a small group of individuals who are ultimately responsible for that pipeline’s longevity.  This group has the dual mission of reducing the cost of ownership and of reducing exposure to integrity-based fines.  We’ll call this group the integrity managers. [cite blog entry]

The organizational structure and composition of this group may differ, but ultimately these individuals are responsible for the following:

1: Creating a program (maintenance, regulatory)

  • Establishing an overall strategy
  • Developing a program to support that strategy
  • Creating procedures to support this program

2: Operating that program

  • Measuring the effectiveness of those procedures
  • Modifying the program to improve its effectiveness
  • Responding to unusual conditions

[Adapted from ASME Pipeline Operations; cite]

Programs for compliance

Historically rules concerning pipeline maintenance are operational in nature:

Example: periodic inspection of rectifiers [check]

When you encounter a new operational rule, the IM group will create a program for compliance.  Once the program is deployed, they are able to demonstrate compliance by comparing a schedule of required tasks against the work that was done.  The schedule is simple, if an asset is of type A then the tasks for type A must be performed within a prescribed interval.

Example: check valves have to be operated annually [check]

At first glance, the integrity rules appear to be operational rules.  “Pig the line every 7 years.  If you can’t pig it then use DA.  Dig up and fix sections that are really degraded.”  If this were truly the case, the IM team’s main concern would be if the pipe were piggable or not.  Compliance would be a simple matter of running assessments according to a calendar schedule.

Of course, things are never simple.  The schedule of the IM rules is not only driven by asset type, it is also driven by the environment around the pipe.  In addition to piggability, you must consider nine threats, three consequences, assessment methods, overall risk, mitigation activities et al.  These concerns apply cyclically over the operational life of the pipe.

Because of the need to consider the environment around the pipe, the rules have significant data handling and analytical components.  They require that data be integrated to support a risk model.  You must respond to discoveries within your risk model, not just your assessments.  You must react to changes within the data.  Instead of occasionally monitoring the rule, the IM team is actively participating in it.

Problem

Examine the responsibilities of the IM group again.  I have broken them into two phases – creating a program to support the IM rules and then operating that program. The IM team has been creating a program for IM compliance over the past few years.

As pipelines go through their second IMP assessments, they move into the operational phase.  Recall the elements associated with operating a process:

  • measuring program effectiveness
  • modifying the program to improve effectiveness
  • responding to unusual conditions

Each of these activities requires that the IM group look into the program and extract information from it.  Based on this information they will take action – kick-off a dig, B31G analysis, et al.  If something unusual happens, they will need to take action once to correct the problem.  If it keeps happening, they will need to alter the program so that it stops.

Hypothesis: The effectiveness of the integrity team is based on their ability to see information and respond to it.

To test this hypothesis one only has to look to other industries.  There is a wealth of case studies addressing this hypothesis in the field of business process management.  [cite needed. gartner?  wiki?]  This field has evolved since the first workflow engines in the 1970’s.  Businesses have continued to invest because they have seen results.  Measurable improvements in efficiency are very real.  So much so that Gartner recently said that you shouldn’t run your business without it. [cite]

I am going to assume that you subscribe to my hypothesis that your IM team’s ability to do their job efficiently is based on their ability to monitor their programs and their ability to intervene and adjust the process.  Let us then examine your IM teams capabilities in terms of visibility and control over their programs.  This will give us the problem we are trying to solve.

In the current environment the view is anything but crystal.  The view of the IM program is fragmented by task.  What does your team need to do to create a “vertical slice” of data across a section of pipe?  Is this something they can do effortlessly?  Now, what if they wanted to examine it historically?  Compare this to other slices?

Control for the IM team is no better.  Procedures that are written on paper, or in an electronic procedural library, don’t provide feedback regarding weaknesses.  Workflows that have been scripted into software tools provide feedback, but are difficult and expensive for the IM team to change.

Problem: What is the most effective way to improve the efficiency of the IM team?

Drivers:

  • Reduce cost of IM program compliance
  • Reduce exposure to IM related penalties and fines
  • Increase effective life of assets

What is available…

I know of four domestic vendors who are messaging to the problem the integrity managers are facing.  Each vendor is taking a uniquely different approach:

  • Vendor 1: Business process management
  • Vendor 2: Workflow engine
  • Vendor 3: Data integration
  • Vendor 4: Decision support

Clearly each of these vendors has a different take on the problem.  Ultimately, they are each trying to help the integrity manager be more effective.

Why such different approaches?  I maintain that each addresses a part of the solution.  Business process management and the workflow engine address the control portion of the problem.  Data integration and decision support address the visibility issue.

As the space matures these vendors should converge to similar answers.  Are you willing to risk your cash to help them find the answer?

So, what about looking to tools available for business processes?  Can these tools be adapted for integrity management?  Maybe.

The challenge is that there is such a broad spectrum of possible solutions.  Additionally the engineering processes behind the IM program are different enough from business processes that they should be examined:

  1. We deal with linear assets that can be parsed into an infinite number of segments.  Contrast this with policies, accounts, and patients which remain relatively discrete through their lifetime.
  2. Geospatial data is relied on much more heavily in our industry.
  3. Our “customer” is the longevity of the pipe.
  4. Our processes require trips from the office to the field and back.

While I think that the software tools are out there to solve the IM problems of visibility and control, I think that it would be useful to take an academic approach to the problem.  What I the most direct path to IM efficiency?  I maintain that nobody knows.

A call for research…

I believe that by studying the successes and failures of business process management we can quickly narrow our scope to those engineering processes that share similar patterns with corresponding business processes.  With a narrowed scope, we can then concentrate on the elements that make engineering processes unique.

To explore these problems, I am trying to set up some formal research through the Colorado School of Mines.  My objective:

Given the vast canvas of software support for business processes, devise a value-based protocol for applying these tools to support pipeline integrity management.

If you know of an operator who would be receptive to the idea of being a laboratory, would you mind helping me connect with them?

Benefits:

  • Be the first in the industry with a real solution
  • Working software tools to keep and expand
  • Thought-leadership in the industry

It will require:

  • Operator participation
    • help identify test scenarios
    • help collect baseline metrics
    • help select and install commercial software packages
    • help customizing them
    • help running tests
    • help analyzing results
    • help designing subsequent experiments
  • Funding
    • research grant
    • time from you or your staff
    • some software & hardware
    • some programming

Maybe if we’re lucky we can get PHMSA to help out with this as well.

Stay nimble!

– Craig

Log of the disambiguator… (volume 1)

December 4, 2009 Leave a comment

Today the disambiguator started reading my blog.  He/she (I can’t really tell) grumbled something about “stupid software jargon” and the grabbed my laptop.  Below are its writings.  I am labeling this as volume 1 because I have a feeling it will be back…

from the lair of the disambiguator…


Craig is concerned about software things, consequently he uses many software terms.  To disambiguate something means to determine its intended meaning.  It comes from linguistics and was adopted by computer science.  This document will be a place for me to clarify how he uses terms.

I like the being called the disambiguator because it sounds complicated and obscure.  You can call me the dissa.  Ironically, I want to make things simple and clear.  I think it makes a nice contrast.

Disambiguator Definition | Definition of Disambiguator at Dictionary.com

Client application

A software program which makes requests of another software program which fulfills those requests.  Usually the other software application is running on a remote server.  In terms of the user experience, a client application provides the interface (GUI) for a user to interact with. In terms of networking applications, a client application is the one making a request.

Specific types: Fat client, thin client
Synonyms: graphical user interface (GUI), user interface (UI)
Compare vs: Server application
Used with: client/server application, 2/3/n-tiered application, user experience (UX)
Examples:

  • Apple iTunes Store uses a thin client application that runs in a web browser
  • When using a central Geodatabase, ArcView functions as a fat client for this data

Client/server application

“Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfills the request. Although the client/server idea can be used by programs within a single computer, it is a more important idea in a network.” – What is client/server? – Definition from Whatis.com

I have heard many people describe client/server as a “normal application” (like excel or visio) which pulls information from a server.  This description implies a fat client application where the local software application does most of the work.  The server is only there to fulfill requests.  Contrast this with a thin client application where the server does most of the work and the local software application merely directs the server’s actions.

When I use the term, I will be using the broader sense of it.  I intend the term client/server to mean any client server arrangement in which one software program makes a request of another program which fulfills that request.

Specific types: fat client, thin client, networking
Synonyms: fat client application, 2-tier application, peer-to-peer application (rare to hear thin client called C/S)
Compare vs: thin client application, 3/n-tiered application, web-application
Used with: client application, server application, database application
Reference: Client-server – Wikipedia, the free encyclopedia
Reference: What is client/server? – Definition from Whatis.com
Examples:

  • Your online banking application is client/server.  In this application a thin client application runs in your web browser.  This client application accesses a server application across the internet.  It is this server application that does the actual work as it is directed by the client application.

Until next time,

the dissa

Welcome!

November 24, 2009 Leave a comment

Do a quick survey of companies claiming to support the IM rules for pipelines and invariably they are focused on the operations side of the business. In the operations world, compliance with the IM rule means running pigs and doing direct assessment.  In terms of time and effort, the hardest part is doing confirmatory digs.  The rulings have had minimal impact on the day-to-day life of a field services professional.

In contrast, the folks in engineering are feeling an enormous strain because of the ruling.  Typically engineering services will own compliance with the IM rule.  Whereas at one time a few engineers could run the integrity program of a major transmission company, the analytically rigorous and data intensive nature of the IM rulings have stretched these departments to the limit.

Follow along as I figure out how to make the world a better place for pipeline engineers.  I aspire to enable pipeliners to orchestrate their IM program to achieve visibility into the process, control over its behavior, and protection for the data behind it.

I am developing a concept called engineering process management (EPM).  It is an extension of business process management (BPM).  BPM has provided visibility, control, and protection to the banking, insurance, and a number of other regulated industries.  Along the way, the folks who have employed it have realized tremendous operational flexibility and control that has translated into reduced operating costs, fewer mistakes, and less harried workers.

I hope to bring the same benefits to the world of engineering where instead of banking transactions or insurance policies, we are concerned with the integrity of physical assets.  At this point EPM is only a concept.  Over the next few months I hope to begin building it. Right now I am looking for an operator who wants me to build it and is willing to pay me a little bit to do so.

Stay tuned!  I’ll share my progress, some of the things I learn, and some of my observations along the way. Here in these early days I’ll try to fill in some background as well.

Welcome! Glad you are here!

Leave me feedback below.

Craig