프로세스 마이닝에 대한 오해
  • 작성일2021/12/29 15:00
  • 조회 715

프로세스 마이닝을 처음 접했을 때 많은 사람들이 이미 알고 있는 다른 개념이나 도구, 기법, 방법과 프로세스 마이닝을 잘 구별하지 못하는 경우가 있다. 프로세스 마이닝이 다른 접근법과 어떤 점에서 다르고, 이들과 어떻게 결합될 수 있는가를 이해하는 것은 매우 중요하다.

이러한 이해를 통해 여러분은 프로세스 마이닝의 개념을 정확히 파악하고, 동료에게 다른 접근법과의 명확한 차별성을 설명할 수 있다. 또한 여러분은 프로세스 마이닝이 할 수 있는 것에 대한 기대치를 관리할 수 있고, 주어진 문제를 해결하기 위한 프로세스 마이닝과 다른 접근법과의 적절한 결합을 착안할 수 있다.

 

 

BI(Business Intelligence) 또는 리포팅 도구가 아님

 

BI 대시보드가 모니터링과 리포팅 용도로 사용되는 반면에 프로세스 마이닝은 분석 도구이다. 그러므로 이 두 기술은 명확히 다른 사용 사례를 가진다. 예를 들어, 프로세스 마이닝 분석은 모니터링 되어야 할 새로운 핵심성과지표(KPI)를 발견할 수 있고, 프로세스 변화를 가져올 수 있다. 프로세스 마이닝을 분석 도구로서 활용하면 프로세스를 처음부터 끝까지 탐색하고, 다양한 관점에서 분석할 수 있다[프로세스를 다양한 관점으로 분석하는 방안은 본서의 7장에 소개되어 있다]. 결국, 프로세스 마이닝의 목표는 프로세스를 자세하게 이해하는 것이다. 이에 반해, BI 대시보드의 기본 아이디어는 여러분의 프로세스가 예상대로 작동하고 있는가를 나타내는 몇 개의 중요하고 통합된 지표가 존재한다는 것이다. 따라서 대시보드나 리포팅 환경은 매일 확인하기를 원하는 제한된 수의 핵심성과지표에 집중한다.

 

프로세스 마이닝은 종종 상호작용 워크숍에서 활용된다. 여기서 여러분은 프로세스 전문가에게 발견된 프로세스 맵을 보여주고, 그들의 의견을 구한다. 프로세스 전문가는 여러분이 놓칠 수 있는 중요한 내용을 지적하고, 분석 과정이나 워크숍 동안에 도출된 질문에 대한 즉각적인 답을 줄 수도 있다. 그러나 대시보드 도구를 이용하는 경우에는 이러한 상호작용 분석 워크숍을 가질 필요가 없다. 왜냐하면 대시보드의 목적은 분석이 아니라 모니터링이기 때문이다. 이와 같이, 프로세스 마이닝 도구와 BI 대시보드는 다른 패러다임을 추구하고, 다른 목적을 가지고 있다. 그러므로 기업 내에서 이 둘을 별도로 가져가는 것이 최상이다. 일반적으로 프로세스 분석 프로젝트를 추진할 때 BI 부서는 적극적인 역할을 수행하지 않는다. 마찬가지로, 프로세스 마이닝을 추진할 때도 BI 부서는 주도적인 역할을 수행하지 않고 있다. 왜냐하면 사업부의 요구사항을 반영한 대시보드와 리포트를 설정하는 것과 프로세스 마이닝을 추진하는 것은 완전히 별개이기 때문이다. 마찬가지로 프로세스 마이닝도 이미 대부분의 기업이 도입한 대시보드 도구를 교체할 수는 없다.

 

사실, 프로세스 마이닝 도구와 BI 대시보드는 상호보완적으로 사용될 수 있다. 예를 들어, 만약 새로운 모니터링 환경의 설정을 원한다면 여러분은 프로세스 마이닝을 이용해서 미래에 어떤 KPI들이 모니터링 되어야 하고, 측정 지점은 프로세스의 어떤 곳에 위치해야 하는가에 대한 귀중한 정보를 얻을 수 있다. 또는 이미 BI 도구를 사용하고 있다면 여러분은 일부 KPI의 임계값이 적절하지 않은 상황에 직면할 수도 있다. 이러한 문제의 근본원인은 BI 도구가 아니라 프로세스에서 확인될 수 있다. 프로세스 마이닝 분석을 통해 여러분은 대상 프로세스를 자세히 조사할 수 있고, 잘못된 것을 발견할 수 있다.

 

 

프로세스 모델링 도구가 아님

 

BPM 전문가는 전통적 워크숍과 인터뷰에서 수행된 수작업 프로세스 맵핑(mapping)을 종종 ‘프로세스 발견(discovery)’이라고 언급해 왔다. 그런데 정보시스템에 축적된 트랜잭션 데이터에서 프로세스를 자동으로 구성하는 것도 프로세스 마이닝 분야에서는 ‘프로세스 발견’이라고 언급된다. 이런 이유로 프로세스 마이닝을 배운 사람들은 두 가지 의미로 사용되는 ‘프로세스 발견’이라는 용어를 다소 혼란스러워했다. 이러한 혼란을 피하기 위해 일부 사람들이 얼마 동안 프로세스 마이닝 분야의 ‘프로세스 발견’을 ‘자동화된(automated) 프로세스 발견’이라고 언급했다. 그러나 이 용어는 유행하지 않았고, 이제 ‘자동화된 프로세스 발견’이라는 의미를 포함하고 있는 프로세스 마이닝이라는 용어 자체가 대부분의 경우에 사용되고 있다.

 

프로세스 마이닝은 정보시스템의 트랜잭션 데이터를 활용하여 프로세스 맵을 자동으로 만든다. 이에 반해, 프로세스 모델링 도구의 프로세스 맵은 수작업으로 그려진다. 그러므로 프로세스 마이닝과 프로세스 모델링을 사용하는 목적은 다를 수밖에 없다. 프로세스 모델링 도구를 이용하면 인지된 현재(As-is) 프로세스가 기술되고, 문서화된다. 이러한 문서화를 통해 프로세스에 관한 다양한 차원들이 포착되고 저장된다. 예를 들어, 스윔레인(swimlane) 다이어그램을 통해 프로세스 수행에 관여하는 조직 단위들의 책임과 경계가 표시된다. 분기 지점에서의 의사결정 논리가 비즈니스 규칙을 통해서 포착된다. 종종 문서화된 프로세스는 포털을 통해서 회사 전체에 발표되고 공유된다. 결국 프로세스 모델링의 목표는 조직 내 프로세스에 대한 맵핑을 통해 공유된 이해를 형성하는 것이다.

 

수작업으로 작성된 프로세스 모델은 대상 프로세스의 전형적인 업무수행을 나타내는 참조모델이 된다. 이러한 참조모델은 신입 직원에게 어떤 방식으로 업무가 수행되어야 하는가를 설명할 때 유용하게 활용될 수 있다. 이에 반해, 프로세스 마이닝은 IT 시스템의 로그 데이터를 기반으로 실제로 발생한 것을 반영한 프로세스 모델(맵)을 발견한다. 거의 대부분의 경우에 프로세스 마이닝이 발견한 프로세스 모델은 수작업 프로세스 모델링에서 작성한 프로세스 모델보다 훨씬 더 복잡하다. 프로세스 마이닝을 활용해서 여러분은 매우 구체적인 것과 실제 프로세스에서 발생한 모든 사소한 예외를 볼 수 있다. 프로세스 마이닝에서 발견된 모델을 통해 여러분은 실제 업무를 수행할 때는 생각했던 것보다 훨씬 더 많은 자유와 융통성이 허락된다는 것을 알게 될 것이다. 사실, 이러한 자유와 융통성이 반드시 나쁜 것은 아니다. 예를 들어, 많은 서비스 프로세스는 업무 수행자의 전문지식을 요구한다. 그러므로 일이 제대로 처리되기 위해서는 정해진 업무처리 방식에 맞추도록 강요하는 것보다 업무 수행자가 자유와 융통성을 가지는 것이 나을 수 있다. 프로세스 마이닝의 목적은 복잡한 실세계 프로세스를 문서화하는 것이 아니라, 이해하는 것이다. 여러분은 프로세스 마이닝을 통해서 복잡한 프로세스를 검토하고 점진적으로 분해할 수 있을 것이다. 실제의 프로세스 현실을 바라봄으로써 여러분은 진행되었던 것을 이해하고, 개선 가능성을 높이고, 컴플라이언스 문제를 해결할 수 있다.

 

프로세스 마이닝과 프로세스 모델링도 상호보완적일 수 있다. 문서화된 프로세스 맵은 일반적으로 모든 사소한 예외를 다루지 않으나, 프로세스가 어떻게 수행되기를 기대하는가에 대한 귀중한 정보를 제공한다. 만약 프로세스를 문서화하지 않은 여러분의 조직이 프로세스의 문서화를 원한다면 여러분은 먼저 프로세스 마이닝에서 발견된 (복잡한) 프로세스를 분석하고, 원하는 수준까지 단순화할 수 있다. 그런 다음에 단순화된 프로세스의 모델을 (이미지 또는 XML 형식의) 파일로 내보낼 수 있다. 여러분은 이 파일을 프로세스 모델링 환경에서 읽어 들이고, 프로세스에 관한 다른 차원의 추가 정보를 함께 저장함으로써 문서화를 완료할 수 있다.

 

 

새로운 개선 방법론이 아님

 

프로세스 마이닝 프로젝트 수행에 활용될 수 있는 다수의 방법론이 제안되었다. 여러분은 프로세스 마이닝 프로젝트의 성공적인 수행에 요구되는 기본 개념과 중요 단계, 단계별 산출물을 제안된 방법론에서 참조할 수 있다. 예를 들어, 프로세스 마이닝 프로젝트 방법론을 통해 데이터 품질 문제를 발견하는 방법과 프로세스 마이닝 분석 결과를 해석하는 방법, 어떤 분석 목표와 질문들로 시작해야 하는가를 참조할 수 있다. 그러나 여러분이 이미 채택하고 있는 어떠한 프로세스 개선 방법론도 프로세스 마이닝(또는 프로세스 마이닝 프로젝트 방법론)에 의해 대체될 수는 없다.

 

프로세스 마이닝은 다양한 사용 사례를 갖는다. 각 사용 사례는 자체의 방법론에 기반을 둔 절차, 기법, 도구를 가질 수 있다. 예를 들어, 실무전문가는 린 6시그마나 BPR/ISP 프로젝트를 수행하기 위해 DMAIC[1] 방법론이나 BPR/ISP 방법론을 활용한다. 이러한 핵심 방법론을 통해 실무전문가는 예비 개선 아이디어들의 우선순위를 정하는 방법과 변화에 대한 저항을 극복하는 방법, 프로세스 개선을 실제로 구현하는 방법을 결정한다. 앞에서 강조한 것처럼, 프로세스 마이닝은 이러한 방법론을 대체할 수 없다. 대신에 프로세스 마이닝은 퍼즐의 한 조각처럼 이러한 방법론에 꼭 들어맞을 수 있다. 이런 이유로 프로세스 마이닝을 활용하여 관련 프로젝트를 수행할 때 프로세스 마이닝 전문가와 함께 관련 실무전문가도 프로젝트팀에 참여하는 것이 매우 중요하다.

프로세스 마이닝과 기존 프로세스 개선 방법론도 상호보완적일 수 있다. 예를 들어, 프로세스 마이닝을 활용하면 현재(As-is) 프로세스에 대한 분석을 더욱 구체적이고 객관적으로 수행할 수 있다. 이런 이유로 유럽의 많은 조직이 린 6시그마 방법론인 DMAIC 방법론과 프로세스 마이닝을 연계하여 관련 프로젝트를 수행하고 있다. 프로세스 마이닝을 기업에 성공적으로 도입하기 위해 여러분은 자사에 맞는 사용 사례와 현재 사용 중인 관련 방법론을 검토하고, 프로세스 마이닝이 이러한 방법론에 어떻게 들어맞을 수 있는가를 고심해야 한다.

 

 

IT 프로젝트를 필요로 하지 않음

 

BI 대시보드 구축도 일종의 IT 프로젝트이다. IT 부서의 컨피규레이터(configurator)는 사용자들이 매일 보기를 원하는 뷰(view)를 설정한다. 이때, 기반 프로세스(underlying process)와 관련된 핵심성과지표의 값이 설정된 뷰를 통해 제시된다. 결국 기반 프로세스는 이러한 핵심성과지표를 통해 고정되고 제한된 방식으로 BI 대시보드와 연결되는 것이다. 한편, 뷰를 설정할 때 데이터와 기반 프로세스에 대한 구체적인 이해를 요구하는 수많은 의사결정이 이루어진다. 적절한 의사결정을 위해 컨피규레이터(configurator)는 사용자의 도메인 지식에 의존해야 한다. 반대로, 설정된 뷰를 벗어나서 기반 프로세스를 바라보려는 사용자는 컨피규레이터에 의존해야 한다. 그러나 사용자가 Disco와 같은 프로세스 마이닝 도구를 이용하면 컨피규레이터에 의존할 필요가 없어진다. IT 부서가 추출하고 전처리한 데이터를 받자마자 사용자는 어떤 프로그래밍 기술이나 IT 지식이 없어도 프로세스 분석을 즉시 시작할 수 있다. 심지어 사용자는 해당 프로세스를 다양한 관점에서 바라볼 수 있다.

 

프로세스 마이닝은 IT 프로젝트가 아니다. 이것은 또한 구매된 도구(즉, 프로그램)가 설치되거나 구현된 후에 스스로 작동하면서 리포트를 만들어내는 것이 아니다. 대신에 프로세스 마이닝은 관련 지식과 경험 축적을 요구하는 일종의 전문분야(discipline)이다. 프로세스 마이닝 분석 결과를 해석하고, 적절한 개선안을 제안하고, 발견된 통찰력을 가지고 실제적인 무엇인가를 추진하기 위해 여러분은 적절한 인력들을 구성해야 한다. 물론 프로세스 마이닝 수행의 결과로 IT 프로젝트가 시작될 수 있다. 예를 들어, 여러분은 반복 분석을 위한 데이터 준비와 전처리를 위해 ETL(Extract, Transform, Load) 루틴을 구현할 수도 있다. 프로세스 마이닝 동안 발견된 데이터 품질 문제를 처리하기 위해 데이터웨어하우스 인프라를 개선할 수도 있다. 또는 여러분의 모니터링 환경에 새로운 핵심성과지표를 추가할 수도 있다. 그러나 다시 한 번 강조하는 것은 프로세스 마이닝 자체는 IT 부서가 전적으로 책임져야 하는 IT 프로젝트가 아니라는 것이다. IT 부서가 추출하고 전처리한 데이터를 제공하면 여러분은 프로세스 마이닝을 시작할 수 있다.

 

 

데이터 마이닝, 인공지능, 또는 머신러닝 도구가 아님

 

프로세스 마이닝이라는 이름 때문에 사람들은 종종 프로세스 마이닝이 데이터 마이닝 분야의 일부라고 생각한다. 물론 이런 식으로 프로세스 마이닝을 볼 수도 있다. 그러나 역사적으로 프로세스 마이닝은 데이터 마이닝 연구분야의 일부가 아니었다. 대신에 프로세스 마이닝은 BPM 연구분야에서 시작되었다. 그러므로 전통적인 데이터 마이닝과 통계 도구는 프로세스 마이닝 기법들을 제공하지 않는다. 일부 데이터 마이닝과 머신러닝 접근법(예, 순차 패턴 마이닝)이 프로세스 패턴을 분석한다. 그러나 이들은 종단간(end-to-end) 프로세스 발견을 제공하지 않는다. 프로세스 마이닝 도구도 여러분의 기업이 이미 사용하고 있는 데이터 마이닝 도구를 대체할 수는 없다.

 

데이터 마이닝 적용은 올바른 알고리즘을 선택하고, 매개변수를 조정하고, 특정 문제에 대한 모델을 학습할 수 있는 전문가를 필요로 한다. 이에 반해, 프로세스 마이닝은 데이터과학 분야의 학위가 없는 프로세스 실무자가 배우고 성공적으로 사용할 수 있는 접근법이다.

 

프로세스 마이닝과 데이터 마이닝도 상호보완적이며 함께 사용될 수 있다. 예를 들어, 만약 여러분의 데이터셋이 직원이 기입한 임의의 메모나 코멘트를 포함하는 비구조화된 텍스트 필드를 포함하고 있다면 이 필드는 프로세스 마이닝 분석을 위한 액티비티 이름으로 사용될 수 없다. 이 필드에서 공통된 액티비티 이름들을 발견하기 위해 여러분은 전처리 단계에서 텍스트 마이닝 도구를 사용할 수 있다. 이와 함께, 프로세스 문제를 발견하고 시각화하기 위해 프로세스 마이닝을 적용한 후에 여러분은 예측을 하거나 분기 지점을 설명하는 원인변수를 찾기 위해 의사결정나무와 같은 데이터 마이닝 알고리즘을 이용할 수도 있다. 마지막으로, 최근에 딥러닝의 순환신경망(RNN: Recurrent Neural Network)과 프로세스 마이닝을 결합하여 프로세스의 행동을 예측하려는 시도가 진행되고 있다.

 

 

시뮬레이션 도구가 아님

 

프로세스 애니메이션을 본 사람들은 가끔 프로세스 마이닝과 시뮬레이션을 혼동한다. 많은 프로세스 모델링과 시뮬레이션 도구들은 (작성된) 프로세스 모델에 기반을 두고 프로세스 흐름을 시각화하는 “플레이 아웃(play out)” 기능을 가지고 있다. 이 기능이 프로세스 애니메이션과 유사해 보이는 것이다. 그러나 프로세스 마이닝의 애니메이션은 발생했던 실제 프로세스를 재생하는 것이다. 그러므로 이 둘은 완전히 다른 것이다.

 

실세계에서 프로세스 개선 대안들의 구현을 위해 많은 돈을 투자하기 전에 여러분은 시뮬레이션 환경에서 이들을 테스트하길 원할 것이다. 이때, 여러분은 수작업으로 만들어진 모델에 기반을 두고 시뮬레이션 도구를 활용해서 다양한 ‘what-if’ 시나리오들을 검증한다. 시뮬레이션을 성공적으로 수행하기 위해 실세계를 반영하는 좋은 모델을 가질 필요가 있다. 만약 그렇지 않다면 시뮬레이션에서 수행하는 모든 분석들이 쓸모 없게 된다. 그러나 처음에 활용될 수 있는 좋은 모델을 만들어내는 것이 매우 어렵다. 수십 년 동안 활용 가능한 상업용 시뮬레이션 도구가 늘었음에도 불구하고 좋은 모델을 만들어내는 것의 어려움 때문에 시뮬레이션 결과를 완전히 신뢰할 수가 없다. 그러므로 시뮬레이션 결과에만 의존하여 대안을 선정하고 투자결정을 하는 것은 현명하지 못한 방법일 수 있다.

 

프로세스 마이닝은 데이터에서 시작하고, 시뮬레이션은 모델에서 시작한다. 이런 차이 때문에 프로세스 마이닝은 두 가지 측면에서 시뮬레이션보다 장점을 가질 수 있다.

  1. 모델의 타당성이 시뮬레이션의 유용성을 결정한다. 만약 프로세스 행동에 영향을 줄 수 있는 모든 요인을 파악하여 모델에 반영한다면 시뮬레이션 결과가 매우 유용할 수 있다. 단순하고 안정적인 프로세스의 경우에는 이것이 가능할 수 있다. 그러나 복잡한 프로세스의 경우에는 모든 요인을 파악하여 반영하는 것이 거의 불가능에 가깝다. 프로세스 마이닝을 활용하면 여러분은 사실을 담은 데이터를 기반으로 병목과 문제점을 관찰하고 조사할 수 있다. 예를 들어, 다음과 같은 질문에 대한 답을 찾아 모델에 반영할 수 있다. “특정 액티비티 이전에 일이 항상 쌓이는 이유는 무엇일까?” 이 문제에 대한 근본원인은 인센티브 구조나 인사 문제, 날씨, 잘못 선정된 성과지표 등에서 기인할 수 있다. 프로세스 마이닝에서 밝혀진 근본원인과 관련된 요인을 시뮬레이션을 위한 모델에 반영할 수 있다.
  1. 일반적으로 프로세스의 모든 측면을 단일 모델에 포착하는 것보다 각 측면을 별도로 포착하는 것이 더욱 쉽고 효과적일 수 있다. 그러나 시뮬레이션은 프로세스의 모든 측면이 단일 모델에 포착되기를 요구한다. 이러한 요구사항은 시뮬레이션 모델의 복잡성을 크게 증가시킨다. 이에 반해, 프로세스 마이닝을 활용하면 여러분은 프로세스의 다양한 측면(예, 프로세스 흐름, 데이터 흐름, 조직 단위간 업무 흐름 등)과 관련된 개별 프로세스 모델과 통찰력을 발견할 수 있다. 또한 프로세스 마이닝에서 발견된 개별 모델은 문제를 잘 이해하고 해결할 수 있을 만큼 구체적일 수 있다.

 

앞에서 강조한 것처럼, 프로세스 마이닝은 시뮬레이션을 보완할 수 있다. 먼저, 여러분은 프로세스 마이닝을 적용해 실제의 프로세스 흐름을 반영한 모델을 발견하고, 이를 시뮬레이션 도구의 기본 모델로 활용할 수 있다. 그런 다음에 프로세스 마이닝에서 도출된 사실 정보에 근거해서 시뮬레이션 모델의 매개변수 값(수행시간, 대기시간, 활용률, 새로운 케이스의 분포)을 채워나갈 수 있다. 프로세스 마이닝이 시뮬레이션에 제공할 수 있는 장점에도 불구하고, 인간과 기계의 행동을 모델링하고 시뮬레이션하는 것은 여전히 어려운 과제임을 명심할 필요가 있다.

 

 

단지 일부 프로세스나 IT 시스템만을 위한 것이 아님

 

프로세스 마이닝은 IT 시스템에 기반을 둔 어떤 프로세스(케이스 아이디, 액티비티 이름, 타임스탬프 정보가 해당 IT 시스템에서 발견되어야 함)에도 적용할 수 있다. 이것은 프로세스 마이닝의 엄청난 장점이다. 가끔 사람들은 프로세스가 상당히 표준화된 BPM이나 ERP 시스템 분석에만 프로세스 마이닝을 활용할 수 있다고 생각한다. 이런 생각은 잘못된 것이다. 특히 프로세스 마이닝은 레거시 시스템이나 웹사이트 기반의 클릭 스트림과 같은 프로세스 지향적이지 않은 시스템의 분석에도 활용될 수 있다.

 

사실, 프로세스 마이닝은 다음과 같은 유형의 IT 시스템에서 도출된 데이터를 분석했다. 예를 들어, 워크플로우 시스템, ITSM(IT Service Management) 시스템, CRM 시스템, ERP 시스템, 제조실행시스템(MES: Manufacturing Execution System), PLM(Product Lifecycle Management) 시스템, BPM 시스템, 창고관리시스템(WMS: Warehouse Management System), 주문 제작된 레거시 시스템, 웹사이트나 모바일앱의 클릭스트림, API 호출을 기록한 시스템 로그, 데이터웨어하우스 등의 데이터가 분석되었다. 심지어 엑셀에 기록되어 있거나 바코드 스캔을 통해 수작업으로 수집된 데이터도 프로세스 마이닝을 활용해서 분석될 수 있다.

 

일반적으로, IT 시스템 자체가 미리 만들어진 “로그 파일” 형태로 프로세스 마이닝에 활용되는 입력 데이터를 제공하는 것은 아니다. 대신에 여러분은 IT 부서나 전문기업에게 데이터 추출을 요청해야만 한다. 어떤 경우에는 프로세스 마이닝에 즉각적으로 활용될 수 있는 형식의 데이터를 받을 수 있다. 그러나 많은 경우에는 데이터 준비를 위한 추가적인 노력이 요구된다. 그러나 중요한 것은 프로세스 마이닝 데이터를 찾기만 하면 주변의 많은 곳에서 이러한 데이터를 발견할 수 있을 것이다. 또한 특정 시스템에서 데이터를 추출하고 전처리하는 체계를 확립하면 이후에는 추가적인 노력을 들이지 않고 프로세스 마이닝 분석을 수행할 수 있을 것이다.

 

 

마법의 해결책이 아님

 

새로운 접근법(예, 6시그마)이나 기술(예, ERP)이 나오고 이에 대한 과대 선전이 있을 때마다 관련된 사람들은 해당 접근법이나 기술이 할 수 있는 것을 과장하는 경향이 있다. 프로세스 마이닝을 처음에 본 일부 사람들은 이 기술이 마술 같다고 생각했다. 약간의 데이터를 가져오면 프로세스 마이닝은 마술처럼 프로세스 맵을 구성한다. 이것은 대단한 일이다. 그러나 프로젝트 수행을 위해 프로세스 마이닝의 한계를 이해하고, 다른 사람에게 프로세스 마이닝을 설명할 때 그들의 기대를 관리하는 것도 중요하다. 일반적으로 비현실적 기대는 프로세스 마이닝의 두 가지 측면에서 발생한다.

 

  1. 입력측: 프로세스 마이닝은 분석에 요구되는 데이터를 IT 시스템에서 자동으로 식별하고 수집할 수는 없다. 가끔 사람들은 프로세스 마이닝이 IT 시스템을 “크롤링”하여 지원되는 모든 프로세스와 이러한 프로세스의 수행과 관련된 모든 데이터를 자동으로 찾을 것이라고 생각한다. 그러나 이것은 프로세스 마이닝 자체의 역할이 아니다. 올바른 방법으로 데이터를 추출하려면 분석 대상 프로세스와 이를 지원하는 IT 시스템에 대한 이해가 필요하다. 일반적으로 프로세스 마이닝 분석을 수행하기 위해서는 다음과 같은 두 단계가 필요하다. 첫 번째는 데이터 추출과 준비 단계이다. 두 번째는 데이터 분석 단계이다. 프로세스 마이닝 도구는 두 번째 단계만을 지원한다.

 

  1. 출력측: 프로세스 마이닝은 분석 대상 프로세스를 위한 개선안과 해결책을 자동으로 파악하고 제안할 수 없다. 프로세스 마이닝 결과를 올바르게 해석하기 위해서는 프로세스에 대한 이해와 도메인 지식이 요구된다. 이런 이유로 프로세스 마이닝 자체가 개선안과 해결책을 파악하고 제안하는 것이 불가능하다. 예를 들어, 프로세스의 반복 패턴이 과도한 재작업을 나타낼 때고 있고, 좋은 것일 수도 있고, 아무런 의미가 없는 것일 수도 있다. 프로세스 마이닝 자체는 이러한 반복 패턴의 명확한 의미를 파악할 수 없다. 프로세스에 대한 이해와 도메인 지식을 가진 프로세스 마이닝 분석가나 이해관계자만이 발견한 반복 패턴의 의미를 파악하고, 적절한 개선방안을 제안할 수 있다. 최근에 주목 받고 있는 인공지능 알고리즘이 이러한 결정을 내릴 수 있다고 생각하는 것은 환상이다. 프로세스 마이닝을 조직에 성공적으로 도입하기 위해서는 이 기술이 할 수 있는 것과 할 수 없는 것에 대한 명확한 이해를 확립해 나가는 것이 매우 중요하다.

 

 

[1] DMAIC: 정의(Define), 측정(Measure), 분석(Analyze), 개선(Improve), 통제(Control)

 

 

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