Home/Resources/Blog/Data & Connectivity
5 min. read
This blog is part of a series of blogs published by UReason about sharing (operational) data from assets used in the industry. It provides the rationale (why would you?!) and discusses the barriers and legal and technical solutions out there to safely share data. It also provides views on the topic of sharing data as well as market insights.
The rationale for sharing data is diverse, and especially in enhancing asset optimization there are clear reasons and quantifiable value drivers. The waste of not sharing data in industry is remarkable but as we experience it there are also clear reasons for this. In the below overview of barriers, we have extended the trust and technical barriers that the WEG/BCG report identified with our experiences and views:
Trust-related barriers
UReason: Not many vendors provide a transparent view of how data is used once shared. Where is it stored, for how long, what is done with the data after the subscription to the software that required the data stops et cetera. This is an area where industry needs to mature and where in our view the International Data Spaces Association (IDSA) initiative fulfils an important role. The IDSA focuses on creating a framework for secure data sharing and exchange in a decentralized manner across organizational and national boundaries. It aims to enable trusted data ecosystems where businesses can share data with confidence, maintaining control over their own data while benefiting from access to data from other sources. A data space is two ways, the analysis results need to be shared in a way that can be automated (using APIs) and at UReason this has our full support.
Technical barriers
- WEF/BCG: Risk of data breaches and losses.UReason: A significant risk is the potential for data breaches, where unauthorized parties gain access to sensitive information. This can lead to financial losses, reputational damage, and legal consequences. Cybercriminals may exploit vulnerabilities in systems or use social engineering tactics to access data improperly. To mitigate these, organisations should implement robust data security measures, including encryption, access controls, authentication mechanisms, and monitoring tools. Additionally, clear data-sharing agreements and contracts should be established with third parties, outlining responsibilities, limitations, and safeguards for protecting shared data. Regular security audits and assessments can help identify vulnerabilities and ensure compliance with relevant regulations and standards.
- WEF/BCG: Different digital maturity levels among participants in the same solution.UReason: Prior to the public introduction of ChatGPT, in late 2022, people would generally not trust technology that they did not understand especially when also the value of the technology was not clear. We see this changing; the adoption of technology is picking up a pace fuelled by the demographic changes in our workforce and issues we have or will soon face in the industry with expertise leaving. Even though technology is more easily and rapidly adapted the knowledge gap most reliability/maintenance engineers and managers have to digital technologies is big and growing. The promise of ease that many predictive maintenance software companies introduced, offering unsupervised anomaly detection algorithms as a band-aid for any issue, is gradually disappearing. They have value, but users realised that deviations needed to be labelled for such models to detect true anomalies (at the cost of valuable time). Today education and knowledge sharing are the only ways to reduce the gaps and we will continue providing seminars, webinars, and lectures to our community!
- WEF/BCG: Costs of switching technologies (or fear of technological lock-in).UReason: This fear actually goes back to the trust-related issue “Lack of visibility into data usage and analysis once shared”. If you as asset owner do not have access to the processed, enhanced and/or deferred and analysed data then you essentially lose data and implicitly create a vendor lock-in when you rely on this. There are several architectures such as microservices and data microservices that must be supported by your vendor. Your software provider needs to support openness and provide you access to your data and derived data. This allows you to treat the APM software you use as a black box: you provide it with inputs, it processes it, and provides you with outputs. When you require to switch technology/vendor this in turn becomes your requirements sheet.
This blog is part of a series of blogs published by UReason about sharing (operational) data from assets used in the industry. It provides the rationale (why would you?!) and discusses the barriers and legal and technical solutions out there to safely share data. It also provides views on the topic of sharing data as well as market insights.