Enterprise master data services in BP. Andy Walker November 15 th 2007 CDI MDM Summit, New York

Transcription

1 Enterprise master data services in BP Andy Walker November 15 th 2007 CDI MDM Summit, New York

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

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

4 Enterprise master data in BP Subject Business Owner Environment Status Customer R & M SAP MDM Development Linked Business Partner Vendor PSCM - Group SAP MDM Live Material R & M Procurement SAP MDM Live Linked Material Master Product R & M SAP MDM Development Employee HR SAP R/3 HR Instance Development 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 4

5 Why manage master data? Two fundamental procurement questions Who do we buy from? Vendors - a business partner to whom payables are owed for products supplied or services rendered. 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? What do we buy? Materials products purchased to be consumed in operations or for resale Services Work performed by a vendor for pay (repairs, maintenance, install) 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? 5

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 within a system Same vendor 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 6

7 D&B business partner hierarchy Business Partner Hierarchy Vendors customers The D&B DUNS Number is a unique, nine-digit; non-indicative identification number assigned to every business entity in D&B s database. D&B provides 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 7

8 D&B web service Provides a 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 provides a 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 8

9 Customer design Customer is a mirror of supplier External services (D&B) will provide the business party legal entity hierarchy D&B will maintain business partner over the Corporate lifecycle DUNS number will be a 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 with D&B as the service provider 9

10 MDM design and implementation

11 Evaluation of MDM 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 MDM 11

12 Programme update September 2007 Object Vendor Material Customer Product Business process MDM Design and build In process MDM System live Q Q Governance & organisation In process In process Data quality enhancement Data conversion process In process Live systems Planned live systems

13 MDM systems architecture Enterprise Portal SAP Applications Intermat MDM Record of Reference Material Vendor XI Layer R/3 PF Manufacturing R/3 PF M&S SRM Dun & Bradstreet Customer R/3 E&P SRM 13

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

15 Portal principle Principle Why? SAP Portal (internet facing) provides the main user interface with MDM 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.) 15

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

17 MDM business partner repository design User Interfaces.Net User Interface Visual Composer Search Adobe off line form Portal Applications D&B External Enrichment Architecture with Web services Call Web services Call to D&B Internal D&B Internal Business Partner Repository SAP MDM Vendor, Customer, US Vendor MDM ID Web dynpro MDM API connection Harmonized US Vendor Repository US Account Groups Centralized Vendor Repository GFT Account Groups Centralized Customer Repository XI Interfaces ERP s PR5 PRV PRE PRO PRE PR1 PRC PR4 GFT Account Groups 17

18 Workflow in MDM Universal Work List is a key design feature Attached example illustrates the create vendor process including Dun & Bradstreet enrichment process *** DEMO **** No match found in company search Stop (2) Start Set Request Received Review Request Send for companysearch Wait Branch Select the record for WB search Send for WBsearch Wait2 Worldbase information not imported Stop (4) Branch (2) Worldbase information imported Enrichment Information Received Select Address Set Address Selection Complete Set Distribution Flags Set Dist Flag Send Notifications Notify Stop 18

19 Progress summary The MDM project has successfully implemented a live solution for suppliers and materials as part of the Process Fitness BP Rotterdam implementation. The solution includes the MDM service organisation, data cleansing and maintenance processes and procedures based on SAP MDM software. The system has been extended to include Customer and Product MDM ready for implementation with Process Fitness in Iberia in An appraisal for implementing MDM for suppliers in the US during 2008 is being completed in September in order to gain significant scale for global mastering via MDM System enhancements are being developed to enable global roll out. In summary, the programme has met all its 2006 and 2007 milestones to date, within budget and is planning to move to a global solution in 2008 to enable the business case to be realised as soon as possible. 19

20 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

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