Six Sigma (Black Belt) Project (Hakeem-Ur-Rehman)

SIX SIGMA BLACK BELT PROJECT REPORT
MANAGING & ENHANCING QUALITY OF IT OPERATIONS BY REDUCING THE UNPLANNED DOWNTIME
HAKEEMURREHMAN 27022012 Lahore, Pakistan SUPERVISOR: DR. NADEEM SHAFIQ BUTT
THIS PROJECT REPORT IS PART OF THE REQURMENT FOR THE
SIX SIGMA BLACK BELT COURSE
ORGANISED BY
PIQC INSTITUTE OF UALITY AND SINGAPORE QUALITY INSTITUTE

SIX SIGMA (BLACK BELT)PROJECT Page 1
TABLE OF CONTENTS
Sr. No. 1 Topic DEFINE PHASE Project Charter Deployment Process Flow Diagram SIPOC Diagram KPIs and KPOs MEASURE PHASE Measurement System Analysis (MSA) Line Chart (Month Wise Downtime) Pie Chart (Category Wise Downtime) Pareto Analysis (Category Wise Downtime) Cause & Effect Diagram (Downtime) Pie Chart Country Wise Downtime City Wise Downtime Bar Chart Shift Wise Average Downtime Gender Wise Average Downtime Qualification Wise Downtime Experience Wise Downtime Age Wise Downtime Multiple Bar Chart Country & City Wise Downtime Qualification & Experience Wise Downtime Age & Experience Wise Downtime Probability Plot Current Sigma Level Calculation ANALYSIS PHASE Testing of Hypothesis IMPROVE PHASE Design of Experiment CONTROL PHASE Process Failure Mode & Effect Analysis Control Charts Page No. 3 4 5 5 8 9 10 12 13 13 14 14 14 15 16 16 17 17 17 18 18 18 19 20 21 33 34 42 43 59
SIX SIGMA (BLACK BELT)PROJECT
Page 2
DEFINE PHASE
DEFINE PHASE: Project Charter Process Flow Diagram SIPOC Diagram KPIs & KPOs
Page 3
PROJECT CHARTER:
PROJECT TITLE: BUSINESS CASE: Managing & Enhancing Quality of It Operations By Reducing The Unplanned Downtime
Last year (from February to August, 2011) due to the different issues in the IT operations and development company faces unplanned downtime which causes the loss of revenue, reputation and customers. By considering these issues the overall losses are approximately Average Rs. 23981100 per month (Average Downtime per month X Average Cost (Human Resource) per Minute X 7 Months). By reducing above said losses by 30%, we will be able to save approximately average Rs.7194330 per month. PROBLEM Managing quality by controlling and improving processes of identified major downtime STATEMENT: categories which are causing 45% of total down time. OBJECTIVE: METRICS: Reduction in %age downtime up to 30% of the total downtime. Primary Metric = Downtime (%) = (Total Downtime / Secondary Metric = % Yield Total Production Time) * 100
PROJECT IT Operations & Development SCOPE: BEFORE IMPROVEMENT MONTHLY DOWNTIME :
Month wise Total Downtime

10000 Total Downtime 8000 6000 4000 2000 0 Total Feb 8079 Mar 6961 Apr 7047 May 6263 Jun 6559 Jul 5405 Aug 6645
AFTER IMPROVEMENT MONTHLY DOWNTIME :
Month Wise Total Downtime

10000 8000 6000 4000 2000 0 Total Downtime
Feb Mar Apr May Jun
Jul Aug Sep Oct Nov Dec
Total Downtime 8079 6961 7047 6263 6559 5405 6645 5430 4355 2122 2276
Schedule:
ID Task Name Start Finish Duration 1 2 3 4 5 Define Measure Analyze Improve Control 10/17/2011 10/31/2011 11/21/2011 12/12/2011 1/30/2012 10/28/2011 11/18/2011 12/9/2011 1/27/2012 2/17/2012 10d 15d 15d 35d 15d
Oct 2011
Nov 2011
Dec 2011 1/1
Jan 2012 8/1 15/1 22/1 29/1
Feb 2012 5/2 12/2
23/10 30/10 6/11 13/11 20/11 27/11 4/12 11/12 18/12 25/12
Page 4
DEPLOYMENT PROCESS FLOW DIAGRAM:

Process Flow Diagram; IT Operations and Development
Client Services
Request to Create New Campaign
Document that contains requirements for new campaign No
Request to Load the Leads
Data which Need to be Loaded
Request to update the filter
Analyze Performance
Satisfied with Performance
Yes
Inform Client
Development Team
Develop Campaign Script
Approval for Script Deployment
No
Update Script
Develop Query to Load the Leads
Develop Filter for Leads Selection No
DBA Team
Correct format Yes
Yes
Load the Leads
Perform Database Maintanance
Perform Leads Scrubbing
Operations Dialer Team Team
Deploy Script
Apply Filter
Update Filter
Analyze Current System and Request Maintainance
Reboot Dialers
Change Dialing Parameters
Login Agents No
Getting Leads
Yes
Start Dialing
Report any Production Impacting Issue
Help Desk
Open the Bridge
Get Required Teams on the Bridge
Record Downtime
Provide Downtime Details to Concerned Person
NT Admin Team
Have Login Rights
Give Rights to the Agents
Perform System Maintainance
Assign/Unassign Machine
GNOC
Set Rules to Access the Network
Monitor Network Traffic
Perform Maintenance Activity of Telco Lines with Career
Analyse Network Health in Case of Issues
SIPOC DIAGRAM:
SUPPLIER
Development Team Operations Team Strategy Analyst
INPUT
Dialing Filter Dialing Criteria Email
PROCESS
APPLY FILTER
Operations team requests filter update
OUTPUT
Correct Leads Enough Leads Available
CUSTOMER
Operations Team Agents
Development team develops the filter
Dialer team implements the filter and checks the leads count
Dialer team provide the updated leads count and filter to development team
Page 5
SUPPLIER
NT Admin
INPUT
Credentials with the rights to reboot
PROCESS
Reboot Dialer
Dialer team analyst stops the controller
OUTPUT
CUSTOMER
Analyst stops the CTIEngine and Dialogic
Controller up Dialer Team and running Agents CTI Engine up and running Dialogic up and running
Restart the machine
Once machine is backup restart the dialogic
Restart the CTIEngine and Controller applications
Dialer is ready for production
SUPPLIER
Client Client Services Team
INPUT
Client Requirements Client's Approval Client Services Approval
PROCESS
UPDATE SCRIPT
Client services requests a change in script
OUTPUT
Correct Script With Updated Information
CUSTOMER
Agents Client Services Operations Manager Developer
Developer makes changes in the script
Script is tested on test server
Developer sends the script to Dialer Team for deployment in production
Dialer Team deploys the script after getting appropriate approvals
Page 6
SUPPLIER
Client Services Strategy Analyst
INPUT
Previous Dialing Data New Strategy
PROCESS
CHANGE DAILING PARAMETERS
Client Services/Strategy Analyst request change in parameters
OUTPUT
Target Strategy Met Dialing with New Parameters
CUSTOMER
Strategy Analyst Client Services Team
Dialer Team analyst implements the strategy
Dialer Team supervisor verifies that the change has been implemented correctly
Dialer Team inform the requestor that change has been implemented
SUPPLIER
Client Services Client
INPUT
Lead files
PROCESS
LEADS LOADING
Operations team requests filter update
OUTPUT
New Leads
CUSTOMER
Operations Team Client Services Dialer Team
Development team develops the filter
Dialer team implements the filter and checks the leads count Dialer team provide the updated leads count and filter to development team
SUPPLIER
NT Admins Dialer Team
INPUT
X-ten NT login credentials Agent application login credentials
PROCESS
LOGIN AGENTS
Agent starts soft phone
OUTPUT
Agent Application Campaign Loaded
CUSTOMER
Agents
Agent logs into terminal server using his credentials
Agents starts agent application and login Once agent is logged into agent application he logs into the campaign Required campaign is loaded and agent starts dialing
Page 7
SUPPLIER
Machine Owner
INPUT
Required approvals Required machine information
PROCESS
MAINTENANCE
Dialer Team request field support to perform maintenance
OUTPUT
Machine up and running
CUSTOMER
Dialer Team NT Admin
Field support team performs the maintenance and restarts the machine
Dialer Team restarts the appropriate applications
KPIs and KPOs:

KPIs Month Gender Qualification Experience Country City Shift X X1 X2 X3 X4 X5 X6 X7 KPOs Downtime Y Y1
Page 8
MEASURE PHASE
MEASURE PHASE:
Measurement System Analysis Line Chart Pie Chart Pareto Chart Cause & Effect Diagram Bar Chart Multiple Bar Chart Probability Plot Current Sigma Level
Page 9
Process performance is measured in terms of downtime per month. This time is measured from the clock and noted on an Excel sheet. Different cases of intervals were provided to operators to evaluate those intervals as Good or Bad. While conducting study, Downtime 60 minutes as good and others as bad. After that operators performance was put in Minitab-16 and Measurement System Analysis for Attribute data was analyzed. Results as shown below:
MEASUREMENT SYSTEM ANALYSIS:

According to AIAG 10% overall error rate is acceptable in measurement system. Below report indicating that our Measurement system has acceptance up to 93.3%. Hence our Measurement system is acceptable.
Attribute Agreement Analysis for Results Summary Report
Is the overall % accuracy acceptable? < 50% 100% Misclassification Rates Overall error rate Good rated Bad Bad rated Good Mixed ratings (same item rated both ways) 6.7% 10.0% 3.3% 13.3%
No
93.3% The appraisals of the test items correctly matched the standard 93.3% of the time.
Yes
% Accuracy by Appraiser 120

100.0 85.0
Comments Consider the following when assessing how the measurement system can be improved: -- Low accuracy rates: Low rates for some appraisers may indicate a need for additional training for those appraisers. Low rates for all appraisers may indicate more systematic problems, such as poor operating definitions, poor training, or incorrect standards. -- High misclassification rates: May indicate that either too many Good items are being rejected, or too many Bad items are being passed on to the consumer (or both). -- High percentage of mixed ratings: May indicate items in the study were borderline cases between Good and Bad, thus very difficult to assess.
100
95.0
93.3%
80
60
40
20
Hassan Rauf
Fahad Javaid
Najeeb Rehma
Page 10
Overall Error Rate = 6.7%
Attribute Agreement Analysis for Results Misclassification Report

Most Frequently Misclassified Items
% Good rated Bad Item 1 Item 5 Item 2 Item 7 Item 9 0 10 20 30 Item 3 Item 4 Item 6 Item 8 Item 10 0 10
% Bad rated Good
20
30
Appraiser Misclassification Rates

% Good rated Bad % Bad rated Good % Rated both ways
Hassan Rauf
Hassan Rauf
Hassan Rauf
Fahad Javaid
Fahad Javaid
Fahad Javaid
Najeeb Rehma 0 15 30
Attribute Agreement Analysis for Results Accuracy Report

All graphs show 95% confidence intervals for accuracy rates. Intervals that do not overlap are likely to be different.
% by Appraiser Hassan Rauf Hassan Rauf % by Appraiser and Standard Good
Fahad Javaid
Najeeb Rehma 40 60 80 100
Fahad Javaid
% by Standard Good Bad 40 60 80 % by Trial 100 Hassan Rauf Najeeb Rehma Bad
Fahad Javaid
Najeeb Rehma
40
60
80
100
40
60
80
100
Page 11
Attribute Agreement Analysis for Results Report Card

Check Mix of Items Accuracy and Error Rates Status Description It is good practice to have a fairly balanced mix of Good and Bad items. Your data shows that you have 50% Good items and 50% Bad items. If you have a small percentage of items of one type, you reduce your ability to assess how well the appraisers rate that type of item. The accuracy and error rates are calculated across all appraisals. Suppose you test 10 items, 5 Good and 5 Bad, and three appraisers test each item twice for a total of 60 appraisals (10 x 3 x 2 = 60). To calculate the error rates for Good items, you would have 30 appraisals (5 x 3 x 2); for Bad items you would have 30 (5 x 3 x 2). To calculate the error for items rated both ways, you would have 30 values (10 items x 3 appraisers = 30). The accuracy and error rates are: Accuracy= 93.3% Error= 6.7% Good rated Bad= 10.0% Bad rated Good= 3.3% Rated both ways= 13.3%
i i
LINE CHART:
9000 8000 Total Downtime 7000 6000 5000 4000 3000 2000 1000 0 Total Feb 8079 Mar 6961 Apr 7047 May 6263 Jun 6559 Jul 5405 Aug 6645
Month wise Total Downtime
Above line chart and descriptive statistics shows last seven months trend of the total production downtime on monthly basis.
Page 12
PIE CHART:
Category Wise Downtime

Windows server 4% Change Error 11% Unknown 25% Client Related 4% Database 1% Dialer Hardware 3% Dialer Software 12% Telco 6% Software 3% Service Provider 0% Procedure Error 12%
Facilities 10%
Maintenance 1%
Network Network Hardware 4% 4%
From pie chart of category wise production downtime we can clearly observe that unknown was the largest downtime category with the share of 25% of total downtime. Dialer Software and Procedure Error were the second largest downtime category with 12% share of each catagory. Overall, we have a clear picture of percentage of downtime associated with each root cause category through pie chart.
PARETO ANALYSIS:
Category Vs Downtime
50000 40000 100 80 60 40 20 0
Downtime
20000 10000 0
Root Cause Category
r e ies ro w ar lit Er Er no tw ci f k e ge Fa So ur Un an ed er al Ch oc Di Pr n
Downtime Percent Cum %
r k e ed lc o or ar he at w Te tw Ot el rd Ne tR Ha en k i r Cl wo et N 11661 5465 5379 5237 4652 2842 2066 2043 1933 5681 24.8 11.6 11.5 11.2 9.9 6.1 4.4 4.4 4.1 12.1 24.8 36.5 47.9 59.1 69.0 75.0 79.4 83.8 87.9 100.0
r ro
Page 13
Percent
30000
After constructing the Pareto chart of downtime of causes it was observed that out of remaining 14 categories (except Unknown) only 4 were responsible for a downtime of 44.2%. Procedure error and Dialer software proved to be the first and second largest category of downtime which was responsible for an 11.6% and 11.5% of the total downtime respectively. Change error caused 11.2% while facilities caused around 9.9% of total downtime. From above information, main four major categories identified which are Change Error, Procedure Error, Facilities Failure and Dialer Software. These four categories alone were responsible for 44.2% of total downtime. By managing these four categories we can considerably increase the quality by reducing unplanned downtime.
CAUSE & EFFECT DIAGRAM:

Below cause & effect diagram indicating that there are number of root causes which are responsible for downtime in the system. Four major causes (i.e.: Procedure Error, Facilities Error, Change Error and Dialer Software Failure) are considered to identify the root causes.
Procedure Error
Agents logging into wrong machine Proper login information was not provided Procedure misunderstanding System crash Lack of Education Not clearly defined Procedure wrongly followed Inexperienced technician Virus attack Antivirus was not installed Some malicious software installed Poor Maintenance System upgrade is costly Maintenance performed on wrong time Misunderstanding of timings Virus database was not updated Too much load Incompatibility after system upgrade Earthquake Natural disaster Flood Fire Hardware failure
Facilities Failure
Storm
Documentation not available Not considered important Not upgraded Trainings not arranged Lack of job knowledge Not enough trained resource
Too much load Load unbalancing Software crash Not thoroughly tested Incompatibility with other components Unhandled exception QA not performed before release New version needs to be released immediately Parameters were not double checked Wrong parameters applied Lack of education/training Lack of experience/knowledge
Downtime
Change implemented wrongly Lack of communication between stakeholders Change was misunderstood Lack of automation Resistance to change Tools are considered unimportant Resources are busy in other tasks
Resources not available to develop customized tools Lack of ownership Change manager/implementer not properly defined Technology failed during change Current system does not support upgrade Change was not properly tested Campaign needs to go live on short notice Not good enough testing environment Lack of time
Dialer Software Failure
Change Error
PIE CHARTS:
4% 1%
Country Wise Downtime

0% Pakistan Philippines Senegal 95% United States of America
Page 14
From pie chart of Country wise downtime we can clearly observe that Pakistan was the largest downtime country with the share of 95% of total downtime.
City Wise Downtime

Manila 0% Pittsburg Bend Beckley 2% 1% 0% Dakar 1% King of Prussia 1% Charlston 0%
Karachi 10%
Lahore 85%
From pie chart of City wise downtime we can clearly observe that Lahore was the largest downtime city with the share of 85% of the total downtime. BAR CHARTS:
70.00 Average Downtime 60.00 50.00 40.00 30.00 20.00 10.00 0.00 Total
Shift wise Average Downtime
Evening 58.94
Morning 56.94
Night 39.95
Above bar chart indicates that average downtime occurs in the evening and morning shifts are much higher than the night shift.
Page 15
Gender Wise Average Downtime

60.00 50.00 Average Downtime 40.00 30.00 20.00 10.00 0.00 Total Female 39.79 Male 50.28
Above bar chart indicates that average downtime occurs due to male is more than female.
Qualification Wise Total Downtime

14000 Total Downtime 12000 10000 8000 6000 4000 2000 0 A BBIT Levels 4985 142 5145 132
BCE 156 2
BCS 6827 144
BEE 1704 59
BIS
BIT
BT
MCS 86 2
MIS 420 1
MT 5389 104
Sum of Downtime Count of Downtime
3289 11470 7488 52 190 117
Legend:
A Levels A-Levels BBIT Bachelors in Business and Information Technology BCE Bachelors in Computer Engineering BCS Bachelors in Computer Science BEE Bachelors in Electrical Engineering BIS Bachelors in Information Systems BIT Bachelors in Information Technology BT Bachelors in Telecommunication MCS Masters in Computer Science MIS Masters in Information Systems MISS Masters in Information Systems Security MT Masters in Telecommunication Due to lesser counts in few categories regarding the downtime bar chart used to high light major responsible qualification levels. So, most of the downtime are due to Graduate (i.e.: BIT, BT and BCS). SIX SIGMA (BLACK BELT)PROJECT Page 16
Experience Wise Total Downtime

18000 16000 14000 12000 10000 8000 6000 4000 2000 0 Sum of Downtime Count of Downtime Total Downtime
2-3 15236 334
4-5 16884 291
6-7 10967 230
8-9 3033 74
10-11 809 15
12-14 30 1
Above bar chart indicates that the lesser experience persons are more responsible for downtime.
Age Wise Total Downtime

25000 Total Downtime 20000 15000 10000 5000 0 Sum of Downtime Count of Downtime 28-29 8664 198 30-31 20699 459 32-33 7833 120 34-35 2647 50 36-37 3954 50 38-39 1702 43 40-41 651 10 50-51 457 8 54-55 352 7
Above bar chart indicates that the people having less than 34 years age are more responsible for downtime. MULTIPLE BAR CHARTS:
Country & City Wise Total Downtime

45000 40000 35000 30000 25000 20000 15000 10000 5000 0 Karachi Lahore Pakistan Sum of Downtime Count of Downtime 4668 93 40016 808 Manila Dakar Beckley Bend Total Downtime
Charlst King of Pittsbur on Prussia g 58 1 352 7 877 9
PhilippinesSenegal 195 2 451 16 92 5
United States of America 250 4
Page 17
Above multiplebar chart indicates that the most of downtime occurs in Lahore, Pakistan.
Qualification & Expereince Wise Total Downtime

6000 5000 4000 3000 2000 1000 0 Total Downtime
4-5
8-9
6-7
2-3
6-7
8-9
4-5
2-3
4-5
6-7
8-9
2-3
2-3
4-5
8-9
2-3
4-5
2-3
4-5
6-7
4-5
4-5 10-11
10-11
A Levels
BBIT
BCE
BCS
BEE BIS BIT Qualification & Experience
BT
MCS MIS MT
Above multiplebar chart indicates that the most of downtime occurs due to lesser experience and having Graduate (i.e.: BIT, BT, BCS) qualification.
Age & Expereince Wise Total Downtime

Total Downtime 14000 12000 10000 8000 6000 4000 2000 0
8-9
2-3
4-5
2-3
4-5
6-7
2-3
4-5
6-7
8-9
2-3
4-5
6-7
2-3
4-5
8-9
2-3
4-5
8-9
12-14
12-14
28-29
30-31
32-33
3637 Age & Experience
34-35
38-39
40-41
50- 5451 55
Probability Plot of Downtime

Normal 99.99
Mean StDev N AD P-Value 49.69 62.08 945 82.236 <0.005
99 95
Percent
80 50 20 5 1
0.01
-200
-100
100
200 300 Downtime
400
500
600
700
Above probability plot of the overall downtime for all root cause categories indicating a non normal distribution because the p-values for the Anderson-Darling test are less than 0.05 SIX SIGMA (BLACK BELT)PROJECT Page 18
10-11
4-5
MEASURING THE CURRENT PROCESS SIGMA LEVEL: Root Cause Downtime Root Cause Categories Categories (Minutes per Year) Dialer Software 5379 Procedure Error Dialer Hardware 1431 Network Hardware Network 2043 Database Windows Server 1685 Telecommunication (Telco) Facilities 4652 Software Client Related 2066 Service Provider Maintenance 491 Unknown/Other TOTAL Change Error 5237
Downtime (Minutes per Year) 5465 1933 677 2842 1257 140 11661 46959
COST OF DOWNTIME: Total Production time (Minutes) per Month = 15 hours X 60 Minutes X 26 Days = 23400 Average Down Time (Minutes) per Month = 6708 Average Cost per minute (Human Resources) = Rs. 3575 Average down time Cost / month = Rs. 23981100 SIGMA LEVEL CALCULATIONS: LAST SEVEN MONTH STUDY: Total Downtime (Minutes) = 46959 Total Production Time (Minutes) = 163800 Opportunity per Unit = 1 DPU (Defects / Unit) = 46959 / 163800 = 0.2867 DPO (Defects/opportunity) = 46959 / (163800 X 1) =0.2867 Yield = 1 DPO = 1 0.2867 = 0.7133 DPMO = 286685 (defects/million opportunity) Sigma Level = 2.06 (Using M.S. Excel) CONCLUSION: From above said investigations it is concluded that most of the downtime occurs in Lahore, Pakistan. On average in evening and morning shift downtime occurs more than night shift and male are more responsible than female for this downtime. Persons having lesser experience and having graduate level qualification (i.e: BIT, BT, BCS) are more responsible than others.
Page 19
ANALYZE PHASE
ANALYSIS PHASE: Testing of Hypothesis
Page 20
One-Way ANOVA for Downtime by Country Diagnostic Report

Distribution of Data Compare the location and spread. Data in Worksheet Order Investigate outliers (marked in red).
Pakistan
Pakistan
500 250 0
Philippines
Philippines
500 250 0
Senegal
Senegal
500 250 0
United State
United State
500 250 0 0 250 500
Page 21
One-Way ANOVA for Downtime by Country Summary Report

Do the means differ? 0 0.05 0.1 > 0.5 # 1 2 3 4 Sample Senegal Pakistan United State Philippines Which means differ? Differs from
Yes
P = 0.076 Differences among the means are not significant (p > 0.05).
No
None Identified
Means Comparison Chart
Senegal
Comments Pakistan You cannot conclude that there are differences among the means at the 0.05 level of significance.
United State
Philippines
-400
-200
200
400
The result of the above test shows that County is an insignificant factor as the Pvalue is more than 0.05.
Page 22
The result of the above test shows that City is an insignificant factor as the Pvalue is more than 0.05.
Page 23
One-Way ANOVA for Downtime by Shift Diagnostic Report

Distribution of Data Compare the location and spread.
Evening
Data in Worksheet Order Investigate outliers (marked in red).

Evening
500
250
Morning
0
Morning
500
250
Night
0
Night
500
250
0 0 100 200 300 400 500 600
One-Way ANOVA for Downtime by Shift Summary Report

Do the means differ? 0 0.05 0.1 > 0.5 # 1 2 3 Sample Night Evening Morning Which means differ? Differs from 2 1
Yes
P = 0.000 Differences among the means are significant (p < 0.05).
No
Means Comparison Chart Red intervals that do not overlap differ.
Night Comments You can conclude that there are differences among the means at the 0.05 level of significance. Use the Comparison Chart to identify means that differ. Red intervals that do not overlap indicate means that differ from each other. Consider the size of the differences to determine if they have practical implications.
Evening
Morning
40
60
80
Page 24
The result of the above test shows that shift is a significant factor as the Pvalue is less than 0.05.
2-Sample t Test for the Mean of Downtime (Male and Female) Diagnostic Report
Downtime (Ma Downtime (Fe
500
250
0 1 90 179 268 357 446 535 624 713 802 891 1 6 11 16 21 26 31 36 41 46 51
Power W hat is the chance of detecting a difference? < 40% 60% 90% 100%
What difference can you detect with your sample sizes of 892 and 53? Difference 14.433 16.495 18.907 22.253 Power 60.0 70.0 80.0 90.0
14.433 22.253 For alpha = 0.05 and sample sizes = 892, 53: If the true mean of Downtime (Ma was 14.433 greater than Downtime (Fe, you would have a 60% chance of detecting the difference. If Downtime (Ma was 22.253 greater than Downtime (Fe, you would have a 90% chance.
Power is a function of the sample sizes and the standard deviations. To detect a difference smaller than 18.907, consider increasing the sample sizes.
Page 25
2-Sample t Test for the Mean of Downtime (Male and Female) Summary Report
Mean Test Is Downtime (Ma greater than Downtime (Fe? 0 0.05 0.1 > 0.5 Statistics Sample size Mean 90% CI Standard deviation Difference between means* 90% CI Downtime (Ma 892 50.280 (46.83, 53.73) 62.571 Downtime (Fe 53 39.792 (27.699, 51.886) 52.573
Yes
P = 0.084 The mean of Downtime (Ma is not significantly greater than the mean of Downtime (Fe (p > 0.05).
No
10.488 (-2.0710, 23.047)
* The difference is defined as Downtime (Ma - Downtime (Fe. 90% CI for the Difference Does the interval include zero? Comments 0 5 10 15 20 -- Test: There is not enough evidence to conclude that the mean of Downtime (Ma is greater than Downtime (Fe at the 0.05 level of significance. -- CI: Quantifies the uncertainty associated with estimating the difference from sample data. You can be 90% confident that the true difference is between -2.0710 and 23.047. -- Distribution of Data: Compare the location and means of samples. Look for unusual data before interpreting the results of the test.
Distribution of Data Compare the data and means of the samples.

Downtime (Ma
Downtime (Fe
-100
100
200
300
400
500
600
Page 26
One-Way ANOVA for Downtime by Qualification Power Report

Power What is the chance of detecting a difference? < 40% 60% 90% 100%
What difference can you detect with your sample sizes? Difference Power 23.539 126.15 139.35 150.83 159.82 3.5 60.0 70.0 80.0 90.0 - 60.0 - 100.0 - 100.0 - 100.0 - 100.0
23.539 159.82 Based on your samples and alpha level (0.05), you have at least a 90% chance of detecting a difference of 159.82, and at most a 60% chance of detecting a difference of 23.539.
Power is a function of the sample sizes and the standard deviations. To detect differences smaller than 150.83, consider increasing the sample sizes.
Statistics Qualification A Levels Bachelors _2 Bachelors _3 Bachelors _4 Bachelors _5 Bachelors _6 Bachelors _7 Bachelors _8 Masters in_9 Masters in_1 Sample Size 142 132 2 144 58 52 190 117 2 104 Mean 35.106 38.977 78 47.410 29.034 63.25 60.368 64 43 51.817 Standard Deviation 43.816 41.490 56.569 51.121 38.518 66.703 75.072 82.220 18.385 57.211 Individual 95% CI for Mean (27.836, 42.375) (31.833, 46.121) (-430.25, 586.25) (38.989, 55.831) (18.907, 39.162) (44.680, 81.820) (49.625, 71.112) (48.945, 79.055) (-122.18, 208.18) (40.691, 62.943)
One-Way ANOVA for Downtime by Qualification Summary Report

Do the means differ? 0 0.05 0.1 > 0.5 # 1 2 3 4 5 6 7 8 9 10 Sample Bachelors _5 A Levels Bachelors _2 Bachelors _4 Masters in_1 Bachelors _7 Bachelors _8 Bachelors _6 Masters in_9 Bachelors _3 Which means differ? Differs from 6 6 7 7
Yes
No
Means Comparison Chart Red intervals that do not overlap differ. Bachelors _5 A Levels Bachelors _2 Bachelors _4 Masters in_1 Bachelors _7 Bachelors _8 Bachelors _6 Masters in_9 Bachelors _3 -100 0 100 200 300
1 1
2 2
Comments You can conclude that there are differences among the means at the 0.05 level of significance. Use the Comparison Chart to identify means that differ. Red intervals that do not overlap indicate means that differ from each other. Consider the size of the differences to determine if they have practical implications.
Page 27
The result of the above test shows that qualification is a significant factor as the Pvalue is less than 0.05.
Page 28
One-Way ANOVA for Downtime by Age Diagnostic Report

Distribution of Data Compare the location and spread. 28 29 30
0 500
28

29 30
250
31
500
31
32
33
32
250
33
0
35
500
35
36
38
36
250
38
0
40
500
40
50
55
50
250
55
0
250
500
One-Way ANOVA for Downtime by Age Summary Report

Do the means differ? 0 0.05 0.1 > 0.5 # 1 2 3 4 5 6 7 8 9 10 11 12 Sample 40 30 28 38 35 29 32 31 55 36 50 33 Which means differ? Differs from 7 8 10 10 10 10
Yes
No
Means Comparison Chart Red intervals that do not overlap differ. 40 30 28 38 35 29 32 31 55 36 50 33 -100 0 100 200 300
1 1 1 2 3 4
Page 29
The result of the above test shows that age is a significant factor as the Pvalue is less than 0.05.
Page 30
One-Way ANOVA for Downtime by Experience Diagnostic Report

Distribution of Data Compare the location and spread.
2

3 4
2
500
3
250
4
0
5 6 7
5
500
6
250
7
0
8 9 10
8
500
9
250
10
0
250
500
One-Way ANOVA for Downtime by Experience Summary Report

Do the means differ? 0 0.05 0.1 > 0.5 # 1 2 3 4 5 6 7 8 9 Sample 8 7 2 3 6 4 10 5 9 Which means differ? Differs from 9 9 9 9 9 9 9 1 2 3 4 5 6 7
Yes
No
Means Comparison Chart Red intervals that do not overlap differ. 8 7 2 3 6 4 10 5 9 0 40 80 120 160
Page 31
The result of the above test shows that experience is a significant factor as the Pvalue is less than 0.05.
CONCLUSIONS: Testing of Hypothesis indicating that the few Key Input Variables (KPIs) are became significant like Shift, Qualification, Experience and Age. In Improve phase, further experimentation will be done by considering following significant factors that is Shift, Qualification, and Experience. While age is a significant factor but its a noise factor thats why not considered it further.
Page 32
IMPROVE PHASE
IMPROVE PHASE:
Design of Experiment
Page 33
Summary for Downtime

A nderson-Darling N ormality Test A -S quared P -V alue M ean S tDev V ariance S kew ness Kurtosis N M inimum 1st Q uartile M edian 3rd Q uartile M aximum 90.34 85.76 9 5 % C onfidence Inter vals
Mean Median 80 100 120 140 160 180
0.33 0.483 132.81 79.71 6353.23 0.040952 -0.641979 16 10.00 55.00 135.00 180.00 280.00 175.29 180.00 123.36
50
100
150
200
250
300
95% C onfidence Interv al for M ean 95% C onfidence Interv al for M edian 95% C onfidence Interv al for S tDev 58.88
Graphical summary of the response clears that the data generated (i.e.: response) against the Design of Experiments is normally distributed and hence the assumption of the normality is fulfilled.
Page 34
Normal Plot of the Standardized Effects

(response is Downtime, Alpha = 0.05)
99 Effect Ty pe Not Significant Significant
F actor A B C N ame S hift Q ualification E xperience
95 90 80
Percent
70 60 50 40 30 20 10 5 B BC
-8
-6
-4 -2 Standardized Effect
Page 35
Pareto Chart of the Standardized Effects

(response is Downtime, Alpha = 0.05) 2.306 B BC C
F actor A B C N ame S hift Q ualification E xperience
Term
ABC AC AB A 0 1 2 3 4 5 Standardized Effect 6 7 8
Residual Plots for Downtime

Normal Probability Plot
99 90 50 10 1 -50 -25 0 25 Residual 50 50
Versus Fits
Residual
Percent
25 0 -25 -50 0 50 100 150 Fitted Value 200
Histogram
6.0
Mean StDev N -4.44089E-15 24.31 16
Versus Order
50
Frequency
Residual
-40 -20 0 20 Residual 40
4.5 3.0 1.5 0.0
25 0 -25 -50
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Observation Order
Page 36
Main Effects Plot for Downtime

Data Means
Shift Qualification
200 150 100
Mean
50 Night 200 150 100 50 2 14 Experience Evening A-Levels Maters
Main effect plots of shift, qualification & experience shows that the most dominating factor is the qualification. As it gives visible variation in the downtime required for the reducing the unplanned downtime.
Cube Plot (data means) for Downtime

15.0 37.5
105.0 Maters
115.0
Qualification
230.0
185.0 14 Experience 2
165.0 A-Levels Night Shift
210.0 Evening
Cube plot for downtime shows the optimum conditions for the desired results. If minimum unplanned downtime is required than organization must work with the combination of Night shift, Master Qualification, and 14 year of experience (means maximum experience). SIX SIGMA (BLACK BELT)PROJECT Page 37
RESPONSE OPTIMIZATION:
Shift Evening Night Night Qualific Maters Maters A-Levels Experien 14.0 [14.0] 2.0
Optimal High D Cur 1.0000 Low
Composite Desirability 1.0000
Downtime Minimum y = 15.0 d = 1.0000
When optimizer is run for the goal of minimum downtime evaluation, it gives minimum downtime which is 15 minutes.
Page 38
Probability Plot of Downtime

Normal
99 Mean StDev N AD P-Value 132.8 79.71 16 0.328 0.483
95 90 80
Percent
70 60 50 40 30 20 10 5
-100
100 Downtime
200
300
Test for Equal Variances for Downtime

Shift Night Qualification A-Levels Experience 2 14 Maters 2 14 Evening A-Levels 2 14 Maters 2 14 0 5000 10000 15000 20000 95% Bonferroni Confidence Intervals for StDevs
Bartlett's Test Test Statistic P-Value 11.06 0.136
Page 39
Pareto Chart of Root Cause Catagories Before Improvement

50000 40000 100 80 60 40 20
Downtime
20000 10000 0
Root Cause Category
r r s e ro ro wn ar itie Er Er no c il ftw k e re Fa So Un ng du ler ha ce a C o Di Pr
k e d lc o or te ar Te tw ela dw r R Ne Ha nt lie rk C o tw Ne
r he Ot
Downtime Percent Cum %
11661 5465 5379 5237 4652 2842 2066 2043 1933 5681 24.8 11.6 11.5 11.2 9.9 6.1 4.4 4.4 4.1 12.1 24.8 36.5 47.9 59.1 69.0 75.0 79.4 83.8 87.9 100.0
Pareto Chart of Root Cause Catagories After Improvement

20000 100 80 60 40 5000 0 20 0
Total Downtime
15000 10000
Root Cause Catagories
r o n rk ted are ver are or re ties er are he r ro rr Telc wa r ow two a ili w Er ovid ftw Ot el se o ftw e E kn e rd rd Fac e r R o s r P N a S Un ng Ha nt r H dow du ice rS a k e e ie e al Ch or rv Cl oc al Win Di Pr tw Se Di Ne Total Downtime 3258 1759 1503 1198 1180 1175 1106 1089 1025 1005 967 965 960 1703 Percent 17 9 8 6 6 6 6 6 5 5 5 5 5 9 Cum % 17 27 35 41 47 53 59 65 70 76 81 86 91 100
Month Wise Total Downtime (After Improvement "Sep. to Dec.")

9000 8000 7000 6000 5000 4000 3000 2000 1000 0 Total Downtime
Feb
Mar 6961
Apr 7047
May 6263
Jun 6559
Jul 5405
Aug 6645
Sep 5430
Oct 4355
Nov 2122
Dec 2276
Total Downtime 8079
Page 40
Percent
Percent
30000
SIGMA LEVEL CALCULATIONS (AFTER IMPROVEMENT): FOUR MONTH STUDY: Total Downtime (Minutes) = 14183 Total Production Time (Minutes) = 93600 Opportunity per Unit = 1 DPU (Defects / Unit) = 14183 / 93600 = 0.1515 DPO (Defects/opportunity) = 14183 / (93600 X 1) = 0.1515 Yield = 1 DPO = 1 0.1515 = 0.8485 DPMO = 151528 (defects/million opportunity) Sigma Level = 2.53 (Using M.S. Excel) SIGMA LEVEL BEFORE THE IMPROVEMENT 2.06 AFTER THE IMPROVEMENT 2.53
CONCLUSIONS: With new suggested combination provided by the Design of Experiment; the overall system performance is improved as shown in the above sigma level calculation.
Page 41
CONTROL PHASE
CONTROL PHASE:
Process Failure Mode & Effect Analysis Control Charts
Page 42
Process Failure Mode and Effect Analysis: CHANGE ERROR

Process Function / Requirement Apply Filter Potential Failure Mode Leads never get buffered Potential Effects of Failure High wait time Potential Causes / Mechanisms of Failure Applied wrong filter Wrong filter was provided Current Process Controls Filter is just overviewed to find out any kind of error No process controls available RPN Recommended Actions Check the filter in database and get the leads count before actually applying it Double check the filter with developer and with Ops manager to discuss the result of implementation and avoid requesting filter change himself Always ask the requester if change is only for one day or its for until further notice O Responsibility Jawad Hassan (Analyst Systems and Production) D S 8
120
144
Wrong leads gets buffered
Agents talking to wrong customers
Import date of leads not updated Part of filter missing while applying
196
Zeeshan Jamil (Supervisor Systems and Production)
168
Filter reverted to old one
Agents getting wrong leads
Applied for only one day instead of until further notice 4 6 Current tasks finished
Usually asked from OPS team if change is only for one day or for until further notice No process controls available Normally developers mentions in which database to
Ali Gohar (Analyst Systems and Production)
144
54
Leads Loading
Loaded to wrong database
Agent in downtime waiting for leads
Wrong information provided by developer
32
Tasks audit should be performed every month Always get a confirmation from dialer team and developer
Afriaz Cheema (Manager Systems and Production) Hammad Haasan (Database Administrator)
Page 43
load the leads
about the location of the database
Misunderstanding by the DBA Loaded with wrong scrubbing information Customers complaining about DNC 6 Wrong scrubbing information provided by client services/developer
Update Script
Incorrect script deployed
Missing some information from script
Miscommunication between developer and client services 5 5
No process controls available Client services normally mentions the scrubbing criteria Developer just relies on the information provided
32 Double check with the client services before actually scrubbing the leads Communication regarding script must be documented and understanding must be developed by asking questions Script must be verified after development and before UAT There should be more focus to improve testing environment and employees should be encouraged to do more and more testing in test Arsalan Ahmed (Database Administrator)
72
Bilal Sheikh (Software Engineer)
100
Developer missed the script
No process controls available Basic testing is performed before going live
120
Bilal Sheikh (Software Engineer) Afaq Ali (Deputy Head of Production)
Missing some call disposition term codes
Functionality not working in production environment Term codes were not added
168
216
Page 44
Dialer Application Update
Applications crashing
Agents get kicked out of system 8
Unhandled Exception 4
Some level of exception handling is done by the developer Once issues are reported the parameters are double checked to find out if anything was missed Information only flows through formal emails
128
Applications not starting
Production affected
Parameters not adjusted properly
63
Application not working properly
Some functionalities stop working like TPV
Controller and CTI Engine are not synchronized
120
environment before going live More importance needs to be given to the exception handling in programming Updated parameters should be verified by the supervisor or checked by other team member in order make sure changes are correct Both dialer development and CTI Engine development team should have a closer interaction and communication before making any changes in any component. There should be more informal communication
Abul Asim (Senior Software Engineer)
Ahmed Usman (Supervisor Systems and Production)
Abul Asim (Senior Software Engineer) Ahmed Raza (Software Engineer)
Page 45
Windows Server Update
Dialer Applications crashing
Dialer applications not starting and agents can't login
Wrong version upgrade
Normally version upgrade is done over the phone as some times clients need not to be aware of the change
96
Unnecessary upgrade to some application and frameworks
Normally upgrades are not allowed
96
Change dialing parameters
Dialing stopped
agents not getting calls
Applied wrong parameter
No process controls available Normally when the issue arises, parameters are checked to make sure if these were updated correctly or not
Everything regarding new and old version must be documented including what is current version, what is new version and are the back out steps in case a change is failed Automatic upgrade must be turned off as it affect custom build application Parameters should be double checked Change management system must be properly implemented and every change must be properly documented and approved before actual change is implemented. Change must be verified by supervisor or another person
Afaq Ali (Deputy Head of Production)
Rizwan Ali (System Administrator)
Dialing with wrong parameters
Too fast dialing
Dialing in wrong time zones Dialing in wrong mode
TAR updated with high value TAR updated with low value Wrong time zones opened Incorrect dialing mode applied
4 4 5
6
6
72
72
150
Zeeshan Jamil (Supervisor Systems and Production) Asim Zafar (Director IT Operations) Shoib Sakoor (Head of Production)
30
Page 46
Process Failure Mode and Effect Analysis: DIALER SOFTWARE FAILURE

Process Function / Requirements Software Crash Potential Failure Mode Application closed itself Potential Effect of Failure Agents logged out and are in downtime Potential Cause / Mechanism of Failure Unhandled exception Current Process Controls Some known exceptions are handled through programming RPN Recommended Action(s) There should be a more focus on exception handling and development team should be more concerned about this Application threads should be properly controlled and memory should be managed in a better way Capacity should be continuously monitored and whenever there are new agents added to the system, the capacity must be rechecked to analyze if current resources are enough to handle this or not Before deployment of application, an extensive QA/testing should be performed and specially stress testing should also be performed
Responsibility Abul Asim (Senior Software Engineer/Program Architect)
S 8
96
Too many processes running
No process control available
96
Abul Asim (Senior Software Engineer/Program Architect)
Capacity issues
Afriaz Cheema (Manager Systems and Production)
64
QA/Testing not performed extensively 4
No process control available 6 192
Abdullah (Head of QA)
Page 47
Compatibility issues with other components Parameter Configuration Application not starting or crashing again and again Agents logged out and are in downtime Wrong parameters applied 8
96
Implemented himself checks the parameters
144
Agents are not able to perform their jobs properly 5
Syntax mistake 2
Implemented himself checks the parameters Implemented himself checks the parameters
30
Some values missed 3
90
Too much load
Software crashes or starts malfunctioning
Leads are unnecessarily burned
No further agents are able to login
Stuck channels are not released so rest of the leads are marked as ND Resources utilization is too high and no further resources are available to perform further actins
No process control available 5 5 125
All relevant stakeholders should be involved during development process Parameters should be double checked and if possible there should be tools available instead of updating anything from backend Training should be given to the technical teams on the current tools being used Parameters should be double check with another team member immediately after any updating This needs to be taken care at programming level
Rabia (Manager Training and Development)
Ali Gohar (Analyst Systems and Production)
No process control available 3 4 60
OPS team should always inform technical teams if there is any change in current resources allocation
Matthew Debelak (Operations Manager)
Page 48
Lead disposition is not properly updated
Application is responding slow to database
120
There should a more focus performance optimization
Page 49
Process Failure Mode and Effect Analysis: FACILITIES FAILURE

Process Function / Requirements System Crash Potential Failure Mode System shutdown Potential Effect of Failure All relevant resources are in downtime Potential Causes / Mechanisms of Failure Too much workload Current Process Controls Network utilization is normally monitored by GNOC RPN Recommended Actions Systems should be monitored continuously to check their capacity. Stress testing should also be performed after every couple of months Compatibility issues must be taken into consideration before updating any software and all stake holders should be informed about the update Nothing can be done Hardwares must be continuously updated Generators should be ready with extra fuel available
Responsibility Afriaz Cheema (Manager Systems and Production)
S 8
64
Incompatibility while updating with new software/hardware
Head of production normally checks with the development team about incompatibility issues
120
Afriaz Cheema (Manager Systems and Production) Afaq Ali (Deputy Head of Production)
Unexpected error
Facility Evacuation
System never comes backup All systems are shutdown
All resources are in downtime All relevant resources are logged out
Hardware failure 8 Storm 8 Heavy Rains
No process control available Nothing can be done
96
144
2 2
UPS are available in case of electricity failure
3 3
48 48
Ehtesham Opel (Manager System Administrator) John Skubis (Field Support Officer)
Page 50
Earthquake
Maintenance
System not available for production
Production cannot be started
Maintenance started on wrong time due to misunderstanding
No process control available Normally emails mention the time
96
Nothing can be done Time should be properly mentioned either its Pakistan time, US time or UK time Hardwares must be continuously updated An extra resource should be hired who could be contacted during off contact hours of primary person Antivirus must be regularly updated and security policies must be tightened without exception to anyone. WSUS server must be installed so that all users are automatically updated on regular basis Munam Khalid (Helpdesk Analyst)
120
Hardware failure during maintenance No one available to restart system after maintenance as the person is moved to another site for some other maintenance Antivirus was not updated
No process control available On contact person is normally available
96
120
Afriaz Cheema (Manager Systems and Production) Shoib Sakoor (Head of Production)
Virus Attack
System shutdown
All user disconnected 8
Some malicious software was installed Windows domain server was attacked due to lack of security Some malicious software/patch was installed that affected the software
System not recognizing the users Some applications not functioning properly
Some users cannot login
Antivirus is manually updated All users are not allowed to install the software Antivirus and security policies are in place
48
64
96
Ehtesham Opel (Manager System Administrator) Shakeel Husain (Manager Networks)
Users are not able to perform their jobs properly
60
Page 51
Process Failure Mode and Effect Analysis: PROCEDURE ERROR

Process Function / Requirements Login Agents Potential Failure Mode Agents Stuck on agent application Potential Effect of Failure Can't login Potential Causes / Mechanisms of Failure Dialer is down and was not restarted Current Process Controls No process control available RPN Recommended Actions Before production starts check all the dialers that these are restarted Before production login a test agent to make sure that dialer applications are up and running
Responsibility Jawad Hassan (Analyst Systems and Production)
S 8
64
Agents kicked out of agent application immediately after they login
Can't start production
Controller is down and was not restarted CTI Engine is not properly working Dialogic is not working properly X-ten /dial pad is not configured properly
288
Jawad Hassan (Analyst Systems and Production)
216
3 No process control available 4
216 Agents should be properly given training regarding how to configure the phone before they login Agents should always sit on their designated stations New agents must always be assigned to the campaign by requesting the required Jason Oliver(Operations Manager)
192
8 Audio codec is not configured
3 Specific agents are assigned to the campaign when it created
168
Joane (Operations Supervisor) Joane (Operations Supervisor)
No campaigns loaded
Can't start production 8
Not assigned to the specific campaign
168
Page 52
Logging in to wrong dialer
Supervisors inform the agents about their current dialer 3 7 168
No dialing
Long wait time 7
Campaign not setup to dial during the specific time agents try to login
Reboot Dialer
Dialer never comes backup
Loss of production 8
Was shutdown instead of reboot Hardware failure Dialogic was not started with optimum settings CTI Engine threads were not stable when next application was started
Production time is normally communicated to Technical teams before production starts No process control available No process control available No process control available
168
technical teams before they try to login OPS team should be informed if dialer is changed and it should be documented and OPS should acknowledge the receipt of email as well OPS team must ensure that they always inform technical teams if there is any change in production time Shutdown option should be disabled for the user Nothing can be done Technical support teams should be given proper training and their knowledge should be continuously updated regarding the
Jason Oliver(Operations Manager)
168
Nadeem (System Administrator)
112
Applications Failing to start
Dialer is not ready for production 8
64
256
Page 53
Applications were started in wrong sequence One of the applications were not started
112
168
Script Deployment
Script Missing
Agents can't see the script and can't properly communicate with customers Performance impacting as agents can't properly communicate with customers
Wrong Script shown
Script was not deployed on one of the terminal servers Some files were not copied Version number was not updated
Script and files are manually checked on all terminal servers
60
current processes. Checklists should be maintained and followed if a process always follows the same steps. A test agent should also be logged in before production to ensure applications are properly working An automated application should be developed that deploys the script itself
4 Script version is checked by the person who updates the script
120 An automated application should be developed that updates the script version automatically Afaq Ali (Deputy Head of Production)
96
Page 54
Critical identified processes which should be monitored on regular basis according to corresponding recommended actions.
Process Function / Requirements Potential Effects of Failure Potential Causes / Mechanisms of Failure Current Process Controls Root Cause Category RPN
Potential Failure Mode
Recommended Action(s) Before production login a test agent to make sure that dialer applications are up and running Technical support teams should be given proper training and their knowledge should be continuously updated regarding the current processes. Checklists should be maintained and followed if a process always follows the same steps. A test agent should also be logged in before production to ensure applications are properly
Responsibility
Login agents
Agents Stuck on agent application
Can't login
Controller is down and was not restarted
288
Procedure Error
Reboot dialer
Applications Failing to start
Dialer is not ready for production
CTI Engine threads were not stable when next application was started
256
Procedure Error
Page 55
Update Script
Incorrect script deployed
Missing some call disposition term codes
Term codes were not added
Basic testing is performed before going live
216
Login agents
Agents Stuck on agent application
Can't login
CTI Engine is not properly working
216
Apply filter
wrong leads get buffered
Agents talking to wrong customers
Import date of leads not updated
no process controls available
196
Software Crash
Application closed itself
Agents logged out and are in downtime
QA/Testing not performed extensively
192
working There should be more focus to improve testing environment and employees should be encouraged to do more and more testing in test environment before going live Before production login a test agent to make sure that dialer applications are up and running Double check the filter with developer and with Ops manager to discuss the result of implementation and avoid requesting filter change himself Before deployment of application, an extensive QA/testing should be performed and
Change Error
Procedure Error
Zeeshan Jamil (Supervisor Systems and Production)
Change Error
Abdullah (Head of QA)
Dialer Software
Page 56
specially stress testing should also be performed Agents kicked out of agent application immediately after they login Agents should be properly given training regarding how to configure the phone before they login Change management system must be properly implemented and every change must be properly documented and approved before actual change is implemented. Change must be verified by supervisor or another person Parameters should be double checked and if possible there should be tools available instead of updating anything from backend
Login agents
Can't start production
x-ten / dial pad is not configured properly
192
Jason Oliver(Operations Manager)
Procedure Error
Change dialing parameters
Dialing with wrong parameters
Dialing in wrong time zones
Wrong time zones opened
Normally when the issue arises, parameters are checked to make sure if these were updated correctly or not
150
Asim Zafar (Director IT Operations) Shoib Sakoor (Head of Production)
Change Error
Parameter configuration
Application not starting or crashing again and again
Agents logged out and are in downtime
Wrong parameters applied
Implemented himself checks the parameters
144
Dialer Software
Page 57
System Crash
System never comes backup Software crashes or starts malfunctioning
All resources are in downtime Leads are unnecessarily burned
Hardware failure Stuck channels are not released so rest of the leads are marked as ND
Nothing can be done
144
Hardwares must be continuously updated This needs to be taken care at programming level Compatibility issues must be taken into consideration before updating any software and all stake holders should be informed about the update Time should be properly mentioned either its Pakistan time, US time or UK time
Ehtesham Opel (Manager System Administrator) Abul Asim (Senior Software Engineer/Program Architect)
Facilities Failure
Too much load
125
Dialer Software
System Crash
System shutdown
All relevant resources are in downtime
Incompatibility while updating with new software/hardware
Head of production normally checks with the development team about incompatibility issues
120
Afriaz Cheema (Manager Systems and Production) Afaq Ali (Deputy Head of Production)
Facilities Failure
Maintenance
System not available for production
Production cannot be started
Maintenance started on wrong time due to misunderstanding
Normally emails mention the time
120
Munam Khalid (Helpdesk Analyst)
Facilities Failure
Page 58
Xbar-R Chart of Downtime Stability Report

Is the process mean stable? Investigate out-of-control subgroups. Look for patterns and trends.
60 UCL=57.42
40
Mean
_ _ X=30.16
20 LCL=2.89 1 3 5 7 9 11 Subgroup 13 15 17 19
Is the process variation stable? Investigate out-of-control subgroups. Look for patterns and trends.
150 100 50 LCL=19.7 0 1 3 5 7 9 11 Subgroup 13 15 17 19 UCL=157.2 _ R=88.5
Range
Page 59
Xbar-R Chart of Downtime Summary Report

Is the process mean stable? Evaluate the % of out-of-control subgroups. 0% > 5% 60 Xbar Chart Investigate out-of-control subgroups. UCL=57.42
Yes
0.0%
No
40
Mean
_ _ X=30.16
20 LCL=2.89 1 3 5 7 9 11 13 15 Subgroup 17 19
Comments The process mean is stable. No subgroups are out of control on the Xbar chart. 0
R Chart Investigate out-of-control subgroups. 150 100 50 LCL=19.7 0 1 3 5 7 9 11 13 15 Subgroup 17 19 UCL=157.2
CONCLUSIONS: Process Failure Mode & Effect Analysis (PFMEA), X-bar & R Charts are suitable for monitoring and controlling the system.
Range
_ R=88.5
Page 60
Page 61

Six Sigma (Black Belt) Project (Hakeem-Ur-Rehman)

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Six Sigma (Black Belt) Project (Hakeem-Ur-Rehman)

Загружено:

Авторское право:

Доступные форматы

SIX SIGMA BLACK BELT PROJECT REPORT

MANAGING & ENHANCING QUALITY OF IT OPERATIONS BY REDUCING THE UNPLANNED DOWNTIME

HAKEEMURREHMAN 27022012 Lahore, Pakistan SUPERVISOR: DR. NADEEM SHAFIQ BUTT

THIS PROJECT REPORT IS PART OF THE REQURMENT FOR THE

SIX SIGMA BLACK BELT COURSE

PIQC INSTITUTE OF UALITY AND SINGAPORE QUALITY INSTITUTE

SIX SIGMA (BLACK BELT)PROJECT

SIX SIGMA (BLACK BELT)PROJECT

PROJECT IT Operations & Development SCOPE: BEFORE IMPROVEMENT MONTHLY DOWNTIME :

Month wise Total Downtime

AFTER IMPROVEMENT MONTHLY DOWNTIME :

Month Wise Total Downtime

Feb Mar Apr May Jun

Jul Aug Sep Oct Nov Dec

Dec 2011 1/1

Jan 2012 8/1 15/1 22/1 29/1

Feb 2012 5/2 12/2

SIX SIGMA (BLACK BELT)PROJECT

DEPLOYMENT PROCESS FLOW DIAGRAM:

Request to Create New Campaign

Document that contains requirements for new campaign No

Request to Load the Leads

Data which Need to be Loaded

Request to update the filter

Satisfied with Performance

Develop Campaign Script

Approval for Script Deployment

Develop Query to Load the Leads

Develop Filter for Leads Selection No

Correct format Yes

Load the Leads

Perform Database Maintanance

Perform Leads Scrubbing

Operations Dialer Team Team

Analyze Current System and Request Maintainance

Change Dialing Parameters

Report any Production Impacting Issue

Open the Bridge

Get Required Teams on the Bridge

Provide Downtime Details to Concerned Person

Have Login Rights

Give Rights to the Agents

Perform System Maintainance

Set Rules to Access the Network

Monitor Network Traffic

Perform Maintenance Activity of Telco Lines with Career

Analyse Network Health in Case of Issues

Development team develops the filter

SIX SIGMA (BLACK BELT)PROJECT

Analyst stops the CTIEngine and Dialogic

Restart the machine

Once machine is backup restart the dialogic

Restart the CTIEngine and Controller applications

Dialer is ready for production

Developer makes changes in the script

Script is tested on test server

Developer sends the script to Dialer Team for deployment in production

Dialer Team deploys the script after getting appropriate approvals

SIX SIGMA (BLACK BELT)PROJECT

Dialer Team analyst implements the strategy

Development team develops the filter

Agent logs into terminal server using his credentials

SIX SIGMA (BLACK BELT)PROJECT