Canadian Tire strategy for getting in control of Master Data
Ayad Azzarouk
Enterprise Architect
Canadian Tire Corporation
ayad.azzarouk@cantire.com
Agenda
•
•
•
•
•
Introduction
The Strategy
Supporting components of the strategy
– Master Data Governance Policy
– Business Data Model
– Architecture
– Master Data entity change plan
Where are we now?
Q&A
2
Canadian Tire
•
•
•
•
•
Canada's largest supplier
of unisex apparel, offering
an extensive collection of
business casual, weekend
and work wear and
accessories for men and
women. more than 325
stores across Canada
Founded 1922
Canada’s largest retailer with more than 1,000 stores and gas
bars coast-to-coast
Business operations in most major Canadian cities
48.000 employees working in the retail, financial services,
petroleum and apparel businesses
10 Bill. CAD (~6.9 Bil. €) in turnover. 558 Mio. CAD (~390 Mio.
€) in earnings.
Canada's largest
independent retailer of
gasoline with more than
250 gas bars and more
than 55 Simoniz car
washes in Canada.
Offers a variety of
financial products,
primarily branded credit
cards, that give Canadian
Tire customers a choice
of payment options, as
well as increased loyalty
rewards.
Automotive parts specialty
chain with 47 stores
designed to meet the needs
of major purchasers of
automotive parts professional automotive
installers and serious do-ityourselfers.
More than 455 stores from
coast to coast. Offering
customers a large selection
of national and retail
brands within automotive
parts, accessories and
service; sports and leisure
products; and home
products.
3
3
Canadian Tire interest in MDM
Master data:
Is a key component of doing business; it is employed throughout Canadian Tire processes from merchandising to
procurement to point of sales transactions. It describes our core business entities (eg. Customers, vendors, partners,
products, materials, locations, employees, chart of accounts, codes, etc.). Master data is considered to be descriptive
and relatively static compared to transactional data.
Master data management (MDM):
Is the practice of gaining control of the organizations most important and commonly shared enterprise information
assets.
MDM solutions: Are designed to manage master data throughout operational transactions and maintain a single
4
operational view, which serves as the system of record for this data.
Challenges affecting business on all levels
Strategic
Tactical
Operational
•
Master Data is currently not an asset that provides agility and
flexibility to the business
•
Running out of numbers for Vendors, Products and Store –
intelligence embedded in numbers.
•
Effective decommissioning of legacy applications is dependent on
removing Master Data dependencies
•
Master Data ownership is not defined or appointed
•
There is a lack of common ratified business definitions and business
rules for Master Data
•
There is a tendency to select tactical solutions over strategic
solutions leading to rework
•
There is a lack of a single authoritative source for Master Data
•
Not all relevant /required data are captured.
•
Many Master Data problems are mitigated with an increase in
operational costs (manpower)
•
The same Master Data is being manually created and maintained in
several systems leading to data inconsistencies
5
Operational Challenge
Example
123-12-12-1 WD-40 oil 250ml can
On deal as a 400ml can, Same product number
Jan-07 to Apr-07
Brampton and
AJ Billes
Rework vs. receiving
15.7%
250 ml 400 ml
Goods received
Boxes are bigger and
cannot be loaded on
truck. Products Left On
Dock.
Picking
Warehouse worker has
to know that the 400ml
can is on deal.
Otherwise the 250ml
can is picked and
packed.
Transportation
Number of pallets increases
due to volume – same order
amount. Rework fixing overheight, overhanging pallets.
Dealer
The dealer’s warehouse
cannot fit the larger size
– manual work and
repacking.
6
Technology challenges
•
•
•
Master data is embedded in business applications which were defined to suit legacy
processing requirements, and further complicated by 2 facts:
– many of the application exists on technology that are not easily modified to support new
requirements. ( existing inter-dependency and constructs)
– no measured advantage or disadvantage for a business initiative to take on the effort to
manage the change on an organizational scope
New applications are begin introduced but implementations are constrained by the above
challenges, resulting in bolt on and EUC solutions to address functionality and data gaps.
A business transaction system package was acquired to fulfill Canadian Tire MDM enterprise
needs, however:
– The package and implementation addresses mainly the merchants aspect.
– The implementation does not have the capacity to tackle the Master Data Management
practice.
7
Interdependency multiplies the complexity, scope, and cost of projects
IMS Application Vendor data usage
PROD
(Product
Database)
VEND
(Vendor
Database)
DIST (Physical
distribution
(stores)
database)
P.O. Receiving
System
Accounts
Receivable
Purchase Order
System
APPT
(Appoint
ment
Database
)
RTAP
Warehouse Control
System
POXR
RSCH
Scheduled Receiving
System
TRLR
(Trailer
Database
)
PROF
HAZR
(Hazardo
us
Informati
on
Database
)
Depot Special Order
System
SPRD
SVND
(Special
(Special
Orders
Orders
Merchand
Vendor
ise
Database
SORD System
)
(Special Product)
Orders
Merchand
ise
System)
STRM
(Store
Database
)
TRIP
System
Trailer Tracking
System
Merchandise Control Claims
System
VMST
(Vendor
Master
Database
(Flex
Billing))
Notice of Returned
Goods System
Flex
Billing
Accounts Payable
Merchandise
System
Inbound
Flow
TABL
(Product
System
Tables
Database
)
ADJH
(AdjustaCard
Database
)
Adjusting Returns
System
TRIP
(Transpor
tation
Trip
Manifests
Database
)
WHIN
(Warehou
se
informati
onproductio
n/errors
Database
)
MCTL
(Merchan
dise
Control
Database
)
EPAC
(Emergen
cy Pack
Slip
Database
)
FENT
(Flex
Entry
Database
)
TSPA
(Scratch
Pad
Database
)
Deal System
DLTR
(Deal
Transacti
on
Database
)
CDCS
PART
(Automoti
ve Parts
Database
)
Cost Of Sales Maintenance
System
Depot Product
Maintenance (PMBASIC)
System
DEAL (Deal
Database)
PCIC
(Product
Class /
Item
Class
Control
Database
)
Corporate Product
Maintenance (PMBASIC)
System
WSCH
(Warehouse
Scheduling
Database)
PROH
8
The bad news is:
There is no silver bullet for master data challenges.
We can’t buy a technology that will fix the problems.
The good news is:
We have a strategy to get in control of Master Data
9
Control of Master Data at Canadian Tire
Organizational Scope
The original scope was defined as all of Canadian Tire, including participants from all
SBU’s (Corp, CTR, PartSource, Petroleum, CTFS & MWW).
• This scope was tested using the following criteria:
– The level of Master Data currently shared across SBUs
– Plans to share data across SBUs based on the strategic direction of Canadian
Tire
• It was determined that data was, to a large extent, not shared or planned to be
shared beyond CTR, CTREL and PartSource and there was no indication from the
corporate strategy that this would be a requirement in the near future. Hence, the
organizational scope for the project was adjusted to CTR, CTREL and PartSource.
Original Scope
CTR
MWW
PartSource
Petroleum
CTFS
Corp
Decision
SBU Focus
CTR
No apparent strategic need to share master data
across all SBUs to date.
Corp
PartSource
Petroleum
10
Master Data Entity (MDE) Scope
•
Three key areas were identified as the highest priorities for the project to include in
its scope. They are:
– Product
– Vendor
– Store
MDE Candidate
Competitor
Product
Organization
Store
Customer
Vendor
Dealer
Warehouse
Employee
Trade Area
As of the
2nd
MDE Focus
Assessment
Product
Store
Vendor
Assessed by:
- Usage across systems & processes
- Priorities (Risk, Benefits, Complexity)
half of 2009 Customer and Supply Chain Nodes are becoming business priority
11
Implementing A MDM practice
Implementing Master Data Management successfully requires:
– Master Data ownership and accountability must be clearly defined.
– Master Data must be commonly defined amongst those who use the data.
– Master Data needs to be managed and used consistently across both business processes
and IT systems.
– Technology must enable Master Data to be readily available to any IT system or business
process that requires it.
12
Core Strategy
Element I: Implement a governance structure around Master Data Entities - MDE
•
•
•
•
•
Organize master data governance by MDE instead of functional areas.
Assign ownership and accountability at entity and attribute level within the business.
Monitor and hold people accountable for the quality of the data.
Integrate existing data stewardship as part of the entity based governance execution.
Incorporate master data considerations into inform decision making within the organization.
Governance
structured
around the
entity
Get in
control of
Master Data
13
Core Strategy
Element II: Focus on Vendor, Product, and Store entities
•
•
•
•
•
Ensure a holistic view (across all relevant business functions) on requirements definition for
designing and building out each of the MDE’s.
Within an entity, focus on attributes that are shared across business areas.
Design and implement changes to business processes and IT systems by addressing problems
at the source.
Develop entity specific detailed plans for getting in control of Master Data.
Implement changes in a series of controlled steps.
Governance
structured
around the
entity
Focus on
Vendor, Product
and Store
Master Data
Entities
Get in
control of
Master Data
14
Core Strategy
Element III: Establish an authoritative source for Master Data
•
•
•
Implement entity focused repositories that serve as data hubs for all IT systems that require
Master Data.
Ensure that data in the Master Data repositories builds only on ratified business definitions.
Replace or remove off-strategy data integration.
Governance
structured
around the
entity
Focus on
Vendor,
Product and
Store Master
Data Entities
Get in
control of
Master Data
Establish a single
authoritative System
of Record
15
Supporting Components
16
Supporting Components
Master Data Management
Governance Policy
-Governance Model
-Principles
Business
Data Model
Architecture
Change Plan
Provides strategic direction and
support
Master Data Governance Council
2009
2008
The owner of the policy and the
Business Data Model
Complete
Master Data
Governance Policy
The Owner of a Master
Data entity
The keeper of the
Business Data Model
The driver and integrator
of the Master Data
Governance policy
The Owner of the data
maintenance process for a
subset of attributes
The expert on data within
his/her field
The keeper of the Master
Data Governance policy
Central
management
and
oversight
2010
Plan remaining
entities
Common Master
Data definitions
Step 4
Step 3
Step 1
Step 4
Step 2
Step 3
Step 1
Plan for getting in
control
Vendor
Step …
Step …
Step 2
Plan for getting in
control
Get in control
of Master
Data in CTR,
CTREL and
PartSource
Step …
Establish Business
Data Model
foundation
Step 2
Tactical Vendor
number solution
Step 1
The protector of data quality
within his/her field
The data quality monitor
and supporter
Plan for getting in
control
Function area A
Function area B
Store
Product
New role (not headcount)
Existing or modified role
Escalation path
Centralized (Business or IT)
Product
Vendor
Location of projects indicates the start - not the duration
Store
Lines of Business
-underlines the
commitment to reach
the strategy’s goal
Guides:
-how we design data
integration
-ensure protection and
management of the
prioritized MDE’s
-how we design
operational systems
-main enabler to get in
control and sustain the
required Master Data.
Directs:
-how built IT systems.
-how to integrate data in
support of the Master
Data Strategy.
outlines the steps
required to move
forward in controlling
Master Data in CTR,
CTREL and PartSource
-how we design
reporting & analysis
17
What components are shared?
Canadian Tire
CTR
PartSource
Real Estate
Petroleum
CTFS
MWW
Common Master Data definitions
Common Master
Data definitions
Common Master
Data definitions
Master Data system landscape
Master Data
system
landscape
Master Data
system
landscape
Implementation roadmap
Implementation
roadmap
Implementation
roadmap
Master Data Principles
Data Governance foundational model
Logical Master Data architecture
18
Master Data Governance Policy
•
The master data governance model and principles are comprised into a formal Master Data
Governance Policy.
•
The policy introduces principles, roles, ownership and accountabilities and is in alignment with
the Board level Information Management Policy.
–
A policy is put in place to ensure protection and management of the prioritized MDE’s.
–
The policy serves as an enabler to get in control and sustain the required quality in
Master Data quality.
19
Master Data Governance Purposed Model
Provides strategic direction and
support
Master Data Governance Council
The owner of the policy and the
Business Data Model
The Owner of a Master
Data entity
The keeper of the
Business Data Model
The driver and integrator
of the Master Data
Governance policy
The Owner of the data
maintenance process for a
subset of attributes
The expert on data within
his/her field
The keeper of the Master
Data Governance policy
The protector of data quality
within his/her field
The data quality monitor
and supporter
Function area A
Product
New role (not headcount)
Existing or modif ied role
Escalation path
Centralized (Business or IT)
Function area B
Vendor
Store
Lines of Business
A Master Data Governance Council consists of CTR, PS and CTREL executives, and is formed to
provide support and strategic direction for the Master Data Governance Policy. The council also
20
serves as the ultimate point of escalation in Master Data related issues.
Assign ownership at the attribute level
ILLUSTRATIVE
Executive Entity Owner defines
the entity as a whole
Executive Entity Owner (Vendor)
Business Data Owner A
Number
Name
Address
Business Data Owner B
Date
Added
...
Marketing
Vendor Entity
FOB
Supply Chain
...
Business Data Owner C
Currency
Finance
Terms
...
Attributes are defined and
owned by different business
areas
• Distributing and grouping of attributes enables ownership to be assigned within
the relevant areas of the organization
• A single person is still needed to define and endorse the entity as a whole
21
An illustrative example of Master Data governance focusing on the Vendor entity
ILLUSTRATIVE
Master Data Governance Policy Owner
The owner of the policy and
the Business Data Model
Entity level
Vendor
Executive Entity Owner
Reg Mclay
(VP Business Development)
Attribute level
Business Data Owner (Marketing)
Mike de Paul
(Director, Imports)
The Owner of a Master
Data entity
The Owner of the data
maintenance process for a
subset of attributes
Business Data Owner (SC)
Anne McCourt
(Director, Order and Info Mgmt)
Data Custodian
Tanya Fitzgerald
(Manager, Ordering Operations)
Business Data Owner (Finance)
Gary Conway
(Director, Fin. Sys. & Info Mgmt.)
Data Steward
Bruce Harper
(Operations Support Team Lead)
The protector of data quality
within his/her field
The expert on data within
his/her field
Data Producer
Helen Troiani
(Placing Deal Coordinator)
Enters and
maintains data
New role (not headcount)
Existing or modified role
Note: Names have been used for illustrative purposes only
Line
Virtual
22
Establish governance oversight and coordination roles
Position roles with Policy Owner
Master Data Governance
Council (including CIO, CTR, PS &
CTREL Exec)
Master Data Governance Policy Owner
“Evangelist”
Executive Entity Owner
Reg Mclay (Vendor)
Business Data Owner
Executive Entity Owner
Duncan Reith (Product)
Business Data Owner
Business Data Owner
Governance Coordinator
Executive Entity Owner
Glenn Butt (Store)
Business Data Owner
Business Data Owner
Business Data Owner
Data advisory council
Data Steward
Data Steward
Data Steward
Data Steward
Data Steward
Data Steward
23
Master Data Principles
The objective of the principles is to support the strategic direction and to make
informed decisions – not to pursue the principles at any costs.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Master data must have ratified definitions
Master data must have governance roles and responsibilities assigned
Master data quality issues must be addressed at the source of the problem
A Master data attribute must only have one System of Record (SOR)
A Master data attribute must only have one MDR and must only be source
from there
Master Data definitions should align to industry/public/de-facto standards
unless a proprietary definition provides better business value.
Master Data attribute could have Local or Shared relevance, which needs
to be determined before being added to any IT system
Master Data must align to existing Data Principles
The same Master Data must be identifiable across multiple IT Systems
24
Business Data Model
The Business Data Model is required to house all ratified Master Data definitions
Per attribute: Attribute name,
Definition, Purpose,
Standardization rules, Life cycle,
Value set, Confidentiality, System
of Record
Per hierarchy: hierarchy name,
hierarchy type (finite/infinite
levels), Purpose, Basic roll-up
Information
Entity
Creation event, Update event,
Deletion event, Purging event
Confidentiality, Entity
classification, Organizational
coverage
Definition
Entity name, Core definition,
Purpose, unique identifier, legacy
identifier, exclusions, Owner
The Business Data Model will our guide on how we:
Design data integration
Design operational systems
Design reporting & analysis
25
Logical Architecture
Operational System
Operational System
Integration
Master Data Repository
Operational System
Dedicated System of Entry*
•A central Master Data Repository (MDR) component and a dedicated System of Entry are introduced.
•The MDR serves as the hub for systems requiring master data.
•In a physical world there can be several MDR components.
•The dedicated SOE component is devoted to data entry and storage for a set of attributes.
•The SOE and MDR can be the same physical system but it doesn’t have to be.
26
Canadian Tire MDM eco systems
Attribute Maintenance:
• Attribute maintenance will be distributed among business transaction systems.
• A master data attribute will be maintained only in one system.
• A dedicated system of entry might be introduced for the sole purpose of data entry without
operational logic. This is intended to provide flexibility in deciding on where to place an
attribute.
Master Data Repository (MDR):
• Logically there will be a Master Data Repository per Master Data Entity (MDE).
• The MDR will hold all shared master data attributes for an entity.
• The MDR will be the source of shared master data to all down stream application.
• The MDR assigns a common Master ID that is mapped to every source master record
• The MDR must consume published data changes from individual systems that maintain shared
master data.
Integrating Master Data:
• Routing & transformation will be through the CTC integration layer
27
Roles & characteristics
Dedicated system of entry:
Master Data Repository :
•
•
Role
–
–
•
Manages data entry for a set of attributes through
an interface
New attributes can be added as necessary
Characteristics
–
Data entry for a small set of attributes for an MDE
with simple data validation and minimum
operational functionality.
–
Must accommodate addition and modification of
attributes.
–
Does not allow for direct data access, an interface
must be used.
–
There can be more than one such component
physically, potentially one per MDE.
–
Publish data change events for the purpose of
data synchronization & integration
Role
–
–
•
Centralized data provider for shared Master Data
attributes to support operational processing
Becomes the source of master data to all down
stream IT systems.
Characteristics
–
All shared attributed for a given MDE must reside
in the MDR.
–
Consume & publish data change events for the
purpose of data synchronization & integration
–
Downstream applications must only source shared
master data from the MDR.
–
The MDR controls the assignment of a common
identifier for new Master Data records.
–
Contains mapping between the common &
different systems keys at the record level.
–
Enable in & out bound data synchronization. (RT &
Batch)
–
Support on demand master data requests
28
Master Data Management & Integration Platform (Combined)
Illustration of how the Master Data architecture and the Integration architecture
works together
29
Master Data Change Plan
•
•
Outlines the steps required to move forward to get in control of Master Data in CTR, CTREL
and PartSource.
The change plan consist of 4 tracks in order of importance:
– Central management Track
– Vendor Track
– Product Track
– Store Track
Planning
•
•
•
Detailed
attribute/system/process
analysis
Define requirements
Define common definitions and
data model
•
Assign Governance roles
•
Design data quality KPIs
•
Design entity change plan
Getting in control step
Design – Develop – Implement
•
•
•
•
•
•
•
Integration
Data harmonization
Migration
Maintenance processes /
workflow
System of Record
Data quality monitoring
IT system changes
30
Where are we now?
Current implementation approach:
•Based on business functionality first and associated data
•Focused on program or initiative functional requirements
Strategic initiatives
underway or completed
Strategic initiatives
underway or completed
Product
Vendor Management
Vendor
Assortment Management
Automotive
management system
Legacy Simplification &
Decommissioning
Price management
Store
Parts Data Management
Identified owners and stewards
Canadian Tire
Master Data Repository V 1.0
Beginnings of a Dedicated SOE
Usage of an Enterprise DM
Incorporating Entity life cycle
into overall environment
CTR
PartSource
Location (Store & DC)
Vendor
Product
Real
Estate
Petroleum
Product
CTFS
MWW
31
Ayad Azzarouk
Enterprise Architect
Canadian Tire Corporation
ayad.azzarouk@cantire.com 32
Data Types
Operational
Systems
Operational Systems
B.I. Systems
Transactional
Data
Product
Vendor
Store
Customer
Master Data
Consistent, accurate master data,
synchronized across applications
with controlled data maintenance
P.O.,
Invoices,
Sales
Master
Data
Transactional
Data
Analytical
Data
Business
functionality &
Operational
reporting
Consistent,
accurate,
integrated data for
analysis and
reporting
33
MDM components or capabilities:
Ownership & Stewardship
Governance: Master Data Governance is the authority that decides how master data is maintained, what it contains, how
long it is kept and how changes are authorized and audited.



Data Stewardship: Stewards are appointed by the owners of each master data entity; they have knowledge of the
data and business rules.
Business Rules: Master Data Stewards establish common business rules for updating and maintaining master data in
each domain.
Entity Life cycle: Master Data Stewards define a workflow for creating and updating their master data according to
the Business Rules.
Platform
Master data repository and services:
persists and maintains the authoritative master data record for a master data entity, such as customer or product, as well as
for the relationships between them. Provides data and application services and logic that can update and access master data
held within the database. Also contains logic for composite business services that represent business processes (for example,
adding a product or a location).





Consistent Unique ID Service: Assigns a common Master ID that is mapped to every source master record. This
cross-reference is maintained in the Master Data Repository.
Business level services: Provides services to integrate master data into business processes of each business unit.
Master Data Integration Services: Exposes common data integration services for creating, updating and
synchronizing master data with other operational and analytic systems.
Security & authorization: Controls transaction and attribute level authorization, as well as user access to critical
master data.
Events configuration and notification: Detects transactions on master data (updated, added or deleted) or other
events such as date driven events
User interface:
Manages data entry for a small subset of attributes that exist in the organization but don’t have a business transaction
system. Additionally provides functionality used to configure and manage the application including code table management,
error messages management and data authorization rules.
34
Master data management Target State
Stewardship
Master data management Platform
Ownership
MDM Principles
Entity Life Cycle
Business Transaction Systems
MDM Solution
scope
Extended Block
Business Level services
Security and authorization
Events Configuration and notification
Essential Block
User interface
Integration points
Master Data Repository & Services
Integration Layer
Canadian Tire
Canadian Tire
CTR
PartSour
ce
Real
Estate
Petroleu
m
Service
Service
CTFS
MWW
Service
Partner
CTR
PartSource
Real
Estate
Common Master Data definitions
Petroleum
CTFS
MWW
MD
Definition
MD
Definition
MDM
Systems
MDM
Systems
Roadmap
Roadmap
Service
Master Data system landscape
Location
Implementation roadmap
Vendor
Vendor
Vendor
Item
Item
Item
Roadmap
Vendor
Master Data Principles
Customer
Master data sharing scope
Customer
Item
Data Governance foundational model
Logical Master Data architecture
Possible shared components
35