top of page
Search

How much risk are your systems hiding?

Writer: Chris Gracie
Chris Gracie
1 day ago
5 min read

There might be a system in your business that makes you nervous.


You know the one. Is it your ERP system, CRM, payroll platform, operational database, or some bespoke piece of software that started life doing one job and somehow ended up becoming critical to the business.


There are spreadsheets and manual workarounds around it. Getting reliable information takes more effort than it should. A few people or suppliers hold a lot of the knowledge. Changes that should be relatively straightforward have become complicated.


Everyone knows something probably needs to be done eventually, but there’s never quite enough reason to do something about it today. Systems don't have to be broken to be risky.

In fact, some of the technology risk we see sits inside systems that continue to work perfectly well. The business has simply become very good at compensating for their limitations.


That's why we've built the Pro Partner Technology Risk Check. It's a quick assessment designed to help you step back from a critical business system and look at the risk sitting underneath it.


It takes around 90 seconds and looks beyond whether the technology simply works. It considers how dependent your business is on it, whether it can support where you're heading, how easily you can get reliable information, how complex it is to change, where knowledge sits, and how much manual effort is happening around it.


If you've already got a system in mind, try it now.


What's the risk profile of your critical business systems?



What can 90 seconds really tell you? We put a real business system through the assessment to see what it would uncover.


Technology risk snapshot executive report
Technology risk snapshot executive report

We put a real system through the assessment


We've called the system CoreFlow. That's not its real name, and we've changed identifying details about the organisation. What is real is the situation behind it.

CoreFlow was the core business system for a New Zealand product supply company operating across multiple locations. Around 80% of the organisation's revenue, approximately $25 million a year, depended on business activity supported by the system. Like many mature enterprise platforms, CoreFlow had become deeply embedded in how the organisation operated. It wasn't just an accounting or back-office system. It sat at the centre of how products were ordered, sold, managed and moved through the business.


If CoreFlow became unavailable tomorrow, the impact would be Critical. Website orders would be affected. In-store purchases would be affected. Stock couldn't be ordered normally. Warehouse management would be disrupted. Staff would lose access to systems they relied on to run day-to-day operations. And there wasn't a meaningful workaround that could simply take over. For their customers customers, that could mean difficulty ordering or receiving products. For staff, it could mean losing the tools needed to process sales, manage inventory and keep the operation moving.


Everything flowed through CoreFlow.

That's an important point, because we have not judged that CoreFlow is a bad system.

We've established that The business is highly dependent on it. now that we know that context, understand that dependency, all the smaller issues around the system start to matter much more.


There were concerns about whether CoreFlow could continue to support where the organisation wanted to go next. Reliable information existed, but getting it into a useful form often took effort. Data needed to be gathered, cleaned or reconciled before it could confidently support decisions.


Change was difficult too. CoreFlow had become connected to other systems, integrations and suppliers. Something that sounded like a relatively straightforward change could have implications somewhere else in the environment.


Probably more importantly, knowledge of how everything fitted together was concentrated among a small number of people and suppliers. The Risk Snapshot rated People and supplier dependency as High.


Then there were the workarounds.

Spreadsheets, re-keying, reconciliation and manual processes had gradually become part of making the system work for the business.



There wasn't a single enormous technology problem where everyone could point and say:

"That's it. CoreFlow has to go." Instead, there were a collection of fairly ordinary problems that had accumulated over time.


If getting information was difficult, someone manipulated it outside the system. If two processes didn't quite connect, someone created a workaround. If making a change was complicated, perhaps that change was deferred. If only a few people understood something, those people became the ones everyone called. The organisation adapted.

The system continued to work because people made it work. And that's often where technology risk hides.


What happens when you put all of that together?

CoreFlow's overall result was High Technology Risk Exposure. Made up of:

  • Business alignment was Moderate.

  • Information and insight was Moderate.

  • Complexity and integration was Moderate.

  • Manual work and data was Moderate.

  • But people and supplier dependency was High.

  • More importantly, all of those risks for a system a system where the business impact of it becoming unavailable was Critical.


That's a very different conversation from "CoreFlow is getting old, but it still works."


CoreFlow business impact rated Critical
CoreFlow business impact rated Critical

We're now able to confidently say that:

"Around 80% of our revenue depends on activity supported by this system. The impact of losing it is Critical. We're highly dependent on a small number of people and suppliers, and there are further exposures around complexity, information, manual effort and future fit."

That's something a leadership team can have a meaningful conversation about.


Estimating cost of doing nothing (status quo)

The Technolgoy Risk Assessment also produced an indicative annual Cost of Inaction of $35,000 to $70,000. Importantly, that isn't an estimate of what an outage could cost the organisation. If $25 million of annual business activity is supported by CoreFlow, it would be tempting to create a big theoretical outage number. We deliberately don't do that.


The $35,000 to $70,000 relates specifically to the manual effort and workarounds identified in the assessment. In the Risk Snapshot, regular manual effort is modelled as approximately 0.25 to 0.5 FTE, using a loaded annual FTE cost of $140,000.


That makes the calculation transparent:

0.25 to 0.5 FTE × $140,000 = $35,000 to $70,000 per year.

It's indicative, not a forecast. But it helps frame the conversation. Previously, IT managers were having conversation with exectives like "We have a few spreadsheets and manual processes" sounds relatively harmless. Now they are able to say:


"We may be consuming the equivalent of a quarter to half a person's time every year compensating for limitations in a critical system" is something worth investigating.

And even then, the assessment doesn't say replace CoreFlow.


The recommended next step is much more sensible: validate and prioritise the exposure.

Confirm the actual business impact. Validate the manual effort. Understand the critical dependencies. Decide which risks you're comfortable accepting and which need to be reduced. Then you can begin having strategic conversations abour options to reduce risk. That's the conversation the assessment is designed to create.


What's the risk profile of your critical business systems?




 
 
bottom of page