By Gabe Minton

In today's market, many lenders are asking how they can improve the quality of their operations and data, often complementary to their existing technology. Their goals are usually to accomplish more with less, or increase their velocity with the same resources (e.g., close more units per month with the same resources). Workflow and workflow automation have long been one of the areas of focus for lenders wanting to make these types of improvements in their operations.

Workflow automation has been around as long as computing has, and has evolved with the large technology shifts that have taken place such as the creation and adoption of mainframes, advent of the personal computer, introduction and mass use of e-mail, dramatic ramp-up of connectivity of businesses to the Internet, introduction of Web services/service-oriented architecture (SOA), movement of systems to the software as a service (SaaS) model, and all the technology advances we have yet to realize. Numerous methodologies, principles and frameworks have been created as well. This column focuses on one element about which lenders should be thinking when configuring workflow in their systems.

I would like to define the term exception-based workflow as utilizing workflow within a given system, such that human resources are only notified on an exception basis. It is not good enough to just automate processes. People still will be monitoring the process as it runs through to completion. The goal is to design the process and configure the system so that people are only notified or called upon when they need to be on an exception basis. If the process runs correctly and returns results within appropriate ranges, then move to the next step.

A good example is when an underwriter may be notified to look at a loan after a credit report is pulled. If the FICO score is within the range for the product the loan is associated with, then the underwriter may not need to be notified. As soon as you configure against data that are not simple numbers, it becomes more challenging but also potentially more rewarding.

There are common business patterns that can be used to discuss this further and create a pertinent example. Things such as users, tasks, milestones and work queues are abstractions that apply to virtually any workflow system. Most workflows are diagramed as an exercise between the business analyst (which could be in-house) and the end user/lender. As the lender going through this exercise, you should be thinking about when each role or type of user needs to be notified or alerted within each workflow, with a goal of minimizing these notifications if the process runs within acceptable boundary conditions.

If we go back to the underwriting example, the underwriter is the role of a person. Ordering credit is a step in the loan processing workflow that occurs at different points based on channel, and a (merged) credit report is a complex document. Making a determination based upon the FICO score is a simple exercise, but taking it to the next level is what we are talking about here. If the FICO score is less than the range associated with the product type for which a loan is slotted, what other steps can be taken in the workflow before a person is notified or added back into the criticalpath? Upon what part of the credit report can the workflow make a further determination before it needs to notify the underwriter? This will vary by loan product, risk tolerance and more.

There are many areas within the loan origination process where this exercise can be performed. Also, new tools and data are becoming available all the time€"all becoming new steps in the workflow and affecting it. For example, introducing automated valuation models (AVMs) to the process introduces AVM technology to your workflow. How does this technology subsequently allow for the further reduction of exceptions that insert people into the critical path?

In going through the exercise with an exception-based looking glass, new efficiencies can be gained because you ultimately are configuring your technology platform to come to resolution and therefore do more of the work. That leads to increased productivity from your human resources. This is due to the fact they are notified less frequently about issues requiring their involvement. By configuring more workflow into your technology, you also reduce the possibility of errors being introduced into the proces (less instances of rekeying, less opportunity for a human to make a mistake looking at a report instead of a machine-decision based on a number, and so forth).

If a workflow-based technology is fully utilized and completely exception-based, then human resources are only brought into the workflow/critical path when the technology cannot render a decision. Therefore, people as a whole within an organization are notified and assigned tasks less often per loan, and thus more loan units are processed utilizing the same resources.