1. Assesing automation potential

1-1. What Are Business Processes?

process와 porcedure(절차)를 구분하는 것은 중요하다.(이하 프로세스, 절차 표기)

• 비지니스 프로세스 : 입력이 출력으로 변화는 과정들이 서로 연관되고 연결된 형태의 액티비티들
• 프로세스를 구성하는 이유 : 통제가 가능한 범위에서 프로세스를 이용하면 규정 준수, 운영 요구 사항 충족, 위험 관리에 도움이 되기 때문
• 프로세스의 구성 요소는 아래와 같음
  • input : 프로세스에 들어가는 데이터
  • process flows : 서브 프로세스들이 연결된 형태, 혹은 하나의 프로세스에 들어간 여러 액티비티들
  • source applications : 하위 프로세스나 액티비티를 수행하는 데에 필요한 어플리케이션 혹은 시스템
  • output : 프로세스가 만들어낸 결과물

프로세스는 데이터가 어떻게 흘러가는지, 업무가 어떻게 진행되는지에 대한 것만 기술한다. 다시 말해 언제까지 해당 프로세스가 완료 되어야 하는지(=시간적 제약), 다른 프로세스와의 상호작용은 어떻게 되는지, 책임자는 누구인지 등에 대한 부분은 빠져있다는 것이다. 이런 부분을 절차(procedure)가 보완한다.

'As-Is'와 'To-Be'가 있다. 흔히 'As-Is'는 현재 상태, 'To-Be'는 클라이언트가 원하는 미래 상태 및 형태라고 하는데, RPA 분야에 적용해보면 의미가 조금 더 구체적으로 바뀐다. 'As-Is'는 어떤 업무가 처리되고 있는 프로세스 그 자체를 의미한다. 그리고 'To-Be'는 자동화가 도입될 수 있는 부분들을 판단해 놓은 형태 및 문서를 의미한다. 그러니 'As-Is'와 'To-Be'를 현재와 과거 관점에서 보는 시각은 바뀌지 않았다고 할 수 있다.

1-2. Assessing Automation Potential

'To-Be'를 만들기 위해서는 자동화가 필요한 업무를 판단할 필요가 있다. 모든 일에 자동화를 적용할 수는 없기 때문이다.

원래는 자동화 가능 여부를 판단하기 위해서 비지니스 전체를 분석할 필요가 있겠지만, RPA 개발자는 비지니스 정보에 접근하는 것이 어려운 경우가 있다. 이럴 때도 자동화 우선순위 결정은 필요하므로 아래와 같은 관점으로 접근해보자.

1. 화면 수
   자동화는 사람이 하는 것처럼 컴퓨터 화면에 그리고 띄우고 작업한다. 화면이 바뀌면 로직을 새로 짜야 한다. 그러니 화면 수가 많을 수록 자동화 구현에 더 많은 리소스가 필요해지고 복잡도가 올라가 구현이 어려워진다.

2. 어플리케이션 수
   어플리케이션에 따라 자동화 난이도가 달라진다. 프로그램 무게도 있을 것이고 사용하는 스크린 수도 있을 것이기 때문이다.

3. 비지니스 로직
   자동화 복잡도는 비지니스 로직에 있어서 의사결정이 이루어지는 횟수가 얼마나 많은지에 따라 달라진다.

4. 입력 데이터의 타입과 개수
   입력으로 받는 데이터의 타입이 어느 정도 통일이 되어있는 경우가 적합하고 정형화된 데이터일 수록 자동화가 수월하다.

5. 프로세스의 변경 정도
   프로세스가 빈번하게 변경되고, 시스템 환경이나 매뉴얼 같은 것들이 자주 바뀌는 프로세스라면 자동화가 불가능하다.

6. 인력이 필요한 업무
   하나의 프로세스에 인력이 필요한 부분이 껴있는 경우, 부분적으로밖에 자동화를 할 수 없다. 따라서 로봇이 할 일과 사람이 할 일을 구분하는 것이 필요하다.

7. 개발 비용
   자주 수행되는 업무가 아니거나 개발 비용 대비 그 효과가 작은 업무는 자동화 우선순위가 낮다.

2. A day in the life of RPA developer

2-1. the automation project likecycle

자동화 프로젝트가 구현되는 과정은 아래와 같다.(개발자가 책임져야 할 부분도 함께 보기)

1. discovery and kickoff
   자동화 프로젝트의 잠재력 평가가 이루어진다. 자동화가 필요한 이유, 타당성, 일정, 목표 설정 등이 안건이다. 주로 고객과 함께 이루어진다. 이 때 RPA 개발자는 프로세스 복잡도를 계산해야한다.

2. process analysis
   RPA 구현에 앞서 프로세스 분석이 필요하다. 자동화 정도가 이 프로세스 분석에 기반하여 결정된다. RPA 개발자는 기존 비지니스 프로세스 관련 문서들을 취합해 'As-is'와 'To-Be' 흐름도를 작성한다. 그리고 비지니스 적용 팀과 협업하여 테스트 데이터셋을 만든다.

3. Solution design
   자동화를 구현하기 위해 보유한 모듈과 맵핑 작업을 하고 대략적인 그림을 그린다. RPA 개발자는 'To-Be' 흐름도가 솔루션 디자인 문서(Solution Design Document, SDD)를 우선적으로 만들고, 자동화 개발 방향이 이와 같은지 확인한다.

4. Development and unit testing
   자동화 프로세스를 구현한다. 이 때 프로세스 정의서(Process Definition Document, PDD)와 솔루션 디자인 문서(Solution Design Document)를 참고하여 구현한다. 그리고 각 모듈은 개별적으로 테스트를 거친다.

5. Integration and user acceptance testinig
   모듈화 된 자동화 프로세스드를 하나로 합치고, 전체 테스트를 한다. 이 과정에서 사용자가 해당 프로세스를 승인 할지 평가한다.(User Acceptance Testing, UAT)

6. Deployment and hypercare
   UAT를 거치면, 해당 프로세스를 배포한다. 그리고 개발팀은 일정 기간 동안 하이퍼케어(hypercare)를 진행한다.(일종의 AS)