Resolved
2 votes

From Tim Bryce: 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?

Thursday, November 12 2015, 09:46 AM
Share this post:
Responses (12)
  • Accepted Answer

    Thursday, November 12 2015, 10:08 AM - #Permalink
    Resolved
    5 votes

    One factor is the shortage of development resources who are skilled at implementing Business Process applications.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2015, 10:18 AM - #Permalink
    Resolved
    6 votes

    https://en.wikipedia.org/wiki/Bounded_rationality

    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..."

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2015, 10:48 AM - #Permalink
    Resolved
    1 votes

    'Why are we content doing..' -> I don't understand what that means.

    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, November 12 2015, 11:29 AM - #Permalink
    Resolved
    4 votes

    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?"

    References:

    1. http://timbryce.com/
    • Patrick Lujan
      more than a month ago
      And my own reply would be that that lower, maybe not necessarily "down in the weeds," but certainly "on its way there," conversation doesn't occur on forums such "AS this". Myself however, I have been doing it all along for the better part of two decades now.

      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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2015, 01:16 PM - #Permalink
    Resolved
    3 votes

    Some reasons:

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, November 12 2015, 03:08 PM - #Permalink
    Resolved
    4 votes

    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.

    Green bananas

    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.

    • Emiel Kelly
      more than a month ago
      I don't think this is a good metaphor, because 'a tree full of ripe bunche of bananas' is the process result, not 'one ripe banana'

      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.
    • John Morris
      more than a month ago
      I'm tempted to say "Day-O", per the bananas . . . But bravo the "process maximalism".
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2015, 03:40 PM - #Permalink
    Resolved
    3 votes

    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

    Thanks,

    AS

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2015, 03:48 PM - #Permalink
    Resolved
    3 votes

    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:A decade into a project to digitize U.S. immigration forms, just 1 is online

    • Bogdan Nafornita
      more than a month ago
      I totally relate to that. There's always a resource call being made. Not everyone can afford a "full monty" approach to BPM, which means full architecture planning, BPM steering committee and all that.

      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).
    • Tim Bryce
      more than a month ago
      Here's another one from the USDA:
      http://timbryce.com/2015/07/22/the-usdas-system-snafu/

      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.
    • E Scott Menter
      more than a month ago
      Bogdan: congratulations on walking the client back. We see it all the time: people are impatient, want to boil the ocean, rather than get a couple of wins under their belt to build support and drive demand.

      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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2015, 07:28 PM - #Permalink
    Resolved
    3 votes
    @tim A couple of times you hint at but don't quite come out and say it: us BPM folks tend to over-emphasize the Process forgetting the 'logical database' as you put it (I prefer business glossary or data dictionary but we're talking off the same thing). After all it's not called Business Data and Process Management, though perhaps it should be. 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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 13 2015, 05:26 AM - #Permalink
    Resolved
    2 votes

    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?

    The reply is currently minimized Show
  • Accepted Answer

    Saturday, November 14 2015, 11:06 AM - #Permalink
    Resolved
    2 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 18 2015, 06:19 AM - #Permalink
    Resolved
    1 votes

    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?

    • Dr Alexander Samarin
      more than a month ago
      Are you talking about technical systems or socio-technical systems?

      Thanks,
      AS
    • Bogdan Nafornita
      more than a month ago
      I am not clear, that's why I was asking Tim.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
276 Replies
26/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
221 Replies
26/09/2016
Bogdan Nafornita
209 Replies
26/09/2016
E Scott Menter
182 Replies
26/09/2016