기존 'RPA 시장 흐름'을 통해 설명했던 "현행 RPA 사업이 주춤하게 되는 주된 이유"는

 

RPA를 IT 부서에서만 주도하며 SI 프로젝트 형태로 받아들이기 때문이다.

 

SI 프로젝트는 CIO단의 스폰서에서 시작해 특정 목적을 가지고 시스템을 구축한다.

 

또한 과제 발굴이라든가 요구 사항 요청 같은 단계가 없거나 혹은 체계가 잘 잡혀있어 RnR이 명확한 편이다.

 

[상대적인 관점. 고객의 요구 사항은 보통 고객 스스로도 잘 모르는 경우가 많기 때문]

 

 

 

하지만 RPA 프로젝트는 특정 목적을 달성하면 종료되는 형태의 프로젝트가 아니다.

 

다량의 발굴을 통해 업무 정의 및 효율성을 높이고 자동화 영역을 넓혀가면서 규모의 경제를 달성해야 한다.

 

따라서 과제발굴, 컨설팅, 변화관리가 지속적, 체계적으로 필요하며

 

CEO급의 장기적인 거버넌스 청사진이 준비돼야 한다.

 

 

 

 

개인적으로 국내 RPA 사업이 주춤하고 있다고 판단했던 이유는

 

모두가 RPA를 10~20개씩 (혹은 그보다 더 적은 과제 숫자로 한 페이즈씩) 구축 단위로 진행하면서

 

자동화 요구 충족 및 구축 규모의 경제를 빠르게 달성하기 힘든 구조가 고착화 됐다고 봤기 때문이다.

 

RPA 아젠다를 가져오긴 했으나 전사적인 진행을 할만한 컨설팅이 된 곳이 거의 없었다.

 

특히나 IT팀의 제한된 예산은 해당 페이즈에서 임원의 실적채우기급 사이즈로만 활용될 유인이 컸다.

 

 

 

 

 

이런 프레임에서 RPA가 고객사에 들어갔을 때 RPA의 입지는 굉장히 좁다.

 

CoE조직의 내부 PM도 궁극적으로 거버넌스를 어떻게 가져가야 할지 감이 없거나 스폰이 부족하다.

 

구축사에게 완전히 맡기고 현업은 프로세스 인터뷰만 해주는 형태라든가

 

KPI가 잡히지 않은 상태에서 내재화를 위해 내부 교육만 받는 형태는 결과적으로 동력이 떨어진다.

 

 

 

 

그나마 가장 빠르게 반응하고 있는 금융업계에서는 역시 현업 개발 및 발굴이 활발하다.

 

[성공한 케이스인 경우. 은행권에서도 이미 1차를 실패하고 2차를 새로 도전하고 있는 케이스도 있음]

 

이렇게 하기 위해선 내부 KPI로 지정하고 전사적인 스폰을 통해 장기적인 자동화 거버넌스를 가져가야 한다.

 

발굴, 개발, 관리, 실행, 현업 참여, 모니터링 플랫폼 구축 및 CoE, Keyman을 명확히 설정하고 힘을 실어주어야

 

빠르고 효과적인 프로젝트 진행이 가능하다.

 

특히나 RPA 도입 관계자들은 내부 KPI뿐 아니라 RPA의 KPI를 어떻게 잡을지에 대한 고민을 꼭 해야한다.

 

[결국 시스템은 장기적으로 유인에 의해 움직이기 때문이다.]

 

 

 

 

요컨대 하청맡긴 회사에 다 던져놓고 output을 평가, 관리하는 현재의 시장 방식으로는 RPA 벤더든, 구축사든, 고객사든

 

RPA로부터 생기는 막대한 가치를 도출하기 어렵다.

 

결국은 전체적인 거버넌스를 제안하는 프레임이 바뀌어야 한다.

 

[물론 이 과정에서 규모에 따른 거버넌스 차이가 크게 날 수도 있다.

 

하지만 이는 다른 솔루션과 마찬가지로 투자 규모에 따른 자연스러운 시스템 형태 분화라고 볼 수 있다.]

 

 

 

 

=============================================================

 

세부적으로 들어가면 더 복잡한 구조들이 나오지만 큼직한 덩어리로 보자면

 

KPI라는 유인과 C-Level의 예산지원을 통해 진행,

 

현업들은 주인의식 가지고 자동화에 참여[KPI로 반영],

 

CoE는 기존 개념 보다 더 넓은 개념으로 가져가고 시스템간 관리자 커뮤니케이션,

 

Keyman 참여, RPA 개발/운영/변화관리 엔지니어의 자문 및 서비스, 컨설팅을 통한 PI를 통해

 

과제들의 라이프 사이클 관리 정도로 볼 수 있다.

 

 

물론 단번에 이런 구조를 가져가기는 어렵다.

 

PoC와 파일럿을 거쳐 사내 결정권자 설득 및 투자 심의를 거쳐야 하고, RPA 성숙도를 차츰 높여가야 한다.

 

다만 궁극적으로 이런 구조를 보고 진행하느냐 아니냐는 자동화 사업 자체의 운명을 결정한다.

 

 

==================================================================

 

거창하게 썼지만 이런 거버넌스를 이미 제안하고 있는 회사도 있다고 본다.

 

다만 대부분의 회사들은 그저 개발자 몇 명 집어넣는다든가

 

오브젝트 단위가 아닌 딱 유저 스토리 단위로만 그리는 컨설턴트를 쓴다든가

 

하청 관리 형태로 생각하고 정직원들은 최대한 덜 귀찮게 해달라든가

[그럴 수밖에 없다. 해봤자 회사에서 KPI로 잡아주지 않는 게 보통이기 때문]

 

하는 식으로 프로젝트를 진행, 관리하고 있다.

 

 

RPA 도입에 관심이 있다면 좀 더 장기적으로 바라봐야 한다.

 

 

'RPA 종합' 카테고리의 다른 글

RPA 개발자 입장에서 보는 RPA 잘하는 기준  (8) 2021.05.11
RPA의 개념  (2) 2020.10.13
RPA 시장의 두드러지는 흐름  (9) 2020.04.06
move file하는 vbs 코드  (0) 2020.01.03
RPA용 SAP GUI 세팅에 관한 설명  (0) 2019.11.18

+ Recent posts