태스크 지정에 대한 책임

과정을 읽는 것은 마치 책을 읽는 것과 같다. 특정 방향을 따르며 왼쪽에서 오른쪽으로, 위에서 아래로 읽는다. 학습 BPMN은 언어를 배우는 것과 비슷합니다. 모든 BPMN 요소는 단어 do와 같이 특정한 의미를 갖는다. 프로세스 언어로 말할 수 있고 심지어 생각할 수 있는 노력도 가치가 있습니다.

배고픈 상태라고 가정하면 기본 BPMN 요소를 사용하여 배고픔을 만족시키는 목표에 도달하기 위해 해야 할 일을 설명하는 프로세스를 생성해 보겠습니다.

• 프로세스를 트리거하는 요인을 설명하는 시작 이벤트입니다.
• 순서 흐름 - 프로세스와 태스크를 안내합니다.
• 우리가 해야 할 일을 설명하는 작업.
• 프로세스 종료 시 도달한 상태를 설명하는 종료 이벤트입니다.

비즈니스 프로세스가 대리점 운영이라고 가정해 보십시오.

프로세스 내에서 대리석이 따라야 하는 흐름이 있습니다. 프로세스를 통해 대리석을 멈출 수 있는 유일한 것은 태스크입니다. 여기서 대리석은 작업이 적용될 때까지 기다려야 합니다. 결국 우리는 모든 흐름이 끝 이벤트에 도달할 수 있도록 해야 합니다. 따라서 대리석은 항상 결승선을 통과할 수 있습니다. 대리석이 도착하지 않으면, 우리는 뭔가 잘못이 있다는 것을 알고 그 흐름이 어딘가에 중단되었다.

대리석 예제는 '토큰'의 BPMN 개념을 쉽게 생각할 수 있는 방법입니다. BPMN에서는 대리석을 공식적으로 토큰이라고 합니다. 토큰 개념은 비즈니스 프로세스가 얼마나 복잡하든 비즈니스 프로세스의 실행 동작을 설명합니다.

이 아이디어를 파악하면 비즈니스 프로세스 흐름, 특히 프로세스 실행 동작을 점검할 때 오류 메시지를 이해하는 데 도움이 됩니다.

이러한 '기술적 점검'이 중요하지 않다고 생각되는 경우, 모델이 시스템에서 실행되지 않기 때문에 해당 모델이 중요합니다.

동일한 개념이 다음 항목에 적용됩니다.

• BPMN 구문 점검(다이어그램을 저장할 때마다 적용됨)
• 프로세스 시뮬레이션(토큰을 시각화할 수도 있는 경우)

토큰 개념을 제대로 적용하면 아무리 복잡한 BPMN 프로세스 모델을 이해할 수 있습니다.

한 회사의 여러 사람이 프로세스 모델링에 관여할 때마다 이름 지정과 일관성을 유지하는 것이 중요합니다. 다행히도 모든 BPMN 프로세스가 동일한 범용 스타일을 따르도록 하는 작업과 이벤트에 대한 명명 규칙이 있어 전 세계에서 이해됩니다.

태스크 및 이벤트에 대한 명명 규칙은 BPMN의 Best Practices를 기반으로 하므로 엄격한 정책 또는 규칙으로 인식되지 않습니다. 모델러가 적절하게 정당화되고 의미 있고 이해할 수 있으면 이를 벗어날 수 있습니다.

그렇다면 어떻게 이벤트 이름을 적절하고 일관되게 지정할 수 있을까요? IS 상태를 식별하는 데 도움이 되는 규칙이 있습니다. 실제로 명명 이벤트의 잠재적 시그널 단어는 다음과 같습니다.

• [수요]이(가) 발생했습니다.
• [오더]이(가) 수령되었습니다.
• [서비스]를 사용할 수 있습니다.
• [송장]이(가) 생성되었습니다.
• ...

"is"라는 용어를 사용할 필요는 없지만 IS 상태를 실제로 설명하는 데 도움이 됩니다.

비즈니스 태스크는 직접 또는 기술적으로 리소스에 의해 수행됩니다.

실제 세계에 이어 BPMN은 풀(Pool)과 레인(Lane)이라는 모델링 목적으로 기억하기 쉬운 또 다른 개념을 사용한다. 이 개념은 비즈니스 프로세스에서 책임을 모델링하는 데 사용됩니다. 이 레인은 수영장과 수영 레인으로 비교할 수 있습니다. 실제로 수영장처럼 보입니다.

풀(pool)과 레인(lane) 개념을 통해 태스크를 다른 방식이 아닌 책임에 지정할 수 있습니다. 이는 모든 작업이 누군가에 의해 수행되고, 동일한 사람을 여러 작업에 할당할 때마다 번거롭기 때문에 더 의미가 있습니다(EPC와 같은 표기법의 경우).

풀은 일반적으로 프로세스가 수행되는 전체 조직을 나타냅니다.

레인은 태스크 적용에 대한 실제 책임을 나타내며 역할, 부서, 포지션, 심지어 지명된 사람일 수도 있습니다(권장되지 않음).

일반적으로 풀의 각 레인은 지정된 모든 태스크를 적용해야 합니다. 순서 흐름은 태스크를 연결하므로 레인 교차도 정보 전달 및 실행 책임으로 간주할 수 있습니다. 따라서 참가자들은 서로 교류하고 소통해야 한다.

풀과 레인의 용도는 숙박시설을 공유하는 두 동료인 티미와 로버트의 다음과 같은 이야기로 설명된다.

티미는 인터넷에서 새로운 레시피를 찾았다. 그러나, 티미는 아주 잘 요리할 수 없다. 다행히 그의 플랫메이트 로버트는 요리를 좋아하며 새로운 레시피를 시도하게 되어 행복하다. 그러나 맛있는 저녁을 요리한 후, 로베르트는 너무 배고프어서 더 이상 팀(그의 맘과 통화하던)을 기다릴 수 없었다. 그래서 그는 혼자 저녁을 먹기 시작했다.

Tim(레인):

• 식료품 구매

로버트(레인)

• 저녁 식사 준비
• 저녁 식사 식사(Tim은 참여하지 않음)

Robert가 이미 먹고 있는 동안, Tim은 그의 전화 통화 중에 저녁 식사를 치우고 부엌으로 갔습니다 - 단지 시간에! 이제 둘 다 함께 먹을 수 있습니다.

로버트(레인)

• 저녁 식사 준비
• 저녁 식사 식사

시간(추가 프로세스 참가자)

• '저녁 식사' 태스크에도 참여합니다.

우리는 우리의 저녁 식사 eexample에서 관찰한 것을 결론 보자:

• 책임(레인)은 하나의 조직(풀)에 속합니다(예: 공유 숙박 시설).
• 다음과 같은 프로세스 모델에서 태스크에 대한 책임을 시각화할 수 있습니다.
  • 있습니다.
  • 추가 프로세스 참여자를 통해 액세스할 수 있습니다.

태스크에 지정된 참가자가 더 많지만 이 태스크를 소유한 주요 책임은 한 명이어야 합니다. 다른 배정된 모든 참가자가 함께 참여하도록 하는 사람을 생각할 수 있습니다.

아래에서 스윔 레인에 대한 명명 규칙의 가능성을 찾아보십시오. 이 그림에 사용된 모든 명명 스타일이 올바르며 가능하면 "사람" 스타일을 피해야 하지만 조합으로도 사용할 수 있습니다.