완성된 계산 모델로서의 견적 프로세스

입력: 연간 550건의 문의, 즉 근무일 기준 하루 약 2,2건이며 일별 변동률은 26 %이고 최고일 계수는 7 %의 날에 1,35입니다.

결정적 소견. Konstruktion은 제안서 프로세스에서 하루에 다섯 시간을 할애합니다. 나머지 시간은 진행 중인 프로젝트에 속해 있습니다. 다섯 시간에 89 %의 유효 이용률을 곱하면 267분입니다. 기술적 확인(t echnische Klärung) 평균 소요 103분을 기준으로 하면 하루에 2,6건을 처리할 수 있어 들어오는 2,2건과 비교하면 겉으로는 충분합니다. 그러나 강한 날에는 충분하지 않습니다.

스트레스 테스트는 바로 그것을, 그리고 평가 대신 확률로 보여줍니다:

열의 합은 100 %이며 이는 우연이 아닙니다: 각 실행에서는 그날 가장 높은 이용률을 보인 단 한 단계가 계산됩니다. 따라서 “79 %”는 “79 %의 이용률”을 의미하는 것이 아니라: 네 번 중 세 번은 이 단계가 처리량을 제한한다는 뜻입니다.

사내에서 병목으로 여겨졌던 Kalkulation은 단 한 번의 실행에서도 병목이 아니었습니다.

1. 근무일당 문의 수. 지난 1년간 문의 수 ÷ 근무일 수. CRM이나 견적번호 순서에 나와 있습니다.
2. 피크 요인. 가장 바쁜 날에 평상시보다 문의가 몇 배로 오나요? 견적에서는 보통 박람회나 계절의 영향을 받으며, 1,3에서 1,5가 흔합니다. 이 값을 넣지 않으면 결코 부하가 걸리지 않는 프로세스를 계산하게 됩니다. 실제로는 부하가 걸릴 때 견적이 제때 나가는지가 결정됩니다.
3. 이 프로세스에 설계팀이 주는 시간. 인원수가 아니라 시간 분량입니다. 핵심 수치는 기술적 확인을 담당하는 사람이 실제로 견적에 할애하는 하루의 비율입니다. 보통 3~6시간이며, 결코 8시간은 아닙니다.
4. 기술적 확인의 처리 범위. 하한과 상한이지, 평균이 아닙니다. 범위가 중요합니다: 변동성은 대기시간에 제곱으로 들어가고 평균은 선형으로만 작용합니다.
5. 하루당 승인 수. 승인할 견적이 있을 때 영업 책임자가 하루에 몇 건의 견적을 승인하나요? 이 숫자가 승인 단계가 두 번째 병목인지 결정합니다. 템플릿에서는 다섯 날 중 하루에 두 번째 병목이 됩니다.
6. 역할별 전부원가율. 총급여 × 1,5~1,8 ÷ 연간 약 1 500 생산시간. 연봉 50 000유로 직무는 시간당 약 53 €가 되며, 단순히 급여 ÷ 2 080시간으로 계산한 24 €가 아닙니다. 단순 계산을 쓰면 나중에 유로 산출 근거가 공격받기 쉽습니다.

계산하기 전의 대조 검증: 현재 열려 있는 문의 수를 세고 하루에 밖으로 내보내는 견적 수로 나누어 보세요 (Little's Law). 대략 알려진 리드타임이 나오면 모델이 실용적입니다. 크게 어긋나면 어떤 대기열이 빠져 있습니다. 견적에서는 거의 항상 고객에게 하는 재질문이나 기다리고 있는 공급사 견적이 빠져 있습니다.

템플릿이 포함하지 않는 것. 리드타임은 처리시간과 작업 중 대기시간의 합입니다. 고정된 달력 시간(공급사가 가격을 내는 데 필요한 3일, 고객의 회신까지 일주일)은 모델링되지 않습니다. 이런 시간이 있으면 별도 단계로 입력하세요; 그렇지 않으면 모델은 고객이 체감하는 것보다 더 빠르게 계산됩니다.

Hebel 1. Pflichtfelder bei der Anfrageerfassung. Die sechs Angaben, nach denen die Konstruktion ohnehin immer fragt, werden beim Erfassen abgefragt. Die Erfassung dauert dadurch länger (15–30 statt 10–22 Minuten), die technische Klärung kürzer (45–100 statt 70–140), weil die Rückfragerunde entfällt. Ergebnis im Modell: Der P90 der Durchlaufzeit fällt von 7,2 auf 1,6 Arbeitstage, die Auslastung der Konstruktion am Spitzentag von 133 % auf 94 %. Zeit am Eingang ist billiger als Zeit im Engpass. Das ist der ganze Satz.

Hebel 2. Mehr Konstruktionszeit für den Angebotsprozess. Eine Stunde mehr am Tag. Wirkt, aber weniger als erwartet: 111 % am Spitzentag statt 133 %, und die Klärung bleibt in 56 % der Läufe der Engpass. Das ist der ehrliche Preis dafür, dass ein überlasteter Schritt nicht linear reagiert.

Hebel 3. Zweiter Konstrukteur halbtags. Der teuerste Hebel, und im Ergebnis kaum besser als Hebel 1. Wer ihn trotzdem rechnet, sieht den Grund: Der Engpass wandert in beiden Fällen zur Freigabe, und ab dort begrenzt nicht mehr die Konstruktion.

Hebel 4. Die Freigabe entlasten. Der Null-Befund, und der lehrreichste. Die Freigabe ist mit 92 % am Spitzentag der zweitknappste Schritt; sie zu verdoppeln bringt 0,3 Tage. Denn solange die Klärung bindet, kommt bei der Freigabe gar nicht genug an. Ein Hebel am zweiten Engpass ist kein halber Erfolg, sondern keiner.

Rechnen Sie die vier einzeln und sortieren Sie nach Wirkung je Aufwand. Hebel 1 ist ein Formular, Hebel 3 ist eine Stelle, und im Modell liegen sie 0,3 Tage auseinander.

Wie aus 20 000 Läufen eine Prozentzahl je Schritt wird, steht im Artikel Monte-Carlo-Simulation für Prozesse; warum die Spreizung zwischen P50 und P90 die eigentliche Aussage ist, in P10, P50, P90 verstehen.

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

• 이전/이후 처리시간을 P50과 P90으로 제시합니다. 영업에 대한 약속은 중앙값이 아니라 P90에 따라 이루어집니다. 중앙값이 0.7이라서 “이틀”을 약속하면 다섯 번 중 한 번은 지키지 못하는 약속을 하는 것입니다.
• 최대일자의 각 단계 가동률과 개선 후 새 병목입니다. 이 모델에서는 가장 효과적인 두 레버의 해제에서 병목이 이동합니다. 이것은 조치의 정상적인 결과이지 오류가 아닙니다.
• 처리량을 주당 제안 건수로, 들어오는 건수와 비교해 제시합니다. 현행 상태에서는 11건 중 10.3건이 나가며, 그 차이는 손실이 아니라 병목이 매주 새로 쌓는 대기입니다.
• 연간 인건비 영향을 수량, 시간 및 전부원가율로 범위로 제시합니다. 템플릿은 제안 건당 약 254 €의 작업시간을 가정합니다; 연간 941시간이 설계에 할당됩니다.
• 가정 목록에 모든 추정 입력값을 기재합니다. “공급업체 가격 대기시간은 모델링되지 않음”이라는 문구는 가장 날카로운 반문을 제기되기 전에 잠재적으로 누그러뜨립니다.

출력물은 두 개의 PDF로 제공됩니다: 의사결정자를 위한 제안서와 추적 가능성을 위한 문서화본이며, 저장된 귀하의 편지지(브랜드지)가 있으면 그것을 사용합니다.

같은 템플릿, 두 가지 질문. 이 페이지는 계산적 질문에 답합니다: 79%가 어디서 왔는지와 병목을 해결하면 어디로 이동하는지. 다른 질문(무엇을 권고할지, 아무것도 하지 않으면 비용이 얼마인지)은 방법론에 속하며 도구의 범주가 아닙니다. 그 내용은 Flowrefy의 분석 아카이브에, 그리고 이 템플릿들이 나온 절차와 함께 있습니다. 하나의 데이터셋, 두 질문, 두 대상입니다.

• **주문처리**은 주문에서 주문확정까지 진행됩니다. 역할이 분리된 경우: 개별적으로는 여유로워 보이는 두 단계가 같은 사람의 오후 시간일 수 있습니다.
• 제안 프로세스가 이 페이지입니다.
• **계산서 승인**은 변동성 사례입니다: 평균적으로는 용량 이하이나 월말에는 초과합니다.
• **불만처리**의 병목은 사외에 있어 정직한 권고는 ‘자동화’가 아닙니다.
• **직원 온보딩**은 볼륨이 적고 참여자가 많으며, 한 단계가 실행의 86%를 차지합니다.
• **IT 티켓**은 분기점이 있는 전형적인 대기열 행동을 보입니다: 65%는 즉시 해결되고 35%는 2단계로 갑니다.

각 템플릿은 환영 창에서 템플릿 보기로 열립니다. 처음이라면 자체 모델을 시작하기 전에 하나를 여는 것이 좋습니다. 그렇지 않으면 너무 세밀하게 구축하게 됩니다.