• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Multiple Database Syndrome:  Symptoms, Risks  and Possible Cures
 

Multiple Database Syndrome: Symptoms, Risks and Possible Cures

on

  • 1,025 views

Many organisations still have multiple data repositories, leading to data integrity issues, the inability to see a complete picture of a customer/supporter, the risk of multiple concurrent contact and ...

Many organisations still have multiple data repositories, leading to data integrity issues, the inability to see a complete picture of a customer/supporter, the risk of multiple concurrent contact and many other data diseases and CRM/fundraising follies. I explain what benefits organisations could get if they address this problem and the options they can pursue: from a single, central database to data integration and a single supporter view.

Statistics

Views

Total Views
1,025
Views on SlideShare
1,020
Embed Views
5

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 5

http://www.techgig.com 2
http://www.linkedin.com 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • - Not just “databases”, spreadsheets etc too If someone says, But I don’t want my data on any other system in case someone tries to contact them…explain that won’t work Also shows how Technology is relatively speaking the easy bit…
  • Showing these to show the benefits from a single db/reduced dbs … and because depending on your primary goal, there may be different/better technical solutions Take care about “Better CRM…”
  • Are more options but these are first to consider… Single db: Pros: simpler, no data transfer, single view, can be used by fundraisers/supp care/marketing, all in one place Cons: breadth of data (not so much volumes), breadth of/does it support functions? complexity of data mgt, behemothical, transactions vs summary Single db with Marketing repository (BBDM, SPSS, Occam’s Alterian, Access/Excel) But do consider first, even if have to compromise (e.g. arts and Excel for events) Single view (with multiple source dbs) Or 360 degree, SCV etc First, if just for Marketing (analysis, cross-mktng, mailshots, RFM etc) ETL diagram Discuss basic writebacks (comms – then deceased, opt-ins/outs, addresses?) For Deceased et al: suggest date/source stamp all such updates, relies on source data being correct and same format/structure etc All updates through source dbs, even if electronically from Marketing db Second, “single view”, e.g. for Supporter Services, maybe fundraising Leads to updating on Single View too, which leads to 2 way synch 2 way issues: continual bounce-back updates, 2 updates done same day on 2 dbs, delete support, adding new cons, guaranteed message delivery – real time?? RE et al as the “pseudo-SCV” Synch software “in middle”
  • - Streamlining: compromises may have to be made; e.g. events team spreadsheets, Arts orgs using RE & Excel

Multiple Database Syndrome:  Symptoms, Risks  and Possible Cures Multiple Database Syndrome: Symptoms, Risks and Possible Cures Presentation Transcript

  • Multiple Database Syndrome: Symptoms, Risks and Possible Cures Ivan Wainewright [email_address] http://blog.itforcharities.co.uk @itforcharities
  • Today
    • Symptoms…
    • Risks/Benefits
    • Possible Cures
    • How to Approach Your Requirements
    • Please Ask Questions and Feedback Your Experiences!
    [email_address]
  • Symptoms “ I didn’t know that Josh had run the Marathon for us last year” “ Every time we find out someone has died, we have to update 4 different systems” “ Our web system and supporter database don’t talk to each other” “ When we run a large mailing we always have to dedupe the different systems manually” “ The events team have their own spreadsheets…” “ Our volunteers have received 3 letters from us in one week – from 3 different departments” [email_address]
  • Why organisations want to prevent multiple databases
    • Better Supporter Care
    • Improve Efficiency
      • Simplicity
      • Data integrity, accuracy, consistency, updates…
      • Save costs (?!)
    • Marketing & Fundraising Opportunities
      • Better marketing/targeting/data mining /predictive modelling
      • Cross-marketing
      • Raise higher income / higher average donation
      • Increase donor retention
      • Prevent multiple approaches
      • Maximise opportunities
    • Support Central Communication/Fundraising Strategy
    • Help comply with data protection
    • Better CRM
    [email_address]
  • Possible Cures… Single Database Single View Marketing/Analysis data repository [email_address]
  • Single Database with Marketing Analysis/Data Repository Single Database Marketing/Analysis data repository [email_address]
  • Single View – One Way Flow ETL – Extract Transform Load Single View – Read Only, All updates done in Source Databases Source Databases Mailings etc [email_address]
  • Single View – Two Way Synchronisation ETL – Extract Transform Load Updates can be done in the SSV and/or Source databases Source Databases [email_address]
  • Challenges of Maintaining/ Synchronising Multiple Databases
    • 2 way synchronisation
    • What if different source databases have different data structures (entities) or different data formats (e.g. name/address fields/structure, opt-ins/outs, deceased flags)
      • Not just about “format” but different meanings of “same field”, one-to-one or one-to-many
      • And what if any of these source data structures change
    • Only as good as the source data
    • Up-to-dateness / ‘Time lag’ in updates
    • Can be technical
    • Cost & effort
    [email_address]
  • How to Approach Your Requirements
    • Internal research: database audit, data audit, functional capabilities, requirement gathering
      • Cross-over analysis on existing databases
    • Any simple streamlining?
    • Create a business case
    • Ensure budget is realistic
    • Create a project team
    • Do you need a formal RFP/ITT?
    • Implementation…
    • Change Management
    [email_address]
  • Top Tips
    • It’s gonna cost you…
      • Plan for all costs
    • If you can use a single database, do!
    • (Mostly) If you move to a single database, remember Change Management
    • If you need multiple databases, try to keep data flows as simple as possible; preferably one way flows
      • Avoid 2 way integration whenever possible
    • A single view is only as good as the source data
    • Remember Business As Usual during any implementation
    [email_address]
  • White Papers, Resources & Web sites
    • www.scribesoft.com/white-papers.asp
    • www.sas.com/whitepapers/index.html
    • www.marketingweek.co.uk/driving-value-from-the-single-customer-view/3015497.article
    • www.itforcharities.co.uk
    • LinkedIn group: Achieving a Single Customer View
    [email_address]
  • Thank You http://blog.itforcharities.co.uk @itforcharities [email_address]