모든 기사
활용 사례2026년 9월 7일 · 4 최소 읽기 시간(분)

일곱 가지 프로세스 시뮬레이션, 상세 계산

간단히 말해

일곱 개의 산출된 예제 모델은 동일한 패턴을 보여줍니다: 처리 시간은 분 단위이고, 소요 시간은 일 단위이며, 병목은 가장 가동률이 높은 단계 앞의 대기 시간으로 구성됩니다. 승인 지급에서는 병목이 실무적 승인에 있고, 견적 프로세스에서는 산출에, 불만 처리에서는 재문의에, 온보딩에서는 일정 연쇄에, 서비스 데스크에서는 두 번째 레벨에, 승인 절차에서는 최고일에, 인사 선발에서는 회신 대기 시간에 있습니다. 일곱 사례 중 다섯 사례에서는 가장 효과적인 수단이 인원 추가가 아니라 변동성 축소였습니다.

Inhaltsverzeichnis

참고: 모든 수치는 고객 자료가 아닌 예시 모델에서 나온 것입니다. 전형적인 규모에 맞게 선택된 값이므로 자체 데이터를 넣으세요. 패턴은 동일합니다.

일곱 개 프로세스, 각기 동일한 형식: 현황, 단계별 가동률, 결과, 가장 효과적인 레버.

1. Rechnungsfreigabe

월 1 200건의 청구서, 다섯 단계, 승인 업무를 14명이 부업으로 분담합니다.

단계처리가동률
스캔2–4 min41 %
ERP 입력6–14 min79 %
내용 승인3–6 min높음, 매우 분산됨
회계코드 지정4–8 min62 %
지급처리주 2회

결과: 처리시간 20–30 min, 리드타임 8–12 근무일. 내용 승인 전 대기만 5–8일이 소요됩니다.

가장 효과적인 레버: 전표 인식이 아닙니다. OCR은 입력을 단축시키지만 승인 단계는 전체 물량을 그대로 받습니다. 병목이 이동해 리드타임은 거의 줄지 않습니다. 금액 기준과 대리 승인 규칙이 더 효과적이며 거의 비용이 들지 않습니다. 자세히.

2. Angebotsprozess

월 60건의 문의, 네 단계, 기술 계산은 두 명의 전문가가 담당합니다.

단계처리처리능력
문의 등록10–20 min영업지원팀
기술 계산2–8 h2명, 프로젝트 업무 병행
상업적 검토30–60 min1명
승인 및 발송15 min영업책임자

결과: 리드타임 P50 = 6일, P90 = 19일. 계산의 분산(단순과 복잡 사이 4배)이 대기시간의 대부분을 만듭니다.

가장 효과적인 레버: 문의를 복잡도별로 분리합니다. 단순한 제안은 가격표로 계산 단계를 우회합니다. P90이 추가 자원 없이 8일로 감소합니다. 이유는 대기시간이 분산의 제곱에 비례해서 커지기 때문입니다. 두 개의 대기열이 섞인 하나보다 낫습니다.

비용 절감보다 가치가 큰 이유: 제안에서는 리드타임이 적중률에 영향을 미치고 비용이 아닙니다. 두 번째로 응답하면 계산한 수주를 잃습니다.

3. Reklamationsbearbeitung

월 400건, 이 중 35 %는 고객 또는 공급사에 재문의가 필요합니다.

결과: 재문의 없는 건: 리드타임 P50 = 1.4일. 재문의 있는 건: P50 = 9일. 혼합하면 평균 4.1일이 되지만 어느 개별 건도 그 평균을 경험하지 않습니다.

소견: 병목은 처리 자체가 아니라 재문의 건이 두 번 대기하는 점입니다. 한 번은 담당자, 한 번은 답변을 기다립니다.

가장 효과적인 레버: 재문의 가속화가 아니라 회피입니다. 접수 폼에 자주 발생하는 세 가지 재문의 사유를 필수 항목으로 넣으면 재문의 비율을 35 %에서 12 %로 낮출 수 있습니다. P50은 2.2일로 감소합니다.

교훈: 서로 완전히 다른 행동을 하는 두 그룹의 평균은 지표가 아니라 위장입니다.

4. 직원 온보딩

월 12명 입사, 참여자 7명(인사, IT, 담당부서, 건물관리, 개인정보보호).

다른 예들과의 차이: 처리량은 매우 적고 각 단계의 가동률은 모두 20 % 미만입니다. 그럼에도 리드타임은 3주입니다.

이유: 부족한 것은 자원이 아니라 일정입니다. 각 단계는 자유로운 처리시간을 기다리는 것이 아니라 담당자가 떠올리는 특정한 날을 기다립니다. 참여자 7명이 각자 이틀의 응답 시간을 가지면 아무도 바쁘지 않아도 2주가 됩니다.

가장 효과적인 레버: 가속이 아니라 병렬화입니다. IT 계정, 출입카드, 책상을 순차가 아니라 이벤트로 동시에 요청되게 합니다. 리드타임 21 → 9일.

5. IT-Service-Desk

월 900건의 티켓, 레벨 2단계, 20 % 에스컬레이션.

단계처리가동률
최초 접수 (Level 1)5–15 min74 %
Level 230–180 min91 %

결과: 티켓의 80 %는 같은 날 종료됩니다. 에스컬레이션된 20 %는 P50 = 4일, P90 = 13일이 소요하며 불만의 대부분을 만듭니다.

가장 효과적인 레버: Level 2를 늘리는 것이 아니라 에스컬레이션 비율을 낮추는 것입니다. 에스컬레이션이 1% 줄면 91% 가동률 단계의 부담이 비례 이상으로 줄어들며, 대기시간이 ρ/(1−ρ)에 따라 감소합니다: 91 %에서 85 %로 떨어지면 대기시간은 절반이 됩니다.

6. 행정의 승인절차

연간 2 400건의 신청서, 매우 불균형적 분포: 두 달에 40 % 몰립니다.

연평균으로는: 가동률 71 %. 건강해 보입니다.

최성수기 주간에는: 가동률 148 %. 그 기간에는 대기열이 매일 증가하고 이를 줄이는 데는 몇 달이 걸립니다. 축소에 사용할 수 있는 것은 용량과의 차이뿐이지 전체 용량이 아닙니다.

결과: 한가한 분기에는 리드타임 9일, 성수기 직후에는 46일. 같은 기관, 같은 인원입니다.

가장 효과적인 레버: 증원보다 앞당기기입니다. 한가한 기간에 신청서의 20 %를 처리(예약, 사전검토, 기한관리)하면 성수기 가동률이 100 % 아래로 내려가고 46일이 사라집니다.

교훈: 계절성이 있는 프로세스에서는 연평균이 가장 오해를 부르는 지표입니다.

7. 채용선발

월 80건 지원, 6개 직무, 면담 일정 조율을 포함한 다섯 단계.

결과: 최초 응답까지 시간 P50 = 8일, P90 = 21일. 지원자 이탈률은 10일째부터 눈에 띄게 상승합니다.

소견: 병목은 검토가 아니라 초면담 일정 조율입니다: 세 명의 캘린더, 2주 전 고지, 고정 규칙 부재.

가장 효과적인 레버: 고정 시간대 지정입니다. 모든 관련자의 캘린더에 주 2시간을 예약해 지원자가 직접 선택하게 하면 P50은 3일로 떨어집니다. 시간 자체는 더 쓰지 않고 분배만 바꾼 것입니다.

일곱 사례의 공통 패턴

예시처리시간리드타임가장 효과적인 레버
Rechnungsfreigabe25 min8–12일금액 기준, 대리 승인
Angebot3–9 h6–19일복잡도별 분리
Reklamation20–40 min1.4 / 9일재문의 회피
온보딩4 h21일병렬화
서비스 데스크15–180 min0 / 4일에스컬레이션 비율 감소
승인절차45 min9 / 46일성수기 완화
채용선발2 h8일고정 시간대

세 가지 관찰:

  1. 처리시간과 리드타임은 보통 두세 가지 크기 차이가 납니다. 처리시간만 개선하는 조치는 잘못된 목표에 집중하는 셈입니다.
  2. 일곱 사례 중 다섯에서는 최고의 레버가 비용이 들지 않았습니다. 분산 축소, 병렬화, 성수기 완화, 재문의 회피 등. 모두 투자 없이 가능한 조치들로 프로젝트화하기에는 매력이 떨어집니다.
  3. 명백한 레버는 거의 예외 없이 최선이 아니었습니다. 인원 증원, 더 빠른 소프트웨어, 더 많은 자동화는 유용하지만 실제 시간이 소비되는 지점에서는 드뭅니다.

자주 묻는 질문

처리시간에 비해 왜 총소요시간이 훨씬 긴가요?

그 사이에 대기하기 때문입니다. 작업은 대부분의 시간 동안 처리 중이 아니라 누군가 용량을 확보할 때까지 바구니에 놓여 있습니다. 행정 프로세스에서는 총소요시간의 90에서 99퍼센트가 대기시간입니다. 따라서 처리만 가속하는 모든 조치는 두 숫자 중 더 작은 쪽에만 영향을 줍니다.

이 수치들이 실제인가요?

이는 고객 데이터가 아닌 예제 모델이며 그렇게 표시되어 있습니다. 규모는 행정 및 서비스 프로세스에서 전형적인 수준에 해당합니다. 가치 있는 부분은 절대값이 아니라 패턴입니다: 사용자의 수량과 용량을 넣어 보세요, 소견의 구조는 대개 유지됩니다.

왜 변동성 감소가 용량 증대보다 더 큰 효과를 내는 경우가 많나요?

대기시간은 변동계수의 제곱에 비례해 증가하기 때문입니다. 변동성을 절반으로 줄이면 대기열에 대한 기여는 네 분의 일로 줄어듭니다. 반면 용량은 ρ/(1−ρ) 요소를 통해 영향하는데 이 요소는 한계에 가까워졌을 때만 강하게 반응합니다. 실무적으로는 유형별로 업무를 분리하고, 입력을 평탄화하며, 재질문을 없애는 것이 보통 추가 인력 한 명을 확보하는 것보다 저렴합니다.

내 프로세스가 온보딩 유형을 따르는지 어떻게 알 수 있나요?

모든 단계의 가동률이 낮은데도 총소요시간이 길다면 그 패턴을 따릅니다. 이 경우 부족한 것은 용량이 아니라 주의력입니다: 각 단계가 누군가가 그것을 떠올리는 날을 기다리고 있습니다. 효과적인 레버는 병렬화와 이벤트에 의한 트리거이지 인력 증가는 아닙니다.

이 모델들은 몇 단계로 구성되어야 하나요?

다섯에서 열 단계가 적절하며, 이는 일곱 예제 모두와 같습니다. 더 세밀하게 모델링해도 병목 위치는 이동하지 않습니다: 병목은 가장 높은 가동률을 가진 곳에 있으며 그 위치는 대략 동일하게 보입니다. 추가 단계는 입력 시간만 늘리고 입력 데이터가 감당하지 못하는 정확성의 인상을 줍니다.

FlowVisual

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

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

Guide: seven steps to the number