Canadian Tire strategy for getting in control of Master Data

1. Canadian Tire strategy for getting in control of Master Data Ayad Azzarouk Enterprise Architect Canadian Tire Corporation ayad.azzarouk@cantire.com

2. 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

3. Canadian Tire • 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. 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. 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 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-it-yourselfers. Canada's largest independent retailer of gasoline with more than 250 gas bars and more than 55 Simoniz car washes in Canada.

4. 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 operational view, which serves as the system of record for this data.

5. Challenges affecting business on all levels

6. Example123-12-12-1 WD-40 oil 250ml canOn deal as a 400ml can, Same product number Operational Challenge 250 ml 400 ml Picking Warehouse worker has to know that the 400ml can is on deal. Otherwise the 250ml can is picked and packed. Dealer The dealer’s warehouse cannot fit the larger size – manual work and repacking. Transportation Number of pallets increases due to volume – same order amount. Rework fixing over-height, overhanging pallets. Goods received Boxes are bigger and cannot be loaded on truck. Products Left On Dock.

7. 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.

8. Interdependency multiplies the complexity, scope, and cost of projects

9. 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

10. 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. Decision No apparent strategic need to share master data across all SBUs to date.

11. 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 Assessment Assessed by: - Usage across systems & processes - Priorities (Risk, Benefits, Complexity) As of the 2nd half of 2009 Customer and Supply Chain Nodes are becoming business priority

12. 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.

13. 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.

14. 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.

15. 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.

16. Supporting Components

17. Governance Policy -Governance Model -Principles Business Data Model Architecture Change Plan Common Master Data definitions Supporting Components Master Data Management -underlines the commitment to reach the strategy’s goal -ensure protection and management of the prioritized MDE’s -main enabler to get in control and sustain the required Master Data. Guides: -how we design data integration -how we design operational systems -how we design reporting & analysis 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

18. What components are shared? Canadian Tire CTR PartSource Real Estate CTFS MWW Petroleum Common Master Data definitions Common Master Data definitions Common Master Data definitions Master Data system landscape Master Data system landscape Master Data system landscape Implementationroadmap Implementation roadmap Implementation roadmap Master Data Principles Data Governance foundational model Logical Master Data architecture

19. 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.

20. 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 serves as the ultimate point of escalation in Master Data related issues.

21. Assign ownership at the attribute level ILLUSTRATIVE Executive Entity Owner defines the entity as a whole Executive Entity Owner (Vendor) Business Data Owner A Business Data Owner B Business Data Owner C Attributes are defined and owned by different business areas Vendor Entity • 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

22. 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 Vendor The Owner of a Master Data entity Executive Entity Owner Reg Mclay (VP Business Development) The Owner of the data maintenance process for a subset of attributes Entity level Business Data Owner (Marketing) Mike de Paul (Director, Imports) Business Data Owner (SC) Anne McCourt (Director, Order and Info Mgmt) Business Data Owner (Finance) Gary Conway (Director, Fin. Sys. & Info Mgmt.) Attribute level Data Custodian Tanya Fitzgerald (Manager, Ordering Operations) 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 Line Virtual Note: Names have been used for illustrative purposes only

23. 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” Governance Coordinator Executive Entity Owner Glenn Butt (Store) Executive Entity Owner Reg Mclay (Vendor) Executive Entity Owner Duncan Reith (Product) Business Data Owner Business Data Owner Business Data Owner Business Data Owner Business Data Owner Business Data Owner Data advisory council Data Steward Data Steward Data Steward Data Steward Data Steward Data Steward

24. 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. • 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

25. 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

26. Integration Data Data Operational System Operational System Data Data Data Data Data Master Data Repository Data Operational System Dedicated System of Entry* Logical Architecture • 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.

27. 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

28. Roles & characteristics Dedicated system of entry: • 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 Master Data Repository : • 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

29. Master Data Management & Integration Platform (Combined) Illustration of how the Master Data architecture and the Integration architecture works together

30. 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 Getting in control step • Detailed attribute/system/process analysis • Define requirements • Define common definitions and data model • Assign Governance roles • Design data quality KPIs • Design entity change plan • Design – Develop – Implement • Integration • Data harmonization • Migration • Maintenance processes / workflow • System of Record • Data quality monitoring • IT system changes

31. 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 Vendor Management Assortment Management Store Price management Automotive management system Parts Data Management Legacy Simplification & Decommissioning Identified owners and stewards Canadian Tire Master Data Repository V 1.0 CTFS MWW CTR PartSource Real Estate Petroleum Beginnings of a Dedicated SOE Usage of an Enterprise DM Location (Store & DC) Incorporating Entity life cycle into overall environment Vendor Product Product

32. Questi ns Ayad Azzarouk Enterprise Architect Canadian Tire Corporation ayad.azzarouk@cantire.com

33. Operational Systems Product Vendor Customer Store Master Data Data Types Operational Systems B.I. Systems Transactional Data P.O., Invoices, Sales Master Data Transactional Data Analytical Data Consistent, accurate master data, synchronized across applications with controlled data maintenance Business functionality & Operational reporting Consistent, accurate, integrated data for analysis and reporting

34. 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.

35. Master data management Platform Master data management Target State Ownership Stewardship MDM Principles Entity Life Cycle Business Transaction Systems configuration MDM Solution scope Extended Block Business Level services Security and authorization Canadian Tire Events Configuration and notification Essential Block User interface Integration points CTR PartSource Real Estate CTFS MWW Partner Petroleum Master Data Repository & Services Service Service Service Service Integration Layer Location Canadian Tire Vendor Vendor Vendor Vendor Item Item Item CTR PartSource Real Estate CTFS MWW Item Petroleum MD Definition MD Definition Common Master Data definitions Customer Customer Master Data system landscape MDM Systems MDM Systems Roadmap Roadmap Roadmap Implementation roadmap Master Data Principles Data Governance foundational model Logical Master Data architecture Master data sharing scope Possible shared components