Cнижение количества ошибок в информационной системе сервис деск
0 likes1,490 views
Документ описывает проект по оптимизации работы информационной системы 'сервис деск' с целью снижения количества ошибок при обработке обращений. Ключевыми проблемами являются высокая доля ошибок классификации и привязки обращений, что влияет на качество аналитической информации и мотивацию сотрудников. Проект включает в себя анализ причин ошибок, методы оптимизации и обучение операторов для повышения качества обслуживания.
Cнижение количества ошибок в информационной системе сервис деск
- 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