6 сигм. Сокращение количества ошибок в информационной системе

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

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

DEFINE
4
Календарный план проекта

DEFINE
5
SIPOC процесса «Сервис Деск»

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

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

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

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

MEASURE
10
Распределение количества ошибок по дням
0.00
10.00
20.00
30.00
40.00
50.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
Общее количество ошибок
Среднее Отклик
0.00
10.00
20.00
30.00
40.00
50.00
60.00
70.00
80.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
Ошибки типа и классификатора
Среднее Отклик Обращения
На 1м графике четко выражены 3 пика: 2го, 19 и 23го
октября. Эти пики соответствуют матчевым дням. В
такие дни появляются ошибки привязки к матчу (в
прочие дни этот вид ошибок отсутствует), поэтому общее
число ошибок резко возрастает.
После исключения ошибок привязки к матчу (2й график)
пики сгладились, а разброс данных уменьшился.
Провалы 1го, 9го, 15го, 16го и 22го октября объясняются
выходными днями. В эти дни на стадионе работает мало
людей, соответственно резко падает число обращений в
службу «Сервис Деск». Этот вывод подтверждается и
графиком количества обращений по дням.

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

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

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

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

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

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

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

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

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

ANALYZE
20
Диаграмма Парето
В соответствии с показателем RPN все причины были проранжированы на диаграмме Парето. Как видно из
диаграммы, 88,6% суммарной величины показателя RPN обеспечивают недостаточный уровень
квалификации оператора, неоднозначная трактовка инструкций и невнимательность оператора. Это
соответствует выводам по диаграмме Ишикавы.
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
Причина 216354
3000
2500
2000
1500
1000
500
0
100
80
60
40
20
0
RPN
Percent
Pareto Chart of Причина Причина/механизмы отказа:
1. Инициатор забыл сообщить необходимую
информацию, а оператор не уточнил
дополнительно эти данные.
2. Инициатор сообщил ошибочную
информацию, а оператору не хватило
квалификации ее распознать и уточнить
3. Невнимательность оператора на стадии
занесения заявки в ИС
4. Недостаточный уровень квалификации
оператора
5. Неоднозначная трактовка указаний
инструкции
6. Невнимательность оператора при
принятии решения о классификации

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

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

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

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

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

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

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

CONTROL
28
Сравнительный анализ общего числа ошибок
0
20
40
60
80
100
120
140
1-Oct
3-Oct
5-Oct
7-Oct
9-Oct
11-Oct
13-Oct
15-Oct
17-Oct
19-Oct
21-Oct
23-Oct
25-Oct
27-Oct
8-Nov
10-Nov
12-Nov
14-Nov
16-Nov
18-Nov
20-Nov
22-Nov
24-Nov
26-Nov
28-Nov
30-Nov
Общее число
ошибок
Количество
обращений
До После
Примечание: данные для анализа "после" взяты, начиная с 7.11 (понедельник), т.к. первое мероприятие по улучшению
процесса прошло 4.11 (в пятницу).
На графике хорошо видно снижение количества ошибок после начала внедрения мероприятий на фоне
роста числа обращений в «Сервис Деск».

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

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

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

Контактные данные
Олешко Виктория
+38 050 347 76 97
oleshko.prof@gmail.com
32

6 сигм. Сокращение количества ошибок в информационной системе

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

Similar to 6 сигм. Сокращение количества ошибок в информационной системе

Similar to 6 сигм. Сокращение количества ошибок в информационной системе (20)

More from Viktoriia Oleshko

More from Viktoriia Oleshko (20)

6 сигм. Сокращение количества ошибок в информационной системе