Resolved
4 votes

Very simply, what is a definite sign that a process model will not be a success?

Tuesday, September 13 2016, 09:42 AM
Share this post:
Responses (20)
  • Accepted Answer

    Tuesday, September 13 2016, 09:47 AM - #Permalink
    Resolved
    7 votes

    As soon as you disconnect with your audience... Guaranteed failure.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 09:48 AM - #Permalink
    Resolved
    7 votes

    A single person in the organization thought about and developed the process model without inputs from others !!

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 09:49 AM - #Permalink
    Resolved
    5 votes
    Success is such a general term, that I have to stick to a general answer:
     
    When the process model doesn't help to reach the goal you had in mind with it.
     
    Like
     
    - Employees don't use it as instruction
     
    -The auditor is not interested in it
     
    - The BPM system doesn't understand it
     
    - It has not enough information about the reality of a process to understand why it doesn't perform.
    • Sandeep Johal
      2 weeks ago
      The goal of the model could change, especially over time. Very rarely will there be 'one model to rule them all'. Would there be new models created for each goal? At what point does it stop? How to manage?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 09:56 AM - #Permalink
    Resolved
    7 votes

    A model with seemingly infinite detail, and without the right abstractions to make it easy to understand. A model's first best purpose is to be understood by others.

    • Patrick Lujan
      2 weeks ago
      If we can anonymize them enough to protect the not-so-innocent, we should have a contest.
    • Dr Alexander Samarin
      2 weeks ago
      Do you include computer or machine to "others"?
    • E Scott Menter
      2 weeks ago
      On the other hand, one of the biggest issues I run into is a model that is so high-level that you learn nothing from it; or, alternatively, consists of an odd mixture of very high-level ("Accounting Review") and very low level ("Set Type to 11") of detail. This is an extension of the problem most people seem to have divorcing the context they carry in their brains from the context required to understand a piece of documentation.
    • Scott Francis
      2 weeks ago
      For "machines" - understanding means execution (or, accessible to other functions like search). So I think technically you can include computers but the baseline interpretation of "understanding" would apply to the sentient among us.

      Scott, you make a good point - too high level can be useless for running a process but very useful for understanding it. much like goals are useful for understanding an organization but don't tell you how it works :)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 09:58 AM - #Permalink
    Resolved
    7 votes

    A process model will be not a success if it is not machine-executable. As we know, each people will understand the same model differently.

    Thanks,

    AS

    • Ian Gotts
      2 weeks ago
      Sorry - this this is the blinkered thinking that will sideline BPM into a quiet backwater of technology history. A process model covers the entire business operation (Quote2Cash, Recruit2Retire), and elements of it will be executed by apps
    • John Morris
      2 weeks ago
      Agreed. If it is not machine-executable, then there it is almost inevitable that the original nicely diagrammed model will become increasingly useless, and business interest in the potential of BPM will fail. Why? In other words, SOA programming will be required to make an executable, thus there's a round-trip problem -- which likely means a "one-way trip", and now process changes are only practical in the real executable, etc. etc.)
    • Dr Alexander Samarin
      2 weeks ago
      There are no reasons for "sorry" because the BPM terminology is a mess. For example, I would call Recruit2Retire end-to-end process but not business operation.

      Machine-executable does not mean “fully-automated by one application”. A process model may be an end-to-end process which is a cluster of classic processes (expressed as flow-charts and coordinated between them by some techniques) which are mixtures (with different coordination patterns) of automated and human activities which are a) microservices and h) flows of pages.

      Such a process model is machine-executable on all of its levels.
      Typical situation is that the top level is often an illustrative model which is not machine-executable thus diluted in some apps. Another typical failure is that people try to implement the top-level as a flow-chart (while it usually should be a cluster of processes).
    • karl walter keirstead
      2 weeks ago
      I agree with Alexander.

      And to be inclusive, 'machine readable" includes being able to pick up at a generic data exchanger, postings by local and remote systems and applications (some apps only do batch or semi-real time exports of their data - they will not publish their internal data structures so no way to directly link such apps to your BPMs).
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 09:59 AM - #Permalink
    Resolved
    8 votes

    Very simple : You model for a purpose. If the model doesn't support you in your purpose, it is a failure.

    When it suits the purpose, we can argue what should be on a process model to make it readable and effective.You can for example also agree some conventions around this, just for the simple purpose that everyone uses similar 'language' to understand each other better.

    And don't forget the quote from George E. P. Box: "Essentially, all models are wrong, but some are useful"

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 10:13 AM - #Permalink
    Resolved
    5 votes

    The model is doomed to failure when graphic process maps cannot immediately be compiled to generate run-time template instances in a Case management environment

    Without an ability to carve up a map into individual sequenced steps and automatically post tasks by role as per BPM logical sequencing at individual Cases (insurance claims, legal cases, patients, customer job shop orders) with resource leveling and balancing facilities, thing quickly go off the rails.

    The problems start when there is no seamless transition from plan side to run time side - the organization has no way to manage arbitrary mixes of ad hoc and structured steps at Cases (workers and others inserting ad hoc tasks, users micro-scheduling their tasks, supervisors leveling and balancing workload across Cases based on resource pool levels and changing priorities).

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 10:26 AM - #Permalink
    Resolved
    4 votes

    If you fail to listen to users.....or if users have knowledge that they see as ensuring they have "power" and management not brave enough to take them on....yes true we had such a situation....!

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 10:50 AM - #Permalink
    Resolved
    6 votes

    With the up-front premise that it's going to be implemented on a new BPMS then "when the process model looks exactly like how they do it now." Hanging an existing, as-is process(es) on a new BPMS is, has always been, will always be, a sure-fire recipe for ugliness down the road.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 10:58 AM - #Permalink
    Resolved
    5 votes

    But the real answer of course is:

    When it doesn't fit on one page and doesn't have 5 +/- 2 sub processes.

    • Patrick Lujan
      2 weeks ago
      Lololol, you know those guys? ;)
    • Emiel Kelly
      2 weeks ago
      Yes, the process modeling guru brigade!
    • Patrick Lujan
      2 weeks ago
      The bane of my existence for thirteen years running now. Early on, they were quite the cowboys... 'til their stuff started falling down in the real world. You only hadda go to one New Horizons BPMN class and you were the shite. ;)
    • Emiel Kelly
      2 weeks ago
      BPMN and real world in one sentence....
    • Scott Francis
      2 weeks ago
      lol. that tired old religion has infected a few vendors :)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 11:05 AM - #Permalink
    Resolved
    5 votes

    Spaghetti. If your process model looks like spaghetti -- AND the business team in the room intuitively know that the process shouldn't look like spaghetti -- then your process model is doomed from the get-go (i.e. the model or the sale won't be approved).

    The solution is that any artefacts unrelated to business process need to be abstracted out (integrations, ESB, SOA etc.). And any business rule collections need to be captured appropriately in a decision table (ideally via DMN). Judicious use of collapsable sub-processes is helpful too. The before and after is amazing.

    • karl walter keirstead
      2 weeks ago
      Collapsable sub-processes are good!

      They allow you to present to different groups of stakeholders (high level summary to top management, low level detail to functional units).

      A spaghetti process model makes it next to impossible to follow the flow. Real estate on a computer screen is not a problem.

      We post our flowgraphs on computer screens as single bitmaps, you can scroll up/down/left/right as fast as you can move the mouse and if you find things perplexing you can do a zoom in and show quadrants as in a printed city street map and easily navigate to the right xy coordinates.

      Nothing wrong for "show and tell" to plot the entire process.

      Except that . . . . .other than for end-to-end processes, these no longer are the main event in b2b, much of the time we no longer have "processes' - what we have are "process fragments" (smaller by definition), and we leave it up to users, robots, and software to thread these together at run time.

      But, too much fussing with the presentation is also the wrong direction - after the model or the sale, the main stakeholder is a computer compiler that does not care about other than 1's and 0's.

      All of this was invented in the 1950s (collapsable sub-processes, nice left-to-right flows, many times 4 feet deep and 20 feet along the timeline) in Critical Path Method and no one really complained or today complains about the many many attributes that you can and often need to park at CPM node.
    • John Morris
      2 weeks ago
      Karl - interesting re: CPM and GANTT charts in the 50''s -huge wall charts prepared for US Congressional oversight visitors to show that money for nuclear submarines was being well spent - and then after departure the charts weren't often updated ever again. Or so I've read ....
    • karl walter keirstead
      2 weeks ago
      John
      They were updated (every two weeks) after departure.

      Before flatbed plotters, this was done by a roomful of draftsmen who would re-draw the entire map by extending durations/compressing durations, adding new nodes. Later on they continued to be updated every two weeks and polotted, with huge statistical printouts of ES-EF-LS-LF, projections.

      And, not just for nuclear submarines, but also pulp and paper plants, electric power generating stations etc.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 11:31 AM - #Permalink
    Resolved
    4 votes

    Imbricated gateways.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 11:38 AM - #Permalink
    Resolved
    5 votes

    Great answers so far! I'll add a physical symptom of a process that is going to fail.


    Someone is concerned with access to a plotter to print the process.

    I have personally seen this a few times and none of them have worked out. 1998 called, they want their plotter back.

    • Patrick Lujan
      2 weeks ago
      Ahhh... but they were so awesome in the bullpen. "Look what we're doing! Ain't we grand?! This project is so oresome! Yaaaay us!" LOLOL
    • Rick Willis
      2 weeks ago
      I like to think about it in terms of incentives. If there is a requirement to print out some huge process every time it changes then you have created an incentive to NOT be agile.
    • Bogdan Nafornita
      2 weeks ago
      No plotter here, but 34" screens are really useful for proces modelling :-)

      (guilty as charged)
    • Patrick Lujan
      2 weeks ago
      @Bogdan, fell back to the Dell U3415-W because I missed it so much and dumped the LG 27UD68-W, the ASUS PB287Q, the AOC Q2963PM, the LG 34UM94-P, the...
    • Rick Willis
      2 weeks ago
      @Patrick HAH!

      @Bogdan 34" screens are awesome!! No need to print! That is what I'm talking about when I talk about being agile.
    • Emiel Kelly
      2 weeks ago
      Being agile doesn't happen because you have 34" screens ;-)
    • Rick Willis
      2 weeks ago
      @Emiel True story. The 34" screens aren't agile by themselves. However, they do facilitate making process updates and distributing the information without having to go to Kinkos (are those still around?).

      Also, printing is dumb.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 11:39 AM - #Permalink
    Resolved
    5 votes

    When the people who do the work you're capturing in the model don't use it.

    No matter how many other people may refer to it or use it, it won't matter because it won't be up-to-date if the people executing it aren't using it, finding it value added and making sure it's updated and relevant.

    • Patrick Lujan
      2 weeks ago
      Ruh-roh, do the big four know?
    • karl walter keirstead
      2 weeks ago
      For any workflow that is the slightest bit complex, they cannot do the work, period, if you roll out your process to a run-time environment and issue a "no verbal orders" directive.

      In this culture the only way they can find out that there ire pending tasks is to go to their InTray.

      No visits to InTray, no work, and the worker will soon get onto the redundancy list.

      Self-correcting problem.

      Any worker who does log in but fails to at least click on "done" runs the risk of creating a logjam along the process template instance.

      Sooner than later, they will be on the carpet with their supervisor to explain why the process execution is being held up.

      The NVO directive is very important in healthcare. i.e. we get to a step called 'breakfast meds" - the healthcare professional administers the meds but tells no one The result is a possible double dose. -> serious medical error.
    • Emiel Kelly
      2 weeks ago
      Go to an intray and click on "done"

      The life of a process worker in 2016...
    • karl walter keirstead
      2 weeks ago
      @Emiel,

      Not that easy to just click on "Done" where the data collection form at the step has mandated fields, range check rules etc.

      They can click on "done" however many times they like but the click will not register.

      The choices are

      1) complete the data entry so there are no errors

      2) put the in-progress task back in the task resource pool but make sure the person going off shift or whatever, clearly documents the reason, otherwise the worker will get a call asking for clarification.
    • Emiel Kelly
      2 weeks ago
      I was suspecting something like that.

      We had it at Pallas Athena in 1992 :-)
    • Emiel Kelly
      2 weeks ago
      @Kathy What does, in your opinion, "using a process model" mean ?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 01:24 PM - #Permalink
    Resolved
    6 votes

    Amazing how many of the comments above imply the following (unpopular) conclusion without actually saying it:

    Your model is doomed to fail if it's built on a flowchart of greater than trivial complexity.

    Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model. They can be valuable for documentation purposes (for example, swim lane diagrams). But having now spent a generation trying to square the circle by using flowcharts as the programming language of business process, it's time to bid them a fond farewell and move to a model that doesn't require a plotter, doesn't look like spaghetti, and doesn't run off the page in a way that makes it impossible to follow.

    • Patrick Lujan
      2 weeks ago
      UML activity diagrams with swimlanes, ahhh... those were the days.
    • E Scott Menter
      2 weeks ago
      Don't get me wrong: it's not like I don't enjoy speaking a secret language that people have to pay me to translate for them. :)
    • Bogdan Nafornita
      2 weeks ago
      Scott, I beg to differ on: "Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model"

      We actually design our process apps logic exclusively with BPMN, and this includes technical error-treatment layers. It's a real pleasure.

      Of course, you have to architect them in a way they make sense and decompose them into business services, separate the business rules, carve out powerful recurring patterns for re-use across architecture...

      But there's nothing wrong with BPMN as business application logic... We have yet to encounter a business scenario we can't model and execute directly in BPMN.

      Yes, this does imply using more than 4-5 BPMN symbols and deeply understanding advanced constructs like event-based streaming, multiple-instance syncronization, transactions, compensation, escalation, error-treatment taxonomies, complex gateways etc.
    • Patrick Lujan
      2 weeks ago
      @Bogdan, thus... Volker Stiehl's "Process-Driven Applications with BPMN." The trick, though, is in the decomposition and the understandability which, "yes," is more than one diagram. And patterns be good.
    • E Scott Menter
      2 weeks ago
      Then you may not be looking hard enough. :)

      Nathaniel Palmer and Denis Gagne, inter alia, have written about use cases that are either impossible or extremely difficult to model using BPMN.
    • Patrick Lujan
      2 weeks ago
      Depends upon which platform(s) you use and your use cases. There are good and bad ways to represent case management in BPMN depending upon what you need to do and the platform. Bruce Silver has done some very good blog posts on this and it was one of them, in fact, that turned me on to PDA.
    • karl walter keirstead
      2 weeks ago
      Scott...

      Flowcharts ARE the instrument of choice to build an executable process model BUT, you are right, NOT if the BPMN map cannot be compiled.

      The way we work is "map->compile->run->take note of deviations/mine the data->upgrade the map ->re-compile...."

      On a bid submission, unless the prospective customer specifically asks for paper attachments, we give them a guest account, let them log into our server via RDP, load the map and scroll it (one big bitmap).

      If they give us fake forms (images of real forms) we park them at process steps and they can run the flowgraphs themselves.
    • Bogdan Nafornita
      2 weeks ago
      @Scott, yes, I have been incomplete... We do use DMN extensively next to BPMN. We stayed away so far from CMMN, we find it lacking in execution and severely lacking in communication. Nothing that can't be fixed in BPMN plus a solid data persistence design.
    • John Morris
      2 weeks ago
      Underscore @Bogdan's reference to "persistent data". This is probably the first cause of process failure -- improperly modeled data (which results in unnecessarily complex process workarounds) -- and I would add "low quality data" too.
    • Dr Alexander Samarin
      2 weeks ago
      I agree that ONLY Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model. Obviously, we need a system of standards to build machine-executable process models. For example, around HTML5 there are CSS, DOM API, and several other standards.
    • John Morris
      2 weeks ago
      But @Scott, what will replace flowchart diagrams (or BPMN or similar)?

      A well-specified process is as complex as it should be, no more and no less. Complexity is not inherently bad; although complexity is inherently costly. And given that "life is rich" and "business is complex" (especially if we take on end-to-end processes), then processes will be necessarily complex too.

      I guess my point is that flowcharts or BPMN are, to paraphrase what Churchill said about democracy, a terrible notation -- the only other problem is that all others are worse.

      Some of the strategies here can help using and communicating with flowcharts and BPMN easier . . .
    • Bogdan Nafornita
      2 weeks ago
      @Alex: I did mention that we design the *app logic* exclusively with BPMN/DMN :-) Data logic, UI logic are obviously part of the overall executable solution. And of course engines that open up possibilities of integration with the outside world of digital services.
    • Patrick Lujan
      2 weeks ago
      @JohnMorris, "all of the above." BPMN diagrams at different levels of abstraction, granularity, handoff diagrams, UML class, activity and object diagrams, use cases, user stories. The more complexity, the more understanding is called for. The bigger and hairier, the more participants, the more called for. Have done architectural strategies, reference architectures and technical designs that, in aggregate, comprised hundreds of pages to get a project from cradle to grave. The inflection is 1) model(s) that support your purpose (per above) and that people agree on and, 2) everyone working from the same page(s).

      It is a rarity and it boils down to execution - project management, sponsorship, delivery team - and tenacity, but when it happens it is most excellent.
    • John Morris
      2 weeks ago
      @Patrick, your note is an inspiring speech to encourage the troops: ". . . Shall think themselves accurs'd they were not here . . . " etc. (Henry V, St. Crispin's Day speech).

      A question though: What is unique to software system construction *** where process (and process modeling) are first class citizens of that project? ***

      Tenacity certainly! Architecture certainly! Sponsorship certainly! Etc. Etc. But so too with all well-managed projects, yes?
    • Dr Alexander Samarin
      2 weeks ago
      @Bogdan, of course we use several DSLs to make a complete process-centric applications. But, it is still a “salade mêlée” and a heroic action. Without clear execution logic, standard DSLs and standard APIs for standard DSLs, BPM will be still lacking the long overdue industrialization.
    • Dr Alexander Samarin
      2 weeks ago
      @John RE “What is unique to software system construction *** where process (and process modeling) are first class citizens of that project? ***” This way considerably simplifies /reduces all the unique problems of software system constructions – business-IT gap, agility, devops, flexibility, microservices, apparch, etc.
    • David Chassels
      2 weeks ago
      Flowchart ...Thought that was in history books...? Next generation MDE shows and builds all requirements accepting that all displays in the models are connected to address the KISS principle and keep the users engaged in build of their process. For example a case management process could have 100 models with 500 UIs all seamlessly working together delivering that important adaptive capability.
    • Dr Alexander Samarin
      2 weeks ago
      RE "Next generation MDE shows and builds all requirements accepting that all displays in the models are connected to ..." Perfect. Let us wait for all the 100+ BPM-suite tool vendors will implement it in 100+ different ways.
    • David Chassels
      2 weeks ago
      And hence the importance of business understanding just how the software works to deliver that Adaptive solution not just what the vendor says what it does?
    • E Scott Menter
      2 weeks ago
      Hey, look how on the mark I was with ”fairly unpopular” — who knows, maybe I'm occasionally right about other things, too. :)

      John: “what will replace flowchart diagrams?”. I use a better model every day. The rarely-heard-from but oft-referenced Mr. Silver has said as much as well (though to be fair I would not want to characterize his position as “yeah that’s it we can dump BPMN now”; I believe he feels there is room for both). So whatever we do end up with, we at a minimum have an existence proof that we can do better.

      Others whose message seems (to me) to be, “but what would we do about {insert your favorite standard here}!?” – There are a lot of standards. There was (I assume) a standard for buggy wheels. There’s a standard for connecting your coffee pot to the Internet . There are no fewer than 44 standards for fertilizer .

      Point is, it is the rare standard that is so broadly useful, and meets market needs so thoroughly, that it deserves to stand forever. BPMN isn’t one of them. My job is to overcome business challenges. If the issue can be addressed using a standard three-conductor plug you can pick up at Fry’s, the business will probably figure that out for themselves. But the world is big, and the domain of problems so easily addressed is small. I’m not going to offer my customer a tri-pronged connector if that isn’t going to get them where they want to go.
    • Dr Alexander Samarin
      2 weeks ago
      @Scott, it is not a question to have many standards, but "a system of standards" for a domain-of-interest.
    • Scott Francis
      2 weeks ago
      incidentally, i don't know that anyone said flowchart above your comment, Scott! :) I think you assumed all the comments related to BPMN flow diagrams - and I'm sure most of them did. But the comments about complexity apply equally well to any "model". I've seen gantt charts that made my eyes bleed and still didn't model how the project (process) would get completed.

      Any modeling approach has a breaking point - at which point, change the model or change the type of model, or change the lens :)
    • Scott Francis
      2 weeks ago
      i haven't seen gagne and palmer's work on "things you can't model easily in BPMN" interested in a link! :)
    • John Morris
      2 weeks ago
      Does this discussion make anyone else all tingley? So many contesting and worthwhile ideas. OK, forget the tingley part...

      As for flowcharts or process diagrams or workflow diagrams (whether based on any given notation such as BPMN or not) I'm interested to know how these could possibly be replaced.

      All process projects make use of the usual collection of technical and business tools, including decision tables, work breakdowns, resource tables, etc. etc. but especially flowchart diagrams. (Such diagrams are closely related to information theory sender, receiver, message and channel primitives -- which also aren't going to be superceded and aren't going away.)

      And the goal here is WYDIWYE, i.e. "what you draw is what you execute", in other words an executable visual language of process.

      As notations improve, and especially as execution engines improve, then if it makes business sense, a manager will be able to say "make it so".

      Maybe I lack imagination, but I don't see how flowchart diagrams won't always be with us. They are just the "best graphical expression" of a "good enough mathematical model" of "work".

      OK, I could imagine maybe a virtual reality version of flowchart which would enable one to fly around and navigate more dimensions of work. That would be fun!

      (Forgive me if I have misunderstood suggestions concerning the limitations of flowcharts...)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 06:46 PM - #Permalink
    Resolved
    5 votes

    Simply put:

    If you cannot explain it. Then you cannot follow it. Therefore it is doomed.

    Agnostic to the tools and platforms you choose to use for modeling and executing business processes, the process model needs to be easily explainable. Process, more specifically bad process, often outlives the human capital that manages it or is required to interact with it.

    Complexity seems to be a recurring theme in this thread as to what makes process doomed. Meaning you are able to assess a process end to end in order to determine it's level of complexity relative to another process you have encountered. In order for this to happen someone had to explain it and someone had to document it. Complexity is also subjective.

    Risk = BadProcess

     

    What is the complexity score of a process model that cannot be explained?!

     

     

    • John Morris
      2 weeks ago
      Marvellous mashup of risk (something that is too often not directly addressed in software projects) and language. To "explain" is to surface concepts into language, yes? One has domain knowledge (e.g. of plant and equipment maintenance) which is captured (i.e. explained) in notations and words through business analysis. Hopefully tools share enough via common standards that those standards become a lingua franca . . .
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 13 2016, 09:56 PM - #Permalink
    Resolved
    3 votes

    1. If people working on the model use the term 'process' very loosely and don't adhere to any notation but continue investing into design of such process 'models'

    2. If the model mixes activities from many levels of the process architecture (poor decomposition)

    3. If the process model attempts to describe activities that cannot be described by the model i.e. work stages

    4. If the process model is overly complicated

    5. If the process model attempts to describe dynamic work handling requirements using notation that won't fit the bill

    6. If the process describes modeler' perspective of one's work without properly validating it with the process stakeholder. People view processes differently during execution vs. modeling

    Great discussion!

    BJ

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 14 2016, 12:24 AM - #Permalink
    Resolved
    3 votes

    Reading over the 17 responses plus a fair number of comments on many of these, are we all on the same page as to what a "process model" is?

    1. Is a "process model" a simplification of an actual process such that it has communicative value but no value for "managing a process" in a run time environment?

    2. Do the contributors make a distinction between a "process model" and "modelling a process" (the latter meaning piloting a run-time process template\instance with a small group of stakeholders with a view to identifying logic errors, bad forms and then improving that process)?

    3. At what point in a changing mix from one Case to another of ad hoc interventions versus end-to-end processes do we say we are doing adaptive case management as opposed to hosting processes in a BPMs environment?

    4. For other than simple processes at Cases, if there are multiple branching decision boxes and roles change from one step to the next, do the contributors agree that the level of detail for run-time Case management is a new node when the performing skill changes, or when there is a change in the resources needed to perform a next step? An exception to this rule is one step, performed by one resource over a very long period of time- here we need milestones (i.e. multiple steps) to facilitate assessment of progress.

    • Dr Alexander Samarin
      2 weeks ago
      Re item 1 - As usual, there is a ladder or maturity levels for any practice including business process one. And different people are in different positions of such a ladder. My version of it at the slide 7 in http://improving-bpm-systems.blogspot.ch/2015/06/help-sme-becoming-digital.html
    • John Morris
      2 weeks ago
      Walter, your question No. 1 is the question of the decade: >Is a "process model" a simplification of an actual process such that it has communicative value but no value for "managing a process" in a run time environment? code and complexity, and arbitrary process modeling restrictions -- and when this all becomes apparent you can just hear the enthusiasm escaping from the hole in the balloon.

      Software vendors may even think they have delivered a BPM platform which is executable, but the practical reality of achieving this is a step-function to high. Ultimately the cost of BPM-as-fancy-communications tool in terms of usage is much higher than we think. Not useless -- but very expensive.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, September 15 2016, 07:21 AM - #Permalink
    Resolved
    3 votes

    Maya Angelou once said: 'people will forget what you said...but people will never forget how you made them feel.'

    If models don't make people feel positive, reassured and confident, they are doomed. Models are created to be useful, purposeful, compliant and accurate (as depicted by countless answers in this forum). However, if the modeler and/or consumer don't 'feel' good about them, it's wasted. This has been my biggest professional challenge.

    Sandeep

    https://twitter.com/deepology

    • karl walter keirstead
      2 weeks ago
      A lot of the "feel good" comes from the process mapping environment (easy?/difficult?), from the run-time end-user UI and from the supervisory user UI.

      We noticed after transitioning customers from traditional icon bars/menu bars with hierarchies of forms parked at the options to a single screen UI (fixed time events on a calendar on one side/floating time tasks in a listbox on the other) a dramatic decrease in grumblings re use of the run-time environment.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, September 22 2016, 12:01 PM - #Permalink
    Resolved
    0 votes
    Yep - agreed with Walker Bril above. And what's more - that audience is now using collaboration/chat apps to get work done.
     
    The difference between "here's a giant process model - please follow it" and a helpless face looking up saying - .... but - how? ... has never been more obvious than today!
     
    Honestly, look at people doing their desk jobs every day. Do they look at flowcharts constantly while they are working?
     
    No. They look at chat apps for 3 - 4 hours a day. It's so obvious it hurts.
     
    And try distributing a new flowchart around saying "oh look - we're doing process improvement. we know more about your job than you do." 
     
    Watch everyone shrug and say "yeah - I wasn't following the old flowchart anyway" ;)
    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
278 Replies
30/09/2016
David Chassels
271 Replies
30/09/2016
Emiel Kelly
223 Replies
30/09/2016
Bogdan Nafornita
210 Replies
30/09/2016
E Scott Menter
182 Replies
28/09/2016