일곱 가지 프로세스 시뮬레이션, 상세 계산
일곱 개의 산출된 예제 모델은 동일한 패턴을 보여줍니다: 처리 시간은 분 단위이고, 소요 시간은 일 단위이며, 병목은 가장 가동률이 높은 단계 앞의 대기 시간으로 구성됩니다. 승인 지급에서는 병목이 실무적 승인에 있고, 견적 프로세스에서는 산출에, 불만 처리에서는 재문의에, 온보딩에서는 일정 연쇄에, 서비스 데스크에서는 두 번째 레벨에, 승인 절차에서는 최고일에, 인사 선발에서는 회신 대기 시간에 있습니다. 일곱 사례 중 다섯 사례에서는 가장 효과적인 수단이 인원 추가가 아니라 변동성 축소였습니다.
Inhaltsverzeichnis
참고: 모든 수치는 고객 자료가 아닌 예시 모델에서 나온 것입니다. 전형적인 규모에 맞게 선택된 값이므로 자체 데이터를 넣으세요. 패턴은 동일합니다.
일곱 개 프로세스, 각기 동일한 형식: 현황, 단계별 가동률, 결과, 가장 효과적인 레버.
1. Rechnungsfreigabe
월 1 200건의 청구서, 다섯 단계, 승인 업무를 14명이 부업으로 분담합니다.
| 단계 | 처리 | 가동률 |
|---|---|---|
| 스캔 | 2–4 min | 41 % |
| ERP 입력 | 6–14 min | 79 % |
| 내용 승인 | 3–6 min | 높음, 매우 분산됨 |
| 회계코드 지정 | 4–8 min | 62 % |
| 지급처리 | 주 2회 | — |
결과: 처리시간 20–30 min, 리드타임 8–12 근무일. 내용 승인 전 대기만 5–8일이 소요됩니다.
가장 효과적인 레버: 전표 인식이 아닙니다. OCR은 입력을 단축시키지만 승인 단계는 전체 물량을 그대로 받습니다. 병목이 이동해 리드타임은 거의 줄지 않습니다. 금액 기준과 대리 승인 규칙이 더 효과적이며 거의 비용이 들지 않습니다. 자세히.
2. Angebotsprozess
월 60건의 문의, 네 단계, 기술 계산은 두 명의 전문가가 담당합니다.
| 단계 | 처리 | 처리능력 |
|---|---|---|
| 문의 등록 | 10–20 min | 영업지원팀 |
| 기술 계산 | 2–8 h | 2명, 프로젝트 업무 병행 |
| 상업적 검토 | 30–60 min | 1명 |
| 승인 및 발송 | 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 min | 74 % |
| Level 2 | 30–180 min | 91 % |
결과: 티켓의 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일로 떨어집니다. 시간 자체는 더 쓰지 않고 분배만 바꾼 것입니다.
일곱 사례의 공통 패턴
| 예시 | 처리시간 | 리드타임 | 가장 효과적인 레버 |
|---|---|---|---|
| Rechnungsfreigabe | 25 min | 8–12일 | 금액 기준, 대리 승인 |
| Angebot | 3–9 h | 6–19일 | 복잡도별 분리 |
| Reklamation | 20–40 min | 1.4 / 9일 | 재문의 회피 |
| 온보딩 | 4 h | 21일 | 병렬화 |
| 서비스 데스크 | 15–180 min | 0 / 4일 | 에스컬레이션 비율 감소 |
| 승인절차 | 45 min | 9 / 46일 | 성수기 완화 |
| 채용선발 | 2 h | 8일 | 고정 시간대 |
세 가지 관찰:
- 처리시간과 리드타임은 보통 두세 가지 크기 차이가 납니다. 처리시간만 개선하는 조치는 잘못된 목표에 집중하는 셈입니다.
- 일곱 사례 중 다섯에서는 최고의 레버가 비용이 들지 않았습니다. 분산 축소, 병렬화, 성수기 완화, 재문의 회피 등. 모두 투자 없이 가능한 조치들로 프로젝트화하기에는 매력이 떨어집니다.
- 명백한 레버는 거의 예외 없이 최선이 아니었습니다. 인원 증원, 더 빠른 소프트웨어, 더 많은 자동화는 유용하지만 실제 시간이 소비되는 지점에서는 드뭅니다.
자주 묻는 질문
처리시간에 비해 왜 총소요시간이 훨씬 긴가요?
그 사이에 대기하기 때문입니다. 작업은 대부분의 시간 동안 처리 중이 아니라 누군가 용량을 확보할 때까지 바구니에 놓여 있습니다. 행정 프로세스에서는 총소요시간의 90에서 99퍼센트가 대기시간입니다. 따라서 처리만 가속하는 모든 조치는 두 숫자 중 더 작은 쪽에만 영향을 줍니다.
이 수치들이 실제인가요?
이는 고객 데이터가 아닌 예제 모델이며 그렇게 표시되어 있습니다. 규모는 행정 및 서비스 프로세스에서 전형적인 수준에 해당합니다. 가치 있는 부분은 절대값이 아니라 패턴입니다: 사용자의 수량과 용량을 넣어 보세요, 소견의 구조는 대개 유지됩니다.
왜 변동성 감소가 용량 증대보다 더 큰 효과를 내는 경우가 많나요?
대기시간은 변동계수의 제곱에 비례해 증가하기 때문입니다. 변동성을 절반으로 줄이면 대기열에 대한 기여는 네 분의 일로 줄어듭니다. 반면 용량은 ρ/(1−ρ) 요소를 통해 영향하는데 이 요소는 한계에 가까워졌을 때만 강하게 반응합니다. 실무적으로는 유형별로 업무를 분리하고, 입력을 평탄화하며, 재질문을 없애는 것이 보통 추가 인력 한 명을 확보하는 것보다 저렴합니다.
내 프로세스가 온보딩 유형을 따르는지 어떻게 알 수 있나요?
모든 단계의 가동률이 낮은데도 총소요시간이 길다면 그 패턴을 따릅니다. 이 경우 부족한 것은 용량이 아니라 주의력입니다: 각 단계가 누군가가 그것을 떠올리는 날을 기다리고 있습니다. 효과적인 레버는 병렬화와 이벤트에 의한 트리거이지 인력 증가는 아닙니다.
이 모델들은 몇 단계로 구성되어야 하나요?
다섯에서 열 단계가 적절하며, 이는 일곱 예제 모두와 같습니다. 더 세밀하게 모델링해도 병목 위치는 이동하지 않습니다: 병목은 가장 높은 가동률을 가진 곳에 있으며 그 위치는 대략 동일하게 보입니다. 추가 단계는 입력 시간만 늘리고 입력 데이터가 감당하지 못하는 정확성의 인상을 줍니다.
자신의 프로세스로 직접 계산해 보세요
FlowVisual은 이 글의 수치를 귀하의 수량, 귀하의 용량, 귀하의 마진을 반영한 실행 가능한 모델로 만듭니다.
Guide: seven steps to the number- 활용 사례
송장 승인: 왜 OCR이 처리시간을 반으로 줄이지 않는가
송장 승인은 가장 자동화된 관리 프로세스입니다. 그리고 약속된 절감이 가장 자주 실현되지 않는 프로세스이기도 합니다. 완전 계산된 예시 모델이 그 이유를 보여줍니다.
읽기 - 방법
프로세스 시뮬레이션: 계산 예제가 포함된 8단계
순서가 도구보다 더 중요합니다. 여덟 단계, 하나의 계산된 예제와 모델에 대기열이 빠졌음을 알 수 있는 대조검증이 있습니다.
읽기 - 비교
프로세스 시뮬레이션: 소프트웨어 비교, 네 가지 범주와 네 가지 목적
“어떤 도구를 선택해야 하나요?”는 잘못된 질문입니다. 프로세스용 도구는 네 가지 범주와 네 가지 다른 목적으로 나뉩니다. 대부분의 잘못된 구매는 누군가 잘못된 범주의 도구를 샀기 때문에 발생합니다.
읽기