The Courage to Explain Complexity
Why making local complexity visible is not complaining, but one of the most valuable contributions a regional leader can make to a global Oracle transformation.
Key takeaways
- Headquarters cannot plan around information it does not have. Global leaders should not be expected to understand every regulatory, operational and organizational constraint across dozens of countries.
- Regional leaders have an information advantage that global teams need. Their role is not limited to executing the rollout; they must make local realities visible before global assumptions become commitments.
- Explaining complexity is not resistance. When regional leaders translate local constraints into their implications for effort, cost, sequencing and risk, they improve the quality of global decisions.
- A readiness assessment can create value even when the conclusion is not to proceed. Discovering that a rollout should be postponed can be a better transformation outcome than executing against assumptions that were never realistic.
Regional teams often describe headquarters as disconnected from local reality during global Oracle ERP programs. They see corporate leaders underestimate implementation effort, question delivery estimates or express surprise when a country asks for additional resources or time, and the natural conclusion is that headquarters does not understand how the region operates.
After years of working on global Oracle transformations, I have come to see this tension somewhat differently. Headquarters make decisions with the information available to it, while much of the knowledge that could change those decisions resides elsewhere in the organization. Local tax regulations, electronic invoicing models, banking standards, statutory obligations and organizational constraints are generally well understood within the countries that deal with them every day, but they are not necessarily visible to the executives designing a global deployment strategy. The problem, therefore, is less a failure of understanding than a failure to move information across the organization early enough.
Every global plan begins with incomplete information.
A global transformation roadmap is ultimately a collection of assumptions about effort, sequencing, resources, dependencies and risk. Over time, those assumptions become budgets, timelines, deployment waves and executive commitments, even though many were initially developed with limited visibility into the environments where the global solution will eventually operate.
A subsidiary may appear straightforward from headquarters because it represents a small percentage of revenue or has relatively few Oracle users. From the region, the same subsidiary may look quite different because its regulatory environment introduces additional integrations, reporting obligations, external providers and demands on local teams. Neither perspective is inherently wrong; they are based on different information.
For regional leaders, the implication is important. Their role in a global transformation should not begin when the rollout reaches their country. By then, many of the decisions that determine what is possible have already been made.
Regional knowledge becomes valuable when headquarters can act on it.
I saw this particularly clearly during the planning of a global Oracle ERP implementation for a U.S.-based multinational. The Regional Controller responsible for Argentina, Brazil and Mexico recognized before implementation began that the global plan did not yet reflect two realities his region would eventually have to manage.
The first was organizational capacity. His finance teams were already fully occupied running the business, yet the implementation would require many of the same people to participate in design workshops, validate future-state processes, define regulatory requirements and support testing. The second was that implementation effort across Latin America would not necessarily correspond to the size of each subsidiary because regulatory complexity could make a relatively small operation considerably more demanding than its revenue or user population suggested.
Neither observation was particularly surprising once explained. The problem was that neither had been incorporated into the planning assumptions. Many regional leaders find themselves in a similar position: they can see where a global plan is likely to encounter friction, but knowing this and turning that knowledge into information headquarters can use are two different leadership tasks.
The challenge is not raising complexity but explaining its consequences.
Regional leaders can understandably hesitate to challenge a global plan before implementation has begun. In programs built around standardization, explaining why a country requires additional effort can easily be interpreted as protecting local practices or resisting the global model.
But complexity that is not discussed during planning does not disappear. It returns later as additional integrations, unavailable resources, delayed workshops, missed milestones or requests for additional budget. What could have been an input into planning becomes a delivery problem.
The Regional Controller handled this distinction particularly well. Rather than describing Brazil as exceptionally difficult, he explained where additional effort would come from, which regulatory requirements extended beyond Finance, which processes would be affected and what level of local participation would realistically be required. Headquarters now had assumptions it could test rather than opinions it had to judge, and the company agreed to perform a comprehensive readiness assessment before committing to the rollout sequence.
Better information changed the decision.
From headquarters, Brazil appeared to be a relatively small subsidiary that could naturally follow Argentina and Mexico. The readiness assessment produced a different picture. Local taxation affected accounting, inventory transactions, logistics processes and statutory reporting, while electronic invoicing introduced multiple external providers and integrations. Regulatory changes could also affect several business processes simultaneously and sometimes require adjustments close to go-live.
None of this complexity had been created by the project. It had always been part of operating in Brazil; what changed was the organization’s understanding of its implications for the Oracle implementation.
The eventual conclusion surprised some people outside the region. The issue was not whether Oracle could support Brazil; it could. The question was whether the business had reached a scale that justified the investment required to implement Oracle successfully within that regulatory environment. At that point, the economics did not support the rollout, and Brazil was removed from the roadmap.
A changed roadmap can be evidence of better planning.
It would be easy to describe that outcome as a planning failure because the original deployment sequence changed. I would argue that it demonstrated the value of the planning process. A readiness assessment should not exist merely to confirm a decision the organization has already made; its purpose is to improve that decision while changing it is still relatively inexpensive.
This principle applies to transformation governance more broadly. A roadmap should provide direction without becoming immune to new information. Organizations invest in assessments and governance precisely because some assumptions will prove incomplete. The discipline lies not in protecting the original plan, but in recognizing when the evidence is strong enough to change it.
Regional leadership is part of global decision-making.
What stayed with me from this experience was not ultimately the decision about Brazil, but the way the Regional Controller contributed to it. He did not position himself as the defender of the region against headquarters, nor did he assume that headquarters should somehow have anticipated everything he knew about the countries he managed. He recognized that different parts of the organization were bringing different information to the same decision.
Headquarters had the enterprise perspective required to allocate investment, establish global standards and determine priorities. The region understood the regulatory, operational and organizational conditions under which those decisions would have to be executed. A strong global program needs both perspectives before deployment assumptions become commitments.
Regional leaders, therefore, are not simply recipients of a global template, nor are they there to make a case for local exceptions. Their contribution is to improve the quality of global decisions by bringing information into the conversation that headquarters would otherwise have little reason to possess.
The bottom line.
When regional leaders explain local complexity, the objective should not be to prove that their country is different. It should be to help the organization understand whether that difference changes a decision.
Sometimes it will not. In other cases, it may materially affect effort, resources, sequencing, architecture or the economics of the rollout. Distinguishing between the two is far more valuable than either defending every local requirement or assuming that standardization will make complexity disappear.
The Regional Controller in this case did not make Brazil easier to implement. He did something more useful: he gave headquarters enough information to decide whether implementing it made sense at that point in time.
That is not resistance to a global transformation. It is one of the most valuable contributions regional leadership can make to it.
Cecilia Suarez
CEO at ITCROSS | Executive Advisor to CIOs & CFOs on Global Oracle Transformations | Strengthening Customer-Side Oracle Execution