The Case for 8/8/2011. Agenda. Panel. Practical Steps to Get Started

Transcription

1 The Case for Master Data Management Mark Raabe Director of Application Services Faegre & Benson LLP Thad Jampol Chief Technology Officer IntApp Panel Mark Raabe Director of Application Services, Faegre & Benson LLP (Minneapolis) 450+ attorneys / 1100 users / 6 offices worldwide / All forms of corporate law Responsible for: Application Development / Application Administration / Business Analysis / Enterprise Architecture Thad Jampol p Chief Technology Officer, IntApp 12+ Years of Legal IT Experience Responsible for: Product and Technology Architecture / Product Strategy 1

2 1 Enterprise Architecture & Master Data Textbook: The authoritative, reliable foundation for data used across many applications and constituencies with the goal to provide a single view of the truth no matter where it lies. Reality: A consolidated approach to managing data with the intent of providing improved quality, integrity, and visibility to a firm s most valuable asset (it s data). 2

3 Types of MDM Registry Technique Authoring at spokes Cross reference only (data not stored in hub) Consolidation Technique Co existence Technique Authoring at spokes and hub (not subscription) Cross reference and golden record stored in hub Maps attributes to common data model Transactional Technique Authoring at spokes and hub (spokes consume changes) Maps attributes to common data model Cross reference and golden record stored in hub We already have a Data Warehouse Data Warehouse Master Data Directory Repository of transactions (record of past activity) Repository of metadata (record of living information) Used for reporting and analytics Used as part of active business processes Not a source of data consumed by other applications Data consumed, used and updated by other applications Stores only a partial picture of entity type Stores a complete picture of entity type 2 3

4 Common Approach to Data Management Legend New Personnel New Business Contact Mgmt. Script (Yours) Connector (Vendor s) + More Manual Strategic Implications for IT Effectively, you don t own your own data Applicationdeployments are painful, slow and resource intensive In several instances 40% time / cost spent on integration, data quality Vendor lock in and dependence Progress on strategic firm projects is slowed by poor data management. Strategic Implications for Business Impaired decision making ability No 360 degree view of a client, matter, user, etc. No consistency in data for business and customer intelligence Decreased operational flexibility Mergers and acquisitions impact operations Increased risk around regulations and security Data management must be considered a central part of a business strategy. 4

5 Real Value Master Data Directory: Business Intelligence (Utilization, Profitability) Use of Technology Based on Integrated Information (Portal, Search, CRM) / Application Upgrades Firm Growth (New Offices, Mergers) Process Efficiency (Intake, Provisioning) Risk Mitigation (Regulatory Requirements, Data Security) Technology Business 3 Building A Master Data Directory Example: Firm Personnel Create a system of record Master Data Directory Data Integration Platform ID Number Billing Rate Location Etc Source Applications 5

6 1. Get Buy In Find a reason to do this that impacts the business in a real way Process challenges: It takes 3 weeks to get a new attorney access to all required systems! Data quality challenges: We have to do hours of manual massaging of data for us to generate accurate financial reports. Is there a pre existing funded project to tie this to? Matter Centricity New Business Intake User Provisioning Business Intelligence 2. Make Design Decisions Pick your data elements Tip: Start SMALL Define your object model Free yourself from the vendor s design: Desc1, Desc2, Desc3 might not be the best way to store a Name Do you need a front end? (phase 2) What s the purpose? Data Synchronization Data Storage Where in your data flow does the MDD sit? 3. Select the Data Start with a single a data element or business object User Group Client Matter Outline the data shared between systems Assign authoritative datasources Define destinations 6

7 4. Build the Schema Define your data model Understand the change process for the data elements Think flexibility and extensibility (build for the future) Normalization Change logs 5. Build the Integrations Source your data What are the events of interest? Destinations When should destinations receive data? What transformations are required? On what frequency do destinations need to be updated? Build flexibility into rules Additional events Additional systems Minimize dependency on source system 4 7

8 Case Study: MDM K&L Gates Pittsburgh 36 Offices 1800 Attorneys Case Study: MDM White & Case Philadelphia 37 Offices 1800 Attorneys Case Study: MDM Baker Donelson Memphis 16 Offices 550 Attorneys 8

9 5 A Better Way Master Data Directory Personnel Data Client Data Matter Data Group Data Contact Data Etc Unified Data Model for Legal Information Architecture What are the key pieces of information for each entity/process? Where are the sources of that information? Who changes that information and by what means? How do changes need to be communicated to other consumers? Beyond this Session Peer Collaboration Vendors & Firms 9

10 Vendor Management Educate your vendors about your data expectations Post installation, firms should control their data Support tfirm driven di efforts vs. professional services No proprietary formats No lock in No non standard integration mechanisms Q & A Keep us posted on your projects! mraabe@faegre.com thad.jampol@intapp.com 10