Removing Decisions

Removing External Activity: applied

Again, notice how this is now focused on the responsibilities of the internal resources – it is “operationally focussed”.

The external contacts are not in your “operational” control, so it is entirely appropriate that onus is given to the resources which are in your control.

Decision Diamonds

Decision Diamonds are commonplace on process maps. These denote flow based on certain conditions, and currently Enate does not have a concept of “automated conditionality”… but does have ways of dealing with conditionality.

• Different Process

  • Early decision

• Delegated Decision

  • RPA/External

• Manual Decision

  • Ad Hoc Action

  • Ad Hoc Cases/Sub Cases

• Absorb the Decision

We will look at each of these further down.

Decision Diamonds – Different Process.

Often a decision implies a different process. By definition, the different possible flows through the decision points can be thought of and modelled as different processes and this is often appropriate as it might imply different allocation and due date rules.

If the information used to make the decision is known at the start of the process, then it can be used to imply a different process.

In this process example, the “High Value” route, might have a different SLA than the standard route. You can see how these can be treated as 2 different processes, with different SLAs.

This depends on knowing the route before the process is started which is often true*.

* In Enate, a CASE process of one type cannot be converted/switched to a different type, once it has started.

Decision Diamonds – Delegated Decision.

If the route through the process decision points isn’t known before the process begins, then the decision can be made manually or delegated to an external technology including RPA.

The Bot routine can be passed data from Enate, but also has a myriad of extensible functionality to make complicated decision based on other factors, with multiple outcomes.

Once the bot routine had arrived at the decision, one option is to launch additional “Ad Hoc” ACTIONS on the CASE.

In this example, the Bot will launch the additional ACTIONS if RPA Bot the value passed to it is above a predefined limit.

A subtlety here, is that although a Bot can launch multiple ACTIONs, it cannot trigger a “chain” of ACTIONS. For this reason, considered use of STEPS ensure here that the process flows as expected: notice that the “Calculate Payout” ACTION will start automatically either after the “Additional Checks” ACTION or when the Bot’s ACTION completes without launching an ACTION.

Decision Diamonds – Manual Decision.

The third, and simplest, way which we can model conditionality is to delegate the decision to a human. This is very similar to the Bot approach on the previous slide and utilises “Ad Hoc” ACTIONS in the same way.

At any point, a user of the system, may elect to LAUNCH a new ACTION from within the ACTION they are working on.

To prompt this, a CHECKLIST item could be used “Do you need to launch Additional checks ?” or “Have you launched Additional Checks ?”.

The same limitation around launching chains of ACTIONS exist, so again in this example we have used STEPS to ensure the process flows as expected.

Remember – A STEP WILL NOT COMPLETE UNTIL ALL THE ACTIONS ON THE PREVIOUS STEP HAVE BEEN completed. So if the user launches “Additional Checks” ACTION on the first step, then completes “Validate Paperwork” the system will only move on to Step2 when that ACTION is complete.

Decision Diamonds: absorbed decision

The final way to consider decisions is to absorb them into larger ACTIONS.

If a series of tasks, with decisions, are done by one resource (as they are in the example process) then you could model the ACTION so that it includes the decision points.

Instead of “Procure Mobile Equipment” or “Procure PC” a single ACTION called “Procure Equipment” would suffice from an operational perspective. Custom Data and/or Checklists on the ACTION could be used to show what decisions was made.

Simplifying Processes: Summary

Applying the concepts outlined previously, the process map is greatly simplified. Importantly, this hasn’t changed the process, just how it is modelled, aligned to the Enate platform.

becomes..

This has reduced the number of ‘tasks’ from 30 to 9, without intrinsically changing the process.