When many engineers hear the term “data management”, they immediately envisage a collaboration site or a proprietary database or even BIM – at a basic level, data management is the approach which an organisation uses to coordinate and improve its knowledge.
Ultimately, data is an important enabler of engineering and asset management at every stage of an asset’s life cycle. It acts as the foundation from which all decisions are made, better data enables better decisions.
I have witnessed a tendency to capture every dataset possible without consideration of the usefulness of that data. This leads to unnecessary cost of data capture, the ongoing cost of data management as well as the additional cost of regularly trawling useful data from the swamp of irrelevant data. My view is that data, like all assets, should be the subject of a cost benefit analysis before creation and always provide an ongoing benefit in return for being maintained.
Does data have a shelf-life?
At what point does data lose its usefulness and have to be discarded? As-built drawings and records of major maintenance interventions such as strengthening will be useful throughout the life of an engineering works - if these can be located by engineers decades later and not lost in the noise of 60 year old graffiti removal and gully cleaning records.
Does your organisation keep everything forever? Or does it have a blanket delete policy for all datasets of certain age regardless of content? My advice is that you should actively assess each dataset considering life of usefulness versus the impact cost of recreating that data.
Tools should support your data strategy and data dictionary of your organisation tools, including integrated databases and decision support tools, back wider business processes and leverage data to be both accessible and beneficial. This is equivalent of a dog wagging its tail.
Set Clear Data Standards
Before you consider any IT software procurement, you should have clear data standards agnostic of any digital tool. Clearly defined data standards feed directly into robust system specifications resulting in cost effective solutions. For example, you may find that you do not immediately have the required input data available and need to undertake costly data collection, cleansing, handling or reformatting. The tail is now wagging the dog.
Remember this…software is only as good as the underlying data, procuring software without knowing the underlying basic data quality is unwise.
Ask yourself honestly; is your data accurate and error free? Is it current and up to date? Is your data assessable in the appropriate format? Is it complete without gaps? Is it unique without multiple conflicting versions of the truth in different databases?
As engineers, we need to show leadership and design our data structures as robustly as any engineering structure.