Incorporating ERP metadata in your data models

3,103
-1

Published on

“Opening Pandora’s box” - Why bother data model for ERP systems?



This presentation covers :
a. Why should you bother with data modelling when you’ve got or are planning to get an ERP?

i. For requirements gathering.

ii. For Data migration / take on

iii. Master Data alignment

iv. Data lineage (particularly important with Data Lineage & SoX compliance issues)

v. For reporting (Particularly Business Intelligence & Data Warehousing)

vi. But most importantly, for integration of the ERP metadata into your overall Information Architecture.

b. But don’t you get a data model with the ERP anyway?

i. Errr not with all of them (e.g. SAP) – in fact non of them to our knowledge

ii. What can be leveraged from the vendor?


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

i. What are the requirements?

ii. How to get inside the black box

iii. Is there any technology available?

iv. What about DIY?


d. So, what are the overall benefits of doing this:

i. Ease of integration
ii. Fitness for purpose
iii. Reuse of data artefacts

iv. No nasty data surprises

v. Alignment with overall data strategy

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,103
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • Chris introduce himself
  • TIM
  • After this, hand over to TIM
  • Gary Larson – The Far SideThanks to Alec Sharp.Next an example – break into groups.
  • Gary Larson – The Far SideThanks to Alec Sharp.Next an example – break into groups.
  • Incorporating ERP metadata in your data models

    1. 1. How do you include ERP metadata in your Information Architecture?<br />Chris Bradley<br />Business Consulting Director<br />chris.bradley@ipl.com+44 1225 475000<br />
    2. 2. Bath Rugby<br />Main sponsor2009-2010 season<br />2010-2011 season<br />
    3. 3. Chris Bradley Recent speaking engagements:<br />DAMA International (DAMA / Wilshire), March 5th -8th 2007, Boston, MA “Data as a service” “Panel of Data Modelling experts”<br />CDi_MDM Summit (IRM UK), April 30 – May 2nd 2007, London, “A Data Architecture for Data Governance”<br />DAMA UK: June 15th 2007, London, “Data Modelling – Where did it all go wrong?”<br />Data Governance Conference, (Debtech / Wilshire) June 25 -28, 2007, San Francisco, CA, “Data Architecture for Governance – case study”<br />IPL & Embarcadero seminar series: (Bristol, London, Manchester, Edinburgh), October 2007, “Data Modelling – Where did it all go wrong?”<br />DQ/IM & DAMA Europe (IRM London), November 2007, “Data Modelling as a service”<br />Data Governance Conference: (Debtech / Wilshire) Florida, December 2007, “Data Governance 2.0”<br />DAMA International: (DAMA / Wilshire), March 16th – 21st 2008, San Diego, CA. “Modelling for SoA” “XML amd data models” <br />DAMA International: (DAMA / Wilshire), March 16th – 21st 2008, San Diego, CA. “Establishing Data Modelling as a Service in BP” <br />BPM Europe: (IRM), September 2008, London: “BPMN for Dummies”<br />DAMA Europe: (IRM / DAMA), November 2008, London, “BPMN for Dummies”“Data Modelling as a service”<br />Data Governance Europe Sysmposia: (IRM / Debtech; London), February 2009, “Data Governance Challenges in a Major Multi National”<br />Webinar series: (Embarcadero Technologies & IPL), Oct 2008 – Feb 2009, “The New Formula for Success – Moving Data Modelling beyond the Database”<br />Data Rage 2009: March 17-19 2009, “Evolve or Die – Modelling is not just for DBMS’s anymore”“Data Modelling as a service”<br />Enterprise Data World International: (DAMA / Wilshire), April 5th -12th 2009, Tampa FL, “Exploiting Models for effective SAP implementations” Chairing panel of experts “Keeping modelling relevant”Panel of experts “Issues in information internationalisation”“Modelling is not just for RDBMS’s”<br />DAMA UK & BCS Data Management Group:, June 11th 2009; London, “Evolve or Die - Data Modelling is not just for DBMS’s”<br />Chris Bradley Summary:<br />30 years Information Management experience<br />MOD, Volvo, Thorn EMI, Coopers & Lybrand, IPL<br />Sample Clients: BP, Enterprise Oil, Statoil, Exxon Mobil, Audit Commission, MoD, Merrill Lynch, Barclays, DoD, Imperial Tobacco, GSK ….<br />Experience: Data Governance, Master Data Management, Enterprise Information Management<br />Author & conference speaker<br />CDMP(Master), CBIP, Prince2, APM<br />Director DAMA UK & MPO<br />BeyeNetwork Expert Channel Author “Information Asset Management”<br />DAMA UK & BCS Data Management Group:, June 11th 2009; London, “Evolve or Die - Data Modelling is not just for DBMS’s”<br />BPM Europe: (IRM), September 2009, London: ½ day workshop “An introduction to Data and the BPMN”<br />Data Migration Matters: October 1st 2009, London, “Designing for Success”<br />Data Management & Information Management Europe: (DAMA / IRM), November 2-5 2009, London, “Modelling is NOT just for DBMS’s anymore”“Meet the Metadata Professional Organisation”<br />Enterprise Data World International: (DAMA / Wilshire), March 14th – 19th 2010, San Francisco CA, “How to communicate with the business using high level models”<br />IPL & DataFlux Seminar Series: (IPL/DataFlux), March 26th 2010, Bath, UK. “The Information Advantage – Exploiting Information Management For The Business”<br />BeyeNETWORK Webinar: (CA/BeyeNETWORK), March 31st 2010, Webinar. “Communicating with the Business through high level data models”<br />Enterprise Architecture Europe: (IRM), June 16th – 18th 2010, London: ½ day workshop “The Evolution of Enterprise Data Modelling”<br />ECIM Exploration & Production: September 13th 15th 2010, Haugesund, Norway: <br />“Information Challenges and Solutions”<br />Information Management in Pharmaceuticals: September 15th 2010, London, <br />“Clinical Information Management – Are we the cobblers children?”<br />BPM Europe: (IRM), September 27th – 29th 2010, London, “Learning to Love BPMN 2.0”<br />October 1st 2009The Kings Fund<br />London<br />
    4. 4. Chris Bradley Recent publications:<br />Database Marketing Magazine, February 2009, “Preventing a Data Disaster”http://content.yudu.com/A12pnb/DMfeb09/resources/30.htm<br />Data Modelling For The Business – A Handbook for aligning the business with IT using high-level data models; Technics Publishing; ISBN 978-0-9771400-7-7; http://www.amazon.com/Data-Modeling-Business-Handbook-High-Level/dp/0977140075/ref=sr_1_4?ie=UTF8&s=books&qid=1235660979&sr=1-4<br />BeyeNETWORK “Chris Bradley Expert Channel” Information Asset Managementhttp://www.b-eye-network.co.uk/channels/1554/<br />Article “Data Modelling is NOT just for DBMS’s” (July 2009)http://www.b-eye-network.co.uk/channels/1554/view/10748 and (August 2009) http://www.b-eye-network.co.uk/view/10986<br />Article: Information Management Deficiency Syndrome (September 2009)http://www.b-eye-network.co.uk/channels/1554/view/11216/<br />Article: Drowning in spreadsheets (September 2009)http://www.b-eye-network.co.uk/channels/1554/view/11482/<br />Article “Seven deadly sins of data modelling” (October 2009)http://www.b-eye-network.co.uk/view/11481<br />Article “How do you want yours served (data that is)” (December 2009)http://www.b-eye-network.co.uk/<br />Article “How Do You Want Your Data Served?” Conspectus Magazine (February 2010)<br />Article “10 easy steps to evaluate Data Modelling tools” Information Management, (March 2010)<br />Chris Bradley Summary:<br />30 years Information Management experience<br />MOD, Volvo, Thorn EMI, Coopers & Lybrand, IPL<br />Sample Clients: BP, Enterprise Oil, Statoil, Exxon Mobil, Audit Commission, MoD, Merrill Lynch, Barclays, DoD, Imperial Tobacco, GSK ….<br />Experience: Data Governance, Master Data Management, Enterprise Information Management<br />Author & conference speaker<br />CDMP(Master), CBIP, Prince2, APM<br />Director DAMA UK & MPO<br />BeyeNetwork Expert Channel Author “Information Asset Management”<br />October 1st 2009The Kings Fund<br />London<br />
    5. 5. shaun.davey@ipl.com<br />Agenda<br />What’s the problem?<br />Why should you bother with data modelling when you’ve got or planning to get an ERP? <br />How can you incorporate SAP metadata into your overall model?<br />Lessons learned & benefits<br />
    6. 6. 1. What’s the problem?<br />Intelligent Business<br />Intelligent Business<br />
    7. 7. Problems in Getting Metadata from ERPs<br />Database System Catalog does not hold useful metadata<br />No PK or FK Constraints in the Database<br />Proprietary ERP DD holds ‘Logical View’ of data<br />
    8. 8. SAP Physical Database…<br />
    9. 9. …70,000 Islands of Information<br />
    10. 10. ...Need intelligible metadata<br />
    11. 11. … and understandable Analytical Structures<br />
    12. 12. 2. Why bother modelling when implementing ERPs? …..<br />Intelligent Business<br />
    13. 13. ERP & packaged systems<br />“We don’t need a data model – the package has it all”<br />But, does it …<br />Meet your business requirements?<br />Logical Data Model will aid configuration / fit for purpose evaluation<br />Have identical data structures & meanings as your legacy systems?<br />Logical Data model will aid Data Integration, Legacy Data take on and Master Data integration.<br />“But its a done deal”<br />So don’t you want to know if there are any gaps?<br />
    14. 14. Why produce a data model?<br />Top ten reasons:<br />Capturing Business Requirements <br />Promotes Reuse, Consistency, Quality<br />Bridge Between Business and Technology Personnel<br />Assessing Fit of Package Solutions<br />Identify and Manage Redundant Data<br />Sets Context for Project within the Enterprise <br />Interaction Analysis: Compliments Process Model<br />Pictures Communicate Better than Words<br />Avoid Late Discovery of Missed Requirements <br />Critical in Managing Integration Between Systems<br />Survey of 200+ Data Modellers: 2008<br />
    15. 15. Key reasons to produce a data model for ERP’s<br />Requirements gathering<br />Fit for purpose assessment<br />Identifying gaps <br />Data migration / take on <br />Master Data alignment <br />Data lineage (particularly important with Data Lineage & SoX compliance issues) <br />Reporting (particularly Business Intelligence & Data Warehousing) <br />But most importantly, for integration of the ERP metadata into your overall Information Architecture <br />
    16. 16. HR example: Personnel tracking<br />1/9/2009<br />1/9/2012<br />1/1/2016<br />1/1/2007<br />Joe’s“Engagements”<br />Expatriated to US<br />UK Employee<br />UK Employee<br />Retiree<br />Candidate<br />DATA ON AN ENGAGEMENT<br />Start & end date,Sponsor / Parent / Home Organisation,<br />Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits)<br />Joe’s “RoleAssignments”<br />DATA ON A ROLE ASSIGNMENT<br />Start & end date,<br />Position (showing Job Type, Work Location, Working Time, Skills Requirements)<br />Exploration Geophysical<br />Consultant<br />Trainee Geophysicist<br />North Sea<br />Geophysicist<br />Sabbattical(No role assignment)<br />GOM Geophysicist<br />GOM<br />GU Leader<br />(pt time)<br />GOM Geophysicist<br />(pt time)<br />North Sea<br />Geophysicist<br />In this model a person goes through a sequence of “Engagements” (in this example: candidate, employee, expat, employee, retiree).<br />For each Engagement, the positions filled are indicated by “Role Assignments”, showing start and end date in each position.<br />
    17. 17. The Corresponding ER Diagram<br />Engagement<br />Role<br />Assignment<br />This is showing that “Role Assignment” is subordinate to “Engagement”.<br />i.e. you can’t set up a Role Assignment until you have an Engagement to relate it to.<br />An everyday language example: “Joe Bloggs’ role as Trainee Geophysicist falls under his UK contract of employment dated 1/1/2007”.<br />
    18. 18. Model 1 One way of keeping track of people…<br />In this model a person goes through a sequence of “Engagements” (e.g. candidate, employee, expat, employee, sabbatical, employee, retiree).<br />For each Engagement, the positions filled are indicated by “Role Assignments”, showing start and end date in each position.<br />Each Position is part of an Organisation Unit, which in turn is part of a higher organisation unit, and so on.<br />A Position is filled by different people over time (i.e. the various Role Assignments to one Position can be for different people).<br />Personal Details (e.g. Name, Bank Acct,<br />Emergency Contact, Qualifications)<br />Person<br />Start & end date,Sponsor / Parent / Home Organisation,<br />Contractual Details (e.g. Employment Status,<br />Level, Legal Entity, Salary, Benefits)<br />Engagement<br />Org Unit<br />Manager, Cost Centre<br />Start & end date<br />Position<br />Role<br />Assignment<br />Job Type, Work Location,<br />Working Time, Skills Requirements<br />
    19. 19. Model 2 One possible simplification<br />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.<br />Personal Details (e.g. Name, Bank Acct,<br />Emergency Contact, Qualifications)<br />Person<br />Manager, Cost Centre<br />Org Unit<br />Start & end date,Sponsor / Parent / Home Organisation,<br />Contractual Details (e.g. Employment Status,<br />Level, Legal Entity, Salary, Benefits)<br />Job Type, Work Location,<br />Working Time, Skills Requirements<br />Position<br />Role<br />Assignment<br />
    20. 20. An example of why the model matters to SAP HR<br />Personal Details (e.g. Name, Bank Acct,<br />Emergency Contact, Qualifications)<br />Person<br />Engagement<br />Org Unit<br />Start & end date,Sponsor / Parent / Home Organisation,<br />Contractual Details (e.g. Employment Status,<br />Level, Legal Entity, Salary, Benefits)<br />Manager, Cost Centre<br />Position<br />Role<br />Assignment<br />Start & end date<br />Job Type, Work Location,<br />Working Time, Skills Requirements<br />This data field recorded on an Engagement might be better implemented as this relationship between the Engagement and an Org Unit. There arepowerful 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’ssponsor/parent/home gets lost as org units are merged, split, or dissolved; e.g. workflow can route transactions seamlessly via sponsor/parent/home<br />when appropriate, rather than as now by using host org unit as a proxy with manual interventions (this applies to salary review & developmentdecisions, for example). Adding the red relationshipis a configuration choice in SAP. SAP is “vanilla” with it or without it.<br />
    21. 21. There are many decisions.Some examples, if we started from model 1…<br />Allow simultaneous Role Assignments?<br />Allow cost-centres only on Position?<br />Allow hierarchy of Org Units, or Positions, or both?<br />NB ALL options here are “Vanilla SAP”<br />Data Modelling – where did it all go wrong?<br />
    22. 22. Data integration & lineage<br />Data take on into SAP<br />Are source & target definitions = ?<br />Load tables or Idocs?<br />Still need the basics:<br />SOX lineage requirements<br />Repository based Data migration design = Consistency<br />Legacy data take on<br />Source to target mapping<br />Reverse engineer & generate ETL<br />Impact analysis <br />
    23. 23. MI / BI / DW<br />Model Data requirements in Dimensional Model<br />Must start from understanding of existing data landscape<br /><ul><li>Capture rich metadata via reverse engineering BW Info Cubes, BO Universes, …….
    24. 24. Generate Star, Snowflake, Star flake schemas</li></li></ul><li>3. How can you incorporate SAP metadata into your overall model? <br />
    25. 25. “Where in SAP is the data I need?”<br />“How are the tables related?”<br />How can I explore SAP (without very expensive SAP consultants)?<br />Challenge<br />
    26. 26. Extract ‘useable’ metadata from ERPs<br />Browse, subset<br />Modelling tool interface<br />Goal: metadata exploration for ERPs<br />
    27. 27. Allows understanding of EA metadata without specialist application knowledge<br />Typical projects<br />Business Information/Data Warehousing<br />Enterprise Metadatamanagement<br />Impact analysis <br />Application Integration <br />Saphir<br />
    28. 28.
    29. 29. Search by description or table name<br />
    30. 30. Sort by child/parent tables to find “master” tables<br />
    31. 31. View table and field information<br />
    32. 32. Navigate relationships<br />
    33. 33. Application Hierarchy & Program tree<br />
    34. 34. Get information from screens<br />X<br />X<br />X<br />
    35. 35. LDM Project Review - Approach to Developing the Model<br />Approach<br />Identify relevant processes (Process Scope Matrix)<br />Identify relevant T-codes for each process<br />Utilize SAP Screens, Process Documentation, and Database Analysis to identify candidate data elements<br />Model - Master Data -> Transactional Data -> BW Data<br />Development Process<br />Identified thru <br /><ul><li> SAP Screens
    36. 36. Process Documentation
    37. 37. SAP Database (Saphir)</li></li></ul><li>4. Lessons learned & benefits?<br />
    38. 38. Lessons Learned - People<br />SAP architects require careful handling. Avoid religious wars!<br />Developers require careful handling. Get them comfortable with using the models (may require training). Avoid DIY ABAP’s to re-invent model!<br />Management require very careful handling. Continually demonstrate value!! <br />Data Modellers require careful handling. Keep them focused on the business objective! We are not trying to create art!<br />….. remember people are people<br />
    39. 39.
    40. 40. Make models available to everyone<br />
    41. 41. Lessons Learned - Process<br />Use the right tool for the job<br />Work closely with project team and process modelers<br />Work directly with SME and get continuous feedback<br />Get involved in projects early (ideally before the ERP has been selected and definitely before it has been configured)<br />Look for value in the maintenance cycle (interface maintenance, XML maintenance, cube rationalization)<br />….. always be part of the team<br />
    42. 42. Minimize Administration<br />
    43. 43. Lessons Learned - Technology<br />Modelling tools need some help to get at meaningful ERP metadata<br />Modellers should have access to a data profiling tool<br />Specialist ERP metadata extraction tool alone is too detailed. Can’t point at complete SAP module and get a good result<br />….. technology is a means to an end, NOT the end in itself<br />
    44. 44. Avoid the Death star!<br />
    45. 45. There are lots of benefits<br />Requirements gathering … leading to focused evaluation and good configuration<br />Data migration / take on … from clear definitions, accountabilities and high quality<br />Master Data alignment … facilitating establishment of master data single version of truth<br />Data lineage … driving down the cost of integration<br />Reporting … and reporting environment optimization<br />Integration within overall Information Architecture … improving the overall understanding of the business and leading to business agility<br />….. always stay focused on the business objectives when modelling<br />
    46. 46. Effective IM IS crucial today<br />Higher volumes of data generated by organisations<br />Information is all pervasive – if you don’t have a strategy to manage it, you will certainly drown in it<br />Proliferation of data-centric systems<br />ERP, CRM, ECM…<br />Greater demand for reliable information<br />Accurate business intelligence is vital to gain competitive advantage, support planning/resourcing and monitor key business functions<br />Tighter regulatory compliance<br />Far more responsibility now placed on organisations to ensure they store, manage, audit and protect their data<br />Business change is no longer optional – it’s inevitable<br />Mergers/acquisitions, market forces, technological advances…<br />
    47. 47.
    48. 48.
    49. 49. Why?<br />Businesses NEED a common vocabulary for communication<br />But ...<br />Be aware of the baggage associated with the term “data modelling”<br />It often works best if you don’t mention you’re doing “data modelling”<br />
    50. 50. Now – That should clear up a few things around here!<br />Businesses NEED a common vocabulary for communication<br />“Ultimately, poor data quality is like dirt on the windshield. You may be able to drive for a long time with slowly degrading vision, but at some point you either have to stop and clear the windshield or riskeverything.”<br />Ken Orr, The Cutter Consortium<br />
    51. 51. 5. Contact details<br />I<br />Intelligent Business<br />
    52. 52. Further information:<br />Articles including:<br /><ul><li>Seven deadly sins of data modelling
    53. 53. The IT Credibility Crunch
    54. 54. Information Management Deficiency Syndrome
    55. 55. Modelling is not just for DBMS’s
    56. 56. Data mining - where’s my hard hat?
    57. 57. Master data mix-ups
    58. 58. Drowning in spreadsheets
    59. 59. Why bother with a semantic layer?
    60. 60. Business Intelligence in a cold climate
    61. 61. Data Management is everybody's business</li></ul>Download from:http://www.ipl.com/services/businessconsulting<br />
    62. 62. Contact details<br />Chris Bradley<br />Business Consulting Director<br />Chris.Bradley@ipl.com<br />+44 1225 475000<br />

    ×