The total cost of ownership (TCO) for any software system includes both direct and indirect costs. Indirect costs are often hard to see, especially when they hide in plain sight as labor costs. Since the largest expense for most companies is labor, it makes sense to keep your labor costs low by finding and eliminating these hidden costs.

System performance, shadow processes and code rework are common causes of indirect costs. Let's review each one of these and how you can eliminate hidden costs from your CTRM system.

1. System performance 

Your CTRM system has been in production for a while and is no longer as zippy as it once was. Over time performance will degrade without the necessary maintenance to keep things speedy. While small performance degradations may be completely acceptable, there are two cases when it makes sense to act.

Problem #1: Long wait times

The first case is when there are long wait times for any process, especially when retrieving data to the screen. Waiting for more than 5 minutes may be aggravating but acceptable. As you approach 10 minutes of waiting, you are also approaching the danger zone. Applications are often configured to wait for about 10 or 15 minutes before they time out. When the timeout is exceeded you get an error instead of getting data.

Long wait times have several hidden costs.

• • The person waiting is unable to work inefficiently. They must either take a break or switch to another task while waiting.
  • While the process is running, the system may be slow for other users, too. One slow process can create a cascade of waiting.
  • Software timeout errors result in high priority support tickets. This is an emergency that is completely avoidable.

Problem #2: Shorter wait times on high frequency processes

The second case is when there are shorter wait times for a process, and that process is performed many times per day.

Imagine a user interaction which takes 15 seconds to complete. While it’s running, the user simply waits. There isn’t enough time to do anything else while waiting, so the time is wasted. Now imagine that time is reduced from 15 seconds to 3 seconds. If the operation is performed 100 times per day, the savings works out to 20 minutes per day. 20 minutes per day is over 86 hours per year. If the person doing that job makes $75,000 per year, the wasted time is worth approximately $3,100.

NOTE: Most performance improvements are relatively straightforward and low effort, and the costs have a short payback period.

The solution: Eliminate wait times 

It’s surprising, but people often consider waiting to be “just the way it is.” If nobody is bringing the problem to the attention of IT, how will it get resolved?

Be proactive and periodically survey the users of your CTRM system. Ask about any wait times over 5 minutes. Ask about short wait times on high frequency processes. Open support tickets to investigate and resolve these issues.

2. Shadow processes

Shadow processes are processes that exist outside the CTRM system and are directly related to it. Two types of shadow processes are verifying and supplementing.

Problem #1: Verifying

Imagine a bug in the CTRM system is occasionally producing incorrect results. To compensate, users build a shadow process to monitor the CTRM system and verify it is working correctly. This is incredibly inefficient and wasteful.

If verification is needed, work with IT to create automated reports that make this easier. When the source of the inconsistent behavior is found, fix it.

Problem #2: Supplementing

When the CTRM system is not producing the complete solution, users must supplement the result with additional effort. Examples include:

• • A settlements analyst edits a PDF invoice to include additional information or change values
  • A risk analyst pulls the data from the CTRM system into Excel to produce reports
  • A credit manager pulls data from two different CTRM systems into Excel to produce a consolidated report of counterparty risk

The solution: Identify and eliminate shadow processes 

Each example above can be automated. Except for the credit manager example, the solution in each of these examples is to make the CTRM system do the additional work. The credit manager needs an external reporting system that can import data from both CTRM systems and produce the desired reports.

Again, be proactive. If you don’t look for these shadow processes, you won’t find them. Ask the users of your CTRM system how they work with it. You may be surprised at what you discover.

3. Technical debt

CTRM systems grow over time. New features often need to integrate with existing customizations. As the codebase grows, there is usually a need to update existing code to work properly with new code. This rework adds additional cost but gives little perceived value to the business. The IT term for avoiding rework and choosing the easy, more limited solution is called technical debt.

Problem: Avoiding rewriting code leads to indirect costs 

When the existing code is difficult to read, understand, and troubleshoot, it is much more difficult to implement new features that work with it. The way to resolve this is to rewrite the existing code. Unfortunately, the scope of the project for the new functionality often doesn’t include this rework. There is not enough time in the project schedule, or money in the project budget, to do the rework. Building on top of that poorly written existing code is like building a house on sand: it’s a bad idea.

Because the development team must work around the existing code’s limitations, adding the new functionality will take longer than expected. Already the hidden costs are adding up.

Choosing to avoid the rework may also lead to bugs that are difficult to troubleshoot. Once the new code is in production, users begin reporting unusual behavior to the help desk, who are unable to reproduce the problem or find a solution. Frustrated, the users keep reporting the strange behavior. The IT team keeps investigating but finds nothing. Hours of lost time keep racking up.

Leaving the poorly written code in place may cut the direct costs on the project budget, but the indirect costs could dwarf the direct costs. Even worse, when you eventually decide to do the rework, you will have to fix the badly written code and the features that integrated with it. Much like paying for debt, the price you pay is higher when you put off paying until later.

The solution: Don't avoid rework 

When the development team identifies code that needs to be rewritten, take heed. Developers prefer to write new code, not to read through existing code and figure out how it works. If they’re saying it needs a rewrite, it must be less painful than working around the problem.

Rarely does it make sense to avoid the rework. Adjust the schedule and budget to include the rework now or put off the new functionality until time and budget permit.

In conclusion

System performance, shadow processes and code rework can all cause indirect costs. The best way to prevent indirect costs accumulating, is to be proactive. You need to have periodic health checks, especially for things like system performance. Routine oversight and open communication will help uncover and correct process gaps, like shadow processes, before they create a bunch of unnecessary costs. 

Veritas can help 

Veritas specializes in helping clients with CTRM implementations and managed services. We look at costs from a total cost of ownership (TCO) perspective and help clients manage their systems and minimize costs, even after Go-Live. Contact us if you are interested in learning more about our services and how we can help. 

At Veritas Total Solutions, we specialize in CTRM Systems and are uniquely positioned to help clients with their CTRM implementation and managed services. If you are interested in learning more about our specific capabilities, contract us to learn more or subscribe to our blog to stay connected.