Who is a Process Analyst
Monday, March 13th 2006 | Ismael Ghalimi
It’s Monday and I am starting a new weekly series on BPM 2.0. Every Monday, I will pick one item in my BPM 2.0 checklist and provide more details about it. I will go through the items of the list in the order they appear in today, then circle back once I have covered all 18 items. Three passes should keep us busy for the rest of the year.
The first item on the list is about process analysts, who I believe are the target users for BPM 2.0. The question then becomes: how can you identify them? A simple test is to ask a candidate if she understands the differences between a do-while, a while-do, and a for-each loop. If she does — and can explain it to a business analyst who could not explain what a loop is at the first place — you found the person you were looking for. You will find her among the 8 million Visual Basic programmers, the 3 million PHP fans, the million PL/SQL folks, and the half a million or so ABAP guys and gals. If you compare that to the 2 million people who can write Java code today, that’s a pretty big group. If you add to the mix the folks who understand HTML, you’ve got a pool of more than 20 million people you can draw from.
And if you want to understand why the mastery of Java and J2EE should not be a pre-requisite to the use of a BPMS, just read the syllabus for the course on jBPM offered by JBoss:
“The student must have previous experience developing an Hibernate application. The student must know how to configure a simple SessionFactory for Hibernate, utilize a Hibernate Session and transactional demarcation and how to perform basic queries on Hibernate objects.”
To me, it’s pretty much a show stopper. BPM 2.0 does not stop there though.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[…] This notion of “process analyst” is consistent with Ismael’s formulation, which I agree is the key role in moving BPM 2.0 forward. But lest you think this resolves traditional issues of business-IT collaboration and alignment, my friend elaborated in a follow-up note: What I meant was most “IT managers” don’t actually “manage” they caretake. Most “IT leaders” don’t lead, they exert power. Most “IT architects” don’t design and engineer anything, they set “standards” (usually by copying something else - like vendor handouts) and act as technology cops. IT has a way of using terms, especially roles and titles in ways that imply one thing but actually do another. So “business analysts” don’t really analyze the business, they document requirements for support systems. My friend prefers to remain anonymous. For obvious reasons. […]
[…] They are right in the sense that indeed, no business analyst — or process analyst for that matter — should ever have to write a single line of BPEL code. Instead, they will use a process modeling tool that will generate the code for them. But they are also wrong, for the code that is generated that way really does matter, for three main reasons. […]
[…] The very idea for Business Process Management, as theorized by Howard Smith and myself back in 2000, was to bring business and IT together. It was neither a top-down approach driven by business folks, nor a bottom-up one controlled by IT people, it was a middle-out one managed by process owners, and these tend to have a good understanding of the business, as well as decent technical skills. It was a fundamentally new approach targetted neither at the business analyst, nor at the software engineer, but at a new category of developers that we later called process analysts. It was neither human-centric, nor integration-centric, it was simply process-centric, and human as well as systems were treated as equal participants to the process. This was our vision back in 2000, and this vision remains as pertinent today as it was back then, with the only difference that products implementing the vision exist today. Check this one out for example. […]
Thanks! I was just hired as a Process Analyst for SAP BW. It was kinda odd sitting in an interview were I knew more about what I was supposed to do than the people interviewing me… Everybody was asking me what a Process Analyst is. I wasn’t even sure. I said “a liaison between IT and Business”. Thanks for clarifying.
Araywood,
Congratulations!
Best regards
-Ismael
Hi Araywood,
Happy to hear about your job with SAP. I would like to know where you did your training, and if you could spare me your materials.I am a process analyst with XDS Solutions, and would like you to acqaint myself with all you do.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment