Keep informed?
Subscribe for our newsletter now!

Why Taylorism is a good thing

Dawn at 300 km/h

Dawn at 300 km/h

Woken up at 4.30am, I am now sitting in the train, crossing Germany from Berlin to Frankfurt for a client’s workshop on BPM, BPMN and all the rest. Rather foggy outside, this seems to be the perfect scenery for finally joining the whole BPM vs. Case Management debate (maybe because I am in the mood for fairy tales?).

Actually I have been rather annoyed by some evangelists, preaching (“Adaptive”) Case Management as it would be some revolutionary new understanding of how the (working) world could become a better place, while the emotions behind that belief are rather similar to those in Charlie Chaplins “modern times” and therefore neither new nor revolutionary (but catching nevertheless).

On the other hand it is a good thing to distinguish between structured processes and those that are more or less unstructured and therefore not really suited for the taylor-oriented management approaches, let them be ways of organization or certain technologies like process engines. I just do not like the connotation that “the world” becomes more and more unstructured, or that taylorism is somehow “evil”, because all those statements sound like ideology to me, and ideoloy has never been a good advisor.

I would even claim that

a) taylorism as a good thing and
b) The limit of taylorism in the world of services is by far not exceeded and therefore
c) taylor-oriented technologies (like process engines) have a damn bright future

Huh, how could he claim THAT!? Tailyorism, isn’t that the thing with the machines and the inflexible production lines and all those zombie-workers that are completely unhappy in their daily work? Well, more or less, yes. But there is one completey killing argument: It is also the one that scales.

Let me explain it somehow different. There is a really nice quote I recently read by Alfred North Whitehead: The progress of civilization can be measured by the quantity of actions we can execute without thinking. And I also have a really nice example: Traffic lights. When I approach a crossing driving my car, and the lights are green, I just go on driving, with about 50km/h in German cities. This is rather fast, but I am completely sure that there will be no one coming from the left or right crashing into me, because there is a defined system I can rely on.

Actually, when I am driving, I am a zombie worker most of the time. Sometimes, of course, there are “unpredictable” events, like a child running over the street, or an alien spaceship landing in the middle of the highway. Then I become a knowledge worker, handling that case with my horribly flexible brain.

But what if I would be a knowledge worker all the time, if there would not be any traffic lights (or traffic rules in general)? I would approach every crossing, looking right and left and right again, and then carefully cross it. I would do that *all the time*! What does that mean for my grade of efficiency, and for that of all the other “knowledge workers” in German streets? If German tourists drive in Italy or Spain, they are often completely scared of all the people ignoring the traffic rules, of all the *unpredictableness* on those streets. Actually I think, if it comes to driving, Germans are more like zombie-workers, and people in other cultures are often more like knowledge-workers. But hey, you can say anything you want about Germans, but for sure we are rather efficient.

So the bottom line is: Making the world more predictable (yes, it can be done), and then applying axiomatic systems to it, is nothing invented by taylor and somehow an “accident” of the 20h century, but it is a central component of human evolution. It has always been there, and it will always be there, as long as people are interested in less work and more free time.

OK, so how do those thoughts apply to BPM in general and process engines in particular? They are about axiomatic systems for business processes, about standardization and less flexibility, but also about less work and more free time, or in other words, less costs and more profit: scalability. If I am running a business, this is my biggest interest. If I need knowledge workers for those parts of the process that are unpredictable but necessary (!), so be it. But my ambition will always be to reduce those parts, because knowledge workers are expensive, and they cannot be copied, and therefore they are not scalable, and therefore I consider them a risk and the need for them a problem I have to solve sooner or later.

OK this sounds a bit harsh, and of course it is not true for every kind of business. But I want to explain why there is still so much to do for BPM and process engines in the world of services, like insurances, banking, telco etc. One example: In Germany we have a lot of rather old, traditional insurances, and we have the new ones that operate their marketing and sales activities mostly online. Those new players could realize their processes on green fields, they used a lot of BPM methods and technologies without the need to regard existing culture, policities, habits and people who must be kept busy because you cannot fire them (and who therefore are considered “knowledge workers”). Those new players are small and extremely efficient, and in those market segments where you can already apply that kind of taylor-oriented approaches (like car insurances), they are a real threat to the traditional insurances.

So I think while the discussion about unstructured processes and how we can handle them is a good one, it is a bit exaggerated. In the end, optimizing business is about scalability, and scalability means production lines, and that means taylorism. Case Management won’t change that.

But I also think that most of the existing BPMS-Technologies lack certain abilities to realize good process applications, which means besides other issues, those that can cover both structured and unstructured parts. At camunda, we aim at those issues with a new kind of BPM-Platform called camunda fox, based on the open source project Activiti. There have already been a couple of blog posts about it, but those adressed mostly IT-people like architectes and developers. In my next post, I will explain what makes fox different in a way that it is also interesting for those of us that are not particulary interested in Class Loading, Persistence Layers and the like 😉

Already read?

Scientific performance benchmark of open source BPMN engines

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

New Whitepaper: The Zero-Code BPM Myth

8 Responses

Leave a reply