Harmon on BPM: Toward an Agile BPM Methodology

The Problem Faced by Organizations

The world is changing very rapidly, and it is going to change even faster in the near future. I have been doing a lot of research on Artificial Intelligence (AI). The good news, from a process practitioner’s perspective, is that most AI will manifest itself as just one more type of automation. Right along with trying to make our organizations more digital, we will find ourselves adding AI apps or components to our existing business processes. The bad news is that AI is poised to initiate a vast increase in the range of things we can automate, and it is preparing to introduce a wide range of very disruptive technologies. For example, within a few years, surely within the coming decade, we will see the widespread introduction of self-driven vehicles. Some will be self-automated ships, like oil tankers. Some will be intercity trucks, and some will be cars. In some cases self-driven cars will lose out to drones that will deliver even more efficiently. At the same time, the self-driving vehicles will shift from gasoline powered vehicles to electric and, perhaps, even hydrogen-powered vehicles.

Or consider the shopping malls that define much of the American suburban landscape. It is expected that some 40% of the stores in those malls will close in the next decade or so – having lost their intensifying struggle with amazon.com and other on-line retailers.

Almost all complex machinery will soon incorporate self-diagnostic systems with natural language interface. Plan to have conversations with your copier when it runs into problems. Similarly, warehousing and supply chain processes will be changed by 3D printers that will increasingly generate required parts on-demand instead of shipping and stockpiling them.

I could continue to enumerate major changes that are now predictable and will become a reality in the next few years. Suffice to say that every company is going to find itself engaged in constant redesign and transformation.

Change and Business Process Practitioners

Business Process Practitioners come in several forms, ranging from Lean and Six Sigma analysts, to Process Designers, Business Analysts and IT Process Reengineers. Most have one thing in common – they are relying on methodologies that were developed at least two decades ago, and in many cases, 4-5 decades ago. These methodologies are, in many cases, well thought out and designed to support a thorough and comprehensive analysis of an organization’s business problems. Even today new versions of comprehensive approaches are being developed – consider, for example, the work being done on Business Architecture by many who urge that that an organization develop a comprehensive business architecture for the entire organization.

The problem with comprehensive process methodologies and comprehensive business process architectures isn’t that they are wrong, but that no one is going to have the time to employ them in the decades ahead. Instead, process practitioners are going to find themselves fixing one problem – arising from a major technological change — and then having to shift and fix another – arising from another major technological change — and then still another. Each will be urgent, and many will require that designers rip out something they just did recently to replace it with something else, reflecting an urgent transition to yet another new technology that the organization has decided to adopt.

The term Business Process Management (BPM) arose around 2003 when a new type of internet-based process analysis software arose. The idea, as advocated in Smith and Fingar’s seminar book, Business Process Management, was that BPM software (BPMS) would facilitate the rapid implementation of business process changes. Processes would be modeled in BPM software tools, and then changes would be made, using the tool and would more-or-less instantly occur. The problem with the approach is that one first had to model the processes as they existed. It was certainly done for some critical processes, but no one has had the time to do it for most of the routine processes found in most organizations. And, being realistic, no one ever will. Things have simply been changing too fast.

Today it is popular to speak of Transformation. The subtle emphasis that transformation carries is that we are faced with one after another major technological innovations, which require that we totally change our business models to survive. Transformation isn’t about improving existing business processes. It’s about reconceptualizing the way we are doing business.

We Need a New, Agile Process Transformation Methodology

Business process change practitioners need a new, rapid process transformation methodology. At the same time, they need a new approach to process work that emphasizes not comprehensive analysis, but an analysis that focuses on the most pressing problems the organization faces – probably the problem arising from whatever new technology the organization has just decided to adopt.

I can’t layout a new process transformation methodology in one column, but I am going to try to do it in a series of columns, over the course of the next few months. In this month’s column I am going to focus on laying out some general principles that will need to be embraced by another approaching transformation in the next decade or so.

  1. Any transformation methodology has to accept that process change is never going to be done – that organizations are never going to have comprehensive business process architectures, or even have their major business processes described.
  2. Instead, any transformation methodology is going to have to be designed to locate and deal with the most pressing change the organization faces. Some organizations are going to find that they must redo the same process, over and over again as technologies roll out, each obsoleting the last. This in turn means we will be using a top-down methodology. We will want to start with a high-level overview of the organization and then focus downward to identify specific changes at various places throughout the organization.

    (Imagine what the auto industry is going to face. They are currently moving from gasoline to hybrid-electric, and will likely have to move to hydrogen-electric before too long. At the same time they are going to have to shift from today’s cars to self-driving cars of various varieties, etc.)

  3. Any transformation methodology is going to have to be Agile – its going to have to work by means of successive approximations. It won’t be a matter of doing a new redesign, but of doing a new draft, and then another, and then another. This in turn means we don’t do detailed flow plans for large processes, but high level flow plans and then we only examine details in specific areas.
  4. Much of the change we will face will be technological change – involving digital and cognitive (AI) changes that will involve large amounts of IT . Process redesign is going to have to get better at describing IT changes and the implications of such changes.

So, Agile, top-down, able to identify technology impacts throughout an organization, and capable of moving quickly. That’s a big order and a departure from most of the more leisurely and comprehensive process methodologies we have today. I’ll try to get more specific, and lay out some specific ideas next month.

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of BPTrends Associates, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager’s Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium’s Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in Las Vegas. Paul can be reached at pharmon@bptrends.info
Paul Harmon

Latest posts by Paul Harmon (see all)



3 responses to “Harmon on BPM: Toward an Agile BPM Methodology”

  1. Claude Patou

    12 and more years ago, I had wrotten : an activity process must be think to can evolve and absorb evolving premices because change is a continue process.
    Technology evolving impacts on business modes, processes, methods, applies, tools, doc asset, people skills/talents, people needs, market offers, thought and culture.
    There are businesses which glue on techno, others which follow it, others which want stay more classical as possible.
    Predictive evolving is prescriptive changes program into steps plans, according to techno jumps and costs.
    Prescriptive changes are impacts plans by techno jumps.
    You can modelize AE, CMM, BSC-BOST, APM, EPM-BAM, evolvings for local 4.0 and world 5.0 according to techno jumps.

  2. karen McKenzie

    I think we have already arrived at the point of needing to be more agile in our methodologies. As systems and process have become more intertwined and dependent on each other we need to more adaptive/innovative in our approaches. Socio economic drivers require greater adaptability and agility in addressing the need for a quick change of process. There are other instances where we may only develop an app which requires a minor rethink around process. In short we need to have some greater flexibility to respond quickly but not loose sight of the bigger picture.

  3. Ken Kracko

    I couldn’t agree more, as usual Paul Harmon is spot on. Our current methodology and more importantly our current tools of the trade are way too slow to keep up with today’s fast paced business environment. In my experience when we put together good processes and good systems in a timely fashion our customers are quick to show their appreciation and embrace them. Speed is king!

Leave a Reply

Your email address will not be published. Required fields are marked *