Using Sub Processes

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.