Own up! Who wants to take on ownership of data?

April 24, 2013

In a recent blog data governance is not data management I recounted some interesting insights from a panel I sat on at TSAM 2013 in London. On the same panel there was also some other interesting topics discussed – one that sticks out related to ownership of data and where is should sit in an organization, be that from a management or governance perspective..

Steve Clark had some interesting take away’s, he stressed how it is important to have “different owners for different (data) types” or domains of responsibility. Specifically he referenced the need for IT ownership and involvement of technology teams in taking ownership for the movement and delivery of data from source to consumer, while at the same time requiring ownership from business for the semantics of the data. This ties in well with my own well published views on ownership and stewardship models. In my opinion it is not just about driving ownership to data source. Today in asset management firms I am firmly of the opinion that the ownership and stewardship models need to be multi-tiered. As data passes through the firm from back-, to middle- to front- office, it starts to snowball in terms of added meaning, enrichment, added value  and increased importance. Typical operating models I see today have owners and stewards ranging from; IT for data delivery to schedule and agreed formats, to data domain specialists for specific data domains across many products, to product specialists that work across multiple data domains for single products, on to front-office specialists such as portfolio managers, or indeed distribution IT specialists involved in delivering data to market. So in effect ownership and accountability needs to follow the nested layers within the back to front publication cycles that so often permeate asset management firms.

Phil Tattersall had some interesting points too – he stressed the importance of “establishing the concept of data ownership” early, and how important it is in the overall scheme of setting up an effective governance structure. Another interesting anecdote from Phil was “ownership helps shift the attitude towards data management” – this was specifically with reference to getting C-Level engagement. My own view here is that ownership top-down is as important as bottom-up, i.e. you cannot neglect one to the detriment of the other. You cannot gain any traction in driving ownership if you are not working it top-down and gaining C-level buy-in and engagement, at the same time you need to be working the process bottom-up to reach the parts of the organization that are handling and managing data as their one and only focus.

I think it is fair to say all the  panellists agreed that getting ownership and accountability is one of the toughest tasks in any program of governance you are trying to gain traction with. The key problem being finding people who WANT to own data. A couple of pointers came up – it is your job to sell the reasons why ownership will help drive the program forward, you need to find those people in your organization that eat, breath and live data and do not fear ownership – but most importantly you need to break down the perceived fears people associate with data ownership!

2 Comments | Data Quality | Tagged: , , , , | Permalink
Posted by Ronan Brennan

Data governance is not data management

April 17, 2013

I was on a panel at the recent TSAM UK 2013 conference in London – where the topic was “Good data governance – the challenges for the business“.

On the panel I was joined by Phil Tattersall (Simitas), Steve Clark (KPMG) and Andrew Barnett (Friends Life Investments), our moderator was Chris Johnson of HSBC Security Services.

One of the topics we discussed on the day was around governance frameworks, what had we seen in practice that worked and to what extent was governance being driven by business (as opposed to IT).

One of Phil’s comments still resonates with me today “Data governance is not data management” – why so? …unfortunately the perception that governance = management is something I come across too often. Data governance is what ensures that data management happens properly i.e. in a way that is aligned with the original goals and terms of reference for the initiative under way. Data management professionals need to clearly understand the difference between governance, stewardship and architecture!

Another of Phil’s points was also very salient  ”treat data as an asset”  any of you that read the recent Citisoft white paper “Data is the new oil” will see the connection – data is something we need to value, it can often be presented in a very raw form, and like oil, it requires careful refinement to extract maximum value. I am fan of the data and oil metaphor myself – from a slightly different angle though, I often refer to data being the oil in the distribution engine for investment managers – feed the engine with poor quality oil (data) and within a short space of time that engine will seize up.

Steve also had some good points in the above discussion, he stressed the importance of setting out the “policy and procedures in governance” and the criticality in “defining good data quality” and the measurement and feedback that should exist in your process management framework to drive improvement.

With respect to whether governance should be driven by business or IT, Andrew indicated that in his business “data teams are made up of business people” – myself and the rest of the panellists agreed that data governance initiatives should be driven by business, but that clearly IT have a role to play and their involvement will always help.

My own view was that frameworks for governance are important, in the sense a framework is anything that providers structure and guidance to the application of governance to any data management initiative. This ‘structure and guidance’ can take the form of technology that assists the empowering of the stewards to manage data in line with the stated strategies and principles as laid out by governance.  Technology can also assist in  driving ownership, accountability and transparency into the process. The key point though is not to overly rely on technology. Technology does not fix bad quality data – that is what good data management professionals do – we just need to enable them to do their job more effectively.

1 Comment | asset management, Data Governance, Data management, Data Quality, distribution, Event, Technology, transparency | Tagged: , , , | Permalink
Posted by Ronan Brennan

Setting up a governance program for effective management of investment product master data – Part 10 – Move to Maturity

March 25, 2013

This is the last post in a series of blogs on setting up a governance program for the effective management of investment product data, in this blog I will wrap up the series with a discussion on how to move your governance program towards a mature model.

If you have followed the earlier 9 posts you will probably recognize many of the steps in the data governance evolution scale  I referred to in one of my previous blogs on maturity models for governance of investment product data (see image below).

Data Governance Evolution - from Chaotic to Predictive

The Data Governance Evolution Scale

As you embark on the instantiation of your program you will more than likely be working within a quite chaotic environment – one lacking in clear, top down driven policies and standards, and very much reactive.

As you start to take action and follow some of the steps that I have outlined in earlier posts you will start the journey towards maturity – initially you will need to go through the process of securing C-Level buy-in, and formulating terms of reference for the program, before embarking on the broader strategy definition.

Do not neglect the importance of the culture and organizational structure that will be needed to support and enable the governance program to succeed – in particular you have to think about the target operating model of stewardship that will be most effective for how your business is structured both now and into the future.

In order to move from the “chaotic” and “reactive” levels in the maturity model you must focus heavily on the following:

  • Ensure your strategy is clearly defined and communicated to all actors within the domain you are trying to apply governance too
  • Set out the policies and standards you want to promulgate, with clear alignment and reference to the strategic goals
  • Once you have the policies and standards down pat you will need to focus on ensuring you have a set of applicable processes and procedures that are aligned with the overall strategy – each process should be directly traceable back to a specific standard/policy
  • In parallel to the process of defining the policies, standards, processes and procedures (the how) you need to be working on building out your master data plan (the what)

If you have worked through the process above, you will have moved from a position of total vacuum, to a chaotic, to a reactive program of governance – in fact you have probably got further than many firms who claim to have governance will ever move past.

To move from “reactive” to “defined” you need to make sure that there is a clear understanding of the data within the terms of reference of the program – all participants have to use the same nomenclature when talking about data, as inappropriate usage, miscommunication and misunderstanding of what is being discussed is the most common root cause of data quality issues I see. To this end, the construction of  a data dictionary is a fundamental step in moving your program to state of ”defined”.

Other areas you will need to focus on before you can consider your program to have achieved the level of “defined” in our maturity model are as follows:

  • You need to start the process of measuring your program – don’t fall into the data quality denial trap – identify the key areas (KPI’s) where useful measurement can contribute to a balanced score card that reflects how well the program is being executed. Think about KPIs that can point to the quality of the data – focus on the standard facets of data quality – timeliness, consistency, completeness and accuracy
  • Examine the operating model you have in place for stewardship - to what extent can it be made more effective and efficient by driving the rights issues to the right experts – in my opinion the stewardship model needs to be n-tiered in line with the back to front alignment of traditionally asset management businesses
  • As you develop and hone the standards and policies, the underlying process and procedure will start to snow-ball and it will become increasingly difficult to achieve the oversight and accountability that all governance programs require to be successful – to that end you will need to consider how technology can help support and frame your program, but remember technology is not a panacea to the ills of data governance and quality
  • For every issue, exception and concern raised through the program start tracking the root cause – this really does require a good underlying collaboration tool

Moving from the level of “defined” and onto “pro-active” and “predicative” will seem at face value to be relatively easy, but is very rarely achieved, in my opinion this is generally culture related – some of the key elements in moving onwards and upwards is buying into the continuous improvement principle – if this is not a core value in your firm you will find it difficult to progress in any meaningful way

So what are the key elements moving your program to the highest levels of maturity?

  • You need complete (firm level) buy-in to the concept of continuous improvement – with the appropriate feedback loops designed into your processes to ensure this becomes a core tenet in your program’s modus operandi
  • You need a specific set of activity centred on reviewing the root cause of issues being surfaced, such that they are being feed into the continuous improvement cycles for the relevant processes
  • Your master data plan and data dictionary will be seen as living breathing entities, that are constantly being updated and reviewed in line with the changes in your BAU operating models – these artefacts must never become stale. I often find this is the easiest way to demonstrate to a firm that their program is still in the “defined” stages of maturity, when they might argue otherwise
  • Your program will be making correct and efficient use of technology to empower and enable the data quality management process, supporting the people (stewards) to apply the governance
  • Your data architecture will be coherent and well designed for your organization and how it does business – I find discussion on architecture and the correct use (or not) of MDM, warehouses, marts, hubs, silos etc can be fraught with generalisms and so I will avoid pontificating on what I consider good architecture

When you are able to demonstrate that your program is constantly being tuned and refined, that you have demonstrable audit-trails, and your people, processes and technology are working in harmony, you are well on the way to achieving a highly predictive and mature governance program.

Before signing off of this 10 blog series, remember to keep your eye on the ball – think about the green grass on the other side of the river – the reason we focus so heavily on applying good governance to client facing investment product data is because data is the oil in the sales engine! Feed it with bad data and the engine will start to seize up…..and a business without sales has no future!

1 Comment | Data Quality | Tagged: , , , , , , , , , , , , , | Permalink
Posted by Ronan Brennan

Setting up a governance program for effective management of investment product master data – Part 9 – Technology Frameworks

March 12, 2013

This is the penultimate post in a series of blogs on setting up a governance program for the effective management of investment product data, in this blog I will explore the importance of technology frameworks.

Investment product data quality is determined by: Completeness, Consistency, Timeliness and Accuracy – but to solve data quality  you need to consider: People, Process and Technology!

People Process Technology

Implementing a formal program of data governance and effective stewardship requires investment in supporting frameworks that empower people to apply the process.  While technology is not the solution to data quality– it has a really important role, and that is to provide a structured framework that empowers the stewards (people!) to apply the process!

Remember technology and your IT department cannot and will not solve your data quality problems – it’s role is to support and frame the process such that the people can do their job effectively.

The aspects of data governance, and of the data quality management process, where technology plays a key role are as follows:

  • Automation of data quality checks, ideally with a business intelligent rules engine. There are many generic DQM/EDM solutions on the market – think about a best of breed for the niche you are in though – they will deliver a greater ROI. Ensure your business rules engine is capable of schedule management, workflow structures, validation, reconciliation, transformation and derivation – ideally choose one with a Domain Specific Language that allows custom rule engineering
  • Effectively measurement of the process and reporting meaningful and actionable information – be that in the form of traditional MIS, KPI’s, Balanced Scorecards or bespoke dashboards. Operational oversight, trend monitoring and feedback loops are key elements in driving  a process to maturity (see next post in the series)
  • Assignment and delegation of ownership and accountability
  • Exception management, alerting, reminding and escalating data quality problems
  • Data mining and reporting
  • Critical to all processes under the remit of the governance program is that they are repeatable, automated and systematic – with a clear audit trail that ties stewards, to data exceptions, to historical temporal views of the platform

Remember though, the key role that technology plays is in providing a framework that empowers the stewards to apply the governance strategy, while allowing the governance function to oversee the application of the strategy.

In the last post of this series I will look at how to drive your governance program from day-care to maturity….

2 Comments | Data Governance, Data management, Data Quality | Tagged: , , , , , , , , , | Permalink
Posted by Ronan Brennan

Setting up a governance program for effective management of investment product master data – Part 8 – Data Dictionary

March 6, 2013

This is part 8 of a series of blogs on setting up a governance program for the effective management of investment product data - in this blog I will explain why building and maintaining a data dictionary is probably one of the most important factors in the success of your program.

Like many business buzzwords, data dictionary means different things to different people. The common thread is that the dictionary is an inventory of the data items being consumed or produced within a specific defined business unit or process.

Why do we create them? Again, there are many reasons – but the most prevalent one is to bring a common understanding to play within a specific environment such that everyone is speaking the same language when it comes to data. Data management projects live and die by the quality of their data dictionaries because even within small teams you can have wildly different nomenclatures in existence for what seems at face value very simple, easily understood data items.

Before I get onto what makes up a data dictionary I would like to clear up a couple of misnomers I often come across:

- A data dictionary is not a document. Documents are two-dimensional, while data dictionaries work across many planes. They are best represented in a relational database, or if needs must, a set of interrelated Excel worksheets.

- A data dictionary is not a project resource – yes, every data management project needs a dictionary, but as a resource it has a life outside of the project. You do not create a dictionary to serve the needs of a project only – the dictionary is also required within the business-as-usual activities that come into play post a project delivery i.e. it is a resource that requires and demands constant attention, updating and refinement.

So what is commonly found in a data dictionary? As I mentioned earlier it is a centralised inventory of information on data items/fields that describes in detail the data items semantics, how the data relates to other data, where the data is consumed, where it is processed and from where it is sourced. The dictionary should also describe the correct format and syntax for each field.

So for each entry in the dictionary I would expect to find the following

- A specific unique name for the item

- A clear definition of the data items meaning, including references to other common/aka names for the item

- A list of all “consumer” entities and processes that consume/use this data item

- A list of all the “suppliers” or source systems that produce this data and deliver to processes downstream

- Specific mention of any master rules for choosing correct source system for specific situations

- A list of all business rules applied to the data item as part of any data quality management process that touches the data

- Reference to stewards or stewardship teams that are responsible for the management of the data

- Reference to subject matter expert(s) who can deal with questions about the data item

- Detailed syntax specification for the data item – including type, structure, format and example values

- Good dictionaries allow users enter and update specific notes and references à la a wiki

If you have constructed your data dictionary using a database then you can easily provide very helpful alternate views of the dictionary for example:

- Show all data items consumed by process X

- Show all business rules

- Show the data items touched by Rule Y

- For data item Z show all sources

- For data item R show all consumers

- and so on…

More advanced dictionary implementation have an integrated audit trail with the live system that can instantly show as-of  transactional views i.e. the dictionary and the real-world systems it relates to are integrated.

So how does one build the dictionary? In MoneyMate we build them out using a SIPOC process in reverse [COPIS]

- So we start off identifying all of the consumers of information

- From here working out what outputs are consumed by each consumer#

- From here working out which processes deliver the outputs

- From here working out which inputs are used in each of the processes

- Before finally identifying the source/supplier systems producing the inputs

A critical element of the COPIS/SIPOC analysis is identifying where certain data items have multiple source systems – in these cases we need to carefully specify the master data rules that indicate which source is correct for the variety of situations that dictate different usage of the data.

Examples of this problem would be:

- You could have multiple back-office providers which means your daily NAV could be flowing from multiple parties/systems

- You could also have different legal structures in play that have different statements of record for different data types e.g. for holdings you maybe using the accounting book of record for your mutual funds but for managed accounts you are taking data from your investment records.

- You could have standard source of performance for all in-house funds, but for sub-advised you take data from the sub-advisor

Clearly the dictionary needs to capture all of this information in a well structured manner and allow for specific notation of the master rules for each item which has more than one source.

So hopefully you have a better understanding of what a data dictionary is, what it contains and why it is needed.  If you have anything to add yourself – send me a PM or comment below.

Next up in the series is a review of the role technology should play….

4 Comments | asset management, client reporting, Data Quality, Technology | Tagged: , , , , , , , , , , , , , , , | Permalink
Posted by Ronan Brennan

Data governance – Part 7: Master Data Plan

February 26, 2013

Setting up a program for effective management of investment product master data This is part 7 of a series of blogs on setting up a governance program for the effective management of investment product data - in this blog I will briefly consider the importance of developing a master data plan (MDP).

There are lots of definitions for ‘master data plan’ in use today,  what I am referring to specifically is the intersection of the data governance strategy, standards and policies with the physical data. The International Foundation for Information Technology have defined ‘Master Data Plan’ as “An ordered or sequenced set of clearly defined and governed Tasks, Activities or Work that are often date and/or time bounded and which exist to facilitate in the strategy, delivery or operations of one or more specific Master Data Items or Entities.“  This is a reasonable definition – it is the overall plan that brings the strategy, standards and policies together to form a coherent plan for managing the data in scope , with specific execution detail specified in the process and procedures. If we consider the previous posts in this series of blogs, what we doing at each stage is effectively building up the layers of the MDP.

Why is an MDP important though? Because without it you can lose that centralized holistic view of the moving parts – which needs to exist to ensure all the various actors within the program are operating coherently and toward a common outcome. It is the constantly evolving project plan that supports and feeds back into the overall program, driving the correct set of activities to achieve the strategic goals for the program.

What is the data dictionary and how does it come into play with the MDP? Earlier, I referred to the MDP as relating to “the intersection of the data governance strategy, standards and policies with the physical data” – well the data dictionary is what defines the scope and breadth of the physical data on a continual/moving basis – in fact we will dig into the specifics of the dictionary in the next instalment of this series of blog posts…

2 Comments | asset management, Data Governance, Data Quality | Tagged: , , | Permalink
Posted by Ronan Brennan

10 Things worth remembering about Solvency II – Part 1

February 21, 2013

JD has some great insight here on lesser known salient points many S2 practioneers should take note of 10 Things worth remembering about Solvency II – Part 1.

Leave a Comment » | asset management, client reporting, Data Governance, Data Quality, Solvency II | Tagged: , , , , , | Permalink
Posted by Ronan Brennan

Data Governance: Part 6 – Processes & Procedures

February 20, 2013

Setting up a governance program for effective management of investment product master data

This is part 6 of a series of blogs on setting up a governance program for the effective management of investment product data - in this blog I will briefly consider the importance of process and procedure documentation.

In my previous blog in this series, I highlighted why standards and policies are important to the task at hand. Similarly, process and procedure are also key elements of an overall program of governance for your investment product data.

If you consider the statement of your policies and standards as the clear communication of the strategy for your program, the explicit documentation of the processes and associated procedures speaks directly to the execution of the strategy.

A process is an operational workflow description that takes into account starting states, end states, resources, participant teams and individuals who interact at each stage or state in the process – a procedure on the other hand is a simply detailed set of instructions for carrying out a specific task, or part of an overall process.

If you consider the example I used in the standards and policies post:

- Policy: ”the policy in our firm is that all client requests for data must be signed off by compliance“

- Standard: “all requests from clients for bespoke client reports should be logged in the ‘reports-requested’ database by the client service team. Only users with a security role of ‘compliance authority’ will have the capability to approve a request in this database and no report shall flow to a third-party without reference to an approval record in the ‘reports-requested’ database”. 

In this scenario we clearly need a detailed description of the process which starts with the event of a client request being received, ending with the delivery of the report to the client. In between the start and end points we need to clearly document the various valid paths or stages the process would need to pass through – for example, showing the logging of a request for compliance approval – this process document should call out the specific valid (and invalid) paths, stages, resources, systems and people interacting at each stage in the process. Typically, the document will contain a process flow diagram (there are tens of different diagram types) and related verbiage that explains in detail each step.

Within this process we will need a set of detailed procedure documents that explicitly call out the instructions for carrying out specific tasks – for example, you may decide you need to have a specific procedure for calling out how to log a client request into the compliance database.

From my own perspective, the definition of the processes that come under the remit of your program is a far more important task than the documentation of the procedures - get your processes down pat first, and only then start to consider the documentation of your procedures.

Next up I will explore the creation of a master data plan…

2 Comments | asset management, Data Governance, Data Quality | Tagged: , , | Permalink
Posted by Ronan Brennan

Solvency II News: regulators consider easing Solvency II look-through

February 14, 2013

Interesting news on Solvency II Wire blog today Solvency II News: regulators consider easing Solvency II look-through.

Leave a Comment » | Data management, Data Quality, Solvency II | Tagged: , , , , , , , | Permalink
Posted by Ronan Brennan

Setting up a governance program for effective management of investment product master data – Part 5 – Standards & Policies

February 11, 2013

This is part 5 of a series of blogs on setting up a governance program for effective management of investment product data - in this blog I will briefly consider the importance of policies and standards.

So having dealt with the political hot potatoes of getting C-level buy-in, agreeing outline terms of reference and formulating a strategy, it is imperative that the governance team / tzar (depending on the level of autocracy in your firm) specify a set of clear and unambiguous policies.

Policies are required to set out the specific objectives across a range of areas, and they should be firmly rooted in the agreed strategy for the governance program.

For example – an element of the strategy could be “We will seek to apply more control to the process of publishing data into the public domain“. From this aspect of the strategy you may decide to specify certain policies that tie back to that strategic thread, for example “the policy in our firm is that all client requests for data must be signed off by compliance“. Clearly there is a relationship between the strategy and the policy…

The governance team/tzar should set out a range of policies to address the stated strategy. Be cognizant of the importance of achieving early and visible wins for the program i.e. do not spend time generating piles of documents to the detriment of delivering visible results. There will be plenty of time to broaden the program once you have some committed champions who not only believe in what you are trying to achieve but can acknowledge the actual accomplishments.

Once you have firmed up on a small set of policies that  address the key elements of your strategy, the next stage is to start formulating the standards that will drive adherence to the policies – so following the above example – where ”the policy in our firm is that all client requests for data must be signed off by compliance“, one of the standards could be “all requests from clients for bespoke client reports should be logged in the ‘reports-requested’ database by the client service team. Only users with a security role of ‘compliance authority’ will have the capability to approve a request in this database and no report shall flow to a third party without reference to an approval record in the ‘reports-requested’ database”.

If you are struggling with discerning your policies from your standards there is a very good diagram here that helps communicate the differences.

The key takeaway here is to keep your initial set of policies small, and in particular relevant to the program strategy. Once you start to develop your policies into standards, and from standards into formalized processes and procedures the workload snowballs at a rapid rate and you are quickly in a place where you are just spinning your wheels and making no visible progress.

Next up I will briefly explain the movement from policies and standards, to process and procedure…

2 Comments | asset management, Data Governance, Data Quality, product master | Tagged: , , , | Permalink
Posted by Ronan Brennan

« Previous Entries
Follow

Get every new post delivered to your Inbox.

Join 26 other followers