 |
|
난이도 : 초급 Ken Beck, 컨설턴트, IBM
Joshy Joseph, 엔지니어, IBM
Germ<aacute></aacute>n Goldszmidt, PhD, 기술위원, IBM
2005 년 2 월 22 일 비지니스 프로세스 모델은 비지니스 스팩과 기술 프레임웍간 제휴를 촉진하는 매개체이다. 공유된 모델은 비지니스와 IT 프로세스를 연결하는데 도움이 된다. 분석가들이 비지니스 프로세스를 정의하는데 사용하는 모델링 개념을 이해하고 이 개념을 지원하는 IBM® WebSphere® Business Integration Modeler의 기능을 연구한다.
비지니스 프로세스 모델링이란?
프로세스란 비지니스의 가치를 지닌 확실한 인풋과 아웃풋을 가진 액티비티를 주문하는 것이다. 예를 들어, 기술 문서 검색 프로세스는 웹 페이지에서 고객의 검색 요청을 받아들여 선택할 수 있는 여러 문서 리스트들을 제공한다.
프로세스를 모델링 한다는 것은 중대한 도전이다. 모델링은 관련 정보를 획득할 때 일관성과 완벽성을 보장하여 비지니스 분석가들과 개발자들이 이 모델에서 획득한 비지니스 요구 사항들을 이해할 수 있도록 해야 한다. 모델링 하는 동안, 일반적인 작동은 물론이고, 표준 절차에 대한 대안과 예외들도 파악되어야 한다. 선호도와 전문성을 지닌 다양한 범주의 전문가들은 프로세스 모델을 구현하여 광범위한 비지니스 목적을 만족시켜야 한다. 예를 들어, 분석가는 프로세스에 대한 고급의 시각을 견지하여 전략적 결정을 하고 시뮬레이션 같은 프로세스 분석을 수행해야 한다. 개발자는 이 프로세스 모델을 사용하여 솔루션을 구현한다.
분석가는 비지니스 담당자들의 요구 사항들을 기반으로 비지니스 프로세스(BP) 모델을 구현한다. 이 요구 사항들은 PowerPoint, spreadsheets, IBM® Rational® Requisite Pro 같은 툴을 사용하거나 프로세스 모델링 툴들을 사용하여 수집된다. 분석가는 이 요구 사항들을 기존 프로세스에 대한 분석과 함께 인풋으로 사용하여 모델을 만든다. 기존 프로세스 모델들은 기존 프로세스의 분석에 사용되거나 기존 모델들을 변경하여 새로운 프로세스를 만드는데 사용될 수 있다.
모델링은 BP를 하위 프로세스로 구조화하는 것으로 시작한다. 이에 따른 분석은 컴포넌트, 서비스, 데이터 인풋과 아웃풋, 정책, 평가를 구분하기 위한 각 하위 프로세스의 중요성에 맞춰 수행된다. 이 요소들은 WebSphere® Business Integration Modeler 소프트웨어 툴(Business Integration Modeler)을 사용하여 BP 모델로 인코딩 된다.
프로세스 엘리먼트라고 불리는 모델링 객체는 재사용 할 용도로 설계된 BP의 한 부분을 정의하는데 사용된다. 프로세스 엘리먼트는 BP 모델 내에서 재사용될 수 있도록 설계 및 관리되는 프로세스의 세그먼트를 정의하는 객체 자산이다. 이는 태스크와 결정, 데이터 객체에 대한 레퍼런스, 정책, 역할, 평가 등을 결합한다. 예를 들어 로그인 프로세스 엘리먼트에는 사용자 로그인 프로세스를 처리하기 위한 액티비티, 로그인 확인 데이터, 로그인 규칙 등이 포함된다.
이 프로세스 엘리먼트는 일반적인 연산 작동을 나타내는데, 쇼핑 바구니 안에 든 내용물을 확인하고 가격을 책정하는 하위 프로세스 모델 같은 경우에 재사용 될 수 있다.
서비스 엘리먼트는 모델로 통합되는 Business Integration Modeler에 반입될 수 있는 사전 정의된 서비스이다. 이 서비스 엘리먼트들은 인풋과 아웃풋, 공표된 웹 서비스의 작동을 지정한다. 예를 들어, 서비스 엘리먼트는 원격 파트 공급자를 노출하는 웹 서비스를 지정할 수 있다.
BP 모델링 툴
Business Integration Modeler는 비지니스 프로세스를 Rational XDE 또는 Business Process Execution Language for Web Services (BPEL4WS) for WebSphere Business Integration Server Foundation (Business Integration Server Foundation)용 UML 모델로 변형 또는 반출하기 전에, 비지니스 프로세스를 모델링, 분석, 시뮬레이션, 향상시킬 수 있는 툴을 비지니스 분석가에게 제공한다. 우리는 Business Integration Modeler V5.1을 사용하여 BP 모델을 만들고 이들을 WebSphere Studio Application Developer Integration Edition V5.1.1 (Application Developer)에 반출한다. (그림 1)
그림 1. 분석가에서 개발자까지의 변형 모델링
Business Integration Modeler V5.1은 다양한 그래픽 및 텍스트 에디터, 비지니스 작동 모델 (BOM), BOM을 이에 상응하는 목표 플랫폼 객체들로 변환하는 변형 메커니즘 등, 다양한 프로세스 모델링 기능들을 제공한다.
그림 2. Business Integration Modeler 에디터, 모델, 변형
그림 2에서 보듯, 분석가는 해당 창에 다양한 프로세스 엘리먼트들을 만든다. (예를 들어, BP 플로우의 그래픽 표현을 위한 사용 프로세스 에디터는 액티비티와 연결들로 구성된다.) 이 프로세스 엘리먼트들은 디스크 파일에 BOM으로 저장된다. Business Integration Modeler는 BOM에 상응하는 밸리데이션을 자동으로 적용한다. 모델 반출 시, 나중 단계에서는 분석가는 정확한 변형을 적용하여 BOM을 상응하는 목표 객체로 변환한다. 그림 2는 4 가지 객체 반출 유형이다:
- Business Integration Modeler 객체 (Business Process Execution Language (BPEL)+/XML Schema Definition (XSD)/Web Services Description Language (WSDL))
- FlowMark Definition Language (FDL) for MQ Workflow
- UML
- Delimited text
비지니스 프로세스 모델링의 구성 요소는 다음과 같다:
- BP 요구사항 수렴하기
- 비지니스 아이템의 모델링
- 역할과 리소스의 모델링
- 서비스의 모델링
- 정책의 모델링
- 핵심 퍼포먼스 인디케이터(KPI)의 모델링
다음 섹션에서 각 단계들을 자세히 다루겠다.
BP 요구사항 수렴하기
BP 분석가는 BP 오너와 도메인 전문가들과 함께 BP 모델을 구현하는데 필요한 모든 정보들을 모은다. 예를 들어, 분석가는 해당 툴들을 사용하여 역할, 태스크, 시퀀스 정보, 리소스, 데이터, 내용, 요구사항 등을 모으고 이들을 BP 모델을 만드는데 인풋으로서 사용한다. Business Integration Modeler에서 프로세스의 모델을 만듦으로서 비지니스 분석가가 수집한 정보들은 워크플로우 개발자들에게 쉽게 반출되어 Application Developer 툴에서 사용할 수 있다.
비지니스 아이템의 모델링
비지니스 아이템들은 비지니스 작동에 사용되는 비지니스 문서 또는 작업의 산물들이다. 비지니스 아이템들의 예로서는 주문서, 고객 주소, 제품 청구서 등이다. 분석가는 XML 스키마 포맷으로 정의된 데이터 모델을 반입하거나 Business Integration Modeler를 사용하여 새로운 데이터 모델을 만들 수 있다.
데이터 모델링 엘리먼트에는 다음과 같은 생성물들이 포함된다:
- 데이터 카탈로그
- 비지니스 아이템
- 비지니스 아이템 템플릿
- 비지니스 아이템 인스턴스
데이터 카탈로그는 비지니스 아이템, 템플릿, 아이템 인스턴스 등을 조직화하는데 사용되는 폴더이다. 데이터 카탈로그의 생성은 선택적인 것이다; 그렇지 않으면 데이터 모델들은 Business Integration Modeler의 디폴트인 비지니스 아이템 데이터 카탈로그로 만들어질 수 있다.
비지니스 아이템들은 생성되어 기존 데이터 카탈로그에 추가된다. 비지니스 아이템 속성들도 비지니스 아이템에 추가된다. 예를 들어, orderItems와 valid같은 애트리뷰트를 가진 주문 비지니스 아이템을 가질 수 있다. 이 속성들은 간단한 유형들(스트링, 정수, 부울 등)이 될 수도 있고 또는 같거나 다른 비지니스 카탈로그에서 온 비지니스 아이템들이 될 수 있다. 예를 들어, 주문 비지니스 아이템에는 같거나 다른 데이터 카탈로그에서 orderItems유형의 OrderItem 속성이 포함 될 수 있다.
비지니스 아이템 템플릿들은 일반적인 속성들을 가진 비지니스 아이템들을 만들 수 있다. 이 새로운 비지니스 아이템은 이 템플릿에는 나타나지 않는 새로운 속성들을 추가할 수 있다. 예를 들어, 해당 속성들을 가진 orderitem 템플릿을 만들어 나중에 구매 주문 생성을 위해 그 템플릿을 사용하면서 전체 orderitem 속성을 타이핑하지 않고 아이템에 대한 제조 청구서를 만든다. 게다가, 새로운 속성들을 추가하여 확장할 수 있다. 이를 테면, orderitem 템플릿에서 검색하여 purchase date, location, store같은 추가 속성들을 추가하여 구매 주문 아이템을 만들 수 있다. 비지니스 아이템 인스턴스는 비지니스 아이템이 발생했음을 나타낸다. 제조번호 "1xDBCS"의 주문 등이 한 예이다.
비지니스 아이템 모델링 가이드
규칙들과 비지니스 아이템들과 다른 개별 속성들을 제휴하는 것도 가능하다. 하지만 이 기능은 현재 BPEL 반출에는 지원되지 않기 때문에 문서화 되어야 한다. 프로세스를 모델링하는 첫 단계로서 필요한 데이터 카탈로그와 비지니스 아이템들을 만들 것을 권한다. 이들은 태스크들과 제휴 될 수 있다.
아이템 속성들의 최소/최대 값을 설정하여 비지니스 아이템들의 주문 순서(어레이)를 만들라. 가능하다면 WBI 모델러의 XSD 반입 옵션을 사용하여 기존 XML 스키마 엘리먼트들에서 비지니스 아이템들을 반입한다. 데이터 카탈로그들은 자바 패키지와 XSD 스키마의 목표 네임스페이스로 매핑되기 때문에 개발 문제를 피하려면 데이터 카탈로그 이름들을 정확히 사용해야 한다.
비지니스 역할 및 리소스의 모델링
리소스들은 태스크를 수행하는데 사용된 사람, 장비, 또는 물품들이다. 역할들은 리소스에 추가 특성들을 추가한다. 예를 들어, 사원 리소스는 Manager의 역할을 가질 수 있다. 역할들은 스태프 액티비티를 가진 프로세스에서 사용될 태스크로 할당된다. 예를 들어, 관리 스태프는 태스크에 예외 핸들링이 있을 수 있다. (예를 들어, 무효 주문, 시스템 오류 등). 프로세스 분석은 리소스 할당을 조절하여 수행된다. 이 분석은 리소스 사용 레벨에 대한 상세한 내용을 제공하고 비용과 순환 시간을 계산하는 것을 돕는다. 이는 프로세스 최적화와 향상에 도움이 된다. 또한 워크플로우에서, 역할들은 사람들을 스태프 액티비티로 할당하는데 사용된다.
서비스의 모델링
Business Integration Modeler에서, 서비스들은 조직의 프로세스 내에서 사용될 수 있는 외부 (모델링 되는 프로세스의 밖에서) 엔터티로서 정의된다.
Business Integration Modeler에서 인풋 세트들을 인풋 기준에 따라 그룹핑 할 수 있다. 각 인풋 기준은 프로세스, 서비스, 태스크를 시작할 수 있는 인풋들의 조합을 정의한다. 한 개 이상의 인풋이 있을 때, 디폴트는 and 조건이다. or 조건의 경우 추가 인풋 기준들이 만들어질 수 있다. BPEL로 반출하고 있기 때문에 엘리먼트 당 단 하나의 인풋 기준을 가져야 한다. 아웃풋도 마찬가지로 아웃풋 기준도 아웃풋 세트를 그룹핑하는데 사용된다. 웹 서비스 WSDL 인터페이스 모델(portType 정의)에서, 이들 인풋과 아웃풋 기준은 연산 인풋과 아웃풋 메시지로 각각 매핑된다.
비지니스 서비스 모델링 가이드
각 서비스를 위해 많은 인풋 기준과 아웃풋 기준을 만들 수 있다 하더라도 BPEL 모델에서는 불가능하다. BPEL 기반의 워크플로우에서는 하나의 인풋 기준과 하나의 아웃풋 기준으로 제한된다. WSDL portType 연산은 하나의 인풋 메시지와 하나의 아웃풋 메시지만을 받아들인다. Listing 1은 인풋 기준과 아웃풋 기준이 portType 연산에서 인풋과 아웃풋 메시지로 매핑되는 방법을 보여준다.
Listing 1: 인풋 기준과 아웃풋 기준
<portType name="ValidateGenerateTopologyPT">
<operation name="sendValidateGenerateTopology_InputCriteria">
<input message="tns:InputCriteriaMessage"
name="InputCriteriaMessage"/>
<output message="tns:OutputCriteriaMessage"
name="OutputCriteriaMessage"/>
</operation>
</portType>
|
현재 기존 서비스 WSDL을 재사용하여 서비스 엘리먼트를 만드는 것은 불가능하다. 기존 WSDL을 재사용하려면 생성된 코드의 변경이 필요하다. 개발자들은 나중이 이 정확한 외부 서비스들을 BPEL partnerLink를 통해 제휴해야 한다.
비지니스 정책의 모델링
분석가들은 의도된 정책들을 지정하지만 정책들은 명확한 규칙에 의해 실행되어야 한다. 정책은 일반적으로 선언적이다. 예를 들어, “오직 미국 고객들만이 머신 X를 주문할 수 있다.”
각 정책은 한 개 이상의 실행 포인트를 필요로 한다. 실행 포인트는 프로세스나 코드의 특정 위치에서 명확한 단계로서 구현될 수 있다. 실행 포인트는 이벤트를 처리할 때 발생할 수 있다. 규칙들은 정책 실행 포인트를 구현하는 유용한 방식이다. 규칙은 명령적이며 논리적으로 실행가능 하다. Listing 2는 규칙 예제이다.
Listing 2: 간단한 규칙
"If !(location(customer) == "USA") then reject(order);" |
어떤 경우, 정책들은 명확히 명시되지 않고 구현에 의해 임의적으로 정의된다. 다시 말해서, 실제로 구현된 실행 포인트와 규칙들이 정책을 정의한다.
분석가는 각 태스크의 주석 필드에 정책들을 문서화한다. 개발자들은 정책들을 규칙으로 변환한다. 분석가는 서비스 엘리먼트들을 실행 포인트를 제공하는 기존 서비스들을 나타내는 모델에 추가할 수 있다. 분석가들은 정책을 실행 할 코드용 플레이스홀더를 나타내는 태스크들도 추가할 수 있다. 개발자는 이 태스크를 구현하고 정확한 규칙을 실행하기 위해 필요한 코드를 추가할 것이다. (Part 4 참조; 참고자료)
프로세스의 모델링
프로세스의 모델링 작업은 비지니스 프로세스 플로우의 상세(details)를 정의하고 그 플로우가 사용하는 모든 데이터, 리소스, 기타 엘리먼트를 모델링 하는 것이다. 비지니스 프로세스는 제어 플로우를 통해 정상적으로 연결되는 프로세스 단계들로 구성되고 이들 제어 흐름들은 액티비티와 결정 노드를 연결한다. 결정 노드에는 프로세스의 어떤 경로를 따라야 하는지를 결정하기 위해 평가되는 비지니스 규칙들(전송 조건)이 포함된다. 모델링에는 BP를 하위 프로세스로 해체하고 필요한 프로세스 엘리먼트들을 모델에 추가하는 것이 포함된다. 분석가는 기존 모델링 객체들을 적용하여(예를 들어, 서비스 또는 프로세스 엘리먼트) 모델의 구조를 활용 및 속도를 향상시킬 수 있다. "WebSphere Business Integration Modeler를 사용한 비지니스 프로세스 모델링" (“온 디맨드 비지니스 프로세스 수명 주기” 시리즈 중)에는 모델링 객체들로부터 프로세스 모델들을 구현하는 방법을 설명하고 있다. (참고자료)
핵심 퍼포먼스 인디케이터(KPI)의 모델링
핵심 퍼포먼스 인디케이터(KPI)는 비지니스의 중요한 성공 요소들을 트래킹하기 위해 설계된 평가 메커니즘이다. BP 모니터링 기능을 사용하여 프로세스 오너와 관리자들이 실시간으로 KPI를 모니터링 할 수 있다. 이 기능들은 분석가들이 기존 프로세스의 문제들과 병목 현상들을 구분하는데 도움이 된다. 이로써 이 시리즈의 Part 1에서 설명한 개발 과정을 끝낸다. (참고자료) Business Integration Modeler는 KPI를 프로세스에 추가하는 툴을 제공하여 이러한 프로세스들을 트래킹 할 중요한 요소들을 문서화한다. ("WebSphere Business Integration Modeler를 사용한 비지니스 프로세스 모델링" 참조)
기타 모델링 가이드라인
- Business Integration Modeler에는 세 개의 모드들이 있다: FDL, BPEL, Operational. 프로세스가 Business Integration Server Foundation에서 실행되어야 한다면 BPEL 모드에서 모델링을 시작해야 한다. 이는 모델을 반출하기 전에 Error View에서 밸리데이션 에러를 보고 픽스하는데 도움이 된다.
- Advanced Business Modeling 사용자 프로파일은 태스크 실행과 리파지토리 사용을 제어하기 위한 인풋 기준 같은 런타임 요구 사항들을 추가하는데 사용되어야 한다.
- Business Item Modeling Refinements -- 상세 정보 없이 정의되어 새로운 속성 등의 추가 상세 정보로 업데이트 될 수 있는 비지니스 아이템
- Fault Handling은 모델의 일부가 되어서는 안되지만 워크플로우 개발자들에게는 남아있다. (서비스 종료 핸들링)
프로세스 모델 밸리데이션
BPEL 모드에 모델러를 배치하면 BPEL 밸리데이션 체커(checker)가 켜진다. 모든 에러 또는 경고들이 Error View에 나타난다. 이 리스트를 걸러내어 에러 또는 경고를 보여주고 전체 프로젝트에서 선택된 엘리먼트까지 모델 레벨을 선택할 수 있다. 에러와 함께 모델을 반출할 수 있지만 이 에러는 나중에 반출하기 위해서는 결국 픽스되어야 한다.
프로세스 모델 반출
모델러는 Application Developer 툴에 필요한 BPEL, XSD, WSDL 파일들을 반출한다. 기존 서비스 프로젝트 또는 나중에 서비스 프로젝트로 반입하기 위한 폴더로 반출하는 것이다.
그림 3. 생성된 파일들과 프로세스 모델 엘리먼트와의 관계
그림 3은 생성된 파일들과, 이 생성된 파일 안에서의 프로세스 모델 엘리먼트와 이에 상응하는 객체들 간 관계를 보여주고 있다. 예를 들어, 복잡한 비지니스 아이템들은 XSD Complex 유형으로서 생성된다. 전체 비지니스 모델링 프로젝트 또는 프로젝트에서 선택된 부분을 반출할 수 있다. 또 다른 반출 옵션은 프로세스 실행 모드의 선택이다. 세 가지 옵션이 있는데 기본은 Long-running (요청-응답)이다.
프로세스 실행 모드
프로세스 모델을 BPEL 기반의 워크플로우 객체들로 반출할 때는 세 가지 실행 모드를 사용할 수 있다:
- Long-running (수락/응답) -- 이 옵션은 BPEL 워크플로우 모드를 장기 실행 프로세스로 설정하고 프로세스 연산을 인풋과 아웃풋 메시지를 이용한 two-way 연산으로 지정한다. 장기 실행 프로세스들은 인터럽트 방식이기 때문에 프로세스 실행을 인터럽트 하는데 필요한 스태프 개입이나 기타 액티비티들을 실행시킬 수 있다.
- Long-running (콜백으로 수락하기) -- 이 옵션은 BPEL 워크플로우 모드를 장기 실행 프로세스로 설정하여 프로세스 연산을 one-way 연산으로 설정한다. 이것은 인풋 메시지만 받아들인다. 하지만 콜백 연산이 생성되어 프로세스가 그 결과를 호출자에게 리턴할 수 있도록 한다. BPEL 코릴레이션 세트가 만들어지지만 어떤 코릴레이션 속성도 추가되지 않는다. 개발자는 나중에 필요한 속성들을 추가해야 한다.
- Microflows -- 이 옵션은 two-way 메시지들을 수락하는 워크플로우 프로세스 연산을 만든다. 하지만 이 프로세스들은 인터럽트 방식이 아니기 때문에 스태프 액티비티를 프로세스에 추가할 수 없다. 프로세스 모델이 스태프 또는 사람과 관련된 리소스와 역할과 태스크가 포함된다면 이 모델은 스태프 액티비티를 실행한 채로 반출한다. 하지만 반출된 모델은 개발자가 수정해야 하는 밸리데이션 문제를 갖고 있다.
결론
비지니스 분석가의 탑다운 모델링은 온 디맨드 프로세스 수명 주기 방식의 핵심 요소이다. 비지니스 프로세스 모델은 기술 프레임웍을 정의하여 비지니스 스팩과 IT 개발 간 제휴를 도모한다. 공유된 모델은 비지니스 프로세스의 수명이 다할 때 까지 보존되면서 비지니스와 IT를 지속적으로 연결시킨다. 이 글에서는 분석가들이 WebSphere Business Integration Modeler V5.1을 사용하여 비지니스 프로세스를 정의할 때 사용하는 프로세스 모델링 개념을 소개했다. 또한 모델링 가이드라인을 소개하고 Business Integration Modeler에서의 다양한 반출 옵션들과 개발 툴의 인풋으로 사용되는 객체들을 설명했다.
부록
Business Integration Modeler V5.1: 핵심 기능
WebSphere Business Integration Modeler V5.1는 비지니스 사용자들이 비지니스 프로세스의 특정 단계들을 선택해 문서화 할 수 있도록 설계된 사용이 쉬운 툴이다. 핵심 기능들은 다음과 같다:
사용자 프로파일: Business Integration Modeler는 같은 프로세스 모델을 다른 상세들로 보여주는 세 개의 다른 사용자 프로파일들을 제공한다. 이 프로파일들은 기본 프로파일, 중급 프로파일, 고급 프로파일이다. 이 프로파일들은 다양한 사용자들의 역할과 제휴된다. 비지니스 도메인 전문가나 분석가는 비지니스 태스크를 액티비티 시퀀스로 설명하고 있는 기본 프로파일을 사용하고, 나머지 모델 정보는 문서로 파악된다. 중급 프로파일은 데이터 모델, 식, 기본 정보에 대한 세부적인 내용을 갖고 있으며 보다 기술 지향적이며 비지니스 아키텍트에 더 잘 맞는다. 고급 프로파일은 프로세스와 데이터 모델들에 대한 포괄적인 상세 내용을 제공한다. 이 프로파일은 솔루션 아키텍트나 IT 아키텍트에 맞는다. 프로파일을 변경한다고 해서 기저의 데이터 모델이 변경되지는 않는다.
기술 모드: 세 개의 기술 모드가 있다: operational, BPEL, MQ Workflow FDL. 기술적 전문성과 필요한 상세 내용에 근거하여 모드들을 바꿀 수 있다. 일부 옵션과 노테이션 엘리먼트는 어떤 모드에서는 사용할 수 없고, 정확한 모델을 선택하는 것이 목표 워크플로우 실행 환경에 맞는 정확한 객체를 정의하는데 도움이 된다. 모드를 바꾼다고 해서 기저의 데이터 모델이 바뀌는 것은 아니다.
카탈로그: 비슷한 모델링 엔터티들을 논리적으로 그룹핑하는 것이다. 카탈로그에는 다음의 내용들이 포함된다:
- 데이터(주문, 제품 같은 비지니스 아이템)
- 프로세스(주 프로세스, 하위 프로세스, 서비스, 태스크)
- 리소스(고객 서비스 대표, 세일즈 매니저 같은 역할 또는 웹 서버, 애플리케이션 서버 같은 리소스들)
- 조직(조직 계층, 위치)
- 리포트(요약, 비교, 문서화)
이렇게 그룹핑을 하면 모델링 엔터티들의 재상용 비중이 높아진다.
프로세스: 프로세스는 액티비티와 조건의 순서로서, 액티비티들이 수행될 때, 리소스들이 이 액티비티를 수행하는데 요구되며, 액티비티들 간 데이터 흐름과 서비스와의 인터랙션을 수행하는 것이다. 이들 프로세스들은 이 툴에서 제공하는 다이어그램으로 모델링된다.
시뮬레이션: 프로세스 모델 시뮬레이션을 통해, 조직은 프로세스가 다양한 인풋 상황 하에서 어떻게 수행되는지를 관찰 할 수 있다. 이 기능은 인풋을 변경하고, 비용 요소들을 결합하고, 리소스/현재의 애플리케이션들을 조정하는 기능을 제공하여 실제 비지니스 시나리오를 시뮬레이션 할 수 있다. 시뮬레이션을 하면, 프로세스 모델의 중요한 경로, 가장 짧은 경로, 순환 시간, 비용/시간 측정에 대한 분석이 나아진다.
리포팅: 프로세스 분석과 재설계를 위한 가이드라인을 제시한다. 프로세스 요약, 두 개의 프로세스 모델 간 비교 리포트, ROI 평가에 대한 현재와 미래의 비교, 문서화, 프로시저(규칙, 정책, 프로시저) 리포트 등 다양한 리포팅 기능들을 사용할 수 있다.
분석: 프로세스 모델에 수행할 수 있는 두 가지 분석 유형이 있다. 바로 정적 분석과 동적 분석이다. 정적 분석의 경우, 대부분의 정보는 모델에서 추출되어 비용, 시간관리, 퍼포먼스, 프로세스 흐름 유효성, 리소스 등급결정 등을 분석하는데 사용된다. 동적 분석은 아웃풋 로그 또는 이벤트에 근거하여 시뮬레이션 프로세스에서 나온 아웃풋에 대해 수행하는 것이다. 두 가지 종류의 동적 분석이 있다: 통합 분석(프로세스 모델 엘리먼트들의 다중 실행을 기반)과 케이스 분석(프로세스 엘리먼트의 특정 부분에 대해 실행되는 하나의 인스턴스를 사용함)
참고자료
필자소개 | | | Ken Beck은 IBM Global Services Application Management Services Business Transformation Center of Excellence의 컨설턴트이다. |
| | | Joshy Joseph는 IBM Software Group (IBM On Demand Architecture and Development organization)의 소프트웨어 엔지니어이다. |
| | | Dr. Germán Goldszmidt 박사는 IBM Software Group의 선임 기술 스태프이다. |
기사에 대한 평가
| 
