로봇 운영 모델(ROM)이 RPA 성공에 필수적인 이유
"RPA 분야의 모든 사람이 '좋은' 프로세스가 무엇인지 아는 것은 아닙니다. 일부는 비즈니스 이점이 거의 없거나, 나중에 문제를 일으킬 복잡한 로직으로 개발됩니다."
벤자민 프랭클린이 "예방 1온스가 치료 1파운드보다 낫다"고 말했을 때, 그는 구체적으로 로봇 프로세스 자동화(RPA)와 로봇 운영 모델(ROM)의 중요성을 염두에 둔 것은 아니었습니다. 하지만 그랬을지도 모릅니다.
RPA는 전체 여정이 미리 정의되었을 때 가장 잘 구현되며, 오류를 발견하고 나서 수정하기를 기다리는 방식이 아닙니다.
블루 프리즘(Blue Prism)의 ROM은 바로 이 목적을 위해 설립되었으며 7개 기둥으로 나뉩니다.
- 비전(Vision)
- 조직(Organisation)
- 거버넌스와 파이프라인(Governance and Pipeline)
- 전달 방법론(Delivery Methodology)
- 서비스 모델(Service Model)
- 사람(People)
- 기술(Technology)
각 기둥은 RPA 솔루션 구현 시 고려해야 할 다양한 사항을 포함합니다.
블루 프리즘 ROM 준수는 RPA CoE(CoE, Center of Excellence)가 정체되지 않고 유기적으로 번성하고 성장하도록 보장합니다. 이것이 RPA를 쉽게 확장 가능하게 하고, 기업이 걷기도 전에 RPA로 뛰지 않게 합니다.
비전
먼저 RPA 구현의 전략과 목적을 고려해야 합니다. 데이터 품질 개선, 비용 절감, 더 빠르고 정확한 응답으로 사용자 경험 향상 중 무엇을 원하십니까?
이유가 무엇이든, RPA 전략이 전체 비즈니스 전략과 어떻게 정렬되는지 이해하는 것이 중요합니다. 이렇게 하면 확장 준비가 되었을 때 이미 지지를 확보한 상태가 됩니다.
비전을 수립했다면, 밖으로 나가 목소리를 내십시오! 조직 최상위에서 바이인(buy-in)을 확보하고 긍정적으로 하향 전파되고 있는지 확인하십시오.
조직 목표에 대한 전염성 있는 열정을 가진 RPA 책임자를 찾아 로드쇼, 워크숍 등 이니셔티브로 전사적 참여를 유도하십시오. RPA 챔피언들도 입소문을 내고 추가 자동화 기회를 식별할 수 있습니다.
올바른 사람들을 일찍 참여시킬수록 좋습니다!
조직
다음 단계는 조직 모델 계획입니다. RPA를 비즈니스 어디에 둘 것이며 성장 계획은 무엇입니까? 중앙집중식 접근은 전사를 아우릅니다. 기존 CoE에 내장하는 것이 유리할 수 있습니다. 하지만 제한된 딜리버리 팀이 있는데 비즈니스 모든 구석에서 자기 프로세스 자동화를 요청하면 기대를 관리해야 합니다!
연합 접근(federated approach)은 RPA 역량이 특정 기능 내에 있지만 비즈니스 전반으로 확장되며, 중앙 팀이 표준과 모범 사례를 통제합니다. 이는 조직 전반에 딜리버리 포드(delivery pods)를 만들어 각자 자신의 자동화 프로세스를 식별하고 전달하되 CoE의 거버넌스를 받도록 함으로써 달성됩니다.
사업부 접근(divisional approach)은 가장 덜 바람직합니다. 여러 RPA 기능이 별도 인프라, 별도 거버넌스, 별도 팀으로 조직 전반에 걸쳐 별도로 운영됩니다. 비용 효율적이지 않고 진정한 확장을 방해합니다.
거버넌스와 파이프라인
RPA 분야의 모든 사람이 '좋은' 프로세스가 무엇인지 아는 것은 아닙니다. 일부는 비즈니스 이점이 거의 없거나, 나중에 문제를 일으킬 복잡한 로직으로 개발됩니다.
진정으로 좋은 프로세스가 무엇인지 명확히 하는 것이 중요합니다. 이진 로직, 높은 트랜잭션성과 신뢰할 수 있는 대상 애플리케이션 등은 찾아야 할 것들 중 일부입니다.
'좋음'의 정의가 명확해지면, 거버넌스를 통해 공급되는 프로세스를 식별할 수 있습니다. 이렇게 하면 올바른 청중에게 올바른 질문을 할 수 있습니다.
예를 들어, 자동화에 이상적인 프로세스를 찾았지만 거버넌스 보드의 IT 대표가 2개월 후 대상 애플리케이션에 예정된 패치가 있다고 알립니다. 패치가 수행될 때까지 요소를 재스파이(re-spy)하고 프로세스를 보류해야 합니다.
거버넌스 보드에서 다뤄지는 다른 주제 중에는 수요 창출, 즉 비즈니스 내에서 RPA 수요를 어떻게 창출할지가 있습니다. 적합한 프로세스 식별을 위한 직원 인센티브, 내부 커뮤니케이션, 참여를 위한 워크숍 운영 등이 권장 기법입니다.
전달 방법론
이제 이 모든 프로세스를 식별했으니, 어떻게 자동화 솔루션으로 전달할까요?
정의 단계에서 잘못된 정보를 수집하거나(또는 전혀 수집하지 않음) 치명적 영향을 미칠 수 있으므로, 프로세스 정보를 수집할 지식이 풍부한 SME(주제 전문가)가 필요합니다. 적절한 청중을 위한 프로세스 워크스루(process walk-through)도 진행할 가치가 있습니다.
개발자가 블루 프리즘에서 솔루션을 최대한 빨리 자동화하고 싶은 유혹이 큽니다. 하지만 장기적으로는 조금 더 시간을 들였더라면 좋았을 것입니다.
먼저 'To-Be' 프로세스를 문서화하십시오. 로봇 프로세스가 인간 프로세스와 어떻게 다를까요? 블루 프리즘에서 구축하기 위한 청사진은 무엇입니까?
이 솔루션에 필요한 비즈니스 오브젝트(Business Objects)를 개요하고 환경에 이미 존재하는 오브젝트와 비교하십시오. 이는 재사용 가능한 오브젝트 라이브러리를 확장함에 따라 개발 시간을 앞당길 것입니다. 'To-Be'가 비즈니스와 합의되고, 설계 책임자/리드 개발자가 제안된 청사진을 승인하고 필요한 동료 검토를 수행하면 개발을 시작할 수 있습니다.
테스트를 승인하고 비즈니스가 만족하는지 확인하십시오. 테스트와 릴리스 단계에서 생산해야 할 다른 핵심 산출물도 있으며, 이를 소홀히 해서는 안 됩니다!
서비스 모델
프로세스가 프로덕션에 들어가면, 올바른 지원을 둘러봐야 합니다.
로봇이 운영 팀에 수동 키잉을 위한 비즈니스 리퍼럴을 넘기고 있습니까? 로봇이 예상대로 작동하지 않을 경우 개발자가 대기하고 있습니까? 로봇 자원 손실을 방지하기 위한 재해 복구 계획이 있습니까?
가장 피해야 할 것은 부실한 서비스 모델로 로봇 자원을 잃는 것입니다.
사람
모든 위대한 팀은 처음부터 미래의 성공을 계획합니다. 개발자가 경험이 없으면 필연적인 RPA 고통 포인트를 다루기 어려울 것입니다. 고품질 리드 개발자 임명이 필수적이지만, 현재 시장에서는 이런 인재를 찾기가 극히 어렵습니다.
개발자들은 블루 프리즘 개발과 프로세스 분석 모두에서 최고 수준으로 훈련되어야 합니다. 이렇게 하면 숙련된 컨설턴트의 현장 지원을 받으면서 하이브리드 역할을 수행할 준비가 됩니다.
개발 팀이 계속 성장함에 따라, 표준 유지를 위한 설계 책임자(Design Authority)와 프로덕션 로봇 관리를 위한 컨트롤 룸 모니터(Control Room Monitor) 임명을 고려해야 합니다.
마지막으로, 언제 채용이 필요한지 계획하십시오. 이는 딜리버리 팀의 연속성과 품질 유지에 도움이 됩니다.
기술
일곱 번째 기둥은 어떤 기술적 접근을 취할지에 대한 고려사항입니다. 가상 머신 설정, 미래 확장을 위한 라이선스 프로비저닝, 재해 복구 등을 고려해야 하며, 클라우드 기반 솔루션과 온프레미스 호스트 중 선택도 포함됩니다.
흔한 문제는 공통 이미지에 맞춰 가상 머신을 구축하지 않아, 서피스 오토메이션(Surface Automation) 같은 개발 기법이 실패할 더 큰 위협에 노출되는 것입니다.
각 기둥을 올바르게 설정하는 것은 모든 RPA 솔루션의 성공에 필수적입니다.
작성자: 롭 도슨(Rob Dawson), 수석 컨설턴트, 로빅위티(Robiquity)