업무자동화 RPA (Robotic Process Automation) 운영기 (4)_검증

지난 포스팅에선 RPA를 도입하는 이유에 대해서 알아봤다. 이번 포스팅에선 RPA를 도입하는 과정과 고려사항에 대해 이야기하겠다. 

 

 

2022.12.05 - [업무자동화(RPA)] - 업무자동화 RPA (Robotic Process Automation) 운영기 (3)_도입

업무자동화 RPA (Robotic Process Automation) 운영기 (3)_도입

 

  앞선 포스팅처럼 다양한 이유로 인해 RPA도입을 결정한 후에, RPA가 효과적인지 검증하고 솔루션을 선정하는 과정이 필요하다. 보통 PoC (Proof of Concept) 이나 BMT(Benchmark Test) 라고 불리우는데, 쉽게 말해서 이 솔루션을 회사에 도입하면 괜찮을지에 대한 테스트와 검증을 하는 것이다. RPA 와 같은 솔루션은 도입후에 실제 솔루션으로 과제까지 개발하기 때문에 한번 도입하면 락인되어 바꾸기 힘들다. 필자는 솔루션을 중간에 한 번 교체했는데 그 과정도 나중에 포스팅 하도록 하겠다.  

 

도입 과정은 이런 프로세스다. 

과제 발굴 → 효용성 검토 → 솔루션 및 파트너사 조사 → PoC 테스트 진행 → 도입

 

STEP 1. 과제 발굴 

 첫 발걸음은 RPA를 적용할 과제를 발굴하는 것이다. 회사내 다른 부서의 업무를 어렴풋이 알고 있으면 '아 어느 부서에서 수작업(개고생) 하지...' 하고는 감이 오겠지만, 내가 모르는 업무들도 수면 밑에서 엄청난 수작업으로 이뤄지고 있기 때문에 가급적 많은 부서 다양한 인원들을 인터뷰하는 것이 좋다. 실제 전체 부서를 순회하면서 RPA에 대한 개괄적인 설명을 하며 일종의 내부 '기술 영업'을 하는데 10개, 20개 팀을 돌아다니며 같은 말을 하고 취합을 반복하는게 고된 과정이기도 하다.

  굳이 힘들이지 않고 '회사 포탈에 공지하고 그룹웨어 메일로 취합받는게 좋지 않아??' 라고 묻는다면 대답은 '해봤지만 발굴이 안된다' 이다. 기업 분위기마다 조금씩 다르겠지만, 세금 징수하듯이 과제를 취합하면 잘 들어오지 않는다. 직접 대면하고 '여러분의 업무를 도와드립니다' 라는 톤으로 설득해야 그때서야 한명씩 입을 열면서 본인이 하고 있는 업무중 수작업으로 하는 업무 들에 대해서 토로하기 시작한다. 주의할 점이 있다면, 일을 제일 많이 하는 막내들은 흡사 본인의 업무를 제안하면 '일을 하기 싫어하는 신입'으로 보일까봐 입을 열지 않는다는 것이다. 실무를 많이 아는 중간관리자를 타게팅해야, '후배를 위해 이런 제안도 했습니다' 라며 그들의 면을 살려줌과 동시에 다양한 과제를 발굴 할 수 있다. 

  보통 취합되는 과제의 분류는 두 가지다. 수작업으로 이미 하고있는 기존 업무와, 엄두가 나지 않아 못하고 있는 신규 업무다. 경험상 후자 과제는 오래 운영되지 못하고 사라졌다. 막상 자동화가 되어도 현업에서 잘 사용을 하지 않기 때문이다. 

 

STEP 2. 효용성 검토 

  효용성이라고해서 거창한 건 아니고, 도입했을때 어느정도 효과가 있는가를 생각해보는 것이다. 보통 윗 어른신들 설득을 위해 만들어지기 때문에 여러가지 명분들이 더 붙혀 몸집을 키우기도 한다. 효용성은 주로 정성적 지표와 정량적 항목으로 나뉘어 진다. 

 첫번째로, 정량적 지표다. RPA를 도입함으로써 얼만큼 업무 시간이 절약되고 그에 따른 효용이 어느정도인지를 측정하는 것이다. 아래 표처럼, 해당 업무를 몇 명이 하고 있으며, 한달에 몇번을 몇시간씩 하는가에 따라 그 업무에 투여되는 전체 시간이 도출된다. 

 

업무	수행 인원	업무당 소요 시간(H)	업무 횟수 / 월	업무 소요 시간 / 월
A팀 취합 업무	6	1	2	12
B팀 전표 업무	2	0.5	2	2
C팀 심의 업무	4	1	4	16
총계				30

 이렇게 도출된 시간은 30시간이라고 한다면, 회사 입장에선 단순하게 30시간치의 일이 사라졌다고 생각한다. 만약에 우리가 하루 8시간, 한달 영업일 20일 곱하여, 한달에 160시간을 일한다고 한다면, 약 30/160 의 사라진것이다. RPA로 1600시간의 업무가 절감되었다면, 10명 만큼인 업무가 사라진 것이다. 하지만, 이런 단순한 비약은 빠지기 쉬운 착각이라는 것을 앞 포스팅에서 언급한 바 있다.  그래서 실제로 의사결정을 내리는 지표보다는, '이 정도의 효용성이 있습니다. 이 만큼 더 중요한 업무에 힘을 쏟을 여력이 생겼습니다.' 정도의 메세지로 사용하는 것이 바람직하다.  인효율을 중요시 하는 기업 분위기라면 사람을 줄인다는 것 보다는 '더 많이는 안뽑아도 됩니다.' 정도로 완하하는것도 좋다. 

  두번째 효용성은 휴먼 에러를 줄인다는 것이다. 사람이 하면 당연히 실수를 할 수 밖에 없기 때문에 그로 인해 발생하는 추가적인 업무 소요가 있다. 실수를 했으면 그에 대한 보완 조치가 들어가기 때문이다. 그런면에서 휴먼 에러 감소 좋은 효용성일 수 있다. 

  마지막으로, 리스크 매니지먼트다. 앞서 말한 휴먼 에러로 발생하는 다양한 리스크가 있을텐데, RPA로 업무를 수행하면 사람의 실수를 예방하기 때문에 휴먼 에러로 발생하는 추가 이슈들을 예방하고 그에 따른 추가 업무 공수들도 절감 할 수 있다.  

  위와 같이, 정량적 개선 지표와 정성적인 명분들이 마련되었다면 지체없이 윗 형님들께 찾아가자.  '이렇게 돈 쓰겠습니다' 허락을 받고 다음 단계로 나아가면 된다. 

 

STEP 3. 파트너 찾기

 RPA는 SI개발이 아닌 솔루션 라이센스형 서비스지만, 처음 도입하는 기업에서 솔루션 도입만으로 내부 IT인력으로 과제를 개발하기 불가하다. 그래서 RPA 과제를 개발해주고, 라이센스도 공급해주는 국내 파트너사를 대상으로 컨택을 해야한다. 다만, 솔루션별로 어떤 특성과 어떤 과금체계가 있는지는 미리 리서치가 필요하다. 

 

가트너, RPA 솔루션 평가

 

  위 표처럼 RPA 솔루션은 정말 다양한 플레이어들이 있는데, 시장을 리드하는 것은 UIpath와 블루프리즘, Automation Anywhere(이하 AA) 등이 있다. 블루프리즘만 영국 회사고 UIpath와 AA는 미국기업이다. 국내에도 SDS의 브리티나 체크메이트 등 다양한 플레이어들이 있고 국내 사정에 맞춰 커스텀화 되어있기 때문에, 다양한 공공기관이나 국내 기업들에서도 많이 사용하고 있다. 각 솔루션들은 개인에게 무료버전으로 제공되기도 하므로, 직접 오케스트레이터나 간단한 개발 툴들을 다운받아서 써보는것도 좋다. 필자는 AA와 UIpath만 써보고 운영하였지만 PoC를 통해 본 국내 기업들의 RPA 솔루션도 매우 우수했다. 다만 개발자 생태계나 라이브러리 같이 부수적인 부분에선 아무래도 업력이 오래된 리드 업체들이 더 좋을 수 밖에 없긴 했던것 같다.

  이렇듯 솔루션에 대한 리서치가 끝나면 솔루션을 공급하고 SI개발을 수행하는 파트너사에게 컨택하면 된다. 보통 각 솔루션 한국 본사에 컨택하면 파트너사들을 소개해주기도 하고, 파트너사에 직접 컨택하기도 한다. 그렇게 각 사마다 미팅을 진행하며 요구사항에 대해 개괄적으로 공유하고 개발 참여 의사를 확인한다. 참여 의사가 있는 수행사에는 사전 테스트 과정이 있으며, 기업마다 다르겠지만 경쟁 입찰이 될 수도 있음을 공유한다. 

 

STEP 4. PoC 진행

  PoC 테스트는 솔루션이 우리 회사의 환경에 잘 맞는지를 확인하는 과정으로 2번의 PoC를 진행한 필자의 경험상, 꼼꼼하게 잘 봐서 나쁠건 전혀 없다. 오히려 좋게 생각했던 솔루션이 우리 회사에서 쓰이는 ERP의 어플리케이션과 충돌이나서 안되는 경우도 있고 특정 브라우저에서는 동작하지 않는등 다양한 이슈가 불거저 나오기 때문에 꼭 진행해야 한다. 괜히 도입하고나서 이슈가 불거지면 그 때는 다시 되돌릴 방도가 없다.  

  PoC를 진행하는 과정은 2개 정도의 과제와 프로세스 정의서를 준비하고, 이틀 정도의 시간에 과제를 개발하고 이상 없이 수행되는지를 확인하는 것이다.  참여 의사를 밝힌 수행사들이 형평성을 위해 동일한 일시에 동일한 환경에서 개발을 진행해야 한다. 

  PoC 과제를 선정할때는 무조건 고난이도 과제보다는, 다양한 시스템과 어플리케이션을 왔다 갔다 하는 과제들이 가장 적합하다. 가령 엑셀안에서 노가다와 복잡한 함수를 써야하는 과제보다는, ERP에서 데이터를 추출하고 엑셀에 옮겨 적었다가 그 파일을 브라우저에 업데이트하고 사내 메신저로 전달하는 과제가 좋다. 다양한 이종 프로그램간의 태스크 이동을 통해 안정성과 호환성을 확인 할 수 있다. OCR 같은 외부 API를 통신해야하는 과제도 좋다. (어렵긴 하지만)

  이렇듯 2개 정도의 과제가 개발이 되면 현업 담당자들과 IT부서 담당자들의 참관하게 다양한 평가 지표로 평가하게 된다. 평가 항목은 호환성, 안정성, 개발용이성, 유지보수 용이성 등 주요한 대카테고리와 그 안에 상세 항목들로 나뉘어 대략 10개 이상의 평가 항목이 있다. 예를들면 호환성에, '당사 프로그램 설치형 ERP의 버튼 인식이 정상적으로 되는가' 이다. 다양한 담당자들의 평가가 마무리 되면 취합하여 점수를 합산한다. 

  그 후에 자체적으로 발주 부서가 있건, 아니건 자체 프로세스를 통해 수행사와 솔루션을 선정하면 된다.