Resolved
4 votes

Last week's discussion on BPMN vs. CMMN made me want to ask this question. So whether it's a case, a decision, or a process, what would you say is the business case for modeling them?

Tuesday, May 03 2016, 09:47 AM
Share this post:
Responses (10)
  • Accepted Answer

    Tuesday, May 03 2016, 10:08 AM - #Permalink
    Resolved
    6 votes

    Understanding, insight and visibility. Contrary to some's opinions the client themselves, even the people who directly participate in a process, don't always know the process as well as they think they do, much less a given process from end-to-end. As long as not too many cycles are expended on this ad nauseum, ad infinitum (as some do), it's one way to know what's going on, why things work they way they do and what opportunities may exist for doing them better, at the micro and macro level both. Remember, optimizing all the sub-flows of a process don't always result in a fully improved process. Then again, courtesy of the insight modeling can provide when done right, sometimes some part(s) or piece(s) of a process don't need to be, shouldn't be messed with.

    It's about what's the correct process in this particular instance and continually examining that, refining it as business needs and markets change.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 10:20 AM - #Permalink
    Resolved
    5 votes

    I second Patrick's response and would go on to say that it's amazing how well a simple process model can help with communication. You may not be talking specifically about the process, but it acts as a point of reference around which other conversations can take place.

    In a recent project I was reviewing some old dust covered process models to see whether they were worth reusing or chucking away and starting again. I found one (actually there were a few but this one stuck out in my mind) that appeared to have been updated on a weekly basis. I called the guy that had been marked as owner on it. I wanted to chat and find out whether he was a closet process analyst. His job title suggested something very different.

    He told me this "Our area is heavily regulated. We're handed new or changed regulations two or three times a week. In every case we need to assess the impact of these on our operation. We get the team together and we put this process up on a screen and we talk about the policy. It often doesn't impact the process but it helps us to ensure we all have the same frame of reference. And at the end of every discussion there's nearly always an improvement suggestion that we update in the process and implement."

    It doesn't always happen but there are teams out there that find process models highly valuable and they're not even automating anything!

    • Patrick Lujan
      more than a month ago
      Good point about the communication, talking point, common reference parts. It's one of the reasons I always do a process landscape coming out of the gate, the communication there being between the cheeses and the minions. That understanding isn't always mutual depending how far up or down one is in the feeding chain.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 10:20 AM - #Permalink
    Resolved
    4 votes

    It might be helpful to inventory the modeling that is possible under a case, decision or a process.

    e.g. we set up a case, wtih a set of objectives - what is the likely evolution of that case and what are the outcomes for major possible forks in the road?. - we do this the reward goes up but so does the risk; we do that, it takes longer/costs more but with reduced risk, what is our best guess re possible external events that could disrupt the case? Seems like a decision tree would be the way to go here.

    in respect of a process, is it common practice across participants to map, compile, roll out and then have key stakeholders piano play the process? OR do we build a text file that bypasses keyboard entry and tries to stress test the process so that all possible pathways are engaged? Fine tuning here would involve rolling out a process with images of eventual data collection forms to avoid the time it takes to design e-forms.

    When modeling, is it essential to bring together the stakeholders or sufficient to have tthese log into, for example, a GoToMeeting session where the facilitator navigates to show everyone how the processing is moving forward, how the case is evolving?

    One big question is how do you model a process when handoff times between steps can exceed the time to perform steps? (i.e. users may be working on 10 cases/processes at a time and we are asking them to simultaneously pretend to be working on a new process)

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 10:29 AM - #Permalink
    Resolved
    4 votes

    Several ideas come to mind:

    - Getting everyone on the same page as to the as--is process and potential to-be scenario. All participants can plainly see the advantages of the target state.

    - Capturing process details, especially KPIs, that can be simulated and/or used to identify bottlenecks, eliminate waste, and streamline process

    - Documenting process for compliance purposes.

    - Moving from process modelling to process automation by adding data models, forms, expressions, integration, and user interfaces to create a full-blown application.

    Process modelling is normally the start to process automation. In BPM Suites where there is no model there is no application. The advantage to doing process modelling into a BPM Suite is that you can turn it into an application with built-in mobility and analytics.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 10:37 AM - #Permalink
    Resolved
    3 votes

    In my opinion any model should be made to understand/communicate (past, current or future) reality. There's only one question not to forget and that is WHO (executors, auditors, lean consultants) or WHAT (workflow engine, 3d printer) needs to understand reality?

    But, the question talks about business, so I assume that is the people working (in different roles) in the business. But then it's still the question what is the goal of that people? Why do they wanna make a model? What's the problem it should solve?

    And most reasons have been mentioned above. The only thing with a process model, in comparison to models of cars, houses, is that it's not a small version of reality, but just a set of agreements on how to visualize aspects of a process. So to be able to have a common understanding those agreements should be known and have value. 

    In the end, I don't need to understand process models, I need to understand processes. 

    wrote about it on Linkedin.

    And as models are still used a lot for improvement, also wrote a post where I wonder if models are really useful for that

    But, to be honest; the biggest business value is for me! Spending 40 hours ( at € 125) a week modelling processes for my customers. In a process center of excellence of course, so I don't disturb daily operations. 

     

     

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 10:40 AM - #Permalink
    Resolved
    3 votes

    As the model becomes the application build arena so business users at last can see how their ideas come to life v quickly and fear of change is removed indeed becomes the norm. With this comes increased efficiency and effectively a future proof investment in new BPM supporting systems

    Frankly just a model as a theoretical exercise does little to excite business but when the Model IS the App without coders / programmers needed then a new era of empowerment opens up. Also important are all the benefits of transparency for compliance and audit knowing exactly what is deployed.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 10:53 AM - #Permalink
    Resolved
    5 votes

    From ref1 “Help SME becoming #digital” -Properly done, a business process model serves many purposes

    • a model and communication tool during the design period
    • input for project evaluation (including impact analysis)
    • input for project planning and execution
    • an executable program for the coordination of work
    • documentation for all staff members
    • a “single source of truth” for operating control and monitoring
    • a framework for internal control and security enhancement
    • the basis for management decisions

    Thanks,
    AS

     

    • John Morris
      more than a month ago
      As usual Dr. Samarin nails the formal reality of, in this case, modeling. The BPM.com crew has provided many practical insights, but progress is enabled when we understand exactly what our topic is.
    • Ian Gotts
      more than a month ago
      Absolutely. But with a broad set of requirements and disparate audience, one notation and one process model and one process tool (BPMN/ CMMN) will struggle to satisfy all of them.

      BTW Your presentation at Ref1 is perfect... but is says SME but I believe the issues you highlighted apply to every size company
    • Dr Alexander Samarin
      more than a month ago
      Thanks John and Ian.

      I noticed that there is no common understanding that BPM is good for Small and Medium Enterprise as well. For this reason I mentioned SME in the title.
    • Emiel Kelly
      more than a month ago
      BPM is good for every company! In fact they are all doing BPM.

      But maybe not according to the standards the BPM(s) society uses.
    • Dr Alexander Samarin
      more than a month ago
      Emiel, sure. I had to say that BPM is *affordable* for SME as well.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 11:08 AM - #Permalink
    Resolved
    5 votes

    On top of what Patrick and Craig already said, I'd touch upon another important business case for modelling, which is to ultimately enable execution.

    A well-designed and well-explained model that is actually executable in a process engine goes a long way into having the customer not only discover their own requirements (huge problem in software projects), but clarify how the system will actually help them in the to-be scenario. This is huge and removes a lot of friction during the development, testing and acceptance phases of the implementation effort.

    I would argue that even if the ultimate goal of the effort is not a system implementation, making your model run in an actual process engine (and hit all the possible walls in there) turns you into a much better process architect.

    On a funny note: I had one of our consulting partners turn to us a process model that they designed - of course not only that the process could not be run in our process engine, but it made absolutely no sense, conceptually, semantically, not even visually. We asked them why did they design such a thing, they said "oh but it was okay, we just needed it for customer's sign-off as requirement" :-)

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 12:38 PM - #Permalink
    Resolved
    4 votes

    TOP LINE

    The question is not whether to model or not, but "how good are your models?" Because all software is modeling. The business case for modeling can be made, even in the face of skepticism. And those who get modeling right have bought themselves a ticket to the frontier of innovation and success.

    DETAILS

    So many hard-won insights concerning the business value of modeling! And clearly an often essential tool for achieving clarity. Given the putative number of failed monster projects that we all hear about, anything that can help us achieve clarity is likely a good thing.

    That's business value and a business case right there!

    Dr. Samarin has provided some formality concerning exactly what modeling is, which is important because too often we get all tied up in rhetoric and anecdote. Examining his list, one is left with the thought that maybe modeling is not just another artefact of technology but perhaps centrally important.

    Let's take this further. Let's go maximalist and see if modeling maximalism is helpful in terms of business value.

    Before anyone gets scared off however, note that we are "all modeling maximalists now"! On the wetware side, human language is saturated with metaphor, which are all models. And where software is concerned, all software concerns models. A sign signifies an object, and then it's "turtles all the way down" as they say.

    So, now the question is not "is there business value to modeling", the question is "how good are your models?"

    Because models define the things you can do with your software. For example, the accounting models implicit in your ERP system define the options you have for managing your cash flow.

    And the process models that you construct for order-to-cash define how your business can manage order-to-cash inside an automated process system.

    In fairness, the original question was posed as "what is the business case for doing a full-on BPMN process model?"

    But expanding the modeling question allows us to expose some of the most exciting business and technical opportunities at the edge of the world of software technology.

    Here are a few of the touch points between technology, modeling, business value, language and anthropology:

    1) LEVEL CONFUSION -- Confusion between conceptual, logical and physical models in the world of data is implicated many software construction challenges.

    2) LEADING EDGE -- One of the hottest areas in software today is "narrative", closely related to "experience" and "journey" -- and "process". And all of these concepts are in essence models or abstractions of reality.

    3) SCIENCE TO THE RESCUE -- Modeling (e.g. conceptual modeling) is mostly today a craft activity and unscientific. And like most craft work the results are sometimes wonderful, but also limited. Ontology is the work of turning modeling into science.

    4) ECONOMICS OF MODELING -- In terms of business value, consider the question of "well-understood commodity processes". A knowledgeable team can probably build such processes directly, without a lot of modeling overhead, "in their sleep". And that gets the team to the proverbial "80% of the way to completion". That easy 80% may have standard exceptions, so standard that we call the whole thing STP ("straight thru processing"). But the interesting thing is that the last 20% is where "winners are separated from losers" and we have left the island of commodities for the sea of wierd exceptions and complicated non-standard customer needs. And our ship will soon sink if we are building without models. Complexity escalates rapidly, and our only salvation is modeling.

    5) ROUNDTRIPPING -- Mr. Nafornita has mentioned "execution", which gets to the mismatch between conceptual and executable models. Called "the roundtrip problem", this problem is I believe responsible for much of the disappointment since 2000 concerning workflow and BPM technology products.

    6) AGAINST COMPLEXITY -- And most importantly, models are how we manage our interface with rich, complex reality. It is impossible for any control system (whether computer or human brain) to manage without models.

    7) REIFICATION -- And lastly, the very idea of models generates its own problems. The word reification captures the situation where humans treat models "as reality"; once could even say that this problem is as old as humanity given our propensity to idol worship. But the problem is real and regardless of the value of a model, as has been pointed out many times on BPM.com, a model always has the possibility of hiding important aspects of reality which are not represented in the model.

    8) DECISIONING & SIMULATION -- Models drive decisions, the life blood of business. And decisioning-in-the-large can be thought of as simulation, or "imagining the future". Simulation only works insofar as there is a model in place. Simulation is not done nearly as much as textbooks would suggest would be useful, but it's reasonable to expect more business and systems simulations in the future, for multiple reasons.

    There is often resistence to formal modeling. Making a business case for any infrasatructure is always tough. And there are often conflicts of interest concerning modeling and various project stakeholders on both the IT side and the business side. Even modeling itself may be difficult -- which is why most software models in use today are the shared models implicit in ERP systems.

    But if we want to win in the marketplace, we have to be able to build out that "last 20%".

    That means capturing our pioneering business vision not with toothpicks, but with models. And then using those models to build and operate our value chain systems.

    The business case for modeling can be made. and those who get it right have bought themselves a ticket to the frontier of innovation and success.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, May 03 2016, 02:05 PM - #Permalink
    Resolved
    3 votes

    We believe modeling is important. No. More than that. It is critically important when companies are trying to transform themselves, redesign the execution applications, and then get all staff algined and on the same page. It a time of disruption it has never been more important.

    But the modeling I am talking about is top down map/model with a simplified notation (ie UPN - see link). The sort that a business consultant would produce. Historically it is was white board, Visio or Powerpoint - but now there are far better and affordable cloud solutions available. The process diagrams, at the lower levels of the heirarchy, then feed BPMN or CMMN diagrams which are more execution focused.

    UPN - top down, strategic, operational, management, training, compliance

    CMMN, BPMN - requirements, technical, execution.

    For BPM world peace - UPN and CMMN/BPMN need to coexist not compete.

    • John Morris
      more than a month ago
      We've all seen or participated in creating top-level models or indeed any kind of models, the sort that end up covering an entire wall, or filling a binder . . . and then reality intrudes, learning occurs, and the deployed model is no longer in sync with the consultant's version. And no one will pay for keeping them in sync etc. etc. This is all of a technical, governance and sales problem.
    • Ian Gotts
      more than a month ago
      John - absolutely so the models need to be
      1. hierarchical - so the diagrams can fit on a screen (8-10 activities)
      2. online and easily accessible
      3. have collaborative update

      It can and does work in over 1000 clients with some powerful case studies.
    • Dr Alexander Samarin
      more than a month ago
      I think, with a proper BPM architecture many modelling notations may co-exist on top of a common run-time engine (similar to Java and jython on top of JVM). Different clients with their different needs for their different purposes might use different notations for their different processes at different levels of details. Just one thing must be common - understanding that a process is an explicitly-expressed coordination of activities while coordination techniques may be different.
    • karl walter keirstead
      more than a month ago
      Ian . . .

      Re "The process diagrams, at the lower levels of the hierarchy, then feed BPMN or CMMN diagrams which are more execution focused"., is one option, but I think David Chassels' references to "the build is the app" adds simplification.

      Re "online and easily accessible", this is all important. A good Case environment will allow users to both view the models (flowgraphs) and, in respect of run-time instances, see "mark-ups" of each instance showing steps that have been committed, steps in progress and not-yet-current steps.

      Re "collaborative update" it's a challenge to extract in-progress instances of a model and re-position these on an update of that model.

      The easy-to-understand practical example is a a sequence a-b-c-d-e where we make a change at "b" that impacts "d" - instances at "a" present no problem, instances at "e" present no problem, but instances at "c" need special attention.
    • Emiel Kelly
      more than a month ago
      A 'good model' doesn’t have to do much with modeling notations themselves, I think, but with understanding the audience and communicating the right thing.

      Like making a drawing of a house. If it shows plumbing, construction and furniture, it is correct but probably not very valuable.

      Agree that high level start is always ok, to understand the boundaries of the process. To make clear if we really talk process or only (too small) sub process or even (too large) process-chain.

      Bet when it comes to deeper analysis to understand what causes bad process performance, you probably need more detail.

      But, when diving into detail too fast, you’ll see often that several case types and several scenarios are combined in one model. Guarantee for mess. I always try to identify these case types and scenarios during process discovery. To decide if they are all really "one process"

      Wrote more about that in Dutch. Not valuable here ;-)

      Personally my favorite way of modelling is “Result based” . I’ll only model milestones with the final milestone as most important. This stresses the fact that a process is a means to deliver a result and focuses on understanding that result (and it’s parts) first.

      Then think about how it’s created and what resources are needed.
    • Dr Alexander Samarin
      more than a month ago
      Agree with Emiel re good model'.

      I consider that a model is good if it is understandable in less than 30 secs by the "trained" audience (knowing the notation and the business). To produce such models I use a modelling procedure from http://improving-bpm-systems.blogspot.ch/2013/07/bpm-for-business-analysist-modelling.html
    • Bogdan Nafornita
      more than a month ago
      @Emiel: "A 'good model' doesn’t have to do much with modeling notations themselves, I think, but with understanding the audience and communicating the right thing.

      Like making a drawing of a house. If it shows plumbing, construction and furniture, it is correct but probably not very valuable."

      Your second para negates the first one, in case the audience IS the plumber, the builder or the decorator :-)

      My point is: a model's usefulness cannot be judged outside the context of its audience.
    • Emiel Kelly
      more than a month ago
      @Bogdan

      That was indeed my point, but maybe expressed it a little stupid ;-) I meant that the audience is the plumber AND construction AND the decorator.

      Like a process model that is made for working instructions AND compliancy AND improvement AND automation design. (although, if you have a good modeling tool that supports layers ;-)
    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
01/10/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