Clarkston Consulting https://www.facebook.com/ClarkstonConsulting https://twitter.com/Clarkston_Inc https://www.linkedin.com/company/clarkston-consulting http://plus.google.com/112636148091952451172 https://www.youtube.com/user/ClarkstonInc
Skip to content

Managing Technical Debt in Retail

Contributors: Jenny McLean

Retail is an industry known for its fast pace and rapid transformations. With constant disruption there is pressure for companies to keep up and these goals often come with tight deadlines, forcing IT leaders to rely on quick fixes rather than long-term technological transformation. Additionally, the speed of technology change is increasing, and not keeping pace with the change can cause organizations to fall further and further behind competitors and customer expectations, which can hamper or even prevent business growth. Legacy systems can increase this burden. Retailers will enhance these outdated systems as it is a lower cost than to replace them outright. While this requires less immediate investment, this creates a build-up of technical debt that can decrease data quality, increase manual workarounds, and have greater operational costs.

What is Technical Debt?

Technical debt is the long-term cost of short-term decision-making with systems and technology. The simplest way to think about it is taking the easiest or lowest cost path now, rather than what is more sustainable in the long run. Technical debt can be very visible, in cases where it leads to gaps in needed business capabilities. You will recognize this when you hear the business say “I just don’t understand why we can’t do x. All of our competitors are doing it.”  Technical debt can also be somewhat hidden, stemming from the way systems are developed, configured, architected.

Technical debt also appears when you fail to upgrade systems regularly. For example, an ERP system implemented in 2001 following all best practices is likely the source of technical debt throughout the business today. While these large scale implementations can have a significant cost, they remove the constraints that debt puts on growth. Modern tools can cause similar problems if organizations do not update when vendors provide their new releases.
Further, technical debt can lead to data debt, which is an extension of technical workarounds into data impacting data quality caused by manual or flawed processes. Data debt can slow analytical or reporting projects by requiring analysts to combine multiple customers, vendor, or product lists from different systems or adding challenges understanding what specific fields mean. Additionally, data debt can stop some analytical projects when data isn’t stored at the right quality level, right granularity or isn’t captured at all.

What Causes Technical Debt?

These situations can be caused by many factors. Often the pressure by competitors to enable new functionality can lead to a patchwork of “band-aid” fixes, which depend on regular, manual interventions from people within IT or elsewhere. Additionally, attempting to minimize process changes can lead to shortcut solutions requiring IT development. While these are cheap in the immediate term, they are costly due to the manhours required to build and support them.

Technical debt can come out of a lack of investing in technology and keeping pace within the industry. While new systems have a large cost, they enable functionality and increase operational efficiency. Failing to devote resources to these efforts while your competitors do can negatively impact market share and incur a human cost as employees are required to fill the technology gap. Your data will also suffer. Manual workarounds can lower data quality and impede any analytical projects and the improved decision making promised by machine learning and advanced analytics.

Retail is no stranger to the impacts of technology and data debt. For many companies, their omnichannel transformation was impacted by these factors. When online retail first became an option , the fastest and easiest way for companies to leverage this channel was to stand up an entirely separate digital store. Separating inventory, merchandising, and pricing decisions to a new business unit whose job it was to just manage the web was a quicker way to get a webstore than to fully integrate it into existing systems. When firms attempted to unite their online and physical storefronts, this caused a series of technical, organizational, and data challenges where companies struggled to provide a single view of items, prices, and inventory. The ramifications for these decisions are often still felt today with challenges combining data for reporting and providing a single view of company performance.

Other examples of technical debt loads are seen across the organization. Departments that rely on a group of analysts to extract data from operational systems and generate standard reports daily or weekly are experiencing debt from not having a true reporting solution. They are incurring operational costs to support this work each week and can affect executive decision-making. Teams that rely on manually entering item data into multiple systems can incur data debt due to quality concerns. All these effects may not be felt in the immediate cost of these systems but can have significant financial and operational impacts over the long term.

How is it Remedied?

Much like financial debt, technical debt should be reviewed and taken on intentionally. Understanding the root cause and what debt looks like can help teams make better decisions as they prioritize projects and implement technical solutions, so they can be deliberate about the debt they take on. Unaddressed technical debt can have a brutal compounding effect, where small debts from a few years back can rapidly become debilitating. Bringing on additional resources can help address the symptoms and pay down the interest of the debt but does little to address the principal. Projects should be organized to address each source of debt within the organization. This does not mean that your organization must constantly replace systems that are causing the slightest amount of technical debt, but rather strategically identify when to make those investments in technology to mitigate long term costs of debt. Organizations who understand when to take on debt in some area and when to mitigate in others achieve a sustainable way to reduce the long term costs of technical debt.

For organizations that are already overburdened with technical debt, there are a few key strategies to help. Identifying and prioritizing indebted areas of the business and dedicating resources to rebuild smarter processes can alleviate the most significant impact of these issues. For some areas, companies can also see success in modernizing their data architecture and decoupling reporting systems from operational databases. This can reduce manual work and help optimize reporting and visualization for the business teams.

Not all custom code is a source of technical debt but leveraging out-of-the-box functionality, when possible, can often reduce long-term technical debt. Generally, software vendors design their solutions to account for future changes and thus minimize technical debt. They also provide enhancements as new capabilities are introduced. However, if customizations are the only way to get what is needed out of the system, following best practices and proper design for scale can reduce long term debt as well.

Technical debt can be seen as an insurmountable challenge but have real financial impacts that organizations cannot ignore. Educating technical and business teams on how to identify debt can be a crucial first step in starting to more actively manage any future or current debt.  Efforts must be made to prioritize and resolve any indebted processes so organizations can continue to grow and achieve their goals.

Subscribe to Clarkston's Insights

  • I'm interested in...
  • Clarkston Consulting requests your information to share our research and content with you.

    You may unsubscribe from these communications at any time.

  • This field is for validation purposes and should be left unchanged.
Tags: Retail Planning and Execution, Retail