Respect for The Knowledge Worker
- September 29, 2010
- 3 Comments
Tom Shepherd writes about the pride of the knowledge worker:
I had this point hammered home almost immediately as I was immersed into product and user research. See, as “automate and improve” types, we are often taught to believe that every worker involved in a business process needs to be told what to do and is limited to doing that work assigned by their manager or team lead. Extrapolating that point, one might assume that measurement of productivity is necessary to enforce good working habits. In some rare cases, this is true, but almost to an individual, what I’ve witnessed are people who are conscientious and truly care about their jobs and their performance. They take pride in their accomplishments, and they are competitive with their colleagues.
I must have missed this “automate and improve” class that teaches you to believe workers have to be micromanaged. I subscribe to the view that the process should remove the mundane and enable the great. I’m glad Tom is experiencing this first hand as well. As a consultant and BPM practitioner, I see this all the time in the field. People care about their work and they want to do it well.
This philosophy has impacts even on seemingly small elements of business process: do you assign work based on skill levels and some notion of “fairness”? Are you overly concerned about cherry picking? Or do you just let users pull the work down as fast as they can work it and reward the most productive and constructive members of the team?
I try to remind our customers and partners that a BPM solution doesn’t replace good management of people. You still have to decide who to keep and who to let go – who to coach and who to reward. And software does not excuse you from these responsibilities. Look – people matter. You have to nurture your human resources or you pay the price in the long run.
I recently met with a customer who achieved a 300% increase in productivity with the solution we helped them build. To give credit where it is due – they designed the process. The process improvement team had the insight (without our help) that more of the work being performed was fungible than others in the business believed. They needed BPM software and some experts like our own at BP3 to show HOW to implement the process to realize their vision – but it was their own key insights that led to the project we helped them with. Now that they’ve implemented the process, they’re in the position of letting their best team members handle the work.
It would be tempting to think that we automated most of the work. But actually, we automated the mundane- notifying the experts when something went wrong with their book of business, rather than making them responsible for constantly monitor for completeness. It wasn’t so much that we automated more – it is that we automated the right parts, and transformed something transactional and case-management-oriented into something process-driven (They previously had what could best be described as case management work – with a set of cases assigned to each person. ).
Of course, before we all embarked on the process, we were told this couldn’t be done – that the work wasn’t fungible. And ACM proponents would have told us this knowledge work isn’t suitable to BPM. But it was clear to us that it makes more sense to have software do the parts that are the same every time. What’s LEFT after we boiled down the process, is the case management activity real people need to perform. But what they were doing before was case management and process management… manually. And the users weren’t clear which was which.
Ironically, there was more assembly-line thinking in the old approach than the new approach.