The triple crown of process improvement standards

The Business Process Model and Notation (BPMN) , the Case Management Model and Notation (CMMN) and the Decision Model Notation (DMN) are powerful and expressive standards published by the Object Management Group (OMG) . This triple crown of process improvement standards offers universally recognized graphical notations in support of organizations seeking efficiency and effectiveness of their operations.

Go beyond just a Visio drawing

Creating Visio drawings describing your operations is a great first step toward Digital Transformation. To fully leverage your existing Visio drawings and take them to the next level, you can import them in the Trisotech’s Digital Enterprise Suite to instantly obtain these benefits:

• Turn your diagrams into flexible and reusable models that can be versioned
• Check correctness and validate your models against the standard specification
• Export your models using the standard interchange file format
• Augment your models with documentation and multimedia content and then animate them
• Collaborate and share your work with the rest of your organization via modern Web Browsers
• Get access to a multitude of other capabilities to help you Visualize, Innovate, Transform, and Improve your organization

Last week was the annual DecisionCAMP conference, where mostly-technical decision management (DM) aficionados gather to talk about the technology, standards and application of DM.

I attended in person last year, but this year was all virtual, and I helped to organize the conference platform using Zoom for live presentations, YouTube for rebroadcast (you can see replays of the presentations there), and Slack for discussion. Although not a replacement for an in-person event, we did manage to capture some of the camaraderie and interactive conversations that would have happened if we had all been in the same room. We even had an after-conference Zoom cocktail hour on the last day!

The great thing about DecisionCAMP is that it’s really a grass roots labour of love by the DM Community site, rather than a for-profit or vendor-sponsored conference. Vendor presenters are requested not to plug their products, so the presentations are a combination of university research, updates and usage of the DMN (Decision Model and Notation) standard, and case studies of practical applications. For a process-centric practitioner/analyst like me, there are always interesting presentations exploring the overlap between decisions and processes. The most noticeable example of this was in a presentation on the “triple crown” of business modeling standards, namely, the Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN) and DMN.

In my post on designing for agility, I mentioned that agility often depends on the design decisions such as the split between process and decision logic – what do you model in as a decision, and what do you model as a process – and went into some detail on when to consider splitting out decision logic from a process. Unsurprisingly, many DM practitioners don’t think first about processes, but suggest that you first focus on determining and modeling your business decisions, then build processes to gather the information and execute the steps required to make those decisions. Within those decisions, however, they often use rule flows, which are really processes that link together individual rules/decisions into larger decisions; this starts to muddy the waters in terms of designing decisions and processes, and may spread your processes over two different model types. To this we add case management (CM), which also provides some process and decision modeling, but may also link to DM and BPM models. Three model types based on three standards: this is the triple crown of process improvement standards.

Last month I provided a brief overview of the Case Management Model and Notation (CMMN) standard.

As it does for BPMN, Method and Style provides CMMN with additional diagrammatic conventions aimed at making the logic understandable from the printed diagrams alone. These conventions are formulated as “style rules” that can be applied as validation in a CMMN tool, such as Trisotech Case Modeler.  As described in that post, CMMN’s event-condition-action (ECA) style defines through declarative logic flexible patterns of case behavior that can be fully automated on a CMMN engine.  The problem for most modelers is that the detailed logic depends on case variables and conditional expressions that are typically delegated to programmers and in any case do not appear in the case diagram.  Method and Style conventions make them visible.

In CMMN’s ECA style, the triggering event is a lifecycle state transition of a task or stage (e.g., start, complete, exit), milestone (e.g., occur), or file item (e.g., create, update).  The condition is a Boolean expression of case variables (file items).  The action is enablement or termination of a plan item.  In the diagram, enablement is signified by a white diamond shape, called a sentry, on the boundary of the triggered plan item.  The sentry is connected to the triggering item by a dash-dot connector called an ON-part link, labeled with the triggering event, such as complete.  In similar manner, termination is signified by a black sentry.  The condition is called the sentry’s IF-part, an expression of case variables (file items).  The rules of the spec do not describe how the condition – if there is one – is made visible in the diagram, but Method and Style provides a way.  The ON-part determines when the action occurs; the IF-part determines whether it occurs.

For example, in the diagram below, task b is enabled when task a is complete.  Here there is no IF-part, i.e., the condition is true by default.

BPMN Method and Style has the concept of an activity end state, meaning how did the activity end, successfully or in some exception state?  The end state names, typically Adjective or Noun-Adjective, are the labels of the gates on an XOR gateway following the activity.

For example, the BPMN diagram above means that task a has end states “OK”, leading to task b, and “Exception”, leading to task c.  CMMN Method and Style borrows this idea, with the task end state indicated by the sentry label of an entry condition triggered by the complete event of another plan item.

Here, CMMN task a again has end states “OK”, leading to task b, and “Exception”, leading to task c.  In CMMN Method and Style, the end state of a task is captured in an implicit variable [taskname].end, and here the sentry label represents the entry condition’s IF-part expression, a Boolean.  When the ON-part link – the dash-dot connector – from the triggering plan item is labeled with the complete event, the sentry label is visual shorthand for the full IF-part expression,

[triggering task].end = [sentry label]

The expression syntax depends on the expression language employed.  The syntax I use is FEEL, which is the default in the Trisotech tools.

A milestone is a plan item signifying an achieved state of a stage in the case.  Like task end states, milestones are used in Method and Style to signify the end state of a stage, determining what happens next (or what is possible to happen next).  Unlike task end states, which are exclusive, more than one milestone in a stage may be achieved.  In Method and Style, global variable Milestones contains the list of all case milestones that have been achieved, in the format [stagename].[milestone name].  Similarly to the example above, when completion of a stage determines what happens next, a sentry labeled with the name of a milestone in the triggering stage is visual shorthand for the FEEL IF-part expression,

list contains(Milestones, [stagename].[milestone name])

Let’s take a look at a few of the style rules.  From the above examples you see that labels play a key role.  In the spec, executable CMMN references elements by ids, which are not visible, and pays little attention to labels, which are.  Many style rules require labels on CMMN elements and ascribe particular meaning to them, as we saw above with sentry labels signifying the IF-part condition.  The label of a plan item signifies its name, which must be unique in its context.  For example, style rule 0010 checks for this:

In the diagram on the left, the stage and its enclosed task have the same name, Registration.  This is a style error.  The diagram on the right is correct.

In the spec, dotted line connectors called associations are optional annotations with no operational semantics, but Method and Style may require them, in order to make the case logic visible from the diagram.  For example, the trigger of a timer event listener (similar to a timer intermediate event in BPMN) has no official representation in the diagram, so Method and Style uses a directional association labeled with an event of the triggering item.  Without this connector, the trigger is assumed to be activation of the containing stage.  If the connector is present, style rules require the event label:

The diagram above means that Registration Stage is terminated automatically (black sentry) if it is not completed within 7 days of the actual start of task Registration.  The association labeled manual start defines the trigger of the timer.  The timer label defines its duration.  The diagram on the left is missing the event label, and thus is a style error.  If the timer event listener is missing its duration label, that is also a style error.

Other style rules resolve inconsistencies in the CMMN spec.  Style rule 0100, for example, prohibits ON-link connectors from crossing stage boundaries.  In one part of the spec, it says such links are not allowed; in another part it says they are allowed, and in the wild you often see them.  But such links do not work when a stage is rendered collapsed, and a basic principle is that the semantics should not depend on an element’s graphical rendering.  In Method and Style such links are not allowed.  The top diagram below is thus a style error; the bottom diagram is correct.

The diagram above also illustrates how milestones are used as stage end states.  Task Acceptance is enabled when Registration Stage completes in the end state “Registration OK”.  The sentry label is visual shorthand for the FEEL IF-part expression

list contains(Milestones, "Registration Stage.Registration OK")

And note also that the milestone Registration OK is activated when the task Registration completes in the task end state “OK”.

Still other style rules guard against infinite loops.  The hashtag symbol indicates a plan item is Repeatable,  meaning when it completes a new instance becomes Available immediately if its Repetition Rule is true.  Like IF-part expressions, Repetition Rules are Boolean expressions of case variables (file items) that are normally invisible in the diagram.  Method and Style requires a text annotation to reveal the Repetition Rule; otherwise the rule is assumed to be true by default.  Thus if a Repeatable task or stage is not manually activated, has no entry condition, and does not have a text annotation indicating a Repetition Rule, the new Available instance will become Active as soon as the previous one completes, an infinite loop that prevents completion of its containing stage.

In the left diagram above, task Registration is an infinite loop, a style error.  In the center diagram, Registration is ok, since it is manually activated, and task Acceptance is ok as well, since it has an entry condition.  In the right diagram, Registration is ok as well, since it has a Repetition Rule that prevents an infinite loop.

A final style rule example is intended to eliminate deadlocks caused by zombie states, when a stage is completed manually before its expected end state milestones are set.  The rule says that if a stage has multiple milestones tested by the IF-parts of complete links, it should contain a single Required milestone triggered by all those milestones, in order to ensure proper stage completion.  A stage may not be manually completed unless all of its Required elements are Completed.  The example below illustrates:

In the top diagram, Registration Stage has two milestones tested by complete links, and one leading to exit.  Since no plan items are Required, it is possible for a case worker to manually declare Registration Stage complete without achieving any of the milestones, and in that case there is no next step available.  Style rules flag this with a warning.  The bottom diagram is correct.  Here achieving either milestone New registration or Existing registration sets the Required milestone Registration completed.  The stage may not complete unless the Required milestone is achieved, preventing the zombie state.

If all of this looks wildly unfamiliar, that’s because it is!  But help is on the way.  My book CMMN Method and Style explains it all at length, and it is available on Amazon.  You can play around with CMMN by starting a free trial.

Read part 1

Case Management Model and Notation (CMMN) is the poor stepchild of process modeling standards.  It was developed a decade ago, around the same time as BPMN 2.0 and largely as a reaction to it by vendors who believed that “real” business processes were about knowledge workers interpreting documents, not web services orchestration following rigid rules.

In case management, the order of actions typically cannot be precisely defined at design time, and many different things happen concurrently.  The list of available actions changes with the state of the case, and initiation of those actions is typically the result of manual case worker decisions.  Such a different process paradigm demands a different standard.

There is some merit to that thinking, but in the meantime just a few tools have adopted CMMN.  Part of the problem was self-inflicted.  Unlike BPMN, which sought to emulate the familiar look of swimlane flowcharts, CMMN went for a decidedly unfamiliar look.  Unless stakeholders make a modest effort to learn the language, the meaning of a CMMN diagram is utterly lost on them.  Adding to the difficulty is the fact that case logic defined in the model is declarative, not procedural.  That means that each case task and stage (phase) independently defines the conditions under which it is available to start or complete.  That gives the case logic flexibility lacking in BPMN, but at the expense of intuitive visual communication.

I decided to take on this challenge with a new book, CMMN Method and Style, that attempts to make case management diagrams more comprehensible and the standard more widely adopted.  This post provides a very brief introduction.

CMMN Basics

In a CMMN diagram, or case plan, actions are represented by tasks (rounded rectangles).  The head-and-shoulders icon means a human task; other task types invoke a BPMN process, a DMN decision, or a CMMN subcase.  Tasks are contained in stages (rectangles with clipped corners).  The oval shapes are milestones, a type of event signifying some state of the case has been achieved.  Tasks, stages, and milestones collectively are called plan items.  Symbols at the bottom of a plan item indicate additional attributes.  The triangular Play symbol indicates the plan item is manually started.  The hashtag symbol indicates it is repeatable.  The exclamation point indicates it is required, meaning it must be completed in order for its containing stage to complete.

Tasks and stages evolve through a sequence of lifecycle states: Available, Enabled (if manually started), Active, Completed or Terminated.  A task or stage becomes Available when its containing stage becomes Active.  (The case plan as a whole – the tabbed folder shape – is considered the outermost stage of the case.)  Each lifecycle state transition generates a standard event that can trigger advancement of the case logic.  Diamond shapes called sentries on the boundary of a task or stage represent entry or exit conditions triggered by a standard event and further controlled by a Boolean expression of case data.  Once it is Available, a manually started task or stage becomes Enabled when its entry condition is satisfied, and then becomes Active when manually started by a case worker.  If not manually started, it becomes Active as soon as the entry condition is satisfied.  A stage may be marked Completed as long as none of its contained plan items are Active and all of them marked required are either Completed or Terminated.

Case data and documents, collectively called the case file, are available to all plan items at any time.  Like plan items, each case file item also progresses through a series of lifecycle states, and those state transitions likewise generate standard events that can trigger plan item entry and exit conditions.  Each file item is assigned a datatype.  In Trisotech, these are modeled as FEEL item definitions as they are in DMN and BPMN models.

All of that is from the CMMN spec.  Method and Style is my own methodology layered on top, aimed at making the logic as clear as possible from the printed case diagram.  It uses milestones and sentry labels – which appear in the diagrams – to signify the end states of stages and tasks, without requiring modelers to explicitly define case variables for them.

Case Modeling Styles

When creating case models in CMMN, there is no single “best” style for representing the logic.  Some modelers may consider progression of the case to be entirely based on the judgment of case workers rather than events and rules specified at design time.  What happens in what order is not revealed by the diagram, even though this permits illogical ordering of tasks.  The case worker is simply assumed to know the correct thing to do next.

Others may take the opposite point of view, describing most case logic explicitly using event-condition-action (ECA) via lifecycle events and sentries.  While intrinsically more flexible than BPMN, CMMN models in this style are similar in that they try to reveal all possibilities of “what happens next” through the diagram.

Scenario: Write a Report

To illustrate, let’s look at the similarities and differences when applied to a very simple case model, writing a report.  Here is the scenario:

1. The report may or may not require research. If it does, tasks include researching the topic and organizing references.
2. Preparing the draft is always required. It includes writing the text, also always required, and generating the table of contents.  If the report contains graphics, additional tasks include creating the graphics, integrating them with the text, and generating a list of figures.
3. Periodically the draft in progress is reviewed. Tasks include seeking comments, discussing possible changes, and verifying spelling and grammar.
4. When ready, the draft is submitted for approval. The case completes successfully when the report is approved.  It is also possible that the Approver cancels the report.

User-Driven Style

In the purest user-driven style, all choices of what to do when are made by case workers at runtime using their judgment about what needs to happen, as illustrated below.

The stage Do Research is discretionary (dashed border), meaning it occurs in some instances and not in others, as determined by an applicability rule defined in the planning table indicated by the small grid on the case boundary and described in Method and Style using a text annotation on the stage.  If research is required, this stage transitions to Enabled when directed via the applicability rule, awaiting manual start by a case worker.  When it starts (becomes Active), its tasks Research Topic and Organize References become Enabled, awaiting manual start.  As drawn here, whether this stage ends in Completed or Terminated does not affect case completion.

Since it has no entry condition, the stage Prepare Draft is Enabled as soon as the case becomes Active.  Since it is marked Required, the case cannot complete until this stage is Completed or Terminated, and the stage cannot complete until its Required task Write Text is Completed or Terminated.  Other than that, the order in which its contained plan items are performed is determined entirely by the case worker.

The contained stage Add Graphics is discretionary, as it applies only to reports that contain graphics.  Again, the applicability rule is defined in a planning table, here on the containing stage Prepare Draft, and visualized in the diagram by a text annotation on the discretionary stage.  If the applicability rule is true, Add Graphics is Enabled when Prepare Draft becomes Active and must be manually started by a case worker.  Its tasks include Create Graphics, Integrate Graphics, and Generate List of Figures.

Prepare Draft also includes the task Generate ToC, which could be considered “optional” since it is not marked Required.  In practice there is little difference between such an optional task and a non-Required discretionary task.

The case also contains the task Approve report.  It is not enclosed in a stage, meaning it becomes Enabled as soon as the case is Active.  Presumably it would not be started until a draft of the report was complete or nearly so, but this is not required by the case plan model.

The milestone Report Approved is marked Required, meaning the case can end in the Completed state only if this milestone is set manually by a case worker.  Alternatively, a case worker in the role Approver may terminate the case at any time, depicted as a user event listener triggering an exit sentry.

In the diagram above, all the stages and many tasks are marked Repeatable.  Since no entry conditions are specified, that means that after being marked Completed or Terminated a plan item immediately becomes Enabled again.  The effect of Repeatable here is simply protection against a case worker mistakenly completing or terminating a task or stage.  Technically, this creates a new instance of the plan item, as CMMN has no way to “reopen” a completed or terminated plan item, but we assume the artifacts created by the original instance are available as file items to the new instance.

ECA Style

The ECA style, in contrast, represents the allowed order of plan items explicitly as much as possible using lifecycle transitions and sentries.  It allows for a great deal more automated behavior than does the user-driven style, but at the same time may be more difficult for stakeholders on the business side to understand.

The same scenario is illustrated in ECA style in the figure below.  Here the order of case actions is explicit.  Because it is the plan item’s complete event that usually triggers what happens next, this case could probably be modeled more simply and clearly as a BPMN process.  Let’s take a closer look.

When the case first starts, the only plan item enabled is Plan Report, as all the others have entry conditions.  Plan Report creates the file item Plan, indicated by the page symbol with a dotted arrow from the task.  The dotted arrow in the spec is an association, just a diagram annotation, but in Method and Style we say a task that creates or modifies a file item should display this connector. File items are represented in the case diagram when their values or events are used in the case plan logic.  We need something like this to say that Do Research and Create Graphics are only performed under certain conditions.

When Plan Report is Completed, its complete event triggers the sentry on Prepare Draft, making that stage Enabled.  Every entry condition has two components: zero or more ON-parts, dash-dot links to a plan item or file item, labeled with a standard event, signifying when entry occurs; and an IF-part, a Boolean expression of file item values, signifying whether entry occurs.  In Method and Style, the IF-part condition is represented by the label of the diamond shape.  No label means the IF-part condition is satisfied by default.  Here there is no label, so Prepare Draft becomes Enabled when Plan Report completes.  Once Prepare Draft is manually started, it becomes Active and all its contained plan items become Available.

The contained stage Do Research has an entry condition with no ON-part, meaning its IF-part condition is evaluated as soon as its containing stage Prepare Draft becomes Active. Here the IF-part references the Research required component of the file item Plan.  Do Research is Enabled only if Plan.Research required is true.  Similarly, the task Create Graphics is Enabled only if Plan.Graphics required is true.  Note that the entry condition for Integrate Graphics has two ON-parts, meaning both Write Text and Create Graphics must first be completed.

If Create Graphics is not performed, then Integrate Graphics and Generate List of Figures are not performed, either.  The task Generate ToC has two entry conditions, meaning it is Enabled either when Write Text is Completed and there are no graphics, or when Integrate Graphics is Completed.

None of the plan items of Prepare Draft are Required, meaning the stage may be declared Completed whenever none of its plan items are Active.  This triggers the stage Review draft, which contains tasks Obtain comments, Discuss changes, and Correct Grammar and Spelling, performed in parallel.

A basic concept of BPMN Method and Style is the end state of a process or subprocess, indicated by the end event reached and signifying how did it end, successfully or in some exception state.  CMMN Method and Style uses a similar idea for stages, with milestones playing the role of end events.  Here Review draft has two manually set end state milestones, either Draft complete or Revision required.  Technically a milestone is an event, but Method and Style assumes each milestone in the Completed state is listed in an implicit Milestones file item that can be tested by sentry IF-part expressions.  If the stage ends with Draft complete set, Approve report is triggered.  If it ends with Revision required set, it goes back to Prepare draft.  In order to prevent a “zombie state” in which the stage is manually declared Completed without setting either milestone, we also need to add the Required milestone Review Complete, which depends on setting one of those two end states.

In Method and Style, tasks also have end states, captured in the implicit file item [taskname].end.  Approve report has task end states “Approved” and “Not approved”, which are tested by sentry IF-parts to trigger either the milestone Report approved or the milestone Changes required.  These milestones act as end states of the case as a whole, although the case can end in the Completed state only when Report approved is set.  Changes required goes back to Review draft and then likely back to Prepare draft for revision.

As in the user-driven model, an Approver also can exit the case at any time.

*                                   *                                 *

Where the User-driven style requires less explanation, the logic of what happens under what conditions is not contained in the model.  It’s entirely inside the heads of the case workers at runtime.  The ECA style makes that logic explicit, but the declarative modeling paradigm takes some getting used to.  In many case models, both styles are used, with User-driven in some stages and ECA in others.  Method and Style adds some extras that put needed logic details in the diagram, where they can be seen by stakeholders other than those who created the model.

As you might expect, there are style rules as well, with style rule validation built into the Trisotech software. 

Read part 2

Blog Articles

Bruce Silver

View all

Make Way for B-FEEL

Make Way for B-FEEL

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is a Decision Service?

What Is a Decision Service?

Blog

By Bruce Silver

(Read Time: 5 Minutes)

FEEL Operators Explained

FEEL Operators Explained

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Lookup Tables in DMN

Lookup Tables in DMN

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is Method and Style?

What Is Method and Style?

Blog

By Bruce Silver

(Read Time: 3 Minutes)

Instance Alignment in BPMN

Instance Alignment in BPMN

Blog

By Bruce Silver

(Read Time: 3 Minutes)

DMN 101

DMN 101

Blog

By Bruce Silver

(Read Time: 5 Minutes)

More On DMN Validation

More On DMN Validation

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Calendar Arithmetic in DMN

Calendar Arithmetic in DMN

Blog

By Bruce Silver

(Read Time: 5 Minutes)

How Much DMN Is Enough?

How Much DMN Is Enough?

Blog

By Bruce Silver

(Read Time: 4 Minutes)

Set Operations in DMN

Set Operations in DMN

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What’s New in DMN 1.4 and 1.5

What’s New in DMN 1.4 and 1.5

Blog

By Bruce Silver

(Read Time: 4 Minutes)

DMN: Data Validation Reconsidered

DMN: Data Validation Reconsidered

Blog

By Bruce Silver

(Read Time: 5 Minutes)

DMN Hit Policy Explained

DMN Hit Policy Explained

Blog

By Bruce Silver

(Read Time: 4 Minutes)

Standardizing BPMN Labels

Standardizing BPMN Labels

Blog

By Bruce Silver

(Read Time: 4 Minutes)

Interrupting Events in Automation

Interrupting Events in Automation

Blog

By Bruce Silver

(Read Time: 2 Minutes)

How Contexts Simplify DMN Logic

How Contexts Simplify DMN Logic

Blog

By Bruce Silver

(Read Time: 4 Minutes)

DMN’s Killer App

DMN’s Killer App

Blog

By Bruce Silver

(Read Time: 7 Minutes)

BPMN’s Magic Event Type

BPMN’s Magic Event Type

Blog

By Bruce Silver

(Read Time: 3 Minutes)

Datatypes with Constraints

Datatypes with Constraints

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Abstract

The processing of parliamentary interventions in a Swiss state (canton) involves many different parties: Parliamentary Services, Government, Ministries, Commissions, etc. In this jurisdiction, it is lawfully required that the government responds to each intervention within precise delays. Additionally, the government must publish an overview of the progress of answering and executing all interventions on a regular basis.

With multiple actors, varying delays and numerous ongoing instances, the government needed a flexible solution to communicate and deliver services to the citizens.

On these bases, the state administration initiated a project to implement a system for keeping track of parliamentary interventions, from their tabling to their classification by parliament after execution. To be able to communicate the courses of action easily and graphically, it was decided to use a model-driven approach. Not only should the models be understandable by all stakeholders, technical or not, but they also needed to be directly implemented on the state administration’s process engine.

At first sight, the processes might have looked like typical linear processes with several parties involved that can be modeled and implemented using BPMN. When diving into the details, it however became clear that it was a better approach to view the intervention as an object (case file) transitioning from one state to another through the occurrence of events or actions triggered by the different process participants, which corresponds to the CMMN view of a process.

In this webinar, we will demonstrate:

How CMMN allows to focus on the activities that the different parties involved can perform on an intervention, depending on its current state;

How each of the activities can be analyzed in the context of the current state of the intervention without having to take into account the rest of the process;

Why CMMN fits an agile software development approach; and

How CMMN can provide the workflow logic behind user-facing software applications.

---

Serge Schiltz, CEO and founder of processCentric GmbH is the founder of processCentric GmbH, a firm that provides expertise in the field of business process and rules management based in Switzerland and working all over Europe. He has delivered business process analysis, decision management and software development projects for over 25 years. Dr. Schiltz is also an author, university lecturer and instructor in project management, business analysis and BPM. He as published several articles and books in English, German and French.

Jean-François Gonguet, Senior Solution Architect at adesso Schweiz AG At adesso, Jean-François is in charge of developing partnerships for business process management, containerization and cloud-ready applications with various technology providers. Before that, he spent 28 years at IBM as technical pre-sales architect and has been involved in different projects around BPM and integration for large customers.

Jean-Christophe Crettenand, Head of Information System, Canton of Valais Government Controlling For fifteen years, Jean-Christophe devoted himself as a PowerBuilder and PL/SQL specialist in the development of an IT solution allowing the management of the State by performance mandate. In 2012, during his master’s degree in Information Systems Management, he discovered BPMN and project management. Since then, he is coordinating inter-agency projects, including ViaParl: “Keeping tracks of parliamentary interventions”.

Download the complete research report

FOR IMMEDIATE RELEASE:

MWD Advisors publishes favorable in-depth review of Trisotech’s Digital Enterprise Suite

Montreal, Quebec, Canada, September 15, 2017 — Trisotech (http://trisotech.com) a global leader in digital enterprise transformation software solutions, announced today that MDW Advisors, an independent technology and advisory services firm, has analyzed the Digital Enterprise Suite features and produced an in-depth review of the tool.

The MWD Advisors’ review concludes that Trisotech offers a “comprehensive set of tools and canvases that provide support to a broad range of users, enabling them to capture reusable models of how the business operates.”

The review puts an emphasis on the Suite’s Decision Management component: Trisotech’s Decision Modeling and Notation (DMN) Modeler. Derek Miers, Principal Analyst at MWD Advisors and author of the review, points out that “we struggle to think of scenarios where organisations with significant operational decision-making requirements would not want to look seriously at the product.”

“MWD Advisors is a well-respected analyst firm and we are very pleased that they have great things to say about our Decision Management product,” says George Barlow, Chief Sales Officer at Trisotech. “Mr. Miers also makes the point that the Decision Management product, while available as a stand-alone offering, has even greater customer value when paired with other components of our Digital Enterprise Suite such as our Business Process Modeling, Case Management Modeling and Strategic Planning tools. The Decision Management marketplace is very active right now. Organizations of all types want to take advantage of the OMG international standard – Decision Modeling Notation (DMN) – to replace existing disparate rules systems, coalesce on a standard, and remove embedded decision logic from program code thus making it accessible directly by business users.”

About Trisotech

Trisotech is a global leader in digital enterprise transformation solutions, offering innovative and easy-to-use software tools that allow customers to visualize, innovate, transform and improve their digital enterprise processes and business decisions. Trisotech customers use The Digital Enterprise Suite to provide new and revolutionary ways for their knowledge workers to collaborate and succeed in an increasingly global, connected and competitive world. Trisotech products are providing digital transformation help to communications, agriculture, manufacturing, financial, healthcare, insurance, energy, distribution, government, and many other types of organizations.

Trisotech is a privately held company.

Website: http://trisotech.com

###

For information

Jonathan L’Ecuyer
Marketing Manager
Trisotech
jlecuyer@Trisotech.com

514 990-6639 ext. 501

All registered trademarks are the property of their respective owners.

See awards earned by Trisotech for its Digital Enterprise Suite

If your Business runs on Rules, it should run on Trisotech!

Get Digital Enterprise Suite