The total cost of ownership (TCO) for any software system includes both direct and indirect costs. Indirect costs are generally difficult to see, especially when they hide under the term ‘labor costs’. It makes sense to keep your labor costs low by finding and terminating these hidden costs, since the largest expense for most companies is labor.
The common causes of indirect costs are System performance, shadow processes and code rework. Let’s review each one of these and how you can remove hidden costs from your CTRM system.
1. System performance
Your CTRM system has been in use for a while and is no longer as speedy as it formerly was. Over time efficiency will degrade without the necessary maintenance to keep stuff speedy. While small performance decrements may be completely acceptable, there are two cases when it becomes necessary to act.
Case 1: Long wait times
The first case refers to long wait times for a few processes, especially like calling data to the screen. Annoying, but acceptable may be waiting for more than 5 minutes. But as you reach 10 minutes of waiting, you are also reaching the red zone. Software applications are often programmed for a wait time of about 10 or 15 minutes before they time out. Past the timeout, you get an error instead of data.
Long wait times have several hidden costs.
- The person waiting is unable to work efficiently. 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 domino of waiting.
- Application timeout errors result in high priority support tickets, an emergency which is utterly avoidable.
Case 2: Shorter wait times on high frequency processes
The second case refers to shorter wait times for a process, and that process is performed multiple times per day.
For instance, a user interaction that takes 15 seconds to complete. While it’s running, the user can do nothing but wait. That time is wasted as there isn’t enough time to do anything else. Let’s consider that the wait time is decreased from 15 seconds to 3 seconds. If the operation is performed 100 times per day, the savings turns out to be 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.
The solution: Terminate wait times
It’s astounding, but people often consider waiting to be “just the way it is.” If nobody is reporting the problem to the IT, how will it get resolved?
Be proactive and survey the users of your CTRM system every now and then. Enquire about any wait times over 5 minutes. Enquire about short wait times on high frequency processes. Open support tickets to troubleshoot and resolve these issues.
2. Shadow processes
Shadow processes are processes that exist outside the CTRM system and are directly related to it. Let’s see the Two types of shadow processes: verifying and supplementing.
Case 1: Verifying
Assume a bug in the CTRM system is sometimes producing wrong results. To compensate, users build a shadow process to check the CTRM system and verify if it is working correctly. This is incredibly inefficient and extravagant.
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.
Case 2: Supplementing
When the CTRM system is producing the incomplete 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 terminate shadow processes
Every case 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 integration of platforms 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. With the growth of the codebase, there is usually a need to update existing code to function properly with new code. This rework adds additional cost but gives little considerate 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 challenging to read, understand, and troubleshoot, it is much more challenging 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. Causes maybe, having insufficient time in the project schedule, or capital in the project budget, to do the rework. Building on top of that badly written existing code is like building a house on sand: it’s a bad idea.
Adding the new functionality will take longer than expected because the development team must work around the existing code’s limitations. The hidden costs are adding up already.
Choosing to avoid the rework may also lead to bugs that are challenging to troubleshoot. Once the new code is in action, users begin reporting unusual behavior to the help desk, who are unable to recognize the problem or find a solution. Frustrated, the users keep reporting the unusual behavior. The IT team keeps investigating but finds nothing. Hours of lost time keep piling up.
Leaving the badly written code in place may cut the direct costs on the project budget, but the indirect costs could overtake the direct costs. Even worse, you will have to fix the badly written code and the features that are integrated with it when you eventually decide to do the rework. See where it goes ultimately?
The solution: Don’t avoid rework
When the development team recognizes the code that needs to be rewritten, go ahead. Developers prefer to write new code, rather than reading through existing code and figuring out how it works. If they’re saying it needs a rewrite, it must be less painful than solving the later problems.
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. Being Proactive is The Best Way to prevent indirect costs accumulation. You need to have regular 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.
Robosoft can help!
Robosoft specializes in helping clients with CTRM implementations and managed services too. We look at costs from a total cost of ownership (TCO) perspective and help clients manage their systems and minimize costs, even after implementations. If you are interested in learning more about our services and how we can help, get in touch with us.