Hope this is the right forum to put my question up.

One excellent book on BPM I am currently reading is Workflow Modeling : Tools for Process Improvement and Application Development by Alec Sharp and Patrick McDermott. One of the few books that actually gives you a minimal framework to keep in mind while setting out to understand the as -is and to be process.

I always have this nagging doubt about the demarcation between a Business Process Modeller and A Business Analyst. My limited knowledge simply tells me that a Business Analyst is a sub set of a Business Process Modeller. If the BPM models cross functional processes with many handoffs, the BAs role would then be to analyse individual processes and gather requirements on a detailed level from the Business.

A BPM too would have to engage the business but on higher level only to get an agreement that a process is detailed enough and no further breakdown is needed when it comes to a Business Process Model or Swim Lane Diagram.

Am I on the right track with my thinking, or is there something more concrete that differentiates a BA from the BPM?

Cheers

Ken

Misplaced words Guy!

You are right. a BPM is a subset of a BA. A BAs work encompasses that of what a BPM does on the whole. As you rightly said, a BA would need to do anything to get the requirements and in many instances, modeling the process helps the BA squeeze out the info from Business who have seen the new To- Be model and have ideas on that. I have to start reading the BABOK soon. Just got a copy of it. Sure is getting me excited on seeing some standards for BAs in place.

Cheers

Ken

Thanks Nigelus,

Will check out the tool and let you know. Regarding what you have mentioned, from the course that I had recently been on as well as in the WorkFlow Modeling book by Alec Sharp, it is clearly mentioned that modeling the as-is process comes under the purview of the Business Process. This is because, while gettting together the picture of the as-is process, the BPM can inadvertantly find out mistakes in the process. HOWEVER, the as-is process is only done to ensure the scope of the system/s that is/are being analysed. Moving onto the TO-BE process is where the actual work by the BPM will be carried out. Constant referaal to the AS-IS process can guide the BPM to know where the initial mistakes were made.

Further, Alec states that, one of the good techniques to follow for BPM is

1. Frame the process

2. Identify the As-IS process

3. Design the TO-BE process

4. Analyse use cases.

Reading this got me confused in the first place as to where would you place the BA in such framework? But then like Guy pointed out, subtle differences exist between a BA and BPM though overall, it is very difficult to have a clear cut definition. It all boils down to what your organisation encompasses in the resposibilities of the BA role I guess.

Reading makes you more knowlegdeable and even more confused :-)

Ken