When you say "standard processes" or "automated processes" in BPM circles, it is a dog whistle for the pundits and gurus to chime in, because those terms are like a Rorschach test for how you view BPM inside your own head.
As a result, the opinions you have about these terms say more about your approach to BPM, than the opinions say about BPM itself. Recently a discussion on BPM.com caught my attention - the question being "Will Standard Processes Soon be Extinct?" For some, "Standard" will mean "Routine" or "Automated" or having no deviation. For some, "Standard" means eliminating defects and cowboy approaches to process.? In Jim Sinur's usage, I believe he meant "standard processes" that a vendor would provide to a customer, rather than the standard processes that a customer would define for themselves.? I've always been skeptical of bringing so-called "standard processes" to a company from the outside, and one of the comments captures it perfectly:
"...standard processes will only exist as long as they are better than the status quo, i.e. a means for an easy, straightforward upgrade from a messy, uninformed, unprepared process landscape."
Back to the discussion thread... There is so much great stuff to unpack from this thread - I'm not sure everyone realizes the quality of the discussion... Theo Priestley writes:
Creating standard processes removes the ability to innovate because the goal for most is to seek and destroy variance in favor of the majority. And when an organization reaches the plateau of process improvement and has created volumes of standard processes which can be reused everywhere, what then ?
We lose the ability to continually adapt and change.
This almost perfectly captures the tension between experimentation and best practices.? If you don't disseminate or enforce best practices, they won't be practiced. But if best practices don't have room to breathe, they won't adapt to changing circumstances on the ground.? There isn't a right and wrong answer here, but when I was at Lombardi running the technical delivery team, we encouraged experimentation, because the "best practices" at a technical implementation level were still being discovered and adapted.? In some years, a major product release would cause a re-thinking of best practices, and new ideas would emerge that needed to be tested in the field before they could be "blessed" as best-practice.
Kiran Garimella points out the false choice being presented:
Home construction, for example, can have a high degree of customization. The core processes and engineering techniques, though, are based on standards (such as weights, measures, sizes, and parts) and standardized processes (the sequencing of home construction tasks).
And, as he points out, customization is likely desired, not just necessary, to make customers happy.? As he says though, the fear is that standardization becomes the goal, rather than a means to an end:
"In standardization of business processes, standardization may end up becoming the main goal, at which point it morphs into meaningless bureaucracy and becomes as inflexible as the old ERP. This is the kind of standardization we don't need and shouldn't have."
Several comments point out that standard processes aren't going away.? My favorite take on this one is John Tesmer's:
"...the standardized processes allow innovators to achieve higher and higher levels of value. Innovation is build upon standardized processes. Think of the computing power that is available now in your hand because of a standardized process for transmitting packets over diverse networks - you don't worry about that stuff any more - and now look at the ecosystem built atop it."
?Nailed it.? Standardization - and the expectation of consistency - allows for innovation that builds upon that expectation to achieve higher levels of innovation.? The network example is a good one.? So is iOS - the operating system of Apple mobile devices.? So too, the innovation unlocked by standard processes, though often that innovation is unlocked when most of the process has been "automated".
Scott Mentor's comment was interesting:
Truly, it's the opposite question that I sometimes consider: is "ad hoc" simply a passing trend? [...] We keep hearing about these, and yet, my customers seem much more concerned about flexible but standardized processes that meet their need for reliable, consistent, and predictable results. Combine that natural desire with increasing pressure from regulators for compliant processes and the "anything can happen" approach naturally falls by the wayside.
Here, I think Scott is exposing a difference between practice and theory.? In the market, customers are more concerned about standard processes with some flexibility, than they are in the truly ad-hoc work.? Peter Whibley takes it further and postulates "Actually it's customized processes that will slowly become extinct."
Another issue might be that the "standard" processes are where a vast quantity of work happens in an organization.? Typically pictures of standard vs. ad-hoc processes show the standard processes as being the tip of an iceberg of potential processes.? Let's take that at face value, and assume that is accurate.? The other piece missing form the picture is that that tip of the iceberg is where all the volume of transactions are, as well as the dollar value is.? Phil Gilbert used to show a graphic that made this point pretty well, when he was stumping for Lombardi and IBM BPM.? So, if we tackle processes from "most-value" to "least-value" it may be that the standard processes are the ones we tackle first because they have the most value, not because they are the most prone to standardization.
I also liked Keith Swenson's contribution to the discussion, the tail end of which is a great summary:
To imply that "standard processes" might be going away would be another way of saying that companies are losing all work where they have control, and that is kind of silly. There are two trends: (1) controlled work is more automated and therefor less visible, so we think about it less, and (2) process technology is getting better at supporting emergent processes and that if the focus of our attention. So it appears like we are doing more and more variable processes, but that does not mean that the "standard processes" are any less important.
The means-to-an-end argument gets good support from Nicholas Kitson:
This is precisely why organisations moved to BPM solutions, these are designed to be built to be configurable and adaptable to future needs. Standardisation is therefore less the important, in my view, than the consistency and efficiency of those processes. And recent history has proved that this goal is far harder to achieve in practice for what negligible benefit it may bring.
Consistency and efficiency are more important than standardization.? The last couple of comments sum up the idea that BPM is the vehicle for bridging the gap between standard/rigid processes, and standard processes with flexibility to adapt to policies, people, and regulations.
You can infer a lot about what these folks do for a living based on their answers, thus the Rorschach test comment at the beginning of this article.?? The whole read is worth it because it exposes interesting fault-lines in the school of BPM.? In your own business, how much do you want to standardize?? How much do you want to swing the pendulum in favor of innovation and flexibility, and how far in favor of efficiency and support.
Discussions like these, if you back up for a minute, and don't get into the back-and-forth and just see the forest for the trees, are a great value that bpm.com provides to the BPM community.