enterprise master data services in bp
TRANSCRIPT
Enterprise master data services in BP
Andy WalkerNovember 15th 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
3
1.
2.
(2000)
(2002) (2002)
(2000)
(1999)
(1996)(2000)
(2001) (2001)
BP has inherited a large variety of processes and systems
Context - BP growth
4
Enterprise master data in BP
Subject Business Owner Environment Status
Customer R & M SAP MDM Development
Financial FC&ASAP R/3 Global Financial Template (GFT)
Live
Equipment/Plant To Be Determined SAP R/3 Development
Geography/Identity DCT Enterprise Services -Bespoke Live
Vendor PSCM - Group SAP MDM Live
Material R & M Procurement SAP MDM Live
Product R & M SAP MDM Development
Employee HR SAP R/3 – HR Instance Development
Link
ed –
Bus
ines
s P
artn
er
Link
ed
Mat
eria
l M
aste
r
5
Why manage master data?Two fundamental procurement questions
Who do we buy from?
• 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?
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 resaleServices – Work performed by a 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 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
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’sdatabase.
• 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
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
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
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 MDM
12
Programme update September 2007
Object Vendor Material Customer Product
Business
process
MDM Design and build In process
MDM System live Q1 2008 Q1 2008
Governance & organisation In process In process
Data quality enhancement
Data conversion process In process
Live systems 2007 1 1
Planned live systems 2008 6+ 4+ 1 1
13
SAP Applications
MDM –Record of Reference
•Material
•Vendor
•Customer
MDM systems architecture
R/3 PFM&S
R/3 E&P
XILayer
Enterprise Portal
Intermat
SRM
R/3 PFManufacturing
SRM
Dun & Bradstreet
1414
MDM technical architecture
• Assembly
− Combination of automated and manual cleansing and consolidation
− Enrichment Services ( D&B and Intermat)
• Distribution using shared infrastructure
− MDM Syndicator
− XI
− MFT
Data Distribution
Service(DDS)
( Access ServicesDelivery Services)
Legacy Application
Data Warehouse
SAP R/3
Maximo
Portals
SAP
Data SourcingAnd
Harmonization
(DHS)
RecordOf
ReferenceSAP
SIEBELLegacy
RecordOf
Reference
Master Data
ManagementProcesses
IntermatD&B
Operational Applications
Portals
Assembly Data Distribution ServiceRecord of ReferenceManagement
SAP MDM•Vendor•Material•Customer•Product
15
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.)
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.)
17
MDM business partner repository design
XI Interfaces
D&B External
D&B Internal Business Partner
Repository
Vendor, Custom
er, US Vendor
MD
M ID
Harmonized US Vendor
Repository
Centralized Vendor Repository
CentralizedCustomer Repository
US Account Groups
GFT Account Groups
SAP MDM
Enrichm
ent Architecture w
ith W
eb services Call
PR5
PR4
PRC
PR1
PRV
PRE
PRO
PRE
ERP’s
Visual Composer
Search
Web services Call to D&B Internal
Adobe off line form
Portal Applications
User Interfaces
Web dynpro – MDM API connection
.Net User Interface
GFT Account Groups
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 ****
Start Review RequestSet Request Received
Send for companysearch
Select the record for WB search
Enrichment Information Received
Set Distribution Flags
StopSelect Address Set Address Selection Complete
Send Notifications
NotifySet Dist Flag
WaitBranch
No match found in company
search
Stop (2)
Send for WBsearch
Wait2
Branch (2)
Worldbase information not
imported
Stop (4)
Worldbase information imported
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 2008.
An appraisal for implementing MDM for suppliers in the US during2008 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.
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
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