WE PROVIDE
피엠아이지는 프로세스 마이닝 관련 컨설팅, 교육, 제품(Disco)을 제공합니다.
PROCESS MINING SUCCESS STORY
프로세스 마이닝은 의료, 금융, 고객 서비스 등을 포함한 수많은 산업 분야에 성공적으로 적용되었습니다.
분야별 프로세스 마이닝 성공사례를 소개합니다.
NEW CONTENTS
프로세스 마이닝 관련 분석 기법, 적용 사례 등 다양한 콘텐츠를 제공하고 있습니다.
피엠아이지가 제공하는 콘텐츠를 이메일로 쉽게 받아보세요.
-
- 린 6시그마와 프로세스 마이닝의 결합_분석
- Part 3. 분석 (Analyze) 단계 여기(클릭)에서 시리즈에 있는 모든 기사의 개요를 볼 수 있습니다. 앞선 CTQ 측정에서, 이미 프로세스의 목표(고객센터의 CTQ 1과 신용대출부서의 CTQ 2)가 충족되지 않았음을 확인했습니다. 다음 질문은 '잠재적인 원인이 무엇인가?' 입니다. 여러분은 고객센터가 최근 긴 디지털화 프로젝트를 완료했다는 것을 알고 있습니다. 그 프로젝트는 고객센터의 많은 리소스를 소비했습니다. 따라서 지금은 다른 프로젝트와 함께 첫 번째 CTQ에 들어가기에 가장 좋은 시기가 아니라고 결정합니다. 그러나 신용 관리자는 대출심사 프로세스에 대한 심층 분석에 매우 관심이 있습니다. 프로젝트 팀이 선정되고 첫 번째 회의가 예정되어 있습니다. 이 회의에서 측정값 및 관찰한 내용을 팀과 공유하고 지연의 잠재적 원인이 무엇인지 질문합니다. 세가지 가설을 설정하고 가설을 검증합니다. 불완전 케이스를 제거하고 기준을 달력일에서 근무일로 변경한 데이터를 기반으로 분석을 수행합니다. 가설 1 : 3 더 많은 대출심사자(underwriters)가 필요할 것이다. 첫번째 가설은 대출 심사팀이 감당할 수 있는 것보다 더 많은 작업이 들어오고 있다는 것입니다. 그렇다면, 시간이 지남에 따라 진행중인 작업이 쌓이는 결과가 초래되어야 합니다. 그러나 Disco의 Active cases over time 그래프를 보면, 진행 중인 작업이 계속 증가하고 있다는 증거를 찾을 수 없습니다(<그림 22> 참고). <그림 22> 진행 중인 작업이 시간이 지남에 따라 증가하는 추세를 보이지 않음 'Active cases over time' 그래프에서는 항상 시작에 'warm-up' 기간이 표시되고, 끝에는 'cool-down' 기간이 표시됩니다. 기간의 시작과 끝의 활성 케이스(active cases) 수는 0입니다. 물론 실제로 진행중인 케이스가 0건은 아니지만, 특정 시간대 이전에 활성화된 케이스는 데이터에 보이지 않습니다. 따라서 warm-up 종료와 cool-down 시작 사이에 해당하는 기간의 추세를 확인합니다(<그림22>의 빨간색 화살표 참고). 신용 대출 프로세스에서 진행 중인 작업이 크게 늘지 않았음을 알 수 있습니다. 가설 2 : € 50 이상의 대출 신청은 처리시간이 더 길 것이다. 연구팀은 또 높은 금액의 신용대출 신청이 더 복잡할 것으로 예상했습니다. 선임 대출심사자의 승인을 필요로 하기 때문에 대출심사자가 부재할 때 지연을 유발할 수 있습니다. 먼저 Disco의 'Amount' 속성을 기반으로 케이스를 필터링하여 최대 €50,000 의 금액을 가진 모집단(A)와 €50,000 이상의 금액을 가진 모집단(B)로 대출신청 케이스를 분할해 해당 가설을 검증합니다. 모집단 (B)의 대출신청에 대한 평균 및 중앙값의 대출신청 처리기간은 모집단(A) 보다 약간 더 길게 나타났습니다. 그러나 이러한 차이가 통계적으로 유의한지 확인해야 합니다. Disco에서 케이스 내보내기(export)를 통해 각 모집단의 케이스 리드타임을 추출할 수 있습니다. Minitab에서 이 두 모집단을 대상으로 가설 검증을 수행하여 모집단(A)와 (B)의 리드 타임 평균이 실제로 다른지 확인하고자 합니다. 두 모집단의 케이스 수행기간을 시간(근무시간 기준)으로 변환하고 하나의 파일에서 별도의 열로 복사합니다(<그림23> 참고). <그림 23> Minitab에서 Mann-Whitney 검정 여기서 고려해야 할 한가지 중요한 점은 신용대출 프로세스의 케이스 기간 분포가 정규 분포를 따르지 않는다는 것입니다. 예측 가능한 기계가 아닌 사람이 중심 역할을 하는 대부분의 서비스 프로세스에서 이러한 결과가 나타납니다. 결과적으로 정규 분포를 가정하는 가설 검정(예: ANOVA 검정)은 적합하지 않습니다. 대신 Mann-Whitney와 같은 비모수 검정을 사용합니다. <그림 23>은 최대 €50,000의 대출 신청이 €50,000 이상의 대출신청보다 처리시간이 더 적게 걸린다는 가설이 사실인지 Mann-Whitney 검정 결과를 보여줍니다. <그림 24> Minitab의 가설검증 결과에 따르면 €50,000 이상의 신용대출 신청에 훨씬 더 많은 처리시간이 필요하지 않았습니다. <그림 24>는 Minitab의 Mann-Whitney 가설 검정 결과를 보여줍니다. 두 모집단에 유의한 차이가 있는 경우 p- 값이 0.05보다 작아야 합니다. 그러나 <그림 24<의 결과에서는 p-값인 0.113이 0.05보다 크므로 €50,000 이상의 금액에 대한 신용 대출신청 처리에 훨씬 더 많은 시간이 걸리지 않는다는 결론을 내릴 수 있습니다. 가설 3 : 불완전 케이스 처리에 더 많은 시간이 소요될 것이다. 앞서 CTQ 측정 단계에서 일부 대출신청이 고객의 요청에 따라 의도적으로 지불을 지연시키기 위해 '불완전(Incomplete)'상태로 설정되었음을 알게 되었습니다. 그러나 이는 실제로 불완전한 대출신청이 아니기 때문에 해당 케이스를 기준 데이터 셋에서 제외했습니다. 이러한 데이터 품질 문제를 수정한 후에도 신용대출 신청이 한 번 이상 완료되지 않은 경우가 여전히 2,339건(기준 데이터 셋의 53%차지)에 달하고, 그 중 일부는 이러한 문제가 여러 번 반복되는 것을 확인하였습니다. 세번째 가설을 이러한 불완전한 대출 신청 건 처리에 더 많은 시간이 소요된다는 것입니다. 결국 누락된 정보는 이메일로 요청해서 고객으로부터 다시 받아야 합니다. 따라서 이는 3 영업일 이내에 고객에게 대출에 대한 확신을 주겠다는 약속이 실현될 수 없는 이유 중 하나일 수 있습니다. 가설 3 검증을 위해 데이터를 2개의 모집단으로 다시 분할합니다. (A)즉시 완료 (never incomplete)된 대출신청 케이스, (B)한번 이상의 불완전(Incomplete)단계가 포함된 대출신청 케이스 Disco 프로세스 맵에서 'Incomplete' 액티비티를 클릭하면 나타나는 'Filter this activity...' 바로 가기를 사용하여 사전 구성된 Attribute 필터에서 'Mandatory' 모드 (모집단 B)를 지정하여 데이터를 쉽게 분할할 수 있습니다. 불완전한 단계가 포함된 대출신청 케이스는 Attribute 필터에서 'Forbidden' 모드(모집단 A)를 지정하여 필터링할 수 있습니다. 이 두가지 모드는 'Incomplete' 액티비티 수행 유무를 기준으로 데이터를 필터링합니다. 모집단 A(왼쪽)와 B(오른쪽)의 프로세스 맵은 아리 <그림 25>에 제시되어 있습니다. <그림 25> 한 번에 완료된 대출신청 케이스(모집단 A, 왼쪽)와 한번 이상의 불완전(Incomplete)단계가 포함된 대출신청(모집단 B, 오른쪽)의 프로세스 맵 (기간 중앙값을 기본 측정항목으로, 절대 빈도를 보조 측정항목으로 사용) 프로세스 맵을 통해, 고객에게 누락된 정보를 요청할 때마다 중앙값 기준으로 26.2 + 20.2 시간이 추가로 누적된다는 것을 알 수 있습니다. 모집단 A는 중앙값 기준으로 1.9 영업일의 리드타임을 가지며, 모집단 B의 경우 중앙값 기준 3.2 영업일의 리드타임을 가집니다. 이제, 이 차이가 통계적으로 유의한지 확인해야 합니다. <그림 26> Minitab에서 영업일 기준 완료된(Complete) 대출신청 건(모집단 A)과 불완전(Incomplete) 대출신청(모집단 B) 케이스의 수행 기간(근무시간 기준) Disco에서 모집단 A와 B에 속한 각각의 케이스 수행기간을 내보낸 다음, 모집단 A의 범주 레이블은 'Complete'으로, 모집단 B의 범주 레이블은 'Incomplete'으로 지정하여 Minitab으로 복사합니다(<그림26> 참고). 그런 다음, Minitab에서 Graphical Summary analysis를 수행하여 데이터에 대한 통계 개요 정보를 얻습니다. <그림 27>은 결과 요약을 보여주며, 이전과 마찬가지로 데이터가 정규분포를 따르지 않음을 확인할 수 있습니다(오른쪽 하단 모서리의 빨간색 강조 표시 참고). <그림 27> 모집단 A와 B에 대한 Minitab의 Graphical Summary analysis 수행결과. 두 모집단 모두 정규 분포를 따르지 않는 것으로 나타남 가설 2에서와 마찬가지로 Mann-Whitney 가설 검정을 다시 적용합니다. 그러나 이번에는 결과를 통해 두 모집단의 케이스 수행기간이 유의하게 다르다는 것을 알 수 있습니다(<그림28> 참고). p-값이 0 이므로 0.05보다 작습니다. 따라서 가설 3이 '참'임을 확인할 수 있습니다. 결과는 95% 신뢰도에서 불완전한 대출신청이 한 번에 완료된 대출 신청보다 44.7~47.4 시간 더 오래 걸린다는 것을 보여줍니다. <그림 28> Minitab의 가설 검정 결과에 따르면 불완전한 대출신청은 한번에 완료된 대출신청에 비해 상당히 많은 시간이 소요됨 근본 원인에 대한 심층 분석 (20) 프로세스 맵에서 대출신청의 불완전한 빈도를 확인할 수 있지만 동일 케이스 내에서 '불완전' 루프가 얼마나 자주 반복되는지는 알 수 없습니다. 해당 정보는 간단한 데이터 처리 작업을 통해 확인할 수 있습니다. 또는 각 반복을 프로세스 맵에서 개별 액티비티로 열거하여 루프를 펼치는 것도 도움이 될 수 있습니다. <그림29>는 펼쳐진 루프가 있는 완전한 대출신청과 불완전한 단계가 포함된 대출신청 모두에 대한 프로세스를 보여줍니다. 액티비티 이름 뒤의 숫자는 1번째, 2번째, 3번째, 4번째, 5번째 또는 6번째 대출신청('불완전' 루프의 수행 횟수)을 나타냅니다. 대부분의 경우, 반복을 펼치면 대출심사팀이 최종 결정을 내리기 전에 한번의 추가 요청만 하면 된다는 것을 알 수 있습니다. 그러나 하나의 케이스에서 최종 승인까지 6번의 반복이 수행되었고, 또한 추가 정보에 대한 5번째 요청 이후에 거절된 대출신청이 없었음을 알 수 있습니다. <그림 29> 루프가 전개된 신용대출 신청 프로세스의 흐름 이와 같이 전개된 프로세스 맵은 이미 진행 중인 상황에 대한 더 깊은 통찰력을 제공하지만 여전히 "왜 이 케이스들이 불완전할까?" 라는 질문에 답하지 못합니다. 대출신청이 완료되지 않은 이유가 데이터에 기록되지 않았기 때문에 초기 데이터 셋을 기준으로 해당 질문에 답할 수 없습니다. 대출심사자와 상의한 후에 여러분은 필요한 서류가 고객마다 다르다는 것을 이해합니다. 처음에는 간단해 보이지만 특히 여러 소득원(고용 상태, 연금 등)을 평가해야 하는 경우, 서류 요건은 매우 빠르게 복잡해질 수 있습니다. 대출심사 정책의 그레이 존에 해당하는 케이스는 대출심사자가 해석할 여지를 남겨둡니다. 다행히도 '불완전한' 이유를 이메일 데이터에서 확인할 수 있습니다. 이메일 데이터는 비정형 데이터이기 때문에 기존 데이터 셋을 보강하려면 수동으로 검토해야 합니다. 전체 데이터 셋의 모든 대출신청에 대한 '불완전한' 이유를 얻으려면 상당한 노력이 필요합니다. 따라서 이러한 불완전한 대출 신청에서 자주 누락되는 것이 무엇인지 이해하기 위해 샘플을 추출하기로 결정했습니다. 샘플 데이터는 총 177건의 대출신청에 대해 939 개의 불완전한 문서를 설명합니다. Minitab에서 파레토(Pareto) 분석을 수행하여 누락된 문서의 빈도를 표시할 수 있습니다(<그림30> 참고). <그림 30> '불완전한' 이유에 대한 파레토 분석 결과 Disco에서 파레토 보기를 생성할 수도 있습니다. 또한 원본 데이터에서 해당 '불완전' 액티비티에 '불완전 사유'속성을 추가하면 추가적인 분석 가능성을 얻을 수 있습니다. 예를 들어, 다양한 '불완전 사유' 속성 조합을 기준으로 필터링하여 이러한 하위 집합에 대한 프로세스 맵을 보다 자세히 볼 수 있습니다. <그림 30>의 '불완전한' 이유에 대한 파레토 분석 결과를 통해 은행 거래 명세서가 가장 빈번한 문제임을 알 수 있습니다. 급여명세서, 계약서상의 문제(예: 서명 누락), 고용명세서 등과 함께 불완전한 문서의 81.4%가 발생합니다. 이러한 '불완전한' 원인을 해결하는데 집중하는 것이 좋은 시작이 될 수 있습니다. 이러한 '불완전' 이유에 대한 근본 원인을 찾으려면 보다 자세한 분석이 필요합니다. 예를 들어, 문서가 누락되었을 수 있습니다. 그러나 문서를 읽을 수 없거나 (잘못된 사진 또는 스캔), 형식이 잘못되었거나, 법적으로 유효하지 않을 수도 있습니다. 근본 원인으로 무엇이 잘못되었고, 이것을 미래에 어떻게 예방할 수 있는지 이해하는 것이 핵심입니다. Fishbone 다이어그램 또는 5-Times-Why 와 같은 고전적인 린 6 시그마 도구는 데이터가 알려줄 수 있는 한계에 도달했을 때 효과적입니다.
-
- 린 6시그마와 프로세스 마이닝의 결합
- 린 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) 단계 Part 2 . 측정 (Measure) 단계 Part 3. 분석 (Analyze) 단계 Part 4. 개선 (Approve) 단계 (continue...) 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
-
- 프로세스 마이닝 도입 ___ A to Z
- [프로세스 마이닝 도입의 모든 것]