주문 처리를 위한 완성된 계산 모델

입고: 연간 6 000건의 주문, 즉 근무일 기준 하루 24건, 일일 변동률 24%이며 전체 일수의 7%에서는 피크 계수가 1,3입니다. 월초, 프레임 콜오프, 액션 종료 때문입니다.

열 방문수는 이 템플릿을 다른 것과 다르게 읽어야 한다는 첫 단서입니다: 단계 03과 04는 주문당 한 번이 아니라 1,18번 실행됩니다. 이유는 한 줄 아래에 있습니다. 승인 중 15%는 클리어링 건으로 가격 책정 단계로 되돌아가며, 그 이상 진행되지 않습니다.

결정적인 발견. 20 000회 실행에서 단계별 병목 확률:

이 열은 합계가 100,0 %입니다: 각 실행마다 그날 가장 높은 가동률을 보인 하나의 구속 단계만 집계됩니다.

신용 심사는 주문이 가장 적게 통과되는 지점입니다. 9–18분 동안 정보를 조회하고 한도를 점검해 승인합니다. 그럼에도 불구하고 이 단계는 네 번 중 세 번에서 구속 단계입니다. 담당자가 한 명이고 모든 주문이 이 단계를 거치기 때문입니다: 하루 가용 시간 370분을 평균 처리시간 13.2분으로 나누면 28건을 처리할 수 있어, 도착하는 24건을 상회합니다. 평균적으로는 충분합니다. 그러나 30%의 날에는 충분하지 않아 대기열이 가동률 상승보다 더 빠르게 커집니다.

그리고 중간의 두 행은 하나로 연결됩니다. 9,7%와 9,7%를 합하면 19,4%로, 그림에서는 두 개의 상자로 보이지만 한 사람에게서 병목이 발생합니다. 이는 신용 심사 다음으로 모델에서 두 번째로 중요한 병목이며, 별도의 행을 갖고 있지 않습니다.

공유된 역할. 승인(단계 04)과 클레임 결정(단계 05)은 템플릿에서 두 개의 용량이 아니라 하나의 자원입니다: 영업책임자, 하루 6.5시간에 가동률 86%로 환산하면 335분입니다. 두 단계가 요구하는 것:

이는 한 사람의 53%입니다. 별도로 측정해 각 단계에 고유한 용량을 할당하면 거기에는 **41%와 12%**가 기재되었을 것입니다. 아무도 의문을 제기하지 않을 편한 숫자들입니다. 실제로는 같은 업무이며 다른 점은 단지 어느 분모로 계산하느냐뿐입니다. 개별적으로는 편해 보이는 두 단계가 동일한 사람의 오후 시간입니다.

따라서 모델의 두 상자에는 동일한 사용률이 표시되며, 바쁜 날에는 약 87%입니다. 이들은 한 사람을 공유하며 운명도 공유합니다. 이 사람이 하루 결근하면 두 단계가 모두 중단되고 하나만 중단되는 것이 아닙니다. 독립된 두 용량을 가정한 모델은 이 지점에서 절대 같은 날 모두 아프지 않은 두 명의 상사를 가정해 계산하는 셈입니다.

재작업 루프. 승인 중 15%가 가격결정으로 되돌아가 클레임이 됩니다. 되돌아가는 것이지 진행하는 것이 아닙니다. 이는 분기점이 아니라 환류이며, 왼쪽에서 오른쪽으로 읽을 때 보이지 않는 결과가 있습니다. 단계 03과 04는 주문당 1/(1 − 0,15) = 1,18회 실행되며, 클레임은 0,18회 실행됩니다.

루프가 없는 동일한 모델과 비교했을 때 드는 비용은 다음과 같습니다:

따라서 루프는 주문당 노동시간의 약 11%와 영업책임자 사용률의 3분의 1가량을 추가로 소비합니다. 그럼에도 불구하고 루프가 병목은 아닙니다. 여기서 두 가지 질문이 갈라집니다. 사람들이 흔히 같은 것으로 보는 질문들 — “이것이 나에게 드는 비용은 얼마인가요?”와 “무엇이 저를 막고 있나요?” — 는 이 모델에서 다른 답을 가집니다. 템플릿은 두 질문을 모두 계산하며, 그들 사이의 차이가 핵심 메시지의 절반입니다.

루프를 “단지 예외”라서 생략하면 방문 수, 비용, 시간 세 가지 숫자를 한꺼번에 잃습니다. 환류가 없는 모델은 실제 프로세스보다 주문당 11% 저렴하고 0,7 작업일 더 빠른 것으로 잘못 읽힙니다.

1. 작업일당 주문 수. 지난 1년의 주문 항목 수 또는 주문 수 ÷ 작업일 수. 처리 단위와 동일한 단위를 사용하세요: 한 주문에 열두 개 항목을 한 번에 입력하는 사람은 주문 단위로 계산하고, 항목별로 검사하는 사람은 항목 단위로 계산합니다. 둘 다 맞지만 혼합하면 둘 다 틀립니다.
2. 피크 계수. 가장 바쁜 날에 평상시보다 몇 배의 주문이 들어오나요? 월초, 프레임 호출, 가격 행사 종료 등이 원인입니다. 계수 1.3에서 2가 일반적입니다. 이 값을 반영하지 않으면 결코 부하가 걸리지 않는 내근팀을 계산하게 되고, 신용심사는 바로 그날들에 과부하가 걸립니다.
3. 신용심사가 실제로 주문에 할당할 수 있는 시간. 채권 회계부의 인원수는 아닙니다. 독촉 작업을 병행하고 입금 처리를 하는 사람은 신용심사에 7시간을 쓸 수 없습니다. 이 한 숫자가 병목을 결정합니다.
4. 신용심사 처리 소요 범위. 최소와 최대. 단골이 한도 내인 경우 2분, 신규 고객에 조회와 문의가 필요한 경우 30분. 평균이 아니라 바로 이 범위가 대기시간을 좌우합니다.
5. 클래임/클리어링 건 비율. 템플릿에서는 15%입니다. 보고서에 잘 나오지 않지만 오후 한나절이면 셀 수 있습니다: 지난달에 가격 확인을 위해 반려된 주문이 몇 건이었나요? 이 수치는 비용, 가동률, 처리시간에 동시에 영향을 주는 모델의 유일한 값입니다.
6. 역할별 총원가율. 총급여 × 1.5에서 1.8, 연간 약 1 500 생산시간으로 나눕니다. 공유되는 역할의 요율을 잊지 마세요: 템플릿에서는 그 요율이 리소스에 있고 두 단계에 있지 않습니다. 그렇지 않으면 승인을 담당자 요율로 계산하게 됩니다.

숫자가 아닌 한 가지 입력. 계산하기 전에 누가 실제로 한 사람을 공유하는지 확인하세요. 템플릿에서는 승인과 클리어링 건입니다. 귀사에서는 다른 조합일 수 있습니다. 입력과 확인은 자주 같은 담당자가 하고, 가격 결정과 승인도 같은 영업책임자가 맡습니다. 이러한 결합을 입력하지 않으면 한 사람을 계산상 두 작업에 분배하여, 모델이 좁은 역할 대신 두 개의 한가한 단계를 보고합니다.

계산 전 검증: ERP에서 아직 확인되지 않은 미확정 주문 수를 세어 하루에 확인하는 주문 수로 나누세요(Little's Law). 귀하가 알고 있는 확인 시간이 나오면 모델이 쓸 만합니다. 크게 다르면 대기열이 빠져 있다는 뜻인데, 여기서는 거의 항상 ‘고객 회신 대기’ 상태가 없습니다.

템플릿에 포함되지 않은 것들. 템플릿은 주문확정에서 끝납니다: 피킹, 발송, 청구는 의도적으로 모델링하지 않았습니다. 이는 다른 용량을 가진 별도의 프로세스입니다. 포함되지 않은 항목: 자재 가용성, 고객에게 하는 조회(달력시간, 업무시간 아님) 및 우선순위 지정. 모델은 접수 순서로 작업합니다. 긴급 주문을 정말로 앞세우려면 별도 용량을 가진 두 번째 분기로 모델링하세요.

레버 1. 조회기관 인터페이스. 조회기관을 자동으로 조회하고 사람은 한도 초과 또는 조회 실패 건만 판정합니다. 소요시간이 9–18분에서 4–9분으로 줄어듭니다. 효과: 처리시간 P90이 5,81일에서 0,28 근무일로 단축되고 정점일 가동률이 132 %에서 65 %로, 주문당 작업비용이 60,85 €에서 53,96 €로 감소합니다. 현장에서 가장 강력한 레버이며 인원 없이 가능한 유일한 조치입니다.

흥미로운 부분은 마지막 열입니다: 이후 가장 가능성 높은 병목은 '가격 및 주문확정'으로 41 %입니다. 이 열만 보면 더 큰 그림을 놓칩니다. 승인과 정리 건은 이어서 각각 25,3 %와 25,1 %로 합하면 50,4 %의 실행입니다. 레버 1 이후 병목은 특정 위치가 아니라 한 사람입니다.

레버 2. 신용심사 인원 1명 추가. 실질적으로 비슷하게 작동합니다(0,30일 vs 0,28일)만 인원 반~정규직 한 명 비용이 들고 주문당 작업시간에는 변화가 없습니다: 같은 작업을 두 사람이 나눕니다. 레버 1(인터페이스 한 건)과의 비교(인원 한 명, 0,02일 차이)가 이 표의 핵심입니다.

레버 3. 정리 건 비율을 15 %에서 5 %로. 명확한 가격규칙, 저장된 조건, 일정 이하에서는 승인하지 않는 가치한계 등이 방법입니다. 효과: 주문당 작업비용이 60,85 €에서 56,00 €로, 공유 역할의 가동률이 53 %에서 40 %로, 처리시간 P90이 5,81일에서 5,20일로 개선됩니다. 좋은 결과지만 병목을 해결하지는 못합니다: 이후 신용심사는 오히려 더 많은 실행(89 % 대 74,7 %)을 묶습니다. 이 레버는 인원을 덜 쓰게 하고 비용을 절감하지만 고객에 대한 응답 속도는 거의 개선하지 않습니다.

레버 4. 역할 분리. 첫 번째 무효 결과이며 불쾌한 쪽입니다. 승인은 두 번째 상사로 가고 정리 건은 첫 번째에 남습니다. 두 단계는 02절의 편한 41 %와 12 %로 떨어집니다. 처리시간 P90은 5,81일에서 5,31일로 줄고 주문당 작업비용은 60,85 €로 유지되며 신용심사 병목 확률은 74,7 %에서 86,6 %로 증가합니다: 그림자 병목은 사라지고 실제 병목은 그대로 있습니다. 역할 분리는 유의미한 발견이지만 신용심사가 앞에 있는 한 조치가 아닙니다. 레버 1 또는 2가 실행된 이후에는 의미가 있으며 그때는 전체 실행의 절반을 묶습니다. 순서가 중요합니다.

레버 5. EDI 또는 고객 포털을 통한 주문 입력. 두 번째 무효 결과이며 이 프로세스군에서 가장 흔한 권고사항입니다: 주문이 이메일로 와서 수작업으로 입력됩니다; 포털이나 EDI로 절약할 수 있습니다. 입력시간이 8–17분에서 3–7분으로 줄고 주문당 작업비용이 60,85 €에서 54,12 €로 감소합니다. 정점일의 처리시간 변화는 5,81일에서 5,79일로 거의 없습니다. 입력 단계는 55 % 가동률에 정점일에 74 %입니다. 프로세스를 막은 적이 없습니다. 조치는 옳지만 '그래서 더 빨라진다'는 설명은 틀립니다. 주문당 6,73 €를 절감하고 연간 6 000건이면 별도의 경제적 근거가 됩니다.

다섯 가지를 각각 계산해 비용 대비 효과로 정렬하세요. 다섯 중 두 가지는 처리시간을 움직이고 세 가지는 비용 또는 가동률을 움직입니다. 둘 다 결과입니다만 하나를 다른 것으로 속여서는 안 됩니다.

20 000번의 실행이 각 단계의 백분율로 어떻게 되는지는 글 Monte Carlo-Simulation für Prozesse에, 왜 이미 85 % 가동률이 너무 높은지에 대한 설명은 Engpass berechnen에 나와 있습니다.

현재 상태를 저장하고, 변경된 레버와 두 번째 실행을 적용한 후 비교 결과는 다음과 같습니다:

• 이전/이후 통과시간을 P50과 P90으로 표시합니다. 중앙값은 0,16 근무일입니다. 영업팀에 ‘같은 날 확인’이라고 약속하면 열 번째 날마다 한 번은 틀리며, 그 차이는 거의 6 근무일입니다. 약속은 중앙값이 아니라 P90을 기준으로 해야 합니다.
• 피크일의 단계별 가동률과 조치 후 새로운 병목지점입니다. 이 모델에서는 다섯 개 레버 중 두 개에서 병목이 “가격 & 주문확인”으로 이동하며, 그 뒤에 더 큰 블록을 가진 공유 역할이 대기합니다.
• 공유 자원별 가동률, 단계와는 분리해서 제공합니다. 단계 행으로는 보여줄 수 없는 수치입니다: 영업책임자의 335분 중 178분이 두 개 박스에 분배되어 있습니다.
• 처리량을 주당 확정 주문 수로 들어오는 주문과 비교합니다: 현재 상태에서 120 중 112입니다. 차이는 매주 새롭게 밀려 남는 8건의 주문입니다.
• 주문당 및 연간 노동비용을 수량, 시간 및 총원가율로 계산합니다. 템플릿은 주문당 60,85 €로 계산하며, 그중 6,90 €는 클레임 루프에 할당됩니다.
• 가정 목록에는 모든 추정 입력값이 포함됩니다. “피킹, 배송 및 청구 발행은 모델링되지 않았다”는 문구는 가장 날카로운 반문이 제기되기 전에 그 날을 미리 벼립니다.

출력물은 두 개의 PDF로 생성됩니다: 의사결정자를 위한 제안서와 추적가능성을 위한 문서이며, 귀하가 회사 머리글을 등록했다면 그 머리글을 사용합니다.

같은 템플릿, 두 가지 질문. 이 페이지는 계산적 질문에 답합니다: 74,7 %는 어디서 오는가, 왜 두 박스가 동일한 가동률을 보이는가, 그리고 시간과 비용을 15 % 되돌리는 데 드는 비용은 얼마인가. 다른 질문(무엇을 권장할까, 신용조회 답변을 3일 기다리는 주문의 비용은 얼마인가)은 방법론에 속하며 도구의 범위를 벗어납니다. 그 내용은 Flowrefy의 분석 보관소에 있고, 이 템플릿이 나온 절차와 함께 제공됩니다. 데이터셋 하나, 질문 두 개, 공개 대상 두 그룹입니다.

• 주문 처리가 이 페이지입니다. 갤러리의 첫 번째 카드이자 공유 역할과 재작업 루프가 있는 유일한 사례입니다.
• **견적 프로세스**는 통과시간이 비용 대신 매출에 영향을 주는 사례입니다.
• **청구 승인**는 변동성 사례입니다: 평균적으로는 용량 아래에 있지만 월말에는 초과합니다.
• **클레임**에서는 병목이 사외에 있어 정직한 권고는 ‘자동화’가 아닙니다.
• **직원 온보딩**은 볼륨이 적고 참여자가 많으며 한 단계가 실행의 86 %를 차지합니다.
• **IT 티켓**은 분기 처리가 있는 사례입니다: 65 %는 즉시 해결되고 35 %는 2단계로 갑니다.

모든 템플릿은 환영 창의 템플릿 보기에서 열립니다. 처음 사용할 때는 자체 모델을 시작하기 전에 템플릿을 하나 열어보는 것이 좋습니다. 그렇지 않으면 지나치게 세밀하게 만들게 됩니다.