Respect for The Knowledge Worker

  • September 29, 2010
  • Scott

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.

Related Posts
  • March 14, 2018
  • Scott

We're heading to IBM's Think! conference next week, and we want to share some of the sessions that jump out to...

  • March 14, 2018
  • Ariana

The Importance of DevOps from BP3 on Vimeo. What is DevOps, what does it mean to customers and how are pe...

  • March 11, 2018
  • Scott

One of the things our engineering team does really well is keep improving the rough edges of any product they ...

  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Respect for The Knowledge Worker --

  • Anonymous


    Maybe you cut class on the day the professor was teaching about micromanagement? (joking, in case it doesn’t come through)

    I wish I could say that the desire to micromanage came from a misguided training course, but unfortunately that’s not the case. I’ve lost count of the folks that I’ve talked with who want to remove all thought and judgement from the people that work under them. One went so far as to say that they wanted to be able to make the system so automatic that they could hire “people who would flip burgers for a living to do the work.”

    My point of view is pretty similar to yours, automate and remove the non-value-add, repetitive work that distracts people from doing work where they can apply their experience. In fact, I’d go so far as to say we’re in violent agreement on this.

    I recognize that there are a number of ACM proponents who say that this sort of knowledge work isn’t suited to BPM, and that “everything is unstructured and unpredictable and BPM is the devil’s handiwork.” I’d like to think that my personal views run a bit more moderate than that. The fact is that you can solve most business problems in any number of different ways. Some of my earlier blog posts deal with that concept relative to the insurance industry ( and

    I think BPM the discipline has merits here and can, when applied correctly, drive substantial value for most types of work. With that in mind, I do believe that many current generation BPMS offerings provide limited support for unstructured, non-repeatable, unpredictable work. Forcing everyone to think in terms of a “process” when sometimes there’s no real step-wise, linear, process flow behind the business is limiting.

    The other side of the coin is that I believe very strongly in supporting process automation, and in a broader sense, incorporating BPMS capabilities within the technology solution that is used to deal with unpredictable work. Back to the original tenet of removing the mundane work that adds no value. Where I draw the line is trying to predefine every single possible permutation a piece of work might require to get to completion. It’s simply not practical, and in the end leads to systems that are just as cumbersome as the legacy approaches they are often intended to replace.

    Thanks for the mention, good to continue the discussion.

    • Really appreciate this thoughtful comment. The goal is not to turn all work into flipping burgers, but to eliminate the flipping burger time so that people can do the more interesting stuff – like making customers happy.

      Tom – You’re right, we’re in violent agreement across the board 🙂 I guess we both missed that class….