프로세스 마이닝을 통한 다양한 관점 도출
- 작성일2021/12/29 15:04
- 조회 800
데이터 분석팀은 탐구적 데이터 분석에 많은 시간을 보낸다. 예를 들어, 오렐리(O’Reilly)가 실시한 ‘2015 데이터과학 연봉 조사(2015 Data Science Salary Survey)’ 에 따르면 46%의 응답자는 데이터에 대한 요약, 시각화, 이해와 같은 탐구적 분석(exploratory analysis)에 매일 1~3시간을 보낸다고 답변했다. Disco와 같은 프로세스 마이닝 도구는 프로세스 관련 데이터(즉, 이벤트 로그)에 대한 탐구적 분석에 특화된 도구이다. 비즈니스 또는 IT 프로세스와 관련된 데이터과학 프로젝트를 수행하는 데이터 분석팀은 의미 있는 방식으로 머신러닝 알고리즘을 학습하거나 (고급) 통계분석을 수행하기 전에 프로세스 마이닝을 활용하여 대상 프로세스를 탐색하고 이해할 필요가 있다. 마찬가지로, 비즈니스 또는 IT 프로세스를 개선하는 프로젝트를 수행하는 프로세스 분석팀은 문제점을 발견하고 개선안을 도출하기 전에 프로세스 마이닝을 활용하여 대상 프로세스를 탐색 및 이해하고 분석해야 한다.
프로세스 마이닝은 하나의 이벤트 로그를 활용해서 실세계 프로세스에 대한 다양한 관점들을 제공할 수 있다. 프로세스 마이닝의 이러한 차별화된 장점은 프로세스 관련 데이터에 대한 탐구적 분석에 기여할 수 있다. 예를 들어, 분석팀은 <부록 1>의 [D1: 콜센터 데이터셋]에 대한 <부록 2>의 [그림 A-2]의 데이터 가져오기 설정을 통해서 [그림 1]과 같은 프로세스 관점을 얻을 수 있다. 이와 함께, 분석팀은 데이터 가져오기 설정 단계에서 케이스 아이디와 액티비티에 대한 설정 변경을 통해 대상 프로세스에 대한 다양한 관점들을 얻을 수 있다. 다양한 관점들을 얻을 수 있는 대표적인 3가지 방식은 다음과 같다.
결합된 액티비티의 활용을 통한 관점의 변화
대상 프로세스에 대한 더욱 구체적인 모습을 얻기 위해 분석팀은 다양한 필드들을 결합하여 새로운 액티비티를 정의할 수 있다 . 예를 들어, [그림 1]의 프로세스 맵을 도출한 분석팀은 콜센터의 전방[‘Agent Position’ 속성의 값이 ‘FL(즉, Front Line)’인 경우]과 후방[‘Agent Position’ 속성의 값이 ‘BL(Back Line)’인 경우]에서 수행된 액티비티의 구분을 원할 수 있다. 이 경우에 분석팀은 ‘Operation’과 ‘Agent Position’ 속성을 결합하여 새로운 액티비티를 정의할 수 있다([그림 2] 참조). 이러한 설정에 기반을 두고 [D1: 콜센터 데이터셋]을 Disco에 가져오면 전방과 후방에서 수행된 동일한 프로세스 단계(예, ‘Handle Case’)가 서로 다른 액티비티(예, ‘Handel Case＼＼FL’과 ‘Handle Case＼＼BL’)가 되기 때문에 발견된 프로세스 맵은 더욱 많은 액티비티들을 포함한다([그림 3] 참조).
[그림 1] 콜센터 프로세스에 대한 하나의 관점(절대 빈도 기준)
[그림 3]의 맵에서 분석팀은 전방에 걸려온 고객문의 전화들 중에서 후방의 전문가들에게 처리를 의뢰하는 137건의 사례가 있음을 알게 되었다. 사실, 후방의 전문가들은 다른 중요한 업무를 수행하고 있다. 그러므로 가능하면 고객문의 전화를 이들에게 넘기지 않는 것이 좋다. 분석팀은 137건의 사례를 추가 조사하여 고객문의 전화를 후방의 전문가들에게 넘기는 횟수를 줄이는 방안을 발견할 수 있을 것이다.
[그림 2] 2개 액티비티의 결합을 통한 새로운 액티비티의 정의
[그림 3] 결합된 액티비티 정의에서 도출된 새로운 프로세스 맵(케이스 빈도 기준)
다른 액티비티 속성의 활용을 통한 관점의 변화
분석팀은 [D2: 구매 데이터셋]에 대한 [그림 4]의 데이터 가져오기 설정을 통해서 [그림 5]와 같은 프로세스 맵을 발견할 수 있다. 이 프로세스 맵은 액티비티 관점에서 구매 프로세스의 흐름을 보여주고 있다. 이와 함께, 분석팀은 [그림 6]과 같은 데이터 가져오기 설정(즉, Activity 필드를 ‘Other’로, Role 필드를 ‘Activity’로 정의함)을 통해서 조직(구체적으로, 수행자의 역할) 관점에서 구매 프로세스의 흐름([그림 7] 참조)을 파악할 수 있다. 이러한 관점의 프로세스 맵을 발견함으로써 분석팀은 ‘Request Manager’와 ‘Purchasing Agent’ 사이의 상당한 지연과 ‘Requester’와 ‘Purchasing Agent’ 사이의 핑퐁 행동을 발견할 수 있다.
[그림 4] [D2: 구매 데이터셋]에 대한 가져오기 설정의 예
[그림 5] 구매 프로세스에 대한 하나의 관점(절대 빈도 기준)
다른 케이스 아이디 속성의 활용을 통한 관점의 변화
다른 케이스 아이디 속성의 활용을 통한 관점의 변화를 설명하기 위해 인터넷 회사의 고객 서비스 부서를 예로 들고자 한다. 이 부서는 다양한 채널(전화, 웹, 전자메일, 채팅)을 통해서 접수되는 고객문의를 처리하는 지원팀을 가지고 있었다. [그림 8]의 프로세스 맵은 ‘서비스 요청 번호’를 케이스 아이디로 정의하여 고객이 이러한 채널들을 통해서 지원팀을 접촉하는 순간을 보여준다. 이 팀은 서비스 성과를 추적하기 위해서 FCRR 을 핵심 지표로 활용하고 있다. 처음에 이 회사는 2만 1,304개의 착신콜 중에서 540개만 반복콜을 야기했다고 판단했다. FCRR이 98%라는 것은 인상적인 결과다.
[그림 6] 다른 액티비티 속성을 새로운 액티비티로 정의함
[그림 7] 수행자 역할 관점의 프로세스 맵(평균 시간 기준)
[그림 8] 98%의 FCRR (케이스 아이디: 서비스 요청 번호)
그러나 지원팀은 추가 분석을 통해서 98%라는 수치가 잘못된 것임을 알게 되었다. 케이스 아이디로 정의된 서비스 요청 번호(Service Request Number)는 시벨(Siebel) CRM 시스템이 새로운 서비스 요청에 대해서 자동으로 할당하는 유일한 번호이다. 문제는 모든 서비스 요청이 최대 3일 이내에 마감된다는 점이다. 고객이 3일 이후에 다시 전화를 하면 새로운 서비스 요청 번호가 해당 전화 문의에 대해서 생성된다. 그러므로 [그림 8]은 3일 이내에 마감되는 서비스 요청 번호(즉, 케이스 아이디)들의 처리 흐름을 보여주지만, 고객들이 실제 경험하는 서비스 프로세스는 보여주지 못한다. 이러한 문제를 해결하기 위해서 지원팀은 고객 아이디를 케이스 아이디로 정의하여 고객 관점의 프로세스 맵([그림 9] 참조)을 도출했다. 1만 7,065개의 착신콜 중에서 3,000개 이상이 반복되어 FCRR은 82%로 떨어졌다.
[그림 9] 82%의 FCRR (케이스 아이디: 고객 아이디)