BP has implemented an enterprise master data management (MDM) system using SAP MDM to centrally manage key master data across its global business units. The summary provides an overview of BP's MDM implementation including the current status, architecture, design principles, and future roadmap. Key master data domains like vendors, materials, and customers are managed in a single SAP MDM instance with enrichment from external sources. The MDM system provides consistent, high-quality master data to various SAP and non-SAP operational systems globally through a common portal and integration layer. BP's MDM program aims to scale the solution across more business units and domains while maintaining core governance principles.

1. Enterprise master data services in BP

2. Agenda • Introduction • Business drivers and benefits − Vendor and customer − External enrichment • MDM implementation in BP − Current status and Roadmap − Architecture − Design principles • Key messages • MDM Demo

3. 2. 1. Context- BP growth (1999) (2000) (2000) (2002) (2000) (2001) (2002) (2001) (1996) BP has inherited a large variety of processes and systems

4. Enterprise master data in BP Subject Business Owner Environment Status Customer Vendor R&M SAP MDM Development PSCM - Group SAP MDM Live Linked – Business Partner Financial FC&A SAP R/3 Global Financial Template (GFT) Live Equipment/Plant To Be Determined SAP R/3 Development Geography/Identity DCT Enterprise Services- Bespoke Live Employee HR SAP R/3– HR Instance Development MaterialR&M Procurement SAP MDM Live ProductR&M SAP MDM Development Linked Material Master

5. Why manage master data? • What materials do we buy? • Where are these materials used? • Who orders these materials? • How much do we pay for similar materials? • What services do we buy? • Where are these services used • Who orders these services? • Who are our suppliers? • Where are our suppliers located? • What are our suppliers’ capabilities? • How stable are our suppliers? • Should we be trading with these suppliers? Two fundamental procurement questions Who do we buy from? What do we buy? Vendors - a business partner to whom payables are owed for products supplied or services rendered. Materials – products purchased to be consumed in operations or for resale Services – Work performed bya vendor for pay (repairs, maintenance, install)

6. Why manage vendor master data? • Financial and trading risk information on suppliers − Risk of trading with ‘denied’ parties • Inefficient master data management processes − Duplicate vendors withina system − Same vendor is set up in multiple systems with multiple identifiers • Implications − Harder to track spend and leverage the scale of the company − Spend data is incomplete and not classified − Difficult to understand when we are trading with the same supplier, or branches of the same supplier − Harder to track issues such as health and safety status − Reaching out to suppliers for supplier enablement purposes is difficult due to the lack of contact information data − Purchasing controls are difficult to implement

7. D&B business partner hierarchy • Business Partner Hierarchy − Vendors − customers • The D&B D-U-N-S Number isa unique, nine-digit; non-indicative identification number assigned to every business entity in D&B’s Worldbase database. • D&B provides Corporate Linkages for − Branch to headquarter − Subsidiary to parent − Domestic ultimate − Global ultimate • Lifecycle management processes are enabled by quarterly refreshes of data D&B hierarchy

8. D&B web service • Providesa unique Duns Number for the Vendor • World base package information (100+ attributes) for the company structure • The Query is triggered by the executing workflow steps. MDM Enrichment Architecture providesa real time response as follows: Workflow step triggers syndication of the request Enrichment Controller routes query to Enrichment Adapter Adapter passes the query to D&B web service D&B Sends the world base information for the company that Matches the query Enrichment Controller sends this info packet to the MDM import process Query Enriched Data

9. Customer design • Customer isa “mirror” of supplier − External services (D&B) will provide the business party Corporate Linkage hierarchy − D&B will maintain business partner over the Corporate lifecycle − The D&B D-U-N-S number will bea unique primary key to identify the business partner legal entity − Credit checking will be carried out against the appropriate level of the business partner corporate structure

10. MDM design and implementation

11. Evaluation of MDM- 2006 • Proof of Concept (Apr 06– Aug 06) − Fifteen BP systems were considered in the repository design − Vendor − Hierarchy was configured in MDM − A new vendor creation request workflow involving five different roles was configured using SAP Portal and MDM − Material − The UNSPSC hierarchy was configured in MDM − The SMD Intermat Classification for materials was configured in MDM and presented via the Portal − BW integration was demonstrated by reporting spend analysis against the MDM hierarchies (from D&B) • Conclusion − Proceed with the implementation of vendors and materials in SAP MDM

12. MDM systems architecture SRM SAP Applications • Material • Vendor R/3 PF M&S XI Layer Enterprise Portal SRM R/3 PF Manufacturing • Customer R/3 E&P

13. MDM technical architecture Data Distribution Service (DDS) ( Access Services Delivery Services) Legacy Application Data Warehouse SAP R/3 Maximo SAP Data Sourcing And Harmonization (DHS) Record Of Reference SAP SIEBEL Legacy Record Of Reference Master Data Management Processes Operational Applications Portals Assembly Data Distribution Service Record of Reference Management SAP MDM 15 Intermat D&B • Assembly − Combination of automated and manual cleansing and consolidation − Enrichment Services( D&B and Intermat) Portals • Distribution using shared infrastructure − MDM Syndicator − XI − MFT • Vendor • Material • Customer • Product

14. MDM Program Summary 16  The MDM Program has successfully designed and implemented a solution for central management of Vendor and Material master data. This was deployed to BP Rotterdam in 2007.  The MDM program provides ongoing support, consulting service, new project engagement, data cleansing service and data maintenance processes. (The data entry and maintenance is done within R&M Procurement Operations)  The system design has been extended to include Customer and Product MDM ready for implementation with Iberia in 2008.  Development work has been completed to deploy Vendor to the North America/PR5 ERP systems during 2008; the first rollout to the A&A business went live in Feb 08.  System enhancements are being developed to enable global roll out to the E&P Backbone, including deployment to Indonesia in 2Q 2008. Indonesia customers and vendors are now loaded into the live MDM environment

15. MDM 2008- Programme scope • Iberia • US refineries 3 6+ 3+ 2+ Activity Vendor Material Customer Product MDM Design and Build progress In MDM Infrastructure Live Data conversion process 2008 Deployment Activities Live consuming systems Planned live systems 2008  Q2 2008 Q4 2008 In progress • Rotterdam • Whiting • North America • Rotterdam • Indonesia • Iberia • BI integration • Indonesia • Iberia • Iberia 17        1 1

16. Portal principle • Principle − SAP Portal (internet facing) provides the main user interface with MDM • Why? − Internet facing– living life on the web − One Portal/ workflow engine to develop and administer • Implications − Need to define process/procedures for multiple portal instances (R&M, E&P, etc) maintaining MDM data. − Requirement for Federated Portal − Develop guidelines around roles to update SAP MDM data across portal environments (defining limitations, by master data object, by implementation, by roadmap etc.)

17. MDM instance strategy • Principle − Single SAP MDM instance will be shared within and between projects/landscapes. • Why? − Time to market and flexibility − Reduces development across SAP landscape. − One interface to record of origin e.g. Dun& Bradstreet, Intermat − One Portal/ workflow engine to develop and administer − Provides an opportunity for better utilization of infrastructure resources. • Implications − Need to define process/procedures for shared central instances servers for handling change control, resource allocation − Develop guidelines around which SAP MDM products repositories should be shared (defining limitations, by master data object, by implementation, by roadmap etc.)

18. MDM business partner– 2008 design and build XI Interfaces D&B External D&B Internal Business Partner Repository US Vendor Customer, Vendor, MDM ID Harmonized US Vendor Repository Centralized Vendor Repository GFT Account Groups Centralized Customer Repository US Account Groups SAP MDM with Enrichment Architecture Web services Cal PR5 PR4 PR1 PRC PRV PRE PRO PRE ERPs Web services Call to D&B Internal Web dynpro– MDM API connection GFT Account Groups Adobe off line form Portal Applications User Interfaces . Net User Interface Company Search

19. Key messages– Business • Design the business processes − Agreeing the master data ownership and the management processes is essential to implement MDM effectively • Prepare the data − Business users at site and segment operations levels to be accountable for the quality of the converted data − Define the data structures– legal entity, delivery address, invoice address, payer details − Define the essential data quality elements– no duplicates, mandatory fields to have ‘business ready’ master records at global and local(R/3) levels − Data clean-up should be started early

20. Key Messages– Technical • Technical delivery is driven by the business design • SAP MDM provides: − Links to Record of Origin − Dun& Bradstreet enrichment web services − Links to consuming systems − R/3- vendor, customer material − Netweaver integration − Portal, Workflow, XI − Each component requires Change Management processes to be established across the global landscape • MDM provides the required capabilities, but should be carefully managed as future enhancements and releases are incorporated

22. 25 Key challenges in MDM Program execution:  How to keep the core governance principles intact when the program grows globally?  How to scale quickly?

23. 26 Innovative Solution Design  SAP MDM Data modeling and Workflow design flexibility  Distribute one master data object with both internal and external numbers as remote keys for different consuming systems  Build Distinct and Modular workflows for enabling looping of steps  SAP Netweaver Platform integration capabilities  Augment Master data service SLA by providing Dashboards and task lists  Validate VAT numbers entered in Portal through EU VAT Validation web services  Auto propose short and long descriptions for Materials based on classification (taxonomy attributes) enabling standardization  Consume new features released in Netweaver platform as they are made available  Usage of Adobe forms for vendor request data capture and integration with SAP Portal for direct upload. Data captured once is carried all the way to consuming systems without re-keying Ensure enterprise wide acceptance of Data Governance principles by leveraging Core MDM Governance Principles

24. 27 Agile Execution  Monthly release of new functionality around the core processes  Engagement of all stakeholders in the solution landscape to ensure readiness and endorsement  Streamlined program schedule to integrate global rollouts with Monthly releases  Make available Hybrid Data Management scenarios to provide data services for both consolidation and Centralization scenarios Innovative Solution Design Core MDM Governance Principles

25. 31 Thank You For additional information, Please contact: [email_address]