Continual internal process improvement is often the greatest threat to any organization. It's never more apparent than when an organization commits to changing a computer system. When a new system is chosen, it will result in the need for process improvement. You may wonder why there would be a chapter on processes in a digital transformation book, and the reason is simple. Eventually, every process in your organization will be digitized, and as a result, your digital processes will reflect your analog processes. For instance, if there are 71 steps in your current loan application process, there will likely be 71 steps in your digitized process. However, a digitized process should reduce steps, improve speed, and improve efficacy. For example, solid processes can—and should—transform a 71-step loan application process into a 3- or 4-step process. Unfortunately, our human instinct to avoid change kicks in. Our instincts are to avoid the unknown and resist things that force us to change, and as a result, getting the process down to a few digital steps will prove to be an uphill battle for even the most seasoned executives.

Regulatory Gridlock

The fear of the unknown is normal for everyone. We know that the existing 71-step process works, so why would we change it? There may even be obvious improvements in the process, and the staff may even acknowledge these initially. Eventually, though, they begin to worry that that outcome of the process will slow them down or put their jobs in jeopardy. This is when we encounter another kind of gridlock. I call it regulatory gridlock. Regulatory gridlock is when subject matter experts (SMEs) on a certain process decide that they don't like whatever is being proposed. Because they are the experts in the process, they invoke a regulation or some other rule that forces the organization to abide by their process.

To understand how irrational and unproductive this is, consider this nonbusiness example. I have a friend whose wife is devoutly religious. Whenever they have an argument or there is contention about something, she will say that God has told her that she is right. As you might imagine, it is difficult to counter the rule of God. It's also difficult to counter an SME's subjective interpretation of a regulation. Sadly, I have seen this tactic work many times, usually because the SME is well regarded in the organization or has overseen a process for many years.

The SME usually believes in what he or she is doing because of what I will call the 1 percent rule. Here is how it works: The SME is a tenured staff member, and as such has seen every permutation of a process. Somewhere along the line, there was a trauma during the process and, as a result, a step was added to the process to resolve this issue. The trauma was real, but in the scheme of things, the chances of it happening again are slim. So now the process has a step in it that covers something that rarely happens or may never happen again.

To be fair to the SME, when the problem does happen, it's not fun. But is it necessary to force everyone through an additional step to avoid something that hasn't happened in 10 years? For the SME, it feels like the issue occurred yesterday. I use the analogy of a wound and a vow. The SMEs and their staff were wounded by the fallout of the trauma and they vowed to never let it happen again. Now you are amid an opportunity to rework this process, and they are blocking the effort. No one wants to challenge the SME because of fear of retribution or, worse yet, a regulatory beat down. To counter this, use analytics to determine the likelihood of the issue happening again.

The Risk Spectrum

Inability to reduce or reengineer processes due to organizational muscle memory is a common theme in financial institutions. The main reason is that there is a high price attached to failure, and as a result, processes are often engineered for the 1 percent because in the employee's experience, failure is not an option. In this regard, it is important that the organizational leadership put the right perspective on failure. Failure, when it happens, shouldn't be a taboo subject; it should be talked about and shared. One thing that might help to put failure in perspective is to look at failure by industry.

By evaluating the two extreme ends of the spectrum, one can gain insight into the playing field. At one end is the entertainment company Pixar, where employees are encouraged to fail, and fail fast. The price for failure at Pixar is missing a date on a movie or losing money due to failure. At the other end of the spectrum is an airline company, Boeing. The consequence of failure in this industry could be loss of life (Figure 1.1).

Where does the financial industry fit in this continuum? By using the failure outcome as a litmus test, we can try to put some perspective on where we are on the risk continuum. We can start by saying that no one is going to die from a failure at a financial institution, so we don't belong at the end with Boeing. We can also rule out the other end of the spectrum, as there is the potential for a financial loss and there is a big reputational risk to the organization, particularly with a digital risk that could lead to a security breach. So, on this spectrum we are somewhere in the middle—people won't die, but there is a lot at risk for the organization and for that organization's customers.

The first thing to do is find your place on the risk spectrum and devise a process to evaluate risk for new processes as well as to reevaluate risk in current processes. Here are some things that should be included as part of any process risk review:

• How often is this process performed? If the process is rarely performed—such as, for instance, a reverse mortgage, perhaps it is not even worth having the product that the process is attached to. Or conversely, if the process is excessively used by the entire organization, then it needs to be on a list of critical processes that are continuously evaluated for improvement.
• How much of the organization is affected by this process? Is the process specific to a department? Processes that are cross-departmental, such as a loan application, need to be evaluated differently than an internal department process like collections.

On the website, you will find a template for evaluating the risk within processes, products, and new features. The risk review should be scored and shared with senior management as well as any process governance groups within the organization. If the process needs to be changed, the risk review should be performed again. For a process, the risk review should cover each of the steps of the process. The process review should provide data definitions and justification for each step of process.

Flawed Bank Processes

It is not necessary to evaluate every process within the average bank to discover the major flaws in our processes. Instead let's take a look at a very common process and point out improvements that can be applied to other similar processes. One simple process with potential complications is an address change. Here is the scenario: A customer calls the call center, goes to the branch in person, emails, or visits the website to change an address. Seems simple, right? Shouldn't it just be going to a screen somewhere and changing the address? Simple processes are often the most deceptive. The address process has several complexities to consider:

• In most large organizations, customer addresses can exist in several systems. For instance, if the organization outsources its credit card processing or mortgage servicing, the address would need to be changed in each system.
• There can be more than one address. Many organizations allow their customers to have a primary address and a secondary address for, say, a business account. Changing the wrong one can be catastrophic. I once worked with an organization that had not identified the primary and secondary address, and when it changed the process, it accidentally copied the primary account address into the secondary address. While this might not seem like a big deal, it is to the customer who doesn't want someone at the primary address to know about his or her other account (especially if it is conveniently named DIVORCE ACCT, as this one was). As you might imagine, the organization had a few upset customers. This oversight created a liability for its organization related to privacy.
• The address might be associated with more than one account holder. For example, there might be a joint or beneficiary but the customer might not remember to tell you. How do you update them all? Do you update them all?
• Address changes can be subject to fraud. As a result, it would be necessary to notify a customer out of band when there are changes on their accounts such as phone numbers or addresses. How do you notify them? Email, snail mail? All the above? Do you do this in all situations? What if, for instance, members come in person to the branch and verify their identity?
• Digital address validation is now possible, using online services such as the national change of address repository. However, I have found in many organizations that the practice of validating addresses is spotty. Meaning that if a customer calls the call center, the address gets changed with no validation but if the customer uses the home banking platform, the validation happens.
• There are many types of addresses to consider. These include foreign or military addresses, which require different fields and different validation.
• Addresses also have to be run through the OFAC process. This is necessary to make sure that they are not associated with terrorism.

As you can see, this process is far more complex than it seems on the surface. So how can this process be improved using simple process improvement practices? Using the process review form from the website, one could score the risk related to each step, and based on that risk either remove, improve, or add steps. Second, since the review for this process revealed the process is cross-departmental as well as self-service, it would benefit from process centralization. A general rule of thumb is that if a process is either a candidate for self-service or currently self-service, there is a good chance it can be centralized by exposing the same customer self-service platform to the staff.

Confused? Don't worry; let me explain. In 2003, when my team and I were developing an in-house home banking solution, we frequently had to go into the staff portal (these are the green screens that the employees use) to validate that the home banking product was working properly. During the continuous back and forth between the home banking application and the staff portal, something occurred to me: Why can't the staff just use the home banking interface we were developing? My reasoning was that we were creating a financial portal for millions of customers and we expected them to use this platform with little to no training. This meant that the interface had to be intuitive and couldn't depend on the customers remembering codes or the steps of a process.

For instance, if a staff member needed to tell customers what the balance was on their mortgage, the staff member would have to open up a new program, sign into a different system, and type several codes to see the current balance. However, in the home banking platform, we collected these data on behalf of the consumer via electronic means and conveniently displayed it for them on the accounts screen alongside all of the other balances from the various systems the bank used to process their data. I realized that if the staff had access to this screen, they could reduce the process of getting a mortgage balance for a customer by several steps. I immediately started working on what it would take to allow staff access to the home banking platform and presented this to the management as a new feature.

Now let's consider the address change process in this context: If your organization has digitized this process for the customers, then this should be reused for the staff, and focusing on the customer version of the process would produce a more efficient transaction. In the situation I mentioned above, we had already built an address change process that addressed all the complexities just mentioned. Moreover, the digitized version, when used by the staff, would ensure that each step of the process was followed, regardless of which channel the request was received on. Since the process was centralized, it greatly reduced the work to integrate the other systems such as credit cards or mortgages. Rather than integrating three or four different processes, we could integrate one, which reduced technical debt. Finally, this allowed the statistics of the process to be accurately recorded.

The trick here is to understand the difference between a customer using the product and a staff member and consider this during your development and implementation phases. For instance, the address change that is done by a staff member must include the proper audit mechanisms, whereas the customer will likely have a different set of rules. How many processes could be improved by exposing the digital process that you have created for your customers to your staff?

Continual Improvement

Now let's take the address process and apply the practice of continual improvement to it. Continual improvement is the practice of improving a product, process, or feature in small increments on a regular basis. One challenge I see in banks is the lack of continual improvement. Once a project or process is done, the organization moves on to the next project and only returns to the project in a crisis such as a regulatory mandate to update it, or if a loss was incurred due to an unforeseen risk. In these situations, the process is reviewed, but usually it is only updated to deal with the issues at hand. In a continual improvement environment, the process would be reviewed regularly by a different group than the group that originally implemented the process whose purpose is to continually improve the process.

Analytics and innovation would play a strong role in this process. If analytics for the address change revealed a rise in mismatched zip codes, perhaps the continuous improvement group would add a zip code validation process to the field that collects zip codes, or perhaps your team identified an opportunity to innovate and to make address updates easier, by adding a way for a customer to use their smartphone to take a picture of their new address on their license, or any other document, and use the evolving object character recognition engines (OCR) to input the address on behalf of the member. The group responsible for process improvement would release new updates at scheduled intervals and continuously and aggressively solicit candid feedback from the process stakeholders. The group would also continually review the process at other organizations looking for improvements.

Project Management

Project management is a process within the organization. It's a very important process, but in most financial organizations it is broken because of the way financial institutions have evolved—especially when compared to fintechs.

When to Use Agile versus Waterfall

Figure 1.2 depicts a quick flowchart to help you decide when to use agile and when to use waterfall:

1. Are the requirements fully known and documented?
2. What is the availability of the stakeholders?
3. Are the stakeholders familiar with the agile process?
4. What will it cost if there needs to be changes made?
5. Can the project be phased?
6. Will the project be completed by in-house resources or outsourced?

John also correctly points out that agile must be taught to the entire organization. There is a tendency for organizations to only train the information technology employees and project management in agile. This will not work. It's a little like putting a Ferrari engine in a Volkswagen—it's great that the engine is new and fast, but if the frame, tires, and other parts of the car can't handle it, it will fall apart quickly. I had one CEO liken it to having a rowboat where one side of rowers is far stronger than the other side, and as a result, the boat just goes in circles. Agility is important to the entire organization, and if staff members are not trained and do not buy into the concept of agile project management, the result can be catastrophic. Other untrained departments will view all the stand-up meetings and constant involvement of their staff as unnecessary overhead, and because they haven't experienced the end result, they will likely not fully participate, which will sour the group on the agile approach from the start. Half measures always avail us nothing.

In-house Staff and Outside Vendors

I can hear you saying, “But John, I am not in control of my products; we don't have a development department.” Good news! Most of your digital vendors have likely adopted the agile methodology of software development and are usually happy to have some end-user participation. This prevents them from releasing software that doesn't meet the needs of their customers. Often, these vendors will have advisory groups or user groups that are specifically designed to collect, document, and evaluate processes (often referred to as user stories) for their continuous improvement process. Key staff members should be encouraged to participate in these communities on behalf of your organization. This will help you influence the future of your software packages as well as share and learn best practice from other organizations. Push to be part of their agile process and see if you can attend their stand-up meetings for software packages that are key to your critical processes. Even implementation of a vendor's product can be executed using an agile project plan. This is an important distinction—that you can replace development with implementation in the agile process model in cases where your organization is not in control of development.

This same process can also be applied when using a consultant group to do your development. In fact, this process is likely the only way to achieve success when dealing with a offshore consultancy, as the agile process allows the organization to overcome the culture challenges that are often present when working with offshore development groups. Learning to work with consulting groups will be an important part of every financial institution's digital future. The resource challenge is real for financial institutions, especially the push and pull between new projects and keeping the lights on in the organization. One way to combat that is to develop in-house expertise at working with outside consulting teams.

Developing leadership inside the organization will pay huge dividends, especially if those leaders can expand their influence beyond the four walls of the institution. A project leader or technical project leader might work with several outside firms at once to create a single platform, feature, or process within the organization. The leaders' most important task is to determine what should be outsourced and what work should stay in house. For instance, if there is a massive amount of business logic that is not formally documented in a project, then it may be necessary to have the in-house resources build the business logic services because they have a better understanding of the business processes and more access to the subject matter experts, since they are onsite with them. If there is a front end that consists of building screens to collect data and send it to the business processes and it is a documented experience, then that would be a good use of the outside development group since they don't need to understand the complex business logic involved in the process. If the outside development group has technical domain expertise beyond what is in house (like designing mobile applications), then the leader may decide to farm out entire projects to the outside firm, relying on an agile process to keep the project in scope.

Let's use building a mobile loan application as an example project. I have added a few major tasks in the process (Table 1.1). Note the location of the working group for each task. Would you make the same choices in your organization?

The idea is to make the best use of your local resources who have special knowledge and, as a result, are more valuable to the organization, and augment them with cheaper outside resources who work on less complex tasks. The value in this approach is increased speed and agility, as well as reduced cost.

Interdepartmental processes are also a challenge inside of financial institutions. An online loan application, for instance, might start in the e-business department, transition to a branch, then go through the call center, and finally to a closing agent. How do you maintain continuity and communication, both with the user and the staff, when a process traverses many departments?

Process Management

The first thing is to standardize the entire organization on a single tool for process management. The majority of the time, the organization will be looking to digitize an existing process and as a result, most process enhancements usually include a website or digital forms. However, if accounting has its own accounts payable process built on proprietary software, then it will be difficult to automate certain stretches of the process because they are not on the same system. This is where the digital governance group comes in to play, as they are responsible for ensuring that all systems introduced to the organization are open and compatible with the other platforms. A digital process platform is often referred to as workflow platform. There are many tools available to financial institutions in this space.

Microsoft Workflow is a product that integrates with the Microsoft office suite of products and allows for automation of processes and tasks. If you are a heavy Microsoft shop, then this could be a great tool to use to start digitizing processes and creating efficiencies. There are also many cloud-based tools that are evolving. Process Street (www.process.st) is an example of a workflow product entirely hosted in the cloud. The platform is designed to automate tasks and processes, and track the progress. Another very popular tool is Kissflow (KiSSFLOW.com). Kissflow is a tile-based system that presents a user with a list of tiles (known as apps in the system) that can be done on the system (start a new loan, request a check copy, etc.). When accessed, the application walks them through the task with intuitive screens (Figure 1.3).

Team Organization: Centers of Excellence

The next step is to organize your teams into centers of excellence (CoE) around your major functions. A simple breakdown might look like this:

1. Lending
2. Enterprise
3. Member contact (Branches Call Center)
4. Digital services

Once you have organized your groups, it is far easier to assign tasks while designing a process. For instance, a lending process might cross each of the groups (as described in the example above). In the old model, call center representatives might have been forced to specialize in lending, or lending experts would deal only with application origination. Neither of these is an effective use of the resources' time. In the new model, the call center representatives would be based in lending and work directly with member contact as part of their charter. This reduces the risk of dysfunction between the call center and the lending group by organizing the resources into a structure that shares common work threads.

When all processes are mixed together without regard for function, there is no accumulation of domain knowledge as these processes evolve. This happens because no one feels specifically responsible for the process. The lack of ownership or accountability is especially common in cross-functional processes. This is precisely because the process is cross-department, and as a result, no one wants to take ownership because they feel that they don't have total control. It is valuable to implement workstreams or processes that are aligned with the centers of excellence. When the processes are aligned with functional areas, the owners will be more comfortable that they can be managed without having to deal with departments that they have no control over. Each process will have a defined owner, and as a result, the process will be more aligned with its discipline as opposed to its delivery channel.

Cultural Considerations

When I am reviewing organizations, I often hear from middle managers that they feel understaffed. When I interview the manager, I usually find that there aren't any steps being taken to work smarter. The group is always very willing and passionate about working hard to complete each task as part of a process, but they lack the ability or authority to review a task or process and try to find a tool, product, or service that could reduce the workload. This is a cultural issue; the employees don't feel empowered to present ideas to improve a process that they work on every day. As you might imagine, it is demoralizing to work passionately on a process each day and then not be consulted when there is a process change. This is a fatal organizational mistake, because those closest to the process need to be heard the most. They are the ones who are most likely to have a great idea on how to improve the process, or they can scuttle a process change to protect their turf. For more on how culture contributes to gridlock, see Part III.

Regularly reviewing your processes and looking for incremental improvements by implementing digital assets, reducing complexity, or centralizing the process is necessary to achieve digital transformation. A bad process, digitized, is still a bad process.