Common Enterprise wide Data Governance Issues #11: No ownership of Cross Business Unit business rules

This post is one of a series dealing with common Enterprise Wide Data Governance Issues.  Assess the status of this issue in your Enterprise by clicking here:  Data Governance Issue Assessment Process

Business Units often disagree

I'm right, he's wrong!

Different Business Units sometimes use different business rules to perform the same task.

Withing retail banking for example, Business Unit A might use “Account Type” to distinguish personal accounts from business accounts, while Business Unit B might use “Account Fee Rate”.


Impact(s) can include:

  1. Undercharging of Business Accounts mistakenly identified as Personal Accounts, resulting in loss of revenue.
  2. Overcharging of Personal Accounts mistakenly identified as Business Accounts, which could lead to a fine or other sanctions from the Financial Regulator.
  3. Anti Money Laundering (AML) system generates false alerts on Business Accounts mistakenly identified as Personal Accounts.
  4. AML system fails to generate alert on suspicious activity (e.g. large cash lodgements) on a personal account misidentified as a Business Account, which could lead to a regulatory fine.
  5. Projects dependent on existing data (e.g. AML, CRM, BI) discover that the business rules they require are inconsistent.

Solution:
Agree and implement the following Policy:  (in addition to the policies listed for Data Governance Issue #10)

  • Responsibility for resolving cross business unit business rule discrepancies lies with the Enterprise Data Architect.

For further details on Business rules – see Business Rules Case Study.

Your experience:
Have you faced a situation in which different business units use different business rules?   Please share your experience by posting a comment – Thank you – Ken.

Process for assessing status of common Enterprise-Wide Data Governance Issues

If you work with data in large enterprises, you will be aware that the data, and the ability of the business to access that data is seldom as “good” as it should be.  But just how “good” or “bad” is it?

This post outlines a process for assessing the status of common Enterprise-Wide Data Governance  issues within your enterprise, or that of a client.  I use it as the basis for my “Data Governance Health Check”.

These issues can impact your ability to deliver the underlying data required for meaningful CRM, Business Intelligence, etc.. More seriously, they can impact your ability to satisfy regulatory compliance demands (e.g. Solvency II, Anti Money Laundering, BASEL II etc.) in a timely cost effective manner.

Do issues like these affect your enterprise?  If not, how have you resolved or prevented them?  Please share your experience by posting a comment.

Common Enterprise-wide data governance issues:

1. Quality of informational data is not as high as desired


2. Quality of data entered by front-end staff is not as high as desired


3. No culture of Data as an ‘asset’ or ‘resource’


4. No clear ownership of data


5. Business Management don’t understand what “Data Quality” means


6. No Enterprise Wide Data Quality Measurement of Data Content


7. No SLAs defined for the required quality level of critical data


8. Accessibility of data is poor


9. Data Migration and ETL projects are Metadata driven


10. No Master repository of Business Rules


11. No ownership of Cross Business Unit Business Rules


12. No Enterprise Wide Data Dictionary


13. Islands of Data

14. No Enterprise Wide Data Model

Explanation of the scale and the process for using it:

There are 6 levels on the scale, starting at level 1, and increasing to level 6.  The higher the score, the better prepared the organisation is to deal with the issue.  The worst case scenario is actually a score of ZERO, which means that management in the enterprise is not even aware that the issue exists.  To assess the actual status of an issue, ask for documentary evidence to illustrate that the Enterprise  has actually reached that level:

Figure 1: Status of a (data governance) issue.

1. Aware Senior Management is aware that the issue exists.e.g. Data Quality is not measured, or measured in ad-hoc manner.#Evidence: Captured in Issues Log or Requirements document.
2. Understands Senior Management fully understands the issue; the impact of not addressing it; options available to address it, complete with the pros and cons of each option.e.g. Issue paper explains the impact of no Data Quality Metrics on downstream data dependent projects etc.Evidence: Issue Paper, Rationale paper or Point of View paper(s).
3. Policy defined Senior Management has a clearly stated policy/strategy identifying the selected option.e.g. Data Quality Measurement must be performed by each Business Unit, using a standard Enterprise Wide Data Quality Measurement process….Evidence: Policy document / Design Principles/ Communications/ education material
4. Process defined The organistaion has a clearly defined process detailing exactly how the policy / strategy will be implemented, which common services / utilities must be used, and exactly how to use them.E.g. The standard Enterprise Wide Data Quality Measurement process will use ‘off the shelf tool X’, to produce a standard set of Data Quality metrics….Each BU must train N staff in the use of the tool.  Training will take place……Evidence: End To End Process documentation / Education and Training material.
5. Infrastructure in place Infrastructure (systems / common services / utilities) needed to implement the process is in place.E.g. ‘off the shelf tool X’ has been licenced and installed Enterprise Wide.  Staff have been trained …Pilots have been run…Evidence: Programme Infrastructure document / Utility user manuals.
6. Governance in place Governance is in place to ensure that the defined policy is implemented in accordance with the defined process.E.g.  The stakeholders are…The Data Steering Enterprise includes the CIO and ….The reporting process is….. The following controls are in place….Evidence: Programme Governance document / Education / completed sign-offs

Your experience:
How do you assess Data Governance within your organisation, or that of a client? Please share your experience by posting a comment – Thank you – Ken.

Business is all about data

Technologies may come and go.  At the end of the day, business is all about data.

Take the banking industry:
Hundreds of years ago, banks had Customers, with Accounts, on which Transactions were recorded. Bankers knew their customers personally, and all details were recorded by hand in ledgers, using quills made from feathers. Over time, quills were replaced by fountain pens, and later by biros, to record customer, account and transaction details.

Fast forward to today:
Banks still have Customers, with Accounts, on which Transactions are recorded, only many, many more of them.   Financial Regulators require banks to “know your customer”, but it is physically impossibe for bankers to know their customers personally. Customers can now perform transactions via multiple channels, at the bank branch counter, over the internet, over the phone, using mobile devices.

Customer Relationship Management (CRM):
To provide their customers with the best service, banks have implemented “Customer Relationship Management” or CRM systems. CRM systems analyse data to identify situations when the bank may wish to contact the customer to offer additional services, or otherwise improve the service the bank provides to the customer.

Money Laundering, Fraud, Terrorist Financing:
Banks today face ever increasing risks of Money Laundering, Terrorist Financing and Fraud.  Regulators require banks to implement best practice Anti Money Laundering (AML) and Anti Terrorist Financing solutions.

Best practice solutions:
What is the common thread amongst the best practice AML solutions?  How do Anti Money Laundering solutions enable a bank to “Know your customer”?  How do Anti Money Laundering solutions identify Accounts that require investigation? How do Anti Money Laundering solutions identify “Suspicious Transactions” amongst the millions of transactions the bank processes daily?

The answer:
By analysing the data.  However, the data analysis must be targetted.  The analysis must seek out defined activity patterns, and then alert trained staff to the possibility of wrongdoing.   More sophisticed AML systems can identify transaction activity that is unusual for a given customer type, by performing “Peer Group Analysis”.   For “Peer Group Analysis” to work, a bank must be able to reliably distinguish between different customer types.   Distinguishing between different customer types is often more challenging than one would think…