2016-07-25 10 views
1

나는 회사를위한 프로세스를 모델링하고있다. 이 과정에는 클라이언트에게 메시지를 보내는 작업이 포함됩니다. 이제이 고객은 응답으로 동의하거나 거절하거나 다른 제안을 할 수 있습니다. 오류 이벤트에서 루프백 할 수 있습니까? - BPMN

내가 이렇게 같은 과정을 모델링 한이를 잡으려고 :

Loop on error

잘 모르겠어요이 모델링의 올바른 방법 인 경우. 그것은 가장 이해하기 쉬운 방법으로 보이지만, 모델링이 나의 학사 학위 논문의 일부이기 때문에 나는 이것을 올바르게해야합니다.

미리 답변 해 주셔서 감사합니다.

편집 :

가 당 Drux의 피드백이 나는과 같이 모델을 변경 :

Remodeled process

이 모델은 부당 오류 이벤트 페지 각각의 결과가 자신의 경로입니다 가지고 있도록한다 . 이것은 더 이해하기 쉬워야합니다.

+0

나는 당신의 모델의 약점을 지적하고 싶다. 클라이언트가 응답하지 않으면 프로세스 인스턴스가 계속 멈추게됩니다. 이 가능성을 다루는 것에 대해 생각해야합니다. – elnin0

답변

1

모델이 올바른 것처럼 보입니다. 원래의 질문이었던 BPM 관점에서는 괜찮습니다. "무슨 일이 벌어지고 있는지"관점에서 볼 때 그것은 나에게 조금 떨어져 보인다.

우선이 메시지를 읽으면 클라이언트에게 메시지를 보낸 직후에 "약속을 확인합니다"라는 인간 활동이있는 것처럼 보입니다. 클라이언트가 아직 응답하지 않은 것을 감안할 때 그것은 잘못되었다고 생각합니다. 둘째 당신은 오류라고 생각하지 않는 오류 이벤트를 사용하고 있습니다. 예를 들어 사용자가 3 가지 방식으로 응답 할 수 있으므로 예상되는 응답에 오류가 발생하면 오류가 발생합니다.

위의 설명을 바탕으로 고객에게 통지를 보낸 직후에 메시지 이벤트를 기다리는 것으로 모델링했습니다. 이것은 "클라이언트 응답"이 될 것이고이 중간 메시지 이벤트는 고객이 응답 한 방식 ("확인", "거절", "카운터 제안")에 따라 정확한 다음 단계로 이동하는 결정 게이트웨이로 이동합니다. 이런 식으로 고객의 응답을 기다리는 동안 "Aletha"수영 차선에서 작동해서는 안되는 활동이 없습니다.

+0

귀하의 책임에 감사드립니다! BPMN을 처음 접했을 때 나는 이런 식으로 생각하지 않았습니다. 그러나 이제는 여러 가지 옵션이 분명해 보입니다. 의사 결정 게이트웨이가 분명히 필요합니다 ... 내가 리모델링하고 내 질문을 업데이트 할 것입니다. –

+0

피드백에 따라 모델을 변경하고 질문에 추가했습니다. 다시 한 번 감사드립니다! –

+1

훨씬 쉽게 이해할 수 있습니다. 나는 이제 너무 많은 문맥을 필요로하지 않고 흐름을 따라갈 수 있다고 생각한다. – Drux