소개
비즈니스 프로세스는 조직 목표의 지원으로 정의된 결과를 제공하기 위해 조직의
자원을 사용하는 논리적으로 관련되고 일반적으로 일련 순서가 정해진 활동 그룹입니다. 조직의 목표는 제품 또는 서비스의 형상으로 가치를 주로 고객이나 파트너 같은 외부 당사자에게 제공하는 것입니다. 하위
프로세스로 분석 가능한 프로세스는 역할 수행뿐만 아니라 필수/사용된 자원, 자원의 소유권, 책임성, 타스크에 전달되는 항목 정의 등을 포함한 프로세스의 모든 측면을 캡처하기 위한 조직, 자원 및 데이터 모델에
연관되어 있습니다.
이는 프로세스의 구체적인 보기이므로 비즈니스 프로세스가 경계 비즈니스 시스템의 비즈니스 유스 케이스의 실현(realization)인 보기를 사용합니다. 비즈니스 유스 케이스에 하는
것처럼 다음과 같이 동일한 분류를 적용할 수 있습니다(가이드라인: 비즈니스 유스 케이스 모델 참조).
-
코어, 가치 체인을 제공하는 외부 대면 비즈니스 프로세스의 경우
-
관리, 가치 체인을 조정하는 내부 비즈니스 유스 케이스의 경우
-
지원, 가치 체인을 지원하는 내부 비즈니스 유스 케이스의 경우
프로세스가 이벤트로 구동되도록, 즉 비즈니스 수행시 발생하는 조건으로 트리거되도록 허용합니다(아티팩트: 비즈니스 이벤트 결과).
프로세스 레벨
개념: 대규모 조직 모델링(아래 따옴표안의 인용)에서는 두 가지 레벨에서 비즈니스 유스 케이스를 자세히 정의하여 비즈니스 프로세스
소유자뿐만 아니라 경영진의 요구 사항을 수용하기 위한 기법을 설명합니다.
"경영진을 위한 하나의 모델은 조직의 의도와 목적을 보여주는 상위 레벨 비즈니스 유스 케이스 세트를 포함합니다." 프로세스 소유자를 위한 다른 모델은 조직이 내부적으로 기능해야 하는 방법을 명백히 하는 유스 케이스
세부 세트를 포함합니다. 각 상위 레벨 비즈니스 유스 케이스에 대해 조직에서의 동일한 활동을 나타내는 세부 비즈니스 유스 케이스를 하나 이상 정의할 수 있습니다.
아래 그림에서는 유스 케이스의 이런 정제를 보여줍니다.
하위 레벨의 더 자세한 유스 케이스는 상위 레벨 유스 케이스처럼 동일한 비즈니스 시스템에 대한 유스 케이스입니다. 즉 해당 비즈니스 시스템의 동작에 대해 블랙 박스 보기를 계속 나타냅니다. 이
레벨의 각 유스 케이스의 경우 비즈니스 프로세스로 설명할 수 있는 각각에 해당하는 실현(realization)이 있습니다. 따라서 이 유형의 분석을 프로세스 분석으로 간주할 수 있습니다.
프로세스 분석에서는 하위 프로세스의 활동 다이어그램을 구성하는 데 유용하고 실현 가능한 세부 레벨로 비즈니스 프로세스와 하위 프로세스를 분석합니다. 프로세스 분석에 대한 입력은
레벨 1 비즈니스 프로세스 모델에서 가져올 수 있고 이 입력은 설명만으로 작성되고 실현(realization) 관계에 의해 해당하는 레벨 1
비즈니스 유스 케이스와 연관될 수 있습니다. 레벨 1 프로세스는 위에서 설명한 대로 비즈니스 시스템에서 수행하는 내용, 경영진의 요구사항 충족에 대한 상위 레벨
설명입니다.
프로세스 분석 결과, 비즈니스 분석 모델에서 비즈니스 유스 케이스 실현(realization)으로 캡처된 문서화된 레벨 2
프로세스 세트가 만들어집니다. 일반적으로 레벨 2에서 프로세스에 대한 활동 다이어그램을 구성할 수 있는데, 보통 레벨 1 프로세스, 레벨 2 프로세스 및 활동(활동 노드로 구성됨)의 세
가지 레벨의 분석입니다. 비즈니스 유스 케이스 실현(realization)을 보여줄 수 있는 몇 가지 방법이 있습니다. 비즈니스 프로세스 모델링에 관심 있는 대부분의 비즈니스 분석가에게 익숙한 양식과 시맨틱이 있기
때문에 여기서는 활동 다이어그램(가이드라인: 비즈니스 분석 모델의 다이어그램 참조)에 초점을 맞춥니다. 이런 모델은 현재 프로세스의 비효율성을 식별하는 데 특히 유용하므로
자동화 및 비즈니스 변환 기회를 식별할 수 있게 됩니다.
유스 케이스 정제에 맵핑된 SOMA의 비즈니스 프로세스 분석
IBM Global Business Services(GBS) 서비스 지향 모델링 및
아키텍처(SOMA)는 비즈니스와 IT간의 간격을 연결해주는 SOA를 위한 접근 방식 및 기법 세트입니다.
아래 그림에서는 비즈니스 유스 케이스 정제를 사용하여 SOMA에서 표시하는 대로 프로세스 분석 결과를 비즈니스 모델링의 동일한 결과에 맵핑합니다. 두 가지 접근 방식이 동일한 개념에 대해 단지 다른 용어
및 표시를 사용하고, 결국 동일한 결과를 산출함을 보여주기 위해 이를 포함합니다. 예를 들어 서비스 지향 아키텍처( (SOA) 이니셔티브에서 IT 시스템이나 서비스를 사용하여 자동화에 대한 간격을 연결하는 데 사용할 수 있는 비즈니스 프로세스 설명 세트를 포함합니다.
위 그림에서는 SOMA에 사용된 표기 양식으로 프로세스가 하위 프로세스 및 유스 케이스로 분석되는 것을 보여줍니다. 하위 프로세스의 개념은 구성 파트(하위 프로세스)로 정제되는 프로세스의 정제에 대한 세부 레벨을
표기하기 위해 사용되는 편리한 구성입니다.
사용자 시스템 상호작용의 조회를 시작할 지점에 도달하면 하위 프로세스를 중지하고 리프 레벨 하위 프로세스로 레이블 지정합니다. 리프 레벨 하위 프로세스는 시스템 유스 케이스의 복합일 수
있습니다. 예를 들어 프로세스 주문의 리프 레벨 하위 프로세스에는 고객 이름 가져오기, 고객 주소 가져오기 및 주문 항목 가져오기의 유스 케이스가 있을 수 있습니다.
아래 그림에서는 RUP 비즈니스 모델링 표기를 사용하여 표현한 동등한 구조를 보여줍니다.
이 구조에서는 활동 다이어그램의 조치 노드로 리프 레벨 하위 프로세스를 표시하는 동일한 세 가지 레벨을 보여줍니다.
SOMA에서 가장 낮은 레벨의 유스 케이스로 표시하는 항목은 여기서 정의한 비즈니스 유스 케이스가 아닙니다. 비즈니스 유스 케이스 실현(realization)의 해당하는 활동 노드(조치 노드)이기
때문에 IT 시스템과의 상호작용을 가능하게 하는 곳입니다. 따라서 SOMA의 유스 케이스는 RUP(가이드라인: 비즈니스 모델에서 시스템으로 이동 참조)에서 설명한 대로 응용프로그램 개발에서 발생하는 유스 케이스와 더 가깝습니다.
비즈니스 프로세스를 모델링하기 위한 UML 활동 다이어그램을 사용하여 핵심 비즈니스 작업자, 비즈니스 중요 이정표 및 이벤트, 타스크 시퀀스 및 종속성, 수정 및 변경된 비즈니스 엔티티, 조직내 및 조직간 상호작용을 식별할 수 있습니다. 프로세스 모델은 타스크를 수행하는 "방법"이 아닌, 발생해야 할 "항목"을 명확하게 식별해야 합니다. 왜냐하면 이는 시간에 따라, 특히
비즈니스 환경이나 기술의 변경사항에 대한 응답으로 변경될 수 있는 비즈니스 프로세스의 관점이기 때문입니다.
|