AKA MONITOR – www.akamonitor.cz – doc. Arnošt Katolický - INFOSERVIS
----------------------------------------------------------------------------------------
Kopie textu Paula Harmona, vystaveného na portálu BPTrends.com.
==========================================================
Autor se v článku zamýšlí nad pojmy a rolemi funkcí „business Analyst“, „software analyst“,
„business process practicioner“ a „BPx“ ( business process expert ). Při tom vychází s vlastního
schematu znározňujícího zdroje procesních problémů.  Autor článku, Paul Harmon je známý
publicista a provozovatel portálu BPTrends.com.
==========================================================

Greetings,

Many business managers think that all Business Analysts are just Software Analysts focused on defining the requirements for software automation projects. Recently, however, there is a broader role emerging for BAs-one that might be called Business Process Practitioner which extends beyond software automation to include a focus on improving the performance of business processes across the enterprise. Here are a few questions to ask yourself when thinking about the role you would like to play.

Celia Wolf, CEO/Publisher
Paul Harmon, Executive Editor/Analyst

 

 

 

 

 

 

Are You a Business Analyst?

  

Like so many terms we use when talking about business process work, the term "Business Analyst" has multiple meanings, depending on who you talk with.

I suspect most people think that "Business Analyst" is just another name for "Software Analyst." The idea is that someone stands between IT and the business users, specializes in particular business processes, and is available to translate user requirements into software requirements that IT can then use to develop software. Companies started out calling these intermediaries "Software Analysts" and then began calling them "Business Analysts," without really changing the role.

This idea is reinforced in the International Institute of Business Analysis's (IIBA) latest Guide to the Business Analysis Body of Knowledge (Version 2.0). The IIBA was founded in 2003 and has some 10,000 members. They recently revised their BOK documentation to reflect the state of today's practice. There are those involved in the IIBA effort who had hoped to expand the use of the term "Business Analyst" and who suggested that business analysts should help companies solve a variety of process problems. In the end, however, Version 2.0 of their BOK looks pretty much like the earlier version, and both basically define how an individual should go about defining business problems that are to be automated.

A more aggressive effort to redefine the historic role of the "Software/Business Analyst" is being led by SAP. In 2007, in a major speech at SAP's TechEd conference, Thomas Volmering, SAP Product Manager, argued that the role that Business Analysts had played, in the past, was not what would be needed in the future. As companies focus more on business processes, he argued, they will need individuals who can help their organizations with all of the various problems that are joined under the term Business Process Management. Volmering proposed that the new type of analyst be termed a "Business Process Expert" (BPx). SAP has since launched a BPx section within its Developer website and posts articles each month to help educate would be BPxs.

I've followed the SAP BPx website off and on for the past two years. Indeed, some of my own articles have been published there. There is clearly an effort being made to reposition the role of the "Business Analyst," but, broadly speaking, the progress is slow.

The problem is pretty straight forward: There are lots of people who already have the title "Business Analyst." And, whether they are working with SAP implementations or are members of IIBA, they understand their job to be gathering business automation requirements and handing them on to their organization's IT developers. Articles on an expanded role may be interesting, but the reality is that Business Analysts already have a job description, and they already have assignments, and those assignments involve being an intermediary between a business unit and IT.

I was reminded of this at a recent conference when I heard several good talks on major BPM projects that companies had undertaken. In almost all cases, the project teams reported to the organization's CIO, but in almost all cases they were operating as a more-or-less independent group that was focused on delivering BPM services. In about half the cases, the individual heading the BPM group didn't have an IT background, but had, instead, a background in quality control.

If I were to make a short list of key groups involved in process change, it would include:

  • Business Managers (Almost all the members of the Supply Chain Council who use SCOR are senior logistics and supply chain managers with no links to either quality or IT).
  • Six Sigma Black and Green Belts and other Quality Control specialists.
  • Lean practitioners who may or may not be focused on Six Sigma.
  • Individuals focused on auditing how organizations approach processes and working to improve an organization's process maturity.
  • Business Analysts from the IT organization that are interested in process because they are involved in ERP implementations, or software automation projects.
  • Human Performance specialists certified by ISPI.
  • Strategy and managerial performance specialists involved in Scorecard initiatives.
  • An assortment of people who learned process redesign from Rummler-Brache, Burlton, Hammer or others who tried to focus on large scale business redesign efforts and on business process architecture. This group of people does not usually include the IT folks engaged in Enterprise Architecture, but it can.

And, although I have not included the role above, there are a growing number of individuals responsible for managing processes on a day by day basis who think that continuous process improvement is simply a part of being a good manager.

We might try to fit some of these groups into a redesigned role as "Business Analysts" or "Business Process Experts" but most just don't fit. Few Black Belts would identify themselves as "Business Analysts." Hardly anyone from the International Society of Performance Improvement (ISPI) would term themselves "Business Analysts," nor would most Lean specialists.

For better or worse, the term "Business Analyst" and "BPx" will probably remain roles that describe someone who interfaces between business managers and IT developers.

In writing for BPTrends, I tend to use the term "business process practitioners." It isn't very elegant, but it is broad enough to encompass business analysts, business managers and Black Belts, and it doesn't carry a lot of baggage from any one of the disciplines.

In the June 30th BPTrends Advisor on Business Process Problems I tried to describe the range of variables that one needs to consider when one is tackling major process problems in today's organizations. They are pictured in Figure 1.


Figure 1. Sources of process problems.

Some of the variables included in Figure 1 involve:

  • Defining processes, eliminating activities that don't add value and straightening out the flow of the activities.
  • Analyzing employee performance, defining jobs and structuring training to support performance. Establishing and aligning measurement systems and evaluating how managers plan and control the processes they manage.
  • Determining how business policies are implemented in business rules.
  • Similarly, the information available, the feedback people get, and the incentives and bonuses that structure employee and managerial behavior are all important elements in understanding why processes work or don't work.
  • And, of course, the ability to analyze customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs in order to be effective.

Think about the list I have just provided. How many of these concerns are concerns of yours, if you are a Business Analyst, or a Black Belt? If you can say "yes" to most of them then you are a "business process practitioner," as I use the term, and you have the range of competencies that individuals need to really change the ways organizations operate.

If you are a "Business Analyst" and only focus on variables that relate to defining processes and specifying requirements for automation, then you play a valuable role, but you are not working with what I would regard as a complete tool kit. Similarly, if you are a Black Belt and don't think about the issues involved in defining processes and specifying requirements for automation, then you are probably a skilled Six Sigma project manager, but you are not working with what I would regard as a complete process practitioner tool set.

Increasingly, we are going to see Business Process Management groups established outside IT and Six Sigma, and reporting to senior executives. The individuals heading and working within these BPM Centers of Excellence are going to require a range of knowledge and skills that encompass more than the knowledge and skills commonly associated with either Business Analysts or Black Belts. I've suggested we call them Business Process Practitioners for lack of a more acceptable name. Maybe we should call them BPM experts. Geary Rummler would have called them Performance Consultants, the title he preferred for himself.

I'd be interested in hearing from BPTrends readers on this subject. What is your preferred job title? Do you think a title like Business Analyst or Business Process Expert should be promoted to serve as a job title for those involved in today's business process efforts, or do we need a new term?

Till next time,

Paul Harmon