A ‘Benefits-driven’ approach to MDM
www.wipro.com
Sureshbabu Balasubramanian
Table of Contents
Introduction.................................................................................................................................................................................3
Current approaches and their shortcomings..............................................................................................................3
Current MDM approaches.......................................................................................................................................................3
Key shortcomings.......................................................................................................................................................................3
Defining Benefits-driven MDM (BD-MDM)..................................................................................................................4
Value of ‘Benefits-driven’ MDM..........................................................................................................................................4
Putting BD-MDM into practice..........................................................................................................................................5
Phase 1: Blueprint..................................................................................................................................................................6
Business case for MDM (Benefits identification)..............................................................................................................6
Building the roadmap (Benefits planning)...........................................................................................................................6
Phase 2: Prepare.....................................................................................................................................................................8
Create baseline (Benefit tracking).......................................................................................................................................8
Equipping the IT........................................................................................................................................................................8
Phase 3: Implement..............................................................................................................................................................8
Considerations for MDM components (Benefits realization)........................................................................................9
Phase 4: Measure (Benefits evaluation).............................................................................................................................9
Conclusion....................................................................................................................................................................................9
Enterprises today understand that master data is critical to helping them connect with their customers across channels, seamlessly collaborate with their vendors
or pursue growth through acquisitions. However, there are a lot of examples of MDM programs either being abandoned due to a lack of demonstrable value
or are being truncated to pilot IT initiatives that never see wider enterprise adoption.
On the contrary, multiple successful MDM implementations bear testimony to the fact that MDM can be the bedrock on which enterprises transform their
operations or gain powerful insights into their business. The difference primarily stems from how these MDM programs have been run – from the choice of
projects, to the architectures to the kind of governance structures being adopted.
We believe that putting ‘benefits’ as the centrepiece to making various decisions in the MDM program can help define an approach that not only ensures wider
adoption, but also ensures demonstrable value to the enterprises.
Current approaches and their
shortcomings
Current MDM approaches
Currently most MDM implementations are:
1.Data focused – Typically there are two key areas where MDM is
applied with data as focus.
• Data Quality – MDM solutions are brought in with a view to improve
data to be reflected in business reporting or operations.
• Data Consolidation – A typical case in point being customer MDM
where a single global identifier needs to be built for a customer across
multiple business units/functions etc.
Though the attention to data is certainly important and key to MDM
success, these projects still fail to answer questions around ‘quantum of
work’ e.g. “how much data needs to be cleansed” or “do I consolidate
data from every customer touch point”. These challenges point to lack of
clear definition of ‘benefits’.
2.Technology driven – Technology driven MDM programs address the
following areas:
• Synchronization – Idea is to build a system of record that can become
a single source of truth for various business entities across the enterprise.
• Data Registry – The need here is to build matching engines that match
and assign unique identifiers to business entities across functions or
BU boundaries.
These projects tend to become pure tool implementations that fail to
apply non-technology components of governance, change management
etc., in true vigour to benefit the enterprise. These implementations fail
to make the business the true owner of master data.
3.Process focused - In certain cases, MDM programs are linked to
specific business process improvements. Arguably, a better
approach when compared to a data or technology focused view to
running the MDM projects; however, it still is likely to suffer from a
narrow-sighted view of what a ‘customer’ or ‘product’ is, which in turn leads to
multiple silo initiatives that try to solve the problem for different
business processes.
Key shortcomings
The themes of failure across the above discussed approaches are
consistently the same:
• Lack of business sponsorship - Because of the nature of the MDM
programs where business users never really see MDM in action (typically
most business users don’t have a user interface to MDM), it becomes a
challenge to sell MDM as a valuable investment.
• Lack of demonstrable value - In few MDM projects which are tied
to business process or reporting – no measures are available to quantify
how MDM contributed to the project’s success.
3
• Function / Department focused efforts – Though it is a good idea
to start small, function focused MDM efforts (e.g. SCM-MDM or Sales
& Marketing – MDM) are rarely able to break beyond the confines of
these departments due to a lack of clear articulation of the ‘enterprise
vision’ upfront.
• IT owned – Lastly, the often sighted problem of MDM being perceived
as being owned by IT (when the goal is to make business own master
data) only makes it more difficult to pursue the “if you build they will
come” philosophy.
is nearly impossible to arrive at, resulting in either ‘boil the ocean’ or ‘skim
the surface’ approach.
Through the rest of the paper, we will provide specific instances of how
a ‘Benefits-driven’ approach will help us guide the implementation while
keeping a firm grip on the results to be demonstrated to the business.
This in return will ensure that MDM programs can be successfully adopted
across the enterprise.
Value of ‘Benefits-driven’ MDM
Defining Benefits-driven MDM
(BD-MDM)
The guiding principle behind BD-MDM is to use the Benefits
implementation
process
to
guide
MDM
implementations.
As
is
evident
from
the
diagram
below,
the
MDM
implementation
lifecycle
closely
mirrors
the
process
of
Benefits implementation.
During the course of an MDM implementation, various decisions around
technology, architecture, process and organization (governance/operations
etc.) are required to be made. These decisions, many a time, are made
without a view on the benefits to be delivered resulting in solutions that do
not deliver ‘demonstrable’ results as per business expectations.
Assess
Solution
Prepare
Identify
Evaluate
Benefits
BD-MDM relies on building three key pillars of support that will ensure
a successful MDM implementation. These three pillars are described
as follows:
• Business buy-in – It might seem obvious but many projects fail
precisely due to the lack of support from ‘users’ of master data –
functions/departments, line of business users (outside IT) who actually use the
master data for performing business operations or making
business decisions.
With BD-MDM every MDM implementation (or iteration) is tied to a set
of specific business problems, this means it is easy to identify sponsors
who are ready to support the initiative.
Also, there is emphasis on building baseline metrics with which to
demonstrate value at the end of each implementation, which makes it
easier to sustain the support of business either in funding of projects or
allocation of resources for data governance.
Measure
Implement
‘Benefits-driven’ MDM (BD-MDM) helps organizations to clearly align
MDM capabilities to organizational priorities. It ensures that there is a clear
balance between the short-term imperatives and the longer term goals of
the organization.
Envision
Blueprint
Plan
Benefits-driven MDM
Realize
For example, decisions on the amount of effort/cost to be expended for
improving data quality is a function of the results to be achieved. Without
the end benefits in mind a ‘fit for purpose’ definition of data quality standard
• MDM roadmap tied to business case – With the BD-MDM
approach, the roadmap definition requires a balance of benefits against
MDM capability development – i.e. the expected benefit at each phase is
weighed against expected cost of implementing MDM.
Though it may not always be possible to provide quantifiable ROI, the
approach emphasizes the need to define benefits that are agreed upon
with the beneficiaries. Further in the paper, we provide pointers to building quantifiable ROI for MDM projects.
Small steps but with a vision – Because MDM projects are perceived
more as ‘infrastructure investments’, there is a need to arrange the MDM
implementations as a series of cumulative ‘capability build-outs’ that
deliver benefits at each iteration. However, these iterations need to be
aligned to an overall long term vision that ties to business priorities.
For example, a ‘spend analytics’ focused vendor and material MDM is
considered a good first step on the MDM journey – here the focus might
be purely on reactive data quality. However, the vendor and material
MDM capability built as part of this ‘spend analytics’ focus needs to be
fit into the next step of support for fine tuning ‘procurement process’ –
here the focus might be more on proactive data quality, governance and
process enablement.
4
• IT as an enabler – Lastly it is important that IT plays the role of an
enabler that brings in best practices, platforms (as in data quality or
technology platforms) and learning that enable smooth execution of the
MDM roadmap.
Putting in place a repeatable process for data quality improvement,
bringing in shared resources with expertise in MDM tools and technologies,
playing the advisory role for enabling data governance could be some of the
support roles that IT should play.
Putting BD-MDM into practice
Though the MDM journey is likely to be different across enterprises and
varies widely in scale and complexity, for the purpose of this paper, we
club the MDM journey into 4 main phases of Blueprint (including assess and
envision), Prepare, Implement and Measure.
Assess
Envision
Blueprint
Prepare
Implement
Measure
• Identify Master Data Issues
• IT Landscape & Master Data
Spread
• Identify Possible Business
Benefits
• Build a Business Case
• Identify Champions &
Sponsors
• Measurable Business Case
• Build Buy-In & Sponsor
Benefits
identification
Benefits
planning
• Creating a Conceptual Solution
• Establishing a Rollout Plan
• Evaluating Tool Options
• Prioritize Benefits to build
Roadmap
• Build Solution Vision aligned to
benefits
• Aligning Organization for
Governance
• Building Consensus on Master
Data
• Migrating Existing Data
• Define Benefits Measurement
Metrics
• Build Baseline of Metrics
• Build Support for Global &
Local Data
• Account for Availability and
Access
• Build Solution aligned to
Benefits
• Measure Success of Program
• Measure Benefit Metrics
• Identify New Benefit Areas
MDM lifecycle
Benefits
realization
Benefits-driven MDM
Benefits
evaluation
Benefits cycle
BD-MDM steps
5
This section takes you through the different aspects to consider, useful
techniques to employ during different phases of the program for adopting
the BD-MDM.
Phase 1: Blueprint
Two things characterize the blueprint phase of a program – lack of clarity
on how big is the master data problem, or as a corollary what is the scale
of benefits that MDM can deliver to the enterprise (Benefits identification).
Second – what is most importantly the first step and what needs to be the
roadmap ahead i.e. planning (Benefits planning). In the following sections,
we elaborate on these main characteristics of the Blueprint Phase of the
MDM journey.
Business case for MDM (Benefits
identification)
1.Unearthing the benefits
An assessment of the current data management practices is the first step in
BD-MDM process. There are two related approaches that can be taken to
uncover the MDM benefits.
• Mapping the business processes – is a good way to understand
how the master data is being used within the enterprise. As part of this
exercise, analysts can poll the impact of its poor quality on the business
processes and build a potential list of ‘benefits areas’.
• Analyzing/profiling the data – is the bottoms-up approach to
establish that lack of quality master data is impacting business operations
and decision making. The key benefit areas identified previously can be
substantiated and in some instances new areas identified using profiling.
2.Cracking the numbers
Established statistical and financial measures like IRR, NPV etc. are in
existence to quantify the value of a new project. This paper doesn’t
endeavour to cover them; instead it shall look at what are the areas of
interest to investigate for building benefits.
Typically, you can look at three main heads for demonstrating business
value of MDM:
• Status-quo cost savings – These are typically around reducing existing
efforts for performing a business process or preparing a business
report – e.g. can you show saving in effort required to ‘consolidate
customer sales’ each reporting cycle for doing ‘sales reporting’.
The other one could be to demonstrate reduction in integration &
system maintenance costs due to implementation of a ‘hub-spoke’
model – systems that could be sunset, integrations that could be
discontinued etc.
Typically, vendor and material data fall into head for demonstrating
business value.
• Opportunity costs – This is arguably a difficult one to build. One of
the ways is to demonstrate master data as ‘hygiene factor’. That is, look
at these not as ‘how master data contributes to a positive result’, but
rather ‘what is the negative impact of not having the correct master data’.
For instance, what is lost profit due to inefficient business processes – e.g.
what does it mean to have new production introduction cycle time 30%
less efficient or lost opportunities in spend optimization due to a lack of
cross-BU vendor visibility.
New business capabilities enabled by MDM definitely need creative
efforts and possibly a lot of review with business stakeholders. e.g.
potential up-lift from cross-sell, up-sell opportunities requires
considerable inputs from sales teams.
• Cost of non-compliance – Given the various regulations around
customer data privacy, black listed vendor and environmental/safety
regarding materials etc, there is an opportunity to demonstrate cost
associated with risk of non-compliance by way of fines and penalties.
This might be most relevant if your company is in financial services (acts
like BASEL II, KYC etc. are relevant) or manufacturing (OHS, GHS etc.)
Ability to build a convincing business case based on the above will vary
by enterprise, but you can keep a few things in mind to smoothen the
process. Look for metrics/business KPIs currently used and trusted within
the organization. Tying your business case to these is much more effective
and generally more acceptable.
Lastly, verify your numbers with business users and gain their consent
before floating it out to a broader audience.
3.Knowing your potential sponsors
The term ‘sponsors’ is loosely used here to include the ‘key
stakeholders’. If you have been able to make an assessment of current
master data landscape and identify the opportunity areas for MDM, you
have probably identified the biggest beneficiaries of MDM i.e., the functions,
business units or regions that stand to gain the most. These beneficiaries
are the ones who you need a firm buy-in from, to ensure they contribute
their resources to the success of the program – either as sponsors or as
key stakeholders.
Building the roadmap
(Benefits planning)
1.Mapping the benefits
One of the tools that is useful for mapping benefits to the required IT
projects (in this case MDM) is Cranfield University School of Management’s
“Benefits Dependency Network”. A complete discussion of the “Benefits
Dependency Network” (BDN) is beyond this paper, however, we use
an example here to highlight how BDN can help establish linkage of the
projects to the business drivers and the set of changes required in
business/IT to attain MDM related benefits.
The BDN is a good tool to understand the linkage of the IT
projects to underlying business-drivers; it also establishes the required
‘organizational changes’ outside the IT environment to enable a realization
of the benefits. In the context of MDM, BDN shows the required changes
in data ownership, data management processes and skills enablement.
6
For instance, the below BDN example shows how the Customer and
Product MDM projects might relate to a retailer’s business drivers. It
also shows the required changes needed in data management – new
classifications systems to be adopted, changes to data ownerships and
realignment of data management processes for product and customer.
While the ‘enabling changes’ are changes that might be necessary to be
delivered as part of the MDM project, the ‘business changes’ might be part
of a broader ‘organizational change management’ track of MDM.
While the blocks on the right help in clarifying the business case for
MDM, the blocks on the left can be used in the process of developing a
solution roadmap.
Program roadmap
IT enablers
Enabling changes
Redefine
customer
segments
Customer master
hub
Simplified a/c
mgmt processes
Business case
Business changes
Product master
hub
Ensure clear
ownership of
data elements
Standardized
product
classification
Business drivers
Create
targeted
campaigns
Offer services
that span
channels-order
online, service
in store
Offer
differentiated
customer
support
Release time
for data mgmt
from cleansing/
standardization
Benefits
Increased
customer
satisfaction/
brand loyalty
Improved
campaign
effectiveness
Increase
online
presence
Growth in new
geos/business
models
Standardize
new product
Introduction
Develop
channel
specific vs
cross channel
products
Improved
product
(line)
profitability/
reduced
spend
Consolidation/
cost reduction
across BUs
Reduce
category
spread
Benefits Dependency Network
7
2.Prioritization of projects/benefits
Building of a solid roadmap relies on balancing of the business benefits
with the feasibility of MDM solutions. Ideally, the MDM solution is built-up
gradually in terms of complexity (consolidation to harmonization styles),
while delivering benefits at each stage.
Some of the key criteria to consider, outside ROI/benefits are:
• Scope of benefits – Benefits that have broader enterprise coverage
deserve better representation.
• Measurability of benefits – For purposes of demonstrating value
addition of the MDM program, projects that have more measurable
benefits should be favoured.
• Magnitude of change (organizational) – Projects that are more
disruptive should be given a lower priority.
• Cost of re-work – In certain cases it might be worth the effort to
implement a more complex MDM solution upfront rather than retro-fit
the solution at a later stage. e.g. if the cost of cleaning data downstream
in MDM is too high, as compared to cleansing at source, it might be
worthwhile to invest in building data quality web-services to be used
by target systems in early phases. Case in point might be customer
self-registration scenarios in retail industries.
• Complexity of implementation – The ‘size of the data model’,
‘number of integrations’, ‘type of integrations’, ‘transactional vs. analytical
styles’ all contribute to determining the complexity of an implementation.
Let us consider a prioritization case where we start with consolidation of
product and customer data while demonstrating improvement in spend
analysis and customer profitability reporting. Of course, this does require
that accompanying ‘enabling changes’ are put in place – in the current
example, new classification of products and new segmentation rules for
customer etc.
3.Tying it to the solution vision (Conceptual Solution)
An important part of the blueprinting phase of the MDM project is to
develop a solution vision that demonstrates the end-state architecture
expected from the program. The roadmap ties into the solution vision to
detail out the interim steps through which end-state architecture is to be
achieved. This step-wise development of the end-state solution ensures
that the program can be developed iteratively while continuing to deliver
short term benefits.
Taking the BDN example - if building a centralized product master and a
harmonized customer master were to be the end-state, you would also
indicate what the initial steps of the architecture would be. It could be
‘consolidation architecture’ for customer, while a harmonization
architecture for product. Similarly, the extent of downstream integration
would vary.
The important thing to consider here of course is the fact that the
suggested architectures would map to the prioritized benefits to be
delivered at each stage of the program.
applications. In the BDN example, if changes to existing reporting
applications were not done in sync with MDM timelines, you pass an
important milestone in your MDM journey with no benefits to show. This
is both an exercise in managing stakeholder expectations and influencing
stakeholder decision making!
Phase 2: Prepare
It is recommended practise to have a prepare phase precede every
implementation cycle, to align organizational resources and building a
baseline. In this section, we talk about what needs to be done from a
benefits perspective.
Create baseline (Benefits tracking)
An important first step for BD-MDM to succeed is to create a
baseline. This baseline obviously needs to be established against a set of
measurable metrics. Definition of business KPIs might be accomplished as
part of the business case development; however, additional metrics around
data quality, process quality etc. might be required to capture different
aspects of impact. e.g. for the case of centralization of customer data
management apart from business KPIs dealing with ‘cross-sell/up-sell’,
you might want to capture ‘completeness of customer data’, ‘accuracy of
customer data’, ‘cycle time for on-boarding of new customer’ etc.
These measures, if taken thoroughly, will feed directly into data governance
KPIs and become a method/technique to ensure on-going effectiveness
of MDM.
Equipping the IT
We suggest IT use the prepare phase to assess the kind of resources
the business would need to bring, whether it is for data cleansing or for
participation in defining governance and technical solutions. A clear
‘engagement model’ should be available at this stage to help business
stakeholders understand their roles. This would also be the phase to staff IT
resources that would support the MDM rollout. Preparations for initial data
load in terms of validation of data quality tools at hand and estimation of the
manual cleansing effort are also key considerations at this point.
Phase 3: Implement
The implementation phase of the program is about creating technical,
process and organizational solutions that help realize the defined benefits
during the blueprint phase of the program.
Rather than focus on the SDLC cycle of a MDM project, we focus
here on the different aspects (or streams of work) relevant to MDM
projects and what considerations are necessary from a “Benefits-driven
MDM” perspective.
One of the challenges typically encountered in MDM programs is that
the program timelines are in many instances misaligned with downstream
8
Considerations for MDM
components (Benefits realization)
Phase 4: Measure
(Benefits evaluation)
1.Scope of the Master Data model and quality
One of the central questions from an MDM standpoint is what is
‘Master Data’? Though this can be answered rather simplistically by
saying anything that is used across functions or geographies, it avoids
answering the implicit question of ‘scope’. To explain – since master data is
something that is common across functions/geographies, question becomes
what functions/geographies have you looked to define ‘common global’?
The measure/sustenance phase of MDM is typically characterized by the
need to identify the areas of improvement in existing implementations and
identifying new areas of benefit for existing MDM solutions. Unfortunately,
this phase of the project is most neglected in the MDM journey. For an
organization that has just started on MDM this phase could be critical, to
prove that you have indeed delivered on your promise. As MDM doesn’t
end with a single implementation, this demonstration could mean the
difference between continued sponsorship versus a one-off project.
The general principle to apply in these cases is ‘design for future,
implement for present’ – this implies the logical model for Master Data
should be designed as broadly as possible, but implementation – i.e. data
cleansing, standardization and loading should be done for the most immediate
needs only.
The important activity with regard to demonstration of value is
measurement of benefits, and more importantly convincing stakeholders of
the need to measure the benefits. The measures obviously fall back to the
metrics that were captured as part of the creation of the ‘baseline’ – both
business KPIs and the data related metrics.
2.Data governance (processes, KPIs and organization)
The measurement of these benefits could result in either improvement
of an existing MDM implementation or adoption of the said solution on a
broader level within the enterprise.
Establishing data governance structure and processes require changes in
existing organizational data management practices and hence requires
careful consideration of ‘Organizational Change Management’ (OCM).
More radical the change (e.g. move from a decentralized creation of items
to a centralized model), more likely the resistance to change within the
enterprise. This implies that data governance changes need to tie closely
with the benefits to demonstrate the necessity of changes to data stewards,
data owners and process owners.
Use of BDN as a tool helps clarify this dependency. Taking the previous
BDN example – centralization of product data management (as against
a federated or de-centralized model), it clearly emerges as an ‘enabling
change’ demonstrating it as a pre-requisite for attaining ‘enterprise view
of product’.
3.MDM architecture
While in most cases picking consolidation architecture (as against
harmonization or centralization) might be the natural first step in
building an MDM solution, bringing in the view of the benefits might force
a different choice. Example: For the case of centralization of product data
management, it is apparent that end-state is ‘centralization’; however,
questions around what approach/architecture needs to be adopted to build
the ‘consolidated initial load’ needs to be answered.
Conclusion
Given the tough economic climate in which most enterprises find
themselves today, it is important that MDM program owners be able to
articulate the value of MDM to the enterprise. More significantly, implement
projects that deliver value aligned to business drivers of the enterprise. A
Benefits-driven approach to MDM (BD-MDM) can ensure that you have a
sound case to begin the MDM journey, and an equally robust roadmap that
delivers consistent benefits.
The BD-MDM can also serve as the guiding force for numerous decisions
ranging from data model, governance to technology and architecture. A
conscious and consistent view on benefits throughout the different phases
of MDM can ensure success of the program.
Similarly, questions around ‘real-time vs. batch mode’ integration for
syndicating Master Data or providing data quality services can be
conclusively answered only if you know the benefits you are chasing. In
the case of customer master data driven to ‘customer reporting’ – it might
make more sense to adopt batch modes when compared to ‘real-time’. On
the other hand, ‘real time’ becomes a pre-requisite if the near term need is
‘real time de-dup’ on a ‘self-serve customer portal’.
9
References
• “Managing the Realization of Business Benefits from IT Investments” - http://www.som.cranfield.ac.uk/som/dinamic-content/research/documents/peppardwarddaniel07.pdf
• “Project management: business cases and gateways”- http://www.accaglobal.com/content/dam/acca/global/pdf/sa_apr11_p3_projectmgt.pdf
• Doherty, N. F. et al. “Towards an Integrated Approach to Benefits Realisation Management – Reflections from the Development of a Clinical Trials Support
System.”
• “Benefits management and benefits realization” - http://www.bereal.salford.ac.uk/N/pdf/Literature-BenefitsRealisation.pdf
10
About the Author
Suresh is a senior consultant at the Wipro MDM Centre of Excellence with over 10 years of MDM experience. He works with Wipro clients across industry
verticals in the areas of MDM business case, strategy and architecture. Prior to Wipro, Suresh was at TIBCO where he was an architect working on the TIBCO
Collaborative Information Manager.
About Wipro Council for Industry Research
The Wipro Council for Industry Research, comprised of domain and technology experts from the organization, aims to address the needs of customers by
specifically looking at innovative strategies that will help them gain competitive advantage in the market. The Council, in collaboration with leading academic
institutions and industry bodies, studies market trends to equip organizations with insights that facilitate their IT and business strategies. For more information
please visit www.wipro.com/insights/business-research/
About Wipro Ltd.
Wipro Ltd.  (NYSE:WIT) is a leading Information Technology, Consulting and Outsourcing company that delivers solutions to enable its clients do business
better.  Wipro delivers winning business outcomes through its deep industry experience and a 360 degree view of “Business through Technology” - helping
clients create successful and adaptive businesses. A company recognized globally for its comprehensive portfolio of services, a practitioner’s approach to
delivering innovation and an organization wide commitment to sustainability, Wipro has a workforce of 140,000 serving clients across 57 countries.
For more information, please visit www.wipro.com
11
DO BUSINESS BETTER
www.wipro.com
NYSE:WIT | OVER 140,000 EMPLOYEES | 57 COUNTRIES | CONSULTING | SYSTEM INTEGRATION | OUTSOURCING
Wipro LTD, Doddakannelli, Sarjapur Road, Bangalore - 560 035, India
Tel: +91 (80) 2844 0011, Fax: +91 (80) 2844 0256
North America South America United Kingdom Germany France Switzerland Poland Austria Sweden Finland Benelux Portugal Romania Japan Philippines Singapore Malaysia Australia
© Copyright 2013. Wipro Ltd. All rights reserved.  No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any means, electronic, mechanical,
photocopying, recording or otherwise, without express written permission from Wipro Ltd. All other trademarks mentioned herein are properties of their respective owners. Specifications
subject to change without notice.
IND/PMCS/WIPRO/SEP 2013 - NOV 2013