Testinvoices - DQM


Published on

Published in: Business
  • Be the first to comment

Testinvoices - DQM

  1. 1. Controlling Telecommunications Data Quality with<br />Test Invoices<br />
  2. 2. Folie 2<br />Stakeholder interests in Test Invoices<br />High qualityinvoicingprocess!<br />Preventlossofincome,<br />Guaranteecustomersatisfaction.<br />Telecommunications Company<br />Write thecorrectinvoices!<br />Every invoicepositionisjustified - and<br />Noinvoiciepositionisomitted.<br />IT division<br />Write theinvoicescorrect!<br />Every invoicepositionispricedasspecified.<br />System Billing Team<br />Even whenweassumethat QA discovers all functionaldefects:<br />Ifthepatchingprocessisdefective, QA did not testwhatisrunning on the live system.<br />Ifthecustomerdataisalreadywrong in CRM, Billing worksunderwrongpremises.<br />Ifthe CRM-Billing interfaceismalfunctioning, billingtests will not reflectreality.<br />Why Quality Assurance aloneisnosolution<br />Currently, we send out toomanywronginvoices!<br />The knownproblem<br />
  3. 3. Chronologyoftestinvoices (offline billing)<br /><ul><li>Depending on severity, a fix cycleisintroduced:
  4. 4. Hotfix Patch (normal)
  5. 5. Repeat Transfer or Data Migration
  6. 6. Repeat Rating (in severecases)
  7. 7. Repeat Test Invoicesprocess</li></ul>In caseofdefects<br /><ul><li>After patching, wewaitforthecustomerdata update,
  8. 8. After eachdatatransfercycle,
  9. 9. A Rating process will beexecuted
  10. 10. Afterwards, testinvoicesaregenerated
  11. 11. After testinvoicesareapproved
  12. 12. The final invoicesaregenerated</li></ul>Every month<br />01.xx.<br />31.xx<br />Patchday<br />CRM-Billing Transfer<br />Rating<br />Test Invoice<br />CRM-Billing Transfer<br />Rating<br />Test Invoice<br />Live Billing<br />Live Billing<br />
  13. 13. Minimizingefforts<br />Take an orthogonal slice fromthesetoffunctionaltests.<br />Toguaranteeswiftandcost-effectivegeneration:<br /><ul><li>Stratified sample ofcustomerdatain theclasses:
  14. 14. Generated in CRM sincethe last patch
  15. 15. Affectedby a usecaseimplementedsince last patch</li></ul>Toguaranteesufficientquality:<br /><ul><li>Knownareasofexistingproblems
  16. 16. Defectsthatoccurred in previousreleasecycles
  17. 17. Critical businessareas such ashighprioritycustomers</li></ul>Toguaranteesustainedresults:<br />And<br />
  18. 18. Orthogonal Design for Test InvoicePlanning<br />Smart groupingcanguaranteefullcoverageatoftenlessthan 100 scenarios.<br />Reduction<br />Designed Experiments createthe optimal strategy:<br />As „get all“ databasequeriesreturn a hugesetaffectedcustomers, thedataneedstobefiltered.<br />OrthogonallyDesigned Experiments (DOE) servethispurpose.<br />
  19. 19. Resultsof Test Invoices<br />The followingare all real, anonymizeddatatakenfrom a real project.<br />Test invoices in yourcompany will produce different resultsfollowingsimilarpatterns.<br />Real UseCases<br />Thereisusuallyonecategoryofcausesresulting in a majorityof all problems.<br />Pareto Principle: Onemainpointofinterest<br />
  20. 20. Resultsoftestinvoices<br />Youmaywonderhow a companywith 27% defectiveinvoicescansurvive?<br />After defectivesarebroughttothetable, issuesneedtobecategorizedandprioritized.<br />Onlyproblemsresulting in loss (ofmoneyorreputation) will bescopedforimprovement.<br />A differencebetweendefectiveandproblematic<br />Companies without Data Quality Controltypicallysufferapproximately 10-25% defectivedata.<br />Ruleof Thumb<br />
  21. 21. Root causesfordefectives<br />Improvingtheresultofthe IT systemoutputdepends on theoverallprocess.<br />This must includefinding out whysystemsareemployed in thewrongfashion.<br />The solutionmay just be proper trainingforthe Call Center staff!<br />Processquality<br />Problems causedbywronguseoftechonologyneedtobehandled different than classic „defects“.<br />Not everyproblemiscausedbyfunctionaldefects<br />
  22. 22. Real worldexamplesofinvoiceproblems<br />A usecase was wronglyduplicated in the CRM:<br />Customers paytwiceforthe same service.<br />Double booking<br />
  23. 23. Real worldexamplesofinvoiceproblems<br />Whenthiscustomerchangedtheirproduct,<br />a chargedservicingposition was lost.<br />Service loss in changerequest<br />
  24. 24. Real worldexamplesofinvoiceproblems<br />Valencia isn‘t in Germany…<br />Thiscustomerwon‘treceivetheirmail!<br />Country Code<br />Onepersongetsthe title in the same line,<br />The other in a newline: why?<br />Inconsistentnamehandling<br />Same person, <br />twonames!<br />Name change?<br />Doesitstrikeanyoneelseasoddthatyoupaypostalservice „per day“ and not „per letter“?<br />Daily postalservicecharge<br />
  25. 25. Summary<br />Ifyouneverusedtestinvoices, chancesareyoursare also 25% defective!<br />Top 1 : Test invoicesareworthwriting!<br />Test invoicesshouldbe a clearlydefinedprocessthatisappliedfrequently.<br />Top 2 : Clear processdefinitionsandschedule!<br />Itmight just bethatbillingcannoteveninfluencethemajorityofdefects!<br />Top 3 : Invoicesaren‘t just aboutbilling!<br />Inconsistentpricesandinvoicetextsare a marketingtopic, not an IT topic.<br />Top 4 : Business sideinvolvement.<br />Ifthemajorityofdefectsarecausedbymisusingthe CRM, the CC agentsneedto do theirpart!<br />Top 5 : Customer Care / Sales involvement.<br />A singletestinvoicerun will only cover currentissues: New topicsarisemonthly!<br />Top 6 : ContinuousImprovement<br />Folie 12<br />
  26. 26. Folie 13<br />Thankyouforwatching<br />