As Keith Swenson wrote here: "Process oriented thinking causes us to think about processes in isolation. We forget that real systems need to be backed up, real systems go up and down, real systems are reconfigured independently of each other. The process oriented approach ignores those to focus exclusively on one processes, with the assumption that everything in that process is always perfectly consistent." What do you think?
Any organization can be too focused on anything to the distraction, detriment of other aspects of running the business. In big orgs, every other year with the arrival of a new SVP or CXO this subject or that becomes the flavor du-jour when they come on board and focus is shifted to that. 'Til the next SVP or CXO comes along and the focus - attention span - turns to something else.
Process, like anything else, is only as good as the people executing it.
Even an appropriate amount of process focus can lead you the wrong way. Optimize a process until it is very efficient and effective internally - but neglect the impact it has on your customers - and you may find that customers take their business elsewhere. It turns out customers care about how they EXPERIENCE your process, they don't actually care how you do it behind the walls of your company, so long as they don't feel the pain...
So you always have to balance process with customer, efficiency with effectiveness, satisfaction with cost, etc. As Patrick said, it's about the people.
Process is about common sense and logic interacting with people and "machines" that delivers the required outcome. Whilst process is the driver in the business sadly with so much legacy complexity it is inevitable such issues as raised by Keith need to be addressed which has little to do with the business logic.
Where the effort to fix these non processes the issues become too great -- even interfering with the front line business -- then maybe it's time to rethink how processes can be supported in a better way.
No company should exist only to improve their processes and forget about anything else.
But on the other hand, I think it is a much more usual error to focus on anything BUT processes. That is a common mistake among smaller companies. Small and Medium enterprises (I always come back to this topic because is what I am familiar with) don't focus on processes, but rather on daily problems. That is why for those cases, a business process analysis is quite useful.
On the other hand, each company has to identify which process is worth automating in which one isn't. Not all processes work better when they are automated, specially the small and simple ones.
I am currently working on a methodology to help SME identify which processes are worth automating and which ones aren't.
So, in sum, too much of one thing is good for nothing. But for SME (and all companies, for that matter) the risk of forgetting about BPM is higher than the risk of becoming too process focused.
Another angle: focusing on the wrong process. Of course it's important to have controls around your spending, HR practices, etc. By all means, devote resources in those areas. But, as Scott notes above, customer experience is the key to the competitiveness and growth. And customers like nothing less than unpredictable or hard to understand interactions: "If you are an existing customer, press '6'. If you are an existing customer with a question regarding the Fair Credit Reporting Act of 1970 without regard to further protections offered by the Fair and Accurate Credit Transactions Act of 2003, press '7'. To repeat these options, enter your social security number divided by the year of your birthdate minus the last two digits of your account number."
Keith’s blogpost is a good example that error-handling in distributed systems is more difficult than in monolith applications.
I disagree with “Process oriented thinking causes us to think about processes in isolation.” it is not a fault of “process oriented thinking” because yet another process-oriented thinking considers: “Enterprise as a System Of Processes” - http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html and “Iceberg of processes within an enterprise” - http://improving-bpm-systems.blogspot.ch/2015/02/iceberg-of-processes-within-enterprise.html
If Keith means BPM as a discipline than I agree with “BPM is not a replacement for good system architecture.” and for this reason, I consider BPM as a trio: discipline, tools and practices/architecture. The latter covers all the problems mentioned. Various techniques are described in “#BPM for software architects - from monolith applications to explicit and executable #coordination of #microservices architecture” http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-software-architects-from.html and “#BPM for the #digital age – Shifting architecture focus from the thing to how the things change together” http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-digital-age-shifting.html
And, in my understanding, BPM is the key for cloud-friendly application architecture – see http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html
I think it is possible to focus too much on processes, especially when a company or organization has been cited as being weak on standardized processes. Then, it becomes processes left and right, night and day, even to the do the simplest action. Over-reaction and mandates can create stacks of processes for the sake of having processes, whether they are intuitive or useful or even necessary. This is what we call "red tape"--the downfall of bureaucracy--and it can exist in a BPM product just like it did when processes still involved paper and TPS reports.
It is easy to blame the process here - it is the way we do process which is at fault.
A company is, at its most fundamental level, a process.
Someone has uncovered a need which more than one person has.
They have identified that the same solution can be offered to multiple people.
The company exists to scale delivery and is a process for doing so.
So being good at process is in its DNA. Often, in a world of me-too products, its competitive advantage.
And every part of that company needs good sub-processes.Ones to ensure:
Every customer is reached, engaged and delighted with the service they receive.
Product is where it should be, backed by the right package of services.
Revenues are collected, banked and distributed.
And internal ones too. How to...
Share ideas, build concensus and turn them into actions.
Bring everyone's skills to bear on problems, not just highest paid person in the room.
Create skills development paths for all employees
Feed market intelligence back into the company information structures.
Oops - we forgot about those ones. Or decided they didn't matter.
But the way we do process means they aren't information streams, or collections of everyone's wisdom and experience for all to share.
They don't evolve, but are imposed as straitjackets. How many straitjackets does a company need?
Now the problem with locking anything down is that it freezes innovation. It makes that thing hard to do better.
Often it forms a blockage and processes actually flow around.
The manager who doesn't use the CRM, because it takes too much time for too little reward.
The COO who keeps the important clients out of the automated system so he can be flexible on delivery.
The HR person who fills out false data just to get the system to deliver what he/she wants without the bother of collecting the data.
We've all seen it. And usually blamed the rogue manager. The one who prioritises company over process.
But that sort of process - the one that holds the company back - we need less of.
And the people who create it and impose it - well, we need fewer of them as well.
But the good processes - the ones which amalgamate intelligence and experience, acting as machine learning for an evolving process?
Well you can never have too many of them.