We’ve all been there: the dreadful unplanned and unexpected SAP downtime. Unplanned downtime comes with stress, pain, and usually a hefty cost; ranging from thousands of dollars to over a million per hour (a true case study from an Avantra customer). These costs typically stem from wait time as employees are helpless until the systems come back up, products not leaving the door, logistics come to a halt, and the list goes on. But these calculations usually miss the hidden costs that come with downtime - the indirect costs that are hard to calculate but have a severe business impact.
Partner, vendor, customer, or third party satisfaction
Modern-day SAP systems are heavily integrated with other environments. Be it SAP or non-SAP environments, these integrations to another partner, vendor, b2b customers, and/or third parties are critical. When we start to calculate the cost of downtime, we often forget that these partners and vendors are reliant on these systems as well. While third parties may not experience any financial costs, downtime to them can slow them down, give them a false representation of information, which in turn causes a domino effect to their other vendors and partners and overall cause overwhelming frustration. Partnerships, vendor, and customer relations can become severely tense.
Furthermore, consider direct to consumer customers in today’s customer-focused online shopping world. If consumers are unable to order their product or service within a couple of easy steps, they’re off to a competitor. Consider the amount of time and effort that goes into developing an ‘ease of use’ ordering platform from a UI/UX perspective where the amount of clicks a consumer goes through to purchase is heavily scrutinized. That all becomes 100% irrelevant when the backend system isn’t even up and running (even for 5 minutes) and consumers are flocking to competitors. This is especially true in hybris billing (formerly BRIM) environments where every single minute is crucial to new members signing up for services.
The funny thing about downtime is that it’s never convenient. It never seems to occur mid-day on a slow afternoon with plenty of free time. No, it happens at 2:00 am on a Saturday morning, 30 minutes before you have to wake up to catch an early morning 9 hour, no internet provided, flight to your daughter’s Hawaiian beach wedding. And here’s the thing, when unplanned downtime occurs in an SAP environment, it’s not always a straightforward issue. Oftentimes the first few hours are spent researching what happened, and it’s not just one person or one department that's affected. Because SAP is so crucial to the lifeblood of an entire organization, unplanned downtime usually calls upon any IT department that may have some ‘touch’ into that system, whether it’s the Basis team, the functional team, the networking team, the storage team. And of course, that means everyone is getting woken up at 2:00 am on that Saturday morning.
For some of us, the inconvenient downtime initially comes as a shot of adrenaline, a rush to put on our detective hats and become a superhero. But as the system comes back online and the postpartum report is being worked on, that adrenaline rush dies down and people start to consider the aftermath. What does this mean for me in the future? Will I be held responsible? Will I lose my job? This becomes increasingly stressful in environments where unplanned downtime becomes a frequent occurrence, nobody can explain what exactly is occurring and there is no clear path forward on how to avoid downtime happening again in the future.
On top of all of this, we need to back-track and reconsider what is actually happening in the ‘war room’ during the outage where it’s all hands on deck. Every IT department is represented by at least one technical team member and a representative of their leadership team. This often means people don’t want to be called out and finger-pointing begins with teams deflecting any blame and then passing that blame onto another team, often with little evidence to go on. It’s sad to see as everyone is just trying to get the system up and running, but in the case of an unknown resolution, nobody wants to be held responsible. Next thing we know, we are further digging into our team silos, pushing back against other team silos and the team divisions grow.
Overall, when unplanned downtime occurs, it usually means everyone stopping what they are currently doing and all hands on deck. This happening just once a year can really start to frustrate employees. Furthermore, creating divisions and self-conscious employees that often comes with downtime just adds to that frustration. Nobody wants to be in an organization where they are not respected by others in their organization, they’re constantly being pulled away from home or work tasks and they don’t know if an outage will cost them their job. This can lead to unhappy employees and even employee churn, which has its own massive set of costs associated with it.
In general, it’s important to take into account not only the easy to recognize costs, but also the indirect costs associated with customers, vendors, partners, and even employees. These costs are not always easily identifiable and don’t present themselves immediately around the timeframe of the unplanned outage, but become very, very crucial in ongoing dollars to the business.
Safe and Transparent Starting and Stopping of SAP Systems
“Never change a running system, even if it's slow,” was the joke when I was a SAP Basis...
It’s all about the preparation - Automated preparation!
Recently I joined a team to run a ‘Ragnar’. A ‘Ragnar’ is a running race where you and an...
Israel’s Largest Food Company Improves SAP performance Monitoring Reliability and Employee Productivity
With a portfolio of five multinational companies, Strauss Group is the largest food distributor in...