RPA 구축사의 Business Model을 논하기 위해선,
근본적으로 RPA 자체의 생산성이 어떻게 생기느냐를 먼저 살펴봐야 한다.
RPA는 업무 자동화 아키텍쳐를 의미한다.
Uipath Studio나 Brity Works Studio 같은 것들, 혹은 시중에서 판매되는 매크로들은
그냥 프로세스 로직 생성 툴, 실행기로 봐야 한다.
RPA가 부각되는 이유는 기존 매크로들에 비해 프로세스 로직 생성 툴이 포함된 아키텍쳐가
코스트 대비 가치를 많이 뽑아내는 '생산성'에 이르렀기 때문이다.
[물론 사일로 시스템에서의 시스템 변화가 잦다든가 하는 부차적인 부분도 있으나 근본적인 건 생산성이다.]
다시 말해, 대단히 새로운 기술이 생겨난 것이 아니라는 것이다.
이미 기존에도 각종 게임, 예매, 크롤링 등에 매크로가 이용되어 왔다.
로직 생성 툴, 실행기를 쓰는 것 자체는 당연히 쉽다.
툴을 포함한 아이텍쳐 자체를 개발한 회사에서는 이를 최대한 쉽다고 말해야 맞다.
그러나 구축사 입장에서는 방어적으로 가야 한다.
실제 가치를 만들어내지 못하는데 괜히 꼬아서 개발하자는 의미가 아니라,
Enterprise급에서 관리, 배포, 수행의 Cost를 최대한 줄일 수 있는 개발 노하우를 갖고 협상을 해야 한다는 말이다.
실제로 기업의 가치를 안정적으로 만들며 관리하기 위해서 구축사를 통해 SM, SI를 진행하는 것이지,
그렇지 않으면 그 '쉬운' 툴로 프로세스를 이미 알고 있는 현업이 개발하는 것이 백배 낫기 때문이다.
요컨대 구축사가 '우리가 왜 필요한가'를 고객사에 보여주기 위해서는
회사 차원에서 체계적으로 RPA 개발 생산성을 높일 수 있는 방법들을 고안하는 데 있다.
[왜냐하면 본질적으로 RPA 자체가 그것때문에 부각이 됐기 때문]
이를 개인의 역량에만 맡기게 되면 '프로젝트' 단위에서 관리되기 어렵다.
슈퍼맨 PM이 개발까지 잘해서 그런 체계를 다 만들고 그를 회사 내부에 전파하지 않는 이상,
비지니스 환경에서 그런 체계까지 고안해서 진행하기란 거의 불가능하다.
다음 글들에서는 '소스 구조 레벨에서의 최적화', 'RPA회사는 정확히 어떤 서비스를 파는가'와
그에 의거한 고객사에 제공할 수 있는, 인력 투입 차원의 '비지니스 모델'에 관해 좀 더 구체적으로 써보고자 한다.
'RPA 종합' 카테고리의 다른 글
2022 RPA 한국 시장 현황 및 전망(2022.03.04) (5) | 2022.03.02 |
---|---|
RPA 트러블 슈팅 관련 (0) | 2021.12.15 |
RPA에서 Amazon OTP를 얻는 방법 (0) | 2021.12.07 |
문제를 발견했을 때의 알고리즘 (0) | 2021.11.08 |
크롬 콘솔에서 CORS policy에러가 뜨면서 접속되지 않는 경우 (0) | 2021.10.15 |