On the journey to successful digital business transformation, we simplify technical complexity to reduce technical debt. That complexity creates a vicious cycle that needs to be addressed. If they do not address the need for simplifying and modernizing, many digital initiatives can falter, or even fail.
Introducing customization, development, and complexity leads to the need for more customization, development, and complexity. In other words, you create a vicious cycle. As solutions or fixes age, and as their complexity increases, organizations incur the technical debt of the initial investment, along with the long-term maintenance debt of supporting and working around this debt. This creates a compounding scenario, much like compound interest, where the mountain of debt continues to grow until it reaches an unsustainable tipping point.
Like constantly borrowing money until you can no longer pay back even the interest on the debt, and still sinking further, technical debt may lead to a similar scenario. Don’t wait until you reach the tipping point to address technical debt. The urgency of the situation may lead to dramatically higher costs than you are prepared for.
Indications You May Be Reaching the Tipping Point
- Is IT too slow to respond to business needs?
- Do enhancements take too long?
- Is support costly and incrementally increasing?
- Do you face a backlog of changes or functionality requests?
- Is it hard to find resources to understand the existing customized environment?
- Do you struggle to work around customized functionality to deploy standard solutions?
- Is the SAP support staff no longer familiar with standard SAP solutions and options?
Adding to this problem, workers accustomed to aging hardware and software platforms generally accept them. Then, newer employees, who are used to the digital age with mobile technology and user interfaces focused on ease of use, find the old technology cumbersome. This all creates change obstacles for doing things differently.
Technical Debt and Personnel Management
This issue brings us to another major obstacle: In many organizations with highly customized systems, individuals and small groups have established their entire careers on building and feeding customizations. They may perceive removing that technical debt as a direct threat to them and their job stability. In other words, the change resistance and people issues often slow, or in some cases prevent, needed changes– even before making the transition to Digital Business. Is it any wonder so many “Digital” initiatives struggle or fail to achieve desired outcomes?
Outside talent has its place in defining how to move back to standard and what standard options and capabilities are, but internal resources with institutionalized knowledge know and manage the significant customization. They are often the individuals who created the customization in the first place.
Software Engineering or Business Process Engineering
No matter which route you choose, you should have clear business justifications for software engineering. In other words, do you have specific processes that are part of your core value proposition or create significant competitive advantage in the marketplace? If your processes are that unique to your business model, are there other ways to achieve the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.
The closer you stay to the “out-of-the-box” goalpost, the less expensive the entire application lifecycle will be:
- The initial implementation will be less expensive.
- Ongoing support and maintenance will be less expensive.
- Upgrades will be less expensive.
- You will have fewer issues and bugs to resolve.
- Issues, bugs, and regulatory changes are more likely supported through your maintenance agreement.
If some unique process areas directly impact your industry or market position, then you might want to consider customization. However, in less unique areas such as purchasing, or accounting, or inventory management, you should try to stay close to the standard functionality. Sticking close to the standard system functionality may require change management, but it will be far more cost effective and less troublesome throughout the entire application lifecycle. With very few exceptions, you should be suspicious of the consultants who frequently seem to need something custom coded.
No matter which goalpost your implementation is closest to (“out-of-the-box” standard or “make it fit our business”), you should always have a direct, business-related justification for customizations. Usually, this is not the case. The most common reason I hear on projects is “this is the way we’ve always done it.”
A popular slogan states that “every company is now a software company.” You should remember that software companies have to create software with real value. By the same measure, your software efforts must bring real value and not just marginal returns. Small efficiency gains, or tweaks to satisfy a constituent group, carry short- and long-term technical debt.
