Author Kestutis Skrodenis
In this article, I will share some real-life experience in building workflows for service-centric organizations (such as leasing and asset-finance companies) and provide some practical insights.
First we should clarify the term “Workflow” and differentiate it from the related concept “Business Process”. Both Workflows and Business Processes are typically visualized as a flowchart with entry points or triggers, a sequence of activities and decision points, outputs and exit points. However, “business process” is a wider term, while a “workflow” is a technique used to automate and facilitate a business process. In this blog series, I will focus on people-centric workflows, because they are more interesting compared to pure software-centric workflows. A sequence of actions that is fully automated and done by software does not require daily attention, and there is little space for improvement.
Let’s assume that your organization already has
- Well-defined business processes,
- Software to facilitate the process, and which has workflow management capabilities,
- People involved in the process.
Building Workflow Blocks
Referring to the generic workflow diagram on the left, let’s analyse each type of workflow building block.
TRIGGER – an event, either external or internal, human-driven or software-driven, which requires a complex response. Examples of triggers can be:
a) Customer request for loan variation (external trigger, the response is complex – credit approval, multiple actions, multiple interactions with the customer);
b) Marketing initiative to launch a promotional program (human-driven internal trigger, requires multiple actions and approvals by multiple departments);
c) Credit application submitted via a web portal (software-driven trigger).
INITIATE – creation of a workflow instance, where an Initiator (officer or software process) must determine what type of workflow is required (i.e. selects the workflow template), describe the action required and provide input information for the next steps. For example:
a) Identify the customer on a phone call, link the workflow to the customer record, log the customer request;
b) Prepare a promotional program brief and launch the approval workflow;
c) A software function initiates the credit assessment workflow.
DECISION – you always have a decision point when there are several possible next steps. A typical example is approval of the action.
Remember, we are talking about human decision points only. Decisions are often limited by business rules (preferably – controlled by the system). For example, a particular officer can approve credit applications up to certain amount. In real life, before a decision point, you may have actions to collect and evaluate information, for example – a credit assistant calls a credit bureau to do reference checks, to verify the credit application for accuracy and then forwards it for approval.
DELEGATE – directing a workflow to a particular person, i.e. assigning a task to an officer. Depending on the size and structure of your organization, there may be several scenarios:
a) Officers proactively pick tasks from a team inbox (e.g. an approval task flows into the Credit Team pool and officers take ownership of those tasks in sequence). This way you can achieve self-balancing of the workload (subject to officer incentives).
b) The Manager receives all team tasks and delegates them to officers.
ACTION – carrying out a required task, using input from previous workflow steps, for example:
a) once a credit application is approved (that is an input) – send out an approval letter to the customer and a credit guarantee letter to the dealer (that is an action)
b) When a customer requests a loan variation (new conditions defined and approved) – then update data in the system and prepare the contract annex (i.e. adjudicate the loan variation).
c) When a promotional program is approved internally – then activate the program in the system and distribute information to dealers.
FEEDBACK – inform the Initiator of the workflow when the requested action is completed (or declined). For example – need to call back to the customer.
In real life, several more types of action must be included in the workflow design (not shown on the picture, just for simplicity):
The officer may need to withdraw the workflow if circumstances have changed and the workflow is no longer relevant. There are scenarios when the system must cancel the workflow automatically, for example: if the customer withdraws the credit application the assessment, workflows must be cancelled.
The officer may need to refer back to the Owner of the previous step (e.g. Initiator, Approver, Delegator) if the officer cannot complete the task because of missing input details. You can refer back from any point in the workflow.
…to be continued.