Yellow Belt DFS Austin Taxas

1,011 views
888 views

Published on

This project was to address the unstable and multiple builds/ multiple machines in the production environment for Dell Financial Services which had more than 30 apps running on Production.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,011
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Microsoft Project, Visio, Office
  • Yellow Belt DFS Austin Taxas

    1. 1. Analyze: Tools Used : Fishbone, Flow charts. Measure: Before Measures : 12 % build failure in 2004 Data from remedy Improve: The build Time has been reduced. Example DBC build and NRD Quarterly update have been automated. Instead of 14 Part Time resources , 2 Full Time resources are doing the Release work. As compared to 12 % failure in 2004 there is only 4 % failure in 2005.Continued improvements in 2006. Through Build Documentation review has led to lesser build failures and improved System Stability in 2005 continued in 2006. The three Year Benefit Losses has been reduced. Control & Report Standardization : Documents related to Release are kept in a centralized location with access to all those who need to know the process. ( URL : usdsdfsdata01dataDFS Release Management) Processes for Sustained Results This Process is being defined in other Groups like PG, HR and Corp. Future aim is to share the best practices throughout the entire AMCS organization Will be training the GSC Release folks in the DFS Release process Matrix will be maintained and no build failure and backout should occur. From lessons learned the new builds should be verified and then implemented Define: Problem Definition : There is no defined Release process for the releases in DFS IT Production Environment Yellow Belt 6-Up Presentation Title: DFS_IT_RELEASE_PROCESS_IMPROVEMENT Area: DFS It and Business PTT #: 23236 Time Period : Oct , 2005 to March 2006 Team :Meenakshi Ganeriwala Steven O’Hara Greg, Pantzer     Why Selected : Lack of defined process for build deployment Lack of Release management group for deployment Root Cause Findings No dedicated resource for build implementation.. On call and Problem Solving people are pulled. Lack of proper build versions being deployed. Lack of Trial builds in the QA environment. Build issues not worked on to be eliminated in the future build Objective : Reduce Time To implement build( Automation) Reduce Resources doing the implementations Improve Accuracy of deployments to 98 % No new change should reduce the System stability Reduce the Three Year Benefit losses As-Is Process Improved Process Raw Data and Baseline Performance Key Tools
    2. 2. DEFINE (PROJECT INFORMATION, DEFINITION) PTT Number : 23236 Team : Meenakshi Ganeriwala O’Hara Steven Greg Pantzer Executive Sponsor : Diana Keating Chartering Manager : Sandeep Kulkarni Finance Analyst : SenGupta, Paul BPI Mentor : Pande, Kaunteya Project Type : Yellow Belt Project Lead : Meenakshi Ganeriwala, Start Date : Oct 4 , 2005 End Date : March, 2006 DFS_IT_RELEASE_PROCESS_IMPROVEMENT % of Build Failure in 2004 ---- 12% As Is Statement (2004) There is no defined Release process for the releases in DFS IT Production. Desired Statement (2005 and part of 2006) To define a process of implementing changes to the DFS Production Environment To reduce the % of Build Failure in 2004 ---- 3% to 5 % Have 98 % good build and 0% backed out builds. To deliver changes that will not break the stability of the environment To reduce the number of resources working on the build implementations To reduce the loss in the Three year Benefit.
    3. 3. Existing Release Process in DFS(2004)
    4. 4. DEFINE IS/ IS NOT ANALYSIS, Why Selected Why Selected : DFS wanted a defined process for Build implementation to the Production Environment Refer to the Flow Chart for the existing process of build deployment to the Production platform As-Is Process Development, Test Application services Not entire DELL IT DFS IT ( part of DELL IT ) Is Not Is Scope Statement Is/ Is Not Analysis
    5. 5. DEFINE (COPIS) Stakeholders Dell Financial Services Development and Test Team. Dell Financial Services Release Management Team Dell Financial Services IT and Business Suppliers Process Owners Customers Where does the process begin? Test Team delivers new Features to be deployed to Production What does the process exclude? Other data sharing, problem solving, support improvements What does the process include? Defined process of Build deployment to the Production environment Where does the process end? Build deployed to the Production environment and master CT closed. Documents successfully published on usdsdfsdata01dataDFS Release Management Boundaries Key Metrics Reduce the % failure Only two Full Time resource Reduce the Benefit loss % of build Failure Resources involved Three Year Benefit Measurable Outputs Process Measurable Inputs
    6. 6. MEASURE CTQ Tree Process Steps Metric Table : Customer Need Drivers (PFQT) CTQs (Metric) DFS IT Mgmt Reduce time and resource spent on Release management Less Build Failures Better stability DFS Business No of Successful Builds deployed to Production Environment stability Effective Build Quality Business Loss Builds completed on less hours Time % Failed reduced Resources $1,584,000 14 App Ser Part time 12 % Before $528,000 2 full time 3 to 5 % After Decrease the num Lagging Attribute productivity num num Resources involved Decrease the loss Lagging Variable Financial $ $ loss 3 year Benefit Decrease the mean Reduce variability Lagging Attribute Productivity/ Quality % Percentage % of the Build failure / backed out Desirability Leading/Lagging Attribute /Variable Family of Measure Unit of measure Metric Descriptor
    7. 7. ANALYZE <ul><li>Tools Used: </li></ul><ul><li>Fish Bone, Check Sheet, Process Flow Charts Data Analysis. </li></ul><ul><li>Root Cause Findings : </li></ul><ul><li>There is no dedicated resource or a Team for Release Management process in DFS production Environment. Too many people involved in the Build Process.14 part Time .On call people , Problem Solving people are pulled in to deploy. </li></ul><ul><li>The Build Documents are passed on to the implementer without being properly tested in Test Environment. </li></ul><ul><li>Lack of proper build versions being deployed. </li></ul><ul><li>Lack of Trial builds in the QA environment. </li></ul><ul><li>DFS Apps support is unaware till the last moment that there are changes to be implemented to the Production Environment. Lack of sufficient Time for Review the Build Doc. </li></ul><ul><li>Build issues not worked on to be eliminated in the future build </li></ul>
    8. 8. ANALYZE
    9. 9. IMPROVE Refer to the Blue boxes in the Flow chart. They are the points where improvement is attempted <ul><li>Anticipation of Release Work </li></ul><ul><li>Better Communication for Release of Features </li></ul><ul><li>Single source of contact for the Release Work </li></ul><ul><li>Rejection of builds if Documentation is not satisfactory </li></ul><ul><li>Trial builds in the QA environment </li></ul><ul><li>More Features under one CT </li></ul><ul><li>Separation of DBA and Ctrl-m work </li></ul><ul><li>Proper scheduling of the CT’s </li></ul><ul><li>Reviewing the build issues </li></ul>528,000 ( $ loss) 1,584,000 ($ loss ) Reduction in the Three Year Benefit( noted in $ loss ) 2 Full Time 14 Part Time Reduction in Resources Better stability Less stable Improve System Stability 4% 12 % % of Builds Failed After Measurement Before Measurement Descriptor
    10. 10. All the Blue boxes denote improvement
    11. 11. IMPROVE ( These are the steps related to the Proposed improved Release Process for DFS
    12. 12. IMPROVE A notice for Build violation would look like this ( This section is referred from the Flow chart ) Change Ticket Number XXXXXXXXX Project/Express lane item XXXXXX Systems Impacted XXXXXXXXX Build Implementer Meenakshi Ganeriwala Subject of the email Build violation for CT XXXXXXXXX Matter sent in the email Your build request for change ticket CT XXXXXXXXXX has been reviewed by DFS-Release-Process Management Team. The following items have been identified as not being in compliance. _____ QA to Prod handoff meeting did not take place _X__ 5 day lead time was not provided for review of scripts and doc. __X_ CT-number folder missing in the QA_Prod_Builds folder under usdsdfsdata01Data . _____ CT-number folder under usdsdfsdata01Data is market “uncertified” __X__ UAT not signed off on this Item. ___­__ Implementation Document not in proper format/ contains insufficient information. _____ Build Document has insufficient Backout Instructions _____ Contact information not completed. _____ Server names missing. _____ Appropriate Login information not received in Build Doc. _____ Trial build requested was not scheduled and implemented with DFS Apps Member Please address these items prior to implementation. All required information must be completed and accurate in the implementation document. Failure to comply with DFS-Build-Process control procedures will result in not implementing your build. Necessary management will be sent a notification. Thanks, DFS-Release-Process Control Team Email : Meenakshi_ganeriwala@dell.com
    13. 13. IMPROVE Weekly build schedule BUILDS TO BE IMPEMENTED FOR THE WEEK OF Week start 3/14/2005. Week end 3/19/2005. Schedule: <ul><li>Important Dates : </li></ul><ul><li>Transition meeting with QA Friday, March 11, 2005. </li></ul><ul><li>Trouble Ticket 0005664951 opened for Control M for RCSS March 14, 2005. </li></ul><ul><li>Test Completed for Control –M on QA and Dev env ( pending ) </li></ul>Steve O’hara 5:00AM 12:00AM CMS 3/18/2005 completed 0000118283 5 DBA work only Raveendra Avutu 5:00AM 11:00 PM Oracle Financials 3/18/2005 NA 0000118151 4 Dustin Crane 5:00AM 12:00 AM Extractor 3/17/2005 completed 0000115623 3 Tentatively at 6PM .”K” is Will be there. Anant Badryani 5:00AM 6:00 PM FMS 3/17/2005 completed 0000116338 2 5664951 Build to be rescheduled. Anant Badryani 5:00AM 8:00 PM RCSS 3/16/2005 reshcheduled 0000115209 1 end start Comments Implementer Schedule Time Key Items Effected Build date Build Tested on QA Env Change Ticket # SR NO
    14. 14. CONTROL STANDARDIZATION & SUSTAINED RESULTS <ul><li>Please refer to Documents to view improvements in the results of build deployment </li></ul><ul><li>Standardization : </li></ul><ul><li>All documents related to Stabilization of builds implemented in production should be kept in a centralize location with access to all those who need to know the process. </li></ul><ul><li>( URL : usdsdfsdata01dataDFS Release Management) </li></ul><ul><li>Processes for Sustained Results </li></ul><ul><li>Matrix will be maintained and no build failure and backout should occur. </li></ul><ul><li>Sharing Best Practices among other Groups </li></ul><ul><li>This Process is being defined in other Groups like PG, HR,GFCS and Corp. </li></ul><ul><li>Several Meetings have been held for the PG/Corp/HR groups. </li></ul><ul><li>Working with the following resources for this process </li></ul><ul><li>Kimberly Pierce </li></ul><ul><li>Nilesh Sangani </li></ul><ul><li>Clyde Burgress </li></ul><ul><li>Brooke George ( Release Manager ) </li></ul><ul><li>Will be training the GSC Release folks in the DFS Release process( estimated duration May 2006) </li></ul><ul><li>The future aim is to share the best practices throughout the entire AMCS organization </li></ul><ul><li>Finance Sheet : </li></ul>
    15. 15. REPORT (Communication & Future Plans) <ul><li>Communication: </li></ul><ul><li>To publish information about the process of build implementation in the DFS general website where all Development, Test , management App Support and Business have visibility usdsdfsdata01DataDFS Release Management. </li></ul><ul><li>Requests to use the site is justified by having this project completed. </li></ul><ul><li>Future Plan: </li></ul><ul><li>98% successful builds implemented to the production environment. </li></ul><ul><li>One click implementation.( Further Automation ) </li></ul><ul><li>Stability is not disturbed with implementation of new features or projects. </li></ul><ul><li>The Release management Team will meet with concerned people every four weeks to work on build issues </li></ul><ul><li>Work with AMCS to implement and standardize the Release Process. </li></ul>
    16. 16. Thank You Q & A

    ×