The Optimist’s View of Automation

Scott Francis
Next Post
Previous Post

Keith Swenson recently wrote about the positive side of automation – that it elevates workers rather than eliminating them.  And history has so far proven Keith right time and time again:

History actually shows a different story.  While automation undoubtedly has a short term effect of displacing particular workers who have grown accustomed to their present habits, it does not show any trend of decreasing the overall size of the economy, or of decreasing the number of jobs available to the population.  One only needs to consider that around 98% of the manual labor performed in ancient Egypt is now automated, but that does not mean that 98% of the workforce is now sitting idle.  The automated looms opened up new opportunities to design fabric, while the increased production opened up new opportunities to distribute and retail the fabric and clothes.

I think this is a key point:

The fallacy seems to come from thinking that the job categories that we have today are the only job categories that we will ever have.

Lack of imagination about the future jobs that will be available is a big issue. A second problem is that the pace of dislocation can be so rapid that the workforce cannot adjust.  Vast numbers of white collar jobs or blue collar jobs can go up in smoke in an economic dislocation, and the jobs those same workers relocate to may not be as good as the ones they left, unless they are agile enough to learn the next set of in-demand skills, or mobile enough to move from one geography to another to chase better paying opportunities.  And this is where assistance with training, cross-training, and other economic incentives to enable job-switching are good investments to make.

Keith published two graphics that do a great job illustrating the concept:

I’ve actually used this same argument when discussing BPM.  That as the routine work is reduced in BPM implementations, more processes will make sense to implement – yielding even more overall BPM work than before.

Rewinding the clock to 2004, Lombardi was on the verge of releasing Teamworks 4, which was going to be a major step forward in the area of tracking and reporting on process instance data.  That release introduced the following ideas to BPM:

  • Tracking point in the process (an explicit point to take a snapshot of the instance’s data, or a subset thereof)
  • Tracking groups – a group of points that are going to store a consistent set of data, at different places in the process(es).
  • Tracking Intervals – a definition of a start- and end-point for a time interval, for the purpose of SLAs, comparisons, etc.
  • Auto-tracking – not implemented in that release, but the concept was evident.

Reporting tools were also added to the product to allow us to visualize all this useful data we were collecting. As the engineering team was having a team meeting about the release, I happened to stop in to listen to the discussion.  Someone in the room asked Phil Gilbert if he was worried that improving productivity for reporting so dramatically would hurt our consulting business, part of which was building reports for customers.  I was a bit touched that someone in Engineering was worried about us in professional services!

Phil started to answer the question and then looked at me and asked me what I thought about it, since I happened to be there, and I ran technical services for Lombardi.  I just told them that I look at it as a pyramid or mountain in the water.  Anything above the water line is “worth doing” – the value is greater than the cost of doing it.  But that as the water level goes down, the number of processes that are “worth doing” increases dramatically (wider base).  So, my contention was that, rather than these reporting tools reducing the amount of revenue associated with reporting work, I assumed we would increase the amount of revenue we earned from reporting and analysis – because many more reports would make sense for customers to implement and use at new, lower costs of implementation.

And that’s exactly what happened.

Keith and I might disagree about whether this Knowledge Work is also “BPM” or whether it is “ACM” – but we agree completely that Automation has, so far, helped eliminate the mundane, the repetitive, and the unnecessary – leaving more room for the artistic, the creative, the subjective.  Or at the very least, more room for the highest-value-adding activities.

 

 

 

Tags: