128K-Member-Banner.jpg

Evolution of Business Process Management: A conversation with author Jim Boots

Contributor: Jim Boots
Posted: 09/19/2012
Jim Boots
Rate this: 
Be the first!

Jim Boots still remembers the days at Chevron where processes were stored inside the heads of people and time was wasted creating and conveying information. But since his early days with the company over 30 years ago, new technology and approaches to management have transformed the "process landscape".

In this interview Boots, a former Business Process Management (BPM) advisor at Chevron and author of a new book out called BPM Boots on the Ground, talks about those changes, offers his opinion on what "BPM" actually means and reveals some of the practical lessons he learned about BPM implementation during his 30 plus year career at the oil giant.

Editor’s note: this is a transcript of a podcast interview. Listen to the original interview here: Practical lesson on BPM from Chevron

PEX Network: You’re joining us today to discuss some practical lessons learned from BPM largely based on your experience at Chevron, but I’d like to start the discussion with a bit of a wider context. You had a 30 year long career at Chevron, during which time you witnessed the evolution of the concept of Process Management. What would you say were some of the key changes in approach over that period?

Jim Boots: When I joined Chevron in 1980 most processes were stored in the heads of people and how to do things often relied on the knowledge of experienced workers. Also, a lot of time was spent creating and conveying information. Work got done, but productivity was much lower than it is now. Unfortunately more undesirable incidents such as errors, injuries and mishaps also occurred. By the mid-1980s at Chevron, two important things happened that gave a jolt to process thinking. First, personal computers were heading toward widespread use as a tool that would greatly decrease the cost of producing and conveying information and, second, the Total Quality Management or TQM wave began. TQM led to widespread adoption of process tools such as flow charts, control charts, experimental design and methods for process improvement.

In the 1990s, ERP systems and the discipline of Supply Chain Management changed the process landscape again. ERPs led to the embedding of transactional processes into computer programs and Supply Chain Management led to process thinking about planning processes that required communications in data flow across organizational boundaries. By 2001, a Lean Six Sigma group was producing value and growing at Chevron and a corporate wide Operational Excellence initiative was launched with an expectation of rigorous attention to processes. Both the Lean Six Sigma practice and the Operational Excellence initiative would have a strongly positive impact through the following decade.

The latest pieces of the BPM puzzle at Chevron began coming together with the introduction of commercial BPM software products. Chevron business units and departments are now in various states of maturity with regard to exploitation of such capability building blocks, as I would call them.

PEX Network: So it sounds like the approaches to Process Management have changed quite dramatically in the last 30 years, driven largely by what sounds like technological enhancements?

Jim Boots: To some degree the technology certainly has been important, but I would say just a lot of the ideas and methods, even going back to the 1980s of Total Quality Management, just began seeping into the culture. Over that time, I would say that Chevron’s BPM approach became more and more mature. I’d say there were two key periods of time when technology played a big role. One was with the ERP systems in the 90s and then more recently in the last six, seven, eight years have been the BPM software suites.

PEX Network: We’ve started banding the term Business Process Management around and certainly we hear a lot of different definitions of Business Process Management. Some may define it as automation, others as process mapping, still others maybe something even different. How would you define BPM?

Jim Boots: It’s interesting you should ask this question. I have been working with an international consortium for the past couple of years developing a BPM framework and we recently have been revisiting the definition of BPM. I will state their current definition agreed by our work group, but brace yourself. It’s a rather long sentence, but I’ll go back over it in pieces to make it clear. Here it is. BPM is a capability that identifies, designs, documents, monitors, optimises and assists in the execution of an organisation’s processes by specifying enabling policies, methods, metrics, roles and technologies.

There are three main parts to this definition that can be characterised as what BPM is, what BPM does and how BPM does it. So the first part of the definition is BPM is a capability. In other words BPM is not simply an improvement method, a software system or knowledgeable people. A capability is all those things and more, combined to produce value for the organisation. Only when value is created does a claimed capability become legitimate.

The second part of the definition talks about what the BPM capability does. BPM is a capability that identifies, designs, documents, monitors, optimises and assists in the execution of an organisation’s processes. So BPM is concerned with doing all those activities with respect to processes, identifying, designing, documenting, monitoring, optimising and assisting in their execution.

The third part of the definition talks about how BPM capability is achieved, namely by specifying enabling policies, methods, metrics, roles and technologies. You will need such things, policies, methods, metrics, roles and technologies to make BPM take root and be effective. Needless to say, it is not easy to get all these things right and that is why doing BPM well is challenging and takes time.

Finally, keep in mind what does not represent the totality of BPM. BPM is not just automation and it is not just about technology. It certainly isn’t something that should be confined to the IT department. BPM is not just process improvement projects based on Lean Six Sigma. BPM includes technology and process improvement methodology, but it also includes all the other things that are necessary for deep sustainable capability that makes the activities of the organisation efficient and effective.

PEX Network: Your new book, BPM Boots on the Ground, is based on your practical experience at Chevron. What made you want to write this book?

Jim Boots: Around 2006 I began to understand the full potential of BPM. My estimate is that BPM done well, can increase an organisation’s profits by at least 10%. I saw examples of what was possible in several business units at Chevron, yet it is still hard to get the attention of executives long enough for them to understand and embrace BPMs potential with a multiyear perspective. Writing the book was my way of making the most persuasive argument I could about why executives should embrace BPM while also providing detailed guidance for those who must implement BPM programmes.

In the book there are two chapters that will convey to executives why BPM should be important to them and how they can launch a BPM initiative. Those are chapters two and 13 respectively. The rest of the book contains a level of detail that will be useful for BPM practitioners and organisational change agents.

PEX Network: You once said in an interview that the oil and gas industry is pretty much the opposite end of complexity from, say, something like banking. In banking you have highly repeatable processes, while in oil and gas you have highly complex global supply chains and physical products that you’re extracting in very different environments - not exactly easy candidates for automation. Do you think it was more challenging to apply BPM in the oil and gas industry than, say, it would have been in a different kind of business?

Jim Boots: That’s a good question. It’s not so much that applying BPM in the oil and gas industry is more challenging than other industries, but there is a different emphasis. The most challenging part of implementation in any organisation, I think, has to do with the behaviours of management in managing the required cultural change. That is true in oil and gas as well as in banking, pharmaceuticals, government services or almost any industry. What is complex about oil and gas from a process perspective is that the process starts with variable inputs, variable inputs scattered underneath the planet’s surface. Petroleum companies must go where the petroleum is. That means working with different governments and cultures and extracting whatever strange mixes of petroleum laden materials that happen to be under the ground or sea 24 hours a day and more or less 365 days a year. After that, inherently dangerous products must be safely transported, refined and sold.

From a process standpoint it is a much different world than the computerised transactions that represent the preponderance of consumer banking processes. Even other manufacturing industries such as automotive, home goods or pharmaceuticals start with much more consistent inputs than the oil and gas industry. Perhaps because of the physical complexity, the oil and gas industry naturally needs to pay close attention to processes in which humans interact with the indigenous environment. That doesn’t mean that automation is unimportant in oil and gas. In fact, automation has great potential for all oil and gas companies, but the critical human processes will be the processes that probably get attention first.

In a bank it is more likely that a manager can get the human operational processes squared away fairly quickly and then address how to automate routine information flows. But even banks are likely to have management processes such as business planning and portfolio management that remain mostly manual. In summary, every industry will have a unique emphasis for maximising the value from its BPM initiative. Some industries will naturally tackle automation earlier in their journeys, others will benefit from initial attention being applied to predominantly manual processes. Nevertheless, as BPM capability matures there will be a value proposition in nearly all industries for addressing both manual and automatable processes.

PEX Network: How did the challenges of BPM evolve over time at Chevron, ie were the challenges you had when you were first getting started with BPM different from those you had as the programme matured?

Jim Boots: Chevron’s BPM capability has been built primarily through grass roots efforts, but also was motivated by Chevron’s Operational Excellence initiative which began in 2001. The Lean Six Sigma capability evolved from grass roots efforts in 1999 or so. The broader BPM capability, including use of BPM software, evolved from grass roots efforts in 2004. In the early stages of successful BPM initiatives, especially grass roots efforts like Chevron’s, pilot project successes were extremely important for proving the value of the new approach.

Basic support structures also evolved quickly based on a realisation that inadequate support would doom any new approach. In the middle stages of development, once the approaches to process improvement and process management gained credibility, standards, methods, governance and implementation models, technology and training were packaged for widespread use. The idea was to provide a lot of guidance and assistance to business units that wanted to pursue process efforts.

In the latter part of my time at Chevron, the primary challenge was how to catalyse more widespread use of Lean Six Sigma and the broader BPM capability that had been proven in several business units. So in summary I would say the three stages during the last decade that I witnessed, included, first, developing the approach and gaining credibility, second, catalysing the approach for widespread use and, third, trying to meet the chasm, so to speak, from use by pioneering business units to general use.

PEX Network: My final question is, if you had to condense your key lessons learned about BPM implementation down into a few key bullet points, what would they be?

Jim Boots: First, there must be someone or some group who is responsible for and deeply committed to making BPM work. You can call that person a champion or whatever you want. Second, before any value will be created the BPM group must have a budget and a business unit or department must be willing to implement BPM. The budget is needed to select, develop and manage the things that will make BPM implementations effective such as methods, governance, models and technologies and the business unit that implements BPM is necessary to show that the methods, models and technologies work. If you get that far you’re on your way. But, third, constantly attend to stakeholders by clarifying their needs and issues, communicating BPM benefits and reinforcing everyone who contributes to BPM progress. Stakeholders include the managers who are your sponsors, the practitioners who deliver BPM services, the employees who interact with BPM artefacts and quite possibly the implementing business unit’s customers. One can never be too good at stakeholder management.

Jim Boots
Contributor: Jim Boots