Resolved
5 votes
Lloyd Dugan gave a presentation at bpmNEXT calling for a simplified CMMN. Lloyd's presentation is summarized on BPM.com here.
Anatoly Belaychuk proposed that much of what can be done in a simplified CMMN can and should be modeled in BPMN. He makes his point here.
So do you think we need a simplified CMMN, or should we just learn how to use BPMN better?
Wednesday, April 27 2016, 06:56 PM
Like
1
Share this post:
Responses (19)
  • Accepted Answer

    Wednesday, April 27 2016, 09:46 PM - #Permalink
    Resolved
    4 votes

    Can't see the need for "Case Management Notations".

    For us, a Case is just a "bucket" that hosts workflow/workload and auto-builds a history.

    You can call structured BPM "process fragments" from within a Case, insert ad hoc interventions (processes of one step), attach documents, files, images, video/audio recordings . . .

    As for the value of notations/languages for business process managment in a BPMs, several members in our group transitioned over decades from deterministic flowgraphing (CPM), to CRM, to workflow/BPM and from there to ACM/BPM.

    We worked in manufacturing, heavy construction, data processing, securities trading, aviation, software manufacturing, and management consulting, with the following observations:

    • No particular notations or languages used
    • No sense of being at a disavantage
    • No problems of scalability.
    • No problems getting end users at customer sites to build, own and manage not-too-complex processes (given help building rule sets, and help with data flows across processes),

    Our basics are nodes, directional arcs, plus a few "complex constructs" such as lassoing two or more nodes to build a branching decision box; putting escape counters on automated loopbacks etc.

    For really complex processing needs (i.e travelling sales, medical diagnostic algorithms), we prefer to build and link to specialty apps to avoid rolling out bloatware where no customer uses more than say 5 % of all of the "features/functions".

    On the topic of Case Management, our view is that Cases are managed by Case Managers.

    Several methodologies, one being FOMM (Figure of Merit Matrices), greatly simplify Case Management (reducing subjectivity from progress assessments). Fortuitously, ordinary spreadsheets with a one-page instruction sheet allows Case Managers to implement FOMM.

    Putting a good Case Manager in charge of a Case seems to have the greatest impact on improving outcomes.

    • KM Mukku
      more than a month ago
      Totally agree. Case is not deterministic, and if you attempt to squeeze all the nondeterminism out of it by some notational straitjacket, you end up with a box-and-arrow diagram which we already have.
    • Lloyd Dugan
      more than a month ago
      As a procedural language, BPMN is a largely deterministic way of looking at processes. CMMN is a declarative language, and thus is not so encumbered. So, if you feel that cases should never be modeled, there really isn't more to be said because understanding of cases can never be captured in representation whose semantics we can share and use to communicate about it.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 03:39 AM - #Permalink
    Resolved
    3 votes
    In essence we don't need any notation.
     
    We need to get work done; processes need to be executed to deliver what we promise to our customers.
     
    But somewhere in time, someone decided that processes need to be (re) designed and automated.
     
    Then someone decided that we need a standard to model and communicate about processes.
     
    Then someone discovered that "steps in a predefined order" is only one type of process and that "a big mess with succes" is also a process.
     
    Then someone decided we need a standard to model and communicate these "case management style" processes.
     
    Then someone discovered that sometimes, decisions are taken in processes.
     
    Then someone decided we need a standard to model and communicate these decisions.
     
    Then someone heard someone shouting "Please can you help me?"
     
    Someone replied "Who are you?"
     
    Someone replied "I am the customer and I've been waiting for finishing of my case very long, now!"
     
    Then someone replied "Sorry, no time. We are busy discussing if we should apply BPMN, CMMN or a combination"
     
    "Bye" said the customer.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 09:38 AM - #Permalink
    Resolved
    8 votes

    Well...the anti-modeling crowd has been heard from. I've never really understood the thinking behind those who are so dismissive of modeling and the need for standards-based modeling languages. Generally speaking, the usual arguments - about moving the tacit to the explicit, supporting reengineering and/or automation, facilitating interchange between domains, yada, yada, yada - never seem to move them off their fervent belief that it is unnecessary. With respect to that crowd's perspective, I would suggest Peter open up a different thread where for that discussion. This thread is intended to air out the CMMN vs. BPMN debate as to which is better for modeling case management situations, as a follow-on to the two papers that Anatoly and I have published elsewhere on the site. FWIW, I do intend (later today) to summarize the extensive back-and-forth between Anatoly and myself in order to help frame the discussion, and, if necessary, jump-start the thread.

    Like
    1
    • Emiel Kelly
      more than a month ago
      Wow. promoted from the "Processes should be executed" crowd to the "Anti-modeling" crowd. ;-)

      Although I've never seen a company that had a mission "to model our processes", I'll use them sometimes if needed.

      https://www.linkedin.com/pulse/i-always-model-my-processes-scale-125-emiel-kelly?trk=mp-author-card

      https://www.linkedin.com/pulse/process-models-really-useful-improvement-emiel-kelly?trk=mp-author-card
    • David Chassels
      more than a month ago
      Certainly not anti modelling more anti notation? When it is recognised that build is in the model which we know reallyy does deliver on all business requirements then the game changes...big time. No need for notations of any sort to build complete case management or any other enterprise operational application. requirements.
    • Keith Swenson
      more than a month ago
      I would like to see a debate between CMMN and DCR Graphs.
    • Lloyd Dugan
      more than a month ago
      Don't necessarily agree on "build is in the model" assuming I really understand what that means. And, I mean no offense to the anti-modeling crowd. Its just that there is not much point in discussing the differences in modeling techniques with those predisposed to eschew modeling at all. My suggestion, again, is that should be in its own thread.
    • karl walter keirstead
      more than a month ago
      Who, exactly, are members of the "anti-modeling crowd"?

      Modeling of a compiled, rolled-out process map where users launch multiple instances and piano-play a process template can provide insight into errors in the logical linking of steps, missing/redundant steps, use of inappropriate/inadequate data collection forms at steps, errors in rule sets, incorrect role assignments at steps.

      All good, but the point is what role do notations/languages play in all of this, other than, as Emile implies, slowing down delivery?

      It might be worthwhile to widen the CMMN vs BPMN. debate i.e. which is better for modeling case management situations "CMMN, BPMN, or Case Managers" ?
    • Lloyd Dugan
      more than a month ago
      I truly meant no disparagement with the use of the label "anti-modeling crowd," but when one is hostile or even indifferent to the value of modeling, then there is not much point in arguing about approaches to modeling, which was the original intention of this thread. Oh, well.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 09:41 AM - #Permalink
    Resolved
    5 votes

    While I was at IBM, we extended the Event Driven Activity notation in BPMN to be able to express Case work patterns quite effectively - Those are now a standard part of IBM's platform. CMMN provides more clarity when the majority of the Activities are Ad Hoc, but you could live without it.

    What we learned from adding "Case Like Work" to the BPMS was that it's the End User's View that is the true differentiator between Case and BPM. In BPM the users typically work from a list of Tasks, in Case they work from a holistic view of the instance that aids them in deciding what needs to be done next.

    That's the frontier we need to focus on - Defining the appropriate interface for the workers in a more declarative way.

    Like
    1
    • Lloyd Dugan
      more than a month ago
      Yes, and Oracle did something, and so did Pega, and so did Appian, etc. - each in their own idiom. This just seems to support my position that BPMN's execution semantics are generally considered inadequate by the BPMS community, leading to endless variations, defeating the purpose of having a standards-based modeling language.
    • Scott Francis
      more than a month ago
      there's a difference between "inadequate" and "more convenient". we solved case problems using Lombardi BPM in 2003. pre-BPMN, let alone pre-CMMN. and in 2004 2005 2006, 2007 ... post bpmn and pre-CMMN. As Bruce has pointed out elsewhere, the engines have always supported adhoc / case style work. the only question was whether the modeling environment did (they do), and whether the "official" notation does ...
      And then the secondary question is whether you need only a few mods to BPMN, or a whole different notation :)
    • Lloyd Dugan
      more than a month ago
      With all due respect to Scott and John, I'm not all that impressed by vendors "solving" these problems. I pretty much expect them to do that, and those that do it well succeed in the marketplace. However, "inadequate" vs. "more convenient" is not a pOtato vs. pAHtato moment - it is instead a largely self-serving, though true, acknowledgement that BPMN has limitaton. Which was the central thesis of the presentation at bpmNEXT. As to whether or not that was necessary on the part of the vendors, it is notable to point out that many of the 12 top-three winners at bpmNEXT the past four years - with very few exceptions - have been been overseas vendors who have "solved the modeling problem by largely working with the associated specs. (It has been exception not the rule that domestic domestic BPMS vendors have been in that list.)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 09:45 AM - #Permalink
    Resolved
    3 votes

    As others have already mentioned, a case is a repository of meta data that is workflowed around the organisation. The vast majority of the case management implementations fail due to the lack of the end-to-end process capture of the what is required pre and post the cases being managed. If you think that BPMN will be the answer to that problem then you are very much mistaken. What is needed is a fast, easy to use, easy to understand notation that is created and understood by the case workers. BPMN is defintely not the answer.

    However, you do raise an interesting question and that is do we need a case management notation? Well, the answer is still No. So the question is, "what do we need to ensure that the end-to-end process where cases are managed and workflowed as part of the process?". As an example, in the legal sector, where cases are known as matters, the Partners of the firm run and manage their cases in many different ways and the downstream case teams need to be agile and flexible to support the many variations of workflow. Do you think that a Partner in a Law will engage in a Case Management optimisation workshop where some consultant is using BPMN? I don't think so!!

    So, the answer is simple - but you need to be a true process professional and a leaderto understand why this is the answer. The answer lies in embracing the new kids on the block. If you haven't checked out Skore Labs then you are just living in the past. This is where the answer lies.

    • Emiel Kelly
      more than a month ago
      " the Partners of the firm run and manage their cases"

      That's what it's all about isn't it? Bringing cases to a good end.
    • Lloyd Dugan
      more than a month ago
      "...need to be a true process professional and a leader to understand..." is a fairly arrogantly presumptive position to take. More to the point, this is not the debate that this thread was to generate. Unfortunately, the original intents has been OBed.
    • Scott Francis
      more than a month ago
      nice advertisement
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 10:08 AM - #Permalink
    Resolved
    5 votes

    By definition, debates "CMMN vs. BPMN" are endless because there is no BPM architecture. Let us have it finally. Otherwise the BPM community may lose good opportunities - see ref1.

    Thanks,
    AS

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 10:10 AM - #Permalink
    Resolved
    4 votes

    Hi all !!!

    Thinking in "be simpler" to be "efficient" ....

    Thinking that current version of BPMN offers artfacts that are able to represent "Case Management"

    Why work in another notation to represent something that is part of business process?

    I'm favor to explore and use BPMN.... or any other that is capable to represent business process and his universe.

    Otherwise, We have to work in 3 levels of notation for many of our process and bring complexity for the effort and for the business process management:
    BPMN
    DMN
    CMMN

    And the question would be Which values these will bring for the business?
    Maybe CMMN can be used in very critical business process...but if currentlymany organizations does not have many of their structured processes managed and modeled, how to advance for complex decisions?

    Rgds, M

    • Lloyd Dugan
      more than a month ago
      The ability to navigate among these 3 separation of concerns was amply and effectively demonstrated by both a modeling vendor and a BPMS vendor at bpmNEXT, so I would hope that this cause for celebration. But thanks for being the 1st response remotely germane to the topic.
    • Marco Mafra
      more than a month ago
      Thanks Lloyd !

      I'll take a time to view the presentations of bpmNext and your article
      "Simplified CMN: A Modest Proposal"

      M.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 10:29 AM - #Permalink
    Resolved
    5 votes

    Short answer: You need context, context and context.

    With regards to notation, this depends (as always) on your audience. If you need to create a case-type definition, representing the objectives of that specific case is pretty important. On the other hand I regard BPMN or petri-nets as a technical notation for a technical audience. Meaning that carbon life forms probably won't read / understand it. And as that happens, any notation that cannot bring the message accross, is missing the point.

    So basically I wouldn't care much for yet another notation, unless it is able to address all audiences in one go :-)

    Like
    1
    • Lloyd Dugan
      more than a month ago
      My hope is that CMMN - especially a simpler version (subset) of it - will be more understandable.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 11:08 AM - #Permalink
    Resolved
    5 votes

    Al models are wrong but some are useful said Albert Einstein. Both BPMN and CMMN are not useful for the business people who are supposed to create the cases and processes.

    Business people want business language and nothing else. Their notation musst be a context sensitive rule language editor in which they can define and execute commands, write decisions and describe goals and map variable data in a simple syntax. The graphical notations are ok for techies doing complex GUI and orchestration.

    We use an ontology to enable well defined business terminology including constraints, validation and conflict resolution.

    We take it a step further and use that to describe the business architecture that is the basis for objectives, targets and goals. Business users can describe their user interactions in well-structured user stories that can be actually executed ...

    All other modeling will simply go the way of other non-user friendly stuff ...

    Like
    1
    • Lloyd Dugan
      more than a month ago
      Actually, that was George Box, not Albert Einstein who said that (see https://en.wikipedia.org/wiki/George_E._P._Box). As part of my presentation to bpmNEXT, I offered my current work in mapping standard concepts in Bus Arch to CMMN concepts, which I found to be clearer than what could be attempted with BPMN.
    • Max J. Pucher
      more than a month ago
      Would you believe that Einstein would plagiarize that? Anyway, mapping standards for BA mapped in any way to any notation like BPMN or CMMN is doomed to fail. What you might find clear is completely useless to a business person.
    • Lloyd Dugan
      more than a month ago
      Well, your assertion is just that. It is not one with which I agree, based on my work to date, which includes using doing it exactly that way with "business" clients. (Just once, I'd love to see something other constant streams of hubris from the pundit class.) With respect, it would be better to see this at the meta model level, which is where conceptual irregularities are resolved. The tooling interface can hide that, so there is nothing that can't be worked out that the business analyst can't come to understand and use.
    • Scott Francis
      more than a month ago
      I'll take ontology for 400, Alex.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 11:22 AM - #Permalink
    Resolved
    6 votes

    First: I am a big fan of a simple task list. Eveyone knows how to use it. There are huge, multi-million dollar projects that are run on check lists which provide everything needed. This is well proven territory.

    Between the fully imperative modeling style of BPMN, and the checklist, there is room for a declarative modeling style that states what can not be done (excludes certain transitions) but otherwise allows anything else, including doing nothing. Offerings in this space:

    1) CMMN gets a lot of air time but not the only game in town

    2) DECLARE is a graph model languange that offers flexible and intuitive partial sequencing of activities. Yes, it includes arrows.

    3) DCR Graphs - (Dynamic Condition Response) has arrows that enable activities (like guard conditions), as well as arrows that can DISABLE previously enabled activities.

    4) SCIFF - a formalism for declarative programming describe as allowing abductive expressions which some say better represents social interactions.

    5) BPMN-D is a declarative extension of BPMN. Best of both worlds! Maybe....

    6) Coloured Petri nets - probably not friendly enough for business users, but stands on a rigorous formal foundation.

    Of al these, I have seen DCR graphs applied to real world problems, and the results feel quite natural and readible. Are these necessary? Hard to say. People have a natural tendency to reduce problems to (sometimes) oversimplified forms (the reductionist falicy) and give that there is a desire to automate in an attempt to avoid what is seen as unnecessary complexity.

    But we should start with a checklist, and only when we find a problem that can NOT be met with a checklist, only then consider declarative programming models.

    • karl walter keirstead
      more than a month ago
      Agree with "..we should start with a checklist, and only when we find a problem that can NOT be met with a checklist, only then consider declarative programming models"
    • Emiel Kelly
      more than a month ago
      I love coloured petri nets. Who says I don't like modelling? ;-)
    • Lloyd Dugan
      more than a month ago
      When one starts with the premise that a model is not necessary, then there is no point to trying to find one. If one starts with the premise that modeling is useful up to a point, then the journey of discovery can commence.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 12:12 PM - #Permalink
    Resolved
    2 votes

    The future does not need any notation language with all business logic readily pre-built for configuration in the model. Remember business logic has not nor will change where information is created by people and machines.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 02:12 PM - #Permalink
    Resolved
    4 votes

    There is a need to be able to communicate the totality of an application (process, data, rules, etc.) to the business. That will always be a huge challenge, because the people doing the work typically don't share a mental framework with the people analyzing the work.

    Notations are an admirable attempt at bridging that gap. But, having spent over a quarter of a century happilly married to a technology-challenged musician, I can attest that fundamental differences in ideation can be awfully hard to reconcile.

    There's a joke: a businessperson, an analyst, and a BPMN consultant are visiting Wisconsin, and happen upon a field, wherein they observe in profile a single black cow browsing in the tall grass. The businessperson says, "I guess the cows in Wisconsin are black." The analyst replies, "Well, at least one cow in Wisconsin is black." The BPMN consultant testily corrects them: "All we know is that there exists at least one cow in Wisconsin, at least one side of which is black." They stare at one another in confusion for a moment before deciding to get the hell out of there before the taxonomy consultant comes along and tells them that what they saw wasn't even a cow to begin with.

    I hope that clears things up.

    • E Scott Menter
      more than a month ago
      As it turns out, the taxonomy guy did show up, and told them it was actually a tractor.*



      *) If you don't get that joke you should come to bpmNEXT next year. :)
    • John Morris
      more than a month ago
      Paraphrasing Hegel, BPM without notation is a "the night in which all cows are black."
    • Lloyd Dugan
      more than a month ago
      The CMMN guy would say we need more cow bell. ;-)

      In truth, though, the BPMN guy can't tolerate any ambiguity because of the BPMS, but the CMMN as a declarative language is not overly concerned with procedural ambiguity.
    • Scott Francis
      more than a month ago
      If you're using the right BPMS (and there's more than one right answer) it deals with "ambiguity" as well as CMMN. (actually there is no ambiguity in either case, only a lack of definition of details that aren't needed, potentially, such as ordering of occurrence.)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 02:29 PM - #Permalink
    Resolved
    9 votes

    Wow, everybody riffing on this one. There is no doubt that BPMN semantics can handle case management, as John Reynolds and Anatoly have demonstrated, Virtually all BPMS vendors have taken this approach because a) their BPMN engines can already do it; b)the spectrum from structured to unstructured process is continuous not binary; and c)what user in their right mind wants two languages and two engines when one will suffice? For that reason, it is pretty obvious to me that CMMN will never achieve liftoff. Lloyd may have the spec on his side re official BPMN operational semantics, but honestly these fine points are in the parts of the standard that BPMS vendors ignore anyway in the effort to build something that works.

    You can use event subprocesses for case models, or as Anatoly does, independent processes coordinating state via messages and shared data. The problem with both these BPMN approaches and with CMMN, "simplified" or not, is that the diagrammatic representation is not particularly helpful in depicting what is going on - where things start, where they end, the general flow of getting from here to there. My own takeaway from bpmNEXT, where we saw many different ways to attack case modeling, is that Scott Menter's Process Timeline approach (basically a Gantt chart) is a more useful representation than any of these standard notations. I'm surprised he didnt mention it. Or maybe he was just being ultra-subtle.

    Like
    1
    • Lloyd Dugan
      more than a month ago
      Yes, riffing, but mostly off-topic. I'd hoped for a semantics-focused discussion, but no one seems interested in that. If your point is that vendors ignore BPMN semantics, then that proves my point that it has reached its zenith in adoption, which means it ended fairly unfulfilled/unrealized. Regarding the problems that remain with the Collaboration approach, which will (for better or worse) rely on the spec, I'll post that separately. I would say, though, and with respect to your immense body of work, "flow" is not as necessary as you all think, and is largely irrelevant in an ECA-driven view of the world.
    • Anatoly Belaychuk
      more than a month ago
      Lloyd, I'm slightly disappointed, too. Didn't expect that the common rule of internet "don't follow the link, just start commenting" is applied to BPM.com forum :( We won't make much progress by just expressing opinions; what I appreciated in your approach is that you've investigated the real business scenario.

      As for the Process Timeline, it's a very natural representation of work indeed but it seems to work well only for scenarios without loops.
    • Emiel Kelly
      more than a month ago
      Lloyd and Anatoly,

      I read the stuff behind the link, but it triggered the "Processes need to be executed, not modeled" part of my brain, which led to my reply. But you're right; discussing the usefulness of modeling in itself, should be another discussion.

      About the timeline notation; in the nineties at Pallas Athena we had a product called Flower . It also had some kind of time line (we called it statusline) which showed the progress of a case. It was able to cope with loops. At that time that 'Total status view of a case' was quite new, but not always understood well by executors "I just wanna do my task, I don't care about all that other tasks in the process"
    • Bruce Silver
      more than a month ago
      @Lloyd, I think it's an overstatement to say that vendors are ignoring BPMN semantics when they add adhoc and event-based extensions, such as those mentioned by John Reynolds. They should be considered extensions. If they break some rule in the spec, it is certainly not breaking the overall semantics. And as I said, all BPMS vendors do that, and it hasn't caused them to say BPMN is dead, long live our new proprietary language.

      As Anatoly demonstrates, and as W4 has demonstrated repeatedly, you don't really need to add new stuff to BPMN to allow ad-hoc and event-triggered activities. In my own classes, we talk a lot about multi-pool structures to handle the instance-alignment constraint of a BPMN process; if there is batching in your business process, you often need to model it as multiple BPMN processes. The advantage of the multi-pool approach, i.e. Anatoly's method, over non-interrupting event subprocesses is that the coordination between pools via messages and shared data is visible in the diagram. BPMN doesn't give independent event subs a clean way to coordinate outside of shared data. I would call that a minor deficiency in the spec - let's just allow intra-process messages! - but OMG has signaled it will let the BPMN RTF expire without further changes. They are declaring victory I guess.

      So clearly you don't need a new language like CMMN to add the semantics. The problem is really visual representation. Don't be baited by my word "flow". If you are an arrow-hater, fine. Process Timeline does not need arrows to indicate generally where things start and what constitutes completion, and the diagrams lead the eye from one to the other. My representational problem with both the BPMN elaborations and CMMN is that neither does that.
    • E Scott Menter
      more than a month ago
      Bruce: thanks! I'm blushing. :)

      Anatoly: Also thanks! One note: Process Director actually has very robust iteration features. Maybe that can be my topic for next year. :)
    • Scott Francis
      more than a month ago
      And actually, this stuff isn't off topic at all. "So do you think we need a simplified CMMN, or should we just learn how to use BPMN better?"
      The argument that simple additions to BPMN address the issue is basically the split down the middle:
      1. simplified CMMN (or maybe even less?) is plenty good, and 2. we have already learned how to use BPMN better by tweaking it to include a few well-defined items from CMMN-style.

      So... if that's the case, then the question is do we need simplified CMMN? or do we need tweaked BPMN. Not off topic, just a place that, perhaps some didn't want the conclusions to go. but you know, you follow the data and then form conclusions. That seems to be the data reported here.
    • Lloyd Dugan
      more than a month ago
      Sorry, but it is off-topic. A simplified CMMN works within the spec, but a tweaked BPMN is nothing more than proprietary extensions or breaking of the spec, They are not the same, by any reasoning.
    • Lloyd Dugan
      more than a month ago
      Turning BPMN into the next proprietary language was not, I would think, its intention. As to what has or has not been proven, whatever John asserts is irrelevant. What was hoped for on this thread was that a focused, scenario-driven examination would ensue that helped to sort out what are rather complex conceptual challenges. What was not intended, but should (upon reflection) been expected, was the outpouring of assertions as proof, especially by those who both know better and are capable of better. Though it may be in vain with this crowd, I'll post my comments on Anatoly's model at the end. For those brave enough to have such a discussion, then please read on. For those that considered the matter settle, I say "Namaste".
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 28 2016, 03:19 PM - #Permalink
    Resolved
    3 votes

    BPM is the technology of work automation; at its core is process language, or more specifically at this time "technical process notation". The fact that these notations are currently inexpressive for the purpose and aggravating for managers to use should not be seen as anything more than technological immaturity. There's a huge win waiting for whoever can deliver the business process management automation technology that business needs.

    tl;dr

    Practitioners, engineers and theorists circling the elephant and each identifying an important facet of the meaning of the thing.

    And what is the thing, but the technology of the automation of work, i.e. where the concepts of work are first class citizens of the technology. And this is a statement which is by definition only true of BPM technology. And from a business and sales perspective, BPM should therefore be pretty important. And likely more successful than it is -- except the technology isn't yet sufficiently expressive and efficient to match the need or the rhetoric.

    If there is to be a fruitful discussion about the development of BPM technology, one must consider the science on which the technology is engineered. Ontology is usually the term that comes up, and only @Max has mentioned it, along with the idea of "business language". (All other references to language are to technical languages.) And @Keith has mentioned graphs, which are also science, i.e. mathematical formalisms, which may support highler level human-friendly business and work languages.

    I have previously compared BPM to accounting and finance. All business people, in greater or lesser degree, do accounting and finance, as a matter of course. And accounting theory, practice and tools are available to help them do this work faster and more accurately. There's no quibbling about "models" or "notations" or "round-tripping" or "waiting a month to change a chart of accounts". This is the future to which BPM technology will evolve.

    At time "x" in the future and like accounting and finance, BPM will also be part of common business technology; all business people will use BPM as a matter of course. The technology will support "task automation for which what you draw is what you execute -- immediately, in flight". Underlying future BPM technology will be expressive but invisible notation that easily supports just about any way of working. If it makes sense to perform work in a given way, then technology will exist to help you do that.

    In the meantime, there should be no "modeling or anti-modeling question". Technology and language by definition concern abstractions. There are just inadequate languages which most business people find unsatisfactory. And so today, the business process management is often still not fully automated, and the sufficiently expressive language used by managers for process management is just the spoken and written vernacular.

    The goal of powerful BPM automation technology, widely adopted, is becoming easier to imagine. And in some cases, the future is already here -- but, as William Gibson said in 1993, "it's just not very evenly distributed yet".

     

    The reply is currently minimized Show
  • Accepted Answer

    Friday, April 29 2016, 10:09 AM - #Permalink
    Resolved
    2 votes

    I disagree heartily that BPM should be about automation. Process management is about automation diagrams but add 'business' and it is not. Yes, it is today about automation but that does not make it right. It rather shows the people doing it quite shortsighted and inept in understanding what a business is about. In fact a business is not about processes at all. A business is about collaboration and it ought to achieve well-defined goals that produce the target numbers defined and follow the larger business objectives layed out in the strategy. Automation in human collaboration does the opposite of what it is being sold for. It does neither make it cheaper, nor does it bring higher quality from a customer perspective or make a business more agile. These are empty claims that anyone with somewhat of a business acumen knows them to be. It gets even worse when experts are needed to define processes and even they have to follow a complex methodology to make them work, just like the business has to go through a 'culture change' to make BPM viable ...

    Is anyone proposing all that even listening to what they are saying? It is highly unlikely that any of that will have a long term impact and much less pay for itself one way or the other. And that was the very clear message consolidated from the discussion in our last management seminar by the participants. BPM is too complex (both methodology and tools), to expensive and kills agility and creativity and reduces customer service quality in the mid-term. Yes, the checklists that Keith proposes are kind of simplistic goals and goals defined in cases go a long way. So there is a direction that will flourish.

    BPM (or whatever it will be called in the future) and its proponents will only survive if they step out of this arrogant attitude that BPM is the silver bullet. Actually most companies who don't do BPM do pretty well if they have a customer service attitude. There isn't a business that has been saved by BPM. How much BPM is REALLY done? 3-5 percent of what a business does is at best implemented and over time the processes are amended with bypasses and ad-hoc external fixes to keep them alive.

    The key for applications is after all is usability and user-friendlyness and in fact customer service friendliness. BPM driven, rigid customer service is not good and certainly not better than a service clerk with a good attitude. So yes, BPMN is about automation and we also use it for that but it is not about business process. BPMN is another form of application coding and it needs experts. I find the discussion about BPM or ACM or BPMN or CMMN so missing the point and a waste of time. Ask the companies and experts who recommend a business to use BPM methodology and automation how much of their business is run like that and there you have your answer!!!

    And finally, there still aren't any independent studies that prove that large scale BPM works. Vendor and consultant success stories are so-called anecdotal evidence. I have proposed a mathematical proof of how difficult it is to make processes work in the large scale and not a single expert has responded. Why? Because they know I am right. When 500 linked processes are 99% right then the probability that the whole business will work right without human intervention to correct problems is just 2%. And now you hear that processes just need to be 80% right ... so much for automation!

    Like
    1
    • Emiel Kelly
      more than a month ago
      I agree with your disagreement
    • karl walter keirstead
      more than a month ago
      Also agree.
    • John Morris
      more than a month ago
      Max, your mathematical argument, is very interesting. Your example reminds me of the famous paper by Prof. John P. A. Ioannidis where he apparently shows why so much of published research is false. Examples I've seen from reviews of his work remind me of your "500 linked processes" -- substitute "500 hypotheses". Even if you can show though that almost all processes require human intervention (highly likely because "reality is rich"), that wouldn't necessarily show that the process isn't a good business case.
    • Bogdan Nafornita
      more than a month ago
      @Max, your argumentation is overwhelmingly flawed on so many levels, it feels like in the movie Inception. But I guess that's part of the whole point - if you can't convince them, confuse them.

      I'll skip right past how you define a graphical notation as non-friendly to business users, who swear by your "ontology to enable well defined business terminology including constraints, validation and conflict resolution" (sounds to me like they are just learning another proprietary programming language but hey at least they sound happy in their adaptive and educated pursuit of fuzzy business goals)...

      and I'll just focus on your last para: your mathematical proof does not make any sense whatsoever - how do you precisely define, in your mathematical world, a "process that is right"? More importantly, I have never heard in my life of someone trying to do business completely automatically by stitching 500 BPMN processes together - I'm looking forward to the public flogging of the person who first proposed this with a straight face.

      @Emiel: I disagree with your agreement :p
    • Lloyd Dugan
      more than a month ago
      I do agree that BPM should not just be about automation. FWIW, I see modeling and the use of a modeling language as a means to an end, not the end itself. But, apparently, others don't.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, April 29 2016, 11:50 PM - #Permalink
    Resolved
    2 votes

    I guess the question is, is CMMN the screwdriver to go with your BPMN hammer? Or is it just that one odd sized philips screwdriver that you really don't use except the one time you bought that self-assembly cabinet from Home Depot and had to buy the right sized screwdriver to go with it?

    • Lloyd Dugan
      more than a month ago
      Or is every process to model a nail because all you have is a BPMN hammer?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 02 2016, 10:41 AM - #Permalink
    Resolved
    2 votes

    Team Craft, in the person of an able champion, Mr. Pucher, has strongly articulated a view of business-friendly software technology. And certainly business can use more business-friendly technology! The concerns from Team Craft regarding BPM software, including "complexity", "expense" and "inflexibility", are serious concerns indeed.

    This view of business software technology is what might reasonably be called "the craft view of technology".

    One expects however that over time the "craft view" of business technology will become progressively less useful.

    The social organization of work according to craft is typical of early stages of technology. There is a significant and important social element (often managed by guilds) to craft technology. As time passes though, craft technology inevitably gives way to codified and industrialized applications of technology. And our standard of living today is in part the result of this process.

    What is this new generation of technology where software is concerned? Software technology deployed not as craft, but as industrialized technology? It is all the categories of modern software, including ERP and industrial controls -- and BPM. And all this software concerns the automation of aspects of work.

    As implied by the root word "automatic", automation means the use of technology artefacts which perform work "by themselves". Typical definitions of automation focus on control systems (i.e. found in factories, or as a thermostat for example), but this perception is unnecessarily limited. All software and especially business process management software involves automation.

    For example, popping a task from a stack of todos in a basic workflow system, and having that item show up in the stack of done tasks, is automation.

    (This more general idea of automation shows up in the growing category of "robotic process automation" ["RPA"], which is the new generation of software-formerly-known-as-screen-scraping.)

    So, by definition, BPM technology concerns automation.

    Software is a force multiplication technology for human endeavour. And software, including software-technology-as-craft, can contribute to the achievement of human goals. But it's even better when we can figure out how to scale software, especially BPM, for even more productivity. And more achievement.

    To champion software progress is not to denigrate the achievements of today. Craft technology of any kind always has a sort of romance to it, and is often associated with an affection for what is uniquely human. Not a bad thing for sure.

    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 02 2016, 03:07 PM - #Permalink
    Resolved
    3 votes

    On topic: BPMN with certain logical extensions (right now you have to overmodel it a bit to make it executable, see coordination of MI sub-processes via signals accumulated in payloads) and with a bit of old school architecture around it can fulfill any case management use cases.

    My grief with CMMN is how the model is actually obscuring the behavior of the case, rather than revealing it. When I show a litigation case plan to some lawyers, they just emit alpha waves. As soon as I finish explaining the case, the same questions arise again: "what's that sentry do?" "so how do you actually complete the case? what are the conditions?" "how do we model - don't do this?" "what are the case files for this scenario?"

    CMMN is not that hard to learn - but what's the point? So, yeah, I'd rather just extend BPMN to properly cover cases.

    • Lloyd Dugan
      more than a month ago
      This is a good critique, but tweaking BPMN is not going to happen, so the question is can we do it adequately with BPMN or does CMMN allow us more utility. Most of your questions are answered as hidden attributes that the modeler may elect to not put in (or do so loosely) in order to allow the progression to execution-level capture it. That is the essence of my proposal for a simplified version. As to your discomfort over "obscuring behavior" all I can say is that declarative modeling is a different beast, and control flow is not actually necessary for full understanding.
    • Bogdan Nafornita
      more than a month ago
      completely agree with you, Lloyd, on the nature of declarative modelling. Yet flows are important (not necessarily critical) as they convey dependency and chronology to customers' understanding. Most of them are not completely out of the "show me some screenshots of your app so I understand what it does" paradigm. So declarative modelling is in many cases hard to digest by customers.

      And BTW - hats off for your and Anatoly's contribution - they mostly validate what my team already does (and we have some interesting variations) in order to address cases in an ongoing BPMN environment.
    • Lloyd Dugan
      more than a month ago
      Thanks! Do you think a separate thread, wherein it can be shared how BPMN has been used to model case-like situations, would be useful? I'm not a BPMN-hater by any stretch, nor am I a CMMN-bigot, so I'm all about airing this out as matter of discovery and sharing. At the moment, CMMN is not widely used, so examples from the wild are in short supply, so BPMN then?
    • Bogdan Nafornita
      more than a month ago
      I would love a separate thread where we could go and talk about actual, practical solutions - in BPMN or anything else.
      Would be great if we could comment on process models directly, I know camunda has a feature like this on their forum.
    • Lloyd Dugan
      more than a month ago
      Great! I concur, and will speak to TPTB at BPM.com about arranging it.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 03 2016, 12:27 PM - #Permalink
    Resolved
    5 votes

    So, here is BPMN semantics-level rebuttal to Anatoly's model. But before going there, I want to thank him for his focused treatment and insights, and to his credit, for catching me on missing the use of Collaboration to model case situations. Having said that, there are still limitations with that approach, as shown below. And for those who are brave enough to get down in the weeds wth me on this, only referenced arguments based on the BPMN specification will be considered germane. In other words, find another thread if you want to promote your product.

    - Use of process name as the pool is a known sore point between those who read the spec as it is (see p.112), and those who read it the way they think it should be. FWIW, I’m sympathetic to the arguments advanced by the latter, but I also see the wisdom in understanding a pool – as a visualization of a participant – as an organizational (or system) concept which essentially defines a span of control over any process contained therein. Those that find this an inconvenient thing, and so respond by ignoring it or decrying it as just an “academic” thing, are just being willfully resistant to considering the other point of view. Anatoly’s use here is clear, namely that it is the same organizational context, so I can look past the pool naming issue. However, we have fractured the E2E perspective of the modeled behaviors that is in effect shared across that context by those very processes. I posit that this is lossy with respect to the CMMN representation (not to mention a bending of the basis for comparison since the point of the comparison was for the single model view). Also, even though I teach Collaboration as well, I have found it a challenge to get folks to use it or at least to use it correctly. It would appear that Anatoly and Bruce have been more successful, and that informs their preference, and I commend them for their successes.

    - Anatoly’s use of the data store to show the capture and retrieval of state is both elegant and informative, but it is a slight bending and distortion of the spec because it is used in more than one process as opposed to used “in one or more places in the Process” (see p. 208). (I found that one modeling tool wrapped a “fake” process around the free-standing data store, which allowed the data input associations and data output associations to still work, but referenced the data store ID rather than a data store reference ID, which is what would otherwise be expected.) The fix to this would be to show it within each of the referenced processes, so we could consider this a semi-legal short-hand approach to diagramming. However, it is nonetheless, a re-interpretation of what is there, which would support my point that the spec is not sufficient. It also reinforces the notion that state can be shared between processes this way, which is not really the case with this use. The data store can persist state beyond the scope of the process, but it still must be introduced into or pushed out of the scope of any process, so the awareness of this state is not knowable by a process instance until something in the process has made it so (see p. 224 for a description of data input association and data output association work with any item aware element in the process scope).

    - The always confounding use of Data Input and Data Output can reference Data State outside of the BPMN spec, allowing “adopters” to use and/or extend it (see pp. 213-215). But aside from having to explain the semantic difference between these and Data Objects used as inputs and outputs (not an easy task), means that vendors work it outside of the spec by using and/or extending the Data State element. Problem, as I see it, is that this is an acknowledgement of the spec’s limitations regarding data, proving my larger point, and, worse, I don’t know of many vendors that actually do this – and I mean uses and/or extends the specific element – as opposed to implementing it by some other means.

    - A Collaboration is NOT an element with scope characteristics (see p.281), so this usage – despite its seeming clarifying use in Anatoly’s model – is not really correct with respect to the spec, which again proves my point that it is too limiting for full-bodied treatment of case-like situations. The fragmenting of scope that is thus realized through the use of Collaboration forces the modeler down the same path I had to tread – namely, synchronizing actions with state across multiple situations. For example, in Anatoly’s example, he wants to allow the process to enable a performer to come in and terminate the “case” but there is nothing in his narrative that is modeled in his BPMN to show how this would be known or occur (it is merely asserted), whereas the conditional event in my single process view of the baseline process does this – as does my CMMN model with its ifPart component for the terminating user event. Anatoly’s Collaboration is missing several triggering events (or, more precisely, appropriate event types) that would be necessary in order to assert a true equivalence to what my base BPMN model shows as well as what my CMMN model shows. Once one corrects for this, the diagram is more complex than it was before.

    - There are other examples of lossiness and looser semantics. By moving the terminate function to a separate process, as opposed to leaving it as an event subprocess, it cannot share in the scope of the main process, and can only terminate a process instance by the use of the other, parallel thread at the start that leads to the terminate end event. While the terminate end event is not really exotic, I find its use in the wild quite rare, and often more associated with the BPMS because its semantics for cleaning/clearing out instances is crystal clear. In Anatoly’s model, it's use is essential so that the end of either main thread can effectively nuke the other. The original model also used this element, though for a different purpose - to kill off any ancillary threads spun off by the boundary conditional events. Otherwise, the parallel thread that advances to termination via a terminate request delivered by message flow accounts for the ability to cancel the clam in the original model, which was done through a boundary conditional event attached to the core sub-process though it could also have been done as an interrupting event sub-process. Perhaps Anatoly has had more success in explaining the presence of a parallel thread to capture the semantics of an exception handling moment (over elements natively designed to do that) than I have had, but, as a matter of preference, I would rather avoid doing what he did. This is, though, admittedly a bt of nit.

    - The "Evaluate claim" task is now immediately downstream from "Record claim" task and before the "Request info" task, which makes it somewhat different from even the revised narrative, particularly if compared to the original narrative. However, the presumed reason for this is to take advantage of the fact that "evaluation" in the revised narrative can happen after the minimal info has been recorded, which this approach does satisfy (though I'm not sure why the 'Wait for info" option is there as an outcome of the "Evaluate claim" task performance). But, if one imagines what a version of the original narrative would look like using Anatoly’s approach, it would have to be redrawn to reverse the reordering he has done here. Compare that effort, involving several moves and reconnects, to a single endpoint relocation in CMMN.

    - Now to the most important point for me: there is a task-driven understanding of how work surfaces that assumes that design approach is used in its implementation - meaning that work is completely work list-driven. In practice, this often means the use of off-book actions, such as stored procs, to effect entry into or exit from what would otherwse be populating queues, allowing instance matching to occur. (Necessary for this as the state is persisted and retired, as opposed to transient and dehydrated.) I'm not a fan of this approach for case-like situations because it severely inhibits an otherwise desirable end-to-end view of what is going on, leading to workers becoming undully comfortable in their isolated view of the flow. (This is no idle speculation on my part. I'm working with a client who presently suffers grievously from this.)

    - Finally, even with CMMN vs. BPMN using the Collaboration, once one corrects for the missing event types in Anatoly's model, there will be little difference in complexity of the diagrams, but that is a subjective determination. (Unfortunatley, process models can be like modern art or Rorschack tests - we see in them what we want to see. What is not subjective is that, by any measure I can think of - meta model elements and relationships, serialization interchange schema, # of symbols, page length of the spec, etc. - CMMN is an order of magnitude simpler than BPMN, unless you are working strictly within the Descriptive Conformance Class, which is similar in intent to my simplified CMMN.

    • Bogdan Nafornita
      more than a month ago
      with the caveat that my expertise in BPMN/CMMN modelling will never ever reach your level (and the risk that my English language may be off by much in some explanations), I'd venture to comment a bit your perspective:
      - use of process name as the pool - I do not see it as a big problem and I happen to actually believe pools are a bit of pain when it comes to both modelling (clogging the model with separate constructs for communication between pools) and execution (each pool creates a separate process instance in process engines, many times really not necessary from an business execution view). We ended up simplifying our modelling and execution (and the camunda engine, which we use, is friendly about that) by having pools representing only actual business processes (i.e. that manipulate similar business objects throughout their entire lifecycle) and referencing them via call activities, where they need to be called from each other. And we are also using message tasks between lanes of the same pool (wink at Bruce) - even though it's not according to the standard, it's been very helpful and clear to us.
      - use of the data store, use of data input and data output - anything related to data persistence outside process scopes is outside the BPMN spec anyway (a huge missed opportunity, even if I understand why the BPMN taskforce explicitly avoided this). But in a case management scenario one cannot escape the data persistence requirement, as this, together with event handling, capture the essence of case work. As I said before, I find that modelling a data store in BPMN (and fwiw any non-executable artefact of BPMN, like annotations or groups) a bit superfluous, even quaint - but other people may have many more positive experiences with these, when communicating to customers.
      - collaborations - as said above, not really a big fan of multiple pools messaging each other, I have successfully avoided this until now and I have no problem stepping a bit outside the standard. There is one idea here that worked for us, although we implemented it behind the model: a user task (e.g. "select claim") is employed to trigger events. Our implementation of choice is an integration with a portal front-end, whereby UI events (list filterings, button presses etc) in the user interfaces are captured by the process engine. Then, in case scenarios, the portal acts as the CRUD actuator for the data store (both persistent and in process scope) and the process engine captures the events and further orchestrates case interactions and activities. You can think of the portal as a separate technical pool that captures all UI events and communicates to the other pool, which depicts the actual business process. And we chose to collapse it in front of the customers as part of our overall ESB-like construct that handles all technicalities (e.g. portal UI interaction, error treatment taxonomy, logging engine, messaging queue etc). Highly executable, and highly readable at the same time.
      - I cannot follow if the terminate events actually kill all instances of the same case (some may survive in the separate pools, either by technical error, UI hanging, server timing out etc) - again, this is just another example why I believe we should limit the number of pools to actual business processes. So here I agree with your proposed solution.
      - task-driven case management - I agree that this view is a bit limiting and does not easily communicate ability to handle new tasks at runtime. I would suggest that Anatoly's model be enriched with ad-hoc constructs.
      - I agree that your simplified CMN representation may be much simpler than Anatoly's, but it looks to me that the pool collaboration (with all the stuff that I may want to edit in/out of it) communicates better how the case may be handled (even though it may be a limited subset of all possible handlings).

      But as you rightly said, everyone sees in models what they want to see. Thank God for diversity. :-)
    • Dr Alexander Samarin
      more than a month ago
      It seems that this case type has a very simple lifecycle. Thus a state-machine will be enough to coordinate other processes. Maybe BPMN and CMMN (and 20+ posts) are overkill for this case type? And a modest state-machine notation can be considered as a good participant in the BPM world. Another approach is to model a state-machine explicitly in BPMN. Thus, models will be easy to understand and uniformly to interpret.

      Thanks,
      AS
    • Lloyd Dugan
      more than a month ago
      Bogdan - Pretty familiar with Camunda, so I commend you on your choice of engine. They were voted best in show at bpmNEXT2016 for their integrated offering that implemented BPMN, DMN, and CMMN. They are one of the few that explicitly support multi-pool models in BPMS engine. Regarding messaging between lanes, what Bruce was wanting was "intra-process messaging" that is already accommodated (though strangely) by signal events. Regarding data treatment in BPMN, it is generally acknowledged that the RTF botched it, but it is what it is. Regarding the terminate end event, the parallel threads mean you use the end of one to kill the other, but you are correct that it is only within that process scope. The effect on other processes - e.g., is additional info process able to execute on that particular case - is unclear. One would have to introduce constraint on that process as unmodeled functionality or something in model or both.
    • Lloyd Dugan
      more than a month ago
      Dr. Samarin - It is simple because I made it so to keep the comparison as straightforward as possible. It is more than a state machine because there are ECA structures in it that do not alter the "state" of the case. This is why I would posit that CMMN is more expressive than simple state machine notation (https://www.google.com/search?q=state+machine+diagram&biw=1252&bih=526&site=webhp&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwjurubpyMDMAhUG5SYKHRIzB8MQsAQIGw&dpr=1.09).
    • Dr Alexander Samarin
      more than a month ago
      lloyd, Just because you can use CMMN for state-machine, doesn't mean you should. Understandability of models by everyone involved is very important.
    • Anatoly Belaychuk
      more than a month ago
      Lloyd, you started by warning others not to promote products yet brought Camunda into this thread yourself ;)

      To the matter: sorry for not answering all your points, very thoughtful indeed. Please let me focus on a single argument that I believe is the most important.

      Let's consider the following branch of your scenario: the due time has passed so that the case worker has rightfully closed the case. Yet some time later the applicant brought the documents requested. Is it an overstretching? Hopefully not.

      Should we model and/or execute this event and appropriate actions? I believe yes - we should instruct the case worker what to do and we should record this interaction and its results.

      But I can't see how we could do it within a single process or case because it's natural to end the process/case instance as soon as the case worker decided to do so. (And it'd be crazy to keep it alive forever anyway.) No process instance - no catching event or activity possible.

      Collaboration hanldes this situation quite naturally: any interaction initiated by an external entity (the applicant in this scenario) is modeled by a separate process pool in my methodology. We welcome the applicant, we search the database for his/her case. If it's found we file the document. If not then we inform that unfortunately the case was expired and closed, and recomment the next possible action, e.g. re-submitting the application.

      It's a very common patterm; we utilize it in every process we work on for living during last 5+ years. BPMN usefullness would be ten times less if this won't be allowed/possible. Only simple processes not interacting with external entities e.g. vacation request, spendings report etc. are fully internal and hence can be modeled by pure orchestration. But these aren't *business* processes really - business begins when customers, suppliers, partners are brought into the scope. That's why I believe that collaboration is essential for any serious business process modeling.
    • Bogdan Nafornita
      more than a month ago
      @Anatoly: in all fairness, I was the one to bring Camunda into the discussion, not Lloyd. No reason other than to provide some context to the discussion. I use their open-source product - I am not affiliated in any way to them.
    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