Учебный проект второй сессии курсов шести сигм для зеленых поясов / SixSigmaOnline.ru http://sixsigmaonline.ru/load/38-1-0-256

2. Проектная команда
Лидер проекта: Олешко В.
Спонсор проекта: Генеральный директор компании
Эксперты: Руководитель проектно-аналитической
службы
Руководители сервисных подразделений
Проектная команда: Аналитик ИС «Сервис Деск»
Операторы ИС «Сервис Деск»
Программисты
Пользователи: Высшее руководство компании
Руководители сервисных подразделений
Инициаторы обращений
Руководитель проектно-аналитической
службы
Операторы ИС «Сервис Деск»
2 © Six Sigma Online . ru

3. DEFINE
Определение проблемы Цели проекта
С момента начала работы ИС «Сервис Деск» (14.07.2011 г.) Стратегическая цель: снизить количество ошибок при
регулярно поступало большое количество жалоб, связанных определении типа, классификатора обращения и привязки
с качеством информации в системе. Выявлялось множество обращения к матчу до 5%.
ошибок при занесении обращений в систему , их
классификации, определении типа, привязке к матчу. Это
приводило к:
1) невозможности качественно провести анализ проблем,
возникающих с различными системами и сервисами, с целью
выявления и устранения их коренных причин;
2) неадекватной оценке работы персонала сервисных
подразделений и искажении данных, используемых для
начисления премий этой категории сотрудников;
3) назначению неправильных SLA (сроков выполнения
задачи) исполнителям.
Область проекта Обоснование проекта
В рамках проекта необходимо оптимизировать процесс по Достижение цели проекта позволит:
приему и внесению в ИС «Сервис Деск» обращений о сбоях в 1. Повысить качество аналитической информации,
работе технических и информационных систем. поступающей руководству компании для принятия решений.
2. Повысить уровень мотивации сотрудников (операторов
В рамках проекта не рассматривается правильность и «Сервис Деск»).
своевременность закрытия обращений в ИС «Сервис Деск». 3. Накопить опыт решения проблем с качеством данных в
информационных системах.
Дата начала проекта – 24.10.11 г.
Плановая дата завершения проекта – 25.11.11 г.
Фактическая дата завершения проекта – 01.12.11 г.
3 © Six Sigma Online . ru

4. DEFINE
Календарный план проекта
4 © Six Sigma Online . ru

5. DEFINE
SIPOC процесса «Сервис Деск»
5 © Six Sigma Online . ru

6. DEFINE
Требования заказчика к выходам процесса
1. В систему должны вноситься все поступающие обращения
2. Внесение данных в систему должно выполняться по мере их поступления без задержки
3. Все поля в обращении должны быть заполнены
4. Обращения должны быть правильно классифицированы
5. Должен быть верно указан тип обращений
6. Обращения должны быть корректно привязаны к матчам
Анализ рисков проекта
6 © Six Sigma Online . ru

7. DEFINE
Что дальше?
На этом этапе в ходе составления QFD
(Дома качества) получена
предварительная оценка степени
влияния параметров процесса на
удовлетворение требований заказчика.
Согласно этой оценке, наибольшее
влияние оказывают 4 параметра:
• дисциплинированность диспетчера;
• наличие, полнота и понятность
инструкций по работе с ИС;
• уровень квалификации диспетчера;
• эргономичность интерфейса
ИС "Сервис Деск".
Подтвердить или опровергнуть эти
утверждения предстоит на
следующих этапах проекта.
7 © Six Sigma Online . ru

8. MEASURE
Общие сведения о собранных данных Актуальное состояние процесса
Из ИС «Сервис Деск» были выгружены в файл Уровень ошибок: 32,2%
формата .xls данные об обращениях за период DPMO: 107440
01.10.11-27.10.11. Общее количество обращений за Z Bench: -1,29
этот период – 1362. Эти данные были
проанализированы на предмет наличия ошибок
определения типа и классификатора обращения и
привязки обращения к матчу.
Результаты анализа измерительной системы Дополнительные риски и сложности
Данные были валидированы путем выборочной Наибольшую сложность вызвала оценка
перепроверки результатов измерений экспертом измерительной системы. В силу специфики проекта
более высокого уровня квалификации. предложенная в архиве вкладка не могла быть
использована, поэтому пришлось использовать
другой способ валидации. Несмотря на это, этап
был завершен в плановые сроки.
8 © Six Sigma Online . ru

9. MEASURE
Результаты анализа измерительной системы
Поскольку стандартный анализ Gage R&R в данном
проекте не применим, была проведена валидация
измерительной системы.
Анализ процедуры проверки данных показал, что
ошибки измерения могут возникать на этапе обработки
уже выгруженных данных, когда эксперт принимает
решение, правильно ли заполнены поля обращения.
Эти ошибки обусловливаются уровнем квалификации
эксперта, который осуществляет проверку данных.
Подтвердить достоверность проведенных измерений
можно путем выборочной перепроверки результатов
измерений экспертом более высокого уровня
квалификации.
Было проверено 1362 обращения, зафиксированные в
системе с 1.10.11 г. по 27.10.11 г. В ходе проверки
выявлено 439 ошибок. Экспертом более высокого
уровня квалификации было выборочно проверено 400
обращений (29 %). Расхождения с результатами
первоначального анализа выявлены в 7 случаях, что
составляет 1,75 % от 400. Результаты первичной
проверки наличия ошибок в ИС признаны приемлемо
точными.
9 © Six Sigma Online . ru

10. MEASURE
Распределение количества ошибок по дням
Общее количество ошибок
50,00
40,00
30,00
20,00
10,00
0,00
1.10
2.10
3.10
4.10
5.10
6.10
7.10
8.10
9.10
13.10
10.10
11.10
12.10
14.10
15.10
16.10
17.10
18.10
19.10
20.10
21.10
22.10
23.10
24.10
25.10
26.10
27.10
Среднее Отклик
Ошибки типа и классификатора
На 1м графике четко выражены 3 пика: 2го, 19 и 23го 80,00
октября. Эти пики соответствуют матчевым дням. В 70,00
такие дни появляются ошибки привязки к матчу (в 60,00
прочие дни этот вид ошибок отсутствует), поэтому общее 50,00
число ошибок резко возрастает. 40,00
После исключения ошибок привязки к матчу (2й график) 30,00
пики сгладились, а разброс данных уменьшился. 20,00
Провалы 1го, 9го, 15го, 16го и 22го октября объясняются 10,00
выходными днями. В эти дни на стадионе работает мало 0,00
людей, соответственно резко падает число обращений в
1.10
2.10
3.10
4.10
5.10
6.10
7.10
8.10
9.10
10.10
11.10
12.10
13.10
14.10
15.10
16.10
17.10
18.10
19.10
20.10
21.10
22.10
23.10
24.10
25.10
26.10
27.10
службу «Сервис Деск». Этот вывод подтверждается и
графиком количества обращений по дням.
Среднее Отклик Обращения
10 © Six Sigma Online . ru

11. MEASURE
Определение вида распределения
Probability Plot of Общее число ошибок Probability Plot of Ошибки типа и классификатора
Normal - 95% CI Normal - 95% CI
99 99
Mean 16,26 Mean 13,37
StDev 13,04 StDev 8,015
95 N 27 95 N 27
AD 1,261 AD 0,398
90 90
P-Value <0,005 P-Value 0,343
80 80
70 70
Percent
Percent
60 60
50 50
40 40
30 30
20 20
10 10
5 5
1 1
-30 -20 -10 0 10 20 30 40 50 60 -10 0 10 20 30 40
Общее число ошибок Ошибки типа и классификатора
Был проведен тест на нормальность общего числа ошибок и ошибок типа и классификатора (без учета
ошибок привязки к матчу). Общее число ошибок не соответствует нормальному распределению. Напротив,
распределение совокупности ошибок типа и классификатора близко к нормальному.
11 © Six Sigma Online . ru

12. MEASURE
Актуальное состояние процесса
Статистический анализ процесса дал следующие результаты:
Показатель Общее число ошибок (в Ошибки типа и классификатора (в
день) день)
Среднее значение 16,26 13,27
Мода 13 13
Минимальное значение 1 1
Максимальное значение 52 13
Стандартное отклонение 13,04 8,02
DPMO 107440 132526
Z Bench - -1,29
Уровень ошибок за весь рассмотренный период составил 32,2%. Поскольку данные об ошибках типа и
классификатора соответствуют нормальному распределению (в отличие от общего числа ошибок),
трансформация данных не выполнялась и уровень сигм рассчитывался только для этой группы данных.
Уровень сигм очень низкий (1,29). В ходе проекта необходимо снизить среднее значение количества
ошибок и уровень разброса.
12 © Six Sigma Online . ru

13. MEASURE
Расчет минимального объема выборки
Power Curve for 1-Sample Z Test for Общее число ошибок Power Curve for 1-Sample Z Test for Ошибки типа и классификатора
1,0 1,0
Sample Sample
Size Size
19 7
0,8 A ssumptions 0,8 A ssumptions
A lpha 0,05 A lpha 0,05
S tD ev 13,04 S tD ev 8,02
A lternativ e N ot = A lternativ e N ot =
0,6 0,6
Power
Power
0,4 0,4
0,2 0,2
0,0 0,0
-10 -5 0 5 10 -10 -5 0 5 10
Difference Difference
На основе имеющихся данных был выполнен расчет минимального объема выборки. По результатам
расчета для анализа всех 3х типов ошибок необходимо отбирать по 19 обращений в день. Исключение из
анализа ошибок 3го типа (привязка к матчу) сокращает величину стандартного отклонения и,
соответственно, размер выборки до 7 обращений в день.
13 © Six Sigma Online . ru

14. MEASURE
Дополнительные риски и сложности
Этот этап проекта завершен в запланированные сроки. Наибольшую сложность вызвала оценка
измерительной системы. В силу специфики проекта предложенная в архиве вкладка не могла быть
использована. Встал вопрос, каким образом можно валидировать систему измерения. Частично это было
сделано с помощью анализа процедуры проверки наличия ошибок. Но на самом деле любая система
измерения, основанная на экспертной оценке при отсутствии однозначных формальных критериев
принятия решения, не может быть полностью валидирована - всегда остается риск ошибок или
разногласий во мнении 2х экспертов. Позднее эта проблема всплывала в ходе проекта не раз: операторы
не были согласны с оценкой аналитика, руководитель подразделения находил ошибки как в работе
операторов, так и у аналитика, некоторые спорные моменты были вынесены на уровень Директора по ИТ,
который ранее разрабатывал логику работы процесса "Сервис Деск" и руководил внедрением ИС. Его
решение становилось "истиной в последней инстанции".
На будущее вынесен следующий урок: если есть возможность – необходимо избегать введения
классификаторов, для которых невозможно четко определить формальные критерии. Если такой
возможности нет - уделить особое внимание обучению операторов; дать им возможность постоянно
консультироваться с экспертом в случае спорных моментов; формировать базу знаний, где фиксировать
все прецеденты - спорные случаи и принятые решения по ним.
Что дальше?
Необходимо проанализировать полученные данные для выявления коренных причин возникновения
проблемы.
14 © Six Sigma Online . ru

15. ANALYZE
Использованные методики анализа Коренные причины возникновения проблемы
• Диаграмма Ишикавы 1. Недостаточное качество рабочих инструкций
• FMEA для операторов
• Анализ Парето 2. Отсутствие системы обучения и проверки
• Корреляционный анализ знаний операторов
• ANOVA 3. Дисциплинированность операторов
Стратегические направления проекта Влияние на метрики проекта
1. Провести совещание с операторами Рассчитать влияние каждой причины на метрики
2. Разработать и внедрить систему обучения проекта невозможно.
операторов
3. Подготовить предложения по корректировке
системы премирования операторов
4. Подготовить новую версию инструкции для
операторов
5. Создать ярлык быстрого доступа к электронной
форме обращения в "Сервис Деск" на
компьютерах всех пользователей
15 © Six Sigma Online . ru

16. ANALYZE
Диаграмма Ишикавы
На диаграмме Ишикавы более
одного раза встречаются
следующие факторы:
1. Квалификация операторов
2. Полнота и доступность
инструкций Количество обращений
3. Способ получения заявки
Им было уделено дополнительное
внимание при анализе.
Также выделены факторы,
которые не поддаются влиянию
в рамках проекта:
1. Архитектура платформы
2. Квалификация программистов
3. Ответственность операторов
Они не анализировались в
дальнейшем.
16 © Six Sigma Online . ru

17. ANALYZE
Распределение ошибок по способу получения обращения
На диаграмме Ишикавы в качестве одного из факторов, которые могут влиять на количество ошибок,
выделен Способ получения заявки. Сделано предположение о том, что при занесении обращений,
полученных по электронной почте, возникает большее количество ошибок, т.к. объем информации в таких
обращениях меньше по сравнению с телефонным звонком.
Как видно из таблицы, предположение о том, что среди заявок, полученных по электронной почте,
количество ошибок выше, не подтверждается. Это значит, что можно стимулировать более широкое
применение электронной формы обращения без ущерба для качества информации в ИС.
17 © Six Sigma Online . ru

18. ANALYZE
FMEA
Возможные последствия
Система контроля
отказа/дефекта
№ Процесс/ на
Причина/
шага/ описание Потенциальный этом на
S механизмы O D RPN
опера операции/ отказ/дефект этапе последующих для заказчика
отказа Предотвращение Обнаружение
ции требования произ этапах /потребителя
водств производства
а
Инициатор забыл
Недостаточно сообщить Инструктаж операторов Наличие незаполненных
1)неправильно
информации в ошибка необходимую о необходимости полей в форме
определенный SLA;
обращении для типа/классифик информацию, а заполнять все поля в обращения в ИС (но не
нет 2)ошибочная 7 3 9 189
правильного ации/привязки к оператор не форме ИС и уточнять страхует от неполной
информация в
заполнения всех матчевому дню уточнил все детали при информации внутри
аналитич.отчетах
полей формы в ИС дополнительно эти получении обращения полей)
Подача данные
1
обращения Инициатор сообщил
Еженедельная сплошная
ошибочную
1)неправильно проверка всех
ошибка информацию, а
В обращении определенный SLA; обращений в ИС более
типа/классифик оператору не
содержится неверная нет 2)ошибочная 7 2 Обучение операторов квалифицированным 9 126
ации/привязки к хватило
информация информация в специалистом (но не
матчевому дню квалификации ее
аналитич.отчетах дает 100% вероятности
распознать и
обнаружения)
уточнить
1)обучение операторов;
1)неправильно Практически невозможно
Полученная ошибка 2)учет в системе
определенный SLA; обнаружить, что
информация типа/классифик Невнимательность показателей для
нет 2)ошибочная 7 3 информация была 10 210
зафиксирована не ации/привязки к оператора премирования
информация в получена, но не была
полностью матчевому дню операторов количества
аналитич.отчетах внесена
Занесение ошибок в ИС
2
обращения в ИС 1)обучение операторов;
1)неправильно Практически невозможно
Полученная ошибка 2)учет в системе
определенный SLA; обнаружить, что
информация типа/классифик Невнимательность показателей для
нет 2)ошибочная 7 5 полученная информация 10 350
зафиксирована с ации/привязки к оператора премирования
информация в была внесена с
ошибками матчевому дню операторов количества
аналитич.отчетах ошибками
ошибок в ИС
Продолжение таблицы см. на следующем слайде
18 © Six Sigma Online . ru

19. ANALYZE
FMEA (продолжение)
Возможные последствия
Система контроля
отказа/дефекта
№ Процесс/ на
Причина/
шага/ описание Потенциальный этом на
S механизмы O D RPN
опера операции/ отказ/дефект этапе последующих для заказчика
отказа Предотвращение Обнаружение
ции требования произ этапах /потребителя
водств производства
а
Недостаточный Сплошная проверка всех
уровень обращений в ИС более
7 7 Обучение операторов 5 245
квалификации квалифицированным
Определение оператора специалистом
3 типа обращения Доработка инструкций
Сплошная проверка всех
1)неправильно Неоднозначная и их регулярное
обращений в ИС более
Классификация определенный 1)неправильно 7 трактовка указаний 7 дополнение на основе 5 245
квалифицированным
4 обращения SLA; определенный SLA; инструкции анализа обращений в
Тип обращения специалистом
нет 2)ошибочная 2)ошибочная ИС
определен неверно
информация в информация в 1)обучение операторов;
Привязка аналитич. аналитич.отчетах 2)учет в системе Сплошная проверка всех
обращения к отчетах Невнимательность показателей для обращений в ИС более
7 4 5 140
5 матчевому дню оператора премирования квалифицированным
операторов количества специалистом
ошибок в ИС
Сбой на шаге 1 или
7 3 см. шаги 1 и 2 см. шаги 1 и 2 5 105
2
На основе полученных значений RPN был выполнен анализ Парето причин возникновения проблемы.
19 © Six Sigma Online . ru

20. ANALYZE
Диаграмма Парето
Pareto Chart of Причина Причина/механизмы отказа:
1. Инициатор забыл сообщить необходимую
3000
информацию, а оператор не уточнил
100
дополнительно эти данные.
2500
2. Инициатор сообщил ошибочную
80 информацию, а оператору не хватило
2000 квалификации ее распознать и уточнить
3. Невнимательность оператора на стадии
Percent
60
RPN
1500 занесения заявки в ИС
4. Недостаточный уровень квалификации
40
1000 оператора
5. Неоднозначная трактовка указаний
500 20 инструкции
6. Невнимательность оператора при
0 0
принятии решения о классификации
Причина 4 5 3 6 1 2
RPN 735 735 560 420 189 126
Percent 26,6 26,6 20,3 15,2 6,8 4,6
Cum % 26,6 53,2 73,4 88,6 95,4 100,0
В соответствии с показателем RPN все причины были проранжированы на диаграмме Парето. Как видно из
диаграммы, 88,6% суммарной величины показателя RPN обеспечивают недостаточный уровень
квалификации оператора, неоднозначная трактовка инструкций и невнимательность оператора. Это
соответствует выводам по диаграмме Ишикавы.
20 © Six Sigma Online . ru

21. ANALYZE
Корреляционный анализ
Scatterplot of % ошибок vs Количество обращений Scatterplot of % ошибок 2х типов vs Количество обращений
0,9 0,8
0,8 0,7
0,7 0,6
% ошибок 2х типов
0,6
0,5
% ошибок
0,5
0,4
0,4
0,3
0,3
0,2
0,2
0,1 0,1
0,0 0,0
0 10 20 30 40 50 60 70 80 90 0 10 20 30 40 50 60 70 80 90
Количество обращений Количество обращений
Pearson correlation of Количество обращений and % ошибок = -0,137 Pearson correlation of Количество обращений and % ошибок 2х типов = -0,384
P-Value = 0,495
P-Value = 0,048
С помощью корреляционного анализа было проверено предположение о том, что количество обработанных обращений
влияет на количество допущенных операторами ошибок. Результаты анализа показали отсутствие существенной
корреляции между количеством обращений и количеством ошибок. В дальнейшем влияние этого фактора не
рассматривалось.
21 © Six Sigma Online . ru

22. ANALYZE
Дисперсионный анализ
Boxplot of C11
100,0%
80,0%
60,0%
C11
40,0%
20,0%
0,0%
1 11 12 2 4 5 6 8
ор р р ор ор ор ор ор
ат то то ат ат ат ат ат
ер ра ра ер ер ер ер ер
Оп Оп
е
Оп
е Оп Оп Оп Оп Оп
C10
С помощью инструмента ANOVA анализировался % ошибок в разрезе операторов. Анализ выполнялся без учета ошибок
привязки к матчу, т.к. эти ошибки денормализуют распределение, а инструмент предназначен только для анализа
выборок, подчиняющихся закону нормального распределения.
По итогам анализа исходная гипотеза о равенстве средних значений % ошибок по разным операторам была отвергнута -
(Р<0,05). Ящичная диаграмма хорошо показывает разницу как средних значений % ошибок, так и разницу в величине
разброса от очень существенной (оператор 11) до очень незначительной (оператор 8). Следовательно, количество
ошибок в ИС зависит от того, какой оператор вносит данные. Это соответствует факторам Дисциплина и Квалификация
на диаграмме Ишикавы.
22 © Six Sigma Online . ru

23. ANALYZE
Коренные причины возникновения проблемы
На этом этапе были выделены следующие коренные причины появления ошибок:
1. Недостаточное качество рабочих инструкций для операторов
2. Отсутствие системы обучения и проверки знаний операторов
3. Дисциплинированность операторов
Стратегические направления проекта – что дальше?
Определены следующие направления работы:
1. Провести совещание с операторами: донести результаты анализа проблемы, объяснить возможные
последствия проблемы для разных групп пользователей, ознакомить с планируемыми мероприятиями
2. Разработать и внедрить систему обучения операторов, включая мероприятия по проверке полученных
знаний
3. Подготовить предложения по корректировке системы премирования операторов
4. Подготовить новую версию инструкции для операторов
5. Создать ярлык быстрого доступа к электронной форме обращения в "Сервис Деск" на компьютерах
всех пользователей компании (для увеличения количества обращений по электронной почте)
23 © Six Sigma Online . ru

24. IMPROVE
Использованные инструменты
Основные направления работы,
определенные на предыдущем
этапе, были проранжированы с
помощью Solution Matrix. В
соответствии с итоговым
показателем значимости
решения определен порядок
реализации мероприятий с
одной поправкой: подготовка
предложений по корректировке
системы премирования
операторов будет выполнена в
последнюю очередь, несмотря
на эффективность и простоту
своей реализации, т.к.
изменения в систему мотивации
операторов могут быть внесены
не раньше середины декабря.
24 © Six Sigma Online . ru

25. IMPROVE
Дата внедрения
Первопричина Решение Результат
Ответственный
Непонимание операторами Провести совещание с 04.11.11 - первый этап После проведения совещаний
важности точного внесения операторами: описать текущую 14.11.11 - второй этап количество ошибок снизилось
данных в систему и ситуацию с качеством Руководитель проектно- до 13,5%.
правильного определения информации в ИС, показать аналитической службы
классификаторов результаты анализа стадии
Analize, рассказать, на что и как
влияет наличие ошибок в ИС,
предупредить о будущем
обучении и проверке уровня
знаний операторов, а также о
предстоящем изменении
системы мотивации с учетом
фактора количества ошибок.
Малое количество обращений, Упростить доступ к 21.11.2011 Среднее количество обращений
поступающих по электронной электронной форме - создать Руководитель проектно- через электронную форму
почте, т.к. позвонить по ярлык быстрого доступа к аналитической службы выросло с 3,2 до 19 в день, в %
телефону для многих электронной форме обращения от общего числа обращений
инициаторов проще, чем в "Сервис Деск" на рост с 3% до 22%.
заполнять электронную форму компьютерах всех
пользователей компании
Продолжение таблицы см. на следующем слайде
25 © Six Sigma Online . ru

26. IMPROVE
Дата внедрения
Первопричина Решение Результат
Ответственный
Отсутствие полной и Подготовить новую версию 25.11.11 Инструкция введена в работу,
однозначно трактуемой инструкции для операторов Руководитель проекта однако ее придется
инструкции по заполнению дорабатывать после подготовки
классификационных полей в новой версии классификатора
форме обращения в ИС обращений (это связано с
инициированным пересмотром
SLA - предельных сроков
закрытия обращения).
Нет системы обучения и Разработать и внедрить 25.11.11 Проверка знаний по итогам
проверки уровня знаний систему обучения операторов: Руководитель проекта обучения выявила большое
операторов порядок проведения обучения, расхождение между уровнем
порядок проверки уровня квалификации отдельных
знаний операторов, кейсы для операторов. Необходимо
проверки знаний дополнительное обучение 6
операторов, показавших
наихудшие результаты.
Нет рычагов стимулирования Подготовить предложения по 30.11.2011 Предложения подготовлены.
операторов выполнять свою корректировке системы Руководитель проектно- Система премирования будет
работу более качественно премирования операторов аналитической службы рассмотрена и утверждена в
(выделить показатели, декабре и вступит в действие с
влияющие на премию, 01.01.2012.
определить лимиты по каждому
показателю и веса - их влияние
на конечную сумму премии)
26 © Six Sigma Online . ru

27. IMPROVE
Дополнительные риски и сложности
1. На этом этапе команда проекта столкнулась с проблемой сопротивления персонала: некоторые из
операторов неохотно проходили обучение и принимали нововведения. В процессе участвуют операторы 2х
подразделений: Департамента ИТ и Технического департамента. Первые непосредственно подчиняются
владельцу процесса, вторые – находятся в составе другого департамента и подчиняются владельцу
процесса только в части вопросов по процессу. Двойное подчинение привело к тому, что технические
операторы чувствуют себя "отдельной вотчиной", и некоторые из них саботируют внедрение ряда
изменений.
На будущее вынесен следующий урок: стараться избегать таких ситуаций. По возможности все
исполнители процесса должны быть объединены "под крышей" одного подразделения. Если такой
возможности нет, нужно обязательно включать эти риски в план управления рисками на этапе Define.
2. Из-за неправильной расстановки приоритетов с учетом общего высокого уровня загрузки участников
проекта, недостаточной дисциплинированности участников закрытие этого этапа было просрочено на 1
неделю.
Что дальше?
На этапе Control необходимо проанализировать результаты проведенных мероприятий.
27 © Six Sigma Online . ru

28. CONTROL
Сравнительный анализ общего числа ошибок
140
До После
120
Общее число
100 ошибок
80
60 Количество
обращений
40
20
0
01.окт
03.окт
05.окт
07.окт
09.окт
11.окт
13.окт
15.окт
17.окт
19.окт
21.окт
23.окт
25.окт
27.окт
16.ноя
08.ноя
10.ноя
12.ноя
14.ноя
18.ноя
20.ноя
22.ноя
24.ноя
26.ноя
28.ноя
30.ноя
Примечание: данные для анализа "после" взяты, начиная с 7.11 (понедельник), т.к. первое мероприятие по улучшению
процесса прошло 4.11 (в пятницу).
На графике хорошо видно снижение количества ошибок после начала внедрения мероприятий на фоне
роста числа обращений в «Сервис Деск».
28 © Six Sigma Online . ru

29. CONTROL
Использованные методики анализа Передача обязанностей
Для контроля результатов проекта были Ответственным за поддержание работы и
проанализированы данные об обращениях, дальнейшее совершенствование процесса «Сервис
занесенных в ИС с 07.11.11 по 30.11.11 г. Общее Деск» является руководитель проектно-
количество обращений – 1714. аналитической службы.
Методики, которые использовались на этом этапе:
• Составление контрольных карт P Chart
• Оценка способности процесса
• Оценка показателей DPMO и ơ – уровня
процесса
Документация Возможности для будущих проектов
В ходе проекта подготовлен: До 01.01.2012г. предстоит реализовать следующие
1. План управления для процесса «Сервис Деск». мероприятия:
2. Новая версия Инструкции для операторов 1й 1. Реализация механизма привязки обращения к
линии «Сервис Деск». В документе отражены матчу инициатором.
изменения классификатора обращения, более 2. Подготовка новой версии классификатора
четко сформулированы критерии определения обращений.
типа обращения, расширено и дополнено 3. Создание базы знаний прецедентов по типу
пошаговое описание действий оператора. обращений.
Руководством поставлена задача увеличения
индекса способности процесса до 1 в ходе
следующего проекта.
29 © Six Sigma Online . ru

30. РЕЗУЛЬТАТ
Метрики проекта Соответствие поставленным целям
В результате проекта: Целью проекта было снижение среднего уровня
• Средний уровень ошибок снизился с 32,2% до количества ошибок в 3 раза, т.е. до 10%.
4,3% Полученный результат (4,3%) превзошел ожидания
• DPMO уменьшился со 107440 до 14197 и соответствует стратегическому целевому
• ơ – уровень вырос с 2,74 до 3,69 показателю не более 5% ошибок.
Сравнительный анализ Финансовые показатели
30 © Six Sigma Online . ru

31. Lessons Learned
Отчет о полученных уроках
Наиболее важные факторы, повлиявшие на достижение целей проекта:
Факторы, помешавшие достижению целей:
Применение результатов проекта
Накопленный в ходе проекта опыт будет использован для дальнейшей работы над повышением
показателя способности процесса «Сервис Деск», а также для оптимизации работы сервисных
подразделений компании.
31 © Six Sigma Online . ru