Developed by:
Jim Buttjer, American Digital Sr. SAP Account Executive, Michael “MJ” Johnson- Director of SAP Solutions
Part Two: How Does Technical Debt Affect Your Business?
Technical debt sounds pretty bad, right? Now let’s look at some of the ways it affects your business. Technical debt can prevent standard and otherwise viable solutions from being adopted, causing you to spend time, money, and risk investigating and trying to develop alternate solutions.
Consider one example customer, an organization that wants to implement Production Material Requests (PMRs) with the implementation of their new SAP Extended Warehouse Management (EWM). This is a newer solution that hit the market in just the past several years, replacing and extending the previous Warehouse Management functionality in SAP ECC. (Technical note: Depending on the landscape and deployment strategy, EWM in this example could be installed as an add-on in ECC or as a separate system sitting on top of HANA.)
Because the ECC system EWM interfaces closely with ECC, they simply could not implement PMRs. This is because ECC was severely outdated in both Support Package Stacks and Enhancement Packages—five years beyond the date on which their last Support Packages were applied with a major implementation project. Worse, the business did not plan to apply any maintenance until they upgraded to S/4HANA in a few years. Therefore, after months of design, delays, and back and forth with SAP about alternatives to getting closer to current software levels, they would need to change their processes and solution design to use the outdated inbound deliveries. It would take more steps, deliver less functionality, and force changes to other custom development objects. Accordingly, delays in capital projects caused by technical debt often, in turn, cost more in time and money while increasing risk and forcing disappointing compromise on functionality and quality.
Technical debt can grow in time depending on the form. With a straightforward debt, you can simply pay it back, much like borrowing $10 for lunch from your friend because you forgot your wallet. Pay the $10 back tomorrow or in a reasonable time and the debt is taken care of—no interest, no problem. Or, that debt can progressively accumulate complexity, risk, and cost, wiping it out the longer it goes unpaid. Let’s take a look at the most common ways technical debt can grow.
Lack of minor and major maintenance.
- Minor maintenance grows quarterly with every missed SAP Support Package Stack and software patch for third party applications, databases, operating systems, and all infrastructure. Did you find an SAP note contained in a higher Support Package but weren’t able to upgrade anytime soon—needing SAP to “downport” the note for your level? Chances are as long as you’re within two to three Support Packages of the current version, SAP will often accommodate your need. On the other hand, if you’re four or five years and 10-20 Support Packages behind, forget it. They’ll tell you to upgrade first, apply the notes they recommended, and then get back to them if you still have a problem.
- Major maintenance grows when you don’t upgrade major versions, especially once your business gets two major releases behind. Getting two releases behind can either complicate your upgrade path or, in certain areas, eliminate a direct upgrade path, causing you to either re-implement the solution or get expensive SAP consulting and development involved.
Custom modifications and WRICEFs.
(Technical note: WRICEF is an acronym in the SAP world representing the various types of development objects found in an SAP system usually because it can’t be done through configuration alone. It stands for: Workflows, Reports [SAP’s generic name for any program and read-only reports], Interfaces, Conversions, Enhancements, and Forms.) Every time your team decides that the standard SAP functionality between WRICEFs and configuration won’t quite give them what they need, they have to decide if they need to create custom WRICEFs or even modify SAP standard objects. To be clear, there’s nothing inherently wrong with delivering what the organization needs. Rather, it’s the due diligence that’s valuable, or the ability to consistently evaluate if a need can be met effectively using SAP-delivered solution components as opposed to being taken on the responsibility of owning all of those parts of your solution puzzle going forward. By choosing custom objects, your organization becomes responsible for reconciling that inventory of modifications and custom objects every time SAP comes out with point fixes, Support Package maintenance, new functionality, and available enhancements along with major upgrades. In several extreme cases, I’ve seen customers that were considering a major upgrade but were blocked by the task of reviewing literally 10,000 to 20,000 WRICEFs accumulated through the years. They asked the expensive but cost- and value-relevant question: “Even if we could complete this review before the upgrade, it would likely take close to a year, maybe two, and most of the people who developed them would be long gone—and of course our documentation is out of date. Should we just start over with a new implementation and take the data from the old system? It might be the right move and very expensive like the original implementation. But I just don’t see a good option here.”
Lack of innovation.
A customer service agent at one cellular provider lamented one day that they have on average of 11 to 13 screens open on different websites and applications just to handle the average call. Their process is extremely compartmentalized, and systems are not integrated. Worse, to compensate for billing errors, slow systems, and slow customer service, some of their agents are trained to handle escalations and given a daily budget in the thousands to fix issues for angry customers. Because their agents are spending more time and money per call, they need more agents to keep up with call volume. When companies aren’t innovating, it’s easy to overlook issues and postpone resolving technical debt, thereby allowing it to linger, fester, and grow in a way you may not anticipate.
Continuous improvement.
A company implemented SAP for the first time, eventually rolling out the new sales order process using the traditional SAPGUI transactions. However, they failed to acknowledge the efficiency with which their inside sales team was able to, in a matter of a few minutes, handle a customer call, answer questions, lookup information, and enter an accurate sales order in the old system. Now, in many cases, the sales reps would either have to keep the customer on the phone for 10 to 15 minutes (instead of ~4 to 5 minutes) while they looked up and entered information before they could be certain the sales order was complete. The sales reps understandably wanted to keep their longstanding customers happy and saw the result that poorly designed and performing systems had on their customers’ disposition and their ability to continue providing “one quick call and done” customer service. So they would tell a customer that they would take their question or purchase requests, complete their work offline, and call them back in 15 to 20 minutes.
This lack of ability to sense and respond to an issue in testing or even with a continuous improvement initiative after go-live resulted quickly in the following costly outcomes:
- Customers deferred purchases;
- Customers ordered less because upselling and cross-selling opportunities decreased with longer call times and worsening mood; and,
- All of this combined changed the work focus of sales reps, who were now conducting many more outbound calls, sometimes getting the right person but sometimes not, instead of being able to take care of everything on the first call—the way it used to be. A significant amount of time shifted from handling mostly inbound calls from happy customers to now making many more outbound calls, increasing their response time for inbound calls and reducing capacity. For a while, this issue lowered their customer service and sales metrics considerably.
Also, if you’re interested in learning more about this topic and being part of a virtual roundtable discussion, please join us July 29th at 10:00am cst. for our Technical Debt webinar.
Register Here
All attendees will be entered to win one of three Keurig Drinkworks Beverages Makers- a $349 value. Check out this artisanal beverage maker here