Enterprise
Award: Winner: Telstra.
Runner-up; SBI Insurance.
There was so much to take in throughout the two days that it’s
pretty tough to try and summarise everything! (I will probably revisit some
topics in more depth in future posts…) But for now, here are my “top 10”
highlights:
1. Data Quality is boring!
Or at least, it can be perceived to be boring by people who aren’t
actively engaged. Passionate people are needed if the data is doing to be cared
for, so you need to engage in a manner that is relevant to the business
community, not concentrate on the practitioner processes. Use language and
examples that are business-oriented. Make it fun!
2. Learn from you mistakes
Don’t repeat the failures of before. Projects should incorporate a
“Long Hard Look” exercise at the start of a project phase as part of project
initiation and planning, not at the end of a project (when the lessons will
quickly get forgotten).
3. Plan for change, and
expect to change your plans.
Having a good plan will enable you to adapt later. But don’t
adhere rigidly to the plan, because reality never turns out the way you though
it might. Be flexible, be adaptable, be responsive, and be available.
4. Identity Management and
Federated MDM
The concepts of “Party” and “Roles” are critical to enabling a
single consolidated understanding and unique identification of each “customer.”
At some point, an individual could play any number of roles in interacting with
the organisation (e.g. customer, member of staff, supplier, broker, agent,
benefactor, consultant…. IAG currently recognise 37 valid roles that a Party
may play.) The concepts of Party and Role require constant ongoing education to
the business.
5. Customer-Centric =
Information-Centric
To enable a customer-centric approach, an information-centric
enterprise view is foundational; it enables both cross-application integration
and analytic insight. System- and Process-centric architectures drive
compromises (because of silo thinking being built-in by design). As a result,
data quality suffers. We need to have an information-centric architecture to
overcome this.
6. Data Quality Declaration
The Australian Bureau of Statistics (ABS) publishes a Data Quality Declaration statement
(DQD) with each data set it issues. The DQD provides contextual and narrative
guidance to data consumers as to the relative suitability of the data set
within a given context. The consumer can then adjudge whether or not the data
set is suitable for their purpose.
7. “The data is always
right”
A data quality error indicates a failure in the process, the
system or the people. Use the data to inform and drive process change.
8. Data Quality by Design
In manufacturing, the production line would stop if there was a
failure in the quality of products. Why is it not the same with failures in
data entry?
Note that the just because we have the ability to profile a
feature doesn’t mean we should! 100% data quality is almost never necessary (at
least for analytic decision-making). Pragmatism should be applied to prioritise
profiling and remedial efforts.
9. Useful Reference
Frameworks
Several public domain reference frameworks were identified as
being useful to the Data Quality Practitioner community, including:
10. Data Quality with “Big
Data”:
In “Big Data” environments, the velocity, volume and variety of
data processing create issues for timely measurement of veracity. Compromises
will be necessary and we therefore need to be very clear and pragmatic about
applying our data quality checks:
- Where to check (which steps in the data processing flow).
Please do leave a note to let me know your thoughts, or to share any
similar experiences.