본 글에서는 앞서 제시한 2) BA(컨설턴트)가 상세한 프로세스 모델링과 화면 설계를 하고 개발자가 데이터 설계와 코딩을 하는 방법에 대한 구체적인 사례를 설명하고자 한다.

전통적인 PI, ISP 프로젝트에서 프로세스 모델링은 업무를 분할하여 업무 기능과 프로세스를 정의하는 수준으로 수행한다. 이를 통해서 어떤 업무를 수행할 것인가를 정의하게 된다. 새롭게 수행해야 하는 업무와 변경해야 할 업무를 파악하는데 도움이 되지만, 구체적인 업무 수행 방법을 기술하는 것은 놓칠 수가 있다.

프로세스 모델링 도구를 사용하면 대상 업무가 무엇인가(what)를 정의하는 것으로 그치지 않고 실제 업무의 수행방식(how)을 상세하게 정의해야 한다. 개발자는 프로세스 모델링 도구에 입력된 내용에 맞게 시스템 설계를 진행할 수 있다.

도구를 활용한 프로세스 모델링은 프로세스를 시스템 관점으로 한 단계 상세화 하는 것이 중요한데 이를 위해서는 “한 업무담당자의 업무 시작과 종료”를 한 화면 User 사용 관점으로 분리하는 것, 화면/데이터 변경에 따라 분기 시키는 것, 필요한 기능을 화면 또는 서비스로 식별하는 것 등을 수행해야 한다.

 

프로세스 모델링 도구를 활용한 사례

프로세스를 시스템 관점으로 한 단계 상세화 할 때 필요한 것은 아래와 같다.

- 한 화면을 사용하는 User 관점에서 분리하는 것
- 업무를 모르는 사람이 프로그램을 설계할 때 볼 수 있도록 설명을 자세하게 정의하는 것
- 시작과 분기(이벤트) 케이스를 상세화 하는 것
- 화면 액티비티를 도출 하는 것, 서비스를 도출하는 것 등
 

기존 프로세스 맵 작성 시에는 보험설계사 선발하는 업무 프로세스를 그렸다면, 현장에서 보험설계사 신청 하는 업무와 본사에서 면접/승인하는 과정 두 개의 프로세스로 구분할 수 있다. 또, 업무 프로세스의 시작과 종료 이벤트는 각 업무 단위로 승인요청/수신 등 시스템 단위 메시지/화면 이동 등을 고려하여 정의해야 한다.
  

 

분기의 경우에도, OR, AND 등 대안흐름을 고려하여 정의해야 한다.
다음으로는, 각 화면 액티비티, 입력정보 및 조회결과, 다양한 조회조건 등을 정의하는 것이 필요하다.
  

왼쪽 표는 기존 프로세스 모델링에서 프로세스 정의서의(L5, 액티비티) 단위로 정의한 예이다. 이때 정의한 설명, 기준 등을 tool에서 표현하면 오른쪽(Visual paradigm으로 정의한 맵) 그림과 같다.

마지막으로 서비스를 도출한다는 것은 화면을 통해 호출하거나, 화면 뒤에서 프로그램으로 돌아가는 서비스(계산/추출/검증 등 온라인 프로그램)를 식별하는 것을 말한다. 자동계산 액티비티는 필요정보/결과정보와 함께 표현해준다. 이런 서비스의 경우, 규칙/ 계산식 등을 필요로 하며, 이는 다음과 같다. 

프로세스 모델링 외 화면 정의 또한 Visual paradigm tool을 활용할 수 있다.

 

Frame, Label, 다양한 버튼을 선택할 수 있고 각 화면은 해당 화면을 사용하는 액티비티에 연결할 수 있다.

여기까지 실제 활용한 사례이고, 프로젝트마다 활용범위를 조정할 수 있을 것이다.

실제 적용 시 고려사항

다만, 프로세스 모델링 완벽하게 적용한다면 고려해야 할 사항이 있다. 먼저 상세화 깊이 측면에서, 기존 프로세스 모델링과 달리 상세하게 정의해야 한다.

▶ BPM 표준에 따라 최하위 Task(액티비티) 속성에 대한 명확한 정의로 서비스, UI 목록 식별

▶ 최하위 Task(액티비티)를 처리하는 상세 step에 대한 자세한 기술을 통한 상세 기능 식별

▶ In/Out 정보 항목에 대한 식별로 화면, 데이터 구성요소 식별

▶ Use case는 자동 변환 되지만, 상세 시나리오 작성을 통하여 비즈니스 케이스, 업무 규칙 기술

위와 같이 4가지가 최소한 정의되어야 하며, 이를 위해서는 상세화 수준을 정의할 수 있는 인력이 확보되어야 한다.

▶ 업무 프로세스 이해(현업 관점의 요구사항 정의) BPM 모델링 이해, 상세화 한다면 분석 모델링 역량(어플리케이션 개발 경험 또는 분석 산출물 작성 경험)이 필요하다.

▶ 프로젝트 기간 수립 시, 상세화 기간을 추가로 고려해야 하며 기존 PI 프로젝트 3~4개월에 추가로 약 2개월이 필요할 것으로 생각된다.

▶ 설계자와의 커뮤니케이션 수단(상세 설계)으로 활용할 수 있으나, 분석단계부터 설계자가 참여해서 검토하고, 이후 개발에 활용하는 것이 좋을 것이다.

지금까지는, 대부분의 프로젝트에서 목표 모델 수립 결과는 보고용으로만 활용되고, 구축 단계에서 처음부터 다시 분석하고 설계하는 경우가 많았다. 이렇게 되면 예산의 낭비와 기간의 지연은 물론이고 고객사가 원하는 목표 모델을 달성하지 못한다는 문제가 발생하게 된다. 개발을 담당하는 SI사도 불명확한 요구 사항으로 프로젝트를 시작하게 되어 추가 비용 발생과 품질 저하라는 위험 요인을 안게 된다.

디지털 탈바꿈은 디지털 기술을 활용하여 비즈니스를 바꾸는 패러다임이다. 따라서 구축과 동떨어진 방식으로 비즈니스를 정의하는 것은 더욱 위험한 접근이다. 비즈니스프로세스 모델링 도구를 기반으로 목표 모델을 정의하고 시스템 구축의 베이스라인으로 활용하는 방식은 우선적으로 도입되어야 한다.

본 글은 ‘목표 모델 그대로 구축하기 [1부] : 왜, 목표 모델과 시스템 개발은 따로 노는가?’의 후속 편입니다.

- 끝 -