In December 1815, just before Christmas, the city of Sydney celebrated the British victory over Napoleon. The Battle of Waterloo happened in June, and it took 6 months for the news to reach Australia.
Today, the connection between Germany and Australia is instant, yet we still function in different realities. For example, the overlap of our business hours is only 2 hours during European summer and none during wintertime, even worse for New Zealand. It’s just one of many pitfalls to consider.
Global corporations today are driven by both: individual success measures and pursuit of efficiency in general – including rationalized IT landscape (as per my other blog about DevOps for Digital Transformation), ERP systems and Zero Trust principles.
But there are drawbacks. Some are quantifiable, for example the Australian legislation to measure us against our local cybersecurity responsibilities, see the Critical Infrastructure Protection Act and the Essential 8.
Some other are harder to capture. But in the pursuit of global integration, the enterprise-class decision-makers tend to forget or ignore the specific needs of local subsidiaries, what may cause some drawbacks. How to communicate our needs and help our Head Offices over-seas to understand them?
In this article, we aim to help with voicing these unquantifiable drawbacks to our head offices and propose simple questions to measure their impact on our bottom lines.
Priorities
When planning for a global rollout, the first step is to gather individual requirements and then to juggle conflicting priorities. Some are of great business significance to our subsidiaries and we worry they may be misunderstood or deprioritized by our IT teams.
The line of consent could be established by reviewing some of the following:
- Why are we voicing our concerns so loudly?
- What is the cost to our local bottom lines?
- How did we resolve these types of issues in the past?
- In terms of our „best people”, what would it cost to replace them?
- How do our priorities compare to global priorities?
- Can they be removed from the global list?
- If removed, can we accommodate for them locally on our own?
Perspective
This is about how we, as humans, perceive problems and resolve them. In a geographically dispersed environment, there is always something happening “here” and “there” and appreciation of context or priorities may be difficult. Making a decision not always involves everyone, especially if they are not in the same room.
Unfortunately, it is hard for someone from the Australian subsidiary to be present in such a meeting due to geography or the time zone difference.
Here are some of the points for our head offices to consider:
- How will you accommodate for our urgent priorities, if a resolution needs to come from another geography?
- How would you decide on priorities, if we were not present in that meeting?
- Are there any simpler ways that allow us to resolve our own urgencies without raising alarms in the first place?
Communication
We already mentioned how time difference cause disruption to our availabilities, but the language barrier is another. Those limitations may affect our planning, implementation and ongoing support.
The considerations to resolve include:
- How many project team meetings can we accommodate for within that short window of business hours?
- Who within our organisations needs to be available after hours in each affected location?
- Which suppliers need to remain available after hours? What is the additional cost?
- How many in-depth conversations can we sustain via a video call alone?
- How successful were we in conveying our messages in the past?
- What are the alternative ways to resolve these communication pitfalls?
Latency
The problem refers to the time it takes for data to pass from one place to another. Not a major consideration for connections within the same continent or even between Europe and Asia or North America – but a problem to connect Europe with Australia.
Every day we encounter European companies replacing local deployments of their business-critical application with a single tenant hosted in Europe.
But it will not work. The commonly accepted maximum latency for ERP systems is 150 mb/s.[1]
A lot of head offices prioritized it out though as one of many obstacles to be resolved at a later stage. Yet it is important right at the beginning, though.
The questions to explore are:
- Can you settle for seconds and minutes of delay in your system performance?
- Would that delay affect your customer satisfaction?
- Would that affect your employee satisfaction?
- What are the alternative ways to resolve that locally?
Accountability
Modern software implementation may lead to the deterioration of personal accountabilities, commonly measured using our corporate KPI (Key Performance Indicators).
For our “best people”, accountability means more, they continuously look for ways to improve and adapt to the local market conditions quicker.
When positioning global IT initiatives, we usually promise to remove the burden of managing this locally. But really, is it possible to decouple our IT operations from business performance, information accessibility, security, problem resolution times or even our abilities to adapt to market changes quicker?
It could be worth reviewing the following questions:
- How are the „best people” KPIs defined? Why?
- How are these KPIs affected by removing IT or business process automation accountabilities?
- Can the „best people” be replaced by someone else who is backed by business process automation from the head office? How will that affect head office KPIs?
- How should „best people” KPIs be adjusted after these accountabilities are removed?
- Can you set up operational KPIs in Australia from the head office while ensuring financial KPIs?
- In the past, how much time did it take to recruit and onboard your „best people”?
- How would your competition respond locally to your local KPIs being managed remotely from the head office?
Support
Ideally, our support is in-house, appreciating our unique requirements without repeatedly explaining our ourselves via a hotline. Today, it’s rarely sustainable.
Outsourcing means that we compromise, settling for non-dedicated teams, with tiered access to specialists, in multiple time zones, with ZERO TRUST policies to continuously authenticate us.
When insourcing our support, we expect more flexibility to standardize, apply our own security measures and contain our costs globally. Locally we would expect for our resolution times to improve. Unfortunately, while 1st line support is ours, we still need to accommodate for the “Shared responsibility”. Let’s unpack it:
Today, modern solutions are built (outsourced or insourced), using a multitude of solution blocks that together form a functioning ecosystem.
Responsibility for each block is assumed by a different party in the background, for example SAP, Microsoft, Atlassian, responsible for uptime, performance, patching, monitoring, compliance, data governance, and 3rd line support.
Shared Responsibility means that if a party that supports our solution does not have relevant access to a specific building block, they are not responsible for that block.
Then, a number of other responsibilities are assumed by a 2nd line support, including, customizations, integrations, data management and user access.
Therefore, our global support team (potentially based in Europe or Asia) has a key role to diagnose our issue, identify who is responsible, report our problem, wait for a fix, test it, apply it, document it and report. More complex scenarios require multiple teams to standby, usually in different time zones, to address a problem or implement a change, just to wait for another party to accommodate for their block.
Let’s suppose our new support structure works fine. In Australia and New Zealand, we are still prone to delayed resolution times, due to limitations caused by physical availability of key personnel in different time zones, different priorities in locations, diluted accountability matrix of our best people, communication challenges and limits of our ticketing systems.
But there is more, see the emerging trend for Zero Trust, also enforced by Australian authorities, as mentioned earlier. Zero Trust comes with three overarching principles that will slow things down: Verify Explicitly, Use Least-Privilege Access, Assume Brach.
The additional considerations for Australian support also include:
- What technical access level is required during Australian business hours to diagnose and troubleshoot a problem?
- Who in our time zone has administrative access and approval privileges?
- Do they need to coordinate with another group in a different time zone?
- How much time is required to provide progress reports on the troubleshooting process?
- What are the head office’s criteria for empowering local subsidiaries to troubleshoot their own support issues?
Summary
While global rollout initiatives hold great promise, they may cause some drawbacks that affect Australian subsidiaries in particular.
We discussed the risk of discouraging our „best people”, by depriving them from decision powers to keep things efficient, offering a support structure instead that may be slower and resource intensive.
We mentioned how the geographical distance between Europe and Australia leads to natural performance issues due to latency.
Ultimately, it boils down to the importance of local perspective, local accountability, and local solutions in achieving local business goals in line with global strategies for support, risk mitigation, and budgets.
The trick to quantifying these drawbacks? Establish healthy communications and evaluate the right questions.
[1] Check your own latency for Australia and New Zealand here for Azure and AWS.
