1 / 15

Cisco's Journey Towards Cleaner Customer Data

Explore Cisco's history of Oracle eBusiness Suite implementation, the challenges with customer data, and their data consolidation methodology. Learn from their lessons and recommendations for others. Q&A included.

rosiemorgan
Download Presentation

Cisco's Journey Towards Cleaner Customer Data

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cisco's Journey Towards Cleaner Customer Data Tina Owenmark, Program Manager, Cisco David Joffe, Applications Architect, Abacus Business Solutions

  2. Agenda • Brief History of Oracle eBusiness Suite at Cisco • Customer Data at Cisco • Cisco’s Data Consolidation Methodology • Lessons Learned / Recommendations for others • Q & A

  3. Oracle eBusiness Suite at Cisco New instances were gradually introduced to support different geos, modules and business needs 2007 1995 1998 2003 - 5 First Oracle implementation, R10.4 10.7 Upgrades in advance of Y2K First R12 instance live at Cisco All instances upgraded to R11i • Current state: Cisco has 10 production Oracle eBusiness Suite instances that are all R11i or R12. • Many instances are highly customized AND have complex integrations with each other and with external non-Oracle EBS systems

  4. Customer Data at Cisco • Cisco has over 2.5 million customer accounts and 6.4 million customer addresses in its core Quote to Cash instances • Customer data can be created through a variety of applications and flows • Customer data is synchronized across multiple EBS and non-EBS instances through Customer Data Hub like replication methodology • More than one million customer accounts are logical duplicates

  5. Why customer data cleanup? Bad / duplicate customer data causes: • Challenges in automating reporting process • Performance problems • User confusion / dissatisfaction • Difficulty in executing future projects Project formed to: • Reduce amount of duplicates by inactivating records

  6. Defining Business Rules: Iterative Approach • Apply proposed steps manually to several sample customers • Review results with all affected teams • Refine steps, re-apply to other customers • Continue to refine steps iteratively until the wider team feels comfortable • Develop scripts to automate many of the consolidation steps

  7. Data Consolidation Steps • Identify a batch of potential duplicates according to company name • Collect and compare attributes of all the records • Gather stats about transactional utilization of each record • Decide which records to keep and which records to consolidate • Validate that candidate records are eligible for inactivation • Inactivate the appropriate records • Move useful auxiliary data from the inactivated records to the keeper records • Update transactional data • Propagate changes to downstream systems

  8. Identify Potential Duplicates: Simple Match

  9. Identify Potential Duplicates: Complex Match • Using more complex methodology (DQM based) finds more matches • Downside: some may be false duplicates. Need to find right balance

  10. Decide which records to keep • Our rules generally involve keeping the records that are most transactionally active • Our data analysis has shown that consistently usage of the records is highly skewed to one or a few records

  11. Validate Inactivation Candidates • Functional teams have provided various conditions under which records may not be consolidated • Conditions may be based on attributes, auxiliary data, or transaction data (from internal or external databases) Examples: • Do not inactivate records that are used in EDI transactions • Do not inactivate records that have special tax set ups

  12. Inactivate and Consolidate • Critical data is copied from the inactivated record to the keeper record according to business rules: Examples: address, contacts, address level credit profiles • Only copy data that: • Does not exist already on the KEEPER record • Is actively used in transaction systems

  13. Update Transactional Data as Necessary • It is not generally mandatory to repoint the transaction records • Sales Orders and Invoices • For certain business functions, it is required that transactional data should be updated • Service Contracts and Install Base • Recommend attempting to discourage updates to transaction data as much as possible unless there is a very critical reason cited • Reasons to discourage transactional updates: • Can take a long time to execute and can cause performance / downstream impacts

  14. Keys to Driving Successful Deployment • Gradual rollout • MANY functional teams need to participate, provide rules, and give buy off. • Provide LOTS of data to increase affected teams’ confidence • Start strict, analyze results, and loosen rules as appropriate • Treat data cleanup as an ongoing, repeatable process and not a one time activity • Consider downstream and external impacts • Log and publish errors and results

More Related