“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
3. Chris Bradley Recent speaking engagements: DAMA International (DAMA / Wilshire), March 5th -8th 2007, Boston, MA “Data as a service” “Panel of Data Modelling experts” CDi_MDM Summit (IRM UK), April 30 – May 2nd 2007, London, “A Data Architecture for Data Governance” DAMA UK: June 15th 2007, London, “Data Modelling – Where did it all go wrong?” Data Governance Conference, (Debtech / Wilshire) June 25 -28, 2007, San Francisco, CA, “Data Architecture for Governance – case study” IPL & Embarcadero seminar series: (Bristol, London, Manchester, Edinburgh), October 2007, “Data Modelling – Where did it all go wrong?” DQ/IM & DAMA Europe (IRM London), November 2007, “Data Modelling as a service” Data Governance Conference: (Debtech / Wilshire) Florida, December 2007, “Data Governance 2.0” DAMA International: (DAMA / Wilshire), March 16th – 21st 2008, San Diego, CA. “Modelling for SoA” “XML amd data models” DAMA International: (DAMA / Wilshire), March 16th – 21st 2008, San Diego, CA. “Establishing Data Modelling as a Service in BP” BPM Europe: (IRM), September 2008, London: “BPMN for Dummies” DAMA Europe: (IRM / DAMA), November 2008, London, “BPMN for Dummies”“Data Modelling as a service” Data Governance Europe Sysmposia: (IRM / Debtech; London), February 2009, “Data Governance Challenges in a Major Multi National” Webinar series: (Embarcadero Technologies & IPL), Oct 2008 – Feb 2009, “The New Formula for Success – Moving Data Modelling beyond the Database” Data Rage 2009: March 17-19 2009, “Evolve or Die – Modelling is not just for DBMS’s anymore”“Data Modelling as a service” 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” DAMA UK & BCS Data Management Group:, June 11th 2009; London, “Evolve or Die - Data Modelling is not just for DBMS’s” Chris Bradley Summary: 30 years Information Management experience MOD, Volvo, Thorn EMI, Coopers & Lybrand, IPL Sample Clients: BP, Enterprise Oil, Statoil, Exxon Mobil, Audit Commission, MoD, Merrill Lynch, Barclays, DoD, Imperial Tobacco, GSK …. Experience: Data Governance, Master Data Management, Enterprise Information Management Author & conference speaker CDMP(Master), CBIP, Prince2, APM Director DAMA UK & MPO BeyeNetwork Expert Channel Author “Information Asset Management” DAMA UK & BCS Data Management Group:, June 11th 2009; London, “Evolve or Die - Data Modelling is not just for DBMS’s” BPM Europe: (IRM), September 2009, London: ½ day workshop “An introduction to Data and the BPMN” Data Migration Matters: October 1st 2009, London, “Designing for Success” 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” Enterprise Data World International: (DAMA / Wilshire), March 14th – 19th 2010, San Francisco CA, “How to communicate with the business using high level models” IPL & DataFlux Seminar Series: (IPL/DataFlux), March 26th 2010, Bath, UK. “The Information Advantage – Exploiting Information Management For The Business” BeyeNETWORK Webinar: (CA/BeyeNETWORK), March 31st 2010, Webinar. “Communicating with the Business through high level data models” Enterprise Architecture Europe: (IRM), June 16th – 18th 2010, London: ½ day workshop “The Evolution of Enterprise Data Modelling” ECIM Exploration & Production: September 13th 15th 2010, Haugesund, Norway: “Information Challenges and Solutions” Information Management in Pharmaceuticals: September 15th 2010, London, “Clinical Information Management – Are we the cobblers children?” BPM Europe: (IRM), September 27th – 29th 2010, London, “Learning to Love BPMN 2.0” October 1st 2009The Kings Fund London
4. Chris Bradley Recent publications: Database Marketing Magazine, February 2009, “Preventing a Data Disaster”http://content.yudu.com/A12pnb/DMfeb09/resources/30.htm 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 BeyeNETWORK “Chris Bradley Expert Channel” Information Asset Managementhttp://www.b-eye-network.co.uk/channels/1554/ 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 Article: Information Management Deficiency Syndrome (September 2009)http://www.b-eye-network.co.uk/channels/1554/view/11216/ Article: Drowning in spreadsheets (September 2009)http://www.b-eye-network.co.uk/channels/1554/view/11482/ Article “Seven deadly sins of data modelling” (October 2009)http://www.b-eye-network.co.uk/view/11481 Article “How do you want yours served (data that is)” (December 2009)http://www.b-eye-network.co.uk/ Article “How Do You Want Your Data Served?” Conspectus Magazine (February 2010) Article “10 easy steps to evaluate Data Modelling tools” Information Management, (March 2010) Chris Bradley Summary: 30 years Information Management experience MOD, Volvo, Thorn EMI, Coopers & Lybrand, IPL Sample Clients: BP, Enterprise Oil, Statoil, Exxon Mobil, Audit Commission, MoD, Merrill Lynch, Barclays, DoD, Imperial Tobacco, GSK …. Experience: Data Governance, Master Data Management, Enterprise Information Management Author & conference speaker CDMP(Master), CBIP, Prince2, APM Director DAMA UK & MPO BeyeNetwork Expert Channel Author “Information Asset Management” October 1st 2009The Kings Fund London
5. shaun.davey@ipl.com Agenda 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
6. 1. What’s the problem? Intelligent Business Intelligent Business
7. 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
12. 2. Why bother modelling when implementing ERPs? ….. Intelligent Business
13. 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. “But its a done deal” So don’t you want to know if there are any gaps?
14. Why produce a data model? Top ten reasons: Capturing Business Requirements Promotes Reuse, Consistency, Quality Bridge Between Business and Technology Personnel Assessing Fit of Package Solutions Identify and Manage Redundant Data Sets Context for Project within the Enterprise Interaction Analysis: Compliments Process Model Pictures Communicate Better than Words Avoid Late Discovery of Missed Requirements Critical in Managing Integration Between Systems Survey of 200+ Data Modellers: 2008
15. Key reasons to produce a data model for ERP’s Requirements gathering Fit for purpose assessment Identifying gaps Data migration / take on Master Data alignment Data lineage (particularly important with Data Lineage & SoX compliance issues) Reporting (particularly Business Intelligence & Data Warehousing) But most importantly, for integration of the ERP metadata into your overall Information Architecture
16. HR example: Personnel tracking 1/9/2009 1/9/2012 1/1/2016 1/1/2007 Joe’s“Engagements” Expatriated to US UK Employee UK Employee Retiree Candidate DATA ON AN ENGAGEMENT Start & end date,Sponsor / Parent / Home Organisation, Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits) Joe’s “RoleAssignments” DATA ON A ROLE ASSIGNMENT Start & end date, Position (showing Job Type, Work Location, Working Time, Skills Requirements) Exploration Geophysical Consultant Trainee Geophysicist North Sea Geophysicist Sabbattical(No role assignment) GOM Geophysicist GOM GU Leader (pt time) GOM Geophysicist (pt time) North Sea Geophysicist 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.
17. The Corresponding ER Diagram 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”.
18. 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). Personal Details (e.g. Name, Bank Acct, Emergency Contact, Qualifications) Person Start & end date,Sponsor / Parent / Home Organisation, Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits) Engagement Org Unit Manager, Cost Centre Start & end date Position Role Assignment Job Type, Work Location, Working Time, Skills Requirements
19. 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. Personal Details (e.g. Name, Bank Acct, Emergency Contact, Qualifications) Person Manager, Cost Centre Org Unit 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 Position Role Assignment
20. An example of why the model matters to SAP HR Personal Details (e.g. Name, Bank Acct, Emergency Contact, Qualifications) Person Engagement Org Unit Start & end date,Sponsor / Parent / Home Organisation, Contractual Details (e.g. Employment Status, Level, Legal Entity, Salary, Benefits) Manager, Cost Centre Position Role Assignment Start & end date Job Type, Work Location, Working Time, Skills Requirements 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 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.
21. 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?
22. 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
23.
24.
25. “Where in SAP is the data I need?” “How are the tables related?” How can I explore SAP (without very expensive SAP consultants)? Challenge
26. Extract ‘useable’ metadata from ERPs Browse, subset Modelling tool interface Goal: metadata exploration for ERPs
27. Allows understanding of EA metadata without specialist application knowledge Typical projects Business Information/Data Warehousing Enterprise Metadatamanagement Impact analysis Application Integration Saphir
38. Lessons Learned - People SAP architects require careful handling. Avoid religious wars! 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!! Data Modellers require careful handling. Keep them focused on the business objective! We are not trying to create art! ….. remember people are people
41. 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
43. Lessons Learned - Technology Modelling tools need some help to get at meaningful ERP metadata Modellers should have access to a data profiling tool Specialist ERP metadata extraction tool alone is too detailed. Can’t point at complete SAP module and get a good result ….. technology is a means to an end, NOT the end in itself
45. 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 modelling
46. Effective IM IS crucial today Higher volumes of data generated by organisations Information is all pervasive – if you don’t have a strategy to manage it, you will certainly drown in it Proliferation of data-centric systems ERP, CRM, ECM… Greater demand for reliable information Accurate business intelligence is vital to gain competitive advantage, support planning/resourcing and monitor key business functions Tighter regulatory compliance Far more responsibility now placed on organisations to ensure they store, manage, audit and protect their data Business change is no longer optional – it’s inevitable Mergers/acquisitions, market forces, technological advances…
47.
48.
49. Why? Businesses NEED a common vocabulary for communication But ... Be aware of the baggage associated with the term “data modelling” It often works best if you don’t mention you’re doing “data modelling”
50. Now – That should clear up a few things around here! Businesses NEED a common vocabulary for communication “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.” Ken Orr, The Cutter Consortium