시뮬레이션이 가능한 BPMN 도구: 표기법이 계산할 수 있는 것과 아닌 것

Inhaltsverzeichnis+

도구 선택에서 잘못된 결정을 자주 유도하는 문장이 하나 있습니다: “우리 BPMN 도구로도 시뮬레이션이 됩니다.” 이 말은 대부분 사실이지만 거의 쓸모가 없을 때가 많습니다. 왜냐하면 그것은 타당성 검사부터 완전한 이벤트 시뮬레이터까지 무엇이든 의미할 수 있기 때문입니다.

원인은 표기법 자체에 있습니다.

BPMN이 기술하는 것과 기술하지 않는 것

BPMN 2.0은 프로세스의 구조에 대한 OMG 표준입니다: 작업, 이벤트, 게이트웨이, 레인, 메시지 흐름입니다. “어떤 일이 어떤 순서로 발생하고 누가 하는가?”라는 질문에 대해 완전하고 정확하게 답합니다.

계산을 위해서는 표기법에 애초에 포함되지 않은 다섯 가지 정보가 부족합니다:

1. 도착 프로세스. 얼마나 많은 건이 도착하는지, 그리고 그것들이 어떻게 분포하는지입니다. 하루에 스무 건이 고르게 도착하는 것과 월요일 아침 한꺼번에 스무 건이 도착하는 것은 전혀 다른 그림을 만듭니다.
2. 처리시간의 분산. 단순히 “10분”이 아니라 “5에서 20분, 대부분은 8분”과 같은 정보입니다. 분산이 대기열을 좌우하는 요인이지 평균값이 아닙니다.
3. 자원별 용량. 몇 명이 어떤 근무비율로 일하는지, 어떤 역할들이 하나의 풀을 공유하는지입니다.
4. 분기 확률. XOR 게이트웨이는 분기된다는 것만 보여줍니다. 어느 경로가 얼마나 자주 선택되는지는 다이어그램 어디에도 나와 있지 않습니다.
5. 캘린더. 하루 8시간, 공휴일, 교대 근무 등입니다. 금요일 16:50에 도착한 건은 10분을 기다리는 것이 아니라 3일을 기다립니다.

BPSim은 바로 이 문제를 위해 만들어졌습니다. WfMC의 표준은 시뮬레이션 파라미터를 BPMN 모델에 부속하도록 정의하며 표기법 자체는 바꾸지 않습니다. 이 표준의 존재 자체가 BPMN만으로는 계산할 수 없다는 최고의 증거입니다.

BPMN 도구들의 시뮬레이션 모듈이 일반적으로 제공하는 것

널리 쓰이는 모델링 스위트(Bizagi Modeler, SAP Signavio, ARIS 등)는 단계별 기능으로 시뮬레이션을 제공합니다. 제조사와 무관한 일반적인 구성은 다음과 같습니다:

• 구조 검사. 토큰이 모델을 통과하는지, 막다른 길이나 절대 도달하지 않는 분기가 있는지를 확인합니다. 유용하지만 좁은 의미의 시뮬레이션은 아닙니다.
• 시간 분석. 작업별 소요 시간에서 처리 시간을 산출합니다. 아직 용량 한계가 없으므로 대기열은 고려하지 않습니다.
• 자원 분석. 이 단계에서야 흥미로워집니다: 인원과 용량을 정의하면 대기열과 가동률이 나타납니다.
• 캘린더 분석. 근무 시간과 교대가 반영되어 실제적인 대기시간이 산출됩니다.

Camunda는 의도적으로 이 목록에 포함되지 않습니다: Camunda는 실행 엔진이지 시뮬레이션 환경이 아닙니다. 실제 건이 프로세스를 통과하도록 하고 그것을 측정합니다. 이는 어떤 시뮬레이션보다도 가치가 있습니다. 다만 프로세스가 이미 자동화되어 실제로 운영될 때만 그렇습니다. 의사결정 이전에는 도움이 되지 않습니다.

도구에 던질 다섯 가지 질문

모델링 도구를 열고 10분 안에 다음을 확인하세요:

1. 소요 시간을 범위로 입력할 수 있습니까? 해당 필드가 숫자 하나만 허용하면 도구는 평균값으로 계산합니다. 그러면 결과가 체계적으로 과도하게 유리하게 나옵니다. 대기열은 분산에서 생기고, 분산이 없으면 대기열도 생기지 않습니다.

2. 범위가 있는 결과를 받습니까? “처리시간 6.4일”은 진술이 아니라 숫자 하나입니다. “P10 4.1에서 P90 11.8일”은 진술입니다. 점 추정값만 내놓는 도구는 결정론적으로 계산했거나 스프레드를 숨긴 것입니다.

3. 역할들이 용량을 공유합니까? 현장에서는 동일한 사람이 세 가지 다른 단계를 수행합니다. 작업별로 용량을 관리하는 도구는 각 단계를 여유 있게 계산합니다. 세 가지를 모두 수행하는 사람은 어느 단계에서도 여유롭지 않습니다.

4. 최고 성수기 하루를 보나요 아니면 월평균을 보나요? 월평균에서는 거의 모든 역할의 가동률이 80% 이하일 수 있습니다. 하지만 최고 성수기 하루에는 정확히 그 지점에서 프로세스가 붕괴합니다. 가동률 수치가 어떤 기준을 말하는지 밝히지 않으면 무의미합니다.

5. 개선 비용과 기대 효과는 얼마입니까? 거의 모든 모델링 도구가 이를 답하지 못합니다. 비용율과 투자비가 모델의 일부가 아니기 때문입니다. 하지만 이 숫자가 프로젝트 여부를 결정합니다.

좋은 모듈도 멈추는 지점

도구가 다섯 가지 검사를 모두 통과한다고 가정해도 마지막 질문이 남습니다. 대부분의 분석은 기술적 한계 때문이 아니라 아무도 이 질문을 하지 않기 때문에 실패합니다:

병목이 해결되면 그 병목은 어디로 옮겨가겠습니까?

누구나 아는 예시가 있습니다: 검사가 너무 오래 걸려 자동화하기로 했습니다. 시뮬레이션은 검사 시간이 80% 줄어든다고 확인해 줍니다. 그런데 시뮬레이션이 자주 보여주지 않는 사실은 이렇습니다: 그 뒤의 승인 단계는 그간 매 26분마다 한 건을 받았는데, 검사가 더 이상 병목을 만들지 않으면서 이제 매 10분마다 한 건을 받게 되어 과부하가 됩니다. 처리량이 약속대로 늘지 않고, 절약된 시간이 새로운 대기열로 들어갑니다.

이것은 예외적 사례가 아니라 규칙입니다. 병목은 사라지지 않고 이동합니다. 이 이동을 초 단위로 재생할 수 없는 모델로는 실제 운영에서 발생하지 않는 비즈니스 케이스를 만들게 됩니다.

실무적 권고

• 이미 시뮬레이션 모듈이 있는 모델링 스위트가 있습니까? 있다면 그것을 사용하세요. 두 번째 도구는 다섯 가지 질문 중 하나에서 실패할 때만 가치가 있습니다.
• 지금 막 모델링을 시작하십니까? BPMN으로 시작하지 마세요. 이 표기법은 문서화를 위해 만들어졌습니다. “어디가 막히고 변경이 무엇을 가져오는가?”라는 질문에는 먼저 배워야 하는 언어를 거치는 우회로가 됩니다.
• 투자 근거를 마련해야 합니까? 그러면 범위, 최고 성수기 하루, 공유 자원 풀, 그리고 전후 비교의 유로화가 필요합니다. 새 도구를 사기 전에 현재 보유한 도구 중 어떤 것이 이를 제공하는지 확인하세요.

FlowVisual은 의도적으로 BPMN을 포기했습니다: 하나의 표기법 대신 여섯 개의 구성요소, 범위로 표현한 소요시간, 최고 성수기에서의 가동률, 공유 풀을 제공합니다. 결과는 P10–P90 스프레드가 있는 전후 비교의 유로화입니다. BPMN을 문서화 용도로 필요로 하는 사람은 이를 대체하지 못합니다. FlowVisual은 다른 질문에 답합니다.