Lean Six Sigma Green Belt Project April 5

Lean Six Sigma Green Belt Project April 5, 2015 Reduce The Number Of Payment Cases Generated By: Jide Fakoya

Agenda § § § Project Charter Define Phase – Operational Definitions Of Key Terms – Business Case – Problem Statement & Goal Measure Phase – Process Map (AS-IS) / Data Collection Plan / CTQs / SIPOC / Fish. Bone Analyze Phase – Case Review / DPMO / 5 Whys / FMEA Improve Phase – OFI / 9 Box / Cost Benefit Analysis 2

Project Charter: Reduce Number Of Payment Cases Generated Big Y: Reduce the average number of payment cases generated by 40% Problem Statement The number of the payment cases generated monthly is too high. From January 1, 2014 to April 14, 2015 there were 10, 098 (approximately 41. 3% of total cases) payment cases generated. Business Case: Analysis of the total cases generated from January 1, 2014 to April 14, 2015 shows that majority of the cases were related to payment issues. By reducing the average number of payment cases generated, customer satisfaction could increase and the cost to keep the payment tool functional would decrease. Business/Financial Impact Historical data shows the average annual cost to maintain functionality on the payment tools is$291, 789. 60. Project Scope/Boundaries: Process Start: When a vehicle sells via Inlane/Simulcast/OVE. Process Stop: When transaction payment via app is complete. In Scope: All cases related to payments made via my purchases / my account. Out of Scope: Payments made at an auction location / Total number of cases generated through the auction. | Dev support work efforts is also out of scope. Milestones/Timeline: Scheduled Define Tollgate Review: Measure Tollgate Review: Analyze Tollgate Review: Improve Tollgate Review: Control Tollgate Review: April 17, 2015 June 30, 2015 Nov 30, 2015 N/A Actual 4/17 7/15 8/20 1/16 Team: Jide Fakoya Champion: Not Disclosed Process SMEs: Not Disclosed Other Resources Required: Not Disclosed Approach: DMAIC Customer External: Dealers Internal: Customer Care Business Rules • Dealer’s Flooring Company Options should always be available if used within 60 days. • Paid Transactions should show as “Paid” immediately across all transaction detail pages. • A transaction record should only belong to one account at time. • Dealers should be able to order Post Sale Inspection (PSI) if their vehicle qualifies.

Operational Definitions Of Key Terms (1 of 2) § § Payment Tools – A combination of My. Purchases and Myaccount My Purchases - an easy, consistent, and predictable buyer settlement experience, across all Manheim channels and locations by offering a simplified, personalized, & automated settlement solution. § My. Account – Payment tool that enables users to: – Pay for vehicles via an electronic bank debit – Review universal credit limit and outstanding balances – Set up proactive e-mail notifications for arbitration status and title changes – View vehicle history reports – Look up all transaction activity for a particular vehicle – Check the current status of a title or transaction § § Customer Care (CC)– The Customer support center Application Support (AS) - Responsible for developing, deploying and supporting processes and procedures necessary to provide advanced technical and business support for the company’s customer focused web based applications. Cases / Request– These are generated through emails or phone calls initiated by a system/ product user PSI (Post Sale Inspection) – A service conducted after a vehicle is sold at the auction. § §

Operational Definitions Of Key Terms (2 of 2) A Defect on this project is defined as a case escalated to the Application Support team and the root cause of the issue cannot be resolved/determined unless escalated to a development(product) team. An Opportunity on this project is defined as requests that could have been handled by the first line of support if there are tools available to present the data being requested. Business definition of a defect and SLAs:

Define Phase of. D M A I C

Business Case § Analysis of the total cases generated from January 1, 2014 to April 14, 2015 shows that majority of the cases were related to payment issues. § By reducing the average number of payment cases generated, customer satisfaction could increase and the cost to keep the payment tool functional would decrease. 7

Business Case - Financial Impact (1 of 2) Cost To Engage Teams: Customer Care: Avg. Cost Per Call = $11 Application Support: Avg. Cost Per Hour = $52 Avg. Time To Work /Resolve issues = 2. 5 hrs Avg. Time The Payment Cases Remains In Queue = 228 hrs Dev Teams (M. com, ODS BEE, IBM): Avg. Cost Per Hour = $115 Avg. Time To Fix a Defect = 4 hrs Note: The total number defects fixed on payment cases issues is out of scope

Business Case - Financial Impact (2 of 2) Begin Date End Date Total Days In Population 1/1/14 4/16/15 469 Total Number of Payment Cases (CC) 7, 837 Total Number of Payment Cases (App Support) 2, 261 CC: Avg # Cases Per Day 17 CC: Avg # Cases Month (30 Days) 501 App Support: Avg# Cases Per Day 5 App Support: Avg# Case Per Month (30 Days) 145 Cost Per Case Customer Care Cost Per Call Cost Per Month (CC) Cost Per Year (CC) $11 $5, 514. 31 $66, 171. 70 Application Support Avg# Labor Cost $52 Avg hrs per case (Overall) 2. 5 Total Cost Per Case Cost Per Month (AS) $130 $18, 801. 50 Cost Per Year (AS) $225, 617. 92 Total Cost Per Year $291, 789. 60

Problem Statement & Goal § From January 1, 2014 to April 14, 2015 the average payment case generated monthly is 721. 3. – 41. 3% (or 10, 098 cases) of the total cases created in the 14 months timeline examined were related to clients experiencing issues when interacting with our payment tools. § The goal is to reduce the average number of payment cases generated monthly by 40% (288 cases). 10

Measure Phase of. D M A I C

Process Map: AS-IS

Data Collection Plan -- Queries Snapshot Vicki Advance Find The queries in the snapshot shows how the total number of cases relating to this project was generated through the customer care channel Mingle L 2 DB: **This query is selecting all the app support cases related to My. Account and My. Purchases where the title matches pay, payment or purchase from 1/1/2014 to 4/14/2014. select * from sc_case_data where (product in ('My Purchases', 'My Account') or title like '%pay%' or title like '%payment%' or title like '%purchase%') and createdon >= '2014 -01 -01’ MSC DB: **This query returns the total number of sold vehicles via simulcast from 1/1/2014 to 4/16/2015. select count (*) from masterf. pfmsttrn where SINTN 1 = 'Z' and SINTN 2 = 'S' and SDTESL between '20140101' and ' 20150414’;

Project CTQ Tree Need: Drivers CTQs: Better Payment Tool Availability Reliability Payments made on time all the time. Flooring companies should always be available as a payment option Accurate Transaction records should always appear on My. Purch / My. Account Issues resolved faster so accounts don’t get put on hold

SIPOC DIAGRAM

Fish Bone: Root Cause Analysis For Defective Payment Cases

Analyze Phase of. D M A I C

Case Review To conduct a root cause analysis, the team randomly selected and reviewed 765 cases out of the total number of cases generated on payment issues on My Purchases and My Account between January 1, 2014 to April 14, 2015. Lets take a look at the results in the next slides…

Calculating DPMO / Sigma Level • • • O = 1 (Number of opportunities) N = 993178 (Total number of simulcast sales from 1/1/2014 – 4/14/2015) D = 10098 (Total number of defects)

Visualizing the Impact Products Examined 450 415 400 350 299 300 250 200 150 100 51 50 0 Other My. Purchases My. Account Notables: My. Account – 31% of the 415 cases reviewed were defects. My. Purchases – This product has the most defect reported. 85% of the 299 cases reviewed were defects. Other – The tools specificied as other includes: Simulcast, M. com, and OVE. com. • The occurences reviewed indirectly affected the Myaccount and My. Purchases payment tools.

Case Review Highlights • Total defect is 51% of the total cases reviewed • Total opportunity is 49% of the total cases reviewed • To help digest the data presented, we broke down the payment issues reviewed into two groups: • Root Causes (Condensed Reasons) • Sub-Root Causes (Defect and Opportunities) The items are reviewed in the next few slides…

Condensed Reasons

Defects Condensed Reason: Unable To Make Payment Root Cause(s): • Cannot Order PSI • Cannot Select Floorplan • Payment not posting • Pending Paid Transaction • Application Not Available Error • Cannot Select Payment Method • Error Processing Payment • Transaction Not Available Condensed Reason: Incorrect Transaction Record Root Cause(s): • Wrong Email Notification • Wrong Vehicle Showing On Account • Duplicate Transaction Record Condensed Reason: Payment Issues Root Cause(s): • Deal. Shield API Issue • Gate. Pass Issue • Email Notification Issue Condensed Reason: Missing Transaction Record Root Cause(s): • CR Not Displaying • Wrong Vehicle Data

Pareto: Total Defects

Unable To Make Payment (1 of 5) Defect Review – How It Gets Generated: • Cannot Select Floorplan: Occurs when application does not give a user an option to select a floorplan that exists under a users profile. (P, A) • Payment Not Posting: Occurs when payment made through other channels is not showing as paid on myaccount / mypurchases. (P, A) • • Example: If a payment is completed on my. Account but does not show as paid on my. Purchases. Transaction Not Available: Occurs when vehicles purchased does not appear under user’s profile. (P, A)

Unable To Make Payment (2 of 5) Defect Review How It Gets Generated: • • • Pending Paid Transaction: Occurs when a payment made remains in pending status. (P, A) Cannot Select Payment Method: Occurs when application does not give a user an option to select a payment method (i. e. cash, flooring options) that exist under a users profile. (P) Cannot Order PSI: Occurs when user does not have the option to buy PSI via my. Purchases application but transaction meets the criteria to have the option available. (P) Error Processing Payment: Occurs when payment application give an error when prcoessing a payment transaction. (P, A) Application Not Available Error: Occurs when application is not accessible by user. (P, A) P =My. Purchases A = My. Account O = Other

Unable to Make Payment (3 of 5) 5 Whys? Unable To Make Payment - Application Not Available Error Why are “application not available” errors getting generated? • Because the web boxes connected to the service are unavailable sometimes. Why do the web boxes become unavailable? • Because the VM connections are failed. Why are the VM connections failing? • Because there are high connection requests on the system, or apache stops running/responding Why is the system experiencing high connection request? • Because of user traffic is unsually • Because load balancer is not routing traffic equally to all the nodes and as a result all the user connection going to one node. Why is the load balancer not routing traffic properly? • Because of the load balancing method • Because the pool setup did not include all the available nodes Unable To Make Payment – Transaction Not Available • This topic is also affected the “duplicate sale key” issue.

Unable to Make Payment (4 of 5) 5 Whys? Cannot Order PSI | Cannot Select Floorplan | Cannot Select Payment Method Why are errors that prevents users from performing the above subjects getting generated? • Because the systems are out of synch Why are systems out of synch? • Because the code changes that could potentially affect other processes are not being fully communicated by the teams making the changes. Why are these code changes not being communicated? • Because teams making these changes don’t understand how it is impacting processes reliant upon the systems/processes being updated. Why are teams not understanding the impact of code changes on other processes? • Because QA does not have a complete checklist on processes to test during Validation/Defect testing. Why is the team making changes not using a complete checklist during validation/defect testing? • Because the teams affected by these issues are not being involved in the validation /defect testing phase. 28

Unable to Make Payment (5 of 5) 5 Whys? Payment not posting | Pending Paid Transaction | Error Processing Payment Why are errors where users cannot perform the above subjects getting generated? • Because duplicated transaction web-service messages are generated that allows the system to think multiple transactions of a sale exist. Why are duplicated web-service messages getting generated? • Because the ODS system is sending multiple messages of a transaction to the process that feeds payment tools. Why is the ODS sending multiple messages to this process? • Because the AS 400 sends ODS updates on sold transactions (i. e Title status) – as it should. Why is this an issue for ODS? • Because the ODS does not send updates on transactions to the payment tools. Why is the case? • Missed requirement. 29

Incorrect Transaction Record Defect Review – How It Gets Generated: • Wrong Email Notification: Occurs when an auto-generated is sent to a wrong user about a specified transaction. (A) • Wrong Vehicle Showing on Account: Occurs when a wrong transaction record shows up on a user account. (P, A) • Duplicate Transaction Record: Occurs when a transaction is duplicated on a user profile. On most occurrences one of the duplicated record will remain in unpaid status, while the other shows as paid. (P, A) P =My. Purchases A = My. Account O = Other

Missing Transaction Record Defect Review How It Gets Generated: • • Wrong Vehicle Data: Occurs when the vehicle details gets displayed on users transaction. (P) • Example: Image for a wrong Make/Model, Wrong sale lane and run number, Wrong price. CR Not Displaying: Occurs when a Condition Report (CR) of a vehicle does appear my. Purchases after transaction is complete. (P) P =My. Purchases A = My. Account O = Other

Incorrect Transaction Record & Missing Transaction Record 5 Whys? Why are transactions records missing on payment tools? • Because there are duplicate transactions records in the system Why are duplicate transactions records in the system? • Because the system is generating duplicate sale keys for one transaction (the vehicle in every transaction affected have been through an arbitration process at least once) Why are duplicate sale keys getting generated? • Because the system was designed to think that every arbitrated vehicle will be completely voided and a new listing will be created (This is not how the arbitration process work at the auctions). Why is the system designed to think that every arbitrated vehicle will be completely voided? • Because DEV did not account for how the auctions perform the arbitration process (example: the auction sometimes reuse the “work order number” of an arbitrated transaction). Why didn’t DEV account for this? • Because it wasn’t captured in the requirements.

Payment Issues Defect Review How It Gets Generated: • • Gate. Pass Issues: Occurs when users are able to print gate passes for not an incomplete/incorrect transaction. (P, A) Payment Rejected: Occurs when a payment submitted by user is rejected due inconsistences. (A) Deal. Shield API Issue: Occurs when a Deal. Shield guarantee purchase request fails. (P) Notification Issue: Occurs when user is not receiving notifications / updates on transaction. • Example: Title available, Payment complete. (P, A, O) P =My. Purchases A = My. Account O = Other

Payment Issues (1 of 2) 5 Whys? Payment Issues – Deal. Shield API Issues Why are users unable order Deal shield products if they are qualified? • Because the Deal shield API failed • Because the window to buy the product expired Why is the Deal shield API failing? • Because validation errors are getting generated Why are validation errors getting generated? • Because the systems are out of synch Why are systems out of synch? • Because of Deal. Shield sometimes don’t communicate their system changes, and as a result these errors occur. • Because outside components that contributes to the process fail (i. e TAPI, BHAG, Oracle On Demand) Why is Deal. Shield not communicating their system changes? • Because the communication SLA between dealshield and teams that use the API needs to be drafted Payment Issues – Gate Pass Issue • See previous slide – this topic is also affected the “duplicate sale key” issue

Payment Issues (2 of 2) 5 Whys? Payment Issues - Notification Issue Why are users experiencing notification issues? • Because the system is not generating the notifications to be sent. Why is the system not generating notifications? • Because the server processing these requests went down • Because the Web. Service requests related to this process is not generating/consuming messages Why is the server down? • Because of any combination of the potential causes below: o Server bandwidth excess o Hardware failure o Software failure o Internet connection problems o Datacenter maintenance Why is the Webservice not generating / consuming the messages needed? • Because the API calls are returning errors due an outage (server outage(web box)) Why is the business experiencing these outage? • Because we don’t have an automatic failover process in place on most of our servers.

Opportunities (Review) 1. Unable To Make Payment • Sale Not Finalized Error o Occurs when users attempt to make payments on incomplete transactions. (P, A) 2. Payment Question • Account Setup • o Occurs when a first time user wants to setup a my. Account or my. Purchases profile. (P, A) o First contact resolutions. Typically user generated questions regarding a transaction, sales, or verification. (P, A) End User Training 3. Payment Issues: • Fees • • o o Occurs when an applied fee is inconsistent with what user had in mind Occurs when user contacts customer support regarding amount owed. o Occurs when user’s access is revoked due to unpaid fees/ transaction. (P, A) o o Occurs when users is calling in to make a payment. Occurs when users payment made on amount owed have not being processed and account remains blocked. Access Restricted Credit Payment/AR Payment Issues (P, A) – Legend 1. Condensed Reason • Root Cause o How it gets generated P =My. Purchases A = My. Account O = Other

Pareto: Total Opportunities

Payment Question | Payment Issue | Unable To Make Payment 5 Whys? Why are so many cases getting generated regarding questions on the payment tools functionality? • Because based on data, a high number of dealers don’t understand some processes on payment tools (For example: account setup, when payment posts e. t. c). Why are some processes difficult to understand? • Because the user manuals available are not extensive and do not have FAQs dealer can quickly reference Why are the user manuals available missing FAQs? • Because the teams responsible for creating the manual did not include one. Why didn’t the team include an FAQ? • Because it was not part of the requirements captured. Why was this requirement not captured? • Because the business did not deem it as a requirement.

em ej R ss Pa en t ym e at ue Is s ro W ai 20 e l n cte d o r n C an or P g V tifca no ti e r t S oce hic on l s e el D ec sin t P g P ata ay ay m m e en nt C t R M no et h Sa t di o sp d le la Ap D yi ea Not pl n ic l F S in g at h al ie io i l n no d A zed P ta va I Iss ila ue bl e er C ro re C r di an t. P no Fe ay t. O es A m rd en cce ss er P t/A R R SI Pa es t r ym ic W en ted Pe ro ng n Ac t Is su Ve din co g hi un es P cl ai t e Sh d T Set up r ow a in nsa g ct P io Tr aym on n A an en c c sa ct t no oun i C an on N t po t st no o t S t A ing v Em el D ec aila up ai b l. N t. F lic lo le ot at o i e Tr fica r. Pla ti an n sa on I s c En tion sue d R U ec se or r. T d ra in in g Er ng ro W Pa G Root Causes Snapshot 200 180 179 160 140 120 100 80 60 40 1 2 2 2 4 7 Legend: Payment Question - Blue Unable To Make Payment - Red Incorrect Transaction Record - Green Payment Issues - Purple Missing Transaction Record – Orange 7 14 18 20 20 27 33 33 34 37 46 48 48 56 62 65 0

Monthly Run Rate On Payment Cases Reviewed (Jan 2015 – April 14, 2014) 80 70 Number of Cases Per Month 60 50 40 30 20 10 0 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr 40

FMEA Process Step Training documentation for end users Key Process Input Documentation content Dealer selects add- Requesting on during payment Quote (i. e Deal. Shield) Fixing Defect Potential Failure Mode Dealer does not find Dealer is frustrated and calls support for documentation informative every issue. Network/Server Down Dealer is unable to get a deal. Shield gaurantee. Implementating Deployment team forgot to Systems gets out of synch and other working code check for system defects surfaces. dependencies Implementating Solution / testing efforts not Defect resurfaces after fix is deployed. working code documented Pay for transaction Select method of Dealer cannot select payment desired floorplan for payment Send purchase Confirmation Potential Failure Effects Make payment Dealer cannot make payment. Dealer temporarily looses access to buy for lack of payment. Dealer is frustrated. SEV Potential Causes Documentation is 5 missing FAQs. Systems are out of synch (API call 7 failure) Changes not comunicated to 7 other product teams 7 7 Missed requirement Systems are out of synch OC C Current Controls Have CC/support team/help desk provide 9 end user training DET RPN 2 90 1 42 2 42 1 49 Dashboard Monitoring 6 Change Management 3 3 QA Pay at local auction 7 Notifications are not getting Dealer does not get transaction processed notifications 6 5 1 30 Pay for transaction Select Vehicle purchased is not available on dealer's Payment Tools account Duplicated sale keys exists in the 7 ODS system Support team research issue and report to the 7 development team 1 49 Login on payment tool Payment tool is unavailable Dealer is frustrated 1 24 Access site Dealer cannot make payment Dealer temporarily looses access to buy for lack of payment Dealer is frustrated Server outage 8 Web Box / VM connection failure Server backup 3 Monitoring dashboard FMEA scales on the next slides…

FMEA Scale – Severity (SEV) Effect Criteria: Severity of Effect Defined Ranking Has sever safety or health effects to group or individual. Failure will occur WITHOUT warning. 10 Has sever safety or health effects to individual or group or is illegal. Failure will occur WITH warning. 9 Very High Major disruption to good production or service delivery. 100% of product or service may have to be scrapped. Vehicle / item inoperable, loss of primary function. Customer very dissatisfied. 8 High Minor disruption to good production or service delivery. Product may have to be sorted and a portion (less than 100%) scrapped. Customer dissatisfied. 7 Moderate Minor disruption to good production or service delivery. A portion (less than 100%) may have to be scrapped (no sorting). Customers experience discomfort/irritation. 6 Low Minor disruption to good production or service deliver. 100% of product or service may have to be reworked. Customer experiences some dissatisfaction 5 Very Low Minor disruption to good production or service delivery. The product may have to be sorted and a portion (less than 100%) reworked. none conformance. Defect noticed by most customers. 4 Minor disruption to good production or service delivery. A portion (less than 100%) of the product may have to be reworked on-line but out-of-station. Defect noticed by average customers. 3 Minor disruption to good production or service delivery. A portion (less than 100%) of the product may have to be reworked on-line but in-station. Defect noticed by discriminating customers. 2 No effect. 1 Hazardous: Without Warning Hazardous: With Warning Minor Very Minor None

FMEA Scale – Occurrence (OCC) Probability of Failure Possible Failure Rates Ranking Once an hour 10 Once every 6 hours 9 High: Generally associated with processes similar to previous Once per shift 8 processes that have often failed Once per day 7 Once every week 6 Once every 2 weeks 5 Once per month 4 Low: Isolated failures associated with similar processes Once per 1 -3 months 3 Very Low: Only isolated failures associated with almost identical processes Once every 6 months 2 Once a year 1 Very High: Failure is almost inevitable Moderate: Generally associated with processes similar to previous processes which have experienced occasional failures, but not in major proportions Remote: Failure is unlikely. No failures ever associated with almost identical processes

FMEA Scale – Detection (DET) Detection Criteria: Liklihood the existence of a defect will be detected by a test* content before product advances to next or subsequent process Ranking Almost Impossible Test content detects < 80 % of failures 10 Very Remote Test content must detect 80 % of failures 9 Remote Test content must detect 82. 5 % of failures 8 Very Low Test content must detect 85 % of failures 7 Low Test content must detect 87. 5 % of failures 6 Moderate Test content must detect 90 % of failures 5 Moderately High Test content must detect 92. 5 % of failures 4 High Test content must detect 95 % of failures 3 Very High Test content must detect 97. 5 % of failures 2 Almost Certain Test content must detect 99. 5 % of failures 1

Improve Phase of. D M A I C

Recommendations / Opportunities For Improvement These recommendations are not in any particular order Solution 1 2 3 4 5 6 7 Update the Tools Manual SLA - Communication SLA – Task Completion Description What It Improves Category The user manual is not extensive and is To help reduce the number missing useful FAQs users can easily of end user training and Process access. general question calls. Promote process improvement and improve cross-team collaboration. Owner Term Content Short Term To improve communication on systems outages and Applicatio Short Process upgrades that can affect n Support Term other team’s processes. To define time frame for task completion To improve the commitment System; IT; on payment tools errors affecting prod. on SLA in completing Process Product environments. production defects Short Term End User Support Training Schedule Lunch and Learn with the first To help reduce the number line support to help them learn more of escalated cases from the Process about the tools and share solutions to Customer Care team FAQ. Product Short Term Testing Improve testing efforts – testing code To improve the quality of System; against other systems to detect possible code getting released to Process breaks. production in deployments IT Short Term IT Mid. Term To improve visibility on A monitoring dashboard that provides payment tools outages and Setup Monitoring teams a visual representation and metrics System improve support team’s of failed payment events. reaction time on escalations Prevents processes from going down in To improve our system Automatic Server Failover System the event of a server failure. uptime

High Recommendations (9 -Box) Rec 5 Rec 3 Rec 6 Rec 7 Rec 4 Med Low Business Value Rec 2 Rec 1 Low Implementation Complexity Relative Risk High Medium High Med Low Implementation Timeline Short Term Mid Term Long Term 47

Process Map – Future State 48

Cost/Benefit Analysis § Benefits: • Become proactive on identifying and fixing defects vs. the current reactive state • Established SLA – Deadlines on resolving defects reported by support groups. • Lunch and learns will produce more knowledgeable end user support agents that can help provide solutions to client’s FAQs • Improved communication among teams and stakeholders § Cost: • Cost of building real-time payment monitoring dashboard • Cost per hour for the content team to write a user friendly tool manual with updated FAQ • Training cost for Dealers and Representatives • Cost of implementing an automatic failover process