Data Integrity Has to Outlive Any One Software Platform
In 2007 the Australian Government introduced the National Greenhouse and Energy Reporting Scheme (NGERS), the first mandated national reporting guidelines for Australian companies, backed by the National Greenhouse and Energy Reporting Act 2007. Glencore, along with many organisations, initially reported this information from consolidated spreadsheets. In time, software platforms emerged offering NGERS reporting support out of the box.
In 2011, Parasyn and Glencore began evaluating options for greenhouse gas reporting to meet these regulatory requirements, looking at enterprise applications that offered Glencore corporate other business benefits beyond NGERS, such as reduced OPEX through better energy use visibility or sharper gas-model definitions through data analysis.
Digitisation Is a Start, Not the Destination
Digitalisation gives software applications a standardised interface and reporting layer, and aims to improve user experience. That is straightforward for basic data entry. It gets harder as the input data grows more complex and harder to qualify for quality. Moving data from paper or spreadsheets into a platform doesn't make the data more useful, only more accessible. Big data on its own doesn't change anything, it just lays a platform that might. Every decision, automated or human, is only as good as the data it's built on.
Data Rarely Has Just One Use
After Glencore selected its reporting platform, the harder question remained: where should process and business data be sourced and stored, and how do you reduce human error and intentional manipulation? Treating data as single-purpose is a long-term investment mistake. Its first use usually serves one business function and a small set of stakeholders, and the investment case is scrutinised accordingly. But there is often real scope to expand a data system's usefulness across the whole business, once that wider value is codified early. Better organisation makes that adoption easier.
Enterprise Application and Historian, Working Together
Glencore's NGERS architecture paired Enablon as the enterprise reporting application with OSI PI as the enterprise historian, which also aggregated raw data from remote mine sites. Implementing enterprise-class software at this scale means weighing hardware, functionality, data access and storage, cybersecurity, networking, user administration, legacy data migration, configuration management, and lifecycle management together, not in isolation.
Designing for the Next Change, Not Just This One
Being boxed into a corner with limited options is expensive and frustrating. A lifecycle-managed system design includes a transition-out plan from the start, giving the next stage better options. That kind of planning usually improves IP, configuration, and product management, and lifts governance, not always welcome to vendors, but lower risk for system owners. The real lifecycle asset is the data itself, including everything derived and reported from it, and access to that data, and how open its configuration is, should be locked in early. The QA cost of a new system can take years to recover, often well after the original vendor has moved on, and that cost repeats at every technology refresh if data isn't carried forward reliably.
When Change Is Required, Do You Start Again?
As Glencore's requirements matured, the business proposed shifting all reporting onto the PI platform, adding an application layer with PI ACE to calculate and automate the transformation of raw data into reporting information. Enablon was transitioned out of NGERS, and PI ACE took over, with manual entry via SAP. A lifecycle approach to information assets made both the transition out and the transition in considerably smoother. OSI PI itself wasn't dedicated solely to NGERS reporting either, process data from other Glencore facilities fed into the same enterprise historian, multiplying the value of an asset already in place and maintained.
Configuration Management Decides Whether You Start Again
Configuration management is core to systems integrity, covering design artefacts, software configurations, audits, incident management, and source code and database backups. Done well, it lowers operating costs, and gives the PR team less to manage when systems stay reliable. Proof-of-concept work tends to skip this discipline, asking only “does it work” rather than “does it meet the wider business requirement, and does it scale.” A PoC that becomes a critical OT system without that scrutiny almost always leads to uncertainty and poor reliability down the line.
The Parasyn-Glencore Application Journey
Across the different stages of Glencore's NGERS lifecycle, Parasyn has played the designer, integrator, tester, and maintainer, distinct from a pure caretaker role that focuses only on data integrity, reporting compliance, application support, and extending the system to new data sources and standards.
Does Lifecycle Management Cost More?
Asking “how much does it cost” at the start of a journey can be misleading. Full lifecycle costs, including transition-out and replacement, almost always dwarf the up-front engineering spend, which makes platform-refresh decisions driven purely by software licence cost a distortion of the bigger picture, especially as subscription licensing makes that cost feel “sticky.” For data-intensive applications with ongoing validation and expansion, full lifecycle replacement costs run an order of magnitude higher again. The practical takeaway: assess whether lifecycle management has been applied with discipline before assuming a system replacement is the only path forward. If it has, transition out is methodical. If it hasn't, expect the same painful cycle to repeat.
The greater the pain to maintain is generally a strong indicator that lifecycle management, and likely configuration management, is the root cause of most of the anguish.