Canadian Tire strategy for getting in control of

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 • Master Data is currently not an asset that provides agility and flexibility to the business Strategic • 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 Tactical • 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. Operational • 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 250 ml can On deal as a 400 ml 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 400 ml can is on deal. Otherwise the 250 ml 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 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, Part. Source, 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 Part. Source 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 Part. Source. Original Scope CTR MWW Part. Source Petroleum CTFS Corp Decision SBU Focus CTR No apparent strategic need to share master data across all SBUs to date. Corp Part. Source 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 Assessment MDE Focus Product Store Assessed by: - Usage across systems & processes - Priorities (Risk, Benefits, Complexity) Vendor As of the 2 nd 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 Directs: -how built IT systems. outlines the steps required to move forward in controlling Master Data in CTR, CTREL and Part. Source Common Master Data definitions -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. -how to integrate data in support of the Master Data Strategy. -how we design reporting & analysis 17

What components are shared? Canadian Tire CTR Part. Source Real Estate Petroleum CTFS MWW Common Master Data definitions Master Data system landscape 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 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 Date Added Business Data Owner B . . . 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 Mc. Court (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 Governance Coordinator Executive Entity Owner Glenn Butt (Store) Business Data Owner Data advisory council 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 The Business Data Model will our guide on how we: ØDesign data integration ØDesign operational systems ØDesign reporting & analysis 25

Logical Architecture Data Operational System Data Integration Operational System Data Da Da ta Master Data Repository Da ta ta 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 Part. Source. 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 • • • System of Record Data harmonization Migration Maintenance processes / workflow 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 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 Part. Source 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 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 co n ratio u g i f n Integration points Master Data Repository & Services Integration Layer Canadian Tire CTR Part. Sour ce Real Estate Petroleu m Service CTFS MWW Service Partner CTR Part. Source Real Estate Common Master Data definitions Petroleum Service Master Data system landscape CTFS MWW MD Definition MDM Systems Roadmap Location Implementation roadmap Vendor 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