Here you will find some useful hints and tips when building business processes in Enate, and deeper dive explainers of some of the fundamental concepts and features, and how best to use them.

Ways to Simplify

We will explain how each of the following techniques and concepts can be used to greatly reduce complicated looking processes:

1. Combining Consecutive Actions

2. Removing “Send” Actions

3. Using Peer Review Actions

4. Focusing on Operational Process

5. Removing Decisions

   1. Differentiating Processes

   2. Delegating Decision to external Technology

   3. Manual Decision Making

   4. Absorbing Decision into Task

6. Using Sub Processes

Often in a process map there will be Actions/Tasks that say “Send to…”. These might represent external communications, email, letters, etc. But often these simply represent workflow.

Often, these can be removed since the “send” is inferred by the work flow.

This can greatly simplify the map.

Commonly, Tasks performed by one resource (the “doer”) will need to be checked by another (the “checker”) – often a manager or team-leader. Very often, both positive and negative outcomes will be fed-back to the “doer” either to correct something or so the process can continue on.

The Peer Review Action in Enate, is a single action with 2 halves. Once the first half has been done, the second half is allocated to a different user to approve it. If they don’t approve it, it goes back to the first user. Both parts have a different allocation rule and different due date rule.

This model reduces the amount of “clutter” on the map as it all “boils down” to a single action which represents the whole “Do and Review”.

Simplifying Processes: applied

If we apply these 3 principals, the example map is greatly simplified.

​Video Playslists

Useful videos of Enate Builder and Work Manager from Enate's Youtube Channel

Custom Card Info

Cases & Tickets Explainer

Enate Data Dictionary

The Enate Data Dictionary explains every table in the Enate Data Warehouse database. You'll need this when building bespoke reporting solutions that incorporate Enate Data:

Solutioning & Project Templates

Useful documents to help you with implementation projects and design workshops.

The Solutioning Journey is a document which explains the various stages during a typical Enate implementation project.

These template documents are useful when running an Enate implementation project.

Sample Workflow

An example of the kind of simple workflow document you may encounter as part of the a customer implementation workshop.

Where information is requested from external resources (users not having logins to Enate) then there is no need to model this request in the flow. The way to think about the workflow is from the perspective of the resource communicating with the external contact. Their activity is to GAIN approval, or GET additional info.

In this example, there is no need to model the “exceptional” flow. The user should validate the paperwork and that might entail getting additional information from a third party.

This, again, simplifies how the process is mapped. It also defines the process from an operational point-of-view. If someone is responsible for gaining information from an external party then the responsibility is on them, not the external party.

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.

Using Sub Processes (Sub Cases):

Some parts of a process, might actually be considered a “Sub Process”. This is common where the “part” can be done in isolation or common to other processes.

In the example, the IT team [setup email and procure equipment], this might be done as part of a “TRANSFER” as well as “ONBOARDING” a new-starter. This part could be abstracted into it’s own CASE and launched from the On- Boarding Case.

The “SETUP USER” case could be launched from different types of processes, e.g. “Transfer”, “Promotion”, “Return from Leave” etc.

From within a CASE or ACTION, the user can elect to launch a “Sub Case”. This is nothing more than a new CASE with a link back to the CASE from where it was launched.

Any CASE that the user could launch manually from the main menu can be launched as a Sub Case too.

The Sub Case will behave according to its own, specific, configuration (just as though it was independent). The “parent” CASE will not complete until it’s Sub Cases have completed, unless the Sub Case was set to “Independent” – then the parent case will close independently of the Sub Case. This is useful when the parents case’s SLA is not dependent on some sub part being completed (e.g. by a different department).

Using Sub Processes (Sub Cases):

There is (currently) no way to configure a CASE in Builder, to launch sub-cases AUTOMATICALLY at a certain point in the flow (instead of an ACTION). Currently, the Sub Case must be launched MANUALLY every time it is needed.

While this feature may be added in the near future, one way to make this automatic with an ACTION given to an RPA bot, which in turn can Launch the required CASE. This is actually more flexible as the RPA routine could include decision logic about which Sub-Case to launch.

Action Due Dates

It is rare for process maps to include information about time, and yet in reality everything can’t be left to the last minute.

If we consider the example process, this might have an SLA of 5 working days from start, so when should the first action be completed by?

Even though client process maps normally won’t include this information, the people doing the tasks instinctively know that things need to be done ahead of the overall due date.

Part of the process analysis is to elicit this additional information about when the constituent actions need to be completed by to allow time for subsequent actions.

Adding Due Date Rules: relative dates.

It is common for a process to have an overall SLA, in this example we have said the On Boarding CASE has a due date that is calculated as 5 working-days from when it starts.

We can then “offset” the due-dates for all the ACTIONS, relative to the overall date.

Part of the process analysis is to elicit this additional information about when the constituent actions need to be completed by to allow time for subsequent actions. Clearly, this is related to how long the task takes, but needs to consider down time, work- load etc.

Regardless of the type of due-date rule being used, it should be considered part of the process analysis.

Re-Merging Flow

In Enate, a process flow can branch to accommodate parallel activity streams.

Currently, there is no way to explicitly re-merge branched flows… accept on a Step change.

Since ALL the open ACTIONS on a STEP must be completed before the system will move to the next STEP, we can use this feature to Re-merge branched streams.

Often in a process map there will be consecutive actions performed by the same resource:

In Enate, an ACTION can have a set of constituent CHECKS. These can represent parts of the activity, but cannot be allocated to different resources or have different due dates.

In the example, these 3 ACTIONS might all be done by the same person with a single overall due date, the constituent activity could then be modelled as checks. This greatly simplifies the map.

Calculate Pay and Start

• Calculate Pay Band

• Calculate Start Date

• Calculate Salary

You would NOT do this if:

• The ACTIONS need to go to different resources

• The ACTIONS have different due dates

• The ACTIONS status need to be highly visible

  • A team leader could see the checks haven’t been done by looking in the ACTION packet, or in dashboards, but couldn’t see it in the Team Leader page or Inbox view.