비교2026년 9월 11일 · 3 최소 읽기 시간(분)

프로세스 기록 수집 또는 프로세스 시뮬레이션? 각 방법이 할 수 있는 것

간단히 말해

프로세스 도식(흐름도, 스윔레인, BPMN 또는 가치 흐름)은 구조를 설명합니다: 어떤 단계들이 있는지, 누가 수행하는지, 어디서 분기되는지 설명합니다. 이는 문서화, 교육, 감사 및 워크숍에서의 공동 이해를 위한 기초가 됩니다. 여기에 포함되지 않는 것은 부하 하에서의 동작입니다: 도착량, 처리 시간의 분산, 역할별 용량 및 캘린더입니다. 따라서 이것만으로는 개선 프로젝트에서 제기되는 네 가지 질문에 답할 수 없습니다: 병목이 어디에 있는지, 최악의 경우 소요 시간이 얼마인지, 조치 후 병목이 어디로 이동하는지 및 그 조치의 가치가 얼마인지입니다. 8단계로 된 도식은 대략 20분 만에 계산 모델이 됩니다.

Inhaltsverzeichnis

프로세스 기록이 하는 일

대부분 계산하려는 사람들은 그 가치를 과소평가합니다. 공동의 그림:

현실에 대한 논쟁을 끝냅니다. 동일한 프로세스를 부서마다 다르게 설명하던 둘이 도해에서야 차이를 알게 됩니다.
책임을 가시화합니다. 스윔레인은 인수인계를 보여주며 인수인계 지점이 작업이 머무는 장소입니다.
문서화, 교육, 감사 및 소프트웨어 개발의 기반입니다. 계산 모델은 이를 대신할 수 없습니다.
거의 비용이 들지 않습니다 워크숍에서 만들어지며 프로젝트에서 나온 것이 아닙니다.

널리 쓰이는 형태들은 지지자들이 주장하는 것만큼 많이 다르지 않습니다:

형식	강점	맹점
흐름도	즉시 이해 가능, 교육 불필요	역할 없음, 시간 없음
스윔레인	인수인계와 책임 가시화	수량 없음, 처리능력 없음
BPMN 2.0	표준화되어 교환 가능, 실행에 가깝다	부하 상황에서의 동작이 완전히 빠져 있음
가치흐름도 (VSM)	재고와 대기시간 포함	순간 포착, 변동 없음
SIPOC	빠른 범위설정, 프로젝트 시작에 적합	매우 대략적, 흐름 논리 없음

가치흐름도가 계산에는 가장 가깝습니다: 대기시간과 재고를 포함합니다. 그러나 그것은 특정 작업의 어느 하루를 기준으로 측정하므로 성수기 하루에 무슨 일이 일어나는지는 답하지 못합니다.

어떤 기록에도 적히지 않는 것들

표기법과 무관하게 네 가지 정보:

도착량과 그 변동성. “하루 120건”과 “월초 180건”은 어떤 도해에도 나오지 않습니다.
처리시간의 분산. “10분”이라고 적힌 상자는 평균입니다. 대기열은 평균이 아니라 분포의 폭에서 생깁니다.
역할별 처리능력. 세 사람 곱하기 일곱 생산시간. 이 숫자 없이는 활용도를 계산할 수 없습니다.
근무일정과 비용. 언제 일하는지, 해당 역할의 시간당 비용이 얼마인지.

이 네 가지 없이는 어떤 도해도 계산될 수 없습니다. 어떤 도구로 열리든 마찬가지입니다. BPMN의 시뮬레이션 모듈도 예외가 아니며, 거기서도 이 값들을 별도 대화상자에 입력합니다. 자세한 내용은 BPMN-Simulation를 보세요.

그림이 실패하는 네 가지 질문

“병목은 어디인가?” 도해에서는 모든 상자가 똑같아 보입니다. 병목은 가장 높은 활용도를 가진 단계이고 활용도는 그림의 속성이 아닙니다.

“나쁜 경우에는 얼마나 오래 걸리나?” 도해에는 분포가 없습니다. P50과 P90의 차이를 알 수 없으며 약속은 P90을 기준으로 이루어집니다.

“3단계를 자동화하면 무슨 일이 생기나?” 도해에서는 상자가 사라집니다. 현실에서는 전체 물량이 다음 단계로 쏟아지고 병목이 그곳으로 이동합니다. 이런 후속 효과가 자동화 프로젝트가 목표를 못 맞추는 가장 흔한 이유입니다.

“그것의 유로 환산 가치는 얼마인가?” 이를 위해서는 수량, 시간, 요율과 함께 비용의 많은 부분이 들어있는 대기열을 알아야 합니다.

언제 기록만으로 충분한가

모든 프로세스에 계산 모델이 필요한 것은 아닙니다. 다음 경우에는 기록만으로 충분합니다:

아무도 기다리지 않는다. 프로세스가 처리능력 한계보다 훨씬 낮게 운영되면 처리시간이 곧 통과시간입니다. 이때는 덧셈이 시뮬레이션보다 더 정직합니다.
목표가 문서화일 때. 감사, 교육, 인수인계, 증빙 의무.
프로세스가 새로 설계되어 아직 아무 수치도 없을 때. 먼저 그립니다, 그다음 수치를 수집하고, 그다음 계산합니다.
이미 결정이 내려진 경우. 내린 결정을 입증하려는 모델은 분석이 아니라 장식입니다.

그림에서 모델로: 절차

전환 비용은 대부분이 생각하는 것보다 적습니다. 단, 도해를 그대로 옮기려는 충동을 억제해야 합니다.

대강 요약합니다. 문서화에 적합한 기록에는 대개 30개 활동이 있지만 계산 모델에는 5~10개가 필요합니다. 동일한 역할이 연속으로 수행하는 것은 묶으세요.
분기점을 실제 분기로 줄입니다, 모든 특수 케이스를 넣지 말고 간선별 비율을 사용하세요.
중단 경로를 보완하세요. 프로세스를 떠나는 모든 것(거부, 철회, 방치). 기록에는 거의 항상 빠져 있고 계산에서는 결정적입니다.
네 가지 누락 정보를 확보하세요. 이것이 실제 작업입니다: 중간 규모 프로세스에 약 두 시간 걸립니다.
계산하고 Little's Law로 검증하세요. 재고 ÷ 일일 처리량을 계산된 통과시간과 비교합니다.

전환에 20분, 데이터 수집에 두 시간 정도를 잡으세요. 이런 비율을 알게 되면 사람들은 도해를 비싼 부분으로 여기지 않게 됩니다.

병행 비교

	프로세스 기록	프로세스 시뮬레이션
답하는 질문	어떻게 운영되나?	부하 상황에서 무슨 일이 발생하나?
포함	구조, 역할, 분기	추가로 수량, 분포, 처리능력, 근무일정
출력	도해	처리량, 통과시간(범위), 활용도, 비용
수명주기	수년, 버전 관리됨	수주, 의사결정용
세부 수준	20–30 활동	5–10 단계
노력	몇 시간	반나절, 주로 데이터 수집
실패 원인	모든 수치 관련 질문	문서화가 되려는 요구

실용 규칙: 둘 다 하되 순차적으로 하세요, 동일한 산출물에 동시에 담으려 하지 마세요. 문서화와 계산 모델을 동시에 하려는 도해는 둘 다에 대해 너무 세밀하거나 너무 대략합니다.

자주 묻는 질문

BPMN 다이어그램에서 바로 시뮬레이션을 만들 수 있습니까?

추가 정보 없이는 안 됩니다. BPMN은 구조를 설명합니다; 계산에는 도착량, 산포, 용량 및 캘린더가 필요합니다. 시뮬레이션 모듈이 있는 도구는 이러한 값을 자체 대화상자에서 묻습니다. 가져오기는 구조를 가져오지만 데이터를 가져오지는 않습니다. 데이터가 일입니다.

가치흐름 분석만으로는 충분하지 않습니까?

계산에 가장 가깝습니다. 재고와 체류 시간을 관리하기 때문입니다. 하지만 부족한 것은 변동입니다: 전형적인 작업을 하루에 측정합니다. 또한 연쇄를 보여주지 않습니다: 병목 뒤의 단계는 병목이 내보내는 것만 받기 때문에 한가해 보이고, 병목이 해결되면 스스로 병목이 됩니다.

계산 모델은 얼마나 상세해야 합니까?

다섯에서 열 단계입니다. 이는 문서화할 수준의 상세한 기록보다 훨씬 거친 수준이며 의도된 것입니다: 병목은 가장 높은 가동률을 보이는 지점에 있고, 거친 모델링에서도 그 지점은 동일하게 보입니다. 각 추가 활동은 결과를 바꾸지 않으면서 입력 필드를 늘립니다.

우리는 이미 200개의 프로세스를 문서화했습니다. 이들을 모두 시뮬레이션할 수 있습니까?

그럴 일은 드뭅니다. 시뮬레이션은 작업이 대기하고 의사결정이 필요한 곳, 보통 동시에 소수의 프로세스에서만 가치가 있습니다. 나머지 195개의 문서는 문서로서의 가치를 유지합니다. 당면한 의사결정이 없는 모델은 수고만 들고 수익은 없는 유지 관리입니다.

시뮬레이션이 프로세스 기록을 대체합니까?

아니요. 기록은 프로세스가 어떻게 진행되는지 밝히고 공동의 기반을 만듭니다. 기록 없이 모델링하면 참여자들이 동의하지 않는 흐름을 모델링하는 셈입니다. 시뮬레이션은 그 위에 구축되어 부하, 병목 및 효과에 대한 질문에 답합니다. 둘은 서로 다른 독자층과 다른 수명을 가집니다.

FlowVisual

자신의 프로세스로 직접 계산해 보세요

FlowVisual은 이 글의 수치를 귀하의 수량, 귀하의 용량, 귀하의 마진을 반영한 실행 가능한 모델로 만듭니다.

Mac App Store에서 받기 Microsoft Store에서 받기

Guide: seven steps to the number

계속 읽기