프로세스 모델링이 디지털 탈바꿈의 성공과 실패를 좌우한다

디지털 탈바꿈(digital transformation)의 대상은 기업 또는 기관이 수행하고 있는 프로세스이다. 현재 프로세스에 디지털 기술을 적용하여 새로운 프로세스로 바꾸는 과정이 필요하다. 프로세스 탈바꿈을 위해서는 현재 프로세스와 목표 프로세스를 정의하여야 한다. 프로세스를 정의하는 과정을 프로세스 모델링이라고 한다.

프로세스 모델링은 비즈니스를 기술하는 것이면서 정보시스템을 개발하는데 기준이 된다. 비즈니스 관점에서는 업무 요건을 빠지지 않게 표현하는 것이 중요하다. 정보시스템 관점에서는 업무가 중복되지 않게 그리고 명확하게 표현되어야 한다. 프로세스 모델은 비즈니스와 정보시스템을 이어주는 다리 역할을 한다.

서비스를 자동화하거나 비즈니스 민첩성 확보 등은 프로세스 모델을 통해 표현된다. 프로세스 혁신(PI, Process Innovation) 또는 업무재설계(BPR, Business Process Re-engineering) 등을 수행할 때도 핵심 공정은 프로세스 모델링이다. 서비스 지향 아키텍처(SOA, Service Oriented Architecture)나 MSA(Micro Service Architecture) 등을 도입할 때도 프로세스 모델링의 품질이 성패를 좌우한다.

모든 비즈니스 혁신 프로젝트와 정보시스템 구축 프로젝트에서 프로세스 모델링을 수행하고 있다. 문제는 프로세스 모델을 제대로 수행하는 경우가 드물다는 점이다. 업무를 기술하는 것을 쉽게 생각하는 경향이 있다. 개인의 경험이나 관점으로 프로세스를 기술하는 경우가 많다. 이렇게 되면 전사 관점의 통합 프로세스 기술에 실패하게 되어 원하는 목적을 달성할 수가 없다.

디지털 탈바꿈을 이루기 위해서는 프로세스 모델링 원칙을 지키는 것이 매우 중요하다. 본고 1부에서는 프로세스 모델링의 기본 원칙을 설명하고, 이어서 2부에서 서비스 기반 프로세스 설계를 설명하기로 한다.

 

원칙 1. 업무 의존성에 따른 흐름에 집중하며, 기술 요소나 화면 등 사용자 인터페이스 요건과 독립적으로 정의한다

비즈니스 프로세스는 특정 업무 영역의 업무 연속성을 유지하기 위하여 연관성이 높거나 종속성이 있는 액티비티들을 하나의 프로세스로 설계하며, 해당 액티비티 간의 연관성을 표현하기 위한 업무 수행 규칙을 명확하게 정의한다.

비즈니스 유연성을 확보하기 위하여 정의되는 업무의 내용과 흐름은 기존 시스템의 지원 기능에 의해 제한되어서는 안되며, 업무 자체의 정의만을 명확하게 표시될 수 있도록 설계한다.

일반적인 화면 구성에 대한 고려는 하나의 화면은 여러 개의 서비스의 조합이 가능하므로 프로세스 설계 시에 정의하지 않고 별도로 정의한다. 그러므로 사용자의 결정이 필요한 업무는 User Task로 정의한 한 후 입력 받는 방식은 다양하게 정의할 수 있도록 한다. 예로 사용자의 결정은 시스템의 화면, 모바일 앱 화면, IoT 시그널 등의 다양한 형태로 서비스를 호출할 수 있다.

 

원칙 2. 프로세스의 액티비티는 독립된 업무가 될 수 있도록, 하나의 Actor에 의해 수행 가능한 단위 업무로 구성한다

프로세스 내의 액티비티는 비즈니스 서비스로 정의되어야 하며, 단일 Actor에 의해 수행되는 독립된 일련의 업무 단위로 구성된다. 액티비티 수행을 위한 시작 조건, 입력 메시지, 결과 메시지, 업무 수행 절차 뿐만 아니라 보상 처리를 정의한다.

Actor는 사용자나 단위 시스템, 목표 시스템 등 해당 서비스 수행의 모든 주체가 그 대상이 될 수 있다.

비즈니스 서비스의 도출은 서비스 기반의 프로세스 설계의 중요한 요건이지만 서비스의 기본 기능을 우선적으로 정의한 후 점차 상세화 할 수도 있으므로 프로세스 설계 시에는 서비스 자체의 상세 명세보다는 기본 업무 수행 조건과 명확한 업무 흐름 제어에 좀 더 집중할 필요가 있다.

 

원칙 3. 프로세스는 시작과 끝에 대한 조건이 명확하게 정의되어야 한다

프로세스의 시작과 끝은 명확하게 표시되어야 하며, 프로세스의 시작은 업무 시작을 위한 비즈니스 이벤트들로 정의한다.

프로세스 시작을 위한 이벤트는 사용자 액션, 메시지, 특정 데이터나 규칙에 따른 조건, 특정 주기 등으로 정의할 수 있으며, 종료인 경우 메시지 전달을 통하여 다른 프로세스를 호출할 수도 있다.

 

원칙 4. 업무 흐름은 분기 조건과 이벤트를 활용하여 제어가 가능하므로 프로세스의 오류를 줄이기 위하여 분기 조건과 이벤트 수행 조건은 명확해야 하며, 예외 상황과 Default 조건에 대한 정의가 필요하다

프로세스 내에서 액티비티 간의 연관관계는 순차적 처리, 동시 처리, 선택적인 처리 등의 다양한 관계를 가지며, 이를 표현하기 위하여 프로세스 설계 시 분기와 이벤트를 사용한다.

단순하게 업무의 순서를 처리하는 것은 데이터의 입력/출력의 매핑만 명확하면 별 문제가 없지만 분기가 필요한 경우 조건에 맞지 않는 상황이 발생했을 때를 대비하여야 하며, 업무적인 예외 상황에 따른 처리 또한 정의하여야 한다. 또한, 특정 이벤트나 예외 상황 처리를 위한 요건도 정의 되어야 한다.

 

비즈니스 프로세스 모델링 예시

비즈니스 프로세스를 설계하여 명시적으로 제공하고 관리하기 위하여 CASE 도구들이 지원되며, 모델링 표준인 BPMN(OMG)을 지원하는 Visual Paradigm을 활용하여 비즈니스 프로세스 모델의 가시화를 가능하게 한다.

[그림 1] Visual Paradigm을 활용한 비즈니스 프로세스 모델 샘플

프로세스의 수행 시나리오

1) 프로세스는 사용자 결정에 대한 입력으로 시작되며 입력된 결과에 따라 업무 수행을 위한 자동화 룰을 처리하고, 결과에 따라 다음 업무 액티비티를 선택한다. 사용자 입력은 시스템의 UI에서의 직접 입력하거나 모바일, IoT등의 다른 시스템의 결과 등 여러가지 방식으로 해당 User 서비스를 호출하는 것으로 시작 가능하다.

2) 앞선 액티비티의 처리 결과에 따라 자동화된 시스템 처리, 오프라인 액티비티, 외부 시스템 호출 중 선택적으로 수행된다.

3) 오프라인 액티비티 후 결과를 입력하거나 오프라인 액티비티 중 메시지 이벤트를 통하여 서비스가 호출되면 다음으로 진행한다. 메시지 처리를 위하여 다양한 방안을 제공하지만 기본적으로는 서비스 호출에 의해 에빈트가 수행된다.

4) 처리 결과에 따라 메시지를 조합하여 외부 시스템을 호출한 후 대기 메시지 처리를 대기한다. 구축 방안은 EAI 등의 메시지 처리 엔진 등을 활용할 수 있다.

5) 외부시스템의 처리가 종료될 때까지 메시지 대기를 수행하며, 메시지 트리거 방식은 다양하게 구현할 수 있다. 데이터베이스 트리거, EAI등을 활용할 수 있다.

6) 다음으로 수행되는 3개의 필수 액티비티와 2개의 선택적 액티비티가 처리되도록 하며, 동시에 시작하여 처리될 수 있다. 업무적으로 승인/합의가 혼용된 처리나, 데이터 처리 중 일부 데이터만 필수 데이터인 경우 활용할 수 있다.

7) 앞선 5개의 액티비티 중 필수 3개의 액티비티가 완료되면 다음 액티비티로 진행한다. 필수 액티비티가 아닌 2개의 액티비티에 대한 종료 여부는 고려하지 않는다.

디지털 탈바꿈을 위한 프로세스 모델링은 자동화도구를 사용하여야 한다

예제로 제시한 프로세스 모델과 같이 비즈니스 민첩성을 확보하고 시스템의 유연성을 보장하기 위하여 프로세스의 구축은 모델 기반으로 자동 구축하도록 서비스 오케스트레이션을 구축하고, 화면과 같은 외부 환경에는 독립성을 확보해야 한다.

이를 위하여 프로세스를 구성하는 비즈니스 서비스들은 다른 서비스와 입/출력 메시지 호출 이외의 종속성이 없어야 하므로 각각의 단위는 업무적으로도 각각이 독립적인 단위로 구성되어야 한다.

설계되는 프로세스는 비즈니스 이벤트와 비즈니스 서비스의 도출하고 비즈니스 서비스 간의 연관관계에 대한 업무 조건에 좀 더 집중을 하며, 이와 병행하여 마스터 데이터 처리와 같은 공통 서비스 영역에 대한 고려도 필요하다.

결론적으로 디지털 트랜스포메이션을 구축하기 위한 업무 프로세스의 설계는 기존의 비즈니스 프로세스 보다는 좀 더 명확하고 정교하게 서비스 기반으로 설계하여야 하며, 이를 위하여 BPMN 표준을 적용한 프로세스 모델링 도구(예를 들면 Visual Paradigm 등)를 사용하여야 한다.

 

 -끝 -