From [url="http://timbryce.com/"]Tim Bryce[/url]: Why are we content doing one business process at a time? Why not a whole system? Do we no longer know how to design total systems or is there another reason?
One factor is the shortage of development resources who are skilled at implementing Business Process applications.
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..."
'Why are we content doing..' -> I don't understand what that means.
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?"
Most of the conversations up here and most everywhere else are at a substantially higher elevation than where those who reside on the ground, in the trenches reside. I suspect because the "in the trenches" crowd is in the minority up here and most everywhere else because we're occupied elsewhere actually doing it.
Just my tuppence.
- Patrick Lujan
- 1 year ago
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.
- John Morris
- 1 year ago
Like 'a tree full of ripe apples' or 'a cow full of milk'
One banana is not the result of a process, but only one part of the process result.
Growing apples, growing bananas, delivering milk, they are all different processes, which can be managed separate from each other within one farm. No one needs a BPM center of excellence for that.
- Emiel Kelly
- 1 year ago
I think, we still do know how to design and implement enterprise-wide systems. But “slightly” differently than in the traditional way - see ref1
using platform-based architecture – see ref2
with the pace of clients
with many concurrent mini-projects
with several practical process patterns – see the 5th law of BPM, ref3
with low-code approach
with many microservices
with delegation of a lot of traditional development work to the super-users
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:
Washington Post:[url="https://www.washingtonpost.com/politics/a-decade-into-a-project-to-digitize-us-immigration-forms-just-1-is-online/2015/11/08/f63360fc-830e-11e5-a7ca-6ab6ec20f839_story.html"]A decade into a project to digitize U.S. immigration forms, just 1 is online[/url]
Tim: Not sure I agree on the ACA site, though you've no doubt spent more time looking at that than I have. The issue there seemed to be less one of coding practice and more of poor understanding of the scaling issues. In the DHS/IBM case, they spent years in the design phase of a waterfall development process. Bottom-up designs are inherently more iterative. If they'd put together 95 teams to each automate one form, we wouldn't be left with a single form a decade later. We might easily be facing other issues, sure: for example, look-and-feel might not be consistent, or you might be able to use PayPal in connection with one process but not with another. I'd argue that nonetheless, they'd be way better off than they are today.
- E Scott Menter
- 1 year ago
But what makes you think either one is "top-down"? Instead, I suspect it was "bottom-up" meaning they rushed to programming before understanding the problem or the system architecture. This is how the Obamacare system was done, costing taxpayers over $400m. I've looked this over and know it should not have cost anything more than $1m.
So, I'm back to my question; do we know how to perform system design anymore? So far, I have seen nothing in these responses to lead me to believe that we do.
- Tim Bryce
- 1 year ago
I am now working for a client that is 18 months into a 17-processes-at-once project. Not happy. Some processes do not work as intended, some have not yet been tested and some are not even finished.
I am trying to regain this client's faith in BPM, he still believes in it but what he's experienced was unpleasant, to say the least (blame is on both sides).
So I did a simple taxonomy, a short prioritization and concluded we need to attack source-to-pay. I asked the customer to let me do it piece by piece (I also don't have a lot of resources). Two weeks later, I am already launching the first process into full testing tomorrow (vendor master data management flow and portal, with web services and in the cloud, all from scratch).
He's seen the result so far and he's thrilled (me too).
As Ian says, "There is only ONE business process" - maybe not literally true but we certainly know what he means. And if you try to describe it without reference to how the data changes along the way you surely have a recipe for disaster.
So imho it's not so much that we are content to do one process at a time; it is certainly valid to look for quick wins and thus focus on a subset of the end to end process, then iterate. But this MUST be done in the context of a holistic process, data and for that matter organisational model if the catastrophic late surprises of those high profile projects that we've all encountered are to be avoided.
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
[b]total system[/b]? 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?
- Page :
However, you are not allowed to reply to this post.