GROWTH BLOG: Why tech and product leaders need to think about gross margins
AKF Partners Logo Technology ConsultingScalability - We wrote the book on it ℠

Growth Blog

Scalability and Technology Consulting Advice for SaaS and Technology Companies

Safely Paying Down Technical Debt for CIOs

April 14, 2020  |  Posted By: Phillip Seawright · 6 min read

Synopsis:  This is a post focused on technical debt for traditional IT, or for teams focused on solutions for internal employees.  This post helps CIOs (leaders of IT teams - not product teams) quickly assess where technical debt occurs throughout the organization to identify short term and long term investments with the right owners.  We’ll focus in more detail how to address the debt that accumulates when a core operating platform such as an ERP has failed to keep up with the needs of the business.  This debt is typically a combination of inefficient tools being maintained by technology department, inefficient workers (labor) in the business using various tools to manage various processes, and lost business opportunities (revenue) from a workforce that can’t compete as quickly as its competitors.  To unwind this mess, CIOs need to map the current systems (tools) they have built and map the current processes (people plus tools) as they exist in the organization.  By analyzing the combination of tools, processes, and people, it becomes much easier to identify short term and long term solutions.  This also greatly reduces the risk of a long term solution such as an ERP replacement. 

In our previous post, we described the situation we see in many B2B companies where technical debt has led to organization debt.  However, it is difficult for many to quantify where this debt sits in the organization and how to pay it down or refinance it.  In the example below in Scenario #2 (Launch it and Leave it), an organization invested in a large ERP solution but failed to invest the business and technical side labor to keep the platform in line with the business needs.  Think of an ERP as the core operational platform that runs your core business operations – it may not be referred to as an ERP in your industry.
technical debt

Your ERP or core operational platform is one of the more powerful tools used to help your workforce do their job.  When you fail to maintain these critical platforms, employees and technical staff will fill the gaps with less powerful tools.
technical debt erp

The question the CIO should ask is “What investment or investments will help me close the gap?”.  The CIO is likely concerned about ripping out and replacing a large ERP platform because these are large, high-risk investments that have very high failure rates.  In order to identify the right mix of large and small investments to pay down debt and to de-risk a rip and replace, the CIO needs to make sure the organization has a clearer picture of what tools people are using today for the majority of processes related to the ERP or core operational platform.

It may seem like a daunting task to get a clear picture of an ERP system that is more than a decade old supporting dozens to hundreds of processes, particularly when the organization has invested in BI (business intelligence), workflow, document management and other tools that are hanging off the ERP platform to keep employees productive.  Even with a strong partnership between the technology organization and business users, it can become difficult to know how users are actually using various platforms for each process.  It can also become difficult to see and remember what the technology team has built and automated (or semi-automated) over the years.  As such, it is important to have a good picture of your processes and systems.
people process technology

A CIO should ideally lead the effort to visualize processes and systems in a way that non-technical people can understand.  There are several methods or techniques for visualizing processes and systems.  To move most quickly and get the technology team organized, we recommend mapping and analyzing systems and applications first.  This can help you determine which processes need to be visualized and analyzed.
system diagram ERP

An internal team could spend months documenting, diagramming, and analyzing systems.  We recommend time boxing the exercise.  That is, have a small technology team identify how well they could diagram and analyze a core platform or platforms in 1 day, 1 week, or 1 month.  For example, a 1-day exercise will likely yield a diagram that is understandable by a handful of people within the technology organization.  A 1-week exercise will likely yield a well-designed visualization with risks and issues that are easily understandable to business users.  A 1-month exercise will yield even more details about the mechanics of almost every touchpoint and integration with a system – this is likely too much for immediate planning purposes.  However, for a large platform that you know needs to be replaced, a 1-month mapping exercise is likely necessary for planning how to make significant changes to a system. 

After visualizing and analyzing what the technology team has built over the years, it is unlikely that the CIO or any single person in the technology organization knows how people are really using a suite of tools to execute dozens or hundreds of processes.  To get a clearer picture of this, we recommend visualizing and analyzing processes.  This step is also critical to establishing proper ownership and accountability of tools and operational metrics and outcomes.
process map

One complaint we’ve frequently heard from CIOs is that business owners are not accountable for their processes.  When we speak to business owners, they do not feel empowered to own their processes for various reasons.  We believe many of these issues can be traced back to a lack of focus on operational key objectives (OKRs) and rigid technology governance processes that slow down the organization.  Whether these rigid governance processes are waterfall artifacts, get in line queues, or annual planning cycles, the time from requesting a change to seeing it in production is simply too long for business owners to see the linkage between what they want and what they get.

Similar to visualizing and analyzing systems, an organization could spend months visualizing and analyzing processes.  We also recommend time boxing this exercise.  For example, in 1-day determine which processes should be visualized and estimated.  This prioritization should be owned by a business side executive, not the CIO.  However, the CIO or staff can help identify and suggest processes that should be analyzed.  Mapping and analyzing the majority of processes for an ERP platform can take a significant amount of time, but it should also be time boxed to get it done as quickly as possible.

We do not recommend skipping the analysis of processes by business users.  This is typically the critical moment when business side leaders have the knowledge how to take back ownership of their processes to realistically achieve their OKRs.  Similar to the product owner in the digital product world, a business product owner is responsible for the combination of people and processes to meet key business metrics such as faster cycle times, fewer errors, etc. 

The outcome of mapping and analyzing systems and processes should identify the sources of technical debt and opportunities for short and long term investments.  These sources are typically:

- Labor and licensing on each component of technology
- Labor from business users in long cycle times and rework from errors
- Lost revenue opportunities due to long cycle times and poor customer experiences

Having a mix of short term investments will help introduce the right behaviors to prepare the organization for a much larger investment such as the rip and replacement of an ERP system.
OKR for IT

To learn more about how AKF Partners can help you pay down your technical and organizational debt, contact us at AFK Partners.

Next: Scalability Rules - Reduce Objects to Improve Website Performance (Rule 5)

Categories:

Most Popular: