Workflow techniques, part 2: Finding opportunities to optimize

In the last edition of Peridrome Perspectives, we discussed how to identify critical processes and develop diagram flows. We now have a set of swimlane diagrams we can use for analysis of our current state operations. In this article, we’ll cover techniques to analyze our current state processes to find opportunities to optimize them.

First, let’s review our example diagrams, which represent service processes for two typical client requests to an investment manager operations department. You may recall that dotted lines between tasks overlapping swimlanes indicate instances when more than one team or system is involved.

Here’s our distribution request handling process:

And here is our process for handling client requests to harvest tax losses:

The tax harvest process continues with buy back activities:

Now we’re going to drill in a little more deeply by performing the analyses described below.

Check for robustness

Before beginning the optimization analysis in earnest, double-check your diagrams for robustness. Do your diagrams really capture all of the steps of the process? There are a few areas in particular you should consider.
It’s easy to remember what happens at the beginning of a process, but sometimes the steps at the end might be overlooked, particularly if there are recordkeeping activities or client wrap-up tasks that follow trading. If you find these activities can’t be eliminated, add them to your diagrams.

Also, make sure your process diagrams are realistic in terms of handling potential errors at various points in the flow. Human nature is to be optimistic: we are wired to believe everything will always go according to plan. However, this isn’t always the case in high-volume service operations. At every task in your diagram, ask yourself the question, “Can anything go wrong here, and if so, what would happen next?” For instance, if a trader catches a problem with a client’s tax harvest request, he might send it back to the account administrator. When you find instances like these, add the appropriate lines or tasks to your diagrams.

When you’re satisfied with the quality of our current state diagrams, you can move on to the optimization analysis.

Confirm collaboration relationships

Remember the dotted lines you drew between tasks overlapping swimlanes where more than one team or system is involved? It’s time to look at those more carefully. Tasks that must be performed by multiple participants at the same time take longer, and are more prone to error. Examine work being done in these sorts of tasks carefully, and consider ways to get the same work done with fewer participants. For instance, in our distribution process, the portfolio administrator must post an entry into the accounting system, which then rolls through to the portfolio management system. Is it possible for the entry to be made automatically?

Rationalize error handling

When you did your robustness analysis, you captured all the points in your processes where errors could occur along with the flows to handle them. Now, it’s time to look more closely. Handling errors is extremely time-consuming, particularly if they occur in the latter-stage activities of a process. After gathering more detail on the types of problems encountered by participants in a given activity, look for ways those errors could have been avoided by modifying tasks upstream in the process. If it’s not possible to completely avoid downstream errors, make sure the workflow to resolve the error does not move unnecessarily far back in the process, while balancing the need to keep work moving for the participant group encountering the potential error.

Identify parallelism between processes

One of the most powerful tools to optimize processes is identifying similar flows among processes, and then abstracting them into modular, reusable sub-processes. As the sub-processes are optimized, the benefits will extend to all the “master” processes that use them. And management of the tasks involved can be greatly streamlined.

For instance, our example distribution and tax harvest processes each have a similar set of activities performed at the beginning. In both cases, the account administration participants validate incoming requests, and if problems are found, they then triage those problems with the sponsors submitting the requests. There may be an opportunity to create a separate workflow managing validation and follow-up that can be shared not only by these two processes, but also by others, such as new account set up.

When looking for such parallelism, focus on the tasks and sequence, not the participants involved. You may find that in some cases, two different teams perform very similar tasks in similar sequence in the context of larger operating processes. For instance, at some firms, the trader participants would be responsible for validating the content of tax harvest requests (and following up), while the account administrators would validate distributions. As the manager of both teams, you may see an opportunity to create a modular sub-process for validation that would be reused to service both types of requests, and thereby provide better utilization of each team’s resources.

Research technology enablers

As you work through the analyses above, you’re likely to encounter situations where the opportunities you’ve identified may require a technology solution. Review your notes at this point, considering the following situations that often lend themselves to technology enablement.

Look at the business events that begin each process. In the case of client requests, these events will usually involve receiving communications from sponsors, typically by fax, email, or through proprietary sponsor web sites. How does this information enter your process? Would a fax server help? Or, is it possible for you to take advantage of electronic communication of information? Using technology to streamline how you handle receiving information from distribution partners can pay big dividends all the way downstream in your processes.

How do internal teams participating in the process communicate? Email is ubiquitous in every organization, but may not be the optimal channel for routing volume-intensive communications like client requests, where important service items will fight for attention with other emails. This may be a time for you to consider other sorts of solutions, like workflow products or groupware (or managed-account specific solutions, such as Peridrome Dash).

Study the decision points in your diagrams represented by diamond-shaped boxes. What decisions are being made in these instances, and would it be possible to introduce technology to automate that decision-making? (See "The three stages of managed account client service" in this edition of Peridrome Perspectives for a discussion on the use of rules technology.)

Finally, look again at the tasks where human participants are interacting with systems. What work are the participants doing with the system? Does the system support an interface for real time data exchange that could be used to reduce the need for human input? For example, in our distribution process, the portfolio administrator simply enters the amount of the requested cash distribution into the accounting system—an easy task to automate if an interface is available. However, the trader’s interaction with the portfolio management system when building and releasing trades is much more sophisticated, and difficult to automate.

Next steps

We’ve looked at two volume-sensitive service processes, distributions and tax harvests. After applying the analysis techniques described above, we’ve found a number of opportunities to optimize the workflow. In the next part of this series, we’ll map out the optimized “to-be” processes, exploiting these opportunities where possible.