150 likes | 348 Views
Cisco's Journey Towards Cleaner Customer Data. Tina Owenmark, Program Manager, Cisco David Joffe, Applications Architect, Abacus Business Solutions. Agenda. Brief History of Oracle eBusiness Suite at Cisco Customer Data at Cisco Cisco’s Data Consolidation Methodology
E N D
Cisco's Journey Towards Cleaner Customer Data Tina Owenmark, Program Manager, Cisco David Joffe, Applications Architect, Abacus Business Solutions
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
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
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
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
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
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
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
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
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
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
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
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