만약 여러분이 프로세스 개선/재설계(redesign)/혁신/린 6시그마에 관여하고 있다면 재작업(rework)을 줄이는 것이 중요한 관심사항 중의 하나일 것이다.

재작업이 발생하는 두 가지 일반적인 원인은 다음과 같다.

1. 작업이 처음에 올바르게 수행되지 않아서 누군가가 그 작업을 다시 수행해야 함.
2. 케이스(case) 처리에 요구되었던 정보가 생략되거나 불충분해서 해당 케이스가 되돌려 보내짐.

 

재작업은 기업에게 업무량(과 비용)을 가중시키고, 내·외부 고객에게 약속한 프로세스 완료 시간을 지연시키고, 추가 작업으로 관련된 케이스들의 완료시간에도 종종 영향을 준다. 그러므로 재작업은 발견되어 제거되어야 할 대상이다.

프로세스 마이닝은 여러분의 프로세스에 나타나는 재작업 패턴을 발견하고, 정확히 묘사하는 것을 도울 수 있다. 프로세스 마이닝 도구는 IT 시스템에 기록된 데이터를 활용하여 실제 프로세스를 가시화한다. 이를 통해 여러분은 어느 곳에서, 얼마나 빈번하게 재작업이 발생하고, 이 재작업이 특정 지역이나 제품과 관련된 프로세스 범주에 영향을 주는가를 알 수 있을 것이다.

 

재작업이 어느 곳에서 얼마나 자주 발생하는가를 알았다고 해도 여러분은 여전히 프로세스 마이닝 도구를 벗어나서 이러한 재작업이 왜 발생하는가를 알기 위해서 대상 프로세스의 이해관계자들과 대화해야만 한다. 그런데 중요한 점은 여러분은 이제 프로세스 마이닝을 통해서 이해관계자들과의 토론에 매우 유용한 객관적인 정보와 시각적인 증거를 확보할 수 있다는 것이다.

그런데 조직 내 수많은 사람들이 어떻게 재작업을 발견하지 못할 수 있을까? 일반적으로 모든 사람이 항상 계획에 따라서 일하는 것은 아니다. 개별 직원은 몇 개의 예외적인 케이스만을 처리하고 있다고 생각할 수 있다. 그러나 개인 수준에서 모인 몇 개의 추가 작업들이 회사 수준에서는 상당한 낭비가 될 수 있다. 이러한 효과가 때때로 “숨겨진 공장(hidden factory)[1]”이라고 불린다. 프로세스 마이닝의 도움으로 여러분은 전체 프로세스에 대한 객관적인 개관을 제공하고 숨겨진 프로세스 패턴을 가시화할 수 있다.

예를 들어, 소비자 전자제품 제조업체의 반품 프로세스 사례가 이에 해당한다. 이 회사는 고객으로부터 반품 요청을 받는 웹사이트의 폼(form)을 개선함으로써 손실 정보의 양과 (손실 정보를 고객에게 다시 요청해야 하는) 일의 양, 핵심적인 고객응대(customer-facing) 프로세스(즉, 반품 프로세스)의 완료시간을 단축했다.

해결책이 항상 기술적일 필요는 없다. 예를 들어, 콜센터에서 반복 콜이 증가하는 것은 품질 문제를 나타낸다. 즉, 첫 번째 통화에서 문제가 해결되지 않았기 때문에 사람들이 다시 통화를 하는 것이다. 콜센터 직원들은 통화 시간을 가능하면 짧게 유지하도록 교육받았다. 이것이 비용을 절감해 주는 것처럼 보일 수도 있다. 그러나 장기적인 관점에서 이러한 교육은 득보다 실이 많다. 왜냐하면 만족하지 못한 고객들이 전화를 계속 걸기 때문이다. 경영진의 초점을 ‘first time right (처음에 제대로 해결하기)’로 전환한 기업은 고객 경험과 콜센터 효율성을 크게 향상시킬 수 있다.

프로세스 마이닝을 통해서 여러분은 대상 프로세스의 문제점을 객관적인 방식으로 정확하게 파악할 수 있다. 이것을 통해서 여러분의 팀은 프로세스 분석에서 (what이 아닌) why (문제점의 근본원인)에 집중할 수 있다. 이것은 프로세스 마이닝이 제공하는 큰 혜택 중의 하나이다.

여러분은 이 아티클에서 프로세스 마이닝 도구인 Disco를 활용하여 재작업을 발견할 수 있는 6가지 팁을 배울 수 있다.

 

1) ‘Filter this path…’ 숏컷(shortcut)을 이용한 직접 루프의 필터링

 

재작업은 여러분의 프로세스에서 다양한 종류의 루프(loop) 패턴들로 나타난다. 여러분은 종종 발견된 프로세스 맵에서 이러한 루프를 직접 확인할 수도 있다.

예를 들어, 아래의 콜센터 프로세스 맵에서 여러분은 인바운드 콜들(inbound calls)로 시작한 케이스들을 볼 수 있다. 또한 여러분은 일부 케이스들에 대해서 반복 콜들을 의미하는 ‘Inbound Call’ 액티비티의 자체 루프(self-loop)를 볼 수 있을 것이다.

 

 

루프 화살표를 클릭하여 ‘Filter this path…’ 버튼을 누르면 (아래의 그림 참조) 여러분은 이러한 반복 콜들에 집중할 수 있다.

 

 

여러분은 이 경로에 대해서 미리 설정된 ‘Follower filter’ 화면을 보게 될 것이며 우측 하단에 있는 ‘Apply filter’ 버튼을 누르면 된다.

 

 

결과적으로, 여러분은 반복 콜들에 대한 새로운 프로세스 맵을 볼 수 있다. 전체 케이스들 중에서 16%가 이러한 반복 콜 패턴을 보임을 알 수 있다.

 

 

 

2) ‘Eventually follows’ 옵션을 이용한 전역 반복(global repetitions)의 포착  

 

전술한 직접 루프의 필터링은 ‘Inbound Call’ 액티비티에 대한 직접적인 반복을 보여주었다. 그러나 몇몇 다른 액티비티들이 수행된 이후에 이 액티비티로 되돌아오는 반복은 어떻게 포착할 수 있을까?

예를 들어, 고객이 처음에 콜센터에 전화했고(‘Inbound Call’), 이후에 콜센터 직원이 고객에게 다시 전화를 했다(‘Outbound Call’). 일정 시간이 경과한 후에 고객이 다시 콜센터에 전화했다(다른 ‘Inbound Call’ )고 하자. 이 시나리오에서 고객의 반복된 콜(‘Inbound Call’)이 있었지만 이 콜들이 연속적으로 발생하지 않았다. 그래서 이러한 반복 패턴이 직접 루프의 형태로 프로세스 맵에 나타나지 않은 것이다.

그렇다면 ‘Inbound Call’ -> ‘Outbound Call’ -> ‘Inbound Call’ 반복을 포함하는 케이스의 수를 세고, 분석하기 위해 어떻게 하면 될까?

사실 이러한 반복은 간단히 포착될 수 있다: 여러분은 (왼쪽 하단의 필터 기호를 클릭하여) ‘Follower filter’로 되돌아간 후에 ‘directly followed’에서 ‘eventually followed’로 모드를 변경할 수 있다. 이제 여러분의 필터 결과는 프로세스의 어떤 지점에서라도 ‘Inbound Call’ 액티비티로의 반복을 가지는 모든 케이스들을 포함하게 된다(다음 그림 참조).

 

 

이제 필터 결과는 프로세스의 어떤 지점에서라도 ‘Inbound Call’ 액티비티의 반복이 발생한 모든 케이스들을 포함할 것이다.

 

3) 동일한 유형의 루프에 대한 필터링

 

지금까지 우리는 동일한 액티비티가 여러 번 수행된 모든 케이스를 필터링하는 방법을 살펴보았다. 그러나 때때로 여러분이 분석하고자 하는 반복 패턴은 훨씬 일반적일 수 있다.

예를 들어, 여러분은 몇 개의 필드들을 결합하여 액티비티를 구성할 수 있다(PMIG 웹사이트의 BLOG에 올려진 ‘프로세스 마이닝을 통한 다양한 관점의 도출’ 아티클에 다중 필드들을 결합하여 액티비티를 구성하는 방안이 자세히 설명되어 있음). 예를 들어, 아래의 스크린 샷은 (콜센터) 데이터를 가져오는 동안에 ‘Operation’과 ‘Agent Position’ 필드를 결합하여 액티비티를 설정하는 방법을 보여주고 있다.

 

 

이러한 설정을 통해 여러분은 콜센터 프로세스에 대한 더욱 정교한 모습을 볼 수 있다. 전방(FL: front line)과 후방(BL: back line)에 위치한 직원들 사이의 접점이 프로세스 맵에 명확하게 표시된다. 이것은 프로세스 마이닝의 크나큰 장점이다. 그러나 이전과 같이 ‘Inbound Call’과 관련된 반복 콜을 필터링하고 싶다면 여러분은 ‘Inbound Call’ 액티비티의 두 가지 버전들(즉, ‘Inbound Call\\FL’과 ‘Inbound Call\\BL)을 액티비티 목록에서 모두 선택해야 한다.

 

 

액티비티 목록에서 두 가지 버전의 ‘Inbound Call’ 액티비티를 선택하는 대신에 여러분은 아래의 그림과 같이 ‘Filter by:’에서  ‘Operation’ 필드를 선택한 후 ‘Inbound Call’을 선택해서 이러한 번거로움을 덜 수 있다.

 

 

한편, 유사한 방법으로 여러분은 동일한 사람이나 부서, 데이터셋에 포함된 다른 속성에 의한 재작업을 포함하는 케이스들을 발견할 수도 있다.

 

4) 발생 위치를 알지 못하는 반복에 대한 필터링

 

만약 여러분이 어떤 루프에 집중해야 하는가에 대해서 모른다면 어떻게 할 것인가? 즉, 대상 프로세스에 포함된 어떤 액티비티가 재작업에 관여되었는가에 상관없이 여러분은 재작업을 가지는 모든 케이스들에 대한 필터링을 원할 수도 있다.

이것을 수행하기 위해서 여러분은 역시 Follower 필터를 이용할 수 있다. 방법을 알기 위해서 Disco의 Sandbox에 담긴 구매 프로세스 예제를 이용하면 된다:

첫째, 필터를 추가하기 위해서 왼쪽 하단의 필터 기호를 클릭하라.

 

 

그런 다음에 필터 목록에서 Follower 필터를 추가하라.

 

 

다음 페이지의 Follower 필터 설정에서 참조(reference)와 팔로어(follower) 값들로 모든 액티비티들을 선택하라. 사실, 이러한 설정은 이용할 수 있는 모든 조합을 맞추기 때문에 데이터셋에 포함된 모든 케이스들이 선택될 것이다.

요령은 다음과 같다: 여러분은 참조와 팔로어 이벤트 목록의 아래에서 또 다른 속성들에 대한 제약들을 추가할 수 있다. 이러한 속성들은 같거나 다른 값을 갖도록 요청된다. 종종 이것은 직분분리(segregation of duties) 위반이나 다른 컴플라이언스 제약들의 필터링에 활용된다. 그러나 우리는 ‘the same value’ 옵션을 이용해서 어떤 종류의 반복들이라도 필터링을 하려는 것이다.

‘Require’ 체크박스를 선택하고, 다음 페이지의 그림에 나타난 것처럼, 액티비티(activity)가 동일한 값을 갖도록 설정을 구성하라. 그리고 나서 ‘Apply filter’를 클릭하라.

 

 

이 필터는 어떤 액티비티가 반복되었는가에 상관없이 프로세스의 어떤 곳에서라도 반복을 가지는 모든 케이스들을 추출한다. 모든 케이스들 중에서 41%의 케이스들이 프로세스 상에서 반복을 가짐을 알 수 있다.

 

 

5) ‘Max repetitions’ 옵션을 이용한 최대 반복의 시각화    

 

가장 빈번한 반복이 일어나는 곳을 찾기 위해서 여러분은, 아래의 그림에 나타난 것처럼, 프로세스 맵 뷰를 ‘Max repetitions’로 바꿀 수 있다. 여러분의 프로세스 맵에 나타난 숫자들은 모든 케이스를 고려했을 때 액티비티(나 경로)가 수행된 최대 횟수를 나타낸다.

위에서 언급한 구매 프로세스 예에서, ‘Amend Request for Quotation Requester’ 액티비티는 동일한 케이스에서 12번 반복되었기 때문에 아래의 프로세스 맵에서 매우 두드러져서 나타난다.

 

 

6) 단일 액티비티에 집중함으로써 구체화된 반복 통계자료 보기  

    

우리는 이제 ‘Amend Request for Quotation Requester’ 액티비티가 동일한 케이스에 대해서 12번까지 수행되었음을 알고 있다. 그러나 정확히 얼마나 많은 케이스들이 이 액티비티를 그렇게 자주 반복했을까? 단지 하나의 케이스일까? 얼마나 많은 반복들이 가장 일반적인 것일까?

만약 하나의 구체적인 반복 액티비티에 더욱 집중하고 싶다면 다음과 같이 하면 된다:

첫째, 아래의 그림과 같이, 집중하고 싶은 액티비티를 클릭하고 ‘Filter this activity…’ 버튼을 눌러라.

 

 

그런 다음에 아래의 그림과 같이, Attribute 필터에서 ‘Mandatory’에서 ‘Keep selected’ 모드로 변경하라 (우리는 단지 이 하나의 액티비티만 유지하기를 원하는 것이다).

 

 

이 필터를 적용한 후에 맵(Map) 뷰에서 통계(Statistics) 뷰로 변경하라.

 

 

마지막으로, 이 특정 액티비티가 케이스 별로 얼마나 자주 수행되었는가를 보기 위해서 ‘Events per case’ 통계로 변경하라.

예를 들어, 이제 여러분은 ‘Amend Request for Quotation Requester’ 액티비티가 12번 수행된 하나의 케이스가 있고, 이 액티비티가 6번 수행된 3개의 케이스들이 있음을 알 수 있다 (아래의 그림 참조).

 

 

앞에서 설명된 6개의 시나리오에 대해 여러분은 이제 더욱 많은 통계치를 살펴봄으로써 재작업 패턴의 맥락을 분석할 수 있다. 예를 들어, 여러분은 어떤 프로세스 범주(예, 지역, 제품유형 등에 따른 범주)가 가장 크게 영향을 받는가를 살펴볼 수도 있다. 또는 케이스(Cases) 뷰에서 개별 케이스들을 검사함으로써 (예, 코멘트 필드를 보거나 이러한 케이스들의 수행에 관련된 사람들과 대화함) 재작업 패턴의 수행맥락을 더욱 깊게 분석할 수 있다.

 

[1] 숨겨진 프로세스, 맹목영역, 사각지대를 숨겨진 공장(hidden factory)이라고 부른다.

 

 

Fluxicon제공 | PMIG 번역 ( e-mail: info@pmig.co.kr  website: http://www.pmig.co.kr/ )