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
Ken,
Interesting question! You suggest that " a Business Analyst is a sub set of a Business Process Modeller" - I would agree if you had put it the other way round! Process Models define a set of requirements for a change project. There will be other sets of information needed: Objectives, High Level Functional and Non-Functional Requirements, Process Models and Specifications, Data Models and Specifications, project and analysis deliverable dependencies and constraints, and other project specific stuff. To see how this all maps together see http://www.businessanalysisdistancelearning.com/articles/Fundamentals%20of%20Business%20Analysis.pdf
So for me BPM is a subset of BA - but bear in mind my observation that there is no binding definition of what a BA is. The bottom line is you do what you need to do to do the analysis regardless of what role it is nominally labelled as (ref Adrian's points on roles).
Cheers,
Guy
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.
An interesting discussion, does BP modelling not take place only, once "as-is" business processes have been discovered, documented and agreed upon. The next phase would be studying the as-is scenarios and then making reccomendations on possible to-be or process improvement, then documenting these. The modelling is then carried out for business process analysis or simulation, or for using the modelling to configure or apply the new business process.
This first step of process discovery and documentation is imperative in any engagement of this nature. So many organisations just do not know how their businesses work and make money, or indeed where they might be losing money. Check out this tool Ken, it is so easy to get going and makes so much sense for anyone to start somewhere. www.processmaster.com There is a free 21 day download, Would appreciate your comments
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 :-)
brought to you by enabling practitioners & organizations to achieve their goals using: