Should we Blame BPM for a Jobless Recovery?

  • October 19, 2010
  • Scott

Max J. Pucher always writes interesting copy on his blog.  And one of his latest, on BPM and the Jobless Recovery, is no exception:

Well, I propose that it is the efficiency and cost-cutting mindset also employed in BPMS justifications that is a major cause of the ongoing lack of jobs in the US. BPM implementations focused on automating work with flowcharted processes (and excuse me,  the majority are!!!) are only usable for a subset of work – those repeatable, low value, high-volume admin processes that ERP can’t handle. The ROI justification is virtually always about less people needed per revenue!

I’m afraid that BPM isn’t in such common usage as to affect the staffing decisions of the local bakery, the law firm, the ad agencies, and the factory floors, which have all shed quite a few jobs in the US (and, of further note, manufacturing jobs in most countries around the world are in decline, as non-BPMS automation is displacing more and more human workers in the manufacturing process).  And it isn’t relevant as an explanation for the dramatic job losses in construction, real estate, mortgage financing, and other related businesses.  (Moreover, according to the New York Times, Eurozone unemployment was steady at 10% as of May 2010… perhaps the US is more volatile, but at 9.6% it doesn’t seem to be an order of magnitude off).

While I agree with Max’s frustration with companies that are so focused on cost-cutting that they’ve cut bone as well as fat – and I agree that this extreme cost-cutting actually deepened the recession and slowed the recovery (because, in this particular recession, the primary driver has been a reduction in consumer spending, rather than in corporate investment).  But BPM is hardly the reason that home building, mortgage processing, loan origination, and other related fields were hit so hard. Quite simply, there was a bubble in that segment of the US economy that had nothing to do with BPM. The bubble led to over-investment, and the bubble bursting led to dramatic re-valuation and contraction in those sectors.

But there’s more meat to Max’s article, regarding the cost of BPM implementations:

Yes, I totally agree with Jim’s assessment of the complexity and substantial people effort need to get BPMS implemented. Some of the cost is also not process related, but caused by the technology stack being used and the resulting INTEGRATION work. Therefore I propose a consolidated platform rather than integration with others. Businesses who try to integrate existing ECM, BPM, CRM, BRM, E20 and BI suites will never achieve a truly dynamic, adaptive and financially sound BPM.

Not too much to take issue with there. Integration is usually one of the biggest costs… And later:

Because the BPMS skills are expensive and rare they are mostly provided by outside consultants. In effect that means that once the processes are implemented the people who know and understand them move on, leaving the business with unskilled workers and killing the ability to improve or innovate. This is the worst possible business proposition I can think of.

(Max’s emphasis).  Max is blaming the wrong party here.  If businesses are left with unskilled workers, then it is the business that must change – by hiring and retaining talent for improvement and innovation.  Hiring consultants as part of a strategy for change makes sense. But making outside consultants the beginning, middle, and end of a strategy for change is not the answer.  Like *all* human resources applied to projects, consultants will move on.  But so will full-time employees.  It is important to build enough critical mass and momentum in BPM efforts to create sustainable organizational learning that can survive the departure of a key team member(s).

Mainly, however, I disagree with Max’ dark view of BPM:

I hope that Jim is wrong with BPMS adoptions speeding up and that we are rather on the verge of enough people realizing that BPM as a concept that turns people in to process monkeys is a failure.  In the worst case, it won’t just be the ‘jobless recovery’ that is going to crash on top of us, but it will be the inhumane, fully automated, mass-produced, market-segmented, analytically predicted process nonsense that will make even those customers walk away that still have a job.

As I’ve argued many times before, BPM can’t be about turning people into “process monkeys”.  It has to be about removing the mundane, and enabling the real humans in the process to excel.  Once someone’s job has been reduced to “process monkey” it is truly something that will be automated.  The point is to remove the “process monkey” parts via automation and leave the judgment calls behind.

Related Posts
  • October 18, 2017
  • Scott

The Institute For Robotic Automation defines RPA as: Robotic Process Automation (RPA) refers to automation wh...

  • October 18, 2017
  • Ariana

Headless BPM from BP3 on Vimeo. In this video, Carmen Galicia walks through using external user interface...

  • October 10, 2017
  • Ariana

Planning Your Project Roadmap from BP3 on Vimeo. In this video, Andrew Paier talks through getting started ...

  • Scott, thank you for covering my post to this extent. Much appreciated. An open-minded discussion is exactly what this needs. A couple of points though, because I am not BLAMING BPM for the lack of jobs. The EU is a very complex demographic and with some of them being at 25% and others at 5% unemployment I only mentioned the effects on the recession, 1) I clearly said that I am concerned with the mindset that leads to cost-cutting measures by means of BPMS. BPM as a management approach is not directly to blame. BPM approaches that focus on customer service quality are essential for a modern business. But as we know many BPMS implementations have no other point than to cut manpower.2) I am in line with you that BPM should be about empowering the decision maker to make judgement calls. This is clearly the point behind my ACM approach. 3) I question that in a typical flowcharted BPMS those judgement calls simply aren’t possible, because the decisions are all encoded into flowcharts. On the other too hand many work items especially content-oriented ones in human-centric BPMS can’t be fully automated, so the process monkey remains necessary. Automation is fine in areas where there is a production process ongoing or some sequence of activities have to be performed with high reliability. It is completely out of place in areas where individuals interact and a positive customer outcome is essential. These are the high-value, knowledge oriented, decision-making processes. They won’t be automated by the means of BPMS, because even the odd human-decision point here and there is not enough and the flowchart will always be the restricting element. it is those processes that firms try to automate with BI and predictive analytics, rule engines and BPMS to get away from the dependency on skilled and thus more expensive people. You might disgree, but my experience and intution tells me it is a small-minded, short-sighted fallacy. The way BPMS are used today is fine for all-out automation (at most 20% of processes), but it makes business brittle and unresponsive to change and certainly not agile.

    • Max – thankyou – this gives me a much better understanding of your original piece as well. If I can sum up: it isn’t BPM itself that is the problem, but a cost-cutting-only mindset that is likely to latch onto BPM (and lots of other things) at the expense of good business practice (e.g. customer service).

      I don’t disagree with your argument against automation… I just don’t know enough about your own product (not that you are making a product-specific argument), to truly understand how you differentiate your approach from a “typical BPMS” approach. I do know that the projects I’ve worked on have avoided this automation trap – we’ve focused on automating the most annoying parts of processes (repetitive, mindless, and non-value adding) and leaving the most interesting parts up to the business. It isn’t the odd decision here and there – the human is the central actor in the process. And so I’m left wondering if this is an operator error issue (of the process author in other BPMS projects), or a technical limitation of some of the other BPMS packages out there. Rules and Flowcharts and Resource allocation – they’re all constraining in nature. I’d love to learn more about what makes Papyrus different at a technical level (rather than the blog/website level only! )

  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Should we Blame BPM for a Jobless Recovery? --