I received an interesting email yesterday re my BPM 2.0 manifesto from a professed “process analyst” I know:
Another good one, Bruce? I’d quibble only about the role defs for “business analyst” (a common misnomer in vogue in IT today that should be titled “requirements analyst” since they don’t really analyze the business or assist the business in developing strategies, workplace design, etc.) and “process analyst” (being a technically oriented position – when there are already a bunch of process analysts out here and our primary role is doing all that stuff that the business analyst doesn’t do? more involved with business consulting/planning/operations design, etc.).
And, lest you shoot back something along the lines of “well, that’s just your opinion”, I submit to you that the IIBA (International Institute of Business Analysts) defines their role pretty much exactly as we do here at my workplace and everywhere else in North America that I have visited or otherwise know about. And the BPMG study done last year combined with ABPMP’s membership both indicate that the role using the title “process analyst” is very much as I have said, more of an internal business consultant oriented to process measurement, management and change.
I can see where an outside analyst or a software vendor who doesn’t have to actually do this kind of work within a large organization might get confused and think that we’d use the titles rationally to mean pretty much what they intuitively would mean to a casual observer, but much the same way many other roles have developed (manager, leader, architect for example… pulleeeeze) they aren’t really what they sound like.
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.
For what it’s worth, our (i.e. the IIBA’s) recent task survey has shown that about half of the business analysts who filled it out are involved in strategic planning and project selection.
One of our goals is to help BAs in the IT world start thinking of their job and the skills they need to support it in broader terms. In fact, a lot of BAs do end up doing process analysis, because every time you bring in a new system you affect the processes around it. The problem is that they don’t think of it that way and they lack some of the training needed to do it effectively.
[…] Over on BPMS Watch, Bruce Silver quotes a friend of his as saying: I?d quibble only about the role defs for ?business analyst? (a common misnomer in vogue in IT today that should be titled ?requirements analyst? since they don?t really analyze the business or assist the business in developing strategies, workplace design, etc.) and ?process analyst? (being a technically oriented position – when there are already a bunch of process analysts out here and our primary role is doing all that stuff that the business analyst doesn?t do? more involved with business consulting/planning/operations design, etc.). […]