Harmon on BPM: Business Analysis and Business Process Management

I spent a week in Las Vegas at the Building Business Capability conference (BBC). As readers may know, the BBC brings together Business Analysts, Business Rules practitioners and people committed to Business Process Management. Under the circumstances, it's inevitable that someone will ask about how Business Analysis differs from BPM. Here's my take:

Business Analysis and Business Process Management, are, in essence, two different names for the same discipline. Both are concerned with identifying, analyzing, redesigning, and implementing improvements in business processes. Here's how a Wikipedia article on Business Analysis describes a BA's responsibilities:

To investigate business systems, taking an holistic view of the situation. This may include examining elements of the organization structures and staff development issues as well as current processes and IT systems.
To evaluate actions to improve the operation of a business system. Again this may require an examination of organizational structure and staff development needs, to ensure that they are in line with any proposed process redesign and IT system development.
To document the business requirements for IT system support using appropriate documentation standards.

One could write a description of a BPM consultant's job and it would sound very similar. Having said that, let me qualify my statement a bit. Historically, Business Analysts were thought of as people with a special knowledge of software systems who could help business people identify opportunities for, and define software requirements for automation. By the same token, historically, BPM initially arose among business managers and tended to focus on people and how changes in the way people approach problems could benefit the business. Recently, BPM people have spent a lot of time focusing on how organizations can coordinate (manage) all of their business process initiatives.

Let me put the distinction in a slightly different way. A typical BPM class will usually put lots of emphasis on higher-level process architecture, and on process management and measurement systems. A typical BA class will normally include a major unit on defining software requirements and on the problems of transitioning to a new software system.

I would stress, however, that these are simply historical tendencies, and don't necessarily reflect today's practices. Current efforts by leading BA organizations, like the IIBA, have put an increasing emphasis on the use of process analysis and on pulling together a wide variety of different options. BAs trained in modern approaches are as likely to recommend changes in the organization of a process or changes in employee training as to recommend automation. By the same token, individuals who think of themselves as BPM consultants commonly find themselves thinking in terms of automating business processes. Much of the latest work in the BPM area involves the use of software modeling tools that allow the analyst to move from a diagram of a process to code that will automate at least the monitoring of the process and more often generate tailored ERP solutions.

In discussions at the BBC, once I explain my position, I am usually asked to go further and explain how the BPTrends methodology, which I helped develop and have written about extensively, fits within this web of definitions. The BPTrends methodology is definitely a BPM approach, in the sense that when we analyze a business process problem, we begin with a high level architecture overview to provide a context for our exploration of the problem. We proceed to consider all of the various kinds of things that could be wrong with a process, and the full range of solutions typically available. We consider changes in the flow of the work, in decisions made during the course of the work, in how people perform, in how managers monitor and provide feedback, and, of course, in how software resources are used. We look for opportunities to improve human performance and for opportunities to automate.

We put less emphasis on capturing software requirements than an older business analysis course might have included, in large part because software requirements capture is well treated in more focused courses, and also because many of our students are interested in using BPMS tools that allow them to move from good BPMN models to code that will be generated and managed by the BPMS tool. When students are interested in that approach, we recommend that they follow our basic courses with courses from a BPMS vendor who can provide detailed training in the use of a BPMS tool.

We think of our courses as a perfect combination for young business analysts. We focus on the analysis of business problems and on exploring the options that an analyst should consider when faced with a challenging business process problem. We spend a lot of time teaching students to define problems by means of BPMN flow diagrams. We indicate when the business analyst should consider automation and point out various typical paths, one leading to BPMS tools and the automation of process flow diagrams and the other leading to a more formal software requirements approach, followed by software development or, perhaps the acquisition of ERP applications. We fully expect that Business Analysts that take our process analysis courses will follow them with classes in how to use BPMS tools or how to define specific types of software requirements.

BPTrends is not, of course, the only methodology that is positioned in this way. As we suggested earlier, an expansion of options is being pursued by most people involved in process change. Six Sigma programs now include Lean, and Lean programs are incorporating more on architecture and on Decision Management. The IIBA has just released a new version of its BABOK standard and includes more on BPM and less on the older approaches to software requirements definition. The world of business is getting more complex and the problems created by the complex interaction of new technologies and media, people, and new ways of organizing business processes requires more and more sophisticated business analysts. SAP refers to business analysts who have had the kind of training that the BPTrends classes provide as BPx (business Process experts) and claim they are the “new” BAs.

Whatever their historical roots, those concerned with improving business processes at modern organizations – whether they call themselves business analysts or BPM consultants (or Lean consultants for that matter) — need all the tools they can get, and they need good ways to help themselves organize when and how they should use the various tools to reach cost-effective solutions as quickly as possible.

PDF Version

Bio
Latest Posts

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.com