Which states: "Bounded rationality is the idea that when individuals make decisions, their rationality is limited by the available information, the tractability of the decision problem, the cognitive limitations of their minds, and the time available to make the decision..."
I raised the question with Peter not long ago as I find it interesting that the BPM people seem content to be able to address one or two business processes at a time. When designing a total system, I am used to designing all of the business processes (or sub-systems) along with the logical data base. These sub-systems can then be refined into their procedural flow and software specs, follwed by programming, testing and implementation. Such sub-systems can be developed in parallel and concurrently. Yet, I hear nothing like this in such forums AS this. So, my question to Peter was, "Do we no longer know how to design enterprise-wide systems anymore?"
1. Not every process has the same charachteristics and doesn't need the same enablers (of which technology is just one).
-> The question looks like it's about building some kind of general enterprise wide system. But that's a very technical view on BPM. You don't do formula 1, rallying and shopping in the same car. So process first, technology later.
2. Not every process needs attention.
-> not all processes are equally important. If some still work fine with pen and paper, why bother.
As you can see, to me a process is not a system. I wouldn't call all the processes of an organization an 'enterprise wide system' .
Although, I always start my projects with a clear overview of the processes of an organization to prevent working on useless or half processes.
To me technology is one of the enablers of process performance. And the value of it can differ form process to process.
One size fits none, so that's why I am very CONTENT ;-) with process by process.
There is only ONE business process; the end-to-end core process (Idea2Cash or Idea2Market). OK - there are also support processes. Tthe concept of multiple processes and only "doing" one at a time is a very "automation"-centric perspective of process. So the word "doing" is guess is the key word in the sentence.
You can't do one process at a time. Nature tells us a lot. All bananas on an bunch ripen at the same time.
So where do bananas come in? Have you ever seen a single banana in a bunch which is larger or riper than the rest? No. Nature is telling us something here. All the bananas ripen at the same speed. So they are all kept consistent. Energy is expended equally across all the bananas to grow and ripen them.
We need to take a holistic approach to BPM and process improvement, so that all the initiatives dovetail. We need to make sure that the end to end processes flow smoothly. There is no point streamlining the quote process if there is a bottleneck in reviewing proposals or order management cannot deal with the increased workload, or finance is unable to raise invoices.
A top down process mapping approach will enable all the improvement initiatives to be kept in step. A BPM Center of Excellence can play a critical role as the business architect; coaching, supporting, coordinating. Just as critical is that those changes in business operation need to be cascaded down the organisation so that everyone understands what they need to do (differently), has the tools to do it, and can see metrics which reinforce behaviour.
I think, we still do know how to design and implement enterprise-wide systems. But “slightly” differently than in the traditional way - see ref1
Not sure I accept the premise. Organizations use BPM to rise to opportunities wherever they arise: back office, sales, customer-facing, etc. To the extent such opportunities involve multiple processes, one might reasonably choose to decompose the problem into bite-sized chunks, because, well, that's how complex problems are best addressed.
For your entertainment: a recent example of what happens when you try to solve your problem from the top down:
Are we really "content" and what do we mean by "a process"? Case Management is a "process" system which will likely have over 50 identifiable processes all working in sync. Maybe the problem is the project is promoted as a “BPM” one when it should be expressed as addressing the business requirement Case Management, Claims Management, Purchase, HR etc. The planning should adopt the “BPM” principles “outside in” people first….and so the journey starts where the initiation of creation of information starts.
This does place importance on the knowledge of just “how” the supporting software actually works to support the vision of delivering on the new end to end system not just the “first process”. This will involve a sound supporting architecture to coordinate all data and that includes people their roles and tasks. So doing research on capabilities is vital if the vision is to create that end to end business requirement. Maybe this is what is lacking in current thinking that results in the very limited approach as expressed in the question?
I guess doing more than one at a time doesn't seem unusual or suprising at all to me. We started a program last year that took 7 processes to production. there was another effort with 2x the people at the same customer that got one process to production, that wsasn't any more complicated than our 7. Not every org, team, or person is ready to do enterprise wide design, nor to break it down into discrete projects. Lots of customers tend to focus on a single process pilot. But the real benefit is when you go wider, if you have the right team to do it.
I feel the need to come back to Tim's question: "Do we no longer know how to design total systems?"
My question to that is: in today's world, what is a total system? How do you recognize it? Has it reached a status where it doesn't require further changes? or further maintenance? is it a self-sufficient status?