Resolved
3 votes

BPM has been around a long time, and still means many things to many people. So with that in mind, what aspects of BPM do you think are dead?

Tuesday, January 13 2015, 09:46 AM
Share this post:
Responses (10)
  • Accepted Answer

    Tuesday, January 13 2015, 10:23 AM - #Permalink
    Resolved
    3 votes

    oh this should be fun. getting out the popcorn :) 

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 10:24 AM - #Permalink
    Resolved
    5 votes

    1. the zero-code myth - if you want your processes to execute and to get integrated into a larger picture, you have to code something in. I have not yet seen a fully integrated solution that gets to executable stage only via the properties panel.

    2. the superficial data modelling - the BPMN standard puts a serious treatment of data outside its scope. This is a mistake. Most data today needs to be persistent and it has to have a logic that is easily accesible by BPMN. Let's say this is not dead, but not yet born.

    • David Chassels
      more than a month ago
      Hey
      Declarative removes hard code the "the map IS the app" sure calculations complex calculations algorithims may need the "geek" input but not the business logic all pre-coded just configure direct with users!
      I thought of BPMN might be dying?
    • Bogdan Nafornita
      more than a month ago
      Declarative may remove hard code in theory (I have yet to see it in practice though), but most real-life processes are not declarative.

      I am struggling right now with this and I happily report that it is a beautiful battle and beautiful code wins everytime :-)

      I started learning a bit of Java, that's how much I believe in the zero-code myth.
    • David Chassels
      more than a month ago
      It is certainly not just theory well proven with early adopters truly adaptive just re-declare changes see research paper http://www.igi-global.com/chapter/object-model-development-engineering/78620 some clues in the summary. Complex or simple really too easy!
      Fact is business logic never changes so make generic store in database ........ Highly disruptive and such as your view has been the challenge.....!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 10:29 AM - #Permalink
    Resolved
    3 votes

    Happily "Analysis Paralysis", the desire to discover, design, document and debate process automation systems, has been replaced by agile implementations that start as prototypes and evolve fast into critical business systems.

    Also, let's not forget, the demise of workflows chiseled in granite: today's best BPMSs can be changed by the users as they self-improve the workflow to optimize their own part of the business. Along with this the once stone-mason guardians of process automation are being replaced by ever eager innovators striving to reduce human effort and streamline business activities.

    • Patrick Lujan
      more than a month ago
      Agree and disagree. Yes, I'm very glad to see that having to map the whole "as-is" and "to-be" processes before cracking open the process console. On the other side though, while I value the users' knowledge of their business processes, allowing them to "optimize their own part of the business" still eventually, ultimately, comes down to a process definition(s) executing on an engine somewhere and sometimes, depending upon "what" is optimized and, more importantly, "how," those user changes can have a negative impact on stability, scalability and performance of the app or the platform both.

      Take those self-improvements and refine them within the context of "this is how the performance characteristics of this app affect the overall performance of the infrastructure its deployed on given the idiosyncrasies - "tips, tricks and traps" - of how this solution, this platform likes to do things, does them well and how, and how not.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 11:04 AM - #Permalink
    Resolved
    6 votes

    Just a list (or is it hopes?): 

    - the idea that BPM is a project  -> No, it's daily business

    - The idea that a process is 'a few blocks with arrows' -> No, that's just a picture of the workflow

    - The idea that every process can be managed 'standardized with a workflow tool' -> No that's just one type of managing a process

    - The idea that BPM = Automation -> Partly it might be, but managing processes needs more than automation

     

    Like
    2
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 11:46 AM - #Permalink
    Resolved
    1 votes

    Yes BPM followed on from BPR as IT (well the enlightened few) in the late 90s recognised how business really worked! In that respect it is a real step change to deliver the next generation people supporting applications that reflect the real world of work is just starting.

    As for what is dead or dying well I guess BPEL for one? Also the BPM tag as application software feels like gone as more recognise it is the BPM discipline in thinking that sets up requirements; the end result should describe what is actually does? The tag emerging is “Adaptive” is the obvious one. It is what we call it and it is not just for Case Management. 

    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, January 13 2015, 11:48 AM - #Permalink
    Resolved
    4 votes

    Nothing dies. It just has fewer followers and supporters.  Is COBOL dead?  This is all described in the Tipping Point principles.  The diagram describes a party, but could be applied to "who thinks BPMN is the only way to go" or "As-Is and To-Be are valuable approaches"

    tipping point

    • Ian Gotts
      more than a month ago
      Forgot to add: The critical thing for BPM is "Which parts / elements / techniques / apps make it over the tipping point". So far the list is pretty short.
    • Peter Johnston
      more than a month ago
      Couldn't agree more. When Moses came down from the Mount with the Ten Commandments, tablets of stone were how you delivered news. We still carve in stone, but it has been a while since it was cutting edge news technology. Some of the process technologies in use are similarly out of date - it can still be done but they have been superceded half a century ago.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 12:24 PM - #Permalink
    Resolved
    2 votes

    My list is only business processes (as the basis for BPM)

    1 Confusion between “planning of work” (i.e. process template) and “observing work” (i.e. process instance)

     2 Process transforms inputs into outputs

    3 Process is a flowchart

    4 Process equals to BPMN

    5 An end-to-end process can be expressed as a flowchart

    6 Process is just an illustration of the real work

    7 Coordination of activities within process may be implicit

    8 Process is a flow-of-resources

    Thanks,

    AS

     

    • BPM Mentor
      more than a month ago
      Dr. Samarin, please tell me why "process transforms inputs into outputs" is dead? What is a process transforming then?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 02:28 PM - #Permalink
    Resolved
    5 votes

    One thing which if it is not dead, should be banged on the head and thrown on the cart Monty Python style is the pricing model.

    I can remember when Business Intelligence meant creating a datawarehouse and building all the integrations painstakingly one at a time. The result was a half million dollar project just to deliver a few graphs to a few executives. Now it is an off-the-shelf app and a few minutes in zapier or something similar.

    In this environment we cannot justify the figures many charge for BPM. It has to come down by a factor of ten or more to gain real traction and take its rightful place as the underpinning technology for the business. 

    The second, surely is Waterfall Development. This Chinese whispers system of Analyst, Architect, Developer makes absolutely sure that the users and customers are abstracted from the process and that the business needs are forgotten when the process finally comes together.

    And the third is IT only process design. Processes need to change fast and the only way to make this happen is for business people to be given the keys. And the way to keep control is to make sure that their decisions are data-driven. By releasing the data the process yields and delivering it in meaningful ways to end users, we can create such obvious areas for change that we can predict how the path will go, eliminating all the arguments on direction, method and measurement of results which dog so many processes. IT only process design says only we can see the data, so the obvious ways to improve the process are hidden from view and people are left arguing from positions of ignorance.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 03:27 PM - #Permalink
    Resolved
    4 votes

    What "aspects" are dead? 

    Maybe the "hope" for agile BPM projects... BPM is in-fact expanding and during its conquest runs into more-than-a-few islands of resistance. The biggest "fortress" standing against the BPM-tide are age-old methodologies (i.e. waterfall). 

    BPM is now entering a new phase where "process aware" applications are the norm. BPM is becoming an add-on core feature to many enterprise back-office systems (applications)...  hence the blending and inter-breeding between technologies and their come-alone methodologies. 

     

     

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 13 2015, 06:37 PM - #Permalink
    Resolved
    5 votes
    1. The idea that BPM is a set of libraries that programmers use to cobble together process applications.
    2. Simulation, possibly the most expensive shelfware ever sold, useful in a tiny percent of cases (missions to Mars, perhaps).
    3. The restriction of BPM to back office applications. BPM is in the field and in the customer's hand. Time to step up our UI/UX game.

     

    • David Chassels
      more than a month ago
      Well said
      Frankly if the supporting BPM software can't support and thus readily delivery the "adaptive" UI you ain't got the right software!
    • E Scott Menter
      more than a month ago
      It's important to recognize, though, that an adaptive UI alone isn't going to solve the mobile UI/UX issue. For example, you may wish to exclude certain elements from a form or search results page to account for the smaller screen size. Or you may change the way certain interactions work. The real issue that the BPM community has generally not had to think too hard about UI/UX in the past, because we've been building applications for colleagues, many of whom are required to use them. Building for customers is a whole new ball of wax.
    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
277 Replies
27/09/2016
David Chassels
270 Replies
27/09/2016
Emiel Kelly
222 Replies
27/09/2016
Bogdan Nafornita
209 Replies
27/09/2016
E Scott Menter
182 Replies
27/09/2016