Quite busy, so my flow of blogitems has been diminished considerably. But collecting a lot of thoughts, observations and lessons, so maybe some time soon....
Today's thought: view on people
As processconsultant, I think it's vital that you have a clear understanding of your own view on people in the context of processes.
I encounter two opposing variations in the BPM world (and anything in between):
1. As processconsultant, we gather input, then design the process, then implement it. Implementing means: pushing people in the pigeonholes (processes, activities, roles), and assume they will do their work, driven by KPI's and managers whipping the lot.
The basis assumption: if you design, they will come and do. The rest is "changemanagement", where we explain and assume that either "they" accept, or we encounter "resistance", which we will need to "overcome". We own the process, but accept "input".
I find this approach also a lot in the BPM technology space "Buy this tool, define the process, and your people will obey and empty their taskboxes....".
So, first goals, then process/technology, then people.
2. Processes are done by people, to reach certain goals. So... first we have goals, then people, then, as a supporting mechanism, we have processes. Quite a different viewpoint! Here we first have to understand the goals of the organization and find people willing to support these goals (if nobody found, the rest is pointless). Once we have these people, we work with them (as a supporting/facilitator) to help them structure their work to reach those goals. They own the process, we bring in the process-structuring knowledge.
I firmly believe in approach 2. Yes, it requires more talking, and even more scary: being vulnerable and sometimes unsure what the people/group will want/do/support. It means running workshops, not owning the result, only the way to get there.... It also means accepting that the quality of the outcoming processes is purely based on the maturity of the people you work with. And with careful interventions you might be able to stimulate/let them grow.
In my experience I have to often seen type 1 approaches result in a lot of paper or BPA tools filled with stuff, but no implementation or support from the key people you need for working processes: the process participants or better: the PEOPLE, that understand and are happy to be supported by the process.....
1 comment:
I think you are 100% correct. In the language of professional sports, you're 110% correct! It drives me crazy when I hear (or read) a business process expert going on about modeling notations and toolsets and such, as if these are the only factors that matter, and not even remotely addressing the human element. Don't get me wrong - I know the technology is important and spend a lot of time defining services, developing use cases, doing data modeling, etc. - but ultimately it's always the human element that matters. My clients seem to keep bringing me back because of the holistic vs. technocratic approach I try to take.
An interesting development - over the past few years, an increasing number of clients have been calling me an OD consultant rather than a BP consultant. Along these lines, I'm spending time trying to bring more Organization Development development practices into my work. When I did the keynote at Array's Trends in BPM event in the Netherlands last week, one point I touched on was the need for BPM people to seek out and partner with the OD people in their organizations. I think there are real needs for such partnerships - a survey of OD literature and conference programs a while ago showed that they NEVER mention business processes, and, as your blog pointed out, we don't do very well in the BP field at dealing with the human element.
This is an important topic for me, so I could blather on and on, but I guess I'd better stop! :-)
Thanks again for the excellent post.
Alec
Post a Comment