린 6시그마와 프로세스 마이닝의 결합

Combining Lean Six Sigma and Process Mining

 

 

린 6 시그마 (Lean Six Sigma)는 고객 만족, 비용 절감, 품질 향상, 공정 속도 향상 등을 신속하게 개선하여 기업의 가치를 극대화하는 방법론입니다. Toyota, Motorola, GE(General Eletric)와 같은 제조 회사에서 처음 도입된 이후 현재까지 전세계 많은 기업에 활발히 적용되고 있습니다.[1]

6시그마의 전형적인 방법론인 DMAIC(Define, Measure, Analyze, Improve, Control)은 다음과 같은 여러 단계로 구분됩니다.[2] 이러한 DMAIC 접근 방식은 디지털 시대에도 여전히 유효합니다. 그러나 조직 내에 점점 더 많은 데이터가 수집됨에 따라 새로운 데이터 과학 기술이 린 6 시그마 영역에 도입되었습니다. 이는 린 6시그마 실무자에게 근본 원인을 신속하게 찾을 수 있는 새로운 관점과 도구를 제공합니다. 

프로세스 마이닝은 DMAIC의 다양한 단계에 가치 흐름 (Value Stream)의 실제 복잡성을 분석하기 위한 훌륭한 추가 기술 중 하나입니다. VSM(Vaule Stream Mapping)은 프로세스를 이해하고 개선 기회를 식별할 수 있는 훌륭한 린(Lean) 도구입니다.[3] 그러나 이 접근 방식의 단점은 시간이 많이 걸린다는 것입니다. 현재 상황을 이해하는데 필요한 모든 정보를 도출하기 위해서는 많은 노력이 필요합니다. 일반적으로 이해 관계자와 연계된 가치 흐름을 만드는데 최소 반나절이 걸립니다. 또 다른 문제는 매핑에 관련된 사람들의 지식에 크게 의존하기 때문에 주관적일 수 밖에 없다는 것입니다. 프로젝트 참가자들은 종종 프로세스에 대한 자신만의 견해를 갖고 자신의 의제(agendas)를 표현합니다. 또한 모든 프로세스 변형(variations)과 복잡성을 포착할 수 없기 때문에 실제 현실을 얼마나 잘 반영했는지 논쟁할 수 있습니다. 

본 아티클 시리즈는 대출 프로세스 사례를 기반으로 DMAIC 방법론에 따라 프로세스 마이닝을 적용하는 방법을 보여줍니다. 프로세스 마이닝 사용 이점과 린 6 시그마 실무자 관점에서의 한계를 설명합니다. 

 

 

 

Part 1. 정의 (Define) 단계 

 

 

위의 글 내용에서는 시리즈에 있는 모든 기사의 개요를 볼 수 있습니다.

 

디지털화가 대출 과정에 미치는 영향을 해결하기 위해 대출 제공업체의 이사와 협력하고 있다고 상상해보십시오. 금리 하락으로 대출상품의 마진 압력이 커지고 있고, 이들 대출의 수익률을 장기적으로 보장할 수 없어 주주들의 자금 조달에 한계가 있습니다. 최소 10%이상 포트폴리오를 성장시켜 더 낮은 금리로 동일한 투자수익률을 달성하겠다는 것이 이사의 전략입니다. 또한 단기적으로 경쟁력을 유지하려면 2년 이내에 비용을 30% 절감해야 합니다.

 

고객 연락 담당자와 신용 담당자 모두를 만납니다. 여러분은 그들이 압박을 받고 있음을 즉시 느낄 수 있습니다. 그들은 지금이 또 다른 프로젝트를 수행하기에 적절한 시기인지 논쟁합니다. 여러분은 그들의 약속 없이는 프로젝트가 시작조차 되지 않는다는 것을 알고 있습니다. 직원들에게 더 이상의 부담을 주지 않으면서 그들의 관심을 끌 수 있는 접근 방식을 취해야 합니다. 따라서 각 대출을 처리하는 주요 대출 신청 시스템의 데이터를 요청합니다. 며칠 후 아래 그림과 같이 지난 해의 모든 대출 신청 프로세스의 트랜잭션이 포함된 데이터 셋을 얻을 수 있습니다 (<그림1> 참고)

 

 

 

<그림 1> 대출 신청 시스템의 트랜잭션 예시 데이터

 

데이터는 다음과 같은 정보를 포함하고 있습니다. 

• Application ID: 대출 신청서 번호
• Status: 프로세스 수행 단계 이름
• Timestamp: 프로세스 수행 단계 시점
• Resource: 프로세스 단계를 수행한 사람(익명화 처리함)
• Department: 프로세스 단계를 수행한 사람의 소속 부서
• Amount: 대출 신청 금액
• Product: 대출 상품 종류(ex. 신용 or 개인 대출)

 

데이터의 의미를 파악하기 위해 몇 가지 통계 정보를 빠르게 확인할 수 있습니다. 예를 들어, Excel이나 Minitab을 활용하여 다음과 같은 결과를 얻을 수 있습니다.

• 매달 평균 5,099건의 대출 신청이 접수되고, 이 중 22%가 대출로 전환됨
• 각 액티비티(프로세스 수행 단계)들의 수행횟수를 확인할 수 있음
• 온라인 대출 신청에서 지급까지 평균 15일 소요됨

 

그러나, 여러분은 여전히 프로세스가 어떻게 수행되었는지 이해할 수 있는 어떤 맥락을 놓치고 있습니다. 따라서 프로세스에 대한 더 깊은 통찰력이 필요합니다.

 

프로세스 이해하기

 

VSM(Value Stream Mapping)은 프로세스를 더 잘 이해하기 위한 좋은 작업 단계일 수 있습니다. 그러나, 해당 작업은 도메인 전문가의 참여가 필요합니다.  프로세스를 매핑하는데 최소한 반나절의 워크샵이 필요하고 나머지 반나절은 불필요한 업무 단계(waste)를 식별하는데 투자해야 합니다. 따라서 다른 접근 방식을 취해야 합니다. 프로세스 마이닝을 사용하면 빠르고 정확하게 프로세스를 시각화하고 이해할 수 있습니다.

대출 신청 시스템의 트랜잭션 데이터는 프로세스 마이닝을 위한 최소 요건을 충족하고 있습니다. 따라서 여러분은 해당 데이터 셋을 (별다른 처리 없이도) 프로세스 마이닝 도구인 Disco로 가져올 수 있습니다.

데이터 가져오기(import) 단계에서 'Application ID' 열은 Case ID, 'Status' 열은 Activity, 'Timestamp'열은 Timestamp로 지정하며, 다른 모든 필드는 Resource 및 Other 속성으로 설정합니다 (<그림 2> 참고).

 

 

 

<그림 2> 대출 신청 시스템의 트랜잭션 데이터를 프로세스 마이닝 도구인 Disco로 가져오기

 

[Start import] 버튼을 클릭하면, Disco는 데이터를 기반으로 프로세스 모델을 자동으로 도출해 실제 프로세스가 어떻게 수행되었는지 가시화합니다 (<그림 3> 참고).

 

 

<그림 3> Disco로부터 자동으로 도출된 프로세스 맵

 

도출된 프로세스 맵에서 16,846명의 고객이 온라인으로 대출 신청을 하고 (<그림3>의 1a 참고), 3,886명의 고객이 콜센터에 직접 전화를 걸어 신청하는 것을 선호한다는 것을 알 수 있습니다 (<그림3>의 1b 참고). 또한 자동 사전승인 신용검사에서 7,036명의 고객이 온라인에서 거부되었음을 확인할 수 있습니다 (<그림3>의 2 참고).

자동으로 거부되지 않은 나머지 대출 신청에 대해 고객은 개인적인 관계를 수립하기 위해 다시 전화를 받습니다. 전화를 통해 신청한 대출이 소득에 맞는지 확인합니다. 대출 제안(Offer Package)이 우편으로 고객에게 발송됩니다 (<그림3>의 3 참고). 그런 다음, 고객은 은행 거래 명세서, 손익계산서 등과 같은 필수 정보를 제공하고, 반환 봉투를 이용해 서명한 계약서 사본을 반환해야 합니다 (<그림3>의 4 참고).

대출심사자(underwriter)는 신청이 완료되었는지 확인하고 대출 신청을 승인하거나 거절합니다 (<그림3>의 5a, 5b 참고). 필요한 경우, 추가 정보를 요청할 수도 있습니다 (<그림3>의 6,7 참고). 고객이 제안을 수락하지 않으면 신청은 취소됩니다 (그림3>의 8 참고).

기존 VSM 접근 방식에 비해 프로세스 마이닝의 한 가지 장점은 프로세스 맵을 수동으로 생성할 필요가 없다는 것입니다. 프로세스 맵은 데이터를 기반으로 프로세스 마이닝 도구에 의해 자동으로 생성됩니다. 그러나 여러분이 이러한 시각화 맵으로부터 결론을 도출하기 전, 관찰한 내용을 설명하는 프로세스를 정확히 이해하고 있어야 합니다. 

일부 도메인 지식이 부족하여 전문가에게 조언을 구하고 싶거나 지금까지 발견한 통찰력을 담당자와 만나 공유하고 싶을 때, 여러분은 그들에게 프로세스 맵 애니메이션을 보여주며 설명할 수 있습니다 (<그림4> 참고). 애니메이션은 노란색 토큰들이 데이터의 실제 타임스탬프에 기반해서 프로세스를 따라 시각적으로 각 케이스가 (대출 신청서) 이동하는 것처럼 보여줍니다. 

 

 

<그림 4> 애니메이션(http://youtu.be/5V8zm_Z9kEs)은 프로세스가 실제 어떻게 수행되는지 보여줌

 

관리자들은 즉시 특정 단계에서의 전환율(conversion rates)과 대출 심사(underwriting) 단계에서의 불완전(imcomplete) 케이스 수에 대해 질문하기 시작합니다. 그들의 관심을 받는 것은 기쁘지만, 내부 과정에 대해 논의하기에는 너무 이르다는 것을 깨닫게 됩니다. 우선, 고객 관점에서 본질에 집중해야 합니다. 

다행히, 고객노력지수(CES : Customer Effort Score)와 고객추천지수(NPS : Net Promoter Score)를 포함한 광범위한 고객 만족도 조사 자료를 가지고 있습니다. 해당 자료에는 금액(즉, 이자)과 대출신청 처리 속도 및 용이성을 고객이 가장 중요한 요소로 고려하고 있음이 기술되어 있습니다. 이를 CTQs(Critical to Qualities)로 변환하면 다음과 같습니다.

• 매달, 제안(Offer)의 90%는 첫 번째 고객 접촉 후 8시간 이내에 제공되어야 함
• 고객의 80%는 계약서 수령 후 3영업일 이내에 대출 신청에 대한 확신을 가져야  함

 

 

 

Part 2. 측정 (Measure) 단계 

 

 

지금까지 고객에게 1주일 이내에 대출이 제공되어야 한다는 목표를 설정했고 (<그림5>의 a 참고), 이를 두가지 CTQs(Critical to Qualities)로 변환했습니다.

 

• CTQ 1: 제안의 90%는 첫 번째 고객 접촉 후 8시간 이내에 제공되어야 함(<그림 5>의 b 참고)
• CTQ 2: 고객의 80%는 계약서 수령 후 3영업일 이내에 대출 신청에 대한 확신을 가져야 함 (<그림 5>의 c 참고)

 

 

<그림 5> 승인 및 거절된 신청서들만 있는 프로세스 맵에서 목표 및 CTQ (평균 기간)

 

다음 단계에서 목표와 CTQ가 제대로 준수되고 있는지 측정하려고 합니다.

 

고객에게 1주일 이내에 대출 제공하기 

 

해당 목표를 측정하려면 먼저 완료된 케이스를 찾아야 합니다. 승인되거나 거절된 14,761개의 대출 신청 건을 선택하려면 Disco의 Endpoints 필터를 사용합니다 (<그림6> 참고). 'Approved' 및 'Rejected' 액티비티를 선택한 후 'Apply filters permanently' 옵션을 지정하여 해당 필터의 결과가 '새로운 100%의 데이터 셋이 되도록 합니다.

 

 

<그림 6> 승인 및 거절된 대출 신청 필터링

 

이제 여러분은 7일 이내에 완료된 대출 건수를 확인할 수 있습니다. 이를 위해 Performance 필터를 추가하고 Case duration을 7days로 설정합니다 (<그림7> 참고). 필터를 구성하는 동안 현재 선택 항목에서 다루는 케이스 수에 대한 추정치가 화면 왼쪽 하단에 표시됩니다. 필터 적용 결과, 실제 대출 신청 건수의 66%인 9,782건의 케이스들이 7일 이내에 완료되었음을 확인할 수 있습니다 (<그림8> 참고).

 

 

<그림 7> 7일 이내에 완료된 대출 신청 필터링

 

만일 여러분이 (앞에서) Endpoints 필터를 설정할 때 'Apply filters permanently' 옵션을 사용해 새로운 데이터 셋을 만들지 않았다면, 최초 데이터 셋인 20,732개의 케이스에서 7일 이내에 완료된 대출 신청 케이스를 추출하게 됩니다. 이 최초 데이터 셋에는 대출이 승인되거나 거절된 14,761개의 케이스 뿐 아니라 방금 대출 프로세스가 시작되었거나 현재 고객 등의 반응을 기다리는 케이스도 포함되어 있습니다. 따라서 필터링 결과의 케이스 수는 9,872건으로 동일하겠지만, 9,782건이 전체 20,732건의 47%에 해당하기 때문에 잘못된 비율정보를 얻게 됩니다.

 

 

<그림 8> 7일 이내에 대출이 승인되거나 거절된 대출 프로세스의 맵

 

7일 이내 완료된 케이스를 필터링하는 것 외에 7일 이상 걸린 케이스를 필터링할 수도 있습니다 (<그림7>의 Performance 필터에서 반대로 선택). 7일 이상 소요된 대출 신청 건을 살펴보면, 우편접수채널이 지연을 초래했다는 것을 알 수 있습니다. 우편으로 대출 제안(Offer)을 보내고, 이를 다시 고객으로부터 받으려면 리드타임이 2~4일 가량 추가됩니다. 이것이 대출 신청 프로세스의 낮은 전환율 원인 중 하나일까요?

이러한 발견은 흥미로운 토론을 촉발시켰습니다. 대출 신청 프로세스의 오프라인 업무 처리 부분을 온라인 채널로 이동하면 완료 시간을 크게 단축할 수 있습니다. 그러나 이를 위해서는 상당한 IT 투자가 필요합니다. 기존 온라인 플랫폼을 확장하여 디지털 방식으로 계약을 체결하고 대출 심사(underwriting)에 필요한 문서를 안전하게 제공해야 하기 때문입니다.

우리는 아직 개선 단계에 있지 않기 때문에 기준에 맞게 측정하는데 집중하겠습니다

 

CTQ 1 : 8시간 이내에 제안(Offer) 제공

 

온라인 대출 신청 후 대출 제공업체는 각 고객에게 전화를 걸어 요구 사항을 확인하고 정확한 정보를 제공합니다.

처리 속도는 대출 제공업체에 대한 고객의 결정에 영향을 미치는 하나의 요인으로 간주됩니다. 따라서 경영진은 첫 번째 고객 접촉(CTQ 1)후 (근무시간 기준) 8시간 이내에 제안을 제공해야 한다는데 동의했습니다.

CTQ 1이 준수되고 있는지 확인하기 위해 프로세스의 첫번째 액티비티에서 'Offered' 까지의 구간을 살펴봐야 합니다. 완료된 케이스 뿐 아니라 프로세스가 아직 종료되지 않았으나 이미 제안이 제공된 케이스를 포함하기 위해 전체 데이터 셋에서 다시 시작합니다.

 

 

<그림 9> CTQ 1 측정을 위해 프로세스 시작 액티비티에서 'Offered'까지의 구간 데이터를 새로운 데이터 셋으로 생성함

 

프로세스 시작에서 첫번째 'Offered'까지의 구간 데이터를 새로운 데이터 셋으로 생성하고자 합니다. 이를 위해 Endpoints 필터의 'Trimfirst' 옵션을 사용합니다. 프로세스의 시작 액티비티(Lead와 Online)와 'Offered' 액티비티를 선택한 후 'Apply filters permanent' 옵션을 지정해 새로운 데이터 셋을 생성합니다 (<그림9> 참고). 필터링을 통해 추출된 구간 데이터는 이제 CTQ 1 준수여부 측정을 위한 프로세스 범위가 됩니다 (<그림10> 참고)

 

<그림 10> CTQ 1의 준수여부 측정을 위한 프로세스 범위

 

이제 여러분은 Performance 필터를 사용하여 대출 제공업체가 8시간 이내에 제공한 제안의 수를 측정할 수 있습니다. 그 결과 8,038건의 대출 신청 중, 39%에 해당하는 3,175건에 대해서 고객 서비스 상담원이 8시간 이내에 제안을 했습니다.

그러나 실제로 CTQ는 근무시간 기준으로 정의됩니다. 고객센터는 24시간 운영하지 않고 주 6일 운영합니다. 평일에는 오전 8시에서 오후 8시까지, 토요일은 오전 8시에서 오후 3시까지 근무합니다. 근무 외 시간은 측정에서 제외해야 합니다. 그렇지 않으면, 이전 근무일 마감 직전에 접수되어 다음 근무일 시작 직후에 완료된 대출 신청서에 대한 제안은 CTQ를 충족하지 못한 것으로 잘못 측정되게 됩니다.

근무시간 기준으로 측정하려면 한 가지 단계를 추가로 수행해야 합니다. Disco의 TimeWarp 기능을 사용해 콜 센터 팀의 근무시간을 정의할 수 있습니다. 요일별 근무시간을 지정하는 것 외에도 휴일(전체 휴무일)을 자동으로 제외할 수 있습니다 (<그림11> 참고).

결과적으로, 모든 Performance 지표는 근무시간 기준으로 계산됩니다. 예를 들어, 'Lead(대출 신청서가 콜센터에 접수될 때)'에서 'Offered(대출 제공업체가 제안을 발송할 때)' 단계까지의 리드타임 중앙값이 18.6시간(달력일 기준)에서 5.6시간(근무시간 기준)으로 변경됩니다. 팀의 근무시간 이외의 시간은 계산되지 않습니다(<그림11>의 왼쪽과 오른쪽 맵 참고).

 

 

<그림 11> TimeWarp 기능을 사용해 근무시간 및 공휴일 지정 전과 후의 프로세스 수행시간(중앙값)

 

TimeWarp 기능이 적용된 케이스들을 <그림12>와 같이 Disco에서 내보내기(export)하고, Minitab에서 CTQ 1을 평가해 프로세스 성과를 분석할 수 있습니다(<그림13> 참고).

전체 대출 신청의 56%(이전에 달력일 기준으로 측정한 39%가 아님)가 (근무시간 기준) 8시간 이내에 제안을 받은 것으로 나타났습니다. 76%의 대출 신청에 대해 콜 센터 팀은 (근무시간 기준) 16시간 이내에 제안을 제공할 수 있습니다.

 

 

<그림 12> TimeWarp로 근무시간 및 공휴일 지정 후, Performance 지표가 근무시간 기준으로 변경됨

 

 

<그림 13> Disco에서 내보내기한 케이스 정보를 기반으로 Minitab에서 분석

 

TimeWarp 기능이 적용된 데이터 셋에 Performance 필터를 사용해 케이스 수행시간을 최대 8시간으로 지정해도 동일한 결과를 얻을 수 있습니다(<그림14> 참고). 따라서 측정을 위해 Minitab으로 이동할 필요는 없습니다. 우리는 프로세스 마이닝 도구인 Disco에서 CTQ를 직접 측정할 수 있습니다.

 

 

<그림 14> 56%의 케이스가 (근무시간 기준) 8시간 이내에 오퍼를 제공하는 CTQ 1을 충족함

 

CTQ 준수 여부를 측정하는 것 외에도 프로세스 마이닝 도구를 사용하면 프로세스의 (주요) 흐름, 프로세스 변동(variants), 병목 현상, 개별 케이스 등을 매우 상세히 분석할 수 있습니다.

 

CTQ 2 : 3 영업일 이내에 결정

 

대출 심사 프로세스(underwriting process)의 기준을 설정하는 것은 조금 더 복잡합니다. 특히, 대출에 대해 언제 확신이 들었는지를 정의하는 것은 그리 쉬운 일이 아닙니다. 심사숙고하여 대출 신청자가 서명한 계약서를 반환한 순간부터 신청서가 승인되거나 거절될때 까지를 측정하기로 결정했습니다. 이를 위해 Endpoints 필터의 'Trim' 모드를 이전과 같이 다시 사용할 수 있습니다 (<그림15> 참고).

 

 

<그림 15> CTQ 2 기준에 따라 필터 설정

 

<그림 15>에서와 같이 필터를 설정하면, 3일 이내에 41%의 대출 신청서만 승인 또는 거절되었음을 알 수 있습니다. 그러나 프로세스를 자세히 살펴보면, 이상한 점을 발견할 수 있습니다. 불완전(incomplete) 신청서는 승인되면 안됩니다(<그림16>의 왼쪽에 강조 표시된 경로 참고). 또한 활성 케이스 작업 그래프('Active Cases over Time' 참고)는 매월 22일마다 유의한 감소를 보여줍니다(<그림16>의 오른쪽에서 강조 표시된 감소 참조). 이것은 다수의 케이스가 동시에 완료됨을 의미합니다.

 

 

<그림 16> 불완전 신청서가 승인됨(왼쪽), 진행 중인 작업의 급격한 하락이 매월 22일에 관찰됨(오른쪽)

 

여러분은 신용 관리자와 함께 해당 케이스를 보면서 어떤 일이 일어났는지 설명할 수 있습니다. 대출 상품 외에 신용 상품도 제공하는데, 일부 고객은 해당 월의 22일에 지급받기를 요청합니다. IT 시스템에서 지불금은 대출 활성화와 연결됩니다. 따라서 이러한 대출 신청은 지불을 지연시키기 위해 (인위적으로) Incomplete 모드로 설정되었다가 22일에 모두 Approved으로 변경되어 지급이 이루어집니다.

대출 신청이 불완전함을 나타내기 위해 사용되는 Incomplete 상태를 오용하는 것으로 확인되었습니다. 그러나 지연된 지급 건은 전혀 불완전한 신청이 아니었습니다. 이러한 시스템 오용은 프로세스 마이닝 분석(및 보고) 시 데이터 품질 문제로 고려해야 합니다. 신용 관리자는 고개를 끄덕이며 현재 해당 문제점을 알고 있다고 말했습니다.

 

 

<그림 17> 'Incomplete'에서 'Approved' 단계로 이어지는 케이스 제거

 

'Incomplete' 단계를 거친 모든 신청서가 불완전한 것이 아니라는 사실 외에도 (고객이 이미 신용 대출에 대해 명확하게 알고 있었기 때문에) 이러한 지연된 지급액을 CTQ 2 측정 대상에서 제외해야 합니다. 

데이터를 정리하려면 프로세스 맵에서 Incomplete에서 Approved까지의 경로를 클릭하고 'Filter this path'를 통해 필터를 추가합니다(<그림17> 참고). 그런 다음 필터 설정을 'directly followed'에서 'never directly followed'으로 변경하여 해당 케이스를 제고할 수 있습니다. 다시 'Apply filters permanently' 옵션을 선택하여 필터링한 데이터 결과를 새로운 기준 데이터 셋으로 설정합니다(<그림18> 참고).

 

 

<그림 18> 필터 설정을 'never directly followed'로 변경한 후, CTQ 2를 위한 새로운 데이터 셋 생성

 

수정된 데이터 셋에는 'Incomplete' 상태의 지연(parked) 케이스가 포함되지 않아, 월 22일 전후로 급격한 하락이 발견되지 않습니다(<그림19> 참고).

 

 

<그림 19> CTQ 2 측정을 위한 새로운 데이터 셋

 

새로운 데이터 셋에서 CTQ 2 준수 여부를 측정했을 때 3일 이내에 처리된 대출신청이 41%에서 45%로 증가했습니다. 하지만 여전히 수정해야 할 사항이 하나 더 있습니다.

CTQ 1과 마찬가지로 CTQ 2 준수여부를 측정했을 때 3일 이내에 처리된 대출신청이 41%에서 45%로 증가했습니다. 하지만 여전히 수정해야 할 사항이 하나 더 있습니다.

CTQ 1과 마찬가지로 CTQ 2의 정의는 실제로 달력일 기준이 아니라 근무일 기준입니다. 따라서 주말 및 공휴일은 측정에서 제외해야 합니다. 이 문제는 앞서 TimeWarp 기능을 사용한 것과 유사하게 근무일을 지정함으로써 해결할 수 있습니다.

신용 대출 팀은 월요일부터 금요일까지 주 5일 근무합니다. SLA는 일 단위로 정의되므로, 해당 요일의 근무 시간을 지정할 필요가 없습니다. 근무일을 표시하고 주말과 공휴일을 제외하는 것만으로 정확한 결과를 얻을 수 있습니다(<그림20> 참고).

 

 

<그림 20> 근무일 기준 CTQ 2 측정할 수 있도록 TimeWarp 기능 설정

 

TimeWarp 기능을 설정하면 CTQ 2에 대한 측정값은 62%로 확인됩니다 (<그림 21> 참고).

 

 

<그림 21> 62%의 케이스가 3 영업일 이내에 대출을 결정하는 CTQ 2를 충족하는 것으로 확인됨

 

CTQ 2 측정값이 초기 41%에서 62%로 증가한 것을 알 수 있습니다. 이는 큰 차이입니다. 프로세스 마이닝은 데이터 품질 문제를 파악하고 휴무시간을 수정하여 CTQ를 정확하게 측정하는데 도움이 되었습니다. 또한 신용 관리자와의 신뢰를 구축하는데 도움이 되었습니다. 신용 관리자는 데이터 검증을 지원함으로써 여러분이 측정한 수치가 프로세스의 현실을 반영한다는 확신을 얻었습니다.

 

 

References

[1] Case Study: General Electric (GE) and Six Sigma: https://6sigma.com/case-study-general-electric-six-sigma/

[2] DMAIC, Wikipedia: https://en.wikipedia.org/wiki/DMAIC

[3] Value Stream Mapping, Wikipedia: https://en.wikipedia.org/wiki/Value-stream_mapping