Elements is extremely useful for putting automation into a business context in a way that promotes common understanding around two key questions:

  • We want to re-engineer our business. Which parts of our systems/automation could be affected?

  • We want to change/extend our systems/automation. Which parts of our business could be affected?

To capture and manage these relationships, Process Knowledge uses a simple mapping notation which allows the capture of automation metadata in context of process. While this is powerful, it is a business representation of process, not a technical one.

Many people, however, want to use a graphical notation that allows you to turn "process models" directly into automated workflows. The point being that if you can capture the process once, enrich it and build the rules engine, you can generate the code and "run" the workflows with little or no intervention. You can also then change automation by changing the graphical representation of that workflow.

While very capable, this approach requires a rich palette of workflow modeling objects, metadata and rules in order to "graphically program" the workflows for automation. It therefore requires highly skilled business analysts to act as interpreters of the business requirements and to interact with the business. We view Elements as a catalyst and complement to this approach – not a replacement for it.

The global standard for this approach is to use one of the many tools that allow mapping using the BPMN2.0 standard.

Using this standard (or similar) approach, a technical representation will be created within the workflow/automation/BPM application. It can be related to an activity box (referenced as an attachment), a diagram, or a collection of diagrams.

A Process Knowledge diagram can help to communicate what the business wants to achieve and can accelerate BPMN mapping – but cannot be exported as a BPMN diagram.

Did this answer your question?