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

Снижение количества ошибок в информационной

системе "Сервис Деск"SixSigmaOnline.ru

2011Олешко Виктория

© Six Sigma Online . ru2

Проектная команда

Лидер проекта: Олешко В.Спонсор проекта: Генеральный директор компании

Эксперты: Руководитель проектно-аналитической службыРуководители сервисных подразделений

Проектная команда: Аналитик ИС «Сервис Деск»Операторы ИС «Сервис Деск»Программисты

Пользователи: Высшее руководство компанииРуководители сервисных подразделенийИнициаторы обращенийРуководитель проектно-аналитической службыОператоры ИС «Сервис Деск»


DEFINEОпределение проблемы Цели проекта

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

Стратегическая цель: снизить количество ошибок при определении типа, классификатора обращения и привязки обращения к матчу до 5%.

Область проекта Обоснование проекта

В рамках проекта необходимо оптимизировать процесс по приему и внесению в ИС «Сервис Деск» обращений о сбоях в работе технических и информационных систем.

В рамках проекта не рассматривается правильность и своевременность закрытия обращений в ИС «Сервис Деск».

Дата начала проекта – 24.10.11 г.Плановая дата завершения проекта – 25.11.11 г.Фактическая дата завершения проекта – 01.12.11 г.

Достижение цели проекта позволит:1. Повысить качество аналитической информации, поступающей руководству компании для принятия решений.2. Повысить уровень мотивации сотрудников (операторов «Сервис Деск»).3. Накопить опыт решения проблем с качеством данных в информационных системах.


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


DEFINESIPOC процесса «Сервис Деск»


DEFINEТребования заказчика к выходам процесса

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

Анализ рисков проекта


DEFINEЧто дальше?

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


MEASUREОбщие сведения о собранных данных Актуальное состояние процесса

Из ИС «Сервис Деск» были выгружены в файл формата .xls данные об обращениях за период 01.10.11-27.10.11. Общее количество обращений за этот период – 1362. Эти данные были проанализированы на предмет наличия ошибок определения типа и классификатора обращения и привязки обращения к матчу.

Уровень ошибок: 32,2%DPMO: 107440Z Bench: -1,29

Результаты анализа измерительной системы

Дополнительные риски и сложности

Данные были валидированы путем выборочной перепроверки результатов измерений экспертом более высокого уровня квалификации.

Наибольшую сложность вызвала оценка измерительной системы. В силу специфики проекта предложенная в архиве вкладка не могла быть использована, поэтому пришлось использовать другой способ валидации. Несмотря на это, этап был завершен в плановые сроки.


MEASUREРезультаты анализа измерительной системы

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


MEASUREРаспределение количества ошибок по дням

1/10

2/10

3/10

4/10

5/10

6/10

7/10

8/10

9/10

10/1

011

/10

12/1

013

/10

14/1

015

/10

16/1

017

/10

18/1

019

/10

20/1

021

/10

22/1

023

/10

24/1

025

/10

26/1

027

/10

0.0010.0020.0030.0040.0050.00

Общее количество ошибок

Среднее Отклик

1/10

2/10

3/10

4/10

5/10

6/10

7/10

8/10

9/10

10/1

011

/10

12/1

013

/10

14/1

015

/10

16/1

017

/10

18/1

019

/10

20/1

021

/10

22/1

023

/10

24/1

025

/10

26/1

027

/10

0.0010.0020.0030.0040.0050.0060.0070.0080.00

Ошибки типа и классификатора

Среднее Отклик Обращения

На 1м графике четко выражены 3 пика: 2го, 19 и 23го октября. Эти пики соответствуют матчевым дням. В такие дни появляются ошибки привязки к матчу (в прочие дни этот вид ошибок отсутствует), поэтому общее число ошибок резко возрастает.После исключения ошибок привязки к матчу (2й график) пики сгладились, а разброс данных уменьшился. Провалы 1го, 9го, 15го, 16го и 22го октября объясняются выходными днями. В эти дни на стадионе работает мало людей, соответственно резко падает число обращений в службу «Сервис Деск». Этот вывод подтверждается и графиком количества обращений по дням.


MEASUREОпределение вида распределения

Был проведен тест на нормальность общего числа ошибок и ошибок типа и классификатора (без учета ошибок привязки к матчу). Общее число ошибок не соответствует нормальному распределению. Напротив, распределение совокупности ошибок типа и классификатора близко к нормальному.

6050403020100-10-20-30

99

9590

80706050403020

105

1

Общее число ошибок

Perc

ent

Mean 16,26StDev 13,04N 27AD 1,261P-Value <0,005

Probability Plot of Общее число ошибокNormal - 95% CI

403020100-10

99

9590

80706050403020

105

1

Ошибки типа и классификатора

Perc

ent

Mean 13,37StDev 8,015N 27AD 0,398P-Value 0,343

Probability Plot of Ошибки типа и классификатораNormal - 95% CI


MEASUREАктуальное состояние процесса

Статистический анализ процесса дал следующие результаты:

Уровень ошибок за весь рассмотренный период составил 32,2%. Поскольку данные об ошибках типа и классификатора соответствуют нормальному распределению (в отличие от общего числа ошибок), трансформация данных не выполнялась и уровень сигм рассчитывался только для этой группы данных. Уровень сигм очень низкий (1,29). В ходе проекта необходимо снизить среднее значение количества ошибок и уровень разброса.

Показатель Общее число ошибок (в день)

Ошибки типа и классификатора (в день)

Среднее значение 16,26 13,27Мода 13 13Минимальное значение 1 1Максимальное значение 52 13Стандартное отклонение

13,04 8,02

DPMO 107440 132526Z Bench - -1,29


MEASUREРасчет минимального объема выборки

На основе имеющихся данных был выполнен расчет минимального объема выборки. По результатам расчета для анализа всех 3х типов ошибок необходимо отбирать по 19 обращений в день. Исключение из анализа ошибок 3го типа (привязка к матчу) сокращает величину стандартного отклонения и, соответственно, размер выборки до 7 обращений в день.

1050-5-10

1,0

0,8

0,6

0,4

0,2

0,0

Difference

Pow

er

Alpha 0,05StDev 13,04Alternative Not =

Assumptions

19Size

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

Pow

er

Alpha 0,05StDev 8,02Alternative Not =

Assumptions

7Size

Sample

Power Curve for 1-Sample Z Test for Ошибки типа и классификатора


MEASUREДополнительные риски и сложности

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

На будущее вынесен следующий урок: если есть возможность – необходимо избегать введения классификаторов, для которых невозможно четко определить формальные критерии. Если такой возможности нет - уделить особое внимание обучению операторов; дать им возможность постоянно консультироваться с экспертом в случае спорных моментов; формировать базу знаний, где фиксировать все прецеденты - спорные случаи и принятые решения по ним. Что дальше?

Необходимо проанализировать полученные данные для выявления коренных причин возникновения проблемы.


ANALYZEИспользованные методики анализа Коренные причины возникновения

проблемы

• Диаграмма Ишикавы• FMEA• Анализ Парето• Корреляционный анализ• ANOVA

1. Недостаточное качество рабочих инструкций для операторов

2. Отсутствие системы обучения и проверки знаний операторов

3. Дисциплинированность операторов

Стратегические направления проекта Влияние на метрики проекта

1. Провести совещание с операторами2. Разработать и внедрить систему

обучения операторов 3. Подготовить предложения по

корректировке системы премирования операторов

4. Подготовить новую версию инструкции для операторов

5. Создать ярлык быстрого доступа к электронной форме обращения в "Сервис Деск" на компьютерах всех пользователей

Рассчитать влияние каждой причины на метрики проекта невозможно.


ANALYZEДиаграмма Ишикавы

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

Также выделены факторы, которые не поддаются влиянию в рамках проекта:3. Архитектура платформы4. Квалификация программистов5. Ответственность операторовОни не анализировались в дальнейшем.

Количество обращений


ANALYZEРаспределение ошибок по способу получения обращения

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

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


ANALYZEFMEA

№ шага/операции

Процесс/описание операции/

требования

Потенциальный отказ/дефект

Возможные последствия отказа/дефекта

SПричина/

механизмы отказа

O

Система контроля

D RPNна

этом этапе производст

ва

на последующи

х этапах производств

а

для заказчика

/потребителяПредотвращение Обнаружение

1 Подача обращения

Недостаточно информации в обращении для правильного заполнения всех полей формы в ИС

нет

ошибка типа/классификации/привязки к матчевому дню

1)неправильно определенный SLA;2)ошибочная информация в аналитич.отчетах

7

Инициатор забыл сообщить необходимую информацию, а оператор не уточнил дополнительно эти данные

3

Инструктаж операторов о необходимости заполнять все поля в форме ИС и уточнять все детали при получении обращения

Наличие незаполненных полей в форме обращения в ИС (но не страхует от неполной информации внутри полей)

9 189

В обращении содержится неверная информация

нет



7

Инициатор сообщил ошибочную информацию, а оператору не хватило квалификации ее распознать и уточнить

2 Обучение операторов

Еженедельная сплошная проверка всех обращений в ИС более квалифицированным специалистом (но не дает 100% вероятности обнаружения)

9 126

2Занесение обращения в ИС

Полученная информация зафиксирована не полностью

нет



7 Невнимательность оператора 3

1)обучение операторов;2)учет в системе показателей для премирования операторов количества ошибок в ИС

Практически невозможно обнаружить, что информация была получена, но не была внесена

10 210

Полученная информация зафиксирована с ошибками

нет





Практически невозможно обнаружить, что полученная информация была внесена с ошибками

10 350

Продолжение таблицы см. на следующем слайде


ANALYZEFMEA (продолжение)

На основе полученных значений RPN был выполнен анализ Парето причин возникновения проблемы.

№ шага/операции

Процесс/описание операции/

требования

Потенциальный отказ/дефект

Возможные последствия отказа/дефекта

SПричина/

механизмы отказа

O

Система контроля

D RPNна

этом этапе производст

ва

на последующи

х этапах производств

а

для заказчика

/потребителяПредотвращение Обнаружение

3

4

5

Определение типа обращения

Классификация обращения

Привязка обращения к матчевому дню

Тип обращения определен неверно нет



7Недостаточный уровень квалификации оператора

7 Обучение операторов

Сплошная проверка всех обращений в ИС более квалифицированным специалистом

5 245

7Неоднозначная трактовка указаний инструкции

7

Доработка инструкций и их регулярное дополнение на основе анализа обращений в ИС


5 245




5 140

7 Сбой на шаге 1 или 2 3 см. шаги 1 и 2 см. шаги 1 и 2 5 105


ANALYZEДиаграмма Парето

В соответствии с показателем RPN все причины были проранжированы на диаграмме Парето. Как видно из диаграммы, 88,6% суммарной величины показателя RPN обеспечивают недостаточный уровень квалификации оператора, неоднозначная трактовка инструкций и невнимательность оператора. Это соответствует выводам по диаграмме Ишикавы.

RPN 735 735 560 420 189 126Percent 26,6 26,6 20,3 15,2 6,8 4,6Cum % 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

Perc

ent

Pareto Chart of Причина Причина/механизмы отказа:1. Инициатор забыл сообщить

необходимую информацию, а оператор не уточнил дополнительно эти данные.

2. Инициатор сообщил ошибочную информацию, а оператору не хватило квалификации ее распознать и уточнить

3. Невнимательность оператора на стадии занесения заявки в ИС

4. Недостаточный уровень квалификации оператора

5. Неоднозначная трактовка указаний инструкции

6. Невнимательность оператора при принятии решения о классификации


ANALYZEКорреляционный анализ

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,137P-Value = 0,495 Pearson correlation of Количество обращений and % ошибок 2х типов = -0,384

P-Value = 0,048


ANALYZEДисперсионный анализ

Операт

ор 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Коренные причины возникновения проблемы

На этом этапе были выделены следующие коренные причины появления ошибок:1. Недостаточное качество рабочих инструкций для операторов2. Отсутствие системы обучения и проверки знаний операторов3. Дисциплинированность операторов

Стратегические направления проекта – что дальше?

Определены следующие направления работы:1. Провести совещание с операторами: донести результаты анализа проблемы, объяснить

возможные последствия проблемы для разных групп пользователей, ознакомить с планируемыми мероприятиями

2. Разработать и внедрить систему обучения операторов, включая мероприятия по проверке полученных знаний

3. Подготовить предложения по корректировке системы премирования операторов4. Подготовить новую версию инструкции для операторов5. Создать ярлык быстрого доступа к электронной форме обращения в "Сервис Деск" на

компьютерах всех пользователей компании (для увеличения количества обращений по электронной почте)


IMPROVEИспользованные инструменты

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


IMPROVEПервопричина Решение Дата внедрения

Ответственный Результат

Непонимание операторами важности точного внесения данных в систему и правильного определения классификаторов

Провести совещание с операторами: описать текущую ситуацию с качеством информации в ИС, показать результаты анализа стадии Analize, рассказать, на что и как влияет наличие ошибок в ИС, предупредить о будущем обучении и проверке уровня знаний операторов, а также о предстоящем изменении системы мотивации с учетом фактора количества ошибок.

04.11.11 - первый этап14.11.11 - второй этапРуководитель проектно-аналитической службы

После проведения совещаний количество ошибок снизилось до 13,5%.

Малое количество обращений, поступающих по электронной почте, т.к. позвонить по телефону для многих инициаторов проще, чем заполнять электронную форму

Упростить доступ к электронной форме - создать ярлык быстрого доступа к электронной форме обращения в "Сервис Деск" на компьютерах всех пользователей компании

21.11.2011Руководитель проектно-аналитической службы

Среднее количество обращений через электронную форму выросло с 3,2 до 19 в день, в % от общего числа обращений рост с 3% до 22%.Продолжение таблицы см. на следующем слайде


IMPROVEПервопричина Решение Дата внедрения

Ответственный Результат

Отсутствие полной и однозначно трактуемой инструкции по заполнению классификационных полей в форме обращения в ИС

Подготовить новую версию инструкции для операторов

25.11.11Руководитель проекта

Инструкция введена в работу, однако ее придется дорабатывать после подготовки новой версии классификатора обращений (это связано с инициированным пересмотром SLA - предельных сроков закрытия обращения).

Нет системы обучения и проверки уровня знаний операторов

Разработать и внедрить систему обучения операторов: порядок проведения обучения, порядок проверки уровня знаний операторов, кейсы для проверки знаний

25.11.11Руководитель проекта

Проверка знаний по итогам обучения выявила большое расхождение между уровнем квалификации отдельных операторов. Необходимо дополнительное обучение 6 операторов, показавших наихудшие результаты.

Нет рычагов стимулирования операторов выполнять свою работу более качественно

Подготовить предложения по корректировке системы премирования операторов (выделить показатели, влияющие на премию, определить лимиты по каждому показателю и веса - их влияние на конечную сумму премии)

30.11.2011Руководитель проектно-аналитической службы

Предложения подготовлены. Система премирования будет рассмотрена и утверждена в декабре и вступит в действие с 01.01.2012.


IMPROVEДополнительные риски и сложности

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

2. Из-за неправильной расстановки приоритетов с учетом общего высокого уровня загрузки участников проекта, недостаточной дисциплинированности участников закрытие этого этапа было просрочено на 1 неделю. Что дальше?

На этапе Control необходимо проанализировать результаты проведенных мероприятий.


CONTROLСравнительный анализ общего числа ошибок

1-O

ct3-

Oct

5-O

ct7-

Oct

9-O

ct11

-Oct

13-O

ct15

-Oct

17-O

ct19

-Oct

21-O

ct23

-Oct

25-O

ct27

-Oct

8-N

ov10

-Nov

12-N

ov14

-Nov

16-N

ov18

-Nov

20-N

ov22

-Nov

24-N

ov26

-Nov

28-N

ov30

-Nov

0

20

40

60

80

100

120

140

Общее число ошибок


До После

Примечание: данные для анализа "после" взяты, начиная с 7.11 (понедельник), т.к. первое мероприятие по улучшению процесса прошло 4.11 (в пятницу).

На графике хорошо видно снижение количества ошибок после начала внедрения мероприятий на фоне роста числа обращений в «Сервис Деск».


CONTROLИспользованные методики анализа Передача обязанностей

Для контроля результатов проекта были проанализированы данные об обращениях, занесенных в ИС с 07.11.11 по 30.11.11 г. Общее количество обращений – 1714.Методики, которые использовались на этом этапе:• Составление контрольных карт P Chart• Оценка способности процесса• Оценка показателей DPMO и ơ – уровня

процесса

Ответственным за поддержание работы и дальнейшее совершенствование процесса «Сервис Деск» является руководитель проектно-аналитической службы.

Документация Возможности для будущих проектов

В ходе проекта подготовлен:1. План управления для процесса «Сервис

Деск».2. Новая версия Инструкции для операторов

1й линии «Сервис Деск». В документе отражены изменения классификатора обращения, более четко сформулированы критерии определения типа обращения, расширено и дополнено пошаговое описание действий оператора.

До 01.01.2012г. предстоит реализовать следующие мероприятия:1. Реализация механизма привязки

обращения к матчу инициатором.2. Подготовка новой версии

классификатора обращений.3. Создание базы знаний прецедентов по

типу обращений.Руководством поставлена задача увеличения индекса способности процесса до 1 в ходе следующего проекта.


РЕЗУЛЬТАТМетрики проекта Соответствие поставленным целям

В результате проекта:• Средний уровень ошибок снизился с

32,2% до 4,3%• DPMO уменьшился со 107440 до 14197• ơ – уровень вырос с 2,74 до 3,69

Целью проекта было снижение среднего уровня количества ошибок в 3 раза, т.е. до 10%. Полученный результат (4,3%) превзошел ожидания и соответствует стратегическому целевому показателю не более 5% ошибок.

Сравнительный анализ Финансовые показатели


Lessons LearnedОтчет о полученных уроках

Наиболее важные факторы, повлиявшие на достижение целей проекта:

Факторы, помешавшие достижению целей:

Применение результатов проекта

Накопленный в ходе проекта опыт будет использован для дальнейшей работы над повышением показателя способности процесса «Сервис Деск», а также для оптимизации работы сервисных подразделений компании.


Контактные данные

Олешко Виктория

+38 050 347 76 97

[email protected]

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

Business