Incorporating SAP Metadata within your Information Architecture

Including SAP data in your Information Architecture EDW Tampa, April 2009 Christopher Bradley & Ken Dunn

Contents BP Overview Information Architecture challenges at Bp What’s the problem? Why should you bother with data modelling when you’ve got or planning to get an ERP? How can you incorporate SAP metadata into your overall model? Lessons learned & benefits

1. BP Overview For alternative section dividers with images, please see the BP images where you can copy and paste a pre-set section divider slide (see BP templates in PowerPoint menu: File / New or www.bp.com/brand)

BP Overview BP is one of the world's largest energy companies, providing its customers with fuel for transportation, energy for heat and light, retail services and petrochemicals products for everyday items Turnover: $284 billion (year 2007) Number of employees: 97,600 (at Dec 2007) Service stations: 24,100 Exploration: Active in 29 countries Refineries: Interest in 17 The data above is taken from the 2007 Annual Report and Accounts

Areas of BP Business Exploration & Production Gas Refining Alternative Energy Chemicals Lubricants Fuels Marketing & Retail

BP Corporate Culture The company is a diverse federated organisation of “strategic performance units” – culture encourages local decision making within a corporate framework Current Information Architecture position: Data architecture planning, modelling & governance undertaken to different degrees in different Segments & Functions Variety of tools & techniques used but the majority of data models are stored in an ER/Studio corporate repository Projects encounter common cross business data concepts, but largely create their own models & definitions

2. Information Architecture challenges at Bp

Characteristics: Well-integrated, enterprise-wide global data where appropriate A single view of customer and product master data Key Attributes Real-time straight-through processing in areas of need Overt focus on Data Quality Business insights through greater data visibility Business ownership with Single Point of Accountability for data IT role in providing leadership, coordination and verification Information Architecture vision VISION Data and Information are effectively and efficiently managed as a shared corporate asset that is easily accessible.

Information Architecture Framework ER/Studio Data Types Master Data MI/BI Data Transaction Data Structured Technical Data Digital Document Structure Models / Taxonomy Catalog / Meta data Integration and Access Quality Lifecycle Management Process Governance Planning People Goals Principles Purpose

Challenges Decentralized management Project focus SAP widely used SAP teams may believe that they only need to configure the application, thus overlooking the importance of modeling gaining value from the modeling that is done (cultural change to get SAP team to actually use models) Plus 5,000 other applications many different overlapping physical models (important to map to logical) much integration and ETL work (looking to establish canonical models) SOA and Integration (XML and message modeling) Process modeling (ARIS) SharePoint and MOSS

3. What’s the problem? For alternative section dividers with images, please see the BP images where you can copy and paste a pre-set section divider slide (see BP templates in PowerPoint menu: File / New or www.bp.com/brand)

Problems in Getting Metadata from ERPs Database System Catalog does not hold useful metadata No PK or FK Constraints in the Database Proprietary ERP DD holds ‘Logical View’ of data

… 70,000 Islands of Information

… and understandable Analytical Structures

4. Why bother modelling when implementing ERPs? ….. For alternative section dividers with images, please see the BP images where you can copy and paste a pre-set section divider slide (see BP templates in PowerPoint menu: File / New or www.bp.com/brand)

ERP & packaged systems “ We don’t need a data model – the package has it all” But, does it … Meet your business requirements? Logical Data Model will aid configuration / fit for purpose evaluation Have identical data structures & meanings as your legacy systems? Logical Data model will aid Data Integration, Legacy Data take on and Master Data integration.

Key Reasons to model ERP For requirements gathering For Data migration / take on Master Data alignment Data lineage (particularly important with Data Lineage & SoX compliance issues) For reporting (Particularly Business Intelligence & Data Warehousing) But most importantly, for integration of the ERP metadata into your overall Information Architecture

BP HR example: Personnel tracking Data Modelling – where did it all go wrong? Candidate UK Employee Expatriated to US Joe’s “Engagements” DATA ON AN ENGAGEMENT Start & end date, Sponsor / Parent / Home Organisation, Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits) UK Employee Retiree Joe’s “Role Assignments” DATA ON A ROLE ASSIGNMENT Start & end date, Position (showing Job Type, Work Location, Working Time, Skills Requirements) 1/1/2007 1/9/2009 1/9/2012 1/1/2016 Trainee Geophysicist North Sea Geophysicist GOM Geophysicist (pt time) GOM GU Leader (pt time) GOM Geophysicist North Sea Geophysicist Sabbattical (No role assignment) Exploration Geophysical Consultant In this model a person goes through a sequence of “Engagements” (in this example: candidate, employee, expat, employee, retiree). For each Engagement, the positions filled are indicated by “Role Assignments”, showing start and end date in each position.

The Corresponding Entity-Relationship Diagram Data Modelling – where did it all go wrong? Engagement Role Assignment This is showing that “Role Assignment” is subordinate to “Engagement”. i.e. you can’t set up a Role Assignment until you have an Engagement to relate it to. An everyday language example: “Joe Bloggs’ role as Trainee Geophysicist falls under his UK contract of employment dated 1/1/2007”.

Data Modelling – where did it all go wrong? Person Engagement Position Role Assignment Org Unit Personal Details (e.g. Name, Bank Acct, Emergency Contact, Qualifications) Start & end date, Sponsor / Parent / Home Organisation, Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits) Start & end date Job Type, Work Location, Working Time, Skills Requirements Manager, Cost Centre Model 1 One way of keeping track of people… In this model a person goes through a sequence of “Engagements” (e.g. candidate, employee, expat, employee, sabbatical, employee, retiree). For each Engagement, the positions filled are indicated by “Role Assignments”, showing start and end date in each position. Each Position is part of an Organisation Unit, which in turn is part of a higher organisation unit, and so on. A Position is filled by different people over time (i.e. the various Role Assignments to one Position can be for different people).

Data Modelling – where did it all go wrong? Person Position Role Assignment Org Unit Personal Details (e.g. Name, Bank Acct, Emergency Contact, Qualifications) Start & end date, Sponsor / Parent / Home Organisation, Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits) Job Type, Work Location, Working Time, Skills Requirements Manager, Cost Centre Model 2 One possible simplification We might try to simplify the model by merging Engagement into Role Assignment (see below). But there are consequences. For example this would require us to repeat the sponsor and contractual details on a new Role Assignment each time the person moves to a new Position. Also if someone had simultaneous Role Assignments we would have to keep the multiple versions of their contractual details in step.

Data Modelling – where did it all go wrong? An example of why the model matters to SAP HR Person Engagement Position Role Assignment Org Unit Personal Details (e.g. Name, Bank Acct, Emergency Contact, Qualifications) Start & end date, Sponsor / Parent / Home Organisation, Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits) Start & end date Job Type, Work Location, Working Time, Skills Requirements Manager, Cost Centre This data field recorded on an Engagement might be better implemented as this relationship between the Engagement and an Org Unit. There are powerful reasons to do this: e.g. the processes of organisation definition (which maintain the list of Org Units) can ensure that, unlike now, no-one’s sponsor/parent/home gets lost as org units are merged, split, or dissolved; e.g. workflow can route transactions seamlessly via sponsor/parent/home when appropriate, rather than as now by using host org unit as a proxy with manual interventions (this applies to salary review & development decisions, for example). Adding the red relationship is a configuration choice in SAP. SAP is “vanilla” with it or without it.

There are many decisions. Some examples, if we started from model 1… Allow simultaneous Role Assignments? Allow cost-centres only on Position? Allow hierarchy of Org Units, or Positions, or both? NB ALL options here are “Vanilla SAP” Data Modelling – where did it all go wrong?

Data integration & lineage Data take on into SAP Are source & target definitions = ? Load tables or Idocs? Still need the basics: SOX lineage requirements Repository based Data migration design = Consistency Legacy data take on Source to target mapping Reverse engineer & generate ETL Impact analysis

MI / BI / DW Model Data requirements in Dimensional Model Must start from understanding of existing data landscape Capture rich metadata via reverse engineering BW Info Cubes, BO Universes, ……. Generate Star, Snowflake, Star flake schemas

5. How can you incorporate SAP metadata into your overall model?

Challenge “ Where in SAP is the data I need?” “ How are the tables related?” How can I explore SAP (without very expensive SAP consultants)?

Goal: metadata exploration for ERPs Extract ‘useable’ metadata from ERPs Browse, subset Modelling tool interface

Saphir Allows understanding of EA metadata without specialist application knowledge Typical projects Business Information/Data Warehousing Enterprise Metadata management Impact analysis Application Integration

SAP Server N SAP Server 3 SAP Server 2 SAP Server 1 ABAP 2 1 5 1. Metadata extracted from SAP 2 Data Modelling Repository 3 4. User browses Saphir repository to Identify & subset metadata. 5. Model metadata in ER/Studio & store Data models in BP corporate repository. SAP Instance 1 SAP Instance 2 SAP Instance 3 SAP Instance N ABAP 1 (read only) Saphir Repository 1 Saphir Repository 2 Saphir Repository 3 Load Saphir repository Database Server Application Server Load Saphir repository Load Saphir repository Load Saphir repository ABAP 2 ABAP 1 (read only) ABAP 2 ABAP 1 (read only) ABAP 2 ABAP 1 (read only) Client 2. Extracted Metadata files moved to application server 3. Metadata loaded into Saphir repository 4 Saphir ER/Studio ER/Studio Repository Server Bp’s SAPHIR Architecture Saphir Repository N

Search by description or table name

Sort by child/parent tables to find “master” tables

View table and field information

Application Hierarchy & Program tree

Get information from screen X X X

LDM Project Review - Approach to Developing the Model Identified thru SAP Screens Process Documentation SAP Database (Saphir) Approach Identify relevant processes (Process Scope Matrix) Identify relevant T-codes for each process Utilize SAP Screens, Process Documentation, and Database Analysis to identify candidate data elements Model - Master Data -> Transactional Data -> BW Data Development Process

6. Lessons learned & benefits? For alternative section dividers with images, please see the BP images where you can copy and paste a pre-set section divider slide (see BP templates in PowerPoint menu: File / New or www.bp.com/brand)

Lessons Learned - People SAP architects require careful handling. Avoid religious wars! Data Modellers require careful handling. Keep them focused on the business objective! Developers require careful handling. Get them comfortable with using the models (may require training). Avoid DIY ABAP’s to re-invent model! Management require very careful handling. Continually demonstrate value!! … .. remember people are people

Lessons Learned - Process Use the right tool for the job Work closely with project team and process modelers Work directly with SME and get continuous feedback Get involved in projects early (ideally before the ERP has been selected and definitely before it has been configured) Look for value in the maintenance cycle (interface maintenance, XML maintenance, cube rationalization) … .. always be part of the team

Lessons Learned - Technology Modelling tools need some help to get at meaningful ERP metadata Specialist ERP metadata extraction tools alone is too detailed. Can’t point at complete SAP module and get a good result Modellers should have access to a data profiling tool … .. technology is a means to an end, NOT the end in itself

There are lots of benefits Requirements gathering … leading to focused evaluation and good configuration Data migration / take on … from clear definitions, accountabilities and high quality Master Data alignment … facilitating establishment of master data single version of truth Data lineage … driving down the cost of integration Reporting … and reporting environment optimization Integration within overall Information Architecture … improving the overall understanding of the business and leading to business agility … .. always stay focused on the business objectives when modeling

Questions? Contact details Chris Bradley Business Consulting Manager [email_address] +44 1225 475000 Ken Dunn Head of Information Architecture [email_address] +1 630 836 7805

Make models available to everyone

Survey Users: What benefits are you gaining from the service? We are not obtaining any benefits We are obtaining benefit through use of a common modelling tool We are obtaining benefit through utilisation of a common repository We are obtaining benefit through use of common standards, guidelines & processes We are obtaining benefit through re-use of models & artefacts We are obtaining benefit through provision of central support & help

Current position at BP Large # of SAP implementations Data take on most frequently via Idocs, XI Large population of SAP BW cubes BP standard data modelling tool is Embarcadero ER/Studio BP wide corporate repository of data models (ER/Studio Enterprise repository) Data Modelling – where did it all go wrong?

Incorporating SAP Metadata within your Information Architecture

More Related Content

What's hot (20)

Similar to Incorporating SAP Metadata within your Information Architecture (20)

More from Christopher Bradley (16)

Recently uploaded (20)

Incorporating SAP Metadata within your Information Architecture

Editor's Notes