Blog: Kelle O'Neal Subscribe to this blog's RSS feed!

Kelle O'Neal

Thanks for joining our data conversation! This blog is an opportunity to share the real life challenges, opportunities and approaches to improving the quality and value of data in your organization. We will write about everything data related from translating "data" speak into "business" speak, to governance models, to the real differences among the myriad software tools available. But there's one catch: we all have to agree to toss out the fluff. That's right, no 30,000 foot, theoretical strategies that leave you wondering how to execute and actually improve performance. Visit regularly to learn from peers and partners on how they are managing and improving data, and we hope you'll also share your views and experiences.

About the author >

As Founder and Managing Partner of First San Francisco Partners, Kelle O’Neal manages specialist data governance and data management consulting services to complex organizations that deliver faster time to results. Kelle can be reached at kelle@firstsanfranciscopartners.com or through the First San Francisco Partners website.

Follow First San Francisco Partners on Twitter at @1stSanFrancsico.

Editor's Note: Find more articles and resources in Kelle's BeyeNETWORK Expert Channel. Be sure to visit today!


A client recently asked me this, and I thought it was a great question!

Data Architecture and Data Governance support each other in a variety of ways, with the mutual goal of creating standards and guidelines to support the enterprise in increasing operational efficiency, decreasing costs and mitigating risk.

Data Governance Supports Data Architecture
There are policies/principles that are designed and enforced by the overall architecture group to ensure best practices are followed for new technology implementations. The Data Governance Team (DGT) can "translate" those policies into business requirements and guidelines and help to enforce them from a business perspective. Education sessions will help the business folks to understand the importance of data architecture and the impact when its guidelines aren't followed. This should help the business in its project planning process as well as set its expectations for what is possible. Without the DGT as a forum, this sort of knowledge transfer only happens on a project-by-project basis and usually only when a request is made that is denied because it doesn't adhere to the data architecture policies/principles.
 
Data Modeling--an important component of Data Architecture--is also critical to Data Governance. It is rare that the business cares to be involved in data modeling, and the DGT has an important role to play in educating the business on data modeling and translating why data modeling needs to be a reflection of the operational use of data (as well as a reflection of customer engagement, product positioning and other key business operations). The hierarchies and data relationships that the DGT creates to reflect the view of the customer, for example, need to be instantiated in the appropriate data model(s). Without a high-level understanding of data modeling, business people will lack the ability to understand how to translate the operational use of data into the systems that house the data. Essentially, the data model needs to reflect the business model, and the DGT can act as both a translator and a facilitator to ensure that this happens.

Data Architecture Supports Data Governance
Data Architecture provides an understanding of what data exists where and how it travels throughout the organizations and systems. It highlights changes and transformations made as data moves from one system to the next. These data inventory and data flow diagrams provide the information and the tools that the DGT needs in order to properly make decisions regarding data policies and standards. These artifacts also help the DGT perform root cause analysis when data issues are raised by business people, and they help to solve those issues.
 
The data inventory and data flow diagrams also help to determine what can be measured, when and how. They can help to identify the possible business impacts associated with improving data quality in the systems by understanding who uses the systems and for what purpose--this also helps in creating metrics and measurements. As well, they can help to determine how to measure adherence to standards based on who creates and updates the data in which systems.
 
Overlaying the data inventory and data flow diagrams with data accountability and ownership is a helpful artifact for everyone in the organization and also helps to determine where gaps in accountability and ownership may lie.
 
Participants in the DGT may also find these artifacts very useful to take back to their groups and educate their teams about the source and usage of data that they may consider "theirs." In fact, in many instances, key business stakeholders say it would be helpful to understand the data landscape and how data moves across the organization. The DGT has a role in educating the rest of the company on this information and in overlaying that information with the policies and standards that are implemented along the way--all of which is important in ensuring that data is accurate and maintains its integrity throughout its lifecycle.

Do your Data Governance and Data Architecture groups work together? How do you see them supporting one another? I'd love to hear how this works in your organization!

Posted March 26, 2014 5:00 PM
Permalink | No Comments |
In the wake of on-going medical device fraud, negligence and harm occurring in the U.S. and abroad, pressure had been mounting to tighten device tracking and monitoring regulations. In UPC barcode_smallthe U.S., Congress responded to that pressure along with other medical and healthcare needs by signing into law the FDA Amendments Act of 2007 (FDAAA). For medical devices, FDAAA required the FDA to establish a unique device identifier (UDI) system to improve adverse event reporting and traceability for devices distributed within the U.S. The system would also facilitate faster and easier device recalls and enable improved detection of and response to counterfeit products, with the ultimate goal of improving patient safety. 

Specifically, under FDAAA, UDI regulations require:
  • The label of a device to bear a unique identifier that enables device identification through distribution and use, unless an alternative location is specified by the FDA or unless an exception is made for a particular device or group of devices
  • The unique identifier to include a lot or serial number
All medical devices manufacturers distributing devices in the U.S. will be required to comply with these regulations, and each manufacturer will have one year to comply, although priority for compliance will fall to those devices that are implantable or life sustaining.

On its most fundamental level, the UDI would be a coded number registered with standards organizations that would incorporate information including, but not limited to:
  • Device manufacturer
  • Device make and model
  • Device expiry date
  • Any special attributes that the device may possess
Currently, the FDA is building the IT infrastructure to support the system. This includes the creation of a UDI database that will serve as the authoritative source for all UDIs and UDI-related information. In effect, they are creating a "UDI Master of all Masters," populated by the feeds provided by the different medical device companies.

This regulation is driving the need for medical device companies to revisit their own data management approaches to ensure that they can provide the FDA with a clean submission of unique identifiers for their own device data. I previously wrote a blog post--Leveraging MDM for UDI Compliance--on how Master Data Management, specifically Product Master Data Management or Product Information Management (PIM), can help medical device companies organize their device data in a way that facilitates their submissions to the FDA. Data Governance is also an important competency that organizations need to develop in order to ensure that changes made to their data management practices to address UDI do not add complexity to their infrastructure or create a short-term "stop-gap" solution that creates rework down the road.

If you are part of a medical device organization, how are you preparing to comply with UDI regulation?

Posted July 19, 2013 5:30 AM
Permalink | No Comments |
In the last blog post, we discussed the first four elements a data governance organization (DGO) needs to consider in planning for and implementing a master data management (MDM) strategy. They included:
  • Entity Types
  • Ownership and Accountability
  • Policies, Processes and Standards
  • Data Integration (Inbound and Outbound)
In this blog post, we'll address the remaining five considerations:
  • Service Level Agreements
  • Data Quality
  • Match and Merge (Survivorship)
  • User Interface and Security
  • General Maintenance

Service Level Agreements

Service Level Agreements (SLAs) guide the standards and set expectations regarding the quality of service provided by the DGO. They are identified and developed to explain the level of service expected from the DGO. SLAs are typically defined and then implemented between key groups as described below.

The DGO and the business - For example, how are data quality exceptions handled? What is the duration of time needed to fix the problem? An SLA might specify that a response will be received from the DGO in two business days with a remediation plan and time line to fix the issue.

Producers of data and consumers of data - For example, to address data integrity, how will changes to data in upstream systems be addressed? The SLA might stipulate that producers of data must perform an impact analysis within a given time period and present the recommendations to the DGO before implementation.

The DGO and IT - For example, in regard to serviceability and the ease in which a service may be performed and completed on a system by the IT group, an SLA may state that 80% of service failures are recovered in less than 30 minutes.

DGO and IT_75 percent.png

Data Quality

Required data quality targets for each entity type and each data element that is to be measured should be defined. The DGO needs to monitor data issues and track progress over time to show the value of the MDM hub.


Typical questions to be addressed include:
  • How good does the data have to be?
  • How will the data be monitored?
  • What are the data quality measurements, metrics and key performance indicators (KPIs)?
  • What scorecards need to be created?

Match and Merge (Survivorship)

Survivorship rules attempt to create the best version of integrated data in cases where multiple systems can create and/or change a record that refers to the same record in production applications. They also serve to outline the required process when master data is deleted in a contributing source system.

The DGO must define survivorship rules to detect duplicate entities based on specific "match" rules. These rules may include:
  • 'find duplicate contacts'
  • 'exact match on full name, organization and email address'
  • 'fuzzy on full name'
  • 'fuzzy on organization'
  • 'exact email address'
The MDM hub must be able to automatically merge duplicates or set them aside for manual verification based on the configuration of the match rules.

User Interface and Security

The extent of the MDM user community and all associated security rights need to be defined and understood. Data stewards need access to the MDM hub, however not all have access rights to all the data in the hub. Some data stewards can only see and work on certain types of data within a certain subject area.


The following questions should be addressed:

  • What type of security is required around the data?
  • What user access rights and privileges are required by user type?
  • How is data security monitored and improved?


General Maintenance

The DGO also needs to define the requirements for job and system monitoring, maintenance, backup and recovery and system support.

Conclusion

Many decisions need to be made in the course of an MDM implementation, and those related to data management, in particular, should be made by the DGO. An MDM implementation has a much higher likelihood for success with an effective decision-making structure and process in place. That is the purpose and value of a well-defined data governance process and DGO.


Consequently, one of the most important factors in preparing for an MDM implementation is setting up the DGO to facilitate these critical decisions. The need for the DGO arises from the fact that data is now being shared at an enterprise level rather than used solely at the application level. With proper data governance practices in place, the MDM hub will deliver trusted data to the organization, and the organization will realize the full benefits of mastering data.


Want to learn more about Data Governance as a key to MDM Success?
See Kelle O'Neal present live at the Data Governance & Information Quality (DGIQ) Conference June 17-20, 2013 in San Diego, California!


Posted March 14, 2013 7:30 AM
Permalink | No Comments |
In part one of this series, we covered the importance of setting up a data governance organization. Now let's identify and review the types of decisions made by this organization.

During the requirements gathering phase of a master data management (MDM) implementation, the data governance organization (DGO) is involved in defining the scope of requirements for data that will be managed in the MDM hub. Several categories need to be considered, including:
  • Entity Types
  • Ownership and Accountability
  • Policies, Processes and Standards
  • Data Integration (Inbound and Outbound)
  • Service Level Agreements
  • Data Quality
  • Match and Merge (Survivorship)
  • User Interface and Security
  • General Maintenance
We'll cover the first four of these categories in this blog post. Our last blog post in this series will review the remaining five decisions that a DGO must consider for a successful MDM implementation.

Entity Types

One of the first decisions the DGO must make is to determine the entity types that are in the initial scope of the MDM implementation. The entity type (or master data type) to be managed in the MDM hub may include, for example, client, product, supplier, legal entity, etc.

The hierarchies, relationships and associations among these entity types that will be managed by the MDM hub must also be defined. Again, these may include client, account and product hierarchies, as well as the association of an individual to a company, a party to an address, a product to a supplier, a part to a finished good, etc. Additional entities, hierarchies, relations and associations can be added as needed.

Ownership and Accountability

Identifying ownership and accountability ensures that there are people in place to drive decision-making and execute data related tasks, such as determining match/merge rules and handling exception reports. A responsible, accountable, consulted and informed (RACI) matrix must be developed and agreed upon. This matrix should outline data owners (by data element) and data custodians who can create, view, update/change and delete the data.

Policies, Processes and Standards

Policies are business rules or guidelines that need to be in place in order to manage and govern the core set of data elements in the MDM hub. Policies ensure that consistency exists around how data is managed. Policies, processes and standards should be clearly defined, followed and enforced by the DGO.

Policies are business rules used to manage the data. Business rules fall into the categories of data management, data integrity, data lifecycle, data access and retention.

Processes are workflow processes that define "how" the business rules will be implemented. Workflow processes can be integrated into a data governance workflow tool. Foundational processes include:
  • Issues identification, escalation and resolution
  • Data changes, change control and new elements
  • Data quality management approach
  • Standard operating procedures (SOPs)
  • Performance baselines
  • Data reconciliation and synchronization
Standards define a means of maintaining consistency. Standards are created to help reduce the risk of multiple data definitions as a result of financial, operational, and compliance related inefficiencies. Definitions of each entity type must be agreed upon. In addition, the data's purpose, the usage of each data element and an authoritative source for each data element must clearly be articulated.

Data Integration (Inbound and Outbound)

The DGO should not only define the type of entity data to be integrated into the MDM hub but also which systems will supply the data. The DGO needs to determine which are the authoritative and most trusted sources of the data, the frequency of updates to the data and the timeliness of the data. These definitions inform the development of service level agreements between the producers of data, consumers of data and other business groups.

Inbound Data Sources
  • What type of data does each source supply?
  • Why is this needed?
  • At what frequency should they supply it?
  • Who owns the quality of the data?
Outbound Data Sources
  • Which applications will receive master data directly from the MDM hub?
We've reviewed the first four decisions that must be made by a data governance organization (DGO). Our next blog post will cover the remaining five necessary considerations.



Want to learn more about Data Governance as a key to MDM Success? See Kelle O'Neal present live at the Data Governance & Information Quality (DGIQ) Conference June 17-20, 2013 in San Diego, California!

Posted February 22, 2013 5:27 PM
Permalink | No Comments |
This is the first blog post in a three-part series discussing the importance and role of a data governance organization in a master data management (MDM) implementation.

MDM is about people and process, not just technology. Implementing MDM technology alone will not address operational and business process challenges. Rather, "mastering" data involves people taking the appropriate action through established data policies and processes.

Data governance is an important people and process component of an MDM strategy. It ensures that data in the MDM hub is of high quality and can be trusted by business users. Without data governance, organizations do not have consistent data definitions or know what constitutes a data problem, who is accountable, what decisions need to be made, or how to escalate and resolve issues.

MDM Implementation funnels_50 percent.png
In this way, data governance plays a vital role in an MDM implementation. The MDM hub provides the requisite data cleansing, duplicate detection, survivorship, hierarchy management and merge/unmerge capabilities. Essentially, it's the technology used to ensure the data is accurate, complete and can be trusted by business users. Data governance is the essential people and process component. It provides the processes, policies, organization and technology guidance required to manage and ensure the availability, usability, integrity, consistency, auditability, quality and security of the data in the MDM hub.

The data governance organization's (DGO) role is to understand and outline data requirements for the MDM hub. Once these requirements are understood, the DGO facilitates the creation and agreement of foundational elements--such as data models and data dictionaries--to support those requirements. Data governance creates a culture of accountability and ownership around the quality of data and provides escalation mechanisms to manage data quality.

The goal of the DGO is to ensure that the right resources, policies and processes are in place and that the data is available, usable and secure in the MDM hub. Bad data will no longer be ignored and can be addressed proactively and effectively. The DGO manages confidence in the data by ensuring that the data stays clean over time, that it is monitored and measured, and that data quality is continuously improved.

In order to deliver on its mandate, the DGO is responsible for guiding and making decisions concerning an MDM implementation. What MDM decisions does the DGO need to make? The next two blog posts will discuss the important data governance decisions that need to be made by the DGO for a successful MDM implementation.



Want to learn more about Data Governance as a key to MDM Success? See Kelle O'Neal present live at the Data Governance & Information Quality (DGIQ) Conference June 17-20, 2013 in San Diego, California!

Posted January 31, 2013 1:33 PM
Permalink | No Comments |
PREV 1 2