Workflow techniques, part 3: Building the "to-be" process

Welcome to the third article in our series on workflow techniques for optimizing managed account operations. Our previous articles explored two common managed account client service requests, distributions and tax harvests. In the first article, we took stock of participants, and created swimlane diagrams of our current state processes based on the type of request. In the second article, we discussed techniques for analyzing those flows to find opportunities to optimize. Now, we’re ready to put those techniques to work, and map out our “to-be” process.

Technology enablers

After going through the exercise of optimizing our operational flows, we want to make sure the new processes are fully adopted. We also want to analyze the performance of the team over time in completing tax harvest and distribution instructions. For these reasons (and others), we’ve decided that our new “to-be” processes will be implemented using an automated business process management (BPM) engine.

After some research, we’ve also learned that our accounting and portfolio management system offer online interfaces that we can leverage to reduce the reentry of data. We have therefore selected a BPM platform that can integrate with the interfaces offered by our core accounting and portfolio management systems. (We’ll discuss how to evaluate a BPM platform for use with managed accounts operations in a future article.)

Process reuse

As we analyzed our current state distribution and tax harvest processes, we’ve found some similarities in parts of the flows. We’ve decided that the initial request review and the trading activities are good candidates for generalization and reuse, so we’ve mapped out each as a subprocess that later will be used as part of a larger process.

The “Receive Request” subprocess

We’ve decided to capture the basic information received from client requests into forms presented by our BPM system. This will allow downstream participants to have a standardized view of request information, and avoid having to decode the various email, fax and web forms used by sponsor firms to submit requests. The data entered can also be used as necessary to update other partner systems, such as accounting and portfolio management, allowing for straight through processing. Finally, the captured data allows for a historical record of client requests handled by the team.

We’ve also discovered, on further analysis, that account representatives receive a certain number of requests that require escalated review before further action is taken. In the current state process, account reps email their questions to the compliance rep. However, in our “to-be” process, we’re opting to have the compliance rep participate in the workflow, so we’ve added her to our swimlane. Including the compliance rep in the process flow also makes it unnecessary for her to revert to the account rep after approving or rejecting a request.

By making the “Receive Request” subprocess more robust, we’ve also made it more likely we’ll be able to leverage it when automating other request types (like new account set up). We’ve also established a level of consistency in how client requests are initially reviewed, which hopefully will lead to fewer problems downstream.

The “Trade” subprocess

Rebalancing client accounts, generating orders, and releasing those orders is a common task for many types of client requests, so it makes sense to create a subprocess for these functions. Again, we’ve taken the opportunity to get in front of potential errors and make the flow more robust by adding a review of completed trades on T+1. Incomplete trading discovered at this stage by portfolio admins will be corrected by routing the request back to the trading desk, together with notes describing the issues found.

Completing the Distribution process

Having defined subprocesses for request review and trading, we can now focus on the few additional steps specific to distribution processing. We’ve created a higher-level block diagram to represent the “to-be” distribution process:

The underlined “Receive Request” and “Trade” boxes represent our subprocesses. We need to define the activities in the “Update accounting” box. Distribution requests require the ops team to post a “dummy” cash debit to the accounting system, and update the portfolio management system. In this case, we’ll integrate with the accounting system API to complete that posting automatically, reverting to a portfolio admin only if an error was received from the interface.

Completing the Tax Harvest process

Fulfilling a tax harvest request doesn’t require an accounting or portfolio management update prior to trading. However, after initial gains or losses are raised, the securities sold must be repurchased in the client account. For this reason, our master tax harvest process shows a “Buy Back” subprocess that occurs after the “Trade” subprocess:

The “Buy Back” subprocess begins with the portfolio admin posting wash sale restrictions if losses were raised, then waiting through the 31-day wash period before cueing the trading desk to repurchase. (If gains were raised, restrictions and a holding period aren’t necessary.)

The second part of our “Buy Back” subprocess looks very much like our “Trade” subprocess. Why didn’t we reuse the “Trade” subprocess again in this case, splitting off the trading activities from the wash period activities? We chose to create a separate process for business clarity. Although reuse would have been technically possible, we wanted to emphasize the difference between trading for the initial tax harvest, and buying back when losses were raised.

What we’ve accomplished

We’ve made some real progress. Identifying the “Receive Request” and “Trade” subprocesses also resulted in our rationalizing a generalized model for handling client requests that we’ll be able to reuse when designing the workflows for other request types. This approach builds integrity into our operating processes, and will make it easier for new staff members to understand the flow of request fulfillment.

We’ve also built in a more robust level of quality review on critical steps in the process (e.g., the initial evaluation of the incoming client request and the post-trade review) that will pay dividends in terms of reduced errors and improved client service. And because these activities are in our reusable subprocesses, as we make further improvements, all flows that use the subprocesses will benefit.

Finally, we’ve taken a big leap forward by implementing our “to-be” processes using an automated BPM platform. This will not only ensure staff consistency in following established procedures while servicing client requests, it will also provide a starting point for management review and continuous process improvement.

Going to the next level

Besides applying our experience with tax harvests and distributions to other types of client requests, where do we go from here? We might look for ways to better manage the intake of new client requests—perhaps by centralizing the collection of emails, faxes and files into a single queue for review by the account reps. We might also consider how some of the routine review performed by the account reps could itself be automated through the use of business rules technology. So stay tuned, we’ll be covering those ideas and others in future articles!