선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 본 프로젝트는 고객이 원하는 것이 명백하여 VOC(Voice Of Customer) 수집과 CCR(Critical Customer Requirement) 전개 등의 과정이 생략되었으며, 404 Not Found 링크 에러율 90% 절감을 목표로 수립하였다.
- 본 프로젝트는 내부적으로는 A사의 대표이사의 지시사항과, 현행 관리지표인 열람 페이지 수 (PV : Page View), 순방문자수 (UV : Unique Visit) 에 새롭게 기사 링크에러율이 추가 관리 대상으로 선정되었고, 외부적으로는 인터넷 사용자의 불만 해결과 관련 이해 관계자들의 요구사항 반영, 외부 고객 만족을 통한 Site 고객 충성도 극대화를 위해 선정되었다.
- 이에 본 연구에서는 서비스 산업 중 우리가 매일 접하여 뉴스 기사를 볼 수 있는 인터넷 미디어 포털업체의 6시그마 추진 프로젝트 사례를 검토하여 실제 실행과정을 소개하며, 이 연구를 통하여 발견된 문제점과 해결방안의 관련 업종의 활용과 6시그마 적용 가능성을 기대할 수 있을 것이다.
- CTQ(Y1)은 PV대비 404 Not Found 발생율, CTQ(Y2)는 404 Not Found Error 발생시 장애 조치 시간이다. 즉, 고객이 Page를 방문하는 건수와 비례하여 문제의 발생빈도를 측정하고 문제 발생 시 이를 얼마나 빨리 정상 상태로 조치하기 위한 능력을 측정하는 것이다. 각 각의 현 수준 측정은 Define 단계에서 정한 3개의 Main site 별로 측정키로 하였다.
제안 방법
- 1시간 단위로 임계치 (10회) 이상 발생한 건에 대해 담당자에게 메일 발송토록 하였다. 임계치는 팀 미팅을 통해 우선 10회로 결정하였으며 매체 별 관계자의 의견을 수렴하여 탄력적으로 적용토록 하였다.
- CTQ 인 404 Not Found Error 를 객관적으로 측정하기 위한 지표인 CTQ(Y) 로 변환키 위하여 우선 잠재적인 CTQ(Y) 후보를 도출하였다. 방문 유형, 측정 기준, 방문 경로, 방문자 기준으로 모든 가능한 후보를 도출 하였으며, CTQ 와의 연관성, 유효성, 논리성, 측정 가능성, 연속형 자료 표현 가능성, 자료 수집 용이성의 기준으로 X-Y Matrix 방법을 이용하여 2개의 CTQ(Y)를 선정하였다.
- CTQ(Y)에 영향을 주는 잠재원인변수를 특성요인도, Logic Tree 방법을 통하여 관련되는 내부 전문가들이 모여서 도출하였다. 이를 내부요인과 외부요인, 모니터링 방법, 업무 수행자 관점으로 정리 하였으며, 이의 확인과 추가 잠재 원인변수 도출을 위하여 층별 분석을 실시하였다.
- Data 수집을 위하여 웹 서버에 자바 스크립트를 추가하여 Referer (해당 기사를 부른 Site 주소) 및 Error 발생 URL을 DB에 저장하였으며, 이러한 Process 의 신뢰성을 확인하여 측정 시스템 분석을 대신하였다.
- Measure 단계 진행 중에 3가지의 Quick fix 사항을 확인하고 즉시 개선하였다. 하나는 각 매체별로 404 Not found 장애 발생 시 사용자의 불만을 감소시키기 위해 안내 페이지를 보여줌과 동시에 1초후 각 매체별 홈페이지로 리다이렉션 되도록 하는 것이다.
- S2를 구체화하기 위하여 다시 몇 개의 세부 개선안을 도출, 적용하였다. 우선, 매체별 404 Not Found 발생현황을 모니터링 할 수 있는 웹 페이지를 [그림3]과 같이 개발 하였다.
- 즉, 고객이 Page를 방문하는 건수와 비례하여 문제의 발생빈도를 측정하고 문제 발생 시 이를 얼마나 빨리 정상 상태로 조치하기 위한 능력을 측정하는 것이다. 각 각의 현 수준 측정은 Define 단계에서 정한 3개의 Main site 별로 측정키로 하였다.
- 각 잠재핵심원인변수의 핵심원인변수 여부의 확인을 위해 가설검정 및 정성적 분석계획을 수립하였다.
- 개선안의 지속적인 적용을 위하여 모니터링 툴 사용 방법 실습교육을 웹 사이트 운영자에게 실시하였고, 모니터링 툴 사용자에게 개발 및 사용 방법 공유하였다.
- 고객의 핵심 요구사항인 CTQ(Critical to Quality) 선정을 위하여 기사 링크 에러의 종류별 Data 를 수집하였으며, 이중 제일 빈도가 많은 404 Not Found Error 를 CTQ로 선정 하였다.
- 그 결과 외부 유입에 의해 404 Not Found가 발생한 파일에 대해서 검색 서비스로 Redirect (S1), 모니터링 페이지 및 자동 경고(Email, SMS) 시스템 구축(S2) 를 우선 적용 개선안으로 선정하였다.
- 하나는 각 매체별로 404 Not found 장애 발생 시 사용자의 불만을 감소시키기 위해 안내 페이지를 보여줌과 동시에 1초후 각 매체별 홈페이지로 리다이렉션 되도록 하는 것이다. 다른 하나는 매체별 404 Not found 발생 현황을 모니터링 할 수 있는 웹페이지를 개발하여 적용하였다. 마지막으로 각 매체별 담당자를 선정하여 404 Not found 장애가 많이 발생하는 파일에 대하여는 즉각적인 수정이 될 수 있도록 유도하였다.
- 임계치는 팀 미팅을 통해 우선 10회로 결정하였으며 매체 별 관계자의 의견을 수렴하여 탄력적으로 적용토록 하였다. 또, 1일 1,000회 이상 발생 건에 대해 매체 별 담당자에게 SMS 문자 발송 조치토록 하였다.
- 또, Referer 페이지에서 링크오류가 발생한 부분 스캔 Tool 개발하여 발생 빈도가 높은 건 Referer를 확인가능케 하고, Referer 페이지의 기사 링크 상태 체크가 항상 가능토록 [그림4]와 같이 개발 하였다. 이를 통하여 일자별 발생현황을 그래프로 표시하여 발생추이를 쉽게 알 수 있도록 하였으며, 매체 별 1일 발생 임계치를 설정하여 임계치 초과시 SMS 또는 Email 로 통보 받을 수 있는 시스템을 개발, 조치 하였다.
- 또한 개선안 적용이 지속적으로 되는가를 확인하기 위한 공정 관리 계획서를 작성하였고, 이상 상태 판단 기준과 그에 따른 조치계획을 수립하였다. 모니터링 페이지 이상 유무은 월별로 http://jasmine.
- 또한 개선안 적용이 지속적으로 되는가를 확인하기 위한 공정 관리 계획서를 작성하였고, 이상 상태 판단 기준과 그에 따른 조치계획을 수립하였다. 모니터링 페이지 이상 유무은 월별로 http://jasmine.joins.com/404NotFound/Daily_Media_404NotFound.asp 에서 페이지 매체 별 404 Not Found 발생 현황 확인토록 하였으며, 데이터 수집 이상 유무은 주별로 Database에 데이터가 정상적으로 Insert 되는지 확인토록 하였으며, Referer 링크 에러 스케닝 툴은 매월 특정 Referer 스케닝 결과 이상 여부 체크토록 하였으며, Email / SMS 발송 상태은 매주 임계치 이상 발생 건에 대해 Email 및 SMS 발송상태를 점검하여 결과 확인토록 하였다 .프로젝트 종료 후 1년간 실시되는 사후관리에 대비하여 Monitoring plan을 작성하였으며, 웹 프로그램 개발 자료, 프로그램 개발 시 작성된 문서 및 소스 파일을 문서화하였다.
- 분석단계에서 찾아낸 핵심원인변수(Vital Few X's)별로 먼저 개선의 방향을 수립하였다.
- 홈페이지 개편 시 운영자 실수를 예방할 수 있게 기사 관리 툴 수정하고, 미리 보기, 수작업 영역 자동 생성토록 하였다. 외부 유입에 의한 기사 링크 에러를 분석하여 동일한 건이 일정 횟수 이상 발생할 경우 업체에 통보하도록 하였다.
- 운영자의 실수(x1)는 “기사 생성시 운영자의 잘못된 URL 링크는 404 Not Found 발생빈도에 영향을 준다”는 가설로 변환하였고, 평상시 발생빈도의 평균값 대비 운영자 실수에 의한 404 Not Found 발생시 빈도의 평균값 비교 (2sample t test), 운영자 실수에 의한 기사 링크 오류 사례 수집, 운영자 유발할 수 있는 가능성이 높은 프로세스를 기능전개형 Process map으로 분석하였다.
- CTQ(Y)에 영향을 주는 잠재원인변수를 특성요인도, Logic Tree 방법을 통하여 관련되는 내부 전문가들이 모여서 도출하였다. 이를 내부요인과 외부요인, 모니터링 방법, 업무 수행자 관점으로 정리 하였으며, 이의 확인과 추가 잠재 원인변수 도출을 위하여 층별 분석을 실시하였다.
- 또, Referer 페이지에서 링크오류가 발생한 부분 스캔 Tool 개발하여 발생 빈도가 높은 건 Referer를 확인가능케 하고, Referer 페이지의 기사 링크 상태 체크가 항상 가능토록 [그림4]와 같이 개발 하였다. 이를 통하여 일자별 발생현황을 그래프로 표시하여 발생추이를 쉽게 알 수 있도록 하였으며, 매체 별 1일 발생 임계치를 설정하여 임계치 초과시 SMS 또는 Email 로 통보 받을 수 있는 시스템을 개발, 조치 하였다.
- 1시그마 수준이다. 이에 개선의 목표도 CTQ(Y1) 과 같은 불량율 90% 절감으로 정해 A 매체는 불량률 4.3%로 3.2시그마, B 매체는 불량률 4.6%로 3.2 시그마, C매체는 불량률 2.7%로 3.4시그마 수준으로 정하였다.
- 6시그마 수준이다. 이에 개선의 목표를 불량율 90% 절감으로 정해 A 매체는 불량률 0.01%로 5.7시그마, B 매체는 불량률 0.38%로 4.2 시그마, C매체는 불량률 0.01%로 5.7시그마 수준으로 정하였다.
- 일반적인 6시그마 프로젝트의 추진 절차는 프로젝트의 성격에 따라서 DMAIC-정의(Define), 측정(Measure), 분석(Analyze), 개선(Improve), 관리(Control), DFSS (Design For Six Sigma) 로 구분되어 추진될 수 있으나 본 사례는 DMAIC 단계로 추진되었다.
- 1시간 단위로 임계치 (10회) 이상 발생한 건에 대해 담당자에게 메일 발송토록 하였다. 임계치는 팀 미팅을 통해 우선 10회로 결정하였으며 매체 별 관계자의 의견을 수렴하여 탄력적으로 적용토록 하였다. 또, 1일 1,000회 이상 발생 건에 대해 매체 별 담당자에게 SMS 문자 발송 조치토록 하였다.
- 잠재원인변수 중 핵심원인변수(Vital Few x's) 임이 의심되는 잠재핵심원인변수를 도출하기 위해 6명의 전문가가 모여 Multi-Voting 방식으로 3개의 원인변수를 도출하였다.
- 적용되어진 개선안에 대하여 개선안의 유효성과 개선성과 목표 달성여부를 파악키 위하여 Piolt Test 를 1주일간 실시 하였다. 그 결과 CTQ(Y1)의 시그마 수준은 A매체의 경우 4.
- 적용된 개선안의 지속적인 유지, 관리에 위협이 되는 Risk Factor를 파악하기 위해 FMEA 방법을 통하여 RPN이 높은 Risk 를 파악하였고, Email / SMS 발송 서버 상태 체크, 스케줄러 동작 여부 체크, 메일 수신 서버 상태 체크에 대한 조치 계획을 수립하였다.
- asp 에서 페이지 매체 별 404 Not Found 발생 현황 확인토록 하였으며, 데이터 수집 이상 유무은 주별로 Database에 데이터가 정상적으로 Insert 되는지 확인토록 하였으며, Referer 링크 에러 스케닝 툴은 매월 특정 Referer 스케닝 결과 이상 여부 체크토록 하였으며, Email / SMS 발송 상태은 매주 임계치 이상 발생 건에 대해 Email 및 SMS 발송상태를 점검하여 결과 확인토록 하였다 .프로젝트 종료 후 1년간 실시되는 사후관리에 대비하여 Monitoring plan을 작성하였으며, 웹 프로그램 개발 자료, 프로그램 개발 시 작성된 문서 및 소스 파일을 문서화하였다.
- 그러나 목표 달성에는 부족하여 그에 대한 대책 및 향후 계획을 수립하였다. 홈페이지 개편 시 운영자 실수를 예방할 수 있게 기사 관리 툴 수정하고, 미리 보기, 수작업 영역 자동 생성토록 하였다. 외부 유입에 의한 기사 링크 에러를 분석하여 동일한 건이 일정 횟수 이상 발생할 경우 업체에 통보하도록 하였다.
대상 데이터
- A 인터넷 미디어 포털 회사는 국내 미디어 업체 중 유일하게 2002년부터 6시그마를 도입, 지속적으로 추진 중에 있다. 본 사례는 그동안 수행되어 온 6시그마 프로젝트중의 하나이며 추진기간은 2007년도 상반기이다.
- 본 회사는 미디어 포털 사이트로, 일간지, 주간지, 월간지 등의 여러 서비스가 존재하나 그중 가장 대표가 되는 일간지 2개와 종합 월간지 1개를 프로젝트 범위로 선정하였고, 각 서비스 별로 1일 평균 순방문자수 (UV)와 일일 Update 되는 링크 Tag 수를 조사하여 3개의 웹서비스의 Main Page를 프로젝트 범위로 최종 선정하였다.
- 404 Not found 발생여부 인지 여부(x3)는 Window Analysis 방법을 이용하여 과거의 Process 상태 분석과 설문조사를 실시하였다. 설문조사 대상은 운영자 및 개발자 10명이며, 실무경력이 풍부한 과장급이상을 선정하였다. 설문분석 결과 이들 모두 404 Not Found 발생 현황을 모르고 있었으며 404 Not Found가 발생하더라도 아무런 조치를 하지 못하고 있었다.
- CTQ(Y2)의 운용정의는 404 Not Found 조치일과 404 Not Found 발생일과의 차이이다. 연속형 Data 이며, 망소항목의 특성을 가지고 있으며, 규격 상한은 관련자와의 협의 결과 60 분으로 설정 하였다.
데이터처리
- CTQ(Y1)에 대하여 매체별 일별 발생빈도의 평균값 차이 비교 (분산분석), Article을 호출하는 Referer의 내, 외부 여부에 따른 발생빈도의 평균값 차이 비교 (2 Sample t test), 매체별 Referer의 내, 외부 평균값 차이 비교 (2 Sample t test), 외부 유입 Referer의 빈도분석 (Pareto Chart), CTq(Y2)인 장애 처리 사간의 매체별 평균 시간 차이 분석 (등분산 검정, 분산분석)을 실시하였다.
- 검증의 효과를 높이기 위해 Quick Fix 처리 후의 Data를 측정하였으며, Referer 가 내부인 평상시의 평균값과 운영자 실수에 의한 잘못된 URL 링크가 발생한 날짜의 평균값을 비교한 결과 기사 생성시 운영자 실수에 의한 잘못된 URL 링크는 404 Not Found 발생빈도에 영향을 준다 (p-value = 0.041, α = 0.05).
- 수집된 Data의 분석을 위하여 “한글 Minitab 14.0” Software 를 이용 하였으며, 각 매체별 CTQ(Y1), CTQ(Y2)에 대하여 그래프 분석과 기술 통계 분석을 실시 하였고, 안정성 평가를 위해 CTQ(Y1)은 불량률 관리도, CTQ(Y2)는 개별 값 관리도를 작성하였다.
- 외부에서 잘못된 URL의 호출(x2)은 층별분석 결과를 토대로 내부/외부 발생빈도의 평균값 비교( 2sample t test)를 실시하였고, 총 31일간의 매체 합산 data를 사용하였다. 분석 결과 내부에서의 발생 빈도 평균값은 555이며 외부 유입에 따른 발생 빈도 평균값은 1,168이 크다 (p-value = 0.
이론/모형
- 404 Not found 발생여부 인지 여부(x3)는 Window Analysis 방법을 이용하여 과거의 Process 상태 분석과 설문조사를 실시하였다. 설문조사 대상은 운영자 및 개발자 10명이며, 실무경력이 풍부한 과장급이상을 선정하였다.
- 개선방향에 따른 창의적 Idea 도출을 위하여 Brainstorming 방법을 이용하였고, CDAM (Combine, Delete, Add, Modify) 방법론으로 Ideas를 확장, 정리하여 7개의 개선안을 선정하였다.
- 개선안 추진에 대한 우선 순위 결정을 위하여 조직적합성(경영진 지원여부, 관련 팀의 반발여부, 조직내 운영시스템과의 상충여부)과 장애요소(회사전략과 배치여부, 소요예산의 양, 개선안간의 상충성)를 가지고 Matrix 평가 방법을 이용 하였다.
- CTQ 인 404 Not Found Error 를 객관적으로 측정하기 위한 지표인 CTQ(Y) 로 변환키 위하여 우선 잠재적인 CTQ(Y) 후보를 도출하였다. 방문 유형, 측정 기준, 방문 경로, 방문자 기준으로 모든 가능한 후보를 도출 하였으며, CTQ 와의 연관성, 유효성, 논리성, 측정 가능성, 연속형 자료 표현 가능성, 자료 수집 용이성의 기준으로 X-Y Matrix 방법을 이용하여 2개의 CTQ(Y)를 선정하였다.
성능/효과
- 2 로 향상되었다. CTQ(Y2)의 시그마 수준은 A매체의 경우 1.8에서 2.7로, B매체의 경우 1.6에서 2.6로, C매체의 경우 2.1에서 2.4 로 향상되었다. 그러나 목표 달성에는 부족하여 그에 대한 대책 및 향후 계획을 수립하였다.
- 적용되어진 개선안에 대하여 개선안의 유효성과 개선성과 목표 달성여부를 파악키 위하여 Piolt Test 를 1주일간 실시 하였다. 그 결과 CTQ(Y1)의 시그마 수준은 A매체의 경우 4.5에서 4.9로, B매체의 경우 3.3에서 4.3로, C매체의 경우 4.6에서 5.2 로 향상되었다. CTQ(Y2)의 시그마 수준은 A매체의 경우 1.
- 05). 또, 기능 전개형 Process Map을 작성하여 수작업입력부분은 기사 등록 시 수작업 입력 부분에서 운영자 실수에 의한 404 Not Found 발생 위험성 존재하며, 미리 보기를 할 경우 예방 가능한 부분임을 확인 하였고, 수작업 영역 수정 Process에서는 취재 기자가 기존에 등록된 기사를 삭제 요청할 경우 운영자가 기사 삭제 후 수작업 영역 수정작업을 누락할 경우 404 Not Found 발생 위험성 존재함을 확인 하였다.
- 05). 또, 외부 유입 URL 현황을 Pareto 차트로 분석한 결과 Referer가 Null, Naver, Nate, Egloos, Daum이 상위 84%를 점유하고 있으며 이 부분에 개선의 초점을 맞춰야 함을 확인하였다. 보다 더 구체적인 원인을 도출하였다.
- 다른 하나는 매체별 404 Not found 발생 현황을 모니터링 할 수 있는 웹페이지를 개발하여 적용하였다. 마지막으로 각 매체별 담당자를 선정하여 404 Not found 장애가 많이 발생하는 파일에 대하여는 즉각적인 수정이 될 수 있도록 유도하였다.
- 우선, 매체별 404 Not Found 발생현황을 모니터링 할 수 있는 웹 페이지를 [그림3]과 같이 개발 하였다. 매체별 특정 일자의 404 Not Found 발생 현황 조회가 가능 하고, 매체 별 당일 404 Not Found 발생 현황 조회 및 발생현황을 그래프를 통한 Visual적으로 확인 가능하며, 404 에러 파일 별 발생횟수를 내림차순으로 보여주고 있다. 또, Referer 보기 버턴을 만들어 클릭 시 해당 404 에러 파일을 유발시키는 Referer 정보를 보여 준다.
- 본 사례는 다양한 서비스 업종 중 정보습득의 채널로 사용되고 있는 인터넷 미디어 포털 업체의 6시그마 프로젝트 사례를 보여주고 있으며, 생산 현장이 아닌 인터넷 산업의 문제도, Process 를 통해 업무가 이루어진다면, 전통적인 6시그마 문제해결 방법론인 DMAIC를 통해 문제해결이 가능함을 확인 할 수 있었으며, 또한 문제가 측정이 됨과 동시에 개선이 되기 시작 하였으며, 측정 될 수 있는 모든 것은 개선 될 수 있음을 확인시켜 주었다. 일반적으로 서비스 기업에서의 6시그마 프로젝트는 비정형화된 프로세스와 Data 수집의 어려움 등의 서비스업의 특징으로 인해 통계적 분석의 적용이 어렵다는 단점이 있다.
- 본 프로젝트 추진 성과로는 웹 페이지 1회 노출 시 책정되는 광고 단가를 산정하여 추정하여 계산하니, 1년 기준으로 약 1억 5천 5백만원의 광고 손실 비용 절감 효과를 가져왔으며, 고객의 만족도 향상과 이에 따른 웹 사이트에 대한 신뢰도 및 충성도가 향상 되었다.
- 분석 결과 CTQ(Y1)은 매체별 1일 평균 404 Not Found 발생빈도는 다르며, Referer는 내부가 외부에 비해 높게 발생하며, A매체는 외부가, B매체는 내부가, C매체는 내외부가 동일하다는 분석 결과를 보이고 있다.
- 분석 결과 내부에서의 발생 빈도 평균값은 555이며 외부 유입에 따른 발생 빈도 평균값은 1,168이 크다 (p-value = 0.004, α = 0.05).
- 선정된 개선안의 유효성 평가를 실시한 결과 S1은 외부 유입에 따른 404 Not Found 발생 (x2) 에 강한 영항을, S2는 Vital few x's 모두와 강한 상관관계를 나타내고 있음을 알 수 있다.
- 선정된 핵심원인변수가 CTQ(Y) 에 미치는 결과를 확인해 본 결과, 운영자의 실수(x1)와 외부 유입에 따른 404 Not Found 발생(x2) 은 CTQ(Y1)인 발생빈도에 강한 영향을 주며, 404 Not Found 인지도(x3)는 장애처리시간인 CTQ(Y2-) 에 강한 영향을 주고 있다.
- 설문조사 대상은 운영자 및 개발자 10명이며, 실무경력이 풍부한 과장급이상을 선정하였다. 설문분석 결과 이들 모두 404 Not Found 발생 현황을 모르고 있었으며 404 Not Found가 발생하더라도 아무런 조치를 하지 못하고 있었다. 404 Not Found 에러를 사전에 예방할 수 있는 기사 생성 프로세스 구축 및 404 Not Found 발생 현황을 모니터링 할 수 있는 툴이 필요하다고 공감하고 있으며, 404 Not Found 에러 발견 시 최대 1시간 이내에 처리하는 것 좋다고 응답하였다.
- 위의 분석결과를 종합하여 기사 생성시 운영자 실수에 의한 잘못된 URL 링크(x1), 외부에서 잘못된 URL 링크(x2), 404 Not Found 발생여부를 모름(x3) 이 CTQ(Y) 에 영향을 미치는 핵심원인변수(Vital Few X's)로 채택되었다.
- 이러한 층별 분석의 결과를 바탕으로 B매체의 기사 삭제 후 수작업 편집 영역 수정 작업을 수행하지 않음에 따른 404 Not Found 발생 건에 대해서 콘텐트 운영팀 및 개발자에게 통보하는 개선 사항을 Quick Fix 로 진행하였고 이를 통하여 개선전 한달간 92,118건의 발생건수가 개선 후 한 달간 5건으로 축소되는 효과를 보였다.
- 현 수준 측정결과 CTQ(Y2)의 A 매체는 불량률 43.16%로 1.0시그마, B 매체는 불량률 45.86%로 1.6 시그마, C 매체는 불량률 26.99%로 2.1시그마 수준이다. 이에 개선의 목표도 CTQ(Y1) 과 같은 불량율 90% 절감으로 정해 A 매체는 불량률 4.
후속연구
- 일반적으로 서비스 기업에서의 6시그마 프로젝트는 비정형화된 프로세스와 Data 수집의 어려움 등의 서비스업의 특징으로 인해 통계적 분석의 적용이 어렵다는 단점이 있다. 그러나, 본 사례는 DMAIC 진행 중 발견되는 이상 원인들에 대하여 원인이 파악되고 이의 재발방지가 가능하면 즉시 Quick fix 를 진행하였고, 가능한 우연원인들 만으로 분석(Analyze) 와 개선(Improve) 단계가 이루어졌다는 점과 다양한 층별분석을 통하여 통계적인 유의성을 확인후 이에 대한 세부 원인을 파악하였다는 점이 잘된 점이며, 다만 Historical 한 Data 를 이용한 통계적 분석만이 이루어 진 점이 아쉬움으로 남는다.
- 본 사례는 동종 업체, Longtail 전략을 추구하는 Internet 서비스 업종, 과거의 많은 자료를 Server 보관하며 이를 서비스하는 유형의 업종 (전자 도서관, 학술DB 등), 지식 경영과 관련하여 추진 중인 일반업체 등의 확산 적용 시 도움이 될 것으로 생각한다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.