A summary of the initial discovery phase findings. Prepared by Opposite to support Indara's High Level Design and Capital Approval Committee submissions in August 2026.
Indara operates approximately 4,500 sites across Australia. The operating model has grown over time through mergers and organic expansion, resulting in overlapping systems, inconsistent processes, and data held across multiple platforms without agreed ownership. Site360 is the programme Indara has established to address this.
Its purpose is to create a single, trusted data and process foundation across the business, one that supports operational efficiency, commercial growth, and improved service to operators and landlords.
This report consolidates Opposite's desktop review, the interview findings, and the leadership workshop into a single reference. Prepared by Opposite to support Indara's High Level Design and Capital Approval Committee submissions in August 2026.
Between January and May 2026, Indara ran eight discovery weeks and fifteen workshop days across Build, Property, Operations Delivery, Engineering, Finance, Site Management Centre, IT, Lease Admin, and Maintenance. Seven process streams were mapped. More than 150 pain points and improvement opportunities were documented.
This report consolidates what was learned through Opposite's desktop review of project artefacts, the interviews held with the project team and subject-matter experts, and the leadership workshop conducted across the first half of 2026. It provides the input to the next phase of the project.
All three sources — the desktop review, the interviews, and the workshop — identify the same underlying patterns. These are characteristics of how the business currently operates, not problems attributable to any individual team.
Process is mapped at an operational level. A strategic, future-state process design is the work of the next phase.
No master data domain has a documented owner. Eleven or more platforms hold overlapping data without agreed authority. Remediation has not yet begun.
Future roles, accountabilities, and decision rights have not yet been defined. The capability to mature processes and move towards automation remains to be mapped.
Two organisations have come together with different ways of working. The behaviour change the transformation requires has not yet been designed.
The need has been identified. The structure, decision rights, and accountability arrangements that will hold the other four pillars together remain to be defined.
The programme needs one sentence every leader can repeat:
Site360 will give Indara a single, trusted data and process foundation — owned by the people who use it — so that people can spend their time on the work that matters, not the work that just recurs.
Before the High-Level Design locks in, the ELT must confirm three things:
Which system is authoritative for each master data domain — the consolidate-versus-integrate decision.
Who owns each domain — a named person, not a team.
What the governance structure looks like — the decision rights and accountability arrangements that hold the Five Pillars together.
This report gives Indara the structured view of the discovery work it needs to enter the High-Level Design phase. Part II documents the findings across process, data, systems, and leadership. Part III synthesises those findings into a Five Pillars maturity analysis built on six cross-business patterns, and a set of recommendations across strategy, design, resourcing, capability, and timeline. The executive summary above is a compressed version of that chain.
Why this report exists, what Site360 is set up to do, and the work Opposite is delivering into it.
This report consolidates Opposite's desktop review, interviews, and leadership workshop from the first half of 2026 into a single, structured view of the discovery work and the decisions the next phase needs to make.
This report consolidates Opposite's desktop review, the interview findings, and the leadership workshop into a single reference. It maps every finding to an asset lifecycle, the business units, and Five 'Pillars' of Change, and names the gaps the next phase must close.
Site360 is Indara's enterprise-wide initiative to establish a single, trusted data and process foundation across the business.
The purpose of Site360 is being refined through this report and ongoing discussions. It may take the form of a transformation and culture programme, a data quality and reliability project, or a combination of both.
Indara operates approximately 4,500 sites across Australia. The operating model has grown over time through mergers and organic expansion, resulting in overlapping systems, inconsistent processes, and data held across multiple platforms without agreed ownership. Site360 is the programme Indara has established to address this. Its purpose is to create a single, trusted data and process foundation across the business, one that supports operational efficiency, commercial growth, and improved service to operators and landlords.
Across the discovery work, the same pattern recurs: value-bearing work happens outside the system of record. Eleven or more systems hold overlapping data and several master data domains have no documented owner.
The business is positioning for automation, growth, and new revenue. There is a need to address these issues to ensure the business is set up for ongoing success. Therefore, the project is seen as an essential business enabler, if done right.
We have organised the potential change of Site360 across five categories. Four describe distinct areas of change: Process, Data and Systems, People and Capability, and Culture. Governance sits across all four, holding the structure, decision rights, and accountability that keep them coordinated. Findings throughout this report are mapped against these Five Pillars. A full maturity assessment appears in Section 3.1.
Four pillars of change, held together by Governance spanning across them.
Standard ways of working across teams, sites and operators, defined at a strategic as well as an operational level
A single trusted source of truth, with named owners, quality metrics and the systems landscape that supports it
Clear roles, accountabilities and decision rights, and the capability to mature process and automation over time
Defined behaviour change across two merged organisations and an inherited culture weary from change, delivered through the project
The framework of ownership, decision rights and oversight that sits across Process, Data and Systems, People and Capability, and Culture, defining how the other four are coordinated, resourced, and held accountable.
The Site360 programme has two phases: a High-Level Design phase concluding with the CAC submission in August 2026, and a phased deployment across FY27 and FY28.
Discovery workshops by Indara. Desktop review, interviews and workshop by Opposite
Validation of the findings, design of the future operating model, master data ownership decisions, and the build of the High Level Design documentation.
High Level Design complete and Capital Approval Committee submission for the deployment investment case.
Deployment is phased by related data sets and functions, supported by the change, capability, and culture programme.
The core analytical body. Business processes mapped to the lifecycle and the business units, master data domains, systems, and the voice of the leadership team gathered through the desktop review, interviews, and workshop.
The findings derived from the Site360 workshops were analysed and Opposite organised 150 of these findings around the asset and customer lifecycles, mapped against the nine business units that operate along them. By doing this, Opposite proposes that all future work anchors priority improvements and reporting at this strategic level so it is clear how incremental process and data improvements are in service of the core business and customer-facing processes of Indara.
Opposite's review has defined the customer lifecycle and the asset lifecycle, and the points at which they interface. The customer lifecycle (what an operator experiences) runs in parallel with the asset lifecycle (what Indara's internal teams do). Organising the programme around this model keeps the customer at the centre of every engagement. Note: this lifecycle will be further adapted and updated as the project progresses.
The customer lifecycle and the asset lifecycle run in parallel, meeting at defined touchpoints.
The 'cube' maps the eight lifecycle stages against the nine business units. Each cell shows whether the unit is a Primary owner (P), a Contributor (C), or not involved. Amber markers count workshop-evidenced findings clustered in that cell. Select a business unit across the top to focus the cube, and click any cell with findings to open the related detail.
Every handover on email is a moment where data falls between teams.
The amber clusters show where coordinated change is most needed. Operate (Site Management Centre), Activate (Finance, Build), and Maintain (Maintenance) carry the heaviest concentrations.
The focus of findings is concentrated where work and data change hands between teams, not within any single function.
Operate, Activate, and Maintain carry the heaviest concentrations — the stages where work passes between the most teams. There is a tendency for workshop findings to focus on the busiest pain points, which might overlook earlier lead processes that contribute to downstream problems.
No stage is delivered by one unit alone. Each contributor holds its own version of the information it needs, so the same site is described differently depending on who is asked.
Primary ownership changes hands at almost every stage boundary. Without defined handover gates and decision rights, accountability fragments exactly where the findings concentrate.
Operate and Activate are the stages operators and landlords experience directly. The internal coordination gaps the cube exposes are visible externally — reinforcing the case for one consistent way of working.
A master data domain is a category of business information that multiple systems and teams must hold consistently. Examples include what constitutes a Site, what defines a Lease, and who qualifies as a Landlord. Opposite's review identified six such domains across Indara. None has a documented owner.
Many versions become one trusted record — with a named owner accountable for it.
The tower or rooftop itself. The Site holds its unique identifier (BUN), address, type, current status, and lifecycle stage. Every other domain attaches to it.
Indara's passive infrastructure (the structure itself, Anchor Work Loops, anti-climb devices, fall arrest systems, generators) and the customers' active equipment installed on top of it (panels, antennas, RRUs). The Asset Management discovery work agreed a two-layer model: Layer 1 for the passive assets, Layer 2 for tenant equipment.
The agreements that give Indara the right to occupy land (Lease, with a landlord) and that give an operator the right to occupy a tower (Licence, with a customer). The same data shape applies to both: parties, terms, dates, escalators, payments.
The parties on the other side of those agreements. A landlord is the owner of land that Indara leases. A customer is the operator (such as Optus, Telstra, or TPG) that licences space on Indara's tower.
The third parties Indara contracts to do work on its sites: construction suppliers, Maintenance Service Providers (MSPs), and others. Identification, qualification, and access governance all sit here.
The categories Indara uses to classify what is reported from a site, such as bushfire, break-in, structural defect, vandalism, or environmental issue. The taxonomy is the shared dictionary; the hazards and incidents themselves are the records that use it.
Mapping the six domains to the process cube shows where each is created or materially updated, and where it is relied on. Every domain is created at one stage and consumed at several others, which is why an error at the point of capture surfaces as rework many stages downstream.
Ownership, not technology, is the gap, which suggests defining an owner for each domain is essential.
The gap is ownership, not technology. There is a need to define an accountable person for each domain so that improvements can be owned and executed.
Each domain is used by multiple teams and synchronised manually between platforms. Divergence is built into the current model — it is a structural property, not an error rate.
A payee update overwrites a landowner contact and a maintenance visit is blocked weeks later. The rework, lost revenue, and customer dissatisfaction land far from where the data broke. There is a need to further clarify processes and simplify them before owners are set.
Domain ownership is a people and accountability decision, not a system build, but there is a need to first clarify processes to ensure a simple model is being utilised.
Opposite's review identified more than eleven platforms in use across Indara. Responsibilities overlap and the boundaries between platforms are not defined. Six are the primary operational platforms and the rest are supporting systems and document stores.
From eleven-plus overlapping platforms to a defined landscape with clear boundaries.
What each platform currently holds and is used for, as documented in the discovery materials.
Currently holds projects, assets, permits and cases. Used as the primary operational platform across most functions.
The Finance ERP. Currently holds leases at rest, the vendor master, and PO / AP.
Currently the customer equipment register (Layer 2 in the asset model).
External engagement surfaces. Today the only one in use is the COLO portal.
Visual record of asset state. Its role in the future operating model is undecided.
The cross-system decision-support layer that pulls from the others.
Beyond the primary platforms, the operating model also relies on a set of document stores and specialist tools: M-Files (legal documents), the R:// drive and SharePoint (project file storage), DoneSafe (BTS contractor incidents), LockVue (the SmartLock control plane), Genesys (the call centre), and the operator-side MNIS system that Indara updates manually. Defining the boundary between these and the operational platforms is part of the next phase's scope.
Mapping the six primary platforms to the process cube shows which platform leads at each lifecycle stage and which support it. No stage is served by a single platform, and no platform covers the whole lifecycle.
Mapping the systems to the master data domains makes the overlap visible: every domain is held in two or three systems at once, and no domain has an agreed authoritative system. Selecting one authoritative system per domain is the consolidate-versus-integrate decision recommended in Section 3.2.
Until one platform is agreed as authoritative for each data type, every integration only synchronises disagreement.
Each system provides a source of truth on some items of information but does not provide the complete story without other systems.
Because the line between operational platforms and document stores is undefined, value-bearing work — decisions, approvals, escalations — drifts into M-Files, SharePoint, and email by default.
The selection of an authoritative system for each domain determines who owns the data and how teams work. That decision sits with the ELT alongside the master data ownership decisions, not in a technology roadmap.
Keeping eleven-plus systems loosely aligned depends on manual synchronisation and the individuals who know where the real version lives. This may also contribute to workload and key-person risk (single points of failure).
Alongside the desktop review, Opposite conducted interviews and a leadership workshop with members of the Indara leadership and project team. The desktop review reads the operating model through its artefacts; the interviews and workshop read it through the people leading the change. This section brings together both sources: the interview findings and the workshop findings. The workshop findings cover the leadership workshop insights and the scope activity the group completed. Together they form a single view of how the leadership group understands the change.
This section presents the quantitative results from the four interview questions, followed by the seven recurring themes identified across the conversations.
All three respondents offered a different framing: data governance, cultural change, and automation. One respondent flagged the initiative as unfocused and recommended a data-first approach with phased process improvement. The programme needs a shared, clearly communicated definition.
Clarity is emerging with a slightly below moderate score across the dimensions (overall average 2.7/5). Intended outcomes scored lowest at 2.3/5. Interview 3 gave a uniform 2/5 across all four dimensions. Interview 1 scored highest, indicating uneven communication across the stakeholder group. There is opportunity for the project to better describe its vision, scope, and plan for success.
Data quality and unclear processes were described as the top pain points, each cited by two of three respondents. Poor data quality limits decision-making. Unclear processes make accountability and improvement harder to establish. Seven unique challenge types across three respondents indicate friction across multiple fronts simultaneously.
Customer experience and operational visibility are unanimous priorities (3/3). AI enablement follows at 2/3. Data quality and process clarity are prerequisites for operational visibility, customer experience improvements, and AI-enabled outcomes.
Patterns that recurred consistently across the leadership interviews.
The interview themes touch every one of Indara's Five Pillars of Change.
Leaders described the initiative in materially different ways across the interviews, variously as data modernisation, business transformation, automation, and cultural change. That variety suggests the programme has accumulated multiple framings over time and lacks a single shared narrative.
Poor data discipline, the absence of a single source of truth, and reliance on manual workarounds were universal pain points in the interviews. Several leaders observed that the original intent of Site360 was data-focused and recommended returning to that foundation.
Work flows exist but they are fragmented and break down at handoffs. The combination produces rework, obscures accountability, and makes scaling dependent on individual key people.
A portion of the workforce is sceptical of the need to change. Recent fatigue from mergers, recent leadership transitions, and a long-tenured workforce have produced inertia that the change effort will need to address.
Site360 is ambitious in its potential scale. The leaders interviewed want staged, prioritised delivery across a defined sequence of domains. A programme that advances across too many domains simultaneously risks stalling before results are visible.
The internal narrative focuses on what Indara intends to fix but it is less clear how the project will benefit stakeholders, staff (if they are to support the change) and customers. Several leaders acknowledged this directly, noting that the case for change requires a stronger customer focus.
Unreliable data and processes prevent leaders from obtaining accurate project status. The reporting layer reflects the underlying data and process issues and cannot function as a management tool until those issues are resolved.
A leadership workshop was conducted across the first half of 2026. It covered future focus, character, scope, and rollout in part to address findings uncovered by the interviews. This section presents the six insights drawn from those activities, with cross-references to what the desktop review and interviews found on the same topics. The synthesis across all three sources appears in Section 3.1.
In the workshop's scope activity, leaders sorted the candidate items drawn from the discovery work into what is clearly in scope, what is likely but not yet committed, and what sits outside this phase. The group scoped in the ownership, governance, and process work that forms the foundation, held the automation and innovation items as a likely next step, and kept tool-building and a standing centre of excellence outside this phase. The scope reinforces that data and process definition is needed now, which will enable many things, including automation. There may be an overlooked aspect of this logic in utilising automation and artificial intelligence now to support the project.
When leaders described their own role in the change, several framed it in terms of ownership and accountability. The same idea carried into the scope activity, where both data ownership and process ownership were placed firmly in scope, and into the future state they described for the business.
An early activity asked the group to select a leadership archetype that resonated the most. The archetypes the group identified with most strongly clustered around operating, serving the customer, and building.
Across the prioritisation rounds, the leading priorities, data and process ownership, held their position consistently. The ordering of items below them shifted between rounds. The group has agreed on what comes first and is working through the sequencing of the remainder.
Automation drew interest when the group considered the future state. The group treats automation as a second-phase commitment, after the data and process foundation is in place. This might overlook the possibility of leveraging automation now to accelerate the project and establish new ways of working that will provide competitive advantage.
The group's choices showed a preference for moving the initiative forward as a 'project' not a lasting structural change. A standing centre of excellence was the one item placed in the unlikely band. Given the scale of the work involved, there may be opportunity in future to consider a lasting team working on process improvements rather than a one-off project.
The desktop review, the interviews, and the workshop arrive at the same conclusions:
The leadership group agrees on the need for change but not yet on what the change is. They are keen to see a detailed plan with a clear scope of work.
Recent large changes, recent leadership transitions, and a long-tenured workforce have produced some fatigue and potentially scepticism that will need to be considered as part of the change.
Purpose 2.7, scope 3.0, direction 2.7, and intended outcomes 2.3 out of 5 — and the scores vary between leaders, signalling that no one owns the narrative at this stage.
Poor data discipline and the absence of a single source of truth were universal pain points — and the leaders are clear they want Site360 to have a strong focus on these points.
Undocumented flows are burdened by handoffs and obscure accountability.
The six cross-business patterns that draw together the desktop review, interviews, and workshop findings, read against the Five Pillars as a maturity analysis; and the recommendations that follow from it — across strategy, design, resourcing, capability, and timeline.
The Five Pillars of Change are the areas Site360 is designed to improve. This analysis reads the desktop review, interview findings, and workshop findings against each pillar and rates current maturity on a five-point scale. Six patterns recur across all three sources; read against the pillars, they give a consistent picture: each pillar is at Emerging. A need has been recognised and early thinking has started. The defining work begins in the next phase.
Each pattern below appears across multiple streams and functions and is corroborated by the desktop review, the interviews, and the workshop. The evidence sits in Part II: process findings in Section 2.1, master data and systems in Sections 2.2–2.3, and the voice of the leadership team in Section 2.4.
Every pillar stands at Emerging today; the near-term target is Defined.
Reviews, approvals, escalations, and financial control points happen in email, SharePoint, M-Files, Excel, and DoneSafe. Sitetracker records when something happened. Decisions are not captured.
Design parameters, asset attributes, lease terms and hazard categories are captured as document content instead of structured fields. Automation and reporting are blocked at the point of capture.
Each system holds the agreed source of truth for something. No system holds it for everything. A single trusted source requires the business to decide which system is authoritative for each type of data.
Site Status, the Item Catalogue, the MAA register, landlord contact and the decommissioning fields are each used by multiple teams, and none has a documented owner.
Every handover between teams is a moment where data falls between them, accountability becomes ambiguous, and customer experience visibly degrades.
Multiple teams contact landlords independently. Contractors raise hazards in different systems. Operators interact through different channels. No single external interface model exists.
The six patterns translate into the maturity ratings below. The radar shows current maturity against a near-term target of Defined.
Rated on a five-point scale from Initial to Optimised.
The findings and the maturity analysis converge on a set of recommendations across five topics: strategy, design, resourcing, capability, and timeline. Select a topic to see a summary and what Opposite recommends for the next phase.
Leaders currently describe Site360 in materially different ways. Opposite recommends Indara adopt one shared definition, confirm the delivery sequence, and have the ELT make three governance decisions before the CAC submission in August 2026.
Adopt one sentence and have every leader repeat it. For example: Site360 will give Indara a single, trusted data and process foundation — owned by the people who use it — so that people can spend their time on the work that matters, not the work that just recurs.
Put three decisions to the ELT now: confirm which system is authoritative for each master data domain, name the owner of each domain (a person, not a team), and define the governance structure that holds the Five Pillars together.
Name data and process owners first. Define the future operating model next. Introduce automation once the foundation is stable, and hold AI pilots and a Sitetracker upgrade on the horizon until then.
For each key change proposed, define a forecasted cost saving along with other improvements (e.g. productivity, cultural, behavioural, customer experience).
Adopt five design principles that define what the future operating model must achieve, and test every High-Level Design decision — on systems, data ownership, or process structure — against them.
Record decisions, approvals, and cross-team handovers as system events with a trigger, a service level, and a completion check. Take email, SharePoint, and spreadsheets out of the approval path.
Make one person accountable for the quality of each domain and one system the holder of the authoritative version. Point every other team and system to read from there.
One front door for each party — operators, landlords, and suppliers each get a single way in.
Have the system identify and action lease expiries, market rent reviews, permit renewals, and Power Offer expiries, removing the reliance on manual reports.
Identify anyone accessing a site, authorise them against a defined scope of work, and log the access. Replace free-text fields and manual permit checks with verified identity records.
Give operators, landlords, and suppliers one portal and one point of contact each for routine interactions, so that Indara presents as a single business to each party.
Stand up a small, dedicated core team of roughly three to four FTE to deliver the programme over 18 months, drawing on contractors for change capacity and on SME time from the business as each area comes into focus. Treat the numbers as indicative and confirm the in-house versus contractor mix once the Phase 1 scope is set.
Make one person own delivery end to end: governance, prioritisation, the staged rollout, and the case for change. The single point of accountability.
Have them design and run the change approach — stakeholder engagement and the culture programme — and lead the communication design and human-centred design of changes.
Resource process mapping, improvement scoping, and requirements capture from day one, and bring in automation and AI capability as the programme matures. Consider bringing in a process/AI specialist; this could be a contractor initially.
Source subject-matter expertise from the business as each priority area enters the cycle, rather than through standing roles, keeping the core team lean and decisions fast.
Build or bring in the six core capabilities that convert the design principles into delivered outcomes. Most can be drawn on or contracted; build data and master-data management first, because it does not yet exist as a formal capability at Indara and the automation ambition depends on it.
Establish data modelling, master-data ownership, quality remediation, and the discipline to establish and hold a single source of truth across systems.
Lift process work from operational mapping to a future-state operating design, and resolve consolidate-versus-integrate across the eleven-plus systems.
Lead behaviour change, translating programme intent into observable behaviours. This will occur by enlisting key change champions to support and drive improvements.
Establish the governance framework, decision rights, and delivery cadence that hold the Five Pillars together — and develop automation and AI readiness as the foundation stabilises.
Run an 18-month staged rollout, working one priority area at a time through a repeatable cycle: prioritise using the process cube, bring the right capability on board, make the changes, embed the change, then hand over and move to the next prioritised process. Re-score the cube at every handover so the next priority always reflects what has already been fixed.
Confirm scope and the reason for change, establish governance and decision rights, name data and process owners, and run the first one or two priority areas through the full cycle.
Embed and hand over the early areas, advance the cycle to the next priorities, extend data ownership across the domains, and introduce the first automation pilots where a mapped, stable process supports it.
Complete the prioritised rollout, scale automation where the cases are proven, and transition governance and ongoing improvement into business-as-usual, owned by the business.
One repeatable cycle, run area by area — each loop leaves an embedded, handed-over process behind.
We propose that every improvement is run like a small project. A priority area would be run through the same five steps.
Re-score the process cube and select the next priority area by finding density across the lifecycle.
Draw in the SMEs, the data owner, and any specialist capability the area needs before work starts.
Map the current state, design the future process, and implement the process, data, and system improvements.
Train, measure, and hold the new way of working in place until it is the default, not the exception.
Transition ownership to the business, re-score the cube, and move to the next prioritised process.
The cube in Section 2.1 ranks the lifecycle stages by the density of documented findings. That ranking sets the cycle order below. Because the cube is re-scored at every handover, the sequence self-corrects as improvements land.
Cycles 1 to 4 cover the top five stages. Design, Build, and Originate (15 findings combined) fold into business-as-usual continuous improvement as owners and governance mature.
Capability to onboard: the core team mobilised, governance cadence established, data and process owners named.
Bring day-to-day operations onto one consistent way of working, with clear ownership of the data that supports them.
Capability to onboard: Operations and Property SMEs, supported by data owners and IT.
Smooth the path from construction to billing so information is captured once and flows through without re-entry.
Capability to onboard: Finance and Lease Admin SMEs, with Build input on the handover.
Give maintenance a reliable, prioritised pipeline built on trusted site and asset data.
Capability to onboard: Maintenance SMEs and the asset data owner.
Tidy the start and end of the lifecycle: how agreements are set up, and how sites are renewed, modified, or retired.
Capability to onboard: Property and Legal SMEs, with Engineering and Finance input.