Exploiting The Digital Oilfield: 15 Requirements For Business Value 7301n

PRAISE FOR THE AUTHORS’ BOOKS: CHANGE IS THE RULE: PRACTICAL ACTIONS FOR CHANGE ON TARGET, ON TIME AND ON BUDGET & RED ZONE MANAGEMENT: CHANGING THE RULES FOR PIVOTAL TIMES

Double Day Select Executive Program Book Club Alternate Selection

“You don’t have to be afraid of change any longer! Change is the Rule offers entertaining and simple solutions that will help you move swiftly and efficiently through the growing pains of organizational change.” Ken Blanchard Co-author, The One Minute Manager and Leadership by the Book

“Just brilliant!” In his book “Change is the Rule” Dr. Winford E. ‘Dutch’ Holland expands on the metaphor of the organization as a theatre company - and it is brilliant! It’s brilliant because it simplifies understanding - it reduces the complexities of organization change to common sense with a very clear ‘picture’ to relate to. It is a very powerful metaphor that is very easily understood and ‘got’ by almost anyone who has ever been to any type of theatre presentation. Rick Sidorowicz from Best of The CEO Refresher on Leading Change

“What a great uncluttered roap for understanding, embracing, and leading

change. We have trained over 10 million leaders worldwide, and change is their biggest challenge. This book should be next on their reading list!” Dr. Paul Hersey, Chairman Center for Leadership Studies “Home of Situational Leadership”

“Organization change - on target, on time and on budget… what a concept! How easy it is to forget these fundamentals when we leap off the cliff of organizational change! The basics aren’t new - but they’re organized in a way that you want to slap yourself on the forehead and say “why didn’t I think of that”!” Katherine M. Tamer Vice President and Chief Information Officer United Space Alliance

These days we are constantly inundated with new books on the topic of management. However, Red Zone Management rises above the rest. It should be required reading for all managers, both to familiarize junior managers with the red zone management concept as well as to fine tune the inherent red zone management skills of senior managers. Mark A. Wallace, President & CEO, Texas Children’s Hospital

…a Red Zone loss could mean irrecoverable losses for your company. Among conditions that flag a Red Zone: major shifts in competitive strategy, mergers,

culture changes, and implementation of new computer systems. Principles for success under Red Zone conditions include practical advice such as, “Put the Best Players in the Game.” Holland points out that “if you select your organization’s best for the Red Zone and your key executives are not on that list … you may want to do some re-staffing.”

Red Zone Management pulls few punches, and its perspective is likely missing from many a boardroom. Harvard Business School Working Knowledge

Multiple rapid changes, successfully executed, will be the key to the 21st century business. ‘Dutch’ lays it out—change must be managed. To expect transformation without good management is a dream. This is a book that must be ‘on the desk’ of a successful 21st century CEO. Major General John S. Parker, M.D., Commanding General USA Medical Research and Material Command Fort Detrick, Md

“Simple ideas often turn out to be winners. Dutch first introduced his simple winning concept ‘Run-the-business: Change-the-business’ to our organization more than ten years ago. Managers who understand how to organize and handle these roles have been the key to the successful transformation of our company.” David G. Birney, President Solvay Polymers, Inc.

Red zone Management reads like the game plan for a space mission. I worked in the Red Zone for over 35 years and from the moment of launch through crew recovery Failure in our work was not an option. I worked with Dutch Holland for several years; his new book, Red Zone Management provides the fundamental guidelines for survival in today’s fast moving and unforgiving world. I would recommend it as a basic textbook! Gene Kranz, Author of Failure is Not an Option

“Red Zone Management is a new, creative and comprehensive treatment of a complex and seldom understood subject. I could not put the book down until I had finished reading it. The book is packed with case histories of business success and failures with comments for why the outcome was as it was. In the past while being involved in a major merger, my company successfully utilized the principles described by Dutch. The results were that the whole was greater than the sum of the parts—a resounding success for the shareholders. M. P. Corky Frank, President Marathon-Ashland Petroleum

EXPLOITING THE DIGITAL OILFIELD

15 REQUIREMENTS FOR BUSINESS VALUE

Dutch Holland, PhD

Copyright © 2012 by Dutch Holland, PhD.

Library of Congress Control Number: 2012918490 ISBN: Hardcover 978-1-4797-2632-5 Softcover 978-1-4797-2631-8 Ebook 978-1-4797-2633-2

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the copyright owner.

To order additional copies of this book, : Xlibris Corporation 1-888-795-4274 www.Xlibris.com [email protected] 119184

Dedication by Dutch Holland This book is dedicated to the kids in my life: the little kids — Everett, Dean, David, Win and Hope — and the big kids — Eric, Wendy and Bear. May they continue to flourish – and God Bless!

My thanks to Digital Energy Journal for their of my research and writing about the Digital Oilfield, and to Art Adair ([email protected]) who never met a paragraph he could not improve.

ABOUT DIGITAL ENERGY JOURNAL

Digital Energy Journal helps you keep up to speed with new digital technologies which are rapidly changing the face of the upstream oil and gas industry, enabling many new discoveries of oil and gas, and viable production with low human, environmental and social risk.

We focus on new developments which are already adding value in the industry – and explain them so they are easy to understand. You will want to read our magazine and newsletters straight away, not add it to your pile of material you promise to read one day.

We provide a bimonthly magazine (on print and pdf), a biweekly e-mail newsletter and a free website news and archive service – and you can subscribe to our e-mail newsletter and pdf magazine free of charge.

Our magazine is ed by a comprehensive social network where you can get into direct with some of the people behind the technologies and engage in private (or public) discussion, and perhaps also make yourself available so other people can you.

our website serves as an encyclopedia of digital technologies in the oil and gas industry - we have written about almost every company and technology in our magazine so you can learn about almost anything.

www.d-e-j.com

TABLE OF CONTENTS

Introduction

Implementing DOF Technology

Business Value Architecture: Overview Chapters

Chapter One

Digital Oilfield Business Value Architecture

Chapter Two

Strategic Business Architecture

Chapter Three

Work Process Architecture

Chapter Four

Technical Process Architecture

Chapter Five

Vendor Architecture

Chapter Six

Intelligent Interfaces for Effective BVA

Chapter Seven

The Digital Oilfield Culture

Chapter Eight

Implementation of Business Value Architecture to Enable the Digital Oilfield

ing Chapters with More Details

Chapter Nine

Collaboration and Incentives for DOF Implementation

Chapter Ten

Portfolio Management for Digital Oilfield Projects

Chapter Eleven

Implementation Strategies: Deploy or Adopt? Success or Failure?

Chapter Twelve

Caution: Workflow Analysis in Progress

Chapter Thirteen

Models for Innovation

Chapter Fourteen

DOF Maturity Factors and Limiting Paradigms

Chapter Fifteen

A to Z Services from DOF Vendors? Not yet!

Chapter Sixteen

Organizational Culture of for IT

Chapter Seventeen

Implementation Principles

Chapter Eighteen

DOF Leadership Roles

Chapter Nineteen

Who Does What for Digital Oilfield Value

Chapter Twenty

Go-No-Go Criteria for DOF Implementation

Chapter Twenty One

The Leadership Last Stand

Chapter Twenty Two

The Sweet Spot for DOF Professionals

Chapter Twenty Three

Big Ideas for DOF Implementation

Chapter Twenty Four

Integrated Risk Management for the Digital Oilfield

Chapter Twenty Five

The Test for DOF BVA Fatal Flaws

Conclusion

Implementing Digital Oilfield Technology

A NOTE TO THE READER

The wonder of our backgrounds causes us to want our content served up in an almost infinite number of ways. And we wish we could get the answers we want from just a few memorable sound bites. Sorry, the explanation of weighty and important concepts takes more than sound bites. We have, however, written this book to be as accommodating as possible with four options for getting value from our content. Good luck!

The organization of this book

The basic principles of Business Value Architecture are presented in the first seven overview chapters. The remainder of the book, ing Chapters, is more like a “reader,” in which a variety of DOF subjects are handled as separate topics. The majority of the subjects in these ing chapters have been published articles or white papers and written at separate times (and moods) over the past few years.

Option One: Just the meat, please!

If you only have time to read a few chapters, then read Chapters One through Six — the Overview Chapters. In fact, you might want to read them twice. Chapters one through six are written to be a short digest of Business Value Architecture for the Digital Oilfield. Then go straight to Chapter Twenty Four and take the Fatal Flaws test. that test and you have the meat of Business Value Architecture.

Option Two: No structure for me. Can’t I just skip around in the book?

Of course you can! Skip around. Just take a look at the table of contents to find chapters that are interesting to you or that relate to your current situation. Better yet, identify those chapters your boss needs to read and strategically position those chapters or important ideas from those chapters right in front of him or her.

Option Three: I want everything, big picture down to Details!!

If that is your goal, just keep reading straight through the book, making sure that you follow the instructions at the end of each overview chapter, instructions that will identify the Chapter(s) you might read before returning to the next overview chapter.

Option Four: I am only going to read “one,” get that, one chapter!

OK, read Twenty Three: Big Ideas for DOF Implementation. Knock yourself out.

INTRODUCTION

Implementing DOF Technology

Implementing digital technology for business value is one of the single most difficult endeavors any company will undertake! Fortunately, the principles for implementation are down in writing at last!

Implementing Digital Technology

SEVERAL RARE DECADES of implementation of digital technology for business value has proven to be both good and bad. The good news is that, when successfully implemented, such technology can be a major boon to a business. The bad news is that implementations are far more complex and difficult than anyone had imagined. Learning about implementation has been slow … but sure. The most significant learning has to do with managing different kinds of risks.

Figure I.1: The three critical risks

Business Value from implementing new digital technology is totally dependent on the successful identification and management of three separate but interrelated risks:

• Technical risks (will the technology work?) • Organizational risks (if it works, will the organization use it?), and finally • Business risks (if it works and is used, will the company gain business value?). This book that describes the business value architecture for implementing the Digital Oilfield has been written with this “great risk management learning” taken into in every dimension of the architecture we describe here. Now let’s move on to the specific kinds of digital technology that is the subject of this book.

Will DOF be a “Game Changer” or just another “Resource Hog?” The time for management to decide is now.

Implementing the Digital Oilfield

The marketplace is recognizing the potential business value of digital technology. The Digital Oilfield, led by numerous vendors, is “off and running” toward digital solutions. Correctly applied, digital technology can be a game changer for the upstream business of the future (UBF). What is at stake? He who exploits new technology first will have an edge until others catch up. But

applying digital technology is easier said than done as many companies are finding out.

Initial DOF projects have shown good potential but many have been degraded because of implementation problems, due to both technical and business lack of readiness. In of implementation, company approaches to DOF are all over the map with many approaches developed around existing vendor products rather than around work processes they wish to improve. Upstream companies must mature their understanding of DOF to be able to regain control and use the full power of DOF.

Phases of Learning from the DOF experience … so far

• Phase One: Oops! It’s not just technology! • Phase Two: Whoa! It’s people, processes, AND technology! • Phase Three: Wait! It’s business performance realization that counts! • Phase Four: It takes top-to-bottom “Business Value Architecture” to fully exploit DOF value!

Figure I.2: Four phases of learning from the DOF experience

After some years in a DOF 1.0 environment, characterized by a “one-project-ata-time” mindset and technology experimentation, it is time to move our thinking and our capabilities to the “enablement” of maximum value from digital technology. Enablement, an approach which provides means and opportunity, is dependent on three key factors:

1. Management purpose, will and commitment, 2. A business improvement imperative, and 3. The use of Business Value Architecture

If DOF is going to be used to achieve management’s purpose and for maximum business results, companies must “prepare the garden in which DOF fruit can grow.” The garden, in this case, is the company’s capability to put DOF resources to work for business value: it’s “Business Value Architecture,” the arrangement of the organization’s “moving parts” from the organization’s strategy for DOF, to its organization and incentive structure, to its operational and technical work processes.

The garden should enable organizations to move full steam ahead in the exploitation of digital technology to maximize business value. DOF must be enabled with the right organizational structure, the right work processes, and the right technical capability.

Figure 1.3: Enablement of maximum value from the Digital Oilfield

But before there can be a revolution in business value, there must be a revolution in the way companies manage their businesses using digital technology. Why do we need a revolution in the way we manage DOF? Aren’t we doing fine now? DOF in most companies is managed “a project at a time,” not as the companywide planned adoption of a valuable new technology that will serve the company and the industry for some time to come.

What is your organization’s state of readiness for the Digital Oilfield?

New technologies seem to come in waves. New technologies can make or break companies or careers. The challenge is to get your company on the bandwagon with a strategy that fits them. The challenge for you is to get on the bandwagon and help, not resist. We know that new technology doesn’t just get absorbed and used until the operations guys get on board.

Upstream companies are all over the map in the ways they are approaching the Digital Oilfield, from ive and unprepared to fully-prepared to exploit.

Figure I.4: States of Readiness to Exploit the Digital Oilfield

What are your organization’s next steps for building readiness for the Digital Oilfield?

1. Assess your organization and your state of readiness. 2. Determine exactly what is at stake for your organization and for you and your team. 3. Plan the steps needed to move to the fully-prepared position, and 4. Implement your plan.

Summary and key points

The wave is coming and it is going to make money for companies and make or break careers for managers and engineers. To advance their careers, engineers will need to be proactive to help their companies win. Stepping out and being the leader in the introduction of DOF will be an act of leadership that will serve an engineer well. Who knows? Maybe a hard-charger can become a digital engineer!

Business Value Architecture: Overview Chapters

CHAPTER ONE

Digital Oilfield Business Value Architecture

When an upstream company decides to “go for it” to maximize the use of Digital Oilfield technology for business value, the organization’s architecture, its moving parts, must be altered and configured specifically to exploit that technology.

JUST SAY THE magic words to fully realize Digital Oilfield (DOF) business potential. The DOF movement is here, and it offers great potential. But how does one realize that potential for his company? Simple. All that is necessary is getting executive management to speak the magic words … as in the interview below:

Scene 1 (An annual stockholders meeting of a public company)

AUDIENCE MEMBER (A WALL STREET ANALYST) I‘ve been reading about the Digital Oilfield, and it sounds important. What are you guys doing in DOF?

CEO Good question. We fully realize the value of digital technology as a key performance improvement tool. We’ve successfully completed two DOF projects

thus far, and I’ve given the “full speed ahead” signal to fully realize the business value of DOF. In fact, gains from DOF deployment are now specifically identified in our corporate strategy and goals.

COO (in charge of Upstream Operations) I agree with the CEO. We in operations have examined every inch of our technical and business workflows, and we’ve identified those steps where applications of DOF technology can produce the most business results. We have specific goals in place to realize that business value, and our guys are hard at work with our IT and Engineering folks to take advantage of those opportunities.

CIO My organization thoroughly understands those processes in the business where digital technology can add value. We’ve worked both inside our shop and outside with our vendor community to nail down the technologies and tools that we’ll need to bring to the workplace to meet those specific business goals. Let me read a letter I just received from our DOF vendor. “Thank you for selecting our company to be your lead Digital Oilfield technology provider. Your specific explanation of your needs and goals will allow us to meet your needs now and in the future.”

ANALYST Great … and thanks for your very specific answers… (Interview concludes)

Simple, right? Those are indeed the magic words for full DOF exploitation. But what’s behind those words from the CEO and his team? More than words are needed. The DOF revolution centers on the way that upstream companies configure their organizations for maximum use of digital technology.

Exploiting DOF through Business Value Architecture

Architecture may be a fancy word, but it is being used today to describe how an organization or an enterprise is “put together.” Enterprise architecture (EA) is a comprehensive description of an organization’s elements, i.e., its “moving parts,” including enterprise goals, business functions, business processes, organization, roles, business information systems, software applications, and computer systems.

When an upstream company decides to maximize the use of DOF technology for business value, the company’s architecture, its “moving parts,” must be altered and specifically configured to exploit digital technology.

In fact, fifteen (15) different moving parts must be altered or full business value will not be realized from Digital Oilfield Technology.

The resulting reconfiguration can be called Digital Oilfield Business Value Architecture (DOF BVA).

Configuring architecture for DOF might sound pretty mysterious … so let’s translate. Example: when a upstream company decides to make DOF adoption a higher priority, the goal statements of Senior Managers might be reconfigured to target specific business gains through the use of digital technology. Or, for another example, the operations organization may be called on to identify the specific parts of their workflows where DOF solutions (e.g., collaborative technology, data bases that can talk to each other) might make a positive gain in business results.

DOF BVA can be described as a combination of three different structures that must be aligned and integrated to maximize the business potential of digital technology in the business. Each structure contains five moving parts (requirements).

1. Strategic Business Architecture … including the company’s DOF vision and strategic goals, measures, and incentives 2. Work Process Architecture … including the matrix of technical and business work processes needed to achieve the organization’s strategic goals 3. Technical Process Architecture … including the processes inside the IT or R&D organization to manage the digital resources required to enable work processes and enterprise optimization Unfortunately the three architectures do not always work smoothly together. Effective interfaces are required between the architectures to provide smooth and harmonious operation. That important component of Business Value Architecture will be covered in a later chapter under the title of “Intelligent Interfaces for BVA.”

Figure 1.1: The Elements of DOF Business Value Architecture

Strategic Business Architecture

Everyone knows that something goes on at the top of their company — even though it sometimes seems mysterious. Actually, there are a handful of organizational elements that senior managers use that will need to be reconfigured to get DOF into full play … as in the list below.

Strategic Business Processes

1. Company vision, goals, and strategy explicitly reflect the company’s intention of exploiting Digital Oilfield Technology for improved business results. 2. Executive commitment to DOF is shown by investment in DOF architecture and by willingness to use pro forma results of DOF initiatives in financial projections. 3. Incentives are in place in the management ranks to motivate DOF exploitation to meet company goals. 4. Robust portfolio / program management is in place to make capital investment decisions, and bring them to life, including DOF 5. Explicit Decisions are made by executives to “Deploy” or “Give Permission to Adopt” for each DOF initiative that finishes development. Work Process Architecture

Work Processes (sometimes called “workflows”) are the steps organization take to do the work of the company. Included are the technical steps associated with upstream production, as well as what may be called the business steps of “making economic decisions about reserves.” It is the day-in/day-out completion of these many steps that move an upstream company toward its business goals. And it is these workflows that must be altered and enabled by digital technology that turn out to be the heart of the DOF movement. Improving process results is the name of the game … but first, an understandable work process architecture is needed for all of the operations of the firm.

Work Processes

1. Comprehensive map of core work processes is in place … i.e., for “valueadded,” “management,” and “enabling” work processes 2. Integrated goals with metrics are in place across operational work processes 3. Aligned structure, roles, KPIs and incentives are in place and in use around integrated goals and work processes 4. Proven method for targeting and developing business improvement opportunities (BIOs) and requirements is in place 5. Robust Business-Readiness implementation project management (for processes, technology and people) including comprehensive risk management is in place Technical Process Architecture

Not only are there business workflows, but there are very specific technical workflows required for the organization-wide exploitation of DOF digital technology. While some of the workflows in the list below may look familiar, there are some flows that might be seen as “new” for the technology end of the

business: new for some but still absolute requirements for a company that is going for it.

Technical Processes

1. Business needs discernment that accurately comprehends the range of operational transactions and decisions that could be made by the business / operations 2. Technology architecture design that optimizes the company’s technical capability to all types of work processes needed by the business to meet its goals 3. Technology acquisition that both secures needed technologies to architecture design and drives vendor innovation 4. Systems readiness method and project management is in place that can produce applications and systems that meet business improvement opportunity requirements. 5. Proven and secure implementation process is in place that does not put operations at risk during DOF technology implementation and testing. Business Value Architecture as a System

The three segments or sets of elements of business value architecture (strategic, work process, and technical process) are inextricably linked. Full business results will be obtained only if all three sets of elements feed and complement each other allowing a smooth flow of work and results that start with the company’s vision for the Digital Oilfield. The integration of business value architecture as a system leads to proven and secure implementation of improved operations processes that are enabled by digital technology.

Figure 1.2: The Elements of business value architecture as a system

All or Nothing

The reader might ask, “Does ALL this stuff have to get done to get DOF into play?” The short answer is “yes.” The initial concept of DOF Business Value Architecture has been broken into three more manageable categories, but the categories are interrelated. Fail to complete one category of organizational reconfiguration, and the end result will be greatly disappointing from both an operational and economic point of view. As the table below is meant to show, if one category of architecture is missing, the results are less than desirable.

Figure 1.3: Requirement for full value from Digital Oilfield

If one set of elements is missing, however, the result will not be a happy one that can range from bad news to very bad news. By far the one we have seen most often in our practice is the one labeled “Technical success but business failure.”

Figure 1.4: Results of missing architectures

The Development of Business Value Architecture

Once a company understands the necessity for Business Value Architecture, a valid sequential process for development of that architecture can begin. The process should be seen as a clean sheet of paper exercise, like zero-based budgeting. Taking the “pieces” of DOF practices that are already being used in the company, as the starting point for architecture development is almost sure to lead to an unbalanced and invalid architecture.

1st -Technical Architecture

• Vendor-driven based on their current products • Not based on operations needs • Technology

Figure 1.5: Today’s DOF architecture situation: wrong development sequence

The development of DOF BVA is a sequential and iterative workflow, starting with the development of the Strategic Business Architecture followed by development of Work Process Architecture and then Technical Process Architecture development.

Unfortunately, much of the DOF Architecture that is in place today in many companies was developed after the fact — around available products from the strongest, most powerful / credible vendors.

This after-the-fact development has resulted in a structure that might be called in some circles, the tail wagging the dog. As an example, look at today’s pattern of customer-vendor meetings: technical vendors hold sales “show and tell” sessions featuring their most applicable products with customers attending to see product demos and ask questions about relevance and capability.

A valid BVA development process would have customers holding vendor conferences to explain with precision to vendors the capabilities the customer requires to execute their battle plan for business improvement opportunities now and in the future.

Such specific capability requirements enable vendors to respond individually and innovatively to the customer to explain their capability to meet customer requirements.

1st - Strategic Business Architecture

2nd - Work Pr

• DOF mission defined • Incentives in place • Program/Portfolio Management • Work proces

Figure 1.6: Proper sequence for development of valid DOF Business Value Architecture

The Future Vision for DOF

Companies will gain the most from the employment of digital technology if they can have their senior managers honestly speak the magic words as above. However, before those magic words are spoken, there are important steps to take to get an upstream company’s business value architecture ready for DOF. BVA for Digital Oilfield: don’t leave home without it.

See Additional Chapters

• Chapter Eighteen: Leadership Roles • Chapter Nineteen: Who Does What for Digital Oilfield Value

CHAPTER TWO

Strategic Business Architecture

When a upstream company decides to “go for it” to maximize the use of digital technology for business value, the enterprise’s architecture must be specifically altered and configured. To translate, when a upstream company decides to make DOF adoption a higher priority for the enterprise, the goal statements of senior managers must be reconfigured to included specific business goals to be gained through the use of digital technology.

STRAIGHT OUT OF the dictionary: Yuck is “used to express rejection or strong disgust.” Yuck is the reaction I have when I, as a technical reader, encounter information that appears to be more than I need or want to read about. But beware of the yuck factor if you are at all interested in anything to do with today’s fast-spreading concept of the Digital Oilfield (DOF)!

Yuck! Why should I bother to read about such an arcane topic as DOF Business Value Architecture “at the strategic level?” The answer is simple: DOF is a new technology, and you as its proponent, are not likely to go far in producing results for your company or brownie points for your annual performance evaluation, if there is not a business foundation for DOF. Without the foundation at the right level of the organization, regardless of top management’s verbal signals of “go ahead,” DOF, and you, may continue to be little more than expensive curiosities. That is the bottom line.

“OK … even if that strategic foundation is important, what can I do about it? I am not exactly at what you might call the strategic level.” If you are connected to DOF in any way, you can do a lot about it; it is called executive education,

education that is patterned after Chinese water torture. Every time you talk, present, or discuss moving DOF forward, you talk about DOF business value architecture. If you think that term will yuck out your top management, then talk about “critical success factors for DOF,” or “known pre-conditions” or “lessons learned” … or whatever it takes. Sometimes a copy of a relevant article can be very helpful.

Enterprise Architecture

When an upstream company decides to “go for it” to maximize the use of digital technology for business value, the enterprise’s architecture must be altered and configured specifically for digital technology. To translate, when an upstream company decides to make DOF adoption a higher priority for the enterprise, the goal statements of senior managers must be reconfigured to included specific business goals to be gained through the use of digital technology. “Must” be reconfigured? Yes, behavior goes toward rewards, not toward words.

Strategic Business Architecture

Five organizational elements will need to be aligned by senior managers to get DOF into full play: (1) company vision, goals, and strategy for DOF, (2) executive commitment to DOF, (3) incentives for results from DOF, (4) robust portfolio / program management, and (5) explicit decisions for DOF Implementation.

Figure 2.1: Elements of DOF strategic architecture

1. Company vision, goals, and strategy must explicitly reflect the company’s intention to exploit Digital Oilfield technology for improved business results. Someone once said, “never underestimate the power of the written word.” We must believe that to be true, or we would not use up so many trees in writing “Vision, Strategy, Values, etc.,” and the other information we produce to guide our organizations.

No, it is not necessary to mention in goal statements that we will use conventional production, because that is not exactly new. But using Digital Oilfield technology to make better decisions about managing a field is new both to many organizations and to many managers, who may have been making production decisions “the old fashioned way.”

The key point to make is that a failure to include the desire to exploit DOF technology in the writings of top management can and will lead to confusion about just how serious the company is.

Example from an annual report: “Our company is once again investing in the future. We believe that the application of digital technology to the management of the upstream business is just beginning through the implementation of what is called “the Digital Oilfield.” For the year, we have set business improvement goals in operations to explore the new ‘Digital Oilfield’ technologies available to apply them to both learn and to obtain concrete business results.”

Later the Director of Information Technology speaks to the Vice President of Operations: “Well, finally we are official. Maybe now we can get some

momentum in the DOF project we have both been working on.”

2. Executive commitment to DOF must be shown by (1) investment in DOF architecture and by (2) willingness to use pro forma results in financial projections. Imagine that a company builds a new production platform. What are the chances that the anticipated production of that platform would be omitted from future earnings projections for the company? The answer is zero, because management is fully committed to making that platform payoff for the investors. The same must be true for DOF projects.

What if millions were committed to DOF projects to improve decision making without there being any mention of that investment and its anticipated earnings in the company’s financial projections? Would we read that as a lack of commitment or a lack of knowledge of what impact the DOF project should have on the business? Either way, failure to show anticipated financial results is a DOF killer.

Example from a planning and budgeting meeting led by the CFO:

CFO: Ladies and gentlemen, what you see on the screen now is our high-level look at next year’s pro forma financials. Notice how our revenue kicks up at the end of Q2 when we put our new platform on line.

Question from the audience: I understand the kick up in revenue idea but I don’t see the kick-up from the DOF initiative to improve field decision making that should increase production and reserves. Isn’t that project supposed to be up and running at the end of Q2 as well?

CFO: I thought about that, but the boss said he was not sure that the DOF project would come through on time, so he asked me to hold off on adding revenue to the pro forma.

CFO: Oops! The VP’s of Engineering and IT are making faces at me. What’s up guys?

VP of Engineering: We have been working diligently on that DOF initiative and we are confident we will get the results. And the last think I want our project team to see is the pro forma without any revenue projection from their project. Talk about a downer!

CFO: Well, looks like you guys need to go make your case to the CEO. And since the COO is sitting here without saying a word, you might want to make your case to her also.

3. Incentives must be in place to motivate DOF exploitation to achieve company goals. Archimedes said, “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” Such is the power of the lever. In organizational , incentives are the equivalent of the lever. What we want, we “describe” and then “incentivize.” Or to use an old phrase, we have to put our money where our mouth is. Failure to explicitly incentivize the exploitation of DOF technology at multiple management levels will result in much less than what we would call “a full-court press.” Incentives should never come automatically or through “activity.” Incentives should only be awarded when business goals are met by exploiting DOF.

Example from a letter from a CEO to Senior Executives:

“As you know I have already committed our company to enter the world of the Digital Oilfield during this year. I feel so strongly about the need to move in that direction, that I have asked our Human Resources Manager to develop several scenarios of incentive plans that would apply to your performance toward our DOF commitments. As soon as I have selected an incentive comp plan for next year, we will sit down and discuss it thoroughly.”

4. Robust portfolio management must be in place for all capital investment decisions including DOF, and Program Management must be in place to give direction and priority to those decisions. Regardless of the size of a company, there are only so many dollars that can be devoted to “new” infrastructure technology, or DOF. Those scarce dollars are allocated by top management using their process, which has probably developed over time.

The issue here is that the use of an allocation process from the past is not likely to put DOF investment opportunities into the same bucket of dollars for allocation as the “big, concrete assets.” If the potential investment in DOF can be only a derivative of another budget category like information technology, expect to see DOF get the short end of the stick.

Failure to explicitly put DOF opportunities into a head-to-head evaluation with other investment opportunities usually results in under-investment in DOF, given its business potential. Failure to explicitly put program management into the organization structure at the executive level, will leave the selected opportunities without direction or propulsion.

Example from a letter sent from CEO to Senior Executives and Department Heads:

As you are all aware, we have for some time been discussing

• the usefulness of more disciplined portfolio management methods to select our investment portfolio (including potential investments in DOF) and • the usefulness of more formal Program Management at the enterprise level.

After “hearing the direction” in the discussions, I have decided to name a team of senior executives to build an implementation plan for putting both formal Portfolio Management and Enterprise Program Management into use in the company before the end of Q2.

5. Explicit decisions to “Deploy” or “Give Permission to Adopt” must be made and communicated for each DOF initiative. Now this one may be hard to believe, but it is true, because managers in almost every company still treat investments in information technology dollars differently than the other investments they make.

For example, if top management funds the construction of a new platform, they would not have to call in the operations manager, sit him down, and say “The company is investing big bucks in this platform … and we expect you to use it to make money for the company!” Can you imagine the look on the operations manager’s face when he hears that? “What??”

But when dollars are invested in DOF initiatives, like a decision system for example, top management DOES have to sit down with managers and tell them that very thing: “When the new decision system goes live, I expect that all decision made about capital assets will be made with information from that new system.” Failure to have that direct, explicit conversation will automatically send the signal that using the new DOF application is optional.

Example: CEO and COO remarks at a Senior Executive Meeting:

CEO: Charlie here wants to bring up a point about implementing DOF technology solutions … Charlie.

COO: Thank you. We have had some good results from the last two DOF projects we completed. In both cases, methods were developed that can save us time and money. In the past, we have offered such solutions to our managers for their use in their organizations. That practice has resulted in very slow implementations of very good ideas as each manager decides when or if the new method will be implemented in his organization.

My suggestion is that we run completed DOF projects back through Portfolio Management and collectively decide if the DOF method is good enough for organization-wide use. If it is, I suggest that the CEO make a formal statement to the organization that we will all put that new method in place by date certain. If the Portfolio Management process evaluates the DOF solution as valuable but not necessarily needed in every organization, I suggest that I as the COO announce to my managers our permission to use the DOF solution if desired.

CEO: Good. So let it be written; so let it be done.

Fail to complete one category of organizational reconfiguration at the strategic level, and the end result will be greatly disappointing from both an operational and economic point of view.

Figure 2.2: All strategy elements are necessary

As the table below is meant to show, if one key ingredient of strategic architecture is missing, the results are far less than desirable.

Figure 2.3: Results of missing element

See Additional Chapters

• Chapter Eleven: Implementation Strategies: Deploy or Adopt? • Chapter Fourteen: DOF Maturity and Paradigms • Chapter Eighteen: DOF Leadership Roles

CHAPTER THREE

Work Process Architecture

While work process architecture doesn’t sound very technical or very digital, it is in fact the key factor in exploiting DOF for business value. Business results are driven by the processes used on the operational side of the business, and it is those processes that must be enhanced if there are to be improvements in business value. That fact puts operations management in the lead position for improving business value with DOF technology.

Operations as the driver for Digital Oilfield payoffs

WORK PROCESSES ARE the steps organization take to do the work of the company. Included are the technical steps associated with production management, as well as what may be called the business steps of “making economic decisions about production.” It is the day-in/day-out completion of these many steps that move an organization toward its business goals. The heart of any DOF strategy is to improve these processes by enabling them with digital technology; but first, a powerful and robust work process architecture is needed.

Figure 3.1: Elements of work processes

Work Process Architecture

Five organizational elements will need to be strengthened and aligned by senior managers to get DOF into full play: work process maps, integrated metrics, aligned organization and incentives, business improvement opportunity development processes, and a business readiness methodology.

1. A comprehensive map of core processes must be in place to serve as the foundation for any improvements that DOF technology can bring.

A map might be important, don’t you think? Want to use digital technology to improve upstream operations? Start with a map of the myriad of work processes that make up the operation of the upstream business.

Developing smart, valid mapping that has the right level of detail in the most potentially-fruitful parts of the work process domain is the goal, not infinitely detailed workflows of anything and everything that moves in the company. Valid work process mapping must comprehend all three kinds of upstream processes, because the pots at the end of the rainbow will likely come from all three process types:

• Value-added processes: what we sometimes call physical processes that make holes and carry product.

• Management processes: frequently called decision processes that produce orders and directions for running the upstream operation.

• Enabling processes: frequently, erroneously omitted from DOF discussion all together, such as supply chain.

Example: VP of Operations to CEO:

VP: Come by and see our war room. We have every work processes mapped at a high level … and the maps are all around the walls of one briefing room. We are now going over everything with a fine tooth comb looking for places where an improvement in processes might make sense.

CEO: That does sound interesting. Where did you get the time to do that amount of mapping? And who is going to keep your war room up to date?

VP: Fortunately the CIO is very interested in helping us with work processes so he volunteered some talent to work with my guys to get it done. He said that he can’t do a good job of aligning with us if he and his guys don’t know our work process architecture as well as we do.

CEO: Our CIO said that? Good!

2. Integrated goals with metrics must be used across work processes to make operations a manageable system.

A work process without goals and metrics is like a tape measure with no markings. Most everyone has heard the old saying: If you can’t measure it, you can’t manage it. That is still true. Unfortunately, many have taken that idea to mean dollar (revenue and/or cost) “measurement by organization, by department, or by individual producer.” Not only are these not the kinds of measures that are needed, they frequently get in the way of the metrics that will be needed for exploiting DOF.

“Measure it to manage it” goes even further. Without measures of work process steps as well as process outcomes, it is impossible to do any kind of in-depth analysis that can be used to generate and evaluate the potential of Business Improvement Opportunities. Without metrics, operations will not be able to generate performance targets that would allow technologists to identify and select digital solutions.

Example from conversation between VP of Operations and the VP of Human Resources:

VP HR: I hear that you have a team working on metrics and goals across work processes. Could I get a couple of my compensation specialists on that team?

VP OPS: Well, I had not thought of that. You and your guys are supposed to help us with performance appraisal, right?

VP HR: Right … and we will need to bring you recommendations for incentive comp as well. That’s pretty tricky, or should I say technical, so I want my guys to understand the business processes inside and out.

VP OPS: Good thinking. Does this conversation mean that I should recommend you for incentive comp?

VP HR with a grin: Guess it wouldn’t hurt!

3. Aligned structure, roles, and incentives must be in place and in use around integrated goals and work processes in order to power the organization with human energy.

The key to making a DOF strategy productive is an organization structure on the operations side of the business that puts a senior manager on point to leverage digital technology. More than just an appointment, this job should be given to an “up and comer,” one of the top two or three senior managers, already at the top of the operations organization, who is in line for movement even further up the organizational chain.

In addition, all operations managers must have key performance indicators and incentive structures that will focus some of their prime time on leading Digital Oilfield initiatives in and around their asset. Every manager in operations is in a position to identify potential business improvement opportunities (BIO’s). In addition, all managers must clearly understand their charter to lead their part of the organization to business readiness when a business improvement, enabled by digital technology, is to be implemented with their personnel.

Example from conversation between CIO and a Senior Ops manager:

Ops: John, I came to see you to tell you about a new role I will be playing in operations. I am still in charge of my region, but I am now the guy who will

champion business improvements that are enabled by DOF technology.

CIO: I understand. Does that mean you and I will be working together to help my IT organization better align with and serve operations?

OPS: It does, and I want us to get to work plotting a future of potential business improvements for the next three to five years.

CIO: Sounds like the end of an era of “I need one of these” is officially over.

OPS: I can assure you that it is!

4. A proven method for targeting and developing business requirements and improvement opportunities (BIOs) must be in place to point out leverage points for DOF technology.

This is it. This is the bull’s eye, the engine, the process that develops the organization’s “battle plan” for improvement. No amount of digital technology will be useful if it is not used on the most critical (or fruitful) business improvement opportunities.

Unfortunately, those BIOs with the most potential don’t self-identify; they must be uncovered and teased out from within the mapped processes. The general idea is that every work process and every step in every process has a “digital economic potential” that may be realized with process improvements enabled by DOF technology. Find the high potential spots and you have BIOs.

The only way a BIO development process will work is with valid and robust BIO selection methodologies, experienced operations leaders, and appropriate subject matter experts from both the operations side and the technology side, all focused on “mining” work process maps.

Example: COO to VP of Operations:

COO: Did I just see another list of hot spots your guys have staked out for improvement with DOF technology? Seems like I just saw a list like that a few weeks ago.

VP: You did see a list, but that was three months ago … , I came by and put the list on your desk. My guys and I are trying to get into the discipline of looking for business improvement opportunities every quarter. We only cover a part of our work process architecture each time, so in a year we have gone through the entire operations organization.

COO: Got it. So that is the list you show up with at the portfolio management meetings.

VP: That’s it. And we are doing a better job of explaining the business case for each potential improvement in order to get your attention for more bucks!

COO: Yeah, I thought this conversation was going to get around to money sooner or later. I wish you good luck, because I am seeing lots of good potential projects from other parts of the company.

A Critical Note

In the next section we will cover the first of two mission-critical readiness processes. Definitions come first.

• A readiness process is a set of tasks executed in a project to prepare an entity or an asset for next use.

There are two such sets of tasks that must be used in order to successfully complete a business improvement that is enabled by DOF technology. The first of those readiness processes – preparing the operations unit to use improved processes and DOF technology –will be covered next. The second readiness process will be covered as an essential ingredient of Technical Process Architecture (Chapter Four).

Figure 3.2: Two Facets of DOF Readiness

Both the operations organization and the technology must be readied so that operations can “go to work at go live” using the new work processes enabled by the DOF solution.

• Preparing the organization to use technology that “does not work” is a disaster.

• Successfully preparing the technology for an organization that is not ready, willing and able to use it is a technical success but a business failure.

Business Readiness and System Readiness efforts, or projects, will need to be “ed at the hip” for implementing solutions in targeted business processes that are to be enabled by digital technology. This means some key people will need to have access to and influence in both readiness efforts and have the discernment and leadership capacity needed to modify plans and expectations as an implementation goes along.

The ed-at-the-hip idea is shown graphically by Figure 3.3: Business Readiness and Software/Systems Development Cycles. These two cycles will be covered in more detail shortly. The idea here is to reinforce that the two cycles must be in sync and be completed for successful implementation.

Figure 3.3: Business Readiness and Software/Systems Development Cycles

Critical to the success of this two-project approach is the right ownership, leadership, discipline and ability. The Business Readiness Project can only be owned and led by the senior management of the operations side of the business. The System Readiness Project can only be owned and led by the senior management of the technology organization.

5. Operations must have a robust Business Readiness method in place for implementing a DOF solution (for processes, technology and people) including comprehensive risk management.

Despite almost two decades of “doing it wrong,” many companies implementing new information technology still depend on the “one-big-technical-project-thatdoes-everything approach,” with tons of technical readiness and almost no to get the business ready for the technology. Such a one-sided resource distribution practically guarantees a “technical success but a business failure.”

Myths about Business Readiness

Myths are widely-held but false beliefs or ideas. Unfortunately myths surround the preparation of the business organization for use of a new technology like a DOF application. How many myths are there? Many, but five very destructive myths are:

• Myth One: This software/system will be so good and so easy that our

operations people will find its use “intuitively obvious” … and besides, there are plenty of pull-down screens for the extremely-remote chance that some half-wit might get stuck.

• Yes, there are still technical folks out there who are repeating this myth with a straight face. No software has proven to be totally bolt-on and so easy that it reads the minds of s and answers their questions before they even know they should have the question

• Operations need help in learning how to use the software/systems to get their operational jobs done. Period. No shortcuts.

• Myth Two: The IT guys and their vendors (software and systems integrators) will prepare the operations folks so that Ops management need not get involved in prepping anything or anybody.

• The IT-side of the house and their vendors usually provide comprehensive, detailed, overly-rich system training (it’s in the software contract) to proudly show operations everything “this baby will do!” System training is needed … but not on every possible functionality the software can provide.

• Operations folks need system training that covers the functionality needed for them to do their job … and nothing more in the way of system training.

• Myth Three: We have this great project manager running the technical project, (i.e., getting the DOF system ready for the organization), his project team with get all our business s prepared and ready to go.

• Great project managers are vital to successfully preparing a DOF system for the organization. Managing that preparation process is more than a handful.

• Business Readiness cannot be successfully provided by the technology side, even with that great project manager, because he does not have the rank, position, and authority to make anything happen on the operations side of the business.

• Myth Four: We have been careful to include super-s from the operations organizations in our technical project. Their input assures us that the organization is now ready to use the DOF system (after all, they are “super s”).

• The use of super s in the software/systems readiness project is clearly important and useful, since they come from the operations side of the house

• However, using super- input does not in any way prepare the operations side of the house to be ready to use the system.

• Myth Five: We have a corporate “Change Management Professional” with multiple degrees in the behavioral sciences who can lead business readiness and allow operations managers to continue running their day-to-day business.

• Readying the operations organization is not a psychological problem but a straight-forward management challenge that must be executed by operations managers who have:

• intimate knowledge of the work processes being improved and enabled with DOF technology and

• the “rank and authority” to officially make changes in the organization.

Steps in the Business Readiness Cycle

Business readiness can only be accomplished with the right leadership and the right steps. The right leadership can only come from business-side managers who have the position and authority to make change happen. Preparing the business for use of the DOF system requires the following five steps or actions, taken in every operations department and with every business (shown in Figure 3.4). The full explanation of these five steps would require considerably more space that we can accommodate in this book. We can, however, illustrate the Business Readiness cycle with the following high-level points.

Figure 3.4: Steps in the Business Readiness Cycle

The way any organization (or a car) works at a given point in time is the direct and inescapable result of the configuration of its moving parts. An organization has four main components or categories of moving parts that must be altered for every change, including the readying of an organization to use a new DOF technology.

a. Develop and communicate the vision … communicate the organization’s picture of what the improved business process will look like with DOF technology in place.

b. Alter work processes … alter the steps that organization (and machines) must take on a daily basis to enact the vision of the improved business process with DOF technology in place.

c. Alter facilities, equipment and technology (FET) … alter the organization’s plant and facilities along with its tools, equipment, software, that organization will need to use in the organization’s altered work processes

d. Alter the performance management system … alter the organization’s mechanisms for engaging workers to follow work processes and use the provided tools to enact the vision.¹

e. Use Project Management to guide business readiness … use disciplined project management to make sure all the business readiness actions above

are completed on target, on time, and on budget.

Example from a company policy manual:

This company will be capitalizing on the advantages of DOF as an enabling technology for work process improvement. The following will apply:

1. The Operations Division will continuously seek improvements in their work processes. 2. All improvement projects costing more than $500,000 will be undertaken only after the VP of Operations approves a written business plan. 3. If an improvement project will be enabled by DOF technology, all costs associated with that technology will be funded from the approved business plan. 4. The Operations organization will be in charge of all aspects of the business improvement project and will: a. Ensure all work-process improvement steps are completed b. And that all operations employees are fully ready to use the DOF Technology 5. The R&D or IT Department will be responsible for readying all DOF technology for use in operations.

Figure 3.5: Ingredients necessary for Complete Work Process Architecture

All or Nothing

Fail to complete one category of work process architecture, and the end result will be greatly disappointing from both an operational and economic point of view.

The Future Vision for DOF

The future vision for the Digital Oilfield is bright for those companies that recognize that the key to success, the heart and soul of the digital strategy, can only reside within the operations side of the business that is committed to growth using digital technology as a key means.

Figure 3.6: Results of missing elements

See Additional Chapters

• Chapter Twelve: Caution: Workflow Analysis in Progress • Chapter Thirteen: Models for Innovation • Chapter Seventeen: Implementation Principles

CHAPTER FOUR

Technical Process Architecture

Technical work processes will need to be in place and aligned by senior managers to gain full business value from Digital Oilfield initiatives: needs discernment, technology architecture design, acquisition of technology, systems readiness, and technical implementation. This chapter will identify both critical technical processes and subject matter skill sets that will be vital in the deployment of digital technology.

THE TERM DIGITAL Oilfield practically screams out the message: “We have digital technology that can save cost and increase reliability if we can just get it deployed on the operations side of the business.” Translated, the technical side is ready to go and just waiting for operations to catch up. Often times, this is not the case. Many upstream technical organizations today are both ill-equipped, process-wise, and inappropriately staffed to help their companies exploit the potential of the Digital Oilfield.

Figure 4.1: Elements of Technical Process Elements

Technical Process Architecture

There are very specific technical workflows or processes required for the organization-wide exploitation of digital technology. While some of the processes listed below may look familiar, there are some that might be seen as new for the technology end of the business.

Five robust technical work processes, or organizational elements, will need to be in place and aligned by senior managers to gain full business value from Digital Oilfield initiatives: needs discernment, technology architecture design, acquisition of technology, systems readiness, and technical implementation.

1. The IT Department must have a “business needs discernment process” in place, not a requirements identification checklist.

A discernment process will be needed that accurately comprehends the range of operational transactions and decisions that could be made by the business both now and in the future.

The dictionary definition of discernment is “the quality of being able to grasp and comprehend what is obscure or not well defined.” Discernment is a major challenge for what has been called “requirements definition.”

Unfortunately discernment may not yet be a strong suit in many upstream

technology departments. Who has the discernment to articulate appropriate needs? Perhaps it is only technologists who are experienced in both operations improvement and technology design and development. It will be critical to staff and manage the interface between technology and operations. The technology unit must put their strongest people into the discernment process.

At this point two things are clear: discernment will always be necessary, and recent college graduates using a “requirements interview guide” to talk to operations managers will not be an adequate mechanism for discerning needs.

Example from a conversation between the Manager of Application Development (MAD) and her boss, the CIO:

MAD: Thanks for arranging for me to attend that course; what I learned will be very useful.

CIO: Good. What did you think about the consultant’s stressing the idea of “discernment” in the requirements definition process?

Mgr. of AD: Well, first I was surprised … and then I got scared. We don’t have any requirements people who can go over to Operations to talk to their people and discern messages. Our folks just don’t have that kind of background.

CIO: I was hoping you would see that issue in the course. Now that you’ve seen it and gotten as scared as I have, I want you to “front burner” find people who can do that. And I don’t just want people who can discern, I want them to be able to see where operations is going in the future … so that we can get ahead of operations in our thinking. I am getting tired of being told in staff meetings that

my department is “behind the times.”

MAD: I understand.

CIO: Meanwhile, do we know who the operations guys are who are the forwardthinkers for their organization? Let’s find out and get to know them. They can help us re-design our interface with operations.

2. The IT Department must have a Technology Architecture Design Process to optimize the company’s technical capability to the types of work processes needed by Operations.

Easier said than done, however. A famous hockey player once said that the secret to his success was “to skate to where the puck was going to be.” Such is the challenge in the design of technology architecture to position functionality so that the operations side of the business can skate toward the most vital and productive business improvement opportunities, using/counting on there to be IT to enable their direction.

• The technology architecture design process is at its best when it can both follow and lead business operations towards business value

As in the first technical process discussed, positioning architecture is dependent on great discernment, based on the technologist’s understanding of both operational upsides and technology capabilities. Technical capabilities must be based on an aggressive “technology watch” competence that monitors and assesses progress in technology, security, and standards.

The goal, however, is not to just follow the direction of operation’s needs but to de functionality and capability that might lead operations to see and solve their business and technical problems in fundamentally new ways. Technology architecture is at its best when it can both follow and lead the operations side toward business value.

Example from a meeting chaired by a senior IT manager:

IT Manager: Welcome to the quarterly Technology Watch and Architecture Forum. I am glad to see some new faces from Operations … including the DOF champion from operations. Did I get that right, Paul?

OPS Champion: You did!

IT Manager: for those of you who are attending for the first time, let me overview the purposes of our group. We have three moving parts we are trying to track and integrate when it makes business sense to do so:

• The operations champion and his team try to get a handle on what you might call the direction of the development of operations technology and work processes in order to craft a sense of their future use of technology in improving their business results.

• We in IT are using a “technology watch” process to continuously scan the technical world for IT developments coming down the pike … developments that could provide some of the functionality operations will need (today or down

the road).

• And our technical architecture team absorbs, discerns and then designs the shape of the architecture we will have to have in place to keep moving both operations and IT forward.

OPS Champion: Well said, and we in operations appreciate the opportunity to try to tly look ahead as best we can to give you guys some direction for your planning and innovation.

3. A Technology Acquisition Process is needed to (1) drive vendor innovation and to (2) acquire needed technologies to technology architecture design. This deceptively-simple statement requires a technology architecture design that is rooted in current and future needs of operations.

While some technologies may be developed in house, many DOF technical elements are likely to come from technical vendors. The ideal would be for the technologist to be able to give clear functional specifications to vendors, so that they might put their innovation processes to work to serve up technical solutions that meet operation’s needs.

However, many technical vendors today state that their customers for DOF technology are not able to articulate functional requirements to the degree needed for an effective vendor response. Rather than a buyer holding a requirements conference for several qualified DOF vendors, vendors are holding the conferences to show what software they have, hoping to serve up one that the buyers can see fitting into their company’s future. And as buyers acquire what’s being sold, they accumulate bits and pieces that must be cobbled together as requirements become clearer.

It is no surprise that today’s customers have technology configurations that span the spectrum from assortments, to cobble-ware, to coherence, to truly enabling architectures – depending on the driving forces for technology sourcing.

Example from a conversation between the CIO and one of the top managers in operations:

OPS: Where have you been, haven’t seen you around.

CIO: I just returned from a four-day customer conference given by HAL; boy, do they have some neat stuff.

OPS: See anything interesting?

CIO: Yes, I saw a number of applications/systems that the HAL guys said we probably need to handle all the data you guys in operations generate. What have you been doing?

OPS: What have I been doing? We just had a bidder’s conference here at the plant to talk about our needs for the next platform power supply.

CIO: Oh, did the vendors who might bid show you any of their new stuff.

OPS: No, we asked them not to; we wanted to spend our time describing exactly what we were trying to do and what all the functional specs needed to be. When they come back one-at-a-time next month, each vendor can show us exactly what he can do to match our needs.

CIO: Oh, I see.

4. A Systems Readiness Process must be in place that can produce/ready applications and systems that meet Business Improvement Opportunity (BIO) requirements.

The second readiness process in the Business Value Architecture is designed to prepare the selected applications and systems for use in operations. Most technology shops have an applications development function (i.e., what we have called “systems readiness”) containing a proven and refined software/system development process. A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system. That process, used in a disciplined way, will be critical in DOF technology exploitation like the one shown in the figure 4.2 below.

Figure 4.2: Software/System Development Life Cycle

There are three problems with typical software/system development that can become obstacles to DOF implementation: “silo” development, lack of visible progress in the systems readiness process, and applications / systems testing.

Problem – Silo Development: Silo development is not a new phenomenon in system readiness. The idea of taking requirements from operations and then going into a dark room to develop applications only to emerge weeks or months later with a completed deliverable is commonplace.

Development in the dark, or developing in an isolated environment, can be a cause for the readying of the business and the readying of the DOF system to be out of sync and miss-aligned. To prevent separate development or to let the operations side see or feel and therefore value progress, a number of techniques or approaches have been developed and put to good use, such as prototyping, “spiral,” “agile software development,” “rapid prototyping” and “incremental development.” While each approach has both advantages and disadvantages, the ones that give maximum flexibility in responding to changes and are the most transparent would have the edge in preparing DOF technology for the organization.

Problem – Lack of Visible Progress: Progress is easy to observe in some readiness situations. For example, when a chemical company wants to add another production unit, progress is usually pretty obvious. There is likely to be construction work clearly visible to managers and employees alike for weeks, if not months. When construction and testing of the new unit are complete, it is rare for any managers or workers around the chemical plant to be surprised that the new facility is ready to go to work to make product and money for the company.

Watching construction progress is a favorite pastime of many employees on the job. But beyond providing entertainment, watching construction progress helps employees mentally prepare for their part in any new operation. In fact, if employees see construction that is nearing completion, and they have not been trained on the new equipment, their anxiety goes up as “go-live” approaches without adequate preparation for utilization.

All of this sounds logical and simple. But things don’t often progress this way for an IT system implementation. In fact, the opposite is likely to be the case. For many employees, the frantic work that may be going on to ready the IT system may be invisible. And to re-coin a phrase, “out of sight, out of mind.”

Lack of visibility of progress toward system “go-live” prevents mental preparation and contributes to a low sense of urgency on the part of operations personnel. Project managers who are responsible for a system startup, and business managers who are able for making money with the new system, don’t have to wait in the shade, however. They can take concrete actions to make system readiness progress visible.

a. Signage – simple signs (like the thermometer we frequently see for a United Way campaign) can show a moving “percentage completed”

b. Business Improvement Opportunity (BIO) Project Website – creating and maintaining a unique website just for the business project enabled by the IT system can be used to show news about progress

c. System Demonstrations – show and tell demonstrations can make the coming system real and more tangible

d. Acceptance Testing – In this most important step, employees get to “see and feel” the system that is on the way. At this point, employees begin to believe there really is a new system.

e. Work Process Training – Employees should have the advantage of two (count them), two different kinds of training: system training (system operational instructions) and work process training (training on using the system as part of the employee’s day-to-day job.)

In summary, seeing progress is an important part of the mental preparation employees must do to be thoroughly prepared “to go to work at go-live.”

Problem – Testing: Testing is an accepted and valuable step in the software/systems life cycle. However, testing in “view of operations” will be quickly seen as an immediate threat to their steady-state operations. As many technology organizations have found out the hard way, operations is not a test environment. As much testing as possible must be done before any software installation in the operational world.

Example from a briefing given by CIO to senior operations managers:

CIO: Good afternoon ladies and gentlemen. I asked to brief you today on the process and approach we in IT will be using to prepare several DOF applications for use in your business project of improving real-time decision making. I have asked Ralph, our Director of Application Sourcing and Development, to lead the briefing.

Ralph: Greetings. My goal today is to reassure you that we know your business mission in this project and that we have developed a system readiness approach that will fully meet your needs. As you may know, the suite of DOF apps we will be preparing for you are a mixture of off-the-shelf apps and those being prepared by an outside vendor.

Ralph: In our shop we use a standardized software/systems development process that has proven to be very reliable and powerful. Our standard process also uses “agile project management” and “rapid prototyping” in the development cycle, that is, the system readiness cycle. We are confident that you will get what you need and that you will have ample opportunities during the system readiness project so see how our development is shaping up against your business needs.

Senior Ops Manager: How will we know how your system readiness project is coming along?

Ralph: I will be present at each and every meeting of your business improvement team to give you visible evidence of progress. In addition, you have been kind enough to loan us two super s of your current applications to be on our DOF system readiness team to make sure we are on track with your business needs. They can give you real-time on our progress as they see it. I can assure you that we intend to hit our DOF readiness objectives on target, on time, and on budget.

5. The technical organization must have a Proven and Secure Technical Implementation Methodology and the disciplined project management competence to use it.

Managers in business operations need proof that the chosen installation / implementation methodology for the DOF system has been tested and retested

and – declared bullet proof. Most operations managers have already been down the IT implementation road, and most have either suffered problems or they know a peer who has had a problem. One can draw that conclusion when you overhear an operations manager sitting down for the technology presentation from IT. The ops guy starts the briefing / demonstration with two requests:

• I want you to show me, and prove to me, that your DOF system fits our business processes and works like a charm, is robust and solid as a rock, OK? … and

• I want you to show me and prove to me that your system implementation method and plan will not disrupt our operations and is as risk-free as humanly possible, OK?

Perfect software can be implemented poorly, causing operations anything from a mild upset to an outright catastrophe. What is the problem? Installation of big system software like DOF has been known to cause disruption in the operations unit. In the upstream business, disruption is the original unforgivable sin, and careers have been killed for causing it. News of a disruptive installation is guaranteed to travel through the rest of the operations community like news of a white powder in the mailroom.

The fact of the matter is that operations guys will not take the risk that the implementation of the “Oh-so-wonderful app” will compromise or shut down operations. The key idea is that a well-designed and reliable app must be ed by a well-designed and reliable installation / implementation method that is just as bullet proof as humans can make it.

The safety and reliability of the implementation process must be tested, tested, and re-tested … and then demonstrated to operations managers who cannot

afford disruption issues. When implementations are required by a date certain as a result of an executive decision by top management, one would think that all parts of operations would be equally receptive to implementation in their units, but such is not the case. Unless technical implementation is proven to be bullet proof, excuses to “delay implementations because of operational emergencies” will pop up like wildflowers in the spring.

Example: CEO and COO remarks at a Senior Executive Meeting:

CEO: Charlie here wants to bring up a point about implementing DOF technology solutions … Charlie.

COO: Thank you. We have had some good results from the last two DOF projects we completed. Both have turned out to save us time and money.

However, we had a devil of a time implementing the solutions. For example, in the last two cases, IT showed up with great technical solutions that worked, solutions that did eventually fit with the business processes we had selected for improvement.

But in both cases, the installation and initial technical implementations did not look like a planned approach at all. My guys and I felt like the technical guys were “feeling their way along” and learning by trial and error.

CEO: So, Charlie, what is your request?

COO: I just want our technical organizations to appreciate the need for implementations that look more professional and under control. Watching “trial and error learning” greatly diminishes my guys’ faith in the DOF technology solution.

Figure 4.3: Ingredients necessary for complete Technical Process Architecture

The reader might ask, “Does all this stuff have to get done to get Technical Process Architecture into play?” The short answer is “yes.” As the table below is meant to show, if one category of technical process architecture is missing, the results are unacceptable.

All or Nothing

Hopefully we have made the case for strong technical processes as critical success factors in gaining business value from DOF. Our discussion so far may be very different from both the points of view and daily work of the technology side of the business. So be it. Many technology shops approaching a DOF future have a long way to go to build technical processes that can rise to the occasion.

Chinese Water Torture Education for Executives

OK … even if that strategic foundation is important, what can I do about it? I am not exactly at what you might call the strategic level. If you are connected to DOF in any way, you can do a lot about it; it is called executive education, education that is patterned after Chinese water torture.

Every time you talk, present, discuss moving DOF forward, you talk about DOF Business Value Architecture. If you think that term will blank out your top management, then talk about “critical success factors for DOF” or “known preconditions” or “lessons learned” (or even “greasing the skids,” if you dare) … or whatever it takes.

See Additional Chapters

• Chapter Twenty: New Ideas for Digital Oilfield Success • Chapter Twenty Four: DOF Integrated Risk Management • Chapter Twenty Five: The Test for DOF BVA Fatal Flaws

Figure 4.4: Consequences of Missing Elements

CHAPTER FIVE

Vendor Architecture

The vendor’s “technologist’s dilemma” is whether to sell good technical stuff and hope the customer puts it to good use for business value, or to jump in (i.e., into the soft stuff) and help ensure the customer gets that value. If the vendor leaves good technical product by the door, and the customer cannot get the technology into play, the vendor faces an almost certain “no sale” when he shows up a year later to sell the next version of technology.

The Hard Stuff vs. the Soft Stuff

MANY DOF TECHNICAL vendors seem to describe the world they work in as made up of “the hard stuff” and “the soft stuff.” Hard stuff seems to mean to them concrete elements, numbers, equations, and codes – you know, real stuff that you can sink your teeth into. Soft stuff seems to mean all the people-related stuff: messy, fuzzy stuff like personality, motivations, and training – you know, like psychology.

Technology vendors specialize in the hard stuff and frequently want nothing to do with any soft stuff. But the reality of the DOF situation is that “getting the hard stuff right” is not enough to get business value for the customer. Somebody has to get “the soft stuff right” or the customer will have nothing more that unused technology that works great … technical success but business failure.

The Technologist’s Dilemma

The technologist’s dilemma is whether to sell good technical stuff and hope the customer puts it to good use for business value, or to jump in (i.e., into the soft stuff) and help ensure the customer gets that value. If the vendor leaves good technical product by the door, and the customer cannot get the technology into play, the vendor faces an almost certain “no sale” when he shows up a year later to sell the next version of technology. However, if the vendor has pitched in and helped the customer “take it all the way to the bank,” the vendor can expect more business over the long haul from a satisfied client.

• Sell and Hope? or • Stay and Play?

Unfortunately, most technical vendors seem to have made up their minds; they are going to continue to sell good technical stuff and hope the customer can put it to good use. For the few vendors who are willing to Stay and Play, who are willing to throw their lot in with their customers and help take the technology all the way to the bank, there will be great business opportunities with their customers; but first, the technical vendor will need to meet several critical challenges.

Challenge: Crossing Industry Thresholds

Despite a vendor’s level of digital expertise, an upstream industry threshold must be crossed before vendors can have “real conversations” with their operating customers. While the customer may spend some time talking to a vendor, there will be no real business conversation unless technical vendors have “boots on the ground” with the following technical qualifications:

• They know and have experience with the physics of the oil patch

• They know, have experience, and are be able to perform analytics and simulations on upstream assets, and

• They know and understand the customer’s comprehensive map of core processes

Few technical vendors seem to have understood this message since they continue to approach customers with marketing, sales, and services representatives who do not even come close to meeting industry threshold requirements for true conversation and partnership.

Challenge: Clarifying Client DOF Requirements

Imagine the lead technologist in a customer operating company making the statement below.

“My [internal technical] organization thoroughly understands the leverage points in our operations’ work processes where digital technology can add business value. We’ve worked both inside our shop and outside with our vendor community to nail down the technologies and tools that we’ll need to bring to operations to meet their specific business goals.

“Let me read a letter I just received from our primary DOF technical vendor.

‘Thank you for selecting our company to be your lead DOF technology provider. Your specific explanation of your needs and goals will allow us to meet your technical needs now and in the future.’”

Simple, right? Those are indeed the magic words for DOF maximization, but eliciting these words is easier said than done since many customer operating organizations continue to have trouble articulating their company’s specific technology needs. The customer’s failure to specify needed technologies is but one of many challenges a technical vendor must overcome to be of real service to an operating company.

Challenge: Mirroring Organization Structures

As shown in the diagram at the end of this chapter, the vendor’s arrangement of its architecture (or moving parts) should “mirror and mesh” with the business value architecture of its customer. While the obvious “touch point” between the technical vendor’s organization and its customer is “Vendor operations” to “Customer technical processes,” the vendor organization must be able to mirror the customer at the strategic and customer-operations level as well.

Challenge: Meshing “Vendor Operations” with “Customer Technical Processes”

• Customer Technical Processes: In a previous chapter, the Customer Technical Processes needed to maximize DOF business value were listed as below:

1. Business needs discernment that accurately comprehends the range of

operational transactions and decisions that could be made by the business

2. Technology architecture design that optimizes the company’s technical capability to all types of work processes needed by the business to meet its goals

3. Technology acquisition that both drives vendor innovation and secures needed technologies to architecture design

4. Systems readiness process in place that can produce apps and systems that meet Business Improvement Opportunity requirements

5. Proven and secure implementation process is in place that does not put operations at risk during technology implementation and test

Vendor Technical Processes: Vendor architecture must be aligned with and add to the customer architecture.

Figure 5.1: Vendor architecture elements

Vendor Operations Processes

For there to be an effective mirroring or meshing between customer and vendor, vendor architecture must directly (i.e., assist, inform, lead) each of the customer’s technical processes.

1. Vendor Business and Technical Needs Discernment that accurately comprehends the range of operational transactions and decisions that could be made by the business … and the level of understanding of those needs by the customer’s technical organization (i.e., the vendor’s technical customer). The Vendor must be able exceed the industry threshold to converse with the customer’s operational organization and “backstop” the customer’s technical organization to ensure there is good understanding and translation of Business Improvement Opportunities into technical requirements.

What’s the problem you say? The problem is that if the company’s IT function does not pick up the right meaning and does not discern the real needs of operations, the vendor may literally be given a “bum steer” by his IT customer. And you can believe that if there is a miss-read it will be labeled as the fault of the vendor.

In those situations where the customer technical departments prevent the vendor from talking to operations or from seeing work processes, the vendor will be flying blind – and the customer’s technical department will be purchasing “a pig in a poke.”

Example: Conversation between CIO, Director of Application Development, and a Vendor Director of Sales and Operations

CIO: Well, Peter, I’m glad you were able to go with us to see our Upstream VP. He doesn’t let us bring vendors around very often.

Vendor: I am glad I met with him. And I was surprised when he nodded to my request to meet with some of his direct reports.

MAD: I’ll see if I can arrange some visits for us. Of course, you won’t be able to see their flowcharts or work processes.

Vendor: What is that about?

CIO: I can answer that. The operations guys are sensitive about their processes, and they want us to translate their needs to vendors.

Vendor: That is a shame, because if we could all get together around work processes and business improvement opportunities, we could each hear things no one of us could have heard.

2. Vendor “Technology Architecture Design” to lead/assist customer to an architecture that optimizes the company’s technical capability to all types of work processes. Assistance in technology architecture Design is no longer an option but a requirement for DOF

vendors.

Example: Meeting between CIO and Manager of Application Development:

CIO: How is the system architecture project going?

MAD: It started well with all the of our team excited and ready to play. But we have cooled off considerably.

CIO: You guys run out of gas?

MAD: No, it’s more like we ran out of ideas. We agreed at the beginning that we would not come forward with our design until we had a consensus, and we can’t get there.

CIO: Why don’t you add a new player or two? Some fresh ideas might help. The vendor project manager on the DOF project might be able to suggest someone from his shop.

MAD: I considered that but didn’t think they had the expertise, and I was concerned they would be biased in their favor.

CIO: Don’t worry about the expertise. If they have what you need, keep the guys; if they don’t, give them back to the project manager. And don’t worry about the bias; they have too much at stake to show a bias.

3. Vendor Technology Preparation and/or Innovation of vendor offerings that accurately responds to the customer’s requests for technology functionality. It is critical for customer and vendor alike that the vendor’s capability for technical innovation be harnessed to the customer. While some existing vendor products may “fit” the customer’s need, the ultimate value of DOF must be driven by innovation to meet specific customer needs.

Example: Meeting between Vendor Product Manager, a Senior IT Manager, and a Senior Director from the upstream organization:

Vendor: Thanks for the opportunity to show you our new stuff. I have been fulltime on this product since I came out of the meeting with you guys last month.

IT Manager: Well, we are anxious to see if you understood what we were talking about in that meeting.

Operations: I thought we did a pretty good job of describing the business problem we are working on and where we think we need IT help.

Vendor: your description was very helpful and very specific. We have focused several man-months of innovation talent on a solution that will fit your problem.

Operations: OK, let’s see. The proof is in the pudding, right?

4. Vendor Alignment with the “Customer’s Systems Readiness Process” enabling the customer to produce apps and systems that meet Business Improvement Opportunity requirements. Vendors who can help the customer use their own internal readiness processes to get products ready are both highly valuable and in short supply.

Example: Conversation between Manager of Applications Development (MAD) and the Vendor Product Manager

MAD: I want to talk to you about our systems development process and yours. Two years ago I was charged with leading a project to firm up and document the system readiness methodology that we would use going forward.

Vendor: That must have been fun!

MAD: it was tedious at the start and taxing at the end, but, you know, I really enjoyed it. And the results of the project were really worthwhile. We finally have a methodology that everybody has signed off on and it works. The best thing is that we and operations trust the methodology.

Vendor: I had heard that your guys had a good methodology. As we get closer to the end of our system preparation, maybe we can sit down and compare notes.

MAD: That’s why I asked you to meet with me. You see, our reading of our contract with you says that you will use a systems development process that we approve.

Vendor: Yes, all our contracts usually have that kind of wording. What we actually do on the job, however, is to use the method our team used on our last engagement because our guys are very familiar with it.

MAD: I understand your answer but we are unwilling to do it that way. We need you to do one of two things:

a. Use our approved methodology. It has the functionality needed to cover this app b. Or, prepare a “point-to-point” reconciliation of your method to ours.

We will give your company time to think about it, but the way you are doing it today is not an option.

5. Vendor Alignment with and of the customer’s implementation process, a planned bullet-proof implementation that does not put operations at risk. Technical communities have for decades had the reputation of being highly focused on the attributes of their products while being “missing in action” during technical implementation. This can no longer be the case.

Example: Meeting between a Senior IT Manager, a Senior Operations Manager, and a three-person vendor team.

IT: Thanks for coming in everybody. Let me start with a little background for this meeting. Ben here is a senior operations manager who is handling the interface between operations and IT. Ben and I have worked together before and Ben thought we should all get together and talk about implementation.

Operations: That is right. I understand that the app you guys have been working on is ready to be loaded onto the operations servers.

Vendor Senior: Yes, we have completed our software tests to this point. Of course when we load the software we plan to consider that a test environment that will give us the data we need to make final modifications to the software.

Operations: Your comment is exactly what I was afraid I would hear … a disaster in the making. (Ops guy gets up and leaves the meeting room.)

Vendor Senior: What did I say that upset him so?

IT: We need to talk.

All or Nothing

The reader might ask, “Does all this stuff have to get done for the DOF Vendor to be able to fully the customer?” The short answer is “yes.” Fail to field one category of vendor , and the end result will be greatly disappointing from both a customer operational and vendor operations point of view.

Figure 5.2: Customer and vendor matching processes

The Technologist’s Dilemma Revisited

Innovative technical vendors are essential to the health and vitality of the DOF movement; but those vendors who can mirror their customers’ organizations and provider leadership to the customer to take technical DOF innovations all the way to the bank, will be prized as future partners of the more successful operating companies.

See Additional Chapters

• Chapter Fifteen: A to Z Services from DOF Vendors? Not Yet! • Chapter Twenty Two: The Sweet Spot for DOF Professionals, Participation and Ownership

CHAPTER SIX

Intelligent Interfaces for Effective BVA

The business side must be committed to mining the technological value of IT for their business. The business side must come through with ionate participation and leadership – from initial exploration of possibilities all the way to full implementation and utilization of DOF technologies.

AS WE STATED in an earlier chapter, unfortunately the three architectures (strategic, work process, and technical process) do not always work smoothly together. Effective interfaces are required between the architectures to provide smooth and harmonious operation. This chapter is all about explaining the needed interfaces and what can be done to improve them.

The Idea of an Interface

An interface is a mechanism that enables separate and sometimes incompatible elements to coordinate effectively. An interface brings two components together, connecting and meshing them. An interface facilitates communication and interaction. In this book, we use the idea of interface to describe how the three different kinds of BVA architecture will work together.

Before we describe the interfaces needed between BVA architecture elements, it might be useful to talk about interfaces we have all seen and perhaps worked in, focusing on the vital interface between the operations side of the business and the innovation provider in the business: IT and/or R&D.

The interfaces that follow were not intended to be one-dimensional concepts, but rather concrete connections between innovation and business functions. The designations that follow refer to people and processes that connect technology and operations to meet business requirements. During our time of working to improve technology insertions, we have seen five types of interfaces in play.

1. “By-the-book business analyst.” Generically, a “bright young guy in a suit and tie,” working on the innovation side of the organization, is assigned to interview various individuals on the business side. Using a checklist to ask questions and record the answers, his mission is to provide a completed template with the purpose being to document and develop an understanding of what the business needs from technology. Theoretically, if this approach works, an applications sourcing expert can interact with both the analyst and template data to select and develop or source appropriate technology and configure it to meet the needs of the business.

2. “The Business-Experienced Analyst.” The idea is that “he comes from the business side so he knows what business wants.” In all aspects, nobody is looking for him to push the envelope in any way, shape, or form. From a positive perspective, he is bringing a wealth of business experience to the table, but on the negative side, he also drags along decades of biases (both conscious and unconscious). Frequently not an effective or disciplined template developer, he may make decisions about the needs of the business “by feel” rather than conduct a data-based analysis of needs.

3. “The Businessman CIO.” Realistically, this is perhaps the most reactionary one of the five. For example, top management comes to the conclusion that communicating with the company’s IT personnel is very difficult if not virtually impossible. For that reason, they are of the opinion that IT is “not under control” and essentially needs to be commandeered. Management’s mission becomes “We’ll fix them (IT)” by installing someone from the business side as the new CIO or IT head.

Before anyone quickly applauds; however, be advised that this approach is very tough to execute for fairly obvious reasons. Not surprisingly, the level of communication is indeed improved between the CIO and the business side, because the latter is where the new CIO came from. Unfortunately, the new chief knows no more about IT’s nuances than a genuine IT-experienced CIO knows about business-side details.

4. “The IT expert inside the business.” Obvious logic here: why not place one or more experienced IT/R&D people” inside the business, both physically and organizationally? Once again, if not prompting a “that could work” reaction, it still might strike some as not necessarily a bad idea, but, hold that thought. Taking a player from the innovation side and inserting him into the business side – attending meetings and picking up daily information and observations – only means having someone hearing the business through IT ears and processing it accordingly. Regardless of good intentions, without figuratively having business in his bones, no real net gain occurs because the IT expert is typically “tuned out” at business meetings.

5. “Operations-Led or the Intelligent Interface” (The operations expert pushing into IT/innovation … what we call the Intelligent Interface).” The actor here is the business side that is committed to exploiting technology (in this case, DOF). The interface is made up of operations/business experts who are not only ionate about exploiting DOF, but are formally commissioned by the business side to penetrate the innovation side and make business improvements happen.

Consider the NASA environment to see how an intelligent interface, in the form of an astronaut, examines the flight hardware that will take him into space. These future fliers interact directly with technology providers, which can sometimes be ugly. Usually the ugliest part is when a technology innovator or vendor responds to an astronaut’s operational question with jargon or alphabet soup acronyms.

It takes but a few seconds for the intelligent interface (the astronaut) to clarify who the customer is, who defines the needs, and who has ultimate control of the dollars – then to insist that the conversation continue without the obfuscation. Most likely, the DOF equivalent is an experienced business person fully committed to putting new digital technology to work to pay off for the business. For this, there is no substitute.

Companies invest considerable human energy and money into the business side and into the technology side as well. As a result, not only does this generate a solid business foundation, it also draws and retains excellence in R&D and technical experts in IT.

However, what is not happening yet in the DOF world is an investment in the interface between the two because the seemingly unsolvable problem still exists: How to get people to communicate from the operational functions to the innovation function and vice versa. For example, it is not uncommon for operations managers and DOF R&D/IT to work at cross-purposes with each other. Too often, R&D is expected to continually develop innovations and then make them available to the operations managers who take the new technology and figure out what to do with it, if anything.

What is missing in this faulty scenario is that a part of operations must be proactive about getting improvements and receptive to innovation and, conversely, a part of the innovation side must be implementation-oriented. What companies need to do, and what continues to be missing, is to invest in the quality of that intelligent interface.

The Intelligent Interfaces in DOF Business Value Architecture

Before we use the term Intelligent Interface in Business Value Architecture, we should stop and define it properly. An intelligent interface is a connection of people and processes that can:

• Translate from one component to another. The Intelligent Interface must be able to on “meaning,” not just words.

• Innovate, test and evaluate the subjects of conversation. The Intelligent Interface can lead the needed dialog between one component and another to innovate, test ideas and concepts, and evaluate results and conclusions.

• Implement ideas and decisions made in one component into the working of the other component.

Business Value Architecture requires three intelligent interfaces as shown in Figure 6.1 below:

• Executive Interface (Executive <> Operations): the vital connection between corporate strategy and the operational units that will enact the strategy

• Mission Interface (Operations <> Technical): the vital connections between Business Improvement Opportunities (BIOs) and the technology that will enable them

• Resources Interface (Technical <> Executive): the vital connections

between the corporate strategy and the technical resources needed to fulfill the strategy

Figure 6.1: Intelligent Interfaces in DOF Business Value Architecture

The Executive Interface

The Executive Interface makes the vital connection between corporate strategy and the operational units that will enact the strategy. This interface does not describe the development of corporate strategy, but the Operations Units’ way of translating corporate strategy into the means that will provide the desired business results from the strategy.

The functions that must be performed in the Executive Interface are shown in the figure below.

Figure 6.2: The Executive Interface

Imagine that a corporation is developing or finalizing their competitive strategy for the future. Imagine that Operations managers have the opportunity to digest the strategy and respond to it in the form of “Here’s what we would do operationally to align with the strategy.” After:

• considerable discussion between operations and corporate executives, • including thorough analysis of operation’s proposed actions, • enough “if-then” exercises to understand the risks and sensitivities in the operations proposal, • executive management provides their guidance and funding to go forward with operation’s plan as modified in discussion.

The Premise of the Executive Interface: Given the corporate strategy, the business structure and work processes we need to put in place are the following: (the operations plan for the structure and processes needed to enable the corporate strategy)

As seen in the definition above, the Executive Interface is the key function that puts the organization to work producing products and services at a profit, thereby satisfying all stakeholders. In practice, many companies do not have a healthy, energetic Executive Interface, with too little real give-and-take conversation and too much “I await your orders, Sir.” The later situation is bound to lead to missunderstandings, missed meanings, and miss-alignment.

The Mission Interface

The most critical and yet most misunderstood intelligent interface is the Mission Interface. This interface is the vital connection between Business Improvement Opportunities (BIOs) and the DOF technology that will enable them.

The functions that must be performed in the Mission Interface are shown in the figure below.

Figure 6.3: The Mission Interface

Imagine that the operations-side of an upstream unit is working through its annual analysis of work processes and identifying those processes or segments of processes that seem to have the potential for improvement either through process re-design or by DOF enablement. Mission Interface personnel lead:

• considerable discussion between operations and leaders from the technology side

• including thorough analysis of operation’s proposed needs, • enough “if-then” or “means-ends” exercises to understand the risks and sensitivities in operations needs/requests, • technology management provides their proposed solutions to meet needs along with investment requirements, • where upon operations provides their approval, guidance and funding to go forward with the technology plan as modified in discussion.

The premise of the Mission Interface: Given the way we must structure operations to enact the corporate strategy, the business improvements we need to enable with technology are as follows: (Operations plan with business improvement opportunities and required technical )

Recognizing that technology insertions are so frequently unsuccessful is painful enough to a company’s management. Yet IT implementations per se are even more painful than a root canal in failing to meet management expectations an

excruciating 80 percent of the time. While companies have figured out how to implement new core technologies (e.g., pumps, valves, etc.), a lesson learned the hard way is that an intelligent interface is vitally needed when trying to connect a digital technology innovation with the company’s business side.

However, a major change is necessary from what is being done today in many parts of the industry, using a mechanical template-driven interface that only “communicates” between R&D/IT and the business. Instead, it is the business side that must drive an intelligent interface.

The business side must be committed to mining the technological value of IT for their business. Still, many in business management ranks carry negative baggage from previous failed insertions at a time when they should actually be mobilizing their “best and brightest” and energizing them to extract the most value for the business from each piece of new DOF technology.

The Mission Interface must operate with a defined set of attributes. If not, once again the necessary integration between operations and technical innovation either will not happen or will be exceptionally bumpy and ultimately unsatisfactory. The five necessary attributes are as follows:

1. A Mission Interface must be a formally-chartered function, not a set of informal practices that may or may not have worked in the past. (Since there is no formal connection between operations and the technology function, a formal charter is needed for the Mission Interface)

2. A Mission Interface must have leadership backing and assigned responsibility to do this interface, backed both by operations and the R&D or IT side.

3. The Mission Interface must have an organizational “mission focus,” not a “technology focus.”

4. The Interface should have the following components: translation of mission opportunities; innovation, tests, and evaluation; and implementation/integration into day-to-day operations.

5. The Mission Interface must be staffed by personnel who have the right stuff.

Essentially, the DOF Intelligent Interface is powered by the disciplines and principles of systems and change engineering. Staffed by highly qualified operations personnel, these people should have ten years in operations, five years with bottom-line responsibility and high credibility with their fellow operations personnel.

Additionally, Mission Interface staff should already be marked and designated as “up and comers” in the organization and known as operations stars, or proactive leaders who are “consciously competent.” The latter refers to being able to articulate what operations needs, wants and is doing. They are anchored in “what we do in operations and the way we do it,” not in the theoretical way it “ought to be done.” More viscerally, these individuals must have operations “in their bones.” They must have a general understanding of the R&D/IT environment rather than knowing the “nuts & bolts” of the DOF technology, and they must keep the conversations focused on the mission first.

The Resources Interface

The least-visible and usually least-active intelligent interface is the Resources

Interface. This interface is the vital connections between the corporate strategy and the technical resources needed to fulfill the strategy. It is the necessary connection between the technology organization leadership and executive management.

The functions that must be performed in the Resources Interface are shown in the figure below.

Figure 6.4: The Resources Interface

Imagine that a corporation is finalizing their competitive strategy for the future. Imagine that Technical managers in IT and in R&D have the opportunity to digest both (1) the corporate strategy and (2) the operations premise (“Here’s what we in operations must do to enable the corporate strategy”), a resource requirements plan can be discussed with Executive management. After

• considerable discussion between IT/R&D and corporate executives,

• including thorough analysis of IT/R&D needed capabilities and proposed actions,

• enough “if-then” and “means-ends” exercises to understand the capabilities, risks and sensitivities in the technology-side proposal,

• executive management provides their guidance and funding to go forward with the resource and capability plan as modified in the Interface discussion.

The premise of the Resources Interface: Given the functionalities requested/needed by operations and the overall company strategy, the resources and capabilities we need on the technical side are as follows: (technology resource plan with investment required).

And in Conclusion …

Leaders in the upstream business of tomorrow are those who will be able to harness technologies, including DOF, for their operations. And who are the leaders? They are the ones who actively and aggressively find technologies that enhance operations in the first place, and then they get these technologies integrated. They will lead technological innovation and insertion, not have “technology done to them.”

See Additional Chapters

• Chapter Twenty One: The Leadership Last Stand • Chapter Twenty-Three: Big Ideas for DOF Implementation

CHAPTER SEVEN

The Digital Oilfield Culture

Steps required for changing to a culture that will the Digital Oilfield are reward-based. In other words, the new DOF culture that is being created must be clearly communicated to workers while explaining that successful implementation will be rewarded in various ways, ranging from bonuses to promotions.

Introduction

WITHIN ANY ORGANIZATION, a desired technology culture does not magically appear, seamlessly integrating people with technology. Realistically, the organizational wheel must first be reshaped to make it roll more easily. Why? Every organization’s culture is made up of several subcultures based on the past and ongoing assumptions. One involves how the people work with and think about information technology (IT). The working relationship with IT dates back many years, or even decades, for most companies. Many assumptions about IT may have been created and reflexively accepted, without ever being challenged as wrong.

The cumulative effect of this unchallenged IT thinking might have been generally benign except for its recent collision with DOF. What happened is that managers have tended to view DOF through the same lens at they view IT – which is somewhat akin to watching a movie with an exciting action hero who unexpectedly meets an unhappy ending. But, the upstream industry has the opportunity of a lifetime, because it can write a much more upbeat ending to real-life DOF at companies throughout the world.

Disconnect in order to connect

This unlimited opportunity begins with an idea that could leave some people scratching their heads but actually makes sense once it’s put into play. Just as a farmer must prepare his field for planting, DOF advocates must diligently prepare the organization’s “IT and operational culture” before DOF’s promise can be realized.

that risks are always associated with introducing new technology within an organization, as is any new way of doing business. Typically these risks are absorbed at the top level of management, because they usually issue the go-ahead on new technology after the case is made at lower levels. However, lower level managers, including the operations manager, are not equipped to absorb R&D risks. So, placing R&D risks on operations managers will accomplish little more than killing DOF innovation on the launching pad.

If that’s the case, what’s the next move? The first step in creating a viable DOF culture is to stage a “cultural disconnect” at senior management levels from the current embedded IT culture.

• First, bring “incorrect” IT assumptions to the surface by writing them down in explicit language in order to challenge each and explain how the DOF culture will work differently. Examples of incorrect assumptions are as follows: • The IT function is a separate business that works at arms-length with operations • The IT unit is in the “IT business,” not the upstream business.

• Then create the new DOF culture from a blank sheet of paper aided by solid business rules: • IT will supply a key means for advancing productivity by enabling work processes • Business expectations for IT projects will consistently be met • IT projects will be on-target, on-time and on-budget • IT implementations will be manageable and doable • Communication between business and IT will be complete, continuous and understood • Operations, working with IT, will ensure that the operations-side workers are ready to use the DOF technology at go-live

Right direction is critical

Properly creating a new DOF culture is critical not just to get the puzzle pieces in the right places. It is also the template for addressing problems and guiding workers in performing their jobs within the new organizational culture. Yet, many organizational cultures are not necessarily pointed in the right direction in the first place. DOF is typically seen by most workers as if it were a television commercial for technology: “Deliver new productivity to your company and solve all your problems with our new DOF software. No special work or skills required.”

The truth is that creating the DOF culture will require an engineering mindset, especially for implementation and business readiness. As a result, management typically looks at the DOF they want to introduce at any given time and invariably concludes the technology will be fully and enthusiastically utilized – after some good psychology-based communication of course, beginning at 8

a.m. the next day. Imagine the surprise at every company that thinks this way when they discover this mindset is simply inaccurate. In brief, a company’s nonDOF culture may work quite well for all manner of tasks and business objectives but may, at best, be an awkward fit for the new DOF working environment.

The solution, as for most business problems, is to shift into the proactive mode and proceed forcefully in order to develop and shape the company’s new DOF culture, one which is a glove-fit for its people and processes. This solution – for the company’s DOF future – begins and carries through on a positive, yet challenging, note.

Take specific actions for successful DOF culture change. Now comes what most people look for when presented with a challenge, in this case, creating the new DOF culture. Yes, there is a game plan to achieve the objective, so that guesswork does not have to be brought into play.

Steps required for changing to a DOF culture are, most importantly, rewardbased. In other words, the new DOF culture that is being created must be clearly communicated to workers while explaining that successful implementation will be rewarded in various ways, ranging from bonuses to promotions.

With that in mind, specific actions required for DOF culture change are listed below:

1. Define the desired DOF culture: Identify the culture or new work environment that everyone will be expected to work towards, so that the organization can optimally leverage all the attributes that DOF offers. This must be communicated at all three levels (senior management, middle management and technical professionals), not just on an arbitrary or spot basis.

2. Map the route to the DOF culture: Help ensure that the transition to a new DOF culture is guided by a systems engineering approach. Pinpoint and communicate the specific changes that must be made in how the company presently functions and map the route to implementation of the new DOF culture.

3. Clarify expectations: Inform employees that the organization’s transition to a DOF culture is project-based (again removing any broad brush thinking), which will hold managers able for how effectively the change is made.

4. Enable self-diagnosis: Establish the opportunities for employees to best comprehend how they are aligned within the new DOF culture, through means such as benchmarking and essentially having them diagnose their niche within the organization and then adjust to fit the desired culture.

Figure 7.1: Steps for culture change

5. Sweeten culture compliance: Inject some “extras” into the reward system to let everyone know that, just as real consequences are in place to penalize failure, there are enhanced sweeteners for DOF culture implementation success.

Avoid the word “culture:” Although this analysis has discussed DOF in of “culture,” it’s best to present the change to workers at the organization by using words such as “DOF working environment” and “DOF workplace.” Often “culture” has a negative effect on employees.

Conclusion

Overall, the objective is to have DOF become more than simply the introduction of new technology into an upstream company. When done properly, the goal is to use the power of digital technology to transform the way the company does business into one that takes the business to a new level of excellence, accomplishment, and profitability.

See Additional Chapters

• Chapter Nine: DOF Collaboration and Incentives • Chapter Ten: Portfolio Management for Digital Energy Projects • Chapter Twenty One: The Leadership Last Stand

CHAPTER EIGHT

Implementation of Business Value Architecture to Enable the Digital Oilfield

Business value architecture is the arrangement of some parts of an upstream company so that Digital Oilfield projects can be implemented both more effectively and more efficiently. As shown in earlier chapters, there are fifteen rearrangements or re-configurations that would need to be made in a typical upstream company to “grease the skids” for DOF.

THIS CHAPTER IS a brief primer on how DOF business value architecture might be implemented. That is, how would incentive systems be reconfigured to incentivize the deployment of DOF, how would we get flowcharts in place that show business process architecture, or how do we put a technology acquisition process in place that drives vendors toward the innovations needed to meet the company’s needs. Implementing BVA is necessary but far from being a trivial matter.

The Needed Perspective for Implementing Business Value Architecture

A common and sometimes useful way of thinking about introducing a new way of thinking and acting in an organization is shown in Figure 8.1. While Figure 8.1 clearly communicates that implementing the DOF business value architecture is the goal, the diagram itself tends to focus thinking on the definition and explanation of DOF as a means of improving performance. Implementers who have the view below tend to construct their implementation road map almost exclusively of communication and intensive training on DOF concepts and techniques … which turn out to be “necessary but not sufficient” steps for the full integration of the Digital Oilfield in a company.

Figure 8.1: Focusing Attention on the Contents of BVA

The central idea in organizational change is to take an organization that is operating in one way and to transition that organization to a new way of operating. It really is as simple as that … and as complex too, because organizations are systems that have many “moving parts” that will be involved in the transition and, of course, to make things really interesting, the moving parts are interdependent: change one part and the others requiring changing too.

Figure 8.2: Focusing Attention on the Needed Organizational Change

Overview of the Three Phases of Implementation of Business Value Architecture

Unfortunately, one does not wake up one morning to find the business value architecture of the Digital Oilfield in place and fully operational. If that were only the case, life would be much easier. Instead what advocates of the Digital Oilfield find is that they have a long journey ahead to make DOF a part of everyday business in their company.

Figure 8.3: The Three Phases of Implementation of DOF BVA

Moving from doing business without use of DOF technology to operating daily taking advantage of DOF technology is a real trip. Fortunately there is at least a high level, three-phase Roap. (See Figures 8.3 and 8.4: The Three Phases of Implementation and more of the detailed steps of the phases.)

• Phase One: Awareness and Education • Understand the digital oilfield movement • Develop rationale /case for change to DOF • Select framework for transitioning to DOF • Develop digital oilfield champions • Conduct informal digital oilfield assessment • Conduct digital oilfield awareness/education • Develop business case for Phase II: Trial by conducting pilot projects

This phase is simple enough. Some folks in upstream may never have heard of the Digital Oilfield. Phase one takes on the task of communication, public relations, as well as some training to make sure over time that organization have a basic understanding of what it is, how it can be used, how it can be implemented and last but not least, how operating the company with the benefits of DOF can make things better, not only for the company but for the work force as well.

Two important ideas stand out. First, who becomes aware of the nature and

benefits of DOF matters a lot, as you can imagine. So while awareness and education is an organization-wide effort, the organization’s DOF advocates must pay special attention to the executive team, those folks who may be most difficult to reach and, frequently, the most “hard of learning.”

The last step in Phase One is critical. Decision makers make an assessment of DOF’s value to the company and, if seen as potentially valuable, complete what amounts to a business plan for Phase Two: Trial by conducting pilot projects. The business plan must be complete with projections of the economics of running, say, a half-dozen pilot projects, each focused on using DOF technology in the improvement of work processes. Why not just start a few pilots, you say? Well you could but the idea is to make the transition from Phase One to Phase Two a formal business action with top management being there to “cut the ribbon” on Phase Two and to show their excitement over the pilot projects!

• Phase Two: Trial by Conducting Pilot Projects • Formally assess digital oilfield needs • Pinpoint strategic DOF targets • Develop pilot projects to “learn and do” • Conduct just-in-time DOF training of pilot teams • Make sure pilot results are put into action • Launch other digital oilfield projects … based on need and visibility • Develop business case for Phase III: Organization-wide Integration

The trial phase has two main objectives: first is to (1) learn from each pilot project completed and to (2) gain business value from each completed project. This phase sounds easy enough until DOF advocates or appointed DOF change

leaders begin to target specific work processes for improvement using aspects of DOF. The obstacle that is usually the toughest is to convince managers to take the time from an already busy business life to participate in a pilot project while they continue doing their day jobs.

Completing a pilot project (that may take several months and cost in the millions) is tough enough, but usually manageable. The tough part, the part most difficult to get pilot team involved in is the “learning” that is supposed to be a prime reason for doing the pilot. Without clear learning objectives set at the beginning of the pilot, without having learning tasks built into the project plan, and without disciplined supervision by the project manager, the learning part of the project will take a very-back seat to completing the technical and work process parts of the project. What is the team supposed to learn during the pilot? The team is supposed to be learning just about everything … with special attention to the following:

• Learning how to do the planning for the pilot to ensure that the pilot project finishes with the DOF technology ready to be used in an improved work process.

• Learning how to do the planning to prepare the operations workforce to use that technology to make money for the company.

• Learning how long it takes to get the project done, which project steps took the most time, where in the project were the delays and the surprises.

• Learning to assess how well the software worked. How was it to manage the vendors used on the pilot? How helpful were they and in what parts of the project?

• Learning how it was to manage a project team whose still had a day job (if they were part-time team ) or hopefully had a day job waiting for them (if they were full-time team ).

Again, a critical last step in Phase Two is to prepare a business plan for Phase Three of the DOF implementation. At least DOF advocates will know more than they did when they completed the first business plan for Phase Two … and their economic projections should be sharper. This business plan, done at the end of the phase, is really the business plan for the enterprise initiative aimed at gaining wide-spread use and value from DOF.

Top management must be integral to completing and buying off on this Phase Three business plan. If top management is not in the game, it is probably best to continue gaining some business value from pilot projects rather than to start the intense effort of Phase Three that will last more than a year and impact just about every employee (and customer).

• Phase Three: Wide-spread Integration of BVA in the Organization • Develop / communicate a detailed DOF vision • Develop implementation plans / timeline /measures / goals • Incorporate DOF measures / objectives into goals and rewards • Modify work processes for DOF effectiveness • Acquire, formalize, integrate DOF tools • Measure digital oilfield results • Identify and maintain a ive environment for the digital oilfield

Implementing all the parts of the DOF Business Value Architecture is both a time-consuming and challenging endeavor. When looked at together, the fifteen moving parts of the architecture vary from “relatively easy to do” … putting DOF goals down on paper … to “difficult to do” … developing a reliable system for identifying the most valuable business improvement opportunities in the work process architecture of the operations side of the business.

A valid formula or framework will need to be used to identify all the moving parts that need to change and then to change them in an organized and disciplined way. The good news is that many of the moving parts can be altered in parallel and with the right level of leadership, resources, and discipline. Despite some gains in business value from the pilot projects of Phase Two, the real pay-off comes when the full architecture is in place … and kept in place by committed leadership.

Difficulty of the three Phases

Phases One and Two are busy and work-intensive, but compared to Phase Three, they are a cake walk. The degree of difficulty for Phase Three jumps at least tenfold, and the mechanisms or road maps to complete Phase Three are few and far between.²

While improved business results from Phase Two are valuable, reaching the real goal of Phase Two requires the development of a convincing business proposition and plan for Phase Three. How do you get a Phase Three plan accepted at the executive level? The answer is available in three simple words: present, present, present. Don’t worry, conducting successful DOF pilot projects between presentations will be additive to your next presentation. The series of presentations should eventually move executives from “Oh, it’s you guys again!” to “Tell us more,” to “It’s time to put the DOF proposal into our portfolio management queue, don’t you agree?”

Despite the best of intentions, most organizations that embark on a DOF journey wind up “stuck in Phase Two.” Being stuck there is not the result organizations want, but Phase Two, especially a continuing Phase Two, can have real value for the organization as more and more pilot projects are completed in different part of the organization. Each pilot, if successfully completed, could make some things better, and a series of pilots can cover a lot of ground. However, covering a lot of ground is a far cry from moving through Phase Two to organization-wide use of digital oilfield technology.

Figure 8.4: The Three Phases of Implementation of BVA

ing Chapters with More Details

CHAPTER NINE

Collaboration and Incentives for DOF Implementation

While possibilities are boundless in the exciting new Digital Oilfield (DOF) world, not every problem or challenge can be solved simply through a new technology insertion. In fact, getting new Digital Oilfield technology in play is more of an organizational collaboration issue than it is a technical one. All parties must align to make a successful implementation of new Digital Oilfield technology happen … and they must have incentive to do so.

Introduction

NUMEROUS NEW TECHNOLOGY insertions show that upstream company management can experience concrete results in better utilizing manpower and money in the best interests of the overall organization and its shareholders if they can achieve collaboration and alignment between their business and R&D/IT sides.

Managers are drawn to goals that are backed by incentives. “Backed goals,” therefore, provide direction for an organization. The lynch pin of DOF BVA Strategic Architecture is a management compensation structure that incents business results from DOF. Collaboration, on the other hand, has proven that smart people working together and combining their thinking can improve business results. Collaboration around cross-functional processes or initiatives is exactly what is needed for implementation of the Digital Oilfield, but collaboration only comes after knowledge that it is a backed goal.

The case for backed goals and collaboration has been made. What is the problem? Goals are backed but they are not aligned. In fact, in many cases they are in conflict. The problem is that collaboration is just not going to happen unless backed goals are aligned using appropriate performance criteria.

Aligning Performance Criteria

Most companies are still learning and optimizing their technical and management methods for implementing digital technology. Having swung back and forth between centralization and decentralization over the years, some upstream companies are seeing today’s advantages of pointedly leveraging centralization in the technological arena while benefiting from decentralization in operations management. Taking advantage of both requires two ingredients: a senior manager who is willing to lead the three-party collaboration and a set of performance criteria that make collaboration possible.

Some companies have learned the hard way that too small a set of performance criteria for a senior team can be an obstacle to collaboration. For example, if the three senior managers have only the interests shown below:

Senior Management • Financial Return

Operations • Production

R&D / IT • Innovation

… collaboration is not likely to happen. In fact, the more likely outcome is a “standoff.” On the other hand, if the three parties have the expanded set of performance criteria shown below, the chances of alignment will be much higher, and the chances of getting business improvements enabled by DOF software into play go up as well.

Senior Management • Strategic Imperatives • Financial Return

Operations • Production • Continuity

R&D / IT • Innovation • Risk Management

Imagine a collaboration scenario that contains the six criteria above. Senior management is of course focused on returns, but also has a strategic issue to face: the need to replace an aging workforce with the selective use of

automation. The R&D/IT manager is charged with developing innovations that can positively impact production and help compensate for the manpower drain, but R&D must also provide professional, effective, and efficient implementation to prevent the operations manager’s nightmare of disrupted production. The operations manager must focus on production but must also consider the need to integrate innovation in his operation to meet long term strategic objectives. Now with six performance criteria, in play, the chances of successful alignment go up dramatically.

The Operations Manager

A key part of pulling together a collaborative effort involves the operations manager. New technology introduction hinges, in the initial stages, on the operations manager “buying” a very tangible reality i.e., that the new technology will enable his work processes to deliver business results. The operations manager’s importance in the new technology scenario is, of course, most significant when management of high stakes technology is in a particular manager’s domain.

The R&D/IT Manager

As this new partnership unfolds, the driving force involves R&D not only providing the DOF innovation but actually helping the operations manager manage the risk of implementation and use of the DOF application. That can be accomplished through the proven and trusted “business readiness approach,” which is based on seven key points that address risks from the technical, organizational, and business points of view:

1. Recognize that all projects create changes and, therefore, risks

2. Analyze the causes of risks in order to be able to respond correctly 3. Take the appropriate steps to mitigate risks 4. Realize that resistance to change creates risk to the project’s success 5. Create a working committee and name a strong champion to work with the organization 6. the rules for communication: communicate, communicate, communicate 7. Get as good at managing organizational change as you are at managing a project’s technical elements.

Senior Management

Before anyone at the company says new software should just be bought from vendors and dropped on s without warning (“Because that’s how we’ve always done it”), some helpful “lessons learned” by other upstream company management. These included going beyond the R&D conversation that must take place with the operations managers, to bringing in senior management. By virtue of their authoritative position within the corporate hierarchy, the latter is the key entity that can exert real force necessary to move from the status quo to the new DOF environment.

In other words, senior management can encourage operations managers to begin adopting R&D’s new DOF technology by outlining the financial and strategic pluses (with these points being backed by senior management’s clout – that these are not suggestions.) Another conversation that must take place is with those inside the company who will be impacted by new technology implementation. Like a pebble in a pond, impacts may be virtually anywhere.

Another hurdle which can be overcome with proper planning and execution centers on short-term and long-term thinking. On the one hand, senior management must determine how much flexibility to give the operations manager versus how much standardization they will require in technology across parts of the business. On the other hand, R&D must be tasked with shedding the technical talk and articulating the business case for the new DOF software. In other words, they must effectively explain how this new tool will help the operations manager produce more business results. At the same time, R&D must appreciate the risks they are imposing on the operations manager and become as proficient at risk-minimizing implementation as they are at innovation.

Collaboration Makes Success Possible

Companies throughout the upstream industry continue discovering the technical and financial benefits that can be delivered by the Digital Oilfield. Yet many are still negotiating their way through minefields in getting the most productivity for their investment, until they discover the other half of DOF, which is successful implementation, and that takes collaboration.

If ever “Life is a learning experience” applied anywhere, introducing new DOF into a company is it. When new software looks right for any upstream company, swing into action by getting a collaborative effort among R&D, operations managers, and senior management. Then bring impacted parts of the organization into the discussion. Deal openly with change resistance, risk and preparing the organization for readiness — to make each new DOF technology insertion the best it can be for the company and its shareholders.

CHAPTER TEN

Portfolio Management for Digital Oilfield Projects

Portfolio management is critical to the Strategic Architecture of BVA. Portfolio management is the tool that enables senior management to see business improvement opportunities enabled by DOF on a level playing field with other company potential investments.

NOT ONLY IS the potential of the Digital Oilfield huge, it’s coming of age and maturing. However many management processes needed for realizing DOF’s potential are not as mature as the technologies. As a result, companies should refocus on maturing their key DOF related processes. As DOF gets increasingly “hotter,” and IT and R&D shops virtually overflow with new project possibilities, saying “No” or “Not now” to the business becomes more difficult. The solution is portfolio management as a mature business concept.

The Digital Oilfield movement is exploding with promise, but mature business processes like portfolio management are needed to leverage the huge opportunities. Otherwise, companies are left with mushy projects that actually decrease business results and limit careers. Therefore, companies must invest now in management processes for getting good business results with minimum employee exposure.

Portfolio management critical success factors

While Project Management is a known success factor, other success factors must

be present internally before DOF projects can be initiated and completed with the expected business results: value delivered on-time and on-budget. Let’s examine each of the phases and factors.

1. DOF Vision and Business Strategy: A upstream company needs a vision and a ing business strategy that acknowledges and commits to the importance of DOF innovation and provides a context for DOF innovation planning. Without such a vision, innovation advocates will not have the credibility they need to get good DOF technology into play.

2. DOF Technology Strategy: The company needs a technology strategy which s the business strategy and vision and provides a framework for prioritizing and selecting DOF innovation projects. Although it’s common for companies to have an IT strategy, they frequently do not have an over-arching vision for what overall technology can do for the business.

3. Business Improvement Opportunities: The company needs a methodology for collecting and screening business improvement ideas to harvest the best prospects for future development. That includes having a specific methodology for viewing the data, looking both at new ideas and the potential s. Not only should there be a methodology for identifying the technology for development, but the alternatives as well. Then, in the context of the business vision, the company must delineate operational advantages for each business improvement idea enabled with DOF.

4. Portfolio Management Process: The company must have a methodology for ranking/prioritizing DOF innovation projects. The purpose is

a. to provide a balance across the cost, risks and rewards spectrum and

b. to incorporate consideration of resource availability (e.g., budget, personnel, facilities) for development and implementation.

In this context, business s are the “customers” and they need to help them understand what it is reasonable to want or expect from new technology or what it is possible to get.

“Commitment Required”

Business “commitment to implement” a Digital Oilfield application, as evidenced by a written implementation plan, is an absolute threshold requirement for commencing a DOF project.

5. Commitment to Implement: The company needs project selection criteria for innovation that ensure one of two situations:

a. Business customers (i.e., s) are committed and ready to implement each successful DOF innovation project. Regardless of a technology’s potential, it cannot succeed without a willing to put forth a clear implementation plan. b. The business potential for rapid acceptance of a new technology by operations managers is substantial.

In of time, people and money, what will be required? The “commitment to implement” must be a critical determinant of whether or not any DOF project commences.

6. Executive in Charge: For each DOF innovation project, the company must have formally identified and charged a sponsor – or business executive in charge (EIC) – who sets comprehensive objectives for the project, explaining the project’s business rationale and clearly establishing both measures of success, and sensible constraints and boundary conditions. The EIC should be on the asset side, representing the one who owns the incentive to implement the DOF innovation.

Portfolio Management Phases

• Development Phase

For openers, the company should vest ability for each DOF innovation project in a project manager. This manager will lead a multi-functional team, establish plans, track progress, costs and schedule and keep management in each business unit informed of project status through successful implementation. That means all the way through technical implementation and continuing until the new technology is in day-to-day operation in the asset – not “stopping early.”

Two, the company should utilize multi-functional teams (project management, operations, IT development, IT maintenance, et al) for managing and tracking DOF innovation projects to ensure that all stakeholders provide input, participate in reviews and understand/accept decisions made. In particular, s and developers must tly understand such factors as:

• detailed business targets, • improved work processes, • basic functionality and benefits of technology,

• interface requirements, • hardware and operating system compatibility, and • interfaces with other programs.

But, since there are likely to be multiple locations and because having numerous s on the team is impractical, one person with a good interpersonal network and high credibility in the community should represent interests in general, not just his/her own personal perspective.

Three, the company should utilize a “stage and gate” process for managing and tracking innovation projects. From a project management point of view:

• is the project on budget and on schedule, and • is the progress to date sufficient to warrant moving on to the next stage of development?

From the business perspective:

• is the original innovation still pertinent, or • have the s’ needs and priorities shifted and the intended value vanished?

Thus, does the DOF project still make sense and is everyone ready to move on? This process on the one hand reduces revisions and recycles and ensures appropriate progress. On the other hand, it expeditiously kills projects that no longer deserve business .

Effective gatekeepers are integral to the success of stage and gate processes. There should be at least two types of gatekeepers: technical and commercial. They must establish clear expectations for issues to be judged during the gate reviews (e.g., budget, schedule, technical viability, commercial viability, commitment to implement, readiness, forward plan). And the gatekeepers must be held able for making good decisions.

• Implementation Stage

The implementation stage includes six aspects.

1. The company’s top management should take two specific actions. They should set clear usage expectations and state “out loud” several times during project implementation that all affected managers and employees are expected to and utilize the DOF innovation. It is not necessary that all potential s adopt the new DOF innovation; however, it is necessary that sufficient s “sign up” to be consistent with the original project justification.

2. An ongoing problem with digital innovations is that development people are working in a back room, not really visible. They could be making progress but successes would not be known to others as progress in building a new plant that everyone sees. The company needs to keep personnel informed about DOF innovation projects that may affect their business/functional units, their roles/duties and their interactions with other units.

3. The company needs to keep affected personnel informed about, and mobilized around, a new innovation’s implementation schedule including milestones, required training, systems and deadlines.

4. The company should insist that all affected personnel participate in awareness, system use, and work process training as relevant to their various roles, learning how to use the new DOF application and how to make money with it.

5. The company should hold business/functional unit managers able for effective implementation and deployment of new DOF innovations and for delivering the benefits expected. Unfortunately ability for harvesting business results from IT innovation projects is too frequently not assigned to these operations managers the way it is for a refinery technology innovation.

6. The company needs to measure outcomes of DOF innovation projects in of both results and the effectiveness of the portfolio/project management system itself. Again, the real test is whether or not the innovation makes money – a technical success but a business failure?

Special considerations for DOF

There are three special considerations for DOF:

• One, when a new and exciting technology emerges, usually a flurry of project requests and people appear. So, there must be an effective way to sort through these new arrivals.

• Two, there must be a clear implementation and deployment strategy that identifies s and gets their commitment. It is particularly important in the Digital Oilfield (DOF) that, as part of project requests, the submits an

implementation plan. That plan should show management’s commitment and allow gatekeepers to understand the resource impact. If not, that project should receive a lower score than projects that can.

• Three, decide whether process or politics will rule and proceed accordingly.

DOF is exploding with promise, but mature business processes like portfolio management are needed to leverage the huge opportunities. Otherwise, companies are left with mushy projects that actually decrease business results and limit careers. Therefore, companies must invest now in work processes for getting good business results with minimum employee exposure.

CHAPTER ELEVEN

Implementation Strategies: Deploy or Adopt? Success or Failure?

The strategic framework for Business Value Architecture requires a way to finally get technology into play. A senior management process must determine the way a business improvement enabled by DOF will be made a part of the way the company does business: deployment or permission to adopt.

A KEY ISSUE revolves around one “deadly” word that inevitably breeds widespread confusion: implementation. While two legitimate ways of getting technology into play are readily available – deployment or permission for adoption – each generates different actions, reactions and results. Consequently, when people do not know whether implementation means deploying or adopting a particular technology, watch for insertion failure to happen.

Introduction

• R&D Manager: … Let me summarize by saying that we are confident that this application will allow your product engineers to see well data in realtime … and will enable them to make far faster, and safer, decisions for a field. • Sr. VP and Head of Operations: Sounds good. Let’s do it! • R&D: … Thanks, we will start implementation ASAP.

(R&D Manager leaves)

• Assistant to Sr. VP: Interesting presentation. It sounded good to me. • Sr. VP: I agree … now let’s see what the engineers have to say. I will mention it at the next telecom. • Assistant: I can hardly wait to hear the comments.

(back in R&D)

• R&D: Charlie, we are “good to go”. Call the asset managers tomorrow and tell them when our implementation teams will be at their locations.

(two weeks later)

• Asset Manager (who reports to the Sr. VP): Well, thanks for the very enlightening presentation. … sounds like you are convinced that your application will really save us time. • R&D: We know it will … and we are ready to implement it. • Asset Manager: So this last slide here is your proposed implementation schedule? … and we are on it in a couple of weeks? • R&D: Right, our implementation team will be here in two weeks. • Asset Manager: I understand … I think.

(R&D leaves the room)

• Assistant to Asset Manager: Wow! What do you think? • Asset Manager: Not sure. The boss (Sr. VP) said something in our last telecom about taking a look at something new from R&D. • Assistant: Surely the IT guys just means he’s coming back in two weeks for another sales job, right? • Asset Manager: I don’t need a sales job. Wait a week; then call that IT guy and tell him we are scheduled to do an HSE audit and won’t be able to meet his implementation team for the foreseeable future.

(back in R&D)

• R&D Assistant: Boss, look at this email. • R&D Manager: “Can’t meet for the foreseeable future!” What the heck is going on here?

Viable solution or not?

What is going on here is a failure to communicate caused by confusion around the word “implementation.” Technology can only be a real problem-solver if two conditions are met: the technology must work and it must be successfully implemented or rolled out to upstream business units.

• During the rollout, the workable technology system must be made ready for

s … and • s must be made ready to use the new technology.

Simple? Not really. Industry-wide, many technology insertions continue to be highly problematic, producing disastrous results.

Why? A key issue revolves around one “deadly” word that inevitably breeds widespread confusion: implementation. While two legitimate ways of getting technology into play are readily available – deployment or voluntary adoption – both generate different actions, reactions and results. Consequently, when people do not know whether implementation means deploying or adopting a particular technology, watch for insertion failure.

Consider how these pure, very technical rollout strategies are defined:

• When management decides a technology will be good for the company and mandates that all units use it for business operations by a specific date, that’s a “deployment.” Management is taking an action that requires others to respond. • In contrast, the second rollout strategy is “adoption” (or more precisely, “giving permission to adopt”). Management says, “Yes that technology is valuable” but then lets each business unit decide “if and when” they will voluntarily adopt the technology.”

But beware. Failure of top management to decide and clearly communicate deployment or adoption will default to the adoption strategy.

Either strategy works

Either will work so neither is the superior strategy. However, opting for technology osmosis through adoption can have a big business impact due to the time lag. By the way, “technology” is inclusive terminology for “know-how” expressed in tangible form: anything from drilling technology to back office IT. Figure 11.1 (percent who utilize by quarter) shows the relative speed of utilization for the two strategies, with adoption usually lagging many months if not years behind a target-date deployment.

Figure 11.1: Timelines for Adoption and Deployment

Not only are utilization timelines vastly different, each insertion method has a unique action formula. If that formula is not followed, or if insertion actions are mixed, not only will the insertion not get accomplished but the organization may slide backward in of inferior results, with bad blood resulting. Again, “implementation’s” fatal flaw is the very fact that people are not on the same page with each other about whether a deployment or adoption is intended, instead putting into play a counterproductive bits and pieces “witches brew” rollout approach.

Illustrative of a deployment is when an upstream company puts upgraded remote monitoring equipment on a fixed implementation schedule with expected compliance by all. Although deployment is not autocratic, it is definitely insistent and forceful. This means that every person’s cooperation is expected internally, and failure to cooperate will have clear performance evaluation consequences.

Distinctly apart from deployment, as noted previously, adoption is voluntary by the business unit. For example, a upstream company may distribute companywide “a new, more efficient decision making application” and expect that some units will soon adopt the application with other units to follow later. The message in this case is that the application is not a requirement but rather an equal opportunity offer to everyone. However, the adoption is not just put idly on the table. Instead, everyone is expected to eventually become an adopter of these “better ways of doing business.” Therefore, while not trumpeting any penalties for not getting with the program, the statement is that non-adopters should not endanger the company’s welfare by not participating because they will stand out like a sore thumb. It’s the “good citizen” approach with lots of time flexibility.

Using specific formula

Either way, the technologist needs to understand what that decision is – that the intended implementation is either deployment or adoption. In other words, it must be crystal clear that when management declares that everyone should use the new technology now, it’s a deployment.

Not surprisingly, deployment mandates having a “take charge” person or Executive in Charge (EIC). Otherwise, nobody is running the show. In contrast, if management simply gives permission for the technology to be used if and when anyone wants to, it’s an adoption. The latter’s more laidback approach only requires a sponsor who’s responsible (maybe even a backer) but does not require the change.

All these factors bring the issue to the critical point: each type of technology insertion follows a unique formula, with a different set of required actions as shown in Figure 11.2. Picking and choosing selectively will not work. If any parts of a formula are skipped, certain failure will result. Just as in a homebuying legal contract, the prepayment cannot be omitted.

For deployment, the formula consists of action steps utilized in engineering organizational change: communicating a clear vision of the use of the new technology, altering processes to mesh with the new technology, modifying plant and tools, tailoring the performance management system and project management.

On the other side of the coin, the adoption formula consists of action steps from the decades-old field of “diffusion of innovation.” These steps are: inform/share, convene, case study, demonstrate, answer/, and project management.

For all the optimism that technology insertion should embody, it is nevertheless important to recognize the impact of negative steps, too. In other words, wrongly-selected action steps undermine the technology insertion. These are referred to as negatives even though possibly appearing benign or even somewhat positive. Using even one wrongly-selected step can jeopardize any planned change and even cause outright failure. In deployment, these negatives are: ask, permit, react, renege, bargain and cave in. In adoption, negative steps are: pressure, selling, guilt tripping, forcing, reporting, tattling and comparing. Even to those not experienced in deployment and adoption, the striking differences in the weak and strong words should be apparent.

Management Position

Implement Strategy

DECISION to use new technology

DEPLOYMENT (Executive in Charge)

PERMISSION to use new technology ADOPTION (Sponsor)

Figure 11.2: Formula steps for Deploy and Adopt

Conclusion

Since the industry’s future springs from new technology, very effective formulas are needed to put that technology effectively into place. When introducing new technology, either of two pure plays will work but implementation must involve a formulaic approach or desired results simply will not happen. Therefore, the road to success begins with:

1. Identifying the focus and business objectives of the performance improvement opportunity 2. Validating the technology for enabling delivery of the business opportunity 3. Determining executive intent 4. Clarifying “decision to deploy” or “permission to adopt” 5. Selecting the matching implementation strategy and 6. Taking formula-driven actions 7. Being certain to block out any negative actions.

In technology insertions, today’s vital issue continues to be the confusion in technical and business communities about implementation or rollout strategies, with many technology advocates still using the “mixed bag” approach to implementation. And that’s where potential success sinks in quicksand. Deployment tactics inappropriately used for adoptions (selling, for example)

drive the process backward and cause embitterment, while adoptions tactics used for deployments (e.g., “bargaining”) produce similarly dismal results and ill will.

By unscrambling rollout strategies and sticking to proven formulas, technology insertions will meet or exceed the satisfaction of even the most ardent “implementation” critics.

CHAPTER TWELVE

Caution: Workflow Analysis in Progress

Work process architecture starts with and hinges on the development and maintenance of a comprehensive map of work processes. Work flow analysis is usually the means to produce the map. But there can be traps to avoid in work flow analysis.

Introduction

AS THE DIGITAL Oilfield’s potential continues to expand, work environment conversations have increasingly branched out from being primarily about new technologies per se to the triad of processes, technologies and people.

In a somewhat curious journey back to the future, the upstream industry is moving away from “process” terminology and becoming more comfortable with the term “workflow,” used by the manufacturing industry for decades. In fact, at a recent Digital Energy conference in Houston, commenting on what has been obvious to many strategists for years, a speaker observed that dealing with the human component in energy technology requires better understanding of workflow.

Virtually overnight, people have come together at energy conferences, talking about bringing the culture of continuous process improvement into the upstream sector. Leapfrogging any debate about newness, this is the right move at the right time and energy companies can directly benefit from what other industries have

done before. Above all – regarding possibly the most misunderstood aspect of the new digital era – DOF is not about fewer jobs but about doing business better to grow companies better. Leadership makes it happen.

Leadership is the key

A major cog in getting the workflow wheel well-oiled and turning properly is to recognize that workflow should not be about analysts grinding out technical work and bringing it to the boss as work product in and of itself. It is each leader’s obligation, not merely responsibility, to have a clear strategy and ensure that valid workflows necessary to attain their strategy are in place. Case in point involves all the companies that have let workflow become an analyst’s playground. Some organizations were quicker than others to see the mistake and rectify the problem with strong leadership.

Eight dangers associated with the workflow step

As a result, it’s vital to see specifically where leadership is needed in the technology implementation scenario while absorbing some “Lessons Learned” by other industries. In moving ahead on a positive note, that there are dangers associated with workflow steps. Let’s examine eight that have too often been discovered the hard way.

Danger No. 1: “The Only Game in Town.” First, in what initially seems a good idea, some companies decide to take the plunge into workflow but quickly stub their toe by making it “The Only Game in Town.” How does this happen? Usually, these companies got into workflow only after being too focused on technology to even get near “workflow and people.” Then they knee-jerk reacted and went overboard the opposite way, getting so focused on workflow that they lost sight of the technology and still failed to

see the people component. But, wait. With all these eight dangers comes a leadership-driven solution as exemplified by Danger No. 1: Experienced leadership and a tight hand on the reins can (1) help prevent a target fixation on workflow and (2) stay focused on all three dimensions: process, technology and people.

Danger No. 2 is “Out of the Forest & Into the Trees.” Forget the idea that workflow should mimic a jam-packed schematic. Actually workflow analysis and documentation can be too detailed, which results in often losing the common sense ingredient along the way. Instead, all that is needed is just enough detail allowing workers to proceed with the next iterative step in the processes, technology and people formulation. In combating danger No. 2, experienced and tightly-istered leadership is called for to let in the light of workflow analysis with the appropriate balance of detail and illumination.

Danger No. 3, “As Is Stays As Is,” refers to the popular term used in workflow analysis to describe how a company is doing things right now, prior to making any improvements or adding new technology. However, this “here and now” snapshot can actually cloud people’s vision. In other words, they tend to forget that the reason any documentation of “As Is” is being done is for better understanding to design and document “To Be.” The latter is the real prize by virtue of being the workflow the company wants in the future. How to strike the right balance of time and resources between “As Is” and “To Be”? Again, that is what experienced leadership exerting a tight hand should do.

Danger No. 4, “Means/Ends Reversal,” brings up a problem common in many aspects of business, not just technology implementation. Workflow analysis and documentation become the end rather than the means and the result is less than tidy. In a hyperbolic example, when a company announces its intention to examine workflow, almost immediately process “mappers,” analysts and software tool aficionados appear out of the blue, all of whom

focus in precisely the wrong direction i.e., the means and not the end.

Organizations seem to love creating new departments with multiple levels of professional personnel. After workflow analysis gets underway there is usually a clamor to create the department with various people actually volunteering to be in charge. How to keep the focus on using means to reach the ends? Look to experienced leadership holding a tight hand on the reins to understand that you don’t need a workflow department to get workflow analysis and documentation done properly.

Danger No. 5 showcases the intriguing title, “Tool Rapture.” This danger carries through the ongoing theme of the eight dangers in that people may just flat-out lose their focus along the way. In this scenario, companies involved in process work can too easily get enamored with workflow tools. In virtually the blink of an eye, tools unwittingly become the stars of workflow mapping instead of being enablers.

The solution is to essentially drive the process work in reverse by taking the focus off the glitz. The more simple and straightforward the workflow tools, the better the eventual DOF implementation will be. For those always looking ahead toward getting their hands on the newest exotic tools, they can be reassured that fancier tools are usually in the pipeline anyway. So, to head off any impact presented by the tool rapture danger and get the game back on track, experienced leadership’s tight hand is necessary to spot rapture and take action accordingly.

Danger No. 6, “Double Dutch,” plays out as a “jump rope” schoolyard game with two ropes going in opposite directions. In the business world, consider DOF technology as one rope and the automated workflow mapping tool as the second rope. Operations personnel, the ultimate s, dance frantically in the middle trying not to get hit by either rope. In exerting a tight hand on Double Dutch, experienced management faces a somewhat tricky but doable task. They must anticipate the likelihood of the two technologies colliding,

and prevent the Double Dutch conflict from getting started in the first place.

Danger No. 7, “Too Tired to Climb the Final Hill,” is surely familiar to companies throughout the upstream operations. Anybody within shouting distance of complex technology implementation knows the draining effects of time-consuming, extra effort, huge investment and countless other frustrating details. Just getting the new DOF solution up and running with processes aligned, and people on board, trained and ready at “Go Live” is often daunting.

Tired after climbing that first hill, many are dismayed to find a second hill in sight. This second hill, optimization, calls for fine-tuning technology, tweaking processes and adjusting people as well as skill mixes in order to get full business value from a DOF Deployment. Once again, send out the call for experienced leadership to conserve the teams’ energy and keep expectations focused on both hills, one at a time.

Danger No. 8, “Lost in the Shuffle,” is the final example of coming to grips with what workflow should be about i.e., more than writing down Action Steps and inserting new technology. Companies need to allay fears that workflow analysis represents reengineering, job cuts, and loss of security – in addition to reassuring them that employees will not get lost in the shuffle with all the focus on process and tools. Experienced leadership needs to reassure employees that DOF offers exceptional opportunities and allows developmental ownership of solutions.

Another Bottom Line: A Special Generation

Many in today’s upstream operations have extensive experience in managing their piece of upstream even though they may have not been around to actually

create the upstream way of doing business. Therefore, they need to see that they now have the opportunity to break through and put their stamp on the upstream business using DOF in the world’s most important industry.

CHAPTER THIRTEEN

Models for Innovation

The power of DOF technology does not in itself generate business value. DOF horsepower comes by enabling innovative solutions for Business Improvement Opportunities.

Introduction

“YOU CAN’T TEACH an old dog new tricks” conjures up a blue tick hound sprawled on the front porch of a rustic farm house on a lazy summer day. While everyone loves that old cuss, most likely he really can’t be taught anything whatsoever besides eating from a new food bowl. Same old hound year after year. But, upstream industry management is light years smarter, more business savvy and adaptable to new ideas than that snoozing hound. They didn’t cling to mainframe punch cards when desktops became the way to do business. And they didn’t insist that phones had to have cords when cell phones became the way to reach anyone anywhere. Most importantly, the real decision-makers don’t grab the shotgun off the old dog’s porch and shoot down ideas that actually work better than worn out ones.

To make productive innovation happen, clear business targets are critical. Certainly, having all kinds of diverse thinkers, innovation techniques and an open, creative environment are all good. But, success dictates that certain “must haves” are necessary, and clear business targets are at the top of the list. That translates into companies having bright people soaked in a nutrient solution of information in pursuit of concrete targets.

That’s why the glitzy Digital Oilfield (DOF) is about much more than changing how the industry works technologically, it’s about how the very process of business innovation works. It’s about putting more productive business innovation models into play for better results more often.

“Wishful thinking” not very productive

Traditionally, innovation at companies has followed the “wishful thinking” approach — take creative people, leave them alone in a detached campus environment and they will come up with magical innovations. That’s Model A in the models of business innovation. Although that has worked for inventors whose product innovations became industry standards, in the broad sweep of revolutionary business innovations it has been a flop.

In contrast, take the same creative people, give them precise needs, hold their noses to the grindstone, and real innovation more likely will occur. That’s Model B. And this approach bears directly on the business-oriented path that the Digital Oilfield will take. With the upstream environment continually demanding lower costs, the question becomes: “With the Intelligent Upstream exploding around us, are we going to be a player? If so, are we going to rely on ‘magical thinking’ or try to manage the direction of business innovation?”

Or, stated another way, numerous innovation areas appear to have fruitful potential in the future of upstream. Therefore, the choice for companies is twofold. Do they essentially let nature take its course, letting people be individually innovative and having conversations with an endless stream of digital vendors while hoping that something, somehow emerges from all this? Or will executives recognize the value of delivering innovation through a more structured program with clear business targets?

Figure 13.1: Model A: a Traditional Model of Innovation

Model B is something that virtually everyone in business is familiar with: a direct problem-solving scenario. For example, an executive typically calls the IT expert into his office and says, “Here’s my problem. Figure out how to solve it within a certain number of days.” Subsequently, the problem-solver returns and announces, “Here’s the solution to the problem you described.” But — and here’s where the typically unproductive business/IT relationship can take a turn for the better — there is another level of innovation. In addition to the IT expert doing most or all the listening, roles are reversed, with the business executive essentially saying “Tell me about what is happening in IT today.” In turn, the IT expert says, “Here are all the amazing things happening technologically. Here’s where IT is headed.” To which the business executive hypothetically replies, “I didn’t realize that all those things were possible. Now that I know, here are my re-stated business problems. In this new context, how can you solve them?”

A major upstream company is very involved in maximizing that approach through a business-oriented forum with their IT Department, adding a unique spin. One quarter, the business executives speak and IT listens, then IT later returns with solutions to specific business problems enumerated. Next quarter, however, when the same group meets, IT becomes the “talkers.”

Then, as noted above, the business executives come forward with a new set of questions not formulated in a vacuum but based on what they understand that IT can technologically do for their business. That cycle becomes an innovation engine for the Digital Oilfield in getting both business and IT on the same page.

Innovation drivers

To make productive innovation happen, clear business targets are critical. Certainly, having all kinds of diverse thinkers, innovation techniques and an open, creative environment are all good. But, success dictates that certain “must haves” are necessary and clear business targets are at the top of the list. That translates into companies having bright people soaked in a nutrient solution of information in pursuit of concrete targets.

Underscoring the second point relative to DOF, companies must restore the basic conversation between business people and technology providers who are supposed to help them solve problems. In many companies, unfortunately, that means a fundamental repair of the relationships between IT and the company’s business side. And, an especially critical point, these companies may have to add special people who can straddle the divide between business and IT. These are people with the unique ability to understand and explain business as well as IT issues.

Figure 13.2: Model B: Target Drivers of the Innovation Process

If companies do not have integrated thinking and cannot have reasonable conversations to develop business solutions from IT, then the digital oilfield will remain “neat stuff in the lab” or a digital oilfield playground. On the other hand, when s and their internal IT vendors can successfully converse in plain “Business English” instead of IT acronyms, when IT talks about what is possible in of business solutions, then the digital oilfield becomes considerably more real.

Boundary spanners

Bring back the what? Bring back the boundary spanners. Back in yesteryear’s mainframe days, business analysts spanned the boundaries between computer people and business / operations people. With the advent of PCs and distributed networks, these analysts were deemed obsolete.

In fact, they need to be added to the corporate team now more than ever. They are the people living in the conventional technology world, understanding both the science and the company’s business so well that business people can actually have a rational conversation with them. The end result is that both sides of a company, business and technology, can work together to address the organization’s bottom line.

Bright lights of innovation

Technological advances have brought more dynamic changes to the upstream

industry then even an over-optimistic futurist could have imagined. Bringing more sea changes is the Digital Oilfield which, without an ounce of hype, will change the industry again and again. Yet, some models for business innovation work better than others. With clear business targets and a structured program, innovation can deliver more fully on its promise than all the wishful thinking combined.

Thinking in & out of the box

As more companies jump on the trendy “out of the box thinking” bandwagon, it’s important to that thinking “inside the box” can be just as valuable. So, take a page from blue-chip companies that thrive by combining both kinds of “box thinking,” using key rules of thumb.

• One, stay in the vicinity of out-of-the-box thinkers whose enriched thinking may add value to the business.

• Two, find ways to cope with these people … who are typically strung differently than the norm within the company. In other words, figure out how to put up with the possibly of eccentric baggage lugged around by out-of-the-box thinkers.

• Three, since out-of-the-box thinkers are not mainstream employees, get their ideas translated so that others within the company can actually use their ideas. That may require pairing “natural translators” with the out-of-the-box thinkers to bring to life the actual value in what these left-field people are saying.

• Four, the “out of the box” expression is not confined to the four walls of a

company. Instead, think about breaking out of the industry box, not just the company box. Explore what people in other industries are doing in their own out- of-the- box thinking.

• Five, leverage everyone potentially having fresh, innovative thinking within the company, instead of pigeonholing only a select few as the innovative thinkers. One of the biggest problems in innovation is that not enough people have been encouraged to do hard, logical and/or critical thinking about the business.

Finally, don’t expect the best thinking to come from those who haven’t been around the block a few times. Again and again, the best thinking comes from those who have worked in the box, explored all its dimensions and even experienced its pitfalls, then have broken out with some leading-edge ideas. The bottom line is that when a company needs an extra shot of adrenalin on the idea front, “Go think.”

CHAPTER FOURTEEN

DOF Maturity Factors and Limiting Paradigms

Business Value Architecture can be of varying maturities, from “aligned conceptually” to “documented and worked in a disciplined way.” This chapter shows the dimension of maturity that can be managed during BVA development. Unfortunately many organizations have paradigms or ways of thinking about the business that slow down the development of Business Value Architecture. Such paradigms must be identified and disarmed.

Introduction

THE DIGITAL OILFIELD in its relatively brief lifespan has strikingly transformed how the industry works. What may not be quite so obvious, however, is that the curtain is coming down on DOF’s “overnight” introduction of dazzling new technology and the simultaneous integration challenge.

Regarding DOF maturity per se, companies reach that watershed point through a multiple process of “getting all the juice possible out of the orange.” Although flashy technology will still emerge from R&D, companies’ DOF initiatives have fulfilled their organic growth and achieved some kind of finality, continuing at a generally even growth rate. In other words, for years DOF innovations have spewed out of R&D with minimal attention directed toward managing the new technology. The next wave, astutely dubbed DOF 2.0, is not marked by exotic development but rather about how to manage solutions into operations.

Keys to effectively making the transition into DOF 2.0 are the seven-fold Dimensions of Maturity. First is the codification of DOF. DOF usage and the accompanying transformation of daily operations are now getting written down as a legitimate part of a company’s business strategy. This contrasts sharply with the previous corporate thinking that DOF was not considered as a strong enough business factor to actually be formalized into how business is planned and conducted. Therefore, more executive KPIs and compensation structures are now included specifically using DOF as a means to increase production. For example, operations managers must be responsible for reliable production as well as the incorporation of new DOF technology … and R&D must be responsible for both innovating and fully implementing DOF innovations.

Second is Enterprise Portfolio Management through which a money scenario plays out as a company decides how much to spend on new technology annually, a process referred to as the funnel. In DOF context the significance reflects changing priorities. Previously, companies (especially larger ones) had separate funnels for major individual investments such as production facilities, with a separate funnel for DOF or other IT initiatives. In effect, management took a first cut at top priorities and relegated other items to second-class status, i.e., the dollars that were left over. In the new environment, DOF is moved higher up in Portfolio Management as a genuine option to other potential investments in the funnel; maturity is ideally achieved when only a single funnel is used for evaluating all an organization’s potential investments.

Third is the emergence of Organizations for Leveraging DOF. In most companies, an organization is typically formed and assigned to connect knowledge in the lab with action in the field. Such a connector organization can be structured as “thick” (multi-function) or “thin” (i.e., for communication and technical transactions only). For DOF 2.0, a thick, “intelligent interface” is greatly needed to connect technical knowledge and operational action. An effective interface organization is one that can hear/anticipate business needs, watch technology trends, design as well as

test innovations, and fully implement solutions. While R&D organizations are typically “thicker,” they are emerging as thicker still to bridge knowledge and action. Where does IT fit in the DOF 2.0 era? More often than not, IT’s reputation is one of having a thin interface and not much of an organization between the thinking part of IT and the business’ action part, for all practical purposes, taking IT out of the DOF 2.0 game.

Figure 14.1: The Intelligent Interface

Fourth is DOF Program Management, which is beginning to render obsolete the expression “a DOF implementation Project,” re-inventing it as “a business improvement project” or a “process transformation.” More than wordplay, it has become increasingly critical for companies to recognize that integrating DOF should mean bringing about business improvement enabled by technology. Technology is the enabler not the driver or totality, a concept that has been difficult to digest but that is changing. However, a senior business executive must take ownership. Additionally a Program Management office is where the risks in process transformation are identified and mitigated – technical risk (will the technology work?), organizational risk (will the business use the technology?) and business risk (if the technology works and if they use it, will money be made for the company?).

Fifth is Optimized Implementation, where two interdependent projects must run side-by-side, with equal priority and adequate resources; one project gets the DOF technical system ready for the business and the other gets the business ready for the system. Without this readiness, new technology becomes largely an interesting conversation piece.

Sixth is Maturity of Digital Solution Providers, built on the idea that is finally gaining currency: vendors must be able to take customers “all the way to the bank” to achieve business value for the DOF investment. Imagine that: vendors no longer able to just “show & sell” glitzy new apps or “dump the software by the door”, thereby leaving company management and s on their own to (at minimum) make it all work, let alone make money with the new technology. Thus, vendor selection for future DOF 2.0 work will be maturity-based, hinging on their demonstrated experience of taking customers all the way from diagnosis to the bank.

Seventh is Life Cycle Management, which establishes policies, procedures and practices for the life of automated information systems. Behind these written mandates, the purpose is to deliver exceptional, cost-effective systems; establish systems functioning on identifiable, measurable and repeatable processes; and build an appropriate organizational and Project Management structure. By taking these steps, companies are betterpositioned and solution providers are better able to think through the cycle.

Paradigms that are obstacles to DOF Maturity

Management, which is doing an increasingly better job leveraging DOF technology, will experience more rapid adoption of DOF technology if they do not let obstacles to maturity get in the way. First, however, let’s define the word that’s thrown around with nebulous meanings in the workplace: paradigm. Most refer to it as a prevailing thought pattern in technical disciplines. Paradigms may be good or become an obstacle when no longer applicable.

Some paradigms are unique to upstream, such as “Each well is unique,” a longtime obstacle to process thinking on the basis that drilling a well is not exactly a repeatable process. Actually that thinking flies in the face of the reality that learning from previous wells can carry over to the next wells. Second is “Downstream may be a factory, but upstream is One Off,” which is a processstopping spin-off of the above obstacle.

Another obstacle is a major one, stating that “Our operations managers run their assets like a stand-alone company.” Yet it is neither the manager’s own business nor a stand-alone company; the operations manager has no responsibility for allocating company capital and no capability to absorb R&D risks. In fact, leaving DOF introduction decisions strictly to operations managers will slow or stops DOF technology spread altogether.

In an obstacle echoed at a conference recently, “All DOF applications must be voluntarily adopted and therefore cannot be deployed by mandate” is an inaccurate belief standing in the way of key decision-making that must be made in upstream organizations. No less of a concern are the paradigms that DOF Technology is “hard” (i.e., manageable) and DOF Implementation is “soft” (i.e., people-related, chaotic and unmanageable), along with the idea that “DOF implementation is a people… read that psychology… problem.” Actually, the bottom line is about all three issues: people, processes and technology necessary for companies to achieve value and increased performance. In the DOF transition, people and process changes must be made in sync with new technology.

How do we deal with these obstacles?

1. Identify and explicitly state the paradigm that could be an obstacle 2. Search for evidence of the paradigm in the way the business operates daily 3. Examine and evaluate the paradigms you find 4. Communicate new and more useful paradigms 5. Mark the new ways of thinking as targets in process improvement projects

What’s at stake?

Round One of the digital oilfield was exhilarating but companies must now effectively manage in the maturity stage. At stake is nothing less than the future of the business.

CHAPTER FIFTEEN

A to Z Services from DOF Vendors? Not yet!

Digital Oilfield vendor statements imply that solution providers have begun to recognize in earnest that yesteryear’s vendor selection criteria are fading away, that their selection may now be based on vendor maturity and scope of services. That means they are either capable of ing each upstream company all the way from diagnosis to operations … or they are not.

DOF TECHNOLOGY VENDORS are key ingredients of the Digital Oilfield equation. Not all vendors, however, have the same services from A to Z or the same level of process and organizational maturity. BVA Technical Process Architecture must include a technical process that enables the selection of an A to Z vendor at the right level of maturity, at the right time and for the right business project.

Consider the major culture/business transition. On the company front, those not transforming themselves to leverage DOF technology to increase production will be unable to match competitors’ cost structures and ROI. On the DOF provider front, those not transforming themselves to customers “all the way to the bank” may see themselves forced out by providers ing complete lifecycle DOF solutions. Given the crossroads at which companies and providers have arrived with DOF technology, it’s a good time to consider the future.

Foremost, how will each member of the DOF team likely alter the way it operates for today’s DOF environment? Let’s attempt to identify several ways

that a DOF Solution Provider (sometimes called Technical Vendor) may move forward in today’s DOF environment. For openers, what does maturity mean for DOF Solution Providers? What is the bottom line for maturity rather than simply the now-outdated approach of getting new technology up and running? As alluded-to earlier, the new business model is for vendors discovering they need to take their customers all the way to the bank. They must be able to work with a client who is planning an expansion and determine what digital technology can do, all the way through planning and execution – to ultimately deliver business value.

The new vendor business model will be to “take customers all the way to the bank.”

Practically speaking, providers must move away from extolling and ing the next “sexy” app and transform themselves to be able to provide complete solutions all the way to client success. No simple challenge, this means that no longer can an app be “dumped by the door” by solution providers with the comment: “Technically, it does everything it’s supposed to. If your engineers can’t use it…well, that’s beyond the scope of our assignment or responsibility.”

Time for label change – and more

In the DOF evolution, certain names and phrases are becoming somewhat obsolete. For instance, “DOF project” may be too dry to convey the fact that what is really occurring involves a value proposition. Therefore, a more-timely expression to replace “DOF project” may be a “business transformation project enabled by DOF technology.” And that’s not just semantics. When companies focus primarily (or exclusively) on getting technology up and running in the organization, they are actually steering their people in the wrong direction. In other words, companies should re-title the box in which they have been working and start re-directing digital technology resources more toward achieving business results.

In the global upstream industry, DOF solution providers have begun to go beyond the talking stage and put their ideas in play. Two major solution providers now have publicly stated their respective positions on DOF. Vendor X, in their own words, assists upstream companies in transforming operations to increase production while improving safety and operational efficiency. Meanwhile, Vendor Y has developed the following philosophy. For companies to look to the future in of achieving value and increased performance, they must actually look beyond technology. And in making the transition to a digital environment, it’s vital that they recognize the people and process changes also required.

Another major shift among solution providers (or vendors) is they have expanded their business pitch and, without modesty, are saying they can cover the solutions landscape from A to Z. Essentially that entails going from:

• diagnostics to design, • to development of applications and infrastructure, • to getting systems ready for the company, • to getting the company ready for the systems and even, in some cases, • to managing DOF infrastructure.

These vendor statements imply that solution providers have begun to recognize in earnest that yesteryear’s vendor selection criteria are fading away, that their selection may now be based on vendor maturity and scope of services. That means they are either capable of ing each upstream company all the way from diagnosis to operations … or they are not.

Wait for Nature or Design for Success?

Having made bold statements about their DOF capabilities and game plan regarding expanding services from A to Z, providers can either wait for needed changes to occur naturally in their organizations or they can be proactive and design an initiative that transforms their organization to be able to their customers from A to Z. In other words, solution providers are making all the “right comments” for DOF success but they have to do more than just talk, they have to “walk the walk.” In order to serve their customers from A to Z, they must have major new organizational/business competencies put into place. Unfortunately for some vendors, that would be a herculean task (which is to say utterly daunting or even impossible).

Why? To “walk the walk,” providers must embrace and become proficient in all three elements

• Help modify customer technologies, • Help customer modify work processes • Help customers align their people and performance management systems to encourage use of the modified processes and technology

Vendor Steps to Maturity

Vendors who elect to design their way to the delivery of quality A to Z services cannot make a single move and expect immediate improvement in their ability to serve their customers. Several steps taken in order will need to be completed before the vendor changes anything about the way it serves customers.

1. Form an A to Z team and get a project plan in place: It is critical for vendors to use a project mindset to mature their way of working with their customers. Therefore, providers must begin by forming an internal project to effect the change i.e., turning the initiative into a disciplined project to mature their organization’s services to be able to serve customers from A to Z.

2. Communicate an A to Z vision: DOF providers must develop and communicate a broader vision to their associates/employees. In one respect, they should let employees see themselves in the near future engaged with the customer in technology, work processes and people alignment. And this is perhaps the biggest change because previously the vision would have only seen solution providers and customer employees working solely with the technology. Additionally, providers need to develop and communicate how their organization will customers all the way. That is expansive —from diagnostic to design, to infrastructure, to system and business readiness, sometimes even to operations, i.e., from A to Z.

3. Alter internal processes to enable A to Z service. The vendor’s internal work processes will need to be altered or added. Now they will have to break the mold and add work processes that go beyond software selection, implementation and systems integration to processes and methodologies that focus on preparing customers for the use of the technology to create business value: increased production.

4. Alter tools to A to Z processes. The provider’s internal tools/technology will have to be altered or added to A to Z work processes, which might include adding models and simulations that detail the business readiness process and collaboration tools that can be used both by customers and other vendors (a sticky situation for most providers).

5. Manage Performance from A to Z: Providers must alter their own people management systems by setting up new organizational leadership structure with “Customer Business-Value Creation” (as opposed to “Technical Operations”) as the focus. Additionally, new value-oriented job descriptions must be written, business readiness people must be brought on board, employees must be trained on business value/readiness … from A to Z. Getting business will be critical.

At stake

As noted earlier, what is at stake in today’s DOF environment is business gain for the upstream company that is the customer of the solution provider. That gain for customers means increasing production and reserves. For technical providers willing to invest in transforming their own competencies, three goals can be achieved: they can have longer-lasting customer relationships, they can more likely keep their “seats,” and they can keep the door open to selling the next round of whiz-bang digital technology and services.

CHAPTER SIXTEEN

Organizational Culture of for IT

An important outcome of implementing the Strategic Elements of Business Value Architecture is a culture of for IT technology. Without a ing culture, IT technology contributions will be problematic and largely ineffectual.

THE EFFECTIVENESS AND efficiency of implementation of IT solutions will always be impacted by the company environment in which IT operates. While some companies understand the game and willingly provide a productive environment for IT, other companies are hostile to IT and provide little if any .

When an upstream organization decides to make a run at Digital Oilfield technology, IT leadership will need to sit down with top management and assess the organization’s culture of for IT. If the organization’s culture of for IT is weak (or hostile), it will be better to repair that culture before moving forward with Digital Oilfield technology.

Over time, companies develop a culture or “context” of practices, attitudes, and conventions that impact the potential success of any IT implementation. A culture might vary from “ive” (e.g., our IT projects always work) to “sabotaged” (this is just more “crap de jure” that we always ignore). The development and maintenance of a positive culture for ing IT is a corporate responsibility. The “C” officers (CEO, COO, CFO, CIO) have a personal responsibility to provide a positive culture of . The dimensions these execs will need to manage cover a wide range of practices and attitudes

about information technology as shown in the list below.

1. Pro forma commitment at decision point

When a new platform is commissioned, its estimated production is added to formal business projections for the scheduled “on line” date.” When IT projects are commissioned, it is common to leave any projected business results out of the formal dollar projections of the company even though there may be a “business case” that included numbers. The difference between a platform construction and an IT implementation is that the platform quite naturally embodies a hard asset mindset while the IT implementation is assumed to be problematic.

Therefore, DOF managers must make the business case as tangible and transparent as possible and then reflect the expected business result of the IT implementation in the “official” business pro forma. A business committed on paper to deliver results is far more likely to be ready to fully use an IT asset at go live.

2. Historical basis to envision tangible results

Largely, DOF IT implementations are stigmatized before they even figuratively get off the ground. One, many employees have only negative recollections of IT implementations and, two, that negativity is very real because many companies have a woeful track record in successfully implementing IT systems that work, or IT that’s actively used throughout the organization, or IT that actually makes money for the company.

Breaking a string of implementation failures only happens one way: management must commit to slam dunk the next IT initiative, followed by the next and so on. Failure to break the losing streak will surely condemn many high potential DOF implementations from their start.

3. Lack of ability for IT utilization in general

While failure to put to use a non-IT asset (a platform) to work would be seen as insubordinate, unsatisfactory and punishable by termination, failure to use (or to learn to use) IT assets, which typically are not cheap, does not even show up on the radar as a performance deficiency. Also not reaching the level of mild censure is a management failure to fully prepare a business team for using IT assets at “Go Live.”

Figure 15.1: Dimensions of Organizational Culture for IT

The solution, which may seem no more than re-inventing language, is a redefinition. Company assets should be defined not just as hard assets such as those at an E&P site but all assets for doing the company’s business including IT systems. Concretely, this means that failure to wring every possible drop of productivity from a new IT implementation should be treated like failure to fully utilize a new platform.

4. Stereotype of an IT Implementation … No can do

Many employee/managers have a mindset about IT implementations: “they are all messy and chaotic, but sooner or later, the workers will figure it out.” Successfully IT implementation depends on turning around the stereotypical perception of an implementation. Unfortunately, that’s no small task due to most employees’ and managers’ view of the whole “exercise.” If company personnel just thought IT implementations had occasional, un-expected glitches, the outlook for success might be brighter. But, throughout companies large and small, that’s simply not the case.

The solution is to provide an apples/apples hard dollar comparison showing everyone why a new, improved implementation approach is called for. On one side of the ledger, calculate and make transparent the costs associated with the failure-ridden “Let them figure it out” way. On the other side, benchmark successful implementations and employ proven templates for both (1) preparing the IT system for the company and (2) vice versa.

5. Top managements’ clear expectation of full utilization

This dimension is virtually astounding in its simplicity: delivering clear top management expectations of full utilization of implemented IT systems/applications. Who would even briefly envision a CEO telling operations personnel that he/she expected them to begin using the new platform upon its completion? Why else would the platform be commissioned? Yet, that assumed expectation does not apply with IT implementations. Believe it or not, top management must openly state and reiterate the company’s intention to have all business units and all employees fully utilize the new DOF IT asset upon “go Live.”

6. Personal control at the desktop

This dimension involves an issue that should not occur in the first place: personal control of IT utilization at the desktop. As a component in successful IT implementations, the slate needs to be wiped clean on a nagging workforce problem which too often finds s stating that their computer desktop is theirs personally (like the family pictures in their office are personal), so they’re not required to “get with the (overall) program,” it’s their computer desktop and they can do what they want with it. This individual hijacking of a corporate asset should be unplugged at the earliest opportunity. That is, the solution should be to strongly educate s that IT systems and applications are company assets accessed from a company desktop that is not their personal property any more than a valve on a drilling rig belongs to a maintenance worker.

7. Visibility/Tangibility of the asset during implementation

Amid all the reasons why IT implementations usually fail, one of the foremost is the “invisibility” factor. Think about it. Whether the new platform is being viewed in a fabrication yard or during construction on site, it’s an oversize visual experience. That is not the case with IT. When s get beyond seeing or

picturing desktops or maybe even servers, that’s about the end of the line for “what IT under construction looks like.” Every other aspect from system integration to all other back room workings may as well be completely invisible.

Given that absence of any visual stimuli for s, how do s get ready for something they cannot see? The company might use prototyping of the company’s DOF system, developing guided tours to see the new system at work (even though they cannot actually see the “gears meshing”), and/or preparing a robust communication “show & tell” program. The objective is straightforward – help ensure that all employees have visibility of the DOF application that is coming so that they can appreciate their need to thoroughly prepare for its use in day-to-day business.

8. Lack of full spectrum of service providers

In the upstream industry, vendors have been in place for decades to build new assets and to help prepare business employees to use them. And they have indepth experience to handle the enormous task and its complexity. Unfortunately, the IT industry is not always well-equipped to handle new IT implementations with the level of vendor needed to ready business personnel for full utilization (i.e., plenty of resources for technical readiness but short of qualified resources for business readiness).

Fortunately, the solution is neither exotic nor infeasible. Upstream companies should create transition teams (from old to new IT systems) to help ease the changeover from a legacy way of doing business to the way business needs to be done with an improved work process enabled by a new DOF application. These teams would be IT’s version of SWAT teams that swoop in and work with s to best facilitate success of the of the business improvement including the IT implementation.

9. Failure to clarify implementation strategy

Look at implementation strategy this way. Either top management will “select and direct” a DOF implementation (like an airline’s management directs the use of a new flight procedure) or management will give permission for a DOF application to be adopted (like management giving permission to accept a new company insurance program should anyone desire to do so). Management’s decision to fully use an asset for a business purpose leads to a “deployment” strategy. Whereas, permission to try, assess or experiment with an IT asset leads to only an adoption assumption with a stretched-out “normal distribution” acceptance. For the solution, look no further than (broadly speaking) a three-step approach:

• clarify and evaluate the business problem and solution, • get a management decision to “direct” or “permit adoption” and • apply an applicable, proven implementation model.

10. Failure to assume control of the IT asset and its implementation

This dimension lands with a thud: failure of the business side to assume full control of the DOF asset and its implementation. This downside occurs for a reason that practically every computer can identify with. Geek speak intimidates many managers and employees, which results in nobody taking firm responsibility and control of an implementation. The solution? It’s one that is absolutely essential, yet still goes down about as well as castor oil. The business side must take ownership of the implementation and should demand that the company’s IT side speak the business language and meet business/output requirements.

The Impact of the or Non- for Information Technology

Even if the technology and the business organization collaborate to improve the business by enabling process changes enabled with DOF technology, their work could be for naught. As you see in the figure below, there are four possible scenarios and three of them are bad.

High

ENDLESS FRUSTRATION

REALIZATION OF BUSINE

DOF Potential TRIVIAL PURSUIT

DISAPPOINTED EXPECTATIONS

Lo Non- Culture of for IT

Full

Figure 15.2: Impact of for Information Technology

So whose job is it to work a non- problem. The obvious answer is the CIO or the Director of R&D. However, their job is to bring the issue to the executive table. Hopefully the CEO will recognize that it is his problem, and he should act accordingly.

Heavy-duty Change Management

With these ten issues continually clanging together, heavy-duty change management is definitely called for. Employee attitudes about IT must be changed to best ensure that DOF implementations are successful and not degraded or complete failures.

Picture a farmer’s field. The dirt must be well prepared or the seeds the farmer plants will not thrive. Today’s DOF implementation environment is like the field that must be prepared for DOF implementations to have the best chance to thrive. Heavy-duty change management will be required in many companies to correct weak cultural factors that today are limiting DOF success. Heavy-duty change management is not seminar-speak, it’s what companies will need to focus on to prepare the upstream for the full benefits of the DOF era.

Survey: The Culture of for Information Technology

Success in implementation of a Digital Oilfield product is based on more dimensions than “quality of the software” and eagerness of business s. Over

time, companies develop a culture or “context” of practices, attitudes, and conventions that impact the potential success of any DOF implementation. A context might vary from “ive” (e.g., our projects always work) to “sabotaged” (this is just crap de jure that we always ignore).

This survey is designed to create a conversation about your company’s culture for implementing DOF projects. Hopefully the conversation, preferably between business s and information technologists, will lead to all actions needed to give new DOF applications the best possible chance of meeting business targets.

How strong is your organization’s culture of for IT?

Instructions

Please answer each question below by selecting a number from 1 (one) to 7 (seven).

• 1 means “absolutely no” and 7 means “absolutely yes” • Go ahead … write in the book … you mother will never know …

Question

1. When our company gives the “go ahead” for a digital upstream project, the anticipated fina

2. Our company has a positive history of implementing large information technology projects

3. Our company holds its managers responsible for preparing their business units to fully use

4. Our employees and managers have an attitude about Information Technology projects that

5. Our company’s top management sets clear expectations for use and says “out loud” several

6. Our managers and employees see “their computer desktop” as an extension of the company

7. Our company ensures that all s of a new information technology system have visibility

8. Our company contracts with the vendors that are expert in helping business s prepare f

9. Our management makes it absolutely clear when a new Information technology system is t

10. Our company’s business unit managers “take full control” of the implementation of the D

Scoring Your Survey

Add your ten scores and identify the zone in which your organization’s context (or culture) falls.

Your score: 55-70

Green Your context should be “safe for DOF implementation”

40-54

Yellow DOF implementation will definitely be chancy. Corrective action

10-39

Red DOF implementation will be unsafe without aggressive corrective a

CHAPTER SEVENTEEN

Implementation Principles

Implementation principles apply to every aspect of DOF Business Value Architecture. Without such principles, implementing BVA would become a huge energy sink of fruitless trials and errors. Why re-invent the wheel when implementation principles are down in black and white?

Context

THE USE OF proven principles for implementing Digital Oilfield is critical. Coming up with the Digital Oilfield systems design, finding the vendors with the right technology, all pale in comparison to the tough job of implementing the organizational changes needed to realize the project gain. Strong leadership will be needed to resist the urge to “slam” Digital Oilfield technology solutions into the day-to-day operations of the company without completing the thorough integration that will be needed.

Several years ago we began to work on the concept of the “Red Zone” that we defined as a maneuver (e.g., merger, strategy change, culture change, etc.) led by a company’s executives in order to move their organization a full step forward. We further restricted the definition to those maneuvers that are “make it or break it” for the organization. That is, if the maneuver works, the organization moves ahead. If the maneuver does not work, the organization does not go back to the starting position, but instead suffers a business setback.

Is the implementation of Digital Oilfield technology a Red Zone? Probably not … if the implementation is restricted to a very limited section of an organization’s work processes. But an organization-wide implementation of the Digital Oilfield is surely a Red Zone … with promise of big gains if successful but with the possibility of a real setback if the implementation is unsuccessful. And any implementation will be haunted by the ghosts of the past … a time in which 70% of big system implementations did not meet management expectations.

Principles

What follows are principles that we believe maximize the chances that a company-wide DOF implementation maneuver will be successful.

Principle One: Declare the Company in a Red Zone

Implementing Digital Oilfield systems is a Red Zone maneuver for four reasons:

• DOF technology, properly applied can produce powerful results, but • Implementation is very difficult from a technical point of view; • Implementation can be very disruptive to the existing order; and because • Many business folks are still caught up either in e-euphoria, the hype about “e” (DOF) curing all … or in the negative stereotyping of “all big system implementations are root canals.”

Implementing big systems to improve the business (like the Digital Oilfield)

brings out conflicts like no other Red Zone: conflicts between “brand new” and “tried and true,” between young and old employees, between notions of the new economy and the old. The bottom line is that top management should warn the organization that they are about to enter an implementation that will require their best ideas and greatest tolerance of each other. During this difficult time, strong business practices and principles must rule, not untested assumptions about the magical qualities of the Digital Oilfield.

When we talk about reengineering, we mention that alarm bells go off for many employees when they hear the word “reengineering.” Top management’s challenge with the Digital Oilfield is to ensure that alarm bells DO go off for the organization.

Principle Two: Put the Best Players in the Game

As with any implementation maneuver, Digital Oilfield implementation requires direct leadership in massive amounts from the executives of the organization. Each and every executive has a distinctive role that must be played well for the organization to enjoy the benefits of the Digital Oilfield. We have seen several problems come up in DOF deployment that must be avoided. First, CEOs and COOs who do not have strong techno-savvy, cannot step back or aside from their leadership roles in a DOF implementation. They must stay in the game lest business interests lose out to technical considerations. Handing the leadership of a DOF deployment to those with the technical skills may leave core business knowledge and experience out of the leadership equation.

Second, top management should avoid the intuitive assumption that if a player has strong information technology skills, she will also be a whiz at implementing the Digital Oilfield. DOF implementation will clearly be more of a people and process exercise than a technical task.

Third, the entire executive team must supply leadership during this Implementation maneuver, staying watchful of divided teamwork and being careful not to under-budget needed manpower. In short, the right horses must be in this race from both a business and a technical point of view, and care should be taken not to allow polarization around the techies and the non-techies.

Principle Three: Focus on the Customer

The customers for the Digital Oilfield are of two varieties: downstream resources that receive upstream production and a variety of decision makers who can use more and better production information to make better business decisions. Both categories of customers should be taken into in the design and development of improved work processes enabled by DOF technology.

But problems can arise if the company is not clear on its customer strategies and on exactly what they want to gain from DOF deployment. Customers are still the king, and any Digital Oilfield deployment must explicitly take them into . Failure to Identify a customer strategy up front in the planning for DOF deployment will result in a de facto strategy the organization may not want.

Principle Four: Set Clear Implementation Goals

Goals for managing a DOF deployment must be the familiar business goals of speed, cost, value to customer, and satisfaction, not down at the detailed level of number of mouse clicks. The purpose of a DOF deployment is to solve a realworld business problem, to add clicks to bricks, strengthening the company’s existing work processes and assets. Clear business goals must for set for the Digital Oilfield initiative.

The goals for DOF deployment fall out like those for reengineering: work process goals and business result goals. Work process goals guide the implementation toward faster, better, cheaper, while business result goals anchor the desired end states of market share, profitability, and return. It is also critical to have goals in place for customer value and efficiency in the distribution channels.

Work process goals can be set aggressively: reducing the time it takes to get down-hole information to production engineers or to place an order with a supplier by, say, 90 percent, increasing the speed by which the field guys can a company expert team to solve a problem, etc. Result goals, on the other hand, should be set like other business goals: at feasible but challenging levels. In a mature industry filled with established companies, it is likely that major changes in business results will be available … from which competitive assumptions can be made.

Principle Five: Blueprint for Success

The goal of this blueprint step is to generate a picture of the organization as it will operate in the future with DOF technology and processes in place. The first and most important step in building the blueprint will be developing the Digital Oilfield strategy. Methodologies are beginning to emerge for this vital step. While the words vary a great deal in these methodologies, the ideas are essentially the same and include steps like those below:

1. Assessment of the company’s overall business strategy as the foundation for Digital Oilfield development,

2. Assessment of the company’s business products/services/processes to identify leverage points for exploitation with Digital Oilfield solutions,

3. Assessment of the company’s current capability for hosting Digital Oilfield solutions (including IT technology strategy),

4. Assessment of the business environment with special emphasis on the Digital Oilfield,

• Customer/supplier direction, trends and capabilities, • Competitive direction, trends and capabilities,

5. Exploration of “what is possible today and tomorrow” with DOF solutions,

6. Development of DOF options/scenarios that could add value to the company in both the short and long term (including quantified business plans), and

7. Presentation and discussion of DOF options with key business and technical personnel to identify the desired DOF strategy.

After development of a DOF strategy, management must aggressively lead the process to select the DOF applications that allow the strategy to be fulfilled. Blueprinting goes further to picture the whole organization, not just those Digital Oilfield systems that are to be added. The finished blueprint must show a complete organizational picture or people will get the impression that their work world will turn totally to clicks. Employees must be able to see and understand

the completed organization with its Digital Oilfield systems up and running, in parallel or substituted for existing systems processes. The blueprint must also show how people will be working, including any changes in culture, attitudes, mindset, etc. Standard ingredients of the blueprint should be: organization chart, goals/measures, process flows, system architecture, and vignettes of how people will need to perform.

Principle Six: Focus on Mechanics and Plan for Complete Operations Integration

Successful execution of the implementation properly begins with the identification of the mechanical moves that must be made for successful implementation. Execution will be successful only after the new DOF solutions have been fully integrated into the day-to-day operations of the company. The mechanicals we work on for any Implementation stay the same. Once again, those mechanicals are:

• work processes, • the plant, equipment, and tools needed to those work processes, • the management systems that help focus employee performance on the new redesigned work processes that are enabled by technology.

Once again the bottom line is the same: work processes and information technology tools have to match to the letter for maximum performance and minimum confusion.

We have found the term “operations integration” to be particularly helpful in communicating about both enterprise and upstream. The term seems to fit well

with technical personnel who are involved in the technical implementation of the DOF solution and the needed systems integration that go along with it.

The following actions must be taken to complete operations integration of the Digital Oilfield:

1. Clearly communicated vision of the DOF solution at work 2. Direct communication of expectations/requirements for use of the DOF solution 3. Work processes altered and aligned to match the DOF solution 4. Work processes documented and worker instructions placed in company policies and work procedures 5. Roles of workers modified to fit aligned work processes and DOF solution 6. s/workers trained on the aligned work processes incorporating the DOF solution and 7. Performance management system in place to reward desired performance and to penalize failure to use the DOF solution to do the work of the company.

In most companies, operations integration is a significant effort that takes careful management and attention to detail. When coupled with the complexities of a DOF solution, technical implementation and systems integration, disciplined program and project management are clearly required.

Principle Seven: Use Program and Project Management to Build to Print

Strong, disciplined Program and Project management are absolute requirements for an DOF implementation. The program manager’s primary duty is to implement the blueprint just the way it has been designed, or at least as close as humanly possible, despite the inevitable conflicts that will come up on the technical and business sides of the equation. For example, it is always tempting to find a place for “old Charlie” who has been here forever even if his skills don’t match the blueprint. So what do you do? You change the design to fit Charlie. Once such a precedent is set, the design is about to lose its integrity and therefore its value.

The program manager should be focused on two things at once: technical readiness and business readiness:

• Ready the DOF System for the organization: The first task ensures that the Digital Oilfield technology, and any other technical systems accompanying it, is successfully readied from a technical point of view on target, on time and on budget.

• Ready the organization to use the DOF System: The second task is to ensure that the operations-side s of the DOF system are thoroughly prepared and are ready to put the new business solution into full use in the organization as soon as it is ready … on target, on time and on budget.

Accomplishing both tasks in parallel not only involves a great deal of planning and day-to-day supervision but also working across many organization lines with technical and business communities who have different missions and priorities, and sometimes, different levels of excitement about digital technology.

The projects that make up a Digital Oilfield program are best organized around (1) technical systems (the Digital Oilfield application) and (2) business

organizations to be impacted by the DOF solution. Some cross-functional hip will be useful in the project organizations. For example, technical project teams focused on configuring and implementing the DOF system should have some business personnel assisting the technical work to ensure the presence of the business perspective. Organization preparation projects, key parts of operations integration, are designed:

1. to get business work processes altered and aligned with the DOF technical system and vice versa, and

2. to alter business-side roles and responsibilities as well as to provide training on work processes as they would be done with the DOF system.

Business organization preparation cannot go forward successfully without intense communication and coordination with the personnel who are at work on the DOF technical projects.

The primary goal of the program manager is to ensure that the DOF solution is fully implemented and fully utilized for the good of the company. Full implementation is tough; full utilization will call on a great deal of skill and hard work as the program manager works directly with the CEO and COO to ensure complete operations integration of the DOF part of the solution.

Once the DOF system has gone live, program management must shift its emphasis to exploiting the new DOF system for company advantage. The projects that make up the DOF system exploitation are best organized around organization-wide work processes that serve internal and external customers. Cross-functional hip is a requirement for project teams designed to find better ways for the organization to work together by using the new system.

Program management should stay active until top management is satisfied the results goals of the DOF implementation have been achieved. At this point, program management can be discontinued until the next hurdle for the DOF system is encountered, such as implementing the next software release from the Digital Oilfield vendor. In practical , some program management functions barely complete one cycle of system implementation and exploitation before top management decides to implement the next purchased release or module. Implementing a new release may or may not be another Red Zone, depending on the amount of process change required to align with the system.

Principle Eight: Focus on Speed

Just as with the other system implementation maneuvers, the idea is to move into the fully-implemented Digital Oilfield solution as fast as possible once the decision is made. However, I have watched several firms with different kinds of speed issues in implementation. While most Implementation maneuvers tend to go on too long, the tendency seems to be to go too fast with DOF solutions. The requirement for excess speed clearly comes from top management who wants results quickly, sometimes too quickly. Pushing too hard has resulted in two kinds of problems: moving into Digital Oilfield implementation before DOF strategy was clear, and slamming technical solutions into the organization. The word slamming means to implement a technical solution with little or no time or effort given to operations integration.

Moving before strategy is clear usually results in bad business results or, if the company is lucky, a canceled project. Slamming usually results in intense organizational confusion, worker frustration, and a far longer delay in utilization of the system than would have been required to do operations integration up front, in parallel with technical implementation. As with any other Implementation maneuver, think twelve to eighteen months from the time of decision and strategy development to implementation and full utilization of the Digital Oilfield. Agile development can produce some returns along the way, but

the longer time frame is still the norm.

Principle Nine: Meet Special Needs of Workers

Two special needs apply to implementing the Digital Oilfield. First, workers will have a very high need for information about the impact that moving to the Digital Oilfield will have on them and their jobs. Unless the workforce is already heavily experienced in the information technology world, confusion will reign, and rumors about job impacts will be rampant. Given the hype that DOF has on the street, it will be especially critical to conduct a robust communication effort during the entire DOF Implementation. The goals of the effort should be to ensure that people know what is going on with the DOF initiative, why Digital Oilfield will be useful, and how the organization’s, and therefore the people’s, future will be unfolding in the DOF world.

The second special concern with the Digital Oilfield implementation has to do with worker skills. While skill level is a critical factor in any Implementation, it is especially critical in this one. If the workforce is low on technical skills, the move to Digital Oilfield will be a tough one. We heard of one manager who got a real sense for how tough the Digital Oilfield implementation was going to be in her organization when she saw workers looking at a mouse for the first time and then rolling it on the computer screen.

Effective, efficient, timely training will be needed to ensure that people will be able to perform as needed in their job that then includes the use of the DOF application. Top management must face the fact that some of their workers just may not be able to make the needed transition to the e-world. Those workers must be dealt with fairly and honestly to ensure they have a place to go in the company where they can continue to be valuable employees.

Principle Ten: Reward for Implementation Performance

Rewards and incentives work for this maneuver just like they do for all the others. Putting those incentives in the right place is critical here, however. Focusing reward dollars on nebulous and short-sighted goals like “getting our company into the DOF world quickly” will result in quick, sexy web sites and slammed-in solutions. Rewards must be closely tied to the accomplishment of process and end result goals. Strange as it may seem, best results during a DOF implementation come from rewarding achieved business results, not implemented e-technology.

Yes, we do want to provide incentives for completion of the Digital Oilfield technical project on target, on time, and on budget, but not at the expense of the organization’s preparation and integration. Incentives need to be tied to multiple goals, including both process and business goals, and paid over one to two years after the Digital Oilfield initiative is essentially complete. Avoid paying incentives for the accomplishment of process goals without corresponding achievement of business results. And avoid paying incentives for either accomplishment if other parts of the organization have been trampled just to get to the DOF targets.

Applying the Game plan

Implementing Digital Oilfield is the rage, technology sellers are going great guns, and the hype is in 6th gear. Top management’s job is to plot a safe and sane journey through this newest of the Implementation maneuvers. Strong leadership focused on getting results, good heads in the blueprinting step, and strong aggressive program management can put an organization on the leading edge, without going overboard to the bleeding edge.

CHAPTER EIGHTEEN

DOF Leadership Roles

DOF Business Value Architecture is both kept intact and propelled by C-level leadership until the processes in the architecture become ingrained in the day-today operations of the company. Leadership will only be effective, however, if the leaders perform their needed duties. So what is the problem? Leaders will have to learn those “digital duties.”

VISIBLE, COMMITTED SENIOR level leadership is required as a critical success factor for the implementation of Digital Oilfield technology across a company. Many technology implementations have failed because senior managers knew they were a piece of the puzzle but did not know exactly what to do. This chapter lays out detailed duties for all the C-Level Officers.

Each of the C-Level Officers in the modern upstream organization has a leadership responsibility (otherwise, why the “C” in their title?). Implementing anything more than a pilot Digital Oilfield project will require senior management, C-Level day-to-day involvement. (No, not every day all day, but maybe 15 to 30 minutes every day to ensure that they are playing their roles in a huge team effort to take advantage of the benefits of the Digital Oilfield.)

Are you ready to implement a big Digital Oilfield Project? As a part of the project kick-off, put all the C-Level players in the same room, put the DOF Duties on the table in front of them, and ask for discussion … and then commitment. (Don’t expect them to start talking immediately; it will take a few minutes for them to catch their breath after reading the duties below!)

• DOF Implementation duties of the Chief Executive Officer (CEO)

• Chief advocate to the organization of DOF deployment. The CEO is the guy who must know in his gut that moving to clicks to the company’s bricks is a good and defensible move with great promise.

• Chief Strategy Officer who ensures that the competitive strategy of the organization is clear and that the e-strategy is clear. The CEO must be able to clearly state the strategy of the company and the role of Digital Oilfield capability in furthering that strategy.

• Works with the COO to target the organization’s work processes that will be enhanced or complemented by the DOF capability.

• Works with the COO to set business goals for DOF implementation.

• Chief Communications Officer to the firm on the business reasons for DOF implementation, the specific business goals that are to be reached, as well as the continuing status of the change.

• In addition, the CEO must be a major provider of resources and an internal obstacle remover. The CEO must keep the ultimate time clock on the DOF implementation and the business objectives associated with it.

• DOF Implementation duties of the Chief Operating Officer (COO)

• Chief Targeting Officer who ensures that the right and best processes are targeted for Digital Oilfield projects.

• Owner of the specific business goals of the Digital Oilfield project

• Chief executor of the Digital Oilfield blueprint. The COO works directly with the CIO to ensure that DOF implementation and organizational preparation to use those systems are in sync and properly done.

• Works with the program manager and the CIO to understand, identify, and schedule all the concrete changes that will be needed to meet the business objectives of the Digital Oilfield project.

• DOF Implementation duties of the Chief Information Officer (CIO)

• Chief information technology strategist ensures that the company’s technology strategy accommodates DOF systems.

• Chief DOF system architect works with the COO to ensure that the systems selected (or developed) will meet the requirements for reaching business goals.

• Chief Technology Officer, ensuring that the technical implementation of the Digital Oilfield systems is properly completed, ensures that technical risks associated with the system implementation are properly managed and mitigated.

• Works directly with Program Management and the COO to ensure that information technology resources are available for cooperating in preparation, i.e., the provision of training on the technical operation of the DOF systems.

• Works directly with the COO after DOF implementation to ensure that performance gains from organization-wide use of the Digital Oilfield systems are realized, consolidated, and technically ed.

• Works directly with the CEO and CFO to ensure that the company metrics and scorecards for measuring results of the system implementation are in place.

• DOF Implementation duties of the Chief Financial Officer (CFO)

• Works with the CEO to understand and document the economics of the Digital Oilfield initiative. Ensures that the CEO and COO know at all times the anticipated costs and benefits of the Digital Oilfield initiative as it is unfolding.

• Requires that the business rationale for Digital Oilfield be as tight and realistic as possible to protect against euphoria.

• Leader in getting business metrics in place to measure the results of the Digital Oilfield initiative, including measurements that allow visibility of progress toward the specific business goals.

• Assisting the CEO with the resourcing needed to get the Digital Oilfield initiative completed.

• Works with the CEO and Human Resources Officer to ensure that monetary incentives are in place to adequately motivate key organization for Digital Oilfield success.

• DOF Implementation Duties of the Chief Human Resources Officer (CHRO)

• Works with the COO and CIO to target processes and upstream systems that are related to employee transactions.

• Works with the COO in aligning employee performance management systems to focus on work processes impacted by DOF deployment as well as changes in incentive compensation criteria.

• Works directly with the COO to ensure that Digital Oilfield Deployment issues that impact employees are identified and worked through.

• Leader in Identifying the worker competencies needed for the use of Digital Oilfield systems and in providing the training employees will need to develop those competencies

• Assists the COO in dealing with performance issues associated with workers who are unwilling and/or unable to align with the Digital Oilfield systems.

Are these DOF implementation duties too much to ask of senior management? Hardly … if the future of the company depends on staying competitive in today’s rat race of a market, taking on the DOF duties is the least they can do. You will never know what to expect from the seniors in the way of until you see how they will react when you put these IT implementation requirements, their digital duties, in front of them.

CHAPTER NINETEEN

Who Does What for Digital Oilfield Value

The key factor in gaining maximum business value from DOF technology is not the software’s power but the way the entire organization is configured and led. Today’s organizations have a choice, continuing a pattern of trial and error until DOF initiatives finally lead to business value or taking what is known about implementing technologies and putting that knowledge to work now. Doing it now, however, will take real leadership to achieve success.

Business Value Architecture Applied at all Organizational Levels

WHO MUST DO what? Who must be competent and participate in a company’s DOF Business Value Architecture? Which levels of the organization are critical in the understanding and use of BVA to gain max value from DOF technology? The answer, as expected, is that all organizational levels and all key players have a role in the use of DOF for full business value.

• What Executive Management must know and do

• Executive Management must take a stronger role in implementing DOF technology than they take in implementing other technical innovations.

• Since DOF sounds like and looks like IT, top management must be aware of extra obstacles associated with IT … namely the assumptions that IT projects

will automatically implement themselves or that the organization’s technical side will handle implementation for operations.

• Executive management must not leave the impression that applying DOF technology is optional. Executive management must assess the value of DOF to their business and then make DOF implementation a priority.

• Executive management must DOF exploitation with real investment in time and resources as well as by providing direct incentives to employees who gain business value for the company through DOF technology.

• What Operations Management must know and do

• Operations managers cannot wait for DOF to come to them. They must take the initiative to use emerging DOF technology for business value … just as they currently take advantage of down hole steering technology and innovations.

• Operations managers must become masters of their own workflows and process architectures … and know the exact location of business value leverage points.

• Operations managers must take charge of any and all performance improvements to be made in their organization’s work processes, not hand off a business improvement opportunity to the technical organization or a technical vendor.

• Operations managers must be able to pinpoint performance requirements for their processes, not just respond to a “requirements survey” from the technical departments nor should they attempt to specify the exact technology to meet needs.

• Operations must assign high-potential, highly-credible personnel to lead business improvement opportunities and to personally interface with the technical side of the company.

• What Technical Management must know and do

• Technical management must see themselves in the business of “enabling operational work processes to achieve business value,” not as in the “IT business.”

• Technical management will need to be able to field a team of “qualified players” who can the credibility test (i.e., the “Do you know this industry?” test) that will always be given by the operational people.

• Technical management must position their “best and brightest” in the interface between technical and operational management.

• Technical personnel in the interface must understand operational processes so well that they can “discern” operational needs, rather than just asking operations about what their needs might be.

• Technical management must be able to select DOF vendors who have the right stuff to provide A to Z services in the three-way DOF game that will be comprised of Operations, Technical Management and Lead Vendor.

• What DOF Vendors must know and do

• First and foremost, DOF vendors must be able to interface both with the technical part of their client’s organization as well as with the client’s operational organization.

• Vendors must be able to field a team of “qualified players” who can the credibility test that will always be given by the client’s operational people.

• Vendors must have first-hand knowledge of a client’s operational processes to be able to validate requirements being served up by the client’s technical organization.

• Vendors must know client work process architectures and not count on just responding to requirements statements from the client’s technical organization.

• Vendors must be able to provide client “all the way to the bank” (i.e., all the way from A to Z). Not only must vendors be able to the client’s technical operations but be able to advise their clients about all aspects of Business Value Architecture.

• Vendors must be able to help their clients in both

1. “preparing DOF technical systems for the client organizations” as well as in 2. “preparing the client organization for use of the technical systems.”

• What DOF Technical Professionals must know and do

• Technical professionals must see the potential business value of the Digital Oilfield and work for it, not against it.

• Technical professionals, whether of upstream organizations or of technical vendor organizations, must understand and be competent in BVA as well as their own technical specialty.

• DOF Pros must be mindful that “Science with business in mind is not science … while Engineering without business in mind is not engineering.” Today’s technical professionals can no longer focus on only their technical specialties and functions, but must be able to understand and act in business processes that translate technology into business value.

The key factor in gaining maximum business value from DOF technology is not the software’s power but the way the entire organization is configured and led. Today’s organizations have a choice, continuing a pattern of trial and error until DOF initiatives finally lead to business value or taking what is known about implementing technologies and putting that knowledge to work now. Doing it now, however, will take real leadership to first install the DOF Business Value Architecture and then to achieve success.

CHAPTER TWENTY

Go-No-Go Criteria for DOF Implementation

The decision to go forward with a business improvement opportunity is a technical one that is dependent on technical factors. The three factors described in this chapter are powerful, but frequently ignored, determinants of DOF success. Ignore these factors at your own peril.

IN EVEN THE best technical implementations of DOF technology, outcomes can be less successful than anticipated. Sometimes management makes a decision to move forward with a new technology even though the implementation methodology has not been clearly thought through. Thus, to coin a word, they may make a decision to implement an “un-implementable” technology. This outcome obviously produces little more than a waste of the company’s time and money, with nothing useful having been put into motion for the organization’s benefit.

Three major criteria should be used to make the decision about what to do with a potential business improvement opportunity that might be enabled by DOF. Two criteria are tagged as “new” because their value has previously flown under the radar:

1. Technical assessment of the DOF technology for proposed utilization in a specific business improvement opportunity

2. New: Technical assessment of the Implementation method that will be

utilized to get new DOF technology into day-to-day use in an organization

3. New: Implementation probability: the economic pro forma (or business case) based on the relevant implementation time function (i.e., rampup of utilization over time) that is determined by top management’s decision to “deploy by date certain” or to “give permission to adopt and implement.”

The upshot is that when companies prepare to make a decision about a DOF opportunity, leveraging these three criteria will best help them. Then, once the decision is made, it should be clearly and formally communicated without exception to all affected employees within the organization to ensure success.

1. Technical Assessment of DOF Technology

On the first criterion, technical assessment of the DOF technology, the salient point is that most companies of any size are not wondering how to make such decisions. They already have a way of evaluating and making decisions about the quality of new technology; they have specific procedures for bringing new technologies to the table for discussion, evaluation, and selection. Additionally, they have technical experts who are accomplished at this entire process. The point is that these technical assessment capabilities should be rigorously applied in the evaluation of any candidate DOF technology.

2. Technical Assessment of Implementation Method

Beyond the first criterion, however, new perspectives have emerged and proven their merit in the energy industry beginning with the second criterion, technical assessment of the implementation method. A red flag should pop up for

management because today this particular technical assessment is not made at a detailed or robust level by most companies’ management. Specifically, implementation is not handled like the rigorous technical assessment conducted on the technology itself although it certainly should be.

Why? One of the problems which happens too often in the field is literally the lack of implementation detail available for decision-making, hence an obstacle to new technology adoption. Instead, the scenario which unfolds is that the individual describing the new technology is typically unable – in lieu of a detailed implementation methodology – to provide end-s an accurate picture of exactly how the technology will be installed and integrated into day-to-day operations and how all the various risks to business interruption will be addressed in detail.

In these situations, outcomes can be less successful than anticipated. Sometimes management makes a decision to move forward with a new technology even though the implementation methodology has not been clearly thought through. Thus, to repeat a word, they may make a decision to implement an “unimplementable” technology. This outcome obviously produces little more than a waste of the company’s time and money, with nothing useful having been put into motion for the organization’s benefit.

Look at a real-world example. Say a major U.S. airline wants to expand its fleet. Realistically, they only have two supplier alternatives: a major U.S. manufacturer or their European competitor. When analyzing two competing manufacturers, airline management will likely not find major differences in size, shape, fuel economy or other major aspects of the offered aircraft. Therefore, they usually make their selection not based on the airplane itself but on which of the two manufacturers will best help the airline integrate the airplane into day-today operations.

Essentially, airplane selection boils down to conducting a highly detailed

examination of the implementation methodology. In some cases that calls for more detail and more calculation than required for the aircraft part of the selection process. As part of the implementation evaluation, implementation should be simulated so that potential s can best understand what is required to actually get the new technology on board and integrated into the operations of the company.

This is no different than what a software salesman does when conducting demos of new releases so that s can see what the software will look like, with all its “bells & whistles,” once it’s up and running. Applying that concept to new DOF technology, management needs to see a demo of the process of implementation of new technology to visualize what the time and resource requirements will be. To provide some perspective, integration of new technology into day-to-day operations usually takes months, not days, and FTE man-months, not just the number of people involved.

Using the airplane analogy, management needs to be able to see how a technology implementation will be done. The following key questions should be considered:

• how maintenance procedures will be written and implemented to fit new airplanes, • what training will be required of pilots, mechanics and other personnel, • what adjustments to facilities will be needed … • with all this folded into a simulation.

Again, the purpose is to best position companies for making optimal decisions about the implementation process for new DOF technology.

3. Economic Pro Forma or Business Case

In the third criterion, companies need to have an economic pro forma or business case that builds relevant implementation probabilities into it. Frequently, business cases for new technology are built on the faulty premise that when a new technology is “up and running” on desktops and laptops throughout an energy company, “utilization by everyone occurs by magic.” Supposedly, there will be a rapid pick-up of the new technology by all employees whereby they can immediately accomplish all the tasks intended for the newly-installed tool.

Unfortunately, as demonstrated repeatedly at companies, that is a heroic assumption. The reality is that the utilization rate, or pick-up on the new technology, has been all over the map for most companies. Pick-up probability is dramatically different for the two most common cases. Case one occurs when the company makes the formal decision to deploy the technology organization-wide with a date-certain implementation that holds managers able. It means that with explicit top management deployment decisions, a high utilization rate (up to 90%) usually occurs at the “go live” of the new technology, quickly surging to 100% or full utilization as the final stragglers overcome their individual obstacles and get on board.

The second case occurs when the company does no more than give permission for new technology adoption at s’ own discretion and timetable. That approach results in a very different utilization curve. For voluntary adoptions, usage begins at an alarmingly low rate of about 20% of s volunteering to use the new technology as soon as it is available. Gradually other s come online, with the painstakingly slow (2-3 years) pick-up by most of the remaining 80%. With the latter there is even a caveat that in too many instances the likelihood is substantial that a remaining 10-20% will never voluntarily pick up the new technology.

When companies are contemplating employing new technology in the field, they need to build one of those two distributions into the economics of their case for change. In other words, consider the following:

• What will be the business value of the new technology if management formally makes the decision to implement new technology by date-certain?

• What will the business value be if management opts to allow voluntary adoption of new technology throughout the organization?

With the three key criteria covered – technical, implementation and economic – the next step should never be underestimated. That is, once management makes the decision to deploy by date certain or to encourage voluntary adoption, this decision must be clearly and explicitly communicated to all potential s and technology providers. Thereby, the company is stating emphatically that through proven methods, they have determined the new technology is good and beneficial for the company and, therefore, will be deployed as the new standard for doing business worldwide … or that the technology has real merit and should be considered for adoption by all s.

Conclusion

Many energy companies are unnecessarily re-inventing the implementation wheel by not connecting the existing dots in integrating new technology. For all that may be said, the integration of new DOF technology is not a mysterious UFO, but a known process in the world of big technology.

Anecdotes abound throughout the energy industry about new DOF technology

launches that fizzled or outright flopped. While these make colorful cocktail banter, think about the time and money this costs companies. When that hard fact hits home, forward-looking company management should decide to take an implementation page from the expert body of knowledge for dramatically better results.

CHAPTER TWENTY ONE

The Leadership Last Stand

Business Value Architecture assumes that the professional personnel involved in performance improvements enabled by technology will all go along with the plan. But, alas, every company and every architecture invariably contains some resisters. If the resisters could possibly make a contribution to business success, you might try the three tactics in this chapter before you ask for resignations.

BEFORE YOU GIVE up, you might want to try what we call the “here-to-fore unpublished Secret Weapons of the effective change leader.” The Secret Weapons are actually direct messages, carefully designed for one-on-one, eyeball-to-eyeball delivery to one or more individuals, who have distinguished themselves in the DOF implementation project by their total blindness and/or disregard for what is going on around them.

Sometimes all the great methods and tools for change engineering, change management, organizational re-alignment, and operational integration just don’t work. You may have tried as hard as you can to make successful implementation happen, but sometimes things don’t seem to work out with some folks.

The truth of the matter is that at its heart, an organizational change like a DOF implementation is “a sport.” Or as another veteran of technology insertions said, “You just have to face the fact that there is going to be trench warfare with some of these clowns.” (He was, by the way, speaking of experienced professionals with all sorts of initials after their names.)

Let’s say that you have been charged to lead technology implementation in your part of the business. With some of the managers and employees, you feel like you have hit a brick wall. The communications about the new way of doing business have been repeated and repeated. The work processes have been altered to fit with the new software application. Everybody has been trained in the new software as well as how to use it in the altered work processes. Their job descriptions have even been altered to reflect the new way of doing business. Still there is this handful of scattered folks who are problems.

There are no real surprises in the three weapons that follow. They all come to mind automatically to the dedicated change leader in the thick of any technology insertion. The surprise is that we suggest you say them out loud. Normally, however, the change leader keeps them unspoken; he thinks the thoughts, then bites his tongue, and puts on his smiling game face.

Our goal is to encourage the leader to say those thoughts out loud … to make effective change happen for the organization. The messages are naturally designed to destabilize the current situation, serve as a warning, a kick in the butt, a jolt and a jar. The messages are designed to remove obstacles that have so far been unscathed by conventional change leadership approaches. In addition, delivering these verbal weapons will just feel good. No more Mr./Ms. Indirect, say what needs to be said!

1. “Get over it!”

The two energy service organizations had been merged for almost a year. All the legal paperwork was behind them, all the signs and stationery as well as product catalogs and web sites had been adjusted to the one new-company name. Customers were starting to react positively, things were moving forward … except for one senior manager who continued to whine about the fact that now he was required to work with another senior manager who had been his most fierce competitor before the merger. What’s more, he was being asked to use a

business software application that came along with the other company. Whine, complain, delay, mumble, grumble, ad nausea. Sound familiar?

Finally, after hearing both second- and third-hand about another whining tirade, the CEO had enough. He had already had more than a half dozen motivational and inspirational sessions with Mr. Whine to catalog the positive reasons for the merger, the necessity to use the software, and to sing “There’s going to be a morning after!”

Enough was enough. The CEO made a surprise visit to Mr. Whine and after taking a chair said, “I gather you are still not comfortable with this merger.” The surprised Mr. Whine said that, in fact, was true.

“Well then, get over it!” said the CEO as he stood to walk out of the office without another word or a glance over his shoulder. And you know what? Mr. Whine got over it … that very day! Sooner or later we all just have to get over some things and get on with business … and life!

The message to the implementing organization is that “we (our company) has made a considered decision, after tons of input from multiple levels, to implement systems that will give us real-time data on a 24/7 basis. We are going to use that data to make better production decisions, starting now. If you have lingering hard feelings, get over them!”

2. “Oh, Balderdash!”

The world-renowned geoscientist was well into his third page of reading me the reasons why not one iota of his operating methods could be changed to

incorporate a five-second entry in a new information system … lest his personal quest to solve the mysteries of the known and unknown universes be hopelessly and forever dashed. I could feel my internal pressure building after yet another detailed, but stupid, rationalization on the part of this imminent professional who just plain didn’t want to be bothered with any duties associated with ing the very company that housed, fed, funded, and coddled him.

I set my feet firmly, looked deep into his eyes to signal my turn to talk, waited a second or two longer than expected, smiled, and then said, “Oh, Balderdash!”

I cannot tell you how good it felt, nor can I adequately describe the look on his face as he processed my unthinkable comment from hell. I continued, “Everybody knows that the five second data entry requirement will not affect a darn thing.” And I just turned and walked away, leaving him to examine exactly where he stood in light of my surprising, direct evaluation.

3. “Your move.”

Jane was bending my ear for the third time in a week, going on and on about how the latest change in work processes was not ideal from where she stood. It just wasn’t the optimum way she had been taught to handle gas lift calculations. Yes, she understood that the work re-design and the new software were initiated to meet specific business needs, and she understood that everybody’s opinions in the department had been heard and evaluated as well as used in the new design. She finally ended her latest harangue with a look that said to me, “So what do you think of that?”

I looked at her, smiled and said, “Your move.”

“Your move?” she said, “What kind of answer is that? What do you mean, my move?” I said, “It means, your move. The company and I have done all we can do to describe the change that we will be making next week. Now it’s your move. us, please; or leave us, please. But, please, no more harangues. It’s your move. The ball is in your court.”

Sometimes we have to help people see the need to make a choice from among limited alternatives. They must either sign up to go forward with the organization or make another choice that suits them best. Staying in the current job and complaining about it is just not an option in today’s world of fast-paced change. “But she is just too important to lose,” you say. “Oh Balderdash!”

Now tell me you haven’t said all of these messages to yourself. Most of us have, and now may be the time to bring those messages out in the open and use them as the secret weapons they can be. Don’t bring them out like the exasperated parent: with stone-cold eyes, a rock-hard face, an aggressive body stance, or a “you are about to die” look. Instead use warm eyes, your smiling face, an informal stance, open hands; deliver with care for the individual, the organization, and yourself.

Now just in case you think this has all been written tongue in cheek, consider a hard-nosed fact about change leadership: you will probably never lead a successful change in organizational behavior until you personally acknowledge that your behavior is likely to be a big part of the change equation. That’s a truth. So as a final shot, please consider the times when you may need to use any or all of the Secret Weapons on yourself. Yep, standing up, looking into the mirror, and letting fly the message(s) that you need to hear to get on with your part of the implementation!

Unfortunately, these secret weapons won’t always work. Not everybody resisting change can be recovered … but you may be surprised at how many you can save, and how better the organization will look on you as the leader with the guts

to say it like it is. Try it, you’ll feel much better about yourself!!

CHAPTER TWENTY TWO

The Sweet Spot for DOF Professionals

Upstream professionals have a choice to make about the Digital Oilfield (DOF) movement. This movement will clearly be a part of the upstream work environment for the foreseeable future. Upstream professionals may want to decide how they will contribute to the movement since their future work will be impacted by DOF-enabled business improvements aimed at maximizing value for the company.

Everybody into the Pool!

OBVIOUSLY THE DIGITAL Oilfield (DOF) era has started. Who could miss it? And it will be around as long as companies focus more on maturing their organizations and taking advantage of any and all ways of improving the bottom line. It’s almost like a line from the movies, “Everybody into the Pool!” And everybody means all upstream professionals will need to get into the DOF pool.

So if all the upstream professionals are in the water, what stroke do they use to make the most progress in swimming? They could use a variety of strokes: the aggressive overhand, the dramatic backstroke or maybe just treading water. It is clearly an important decision to make for the swimmer … and it is an important decision for upstream professionals to make as well. How will they swim or posture themselves in the DOF movement?

A Decision Framework for DOF Positioning

A simple framework for positioning can be constructed with only two variables: “degree of participation in the details of implementing DOF for business value” and “degree of ownership felt for DOF-enabled improvements in the organization.”

Participation simply means getting in and getting one’s hands dirty with the hard work of making improvements for business value. More specifically, participation means taking part in

• identification of business improvements that could increase business value, • contributing to the design of such business improvements, • interfacing with technical professionals who can bring an appropriate DOF technology to enable all, or parts of, the business improvement, and • leading the operations organization to fully implement the DOF-enabled improvement to increase business value.

Ownership, the second dimension for the posturing framework, is less an action and more of a feeling. Ownership simply means the feeling that the improvements the pro is working on are really his, holding a personal place in his heart and mind. Ownership must be tied to the business value that can be gained through a DOF-enabled improvement, not tied to either the seductiveness of the technology or the elegance of the newly-designed work process.

Combining the two variables of participation and ownership produces a simple framework. Each cell is designed to communicate a dominant action or idea that might be the theme in a professional’s contribution to DOF.

Fortunately other industries have struggled through the process of recognizing the value of a new technology and the hard work of bringing the power of new technology to bear on business improvements designed to increase shareholder value.

• Upstream Professionals working in the DOF Sweet Spot

How does someone in this position talk and act? Sweet spot pros are eager beavers willing to give new things a try and willing to spend time in learning, experimenting, failing and succeeding in using new DOF technology and solutions. Expect the sweet spot pro to be the volunteer or otherwise obvious leader of business improvement projects enabled by the new DOF technology.

Upper management sees a professional working in the new technology sweet spot as pro-active, helpful, loyal, aligned, and ive of organizational directions and strategies. Upper management is almost always appreciative of the time and effort this professional is spending on trying to incorporate new ideas into business improvements.

For industries in which technology is a key factor of production, professionals who work in the sweet spot have the very best chances of personal success in the organization. Tomorrow’s leaders are almost always selected from the population of sweet spot professionals who can apply the most important technologies to increase business value.

The kind of work done in the sweet spot is different for each organizational level or role. Short descriptions are below:

• The Executive Sweet Spot: Executives are responsible for putting the elements of DOF Business Value Architecture into place … as well as for visible and explicit DOF leadership.

• The Operations Management Sweet Spot: Operations Managers must take the lead in DOF innovation and performance improvement … understanding their own work processes and pointing out leverage points for DOF application.

• The Technology Manager Sweet Spot: Technical Management must know operational processes like “the backs of their hands” and be able to bring technologies to bear on operational leverage points.

• The DOF Vendor’s Sweet Spot: DOF vendors must their clients all the way to the bank … providing technical and advisory services until their clients realize business value from DOF technology.

• The Technical Professional’s Sweet Spot: If DOF technical professionals cannot “make money for their company” through their technical disciplines, then they are not masters of their disciplines.

• Upstream Professionals as ive Investors

The DOF ive investor that can talk the DOF talk but chooses not to walk the DOF walk is likely to be ive of DOF initiatives, but not to the level of getting his hands dirty in the details or designs of business improvements.

Upper management can see both positives and negatives of this positioning, looking at the professional as ive but not someone to be counted on to resolve technical details of a DOF-enabled business improvement. Will they be looked at as one of the “good guys?” Yes. Will they be looked at as “real gogetters?” No.

Pros who take this position with regard to a new technology are not likely to lose their jobs over their unwillingness to roll up their sleeves. But they also are not likely to be promoted to important positions as fast as professionals operating from their sweet spots.

• Upstream Professionals with a Vendor/Contractor Mentality

This professional is very interested in the technology for technology’s sake, but is not tuned into the business consequences of using the DOF technology to improve business results. His day-to-day actions are likely energized by the technology’s glamour or by the vendor’s siren song rather than by the opportunity to connect technology to the company’s bottom line.

Upper-level managers spot this pro easily because of his focus on the situation’s technology aspects rather than on any of the business implications. While the boss almost always asks if this professional is on the problem-solving team to apply his technical skills and interest, the boss almost never invites this professional into the heart of business decision-making for operations.

The contractor mentality professional who really likes the technology may be shunted off into the technical organization or become the leader of a shadow technology organization inside operations. In either case, the positioning will not

take the professional up the organizational ladder. Regardless of the level of interest and skills in the new technology, the lack of linkage to business results will be a continual promotion obstacle.

• Upstream Professionals as Ponies that have run out of tricks

While this professional may be very interested and deeply involved in the upstream business, she will be missing in action when the conversation turns to utilizing DOF technology to enable business improvements. Whether a feeling that “this too will ” or a lack of comfort with the idea of digital technologies (i.e., computers), the result is the same, an aversion to the notion of DOF.

Upper management can spot aversion in a heartbeat, and they cannot afford to tolerate it for long. If use of a new technology like DOF has become a company strategy, these bosses will only look at averting professionals as one-trick ponies, ultimately burdens on the organization.

Professionals who take an averting position to the implementation of any important technology are living on borrowed time. Survival in the short run may not be a problem, but long-term survival as a vital member of the organization is not likely.

DOF will be a continuous opportunity for making upstream organizations better businesses. Despite diversions of attention like the latest technology, DOF will still be available to help increase earnings and cash flow. of upstream organizations will need to take a stand on how they will contribute to the use of DOF-enabled business improvements to improve business results. The time to choose is now.

CHAPTER TWENTY THREE

Big Ideas for DOF Implementation

This chapter contains twelve “big Ideas” that can improve the implementation of Digital Oilfield technology projects. There is no longer any reason for DOF implementations to be so difficult and to have such a high failure rate. The ideas that can make implementations successful are available today in practical form.

THE GOAL OF this chapter is to highlight what we consider “big Ideas” that will drive overall DOF implementation success. You might consider this chapter as one of the summary chapters of this book.

1. Need for a concrete DOF strategy

Simply making strategy pronouncements such as “… by the way, we might be using some Digital Oilfield (DOF) ideas / innovations to improve our upstream operations” will not get the job done. Instead, DOF strategy statements must fit the overall business strategy and have specific intentions: e.g., to use down-hole sensors connected to data management software to enable real-time decision making about well production.

2. Business value is totally dependent on implementation effectiveness

Business value only results when business personnel fully utilize the DOF application in day-to-day job performance. And utilization depends on quality of

implementation.

Business Value = Quality of DOF App X Quality of Implementation

If either part of this equation is zero, business value will be zero. Today’s common practice of focusing almost entirely on the quality of the technical application will prevent business value from ever occurring for lack of effective implementation.

3. Treat DOF system/application like any other corporate asset

Work to ensure that a DOF application is treated like any other corporate asset that we expect to be developed and used to make money for the company. Easier said than done for innovations that are flavored with IT, companies generally do not treat an investment in such DOF apps in the same way they treat investments in hard assets. For example, if a company builds a new platform costing millions, everyone automatically assumes the company needs to be fully ready to make money with that platform when it “goes on line.” Not so for an IT investment. Without a specific message from top management to use the IT asset to make money for the company from the moment it “goes live,” expect business s to assume that the DOF IT asset is optional. Go figure.

4. How Implementation fits between innovation and business results

DOF is driven by innovation which produces functionality that must be implemented into the business to produce results. However, the quality of the implementation process must match the complexity and sophistication of both the innovation and the operations units receiving the innovation.

In short, take a complex innovation and turn it into a complex DOF application, use an unsophisticated and invalid implementation process to integrate it into a complex and sophisticated business operation … and expect failure. Imagine Boeing building a new 787 aircraft, parking it on the ramp and telling the purchasing airline to come get it … “We built it, you figure out how to fly it … and maintain it.” P.S. Boeing spends as much money on integrating the aircraft into an airline’s fleet as it does building the aircraft.

5. Portfolio management: the key linkage between strategy and business results

A mature Portfolio Management process is required at an organization’s senior level to ensure selection of the right number or type of DOF projects for development and implementation. Since a company cannot work on every DOF idea, Portfolio Management is necessary to direct resources to those DOF ideas / projects following the DOF strategy and best fulfilling the company’s business vision

6. Two very different implementations: deployment vs. permission to adopt

While the word deployment in a general sense may mean getting a DOF application into play, more specific definitions are called for in the DOF arena. Deployment more specifically means “a required use of the DOF app by all parties by a date certain.” An adoption, on the other hand, means that “s may choose if and when the DOF application will be used” in their business.

For proper deployment, expect almost all s to be ready to put the technology into play at the moment the application is available. For adoption, expect only a

small number of s to volunteer initially to try the DOF technology, with most other s opting to try the technology over a period of years (and some s electing never to use it). Effective implementation of either type requires a firm, explicit decision communicated from top management to either deploy or give permission to adopt. If management fails to name one or the other, s will automatically conclude that using the DOF technology is optional.

7. How change management fits into implementation: system and business readiness

Two separate but interdependent tasks are required for DOF implementation success: the DOF technology must be made ready for use in the business and the business organization must be made ready to fully utilize the DOF technology. These two tasks require very different skills and competencies, and the tasks must be managed in two distinct project organizations.

8. Essence of Change Management

In its most simple form, change management literally means “ensuring the business work processes and people are aligned and in sync with the DOF technology being implemented.” Change management (or change engineering) is a formal body of knowledge dealing with the organizational mechanical changes necessary to incorporate a new technology into the business. Far beyond today’s street definition of change management as “lots of communication and soft stuff,” change management includes the hard mechanical decisions and alterations necessary for the organization to be more productive business-wise by using the new technology.

9. Deployment: How to do it… engineering organizational change

Deployment depends on certain mechanical actions being taken by management to ensure the DOF technology will be implemented and utilized on target, ontime, and on-budget. The specific mechanical actions required are part of a deployment formula (certain number of steps, all of which are required for implementation to occur). Failure to follow each step will prevent a successful implementation of the DOF technology.

10. Adoption: How to do it

The adoption process as applicable in an optional DOF implementation has been studied for decades in “diffusion of innovation” literature. How an innovation travels voluntarily through a population of potential adopters has been well studied and clear, definitive actions have been tested to be a positive influence on adoption speed. But adoption remains voluntary and depends largely on each ’s propensity to adopt very early, very late or any point in between.

Managing an adoption is not at all about “high pressure selling” but more about ensuring that early volunteer adopters mix with non-adopters to spread the word and let non-adopters decide for themselves whether they want to try the innovation. Not surprisingly, spreading of the innovation through an adoption process is relatively slow (years!) and somewhat unpredictable.

11. Strong project management: An indispensable part of DOF implementation success

A DOF Project Manager (PM) must have the authority to make virtually all decisions within boundary conditions set by the Sponsor’s project objectives. That is, the PM should be empowered to define project scope, plan project

activities and spend the budget to accomplish the business objectives. In this sense, the PM has been provided the opportunity to be strong.

However, this means being a leader, not an autocrat, by taking in his team’s views and respecting their skills, knowledge and insight. Yet, since a project team is not a democracy, the PM must make decisions based on his expertise combined with the expertise of his team. Ultimately, the DOF PM must have the maneuverability to do his job with upper management providing oversight without micro-managing.

12. Defining, creating, and maintaining the DOF culture

Whether formalized or not, an organization’s culture is “the way we do things around here.” An organization’s culture must have certain attributes to enable full value from DOF technology. For example, a DOF culture might include “high levels of collaboration, data-based analysis, and speedy decision processes.” If a company is missing those three dimensions of culture, they need to act quickly and aggressively to change that situation.

Creating a DOF culture begins by establishing culture expectations at three levels: executive, senior management and technical professional. Then action steps must be taken, based on rewards, to achieve the desired DOF culture. These are: identify at all levels the desired culture to leverage DOF potential, tools and applications; identify changes necessary; treat the culture change as a project; and hold managers able.

In this chapter we have highlighted what we consider to be the “big Ideas” that will drive overall DOF implementation success. Consider this chapter as a checklist to cross-check the DOF initiatives in your organization.

CHAPTER TWENTY FOUR

Integrated Risk Management for the Digital Oilfield

Documented failures of big IT system implementations rarely point to a single cause. Too often the mentioned causes go beyond what we might call technical glitches to problems with botched training, excessive resistance to change, lack of interest/, failures to communicate, etc. The failure record clearly calls for proactive, formal risk management programs that integrate technical, organizational, and business risk mitigation efforts.

NEW INFORMATION TECHNOLOGY can promise and deliver important business results in today’s challenging government and business environment. While the benefits of many new systems have proven to be big for many organizations, the implementation of such systems continues to be a risky proposition. The size of the risk, which can run into the tens of millions of dollars for new systems or into hundreds of millions for potential disruption to the organization or to its customers, calls for aggressive and systematic risk management to ensure success. Risk management must handle three major, integrated risk categories:

• Technical risk - will the implemented system work? • Organizational risk - will the organization use the system? • Business risk – if the system works and is used, will the system produce desired business results?

Unfortunately, integrated risk management is a tall order for many of today’s

organizations that focus on technical issue resolution alone while leaving organizational and business risks to chance. Today’s message is very clear: plan to assess and mitigate all three kinds of risks effectively … or keep what you have in the way of systems and business processes. Moving ahead without managing all three risks is a certain recipe for organizational disruption and even disaster.

Figure 23.1: Integrated Risk Management

Managing Technical Risk … The First Step to Success

Companies and technical vendors have been doing high-quality risk management for decades. But most of the risks that have been managed are what we call the technical risks of the implementation project. The best layman’s definition of the technical risk is associated with the critical questions − will the system work, will it work on time, and will it come in on budget? This kind of technical risk, while occasionally mismanaged, is usually handled quite well by a combination of the organization’s IT professionals and technology vendors.

The primary approaches for mitigating Technical Risk fall into three general categories:

1. Formation of a technical project that will focus on the delivery of the technical system only. The scope of the project should be minimized to ensure technical delivery.

2. Rigorous project management must be used to ensure that the technical delivery of the system comes in on target, on time and on budget.

3. Use of systematic processes to keep s informed and in-the-loop. Business organizations must understand where technical implementation is at all times, so that they can adequately prepare to use the new system to do the work of the organization.

Managing Organizational and Business Risk … The Keys to Success

However, for really big, comprehensive technical systems, other kinds of risks must be equally well managed for the implementing organization to get what they are looking for. The two most critical risks are what we call Organizational and Business Risks.

• Organizational Risk

By Organizational Risk, we mean the chance the organization will not fully use the new system or, in some documented cases, not use the system at all. Failure to use the new system could be caused by a number of factors − one of the most common and deadly factors is “failure to prepare the workforce for the change.”

The primary approach to mitigating Organizational Risk is the systematic and comprehensive use of change management to ensure that the organization will be positioned to use the new system after technical installation. Change management is the body of knowledge that is used to ensure that a complex change, like that associated with a big system, gets the right results, in the right timeframe at the right costs. Change management is a disciplined approach applied in the organizational units that will operate the new systems to ensure their acceptance and readiness to use the new system effectively.

The primary approaches for mitigating Organizational Risk fall into three general categories:

1. Formation of preparation projects and using rigorous project management to ensure that business organizations have done all their needed homework to adjust business processes as necessary to align with the technical system soon to be delivered.

2. Comprehensive communication to all employees that covers the business objectives of the DOF system, the reason for change to the new system (including “what’s in it for me”) and the vision of the organization using that new system to do its work.

3. The performance management system of the organization will need to be altered to include role and job descriptions that require the use of the DOF system as a part of the regular work of the organization.

• Business Risk

By Business Risk, we mean the chance the costly-to-implement system will not pay off in “dollars-and-cents” results for the implementing organization. Failure to gain a business outcome could be caused by a number of factors − one of the most commonly-found factors of failure is lack of alignment between processes imbedded in the DOF applications and the organization’s business objectives and priorities.

The primary approaches for mitigating Business Risk fall into three general categories:

1. System selection must be done so that the system selected has not only the integrating efficiencies needed by the company but has the imbedded processes

that the organization will be able to use to get results over the long-term in their specific business environment.

2. Business process translation (or documentation) must be done so that the overall work of the organization as it uses the new system is logical, understandable, and doable by the workforce.

3. work training must be done so that the s will not only be able to operate the DOF system but will be able to use the system correctly in the context of the work that must get done for desired business results.

While the benefits of many new systems have proven to be big for many organizations, the implementation of such systems continues to be a risky proposition. The size of the risk, which can run into the tens of millions of dollars for new systems or into hundreds of millions for potential disruption to the organization or to its customers, calls for aggressive and systematic risk management to ensure success

CHAPTER TWENTY FIVE

The Test for DOF BVA Fatal Flaws

Call this chapter the conclusion of the book. If the fatal flaws noted below are all understandable and seem manageable, then you have gained the real value of this book. Why not rate your organization using the checklist below? Call it a short test to see if Business Value Architecture is being properly set in your organization.

GAINING BUSINESS ADVANTAGE from digital initiatives is hardly a cake walk. Upstream and technical vendors alike are finding DOF initiatives difficult to design, develop, and, especially, implement. Apparently it’s easier said than done.

Where might we turn for guidance in dealing with such difficulties? Most helpful guidance is likely to come from studying technology implementations across industries and across lengthy time periods. Failure mode and effects analysis studies from across industries over the past decades suggest that there are fatal flaws that could be inherent in any such implementation.

A fatal flaw is just what it sounds like, an inherent weakness that could jeopardize the health of an entire initiative. The scary thing about many fatal flaws is that you don’t always know if you have one until it is too late. The best actions to prevent being blind-sided are to (1) value “lessons learned from the past,” and to (2) do exquisitely-detailed planning on the front end of the initiative to avoid the ten common flaws below.

Ten Fatal Flaws

One of our team says that we should look at these fatal flaws as the onset of cancer in an initiative. We better spot the flaws early and treat them aggressively. Fore-warned is fore-armed.

1. Fatal Flaw: Failure to make DOF a part of the formal company strategy

While this flaw may seem like a “no-brainer,” it is amazing to see companies leave it out of the single most important words they have for steering the direction of their company. Believe it or not, some folks inside the company really do consider written strategy statements as the official word. They use those words when they assess and prioritize how they will spend their time and the company’s money. The Acid Test: Is taking advantage of digital technology written down and briefed to the board and to analysts on the street? The answer is either yes or no.

2. Fatal Flaw: Failure to have the needed level of executive commitment to DOF

Most program and project managers beg for indications of executive commitment to a DOF initiative, and most company executives are likely to be tired of hearing about the need for more commitment. What are we missing? The answer is so basic we frequently miss it. If the anticipated business returns from the DOF initative are not included in the company’s financial pro forma for the go live time period, then there is inadequate executive commitment. The Acid Test: Are anticipated returns from the DOF initiative in the pro forma? Yes or no?

3. Fatal Flaw: Failure to have needed incentive structure in place to gain full value from DOF

While many consider goals as the primary steering mechanism for the organization, the truth of the matter is that people pursue incentives first and goals second. Show me an organization that is goal-oriented, and I can likely show you how their incentive structure reinforces the goals that they pursue. What better test than to watch a DOF initiative come to a screeching halt when the innovation is served up for trial to an operations manager whose incentives are based almost entirely on production and the absence of any disruption. The Acid Test: are goals and matching incentives for the use of digital technology a part of all incentive structures from the top levels of the organization down? Yes or no?

4. Fatal Flaw: Failure to have robust portfolio management

Portfolio management is to both pick the best investments for the company’s money and to ensure that the investments turn into business value. While most mature companies have at least a form of portfolio management for capital expenditures, we frequently see potential DOF projects and their advocates struggling for visibility, a fair hearing, toe holds, and executive-level sponsors. Launching a DOF initiative under such circumstances is likely to be a fatal flaw that damages the initiative’s chances of success, as day-to-day business priorities weaken or even gut the initiative. The Acid Test: Does your DOF initiative show up as one of the initiatives on the short list of high priority investments? Yes or no?

5. Fatal Flaw: Failure to make the “Deploy” or the “Permission to Adopt” Decision explicit

We think of “Deploy” as a Decision made by the senior executive to put a DOF solution into play in all relevant parts of the organization by a date certain. Failure to make a Deploy Decision “loud and clear” will result in the organization reading “permission to adopt at our own discretion.” While Deployment can hit a date, permission to adopt is guaranteed to stretch over multiple years, never reaching all parts of the organization. Acid Test: Is your initiative clearly and explicitly described by top management as a Deployment with date certain? Yes or no?

6. Fatal Flaw: Failure to focus the initiative on the business reason and processes

How easy it is to think of a DOF initiative as “an R&D project” or worse yet, “an IT project.” While DOF initiatives almost always start with at least some business goals, how soon we forget and find ourselves considering our initiative very narrowly, as a technical play and not a business improvement, and the problem that follows can be a fatal flaw. As soon as we forget to stay focused on the business rationale for the initiative, we lose business-side feelings of ownership and, therefore, of responsibility. The Acid Test: Is your DOF initiative described solely in of the desired business outcomes? Yes or no?

7. Fatal Flaw: Failure to serve up a fully-tested technical solution

Surely we wouldn’t miss this one, would we? Yes, it is still happening with technology introduced to the customer (operations managers, for example) with all sizes and manner of bugs. Complete testing in as near a combat environment as possible must be completed before operations sees it. Given that operations folks are paid to manage risks to production, showing them something that is not fully developed and tested (and therefore, is risky) can kill the initiative. The Acid Test is whether the technical team can serve up their technical solution along with full and complete test records. Can they? Yes or no?

8. Fatal Flaw: Failure to have a robust Implementation strategy that integrates processes, technology, and people

Until quite recently, the words “implementation” and “robust” were not heard in the same sentence … or conversation. After all, “robust” is a technical term that goes with the hard stuff, the technology … while implementation is soft stuff that can never be tied down enough to be labeled as robust. But as implementations hit brick walls, we have learned that strong (read that “robust”) implementation methods are needed for work processes and people … as well as for technology. The acid test is whether or not there is a formal, integrated work breakdown structure and task list for the DOF initiative that includes concrete action steps for aligning technology, work processes and people systems to meet business objectives. Yes or no.

9. Fatal Flaw: Failure to organize around “Technology Ready” and “Business Ready”

The work to be done in a DOF initiative is clear-cut … the organization needed for implementation is clear cut as well:

• A Business Program Office to manage the creation of business value • A Technical Project organization to prepare the DOF technical system for the organization • An Organizational Readiness Project organization to prepare the operations organization for the use of the technical system

The Acid Test: Does your DOF initiative have three separate organizations linked together under a single operations-side executive? Yes or no.

10. Fatal Flaw: Failure to use a comprehensive risk management process

It is standard practice today to have a formal risk management process as a part of any significant technical initiative. That is good, but managing the technical risks (i.e., will the technical system work?) is not nearly enough. For DOF success, two other categories of risks must be managed: organizational risks (will operations employees use the system?) and business risk (if the system works and if people use it, will the company make money?). The Acid Test: Does your risk management process cover all three of the primary risks? Yes or no?

The Bottom Line: Yes or No?

So how does your initiative score? If you had ten “yes” answers, you seem to be well on the way to success. But if you had just one “no” answer, you just might have a cancer in your Business Value Architecture that will eat its way into or end your business and personal success. Act accordingly.

CONCLUSION

Implementing Digital Oilfield Technology

IMPLEMENTING DIGITAL TECHNOLOGY to help organizations increase business value has been problematic from the beginning. The problem is that business organizations lack the knowledge to take operating applications and put those digital assets to work in the business.

There have been two missing pieces that prevent new assets like Digital Oilfield from going to work:

Managing three Critical Risks: First, digital assets, like DOF technology, do not add business value by themselves. Digital Oilfield technology can only contribute to business value by enabling those business work processes that produce the business value. Those who would implement DOF technology must successfully manage three interdependent risks, two beyond the boundary of IT: technical risk — will the DOF technology work; organizational risk — will the DOF technology be used; and business risk — will the DOF technology make money for the company?

Greasing the skids with Business Value Architecture: Second, business organizations do not automatically reach out and accept new technology with open arms. Those who advocate the use of new DOF technology must work with management to make organizational accommodations for the technology. These accommodations range from naming the DOF technology in top management goal statements — to identifying work processes in the organization that can be improved by DOF technology — to building critical mission and resources interfaces. Enter Business Value Architecture,

a way to “tune the configuration” of the organization to grease the skids for DOF technology. Failure to grease the skids for DOF is likely to result in nothing more than DOF demo projects that go nowhere.

SERVICES … 1 2 3 4

1. CONSULTATION: We offer a one-day consultation on your Digital Oilfield strategy and/or projects. We put two professionals on the ground in your organization for interviews, to review your presentations (if you like) and to present a one-hour “out-brief” describing our observations and suggestions with regard to business value from DOF.

2. DOF SUMMIT MEETING: We offer a two-day summit meeting of your DOF key players, a meeting led by two of our professionals to sort through data we will collect in advance, to clarify and/or confirm DOF strategy/goals/objective, to Identify and discuss the key issues and obstacles to DOF success in your company, and to generate a set of go-forward recommendations to increase business value from DOF. The Keys to a successful DOF Summit will be your choice of participants from operations and the technical side of the house … and our use of critical thinking skills and techniques.

3. ACTION PLANNING: Based on the results of the DOF Summit, we will work with your appointed players to build implementation plans and work packages that are responsive to your go-forward recommendations to increase Business Value from DOF. As you can well imagine, if Step 3 Action Plans are not completed and actions taken in a disciplined way, everybody’s time will have been wasted.

• FAQ: Is this going to be a technology-oriented exercise where acronyms will fly fast and furious?

• ANSWER: No, this will be a business meeting focused on gaining business

value from your company’s investments in DOF.

• FAQ: Will this be an unstructured exercise, or will we have some valid and reliable framework to use?

• ANSWER: We will use two frameworks to guide our work for the summit meeting, we will use

• “Business Value Architecture for DOF™” … a tool that is second to none in Deg a company’s digital energy approach for maximum business value … and

• “Engineering Organizational Change™… a proven guide to implementation of technology systems and organizational change

• FAQ: How will we know that our thinking in this exercise is “sound?”

• ANSWER: While “the proof will always be in the pudding,” we will use the very latest and best critical thinking tools and techniques to make the most of the available data and the collective intelligence / experience of your DOF team.

4. DOF VALUE REALIZATIONS: We offer the disciplines that are needed to get the job done. And there is a mixture of disciplines that it takes to cover a successful DOF implementation. We provider these varied services to the client so that they can do the implementation themselves … with us looking over their shoulders, or we can provider a team that will handle a

lot of the work for them.

• Strategy and Selection - A DOF strategy must be driven by a business strategy that has (1) a high chance of success and (2) strong, visible executive leadership. Holland Management Consulting offers business strategy Development and implementation services, as well as a full management of DOF technology selection processes.

• Executive Advocacy - Almost everyone knows by now that “executive commitment” is needed for implementation success. While commitment is necessary, it is far from enough. Holland Management Consulting has Developed and tested, tight and precise “prescriptions” for executive behavior, for all “C-level execs (CEO, COO, CFO, CTO, and CIO). Holland Management Consulting has the senior, credible people who can influence executive behavior, while providing the executive advocacy required for DOF success.

• Program Management - A technical initiative will have many technical and business “moving parts” or projects that we can drive to completion for business success.

• Project Management - There is no substitute for disciplined project management. We can bring project management methodology, tools, Project Managers, and staff to provider the focus and resources needed for business success.

• Change Engineering - New technology must be engineered into place inside a business organization if business objectives are to be met. We bring SOA (patent pending) methodology experienced leaders and staff to get your job done.

• Team Formation - An effective and efficient team is needed to do the hard work of technology insertion and integration. We provider complete team services: recruitment, selection, chartering, team building, and conflict resolution for the DOF implementation … and teambuilding for the operations team around the new technology.

• Utilization Optimization - The key to meeting the business objectives of a new technology is Full Utilization by the business. We structure technology implementations for 100% utilization at “go live.”

• Innovation Methods - New technology initiatives require huge doses of innovation for effective insertions into a business organization. We bring years of innovation and technology transfer experience to your DOF Initiative.

• Governance - Steering a DOF project is easier said than done with many stakeholders with different business agendas. We provider a “Decision structure” that aligns stakeholders while ensuring that needed Decisions are made on time.

• Risk Management - Inserting of a new technology runs three risks: (1) Will it work? (2) Will people use it? (3) Will it make money for the company? We bring unique risk assessment and mitigation tools and to ensure business success.

• Business Readiness - While new technology is being made ready for the business, the business must be made ready for the technology. We bring our patented Business Readiness methods and tools to ensure readiness on

target, on time, and on budget.

US

Call us directly at 281.657.3366. Our receptionist will put you in touch with a professional who can move the ball for you and your company.

Holland Management Consulting 2700 Post Oak Blvd, S 1400 Houston, TX 77056

1 The moving parts of an organization have been identified by no less than a veritable “who’s who of OD” serving as the Board of Editors of the widelyaccepted Jossey-Bass / Pfeiffer series of books on Organization Development: David Bradford is senior lecturer in Organizational Behavior, Graduate School of Business, Stanford University; W. Warner Burke is Professor of Psychology, Columbia University; Edith Whitfield Seashore is organizational consultant and co-founder of AUNTL Master’s Program in Organization Development; Robert Tannenbaum is emeritus Professor of Development of Human Systems, University of California, Los Angeles; Christopher G. Worley, Director of the MSOD Program at Pepperdine University; and Shaolin Zhang is senior member of Organization Development for Motorola (China) Electronics Ltd.

2 Unfortunately there is no room in this book for a detailed Phase Three roap. However, the detailed road map will be at the heart of a forthcoming book: “Implementing DOF Projects” by Dutch Holland, PhD.