BPMN은 흐름을 설명합니다. 시뮬레이션에는 네 가지 추가 정보가 필요합니다

“BPMN 2.0이 설명하는 것:” 활동, 이벤트, 게이트웨이, 시퀀스 플로우, 풀과 레인, 메시지, 서브프로세스입니다. 즉 흐름의 구조입니다. 완전하고 표준화되어 있으며 도구 간 교환 가능합니다.

“BPMN 2.0이 설명하지 않는 것:” 부하 하에서의 동작입니다. 구체적으로 네 가지 정보가 빠져 있습니다:

WfMC 확장인 “BPSim”(Business Process Simulation Interchange Standard)은 바로 이를 위해 만들어졌습니다: 이 매개변수들을 BPMN 파일에 별도 섹션으로 추가합니다. 현실적으로 보급률은 제한적입니다. 대부분의 도구가 시뮬레이션 매개변수를 자체 필드에 저장하므로 도구를 바꿔도 다시 입력해야 하는 수고를 줄여주지는 않습니다.

“프로젝트에 대한 결론:” BPMN 다이어그램을 가져오면 구조는 절약되지만 데이터는 절약되지 않습니다. 그리고 데이터가 실제 작업입니다.

도구를 결정하기 전에 공급자에게 물어야 할 세 가지 질문:

1. 시뮬레이션이 이 에디션에 포함되어 있습니까, 아니면 더 비싼 에디션에 포함되어 있습니까?
2. 점유된 단계 앞의 대기열을 모델링합니까, 아니면 경로를 따라 처리 시간만 합산합니까?
3. 결과를 구간으로 받습니까 (P10–P90) 아니면 단일 수치로 받습니까?

질문 2에서 범주가 갈립니다: 경로 소요 시간을 단순 합산하는 도구는 결과를 “Durchlaufzeit”라고 부르지만 실제로는 처리 시간을 의미합니다. 행정 프로세스에서는 그 차이가 보통 세 배보다 작지 않습니다.

BPMN 다이어그램은 프로세스를 알아야 하는 사람과 시스템을 위한 것입니다: 품질 관리, 감사, 교육, 소프트웨어 개발이 해당됩니다. 다이어그램은 수년 동안 유지되며 버전 관리됩니다.

계산 모델은 의사 결정을 위한 것입니다: 이 자동화가 가치가 있는지, 프로세스가 두 배의 처리량을 견디는지, 어디에서 반 인력(halbe Stelle)을 채용할지 판단합니다. 계산 모델은 수주 동안 유지되며 결정이 내려지면 폐기됩니다.

일반적인 절차:

1. 문서화가 필요한 경우 BPMN으로 프로세스를 문서화합니다. 구조, 책임, 예외 사항을 기록합니다.
2. 의사 결정을 위해 대략적인 계산 모델을 구축합니다: 다섯에서 열 단계, 서른 단계가 아닙니다. 병목은 거의 세부 사항에 있지 않습니다.
3. 수량, 범위, 용량 및 단가를 입력합니다. 이것이 BPMN이 대신해 주지 않는 작업입니다.
4. 계산하고 현황을 확보한 뒤, 한 가지 지렛대를 변경해 비교합니다.
5. 결과로 의사 결정을 정당화하고 문서화를 위해 다이어그램을 보관합니다.

절차 2를 절차 1과 같은 도구에서 수행하면 도구 전환을 절약하는 대신 다음을 감수하게 됩니다: 과도한 상세화 압박. 문서화에 적합한 다이어그램은 서른 개의 활동을 가지지만, 계산 가능한 모델은 열 개가 필요합니다. 추가되는 각 활동은 입력 필드 다섯 개의 비용을 발생시킵니다.

FlowVisual은 시작, 작업, 결정, 병합, 중단 및 종료를 인식합니다. 풀(pool), 레인(lane), 메시지 이벤트, 서브프로세스 마커, 표기법 검사 기능은 없습니다.

비용: 여기서 제공되는 것은 규격에 맞는 프로세스 문서가 아닙니다. 품질관리에서 BPMN-2.0 다이어그램을 요구한다면 BPMN 도구가 필요합니다. 그 점은 피할 수 없습니다.

효과: 실무 부서는 표기법이 아니라 프로세스 자체에 대해 워크숍에서 논의합니다. 모델 한 개가 두 시간이 아니라 열 분 안에 완성됩니다. 그리고 제공되는 모든 입력 필드는 결과를 바꾸는 항목들입니다: 수량, 범위, 용량, 역할, 시스템, 세트.

정직한 경험칙:

• 규격이나 감사 문서를 충족하는 문서가 필요하다 → BPMN 도구.
• 의사결정자가 서명할 숫자가 필요하다 → 계산 모델, 표기법은 부수적입니다.
• 두 가지가 모두 필요하다 → 둘 다 필요하지만 순차적으로, 같은 산출물에 같이 넣지는 마세요.

이 비교의 장문 버전은 기사 BPMN-Tool mit Simulation에 나와 있습니다.