RPA vs. BPM: 하나의 목표, 2 개의 솔루션
RPA vs. BPM: One Goal, Two Solutions <원본>
"로봇 프로세스 자동화(RPA)는 정말 새로운 것인가? 라는 질문을 많이받는다. 완전히 혁신적인 기술을 찾고 있었다면 너무 기대하지는 마라. RPA의 뿌리는 소프트웨어 로봇의 발전 속에서 찾을 수 있다. 따라서 RPA는 이것의 조상 또는 사촌인 비즈니스 프로세스 관리와 닮아 있을지도 모른다.
BPM (가끔 "비즈니스 프로세스 자동화"와 혼용됨)은 특정 소프트웨어가 아닌 비즈니스 프로세스를 간소화하고 효율성과 가치를 극대화하는 방법이다. 프로세스가 어떻게 작동되고 있는지, 개선 분야는 어디인지 파악하고, 솔루션을 처음부터 끝까지 구축하기 위한 방법을 상세하게 검토한다. BPM은 비즈니스 프로세스의 인프라가 견고하다는 것을 확인하는 것이다.
반면 RPA는 인간처럼 프로세스를 조작하기 위해 설계되었기 때문에 좀더 표면적인 레벨(UI 같은)에 존재한다고 할 수 있다. 구현이 좀 더 빠르고 모든 소프트웨어에서 바로 사용할 수 있으며, 변화하는 세계에 적응하도록 쉽게 변경하거나 업데이트가 가능하다.
우리가 보기에는 RPA와 BPM은 서로 상충되지 않는다. 서로 다른 구현 전략을 가지고 같은 목표를 달성하고자 하는 것이다. 이전에 사람에 의해 처리되던 빈도 높은 프로세스를 처리하기 위해 RPA를 사용하는 동안 실제로 필요한 것은 워크 플로우에 대한 정밀 검사 정도이다. 예를 들어, 특정 유형의 트랜잭션이 조직의 서비스의 핵심 요소 인 경우, 프로세스가 가능한 긴밀하고 효율적이고 독립적임을 확인해야한다. 표면 수준의 수정에 의지하는 것이 아니라 프로세스 자체를 변환해야하는 경우가 있는데 이럴 때 BPM을 사용하는 것이 적당하다.
물론, 우리 모두는 비즈니스 구조를 변화시키는 것이 항상 실현 가능한 것은 아니라는 것을 알고 있다. 이런경우 많은 개발과 많은 투자 (시간과 돈)가 필요하다는 것도 알고 있다. 처음부터 끝까지 구축할 만큼 당신은 여유롭지 않을 것이다. 이럴 때 RPA가 가장 적합한 솔루션일 수 있다. 최소한 RPA를 사용하여 작업을 계속하는 동안 좀더 깊게 수정을 검토할 수 있는 시간을 벌수 있다 .
Self-driving cars에 비유한다면: RPA의 접근은 인간처럼 기존의 자동차를 조종하려고 하는 한편, BPM 접근법은 모든 포장 된 도로를 철거하고 신차가 자력으로 이동하기위한 인프라를 설치해야 한다는 것이다. 모든 도로 (특히 미국)를 대체 할 이상적인 솔루션이 없기 때문에 Google은 RPA의 관점에서 문제에 접근하고 있는 것이다. 그렇다고해서 RPA가 항상 더 나은 선택 일 수는 없다. 전혀 그렇지 않다. 핵심은 차이점을 파악하고 두 가지 전략을 최대한 활용하는 것이라고 할 수 있다.
"로봇 프로세스 자동화(RPA)는 정말 새로운 것인가? 라는 질문을 많이받는다. 완전히 혁신적인 기술을 찾고 있었다면 너무 기대하지는 마라. RPA의 뿌리는 소프트웨어 로봇의 발전 속에서 찾을 수 있다. 따라서 RPA는 이것의 조상 또는 사촌인 비즈니스 프로세스 관리와 닮아 있을지도 모른다.BPM (가끔 "비즈니스 프로세스 자동화"와 혼용됨)은 특정 소프트웨어가 아닌 비즈니스 프로세스를 간소화하고 효율성과 가치를 극대화하는 방법이다. 프로세스가 어떻게 작동되고 있는지, 개선 분야는 어디인지 파악하고, 솔루션을 처음부터 끝까지 구축하기 위한 방법을 상세하게 검토한다. BPM은 비즈니스 프로세스의 인프라가 견고하다는 것을 확인하는 것이다.
반면 RPA는 인간처럼 프로세스를 조작하기 위해 설계되었기 때문에 좀더 표면적인 레벨(UI 같은)에 존재한다고 할 수 있다. 구현이 좀 더 빠르고 모든 소프트웨어에서 바로 사용할 수 있으며, 변화하는 세계에 적응하도록 쉽게 변경하거나 업데이트가 가능하다.
우리가 보기에는 RPA와 BPM은 서로 상충되지 않는다. 서로 다른 구현 전략을 가지고 같은 목표를 달성하고자 하는 것이다. 이전에 사람에 의해 처리되던 빈도 높은 프로세스를 처리하기 위해 RPA를 사용하는 동안 실제로 필요한 것은 워크 플로우에 대한 정밀 검사 정도이다. 예를 들어, 특정 유형의 트랜잭션이 조직의 서비스의 핵심 요소 인 경우, 프로세스가 가능한 긴밀하고 효율적이고 독립적임을 확인해야한다. 표면 수준의 수정에 의지하는 것이 아니라 프로세스 자체를 변환해야하는 경우가 있는데 이럴 때 BPM을 사용하는 것이 적당하다.
물론, 우리 모두는 비즈니스 구조를 변화시키는 것이 항상 실현 가능한 것은 아니라는 것을 알고 있다. 이런경우 많은 개발과 많은 투자 (시간과 돈)가 필요하다는 것도 알고 있다. 처음부터 끝까지 구축할 만큼 당신은 여유롭지 않을 것이다. 이럴 때 RPA가 가장 적합한 솔루션일 수 있다. 최소한 RPA를 사용하여 작업을 계속하는 동안 좀더 깊게 수정을 검토할 수 있는 시간을 벌수 있다 .
Self-driving cars에 비유한다면: RPA의 접근은 인간처럼 기존의 자동차를 조종하려고 하는 한편, BPM 접근법은 모든 포장 된 도로를 철거하고 신차가 자력으로 이동하기위한 인프라를 설치해야 한다는 것이다. 모든 도로 (특히 미국)를 대체 할 이상적인 솔루션이 없기 때문에 Google은 RPA의 관점에서 문제에 접근하고 있는 것이다. 그렇다고해서 RPA가 항상 더 나은 선택 일 수는 없다. 전혀 그렇지 않다. 핵심은 차이점을 파악하고 두 가지 전략을 최대한 활용하는 것이라고 할 수 있다.
댓글
댓글 쓰기