비즈니스 인사이트는 기업의 혁신 기법 및 사례를 분석하고 미래의 사회변화상과 트렌드를 제시합니다.
▲ 글. 정성철 대표
(주)동아엑스퍼츠
생각보다 RPA TCO가 높다?
RPA란 Robotic Process Automation의 약자로 물리적 로봇이 아닌 소프트웨어 로봇이 자동으로 사람의 업무를 대신해 주는 것으로 표현할 수 있다.
RPA는 사람의 업무를 도와주는 매크로보다 훨씬 고도화된 방식의 소프트웨어다.
대기업을 중심으로 RPA를 도입하지 않는 회사를 찾기 어려울 정도로 일반적이다.
그러나 최근 RPA가 안정화된 이후에 “RPA 도입이 필요한가?”에서 “생각보다 RPA의 유지 관리 비용이 높다”로 화제가 바뀌고 있다.
RPA 도입 전 RPA Vendor에서는 업무 담당자가 쉽게 설계와 구축이 가능하다고 했지만, 실제로 핸들링하기가 쉽지 않아 외부 개발사에 의존할 수밖에 없었다.
시스템 운영 또한 개발사가 담당하고 있다.
기업에 청구되는 비용은 시스템 구축비용 외에도 운영 단계에서 솔루션의 연간 사용료와 유지보수 비용이 있다.
연간 솔루션과 유지보수 비용만 해도 1,500만 원이 넘는다.
도입 시에는 크게 느껴지지 않았던 연간 RPA 솔루션 비용이 도입 영역을 확대하다 보니 결코 무시 못할 수준이 된 것이다.
왜 이런 문제가 생기나?
RPA 도입 시 주요 의사결정 주체는 회사마다 명칭은 다를 수 있으나 일반적으로 디지털 트랜스포메이션 조직 또는 정보전략 조직이 되겠다.
이는 회사의 디지털 방향성을 정하고 추진하는 조직이지만 실제 회사의 코어 프로세스를 담당하는 조직은 아니다.
따라서 연구개발, 구매, 품질, 마케팅, 영업, CS 관리 조직 등의 니즈를 파악한 후 그에 적합한 솔루션을 채택하는 것이 일반적이다.
또한 이러한 과정을 객관화하기 위해 RPA Vendor와 벤치마크 테스트(이하 BMT)를 진행한다.
BMT 대상 솔루션은 대부분 가트너, 포레스트 등에서 상위 랭크된 벤더사를 대상으로 하는 것이 일반적이다.
국내에서는 UiPath, AutomationAnywhere, BluePrism, Softomotive가 있다.
BMT 과제 선정 시 회사에서 많이 사용하는 시스템뿐만 아니라 난이도가 높은 시스템도 포함하여 진행한다.
단일 업종 회사 관점에서 솔루션을 선정할 경우 그나마 선정 과정이 용이하지만, 여러 업종이 모여 있거나 그룹사의 경우 여러 가지 시스템을 모두 반영할 수 있는 솔루션을 선정한다.
이런 연유로 도입 초기에는 가격보다 기능적인 측면에서 도입하는 것이 일반적이다.
여러 조직의 니즈를 반영하고 실제 도입할 영역이 명확하지 않아 고비용 구조의 고사양 시스템을 채택할 수밖에 없는 구조가 되기 때문에 실제로 채택하고 나면 생각보다 비용 대비 효용성이 떨어진다는 이슈가 발생하는 것이다.
그러나 저비용이나 기술적으로 낮은 시스템을 도입할 경우 RPA로 구현하지 못하는 프로세스가 발생할 수도 있다.
왜 RPA를 Single Vendor로만 도입하는가?
이러한 RPA 도입 딜레마는 한 가지 RPA 솔루션을 채택한 것이 주요 원인 중 하나라 판단된다.
하지만 한가지 RPA 솔루션을 채택하여 전 그룹사의 전 프로세스에 적용하는 것이 맞는지는 생각해볼 필요가 있다.
우선 프로세스마다 명확한 특성이 존재한다.
예를 들어 주기적으로 고객에게 정해진 콘텐츠를 이메일로 보낸다든지, 반복적으로 엑셀을 편집하여 공유하는 업무 등은 기술적 난이도가 높지 않은 부분이며 대부분의 RPA 솔루션에서 안정적으로 처리된다.
즉 Class 1에서 제공하는 RPA는 대용량 데이터 처리 역량 등의 차별성을 제외하고는 대부분 유사한 성능을 제공한다.
그러나 OCR과 M/L, NLP 등과 연계하여 Cognitive RPA를 적용하는 부분은 어느 정도 기술적 난이도와 장기적인 로드맵이 필요하다.
그러나 앞서 언급한 두가지 업무에 동일한 솔루션을 적용할 필요가 있을지 또한 생각해볼 필요가 있다.
현재 기술적 성숙도를 봤을 때 한동안은 아르바이트 직원에게 단순 업무를 맡겼을 때의 결과물을 기대하는 것이 적합할 것이다.
즉 Class 1 수준이 대부분의 RPA 도입 영역이 될 것이다.
그러나 아르바이트 직원에게 맡기는 업무도 레벨이 있을 것이다.
영작, 번역 및 보고서 작업을 하는 업무와 단순 사무실 정리 정도의 업무에 동일한 시급을 제공하는 것은 합리적이지도 비용 효율적이지도 않다.
고급 번역 담당에게는 시간당 만 원 이상도 가능하겠지만 단순 사무실 정리 업무에는 기본 시급이 적당하다.
현재 RPA의 비용 효율화의 이슈는 업무의 난이도와 관계없이 회사 내 표준 RPA 채택으로 인해 발생할 수밖에 없는 구조이다.
즉 고난도 작업이나 이메일, 엑셀 등과 같은 단순한 작업이나 시간당 동일한 비용이 발생하고 있는 구조이다.
한 가지 RPA Vendor가 효과적인가?
상식적으로는 업무의 난이도와 부가가치를 따져서 각기 적당한 RPA 솔루션을 쓰는 것이 비용효율적일것이다.
그러나 이 부분이 전사 차원에서 최적화된 의사결정인지 면밀히 검토해 봐야 한다.
대부분의 회사는 ERP의 경우 한 가지 솔루션을 채택하여 사용하는데 이는 데이터의 통합성이 가장 큰 이유라 생각된다.
예를 들어 ERP는 각 조직에서 데이터를 입력하면 회사 전체적으로 정보가 통합, 분석 및 보고되는 구조로 되어 있다.
따라서 ERP는 동일한 시스템과 정보를 여러 사용자가 바라보는 상황이므로 단일 솔루션 채택이 적합한 시스템이다.
그러나 RPA는 ERP, SCM 등과 같이 메가 프로세스를 대체하는 방식이 아닌 업무 담당자 개인별 업무를 자동화하는 방식이다.
따라서 개별 RPA 업무와 다른 사람의 업무가 통합되어야 하는 상황이 크게 발생하지 않는다.
시스템 통합 관점에서 단일 RPA 도입이 생각보다 파급 효과가 크지 않았다는 것이 대부분의 도입 사례이다.
물론 도입 시 서버 비용 등은 도입 Bot의 숫자가 많아질수록 Bot당 비용이 절감되는 경우가 있지만, 이 부분은 전체 비용에서 차지하는 비중이 생각보다 크지 않을 수 있다.
꼼꼼한 RPA 도입 계획이 필요하다.
RPA를 도입하고 시행착오를 거치다 보면 단일 RPA Vendor의 한계점이 명확해 보인다.
RPA를 도입한 몇몇 회사의 경우 이미 Multi-Vendor RPA 체계로 넘어가고 있다.
이런 회사 또한 처음부터 Multi-Vendor RPA를 계획하고 추진했다고 보기는 어렵다.
막상 RPA를 도입하다 보니 생각보다 난이도가 낮은 업무 위주로 시스템이 적용되는 반면 높은 연간 사용료로 인해 Multi-Vendor RPA를 시도하고 있는 것이다.
Multi-Vendor RPA 채택을 위한 업무 단계는 다음과 같다.
도입 Process 및 시스템의 기술적 난이도 평가
각 벤더사별로 RPA 기술적 로드맵을 제시하고 있지만, 안정적으로 적용 가능한 영역은 단순 자동화 영역에 한정되어 있는 것이 현실이며 통제해야 하는 시스템 또한 제한적이다.
SAP, ORALCE 등의 ERP, SCM, CRM, Marketing 시스템, MS Office, 국내 오피스, 이메일 및 자체 구축한 시스템이 대부분이다.
ERP 등 글로벌 시스템은 대부분 RPA에서 적용이 가능하나, 개발 Framework을 가지고 자체 구축한 시스템의 경우 솔루션별과 개발자별로 차이가 있을 수 있다.
시스템·프로세스와 RPA Capability Mapping Table 등을 만드는 것도 좋은 방법이다.
이미 벤더사별로 가능한 시스템과 불가능한 시스템에 대한 내부 분석이 되어 있다.
굳이 여러 벤더사에서 검증된 단순한 시스템에 고가의 RPA를 채택할 필요가 없다.
실제 개발 및 사용자 정의
대부분 RPA 솔루션사는 IT가 아닌 마케팅, 회계 담당자가 일주일 정도의 교육을 받으면 충분히 혼자 개발이 가능하다고 주장한다.
이 부분은 상당 부분 맞는 주장이나 표현상 함정이 있다.
우리가 당연하게 쓰고 있는 엑셀과 파워포인트를 익히기 위해서 사회 초년생 시절 얼마나 많은 시간을 투자했는지 생각해 보면 답은 간단하다.
RPA를 어느 수준까지 쓰기 위해서는 최소한 2~3주 정도 집중적인 학습과 교육이 필요하다.
그러나 우리가 파워포인트를 어느 정도 사용할 줄 아는 것이지 제대로 활용하려면 차원이 다른 노력이 필요한 것처럼 제대로 쓰기 위해서는 현업 담당자가 개발하는 데 한계가 있다.
따라서 실제 개발하고 유지보수할 사람이 현업 사용자인지 개발자인지가 매우 중요하다.
현업 사용자가 담당할 경우 한 가지로 벤더를 선정하는 것이 적합하고, IT 담당자가 포함될 경우 2~3가지의 멀티 벤더도 가능하다.
단일 및 복합 RPA 솔루션의 TCO 계산
해외뿐만 아니라 국내 RPA 솔루션도 대부분은 연간 사용량 개념으로 과금 된다.
따라서 적용 프로세스 및 Bot 도입 대수가 명확할 경우 상호 금액 비교가 용이하다.
단일 벤더를 채택하여 Bot을 늘려가는 케이스의 경우, Bot 서버에 대한 추가 비용이 늘지 않는다는 장점이 있다.
그러나 특정 벤더사에 프로세스가 Lock-in 되어 향후 그 벤더사의 가격 정책에 휘둘린다는 단점이 있다.
또한 특정 벤더가 상대적으로 비싼 솔루션일 경우 연 단위 사용료 또한 기업에 큰 부담으로 다가올 것이다.
따라서 재무적 측면, 향후 Lock-in 측면 등을 고려하여 복합 RPA 솔루션 채택 여부를 결정해야 한다.
체계적 Multi-RPA 관리 포털이 필요하다
Multi-Vendor RPA를 도입하기 위해서는 RPA 포털 도입이 필수적이다.
RPA 포털을 통해 Multi-Vendor에서 제공하는 Bot이 활동하는 정보를 모니터링할 수 있다.
물론 각 RPA 벤더는 별도의 모니터링 화면을 제공하고 있지만 이 경우 RPA 전체 라이프 사이클 관리 미제공, 제한된 사용자 권한 및 자사 솔루션에 대한 모니터링만 제공한다는 제한이 있다.
이러한 이슈를 해결하기 위해 특정 벤더에 종속되지 않고 통합적으로 여러 RPA 벤더를 관리할 수 있는 RPA 포털 도입의 필요성이 대두되고 있다.
과제 등록, ROI 측정 및 선정
성공적인 RPA 도입을 위한 첫 단계로 업무의 특성과 연계된 시스템이 RPA로 구현 가능해야 하며 적합한 업무여야 한다.
적합한 과제 선정을 위한 기준을 정의하고, 예상 도입 비용 등을 고려하여 ROI를 산정해야 한다.
물론 ROI가 모든 기준이 될 수는 없다. 전략적 중요도, 특정 기간의 업무 부하 정도가 추가적인 기준이 될 수 있다.
ROI가 높은 업무의 대표적인 예로 유통업에서 각 지점별로 매일 동일한 시간이 소요되는 보고 업무가 있다.
이 경우 계산상으로는 높은 ROI가 나올 수 있다.
전체 사용자 숫자 × 매일 작업 여부 × 인별 소요 시간 등을 고려할 경우 재무적으로는 우선순위가 높을 수 있다.
이런 과제는 전체 누적 절감 시간은 크지만 RPA가 도입되지 않더라도 업무 담당자가 느끼는 불편은 상대적으로 크지 않을 수 있다.
오히려 특정 부서에 특정 기간에만 업무가 집중되는 경우 RPA 도입 만족도가 더 클 수 있다.
예를 들어 분기별로 있는 지점별 부가세 신고나 지방세 신고 등이다.
이런 사례는 ROI를 계산하면 상대적으로 높지 않게 나오지만 담당자에게는 절실하며 효과 또한 크다.
Knowledge DB
타 조직 및 타 계열사에서 선정하여 개발된 과제에 대한 정보는 시행착오를 줄이는 데 많은 공헌을 한다.
유사한 과제의 경우 기존에 개발된 스크립트 등을 이용해 개발 및 검증시간을 획기적으로 단축할 수 있다.
과제 등록, ROI 측정 및 선정 단계에서 확정된 과제는 Knowledge DB로 자동 이관되게 설계할 경우 지속적인 성공 경험의 축적이 가능하다.
개발
RPA는 국내에 본격적으로 도입된 지 2~3년에 불과해 개발 측면에서 표준화가 미흡하다.
한 프로젝트 내에서도 개발자마다 개발 방식이 상이한 것이 현실이다.
이 경우 에러가 발생해도 원인 규명이 어렵고 향후 운영 단계로 넘어갈 때 운영자가 다시 개발하는 것이 더 쉬울 정도로 운영이 복잡해지는 결과를 낳는다.
포털을 통해서 모듈을 제공하여 개발을 표준화하고 방법론을 적용하여 개발의 효율성을 높일 수 있다.
RPA Monitoring
RPA 모니터링은 기능적으로 볼 때 포털의 가장 중요한 역할이다.
각 벤더별로는 별도 모니터링 기능이 있지만 해당 벤더 정보만 볼 수 있으며 이 또한 권한 등의 문제로 인해 다양한 사용자가 보기 쉽지 않다.
RPA 개발을 마치고 운영 단계로 넘어갈 경우 시스템 관리의 이해관계자는 고객사의 정보전략팀, 시스템 관리, 해당 프로세스 담당자에서부터 시스템 운영 담당자까지 다양하다.
이 경우 같은 정보를 보고 같이 상황을 이해하는 것은 매우 중요하다.
이럴 때 포털의 모니터링 화면이 그 역할을 한다.
Multi-Vendor RPA 상황의 경우 모니터링 정보는 단일 RPA 솔루션 도입 상황에 비해 반드시 필요한 정보가 될 것이다.
RPA 장애 처리 및 운영 관리
RPA 운영 관리의 가장 적합한 모습은 ERP, CRM 및 Legacy System 유지보수 사업자가 이를 같이 맡는 것이다.
그러나 RPA는 Legacy System과는 달리 고객사의 시스템 환경과 UI·UX 변경에 따른 지속적인 업데이트가 필수적이다.
타 시스템 대비 RPA는 상대적으로 불안정한 시스템임을 경험자들은 충분히 인지하고 있는 상황이다.
이런 연유로 기존 Legacy System 유지보수 사업자가 RPA 프로젝트에 대해서는 안정화될 때까지 유지보수를 보류하는 경우가 많다.
이 경우 RPA 개발 회사가 개발, 모니터링, 장애 처리 및 운영까지 연계하여 관리하는 것이 대안이 될 수 있으며 포털의 역할이 중요해진다.
RPA 교육 관리
사용자에 대한 교육은 RPA 운영과 확산을 위한 핵심적 요소이다.
ERP 등의 Legacy System은 전사적으로 프로세스를 표준화시키고 이를 시스템으로 구축하여 사용자가 여기에 맞춰 일하는 방식이었다고 한다면, RPA는 철저하게 사용자 관점에서의 맞춤형 시스템이라고 할 수 있다.
표준화가 필요하지만 전사적 표준화 관점보다 사용자의 편의성 관점의 표준화가 일반적이다.
따라서 사용자가 RPA를 이해하고 수정 사항을 반영할 수 있다면 확산과 안정화에 큰 장점이 될 수 있다.
포털을 통해 벤더사에서 제공하는 동영상 교육과 자체 오프라인 교육을 병행한다면 빠른 시간 내에 사용자의 이해도를 높일 수 있을 것이다.