송장 승인에 대한 완성된 계산 모델

Eingang: rund 1 200 Rechnungen im Monat, also etwa 60 an einem Arbeitstag, mit Spitzenfaktor zum Monatsende.

Der entscheidende Befund: Die Summe der Bearbeitungszeiten liegt bei 20 bis 30 Minuten je Rechnung, die tatsächliche Durchlaufzeit bei acht bis zwölf Arbeitstagen. Zwischen beiden liegen rund drei Grössenordnungen, und diese Lücke besteht fast vollständig aus Wartezeit, überwiegend vor der sachlichen Freigabe.

Der Grund ist strukturell und hat nichts mit Nachlässigkeit zu tun: Freigeben ist kein Vollzeitjob, sondern eine Nebentätigkeit von vierzehn Personen. Daraus folgen sehr hohe Streuung (zehn Minuten oder sechs Tage) und fehlende Vertretung. Zwei Eigenschaften, die zusammen die Wartezeit erzeugen.

1. 하루 평균 처리량. 지난 한 해의 수신 세금계산서 수 ÷ 영업일 수. 외상매입금 관리(채권이 아니라 채무)나 ERP 보고서에 나와 있습니다.
2. 최고치 계수. 가장 바쁜 날에 보통 날보다 몇 배 많은 세금계산서가 들어옵니까? 대부분 월말이며 계수 1.5에서 2가 일반적입니다. 이 값을 넣지 않으면 부하가 전혀 걸리지 않는 공정을 계산하게 됩니다.
3. 회계팀 처리능력. 인원 수 × 1인당 하루 생산적 근무시간. 경험칙: 정규직 비율 × 7시간, 8시간이 아닙니다. 회의, 문의 응대, 방해는 처리시간으로 보지 않습니다.
4. 결재자 수. 실무적으로 결재하는 인원이 몇 명입니까? 이 수치는 다른 어떤 것보다 분산에 큰 영향을 줍니다.
5. 결재 주기. 결재자는 평균적으로 얼마나 자주 본인 업무함을 확인합니까? 매일, 주 2회, 불규칙적으로? 결재 자체의 소요시간이 아니라 처리 범위를 입력하세요.
6. 역할별 총원가율. 총급여 × 1.5에서 1.8, 연간 약 1 500 생산적 시간으로 나눕니다. 연봉 50 000유로 자리라면 시간당 약 53€가 되며 급여 ÷ 2 080으로 계산한 단순값 24€는 아닙니다. 단순한 수치를 쓰면 나중에 유로 환산 근거가 공격받을 수 있습니다.

계산 전에 검증하세요: 현재 대기 중인 세금계산서 수를 세고 일일 처리량으로 나누어보세요 (Little's Law). 대략 알려진 평균 처리시간과 맞으면 모델이 타당합니다. 크게 벗어나면 대기열이 빠졌을 가능성이 높으며 보통은 공급자 문의 대기나 일정 금액 이상의 두 번째 결재 단계가 빠져 있습니다.

레버 1. 문서 인식(OCR)로 기록 입력. 기록 입력을 크게 단축합니다. 계산해 보시고, 승인 처리에 어떤 일이 일어나는지 관찰하세요: 이제 승인에는 제한된 양이 아니라 전체 양이 들어오며 승인 자체가 병목이 됩니다. 처리 시간은 기록 입력 시간이 줄어든 것보다 훨씬 적게 감소합니다. 바로 이 효과가 자동화 프로젝트의 사업 타당성이 실현되지 않는 가장 흔한 이유입니다.

레버 2. 금액 한도에 따른 실무 승인 기준. 임계값 이하의 송장은 개별 승인을 하지 않고 사후 표본검사로 처리합니다. 이는 승인 건수에 영향을 주지 시간에 영향을 주므로 대기 시간이 발생하는 지점에 효과가 있습니다.

레버 3. 대리 규칙과 풀. 승인을 더 빠르게 하는 것이 아니라 분산을 줄이세요: 부재 시 고정 대리 지정, 개인 바구니 대신 부서별 공유 바구니. 대기 시간은 분산의 제곱에 비례해 증가합니다. 분산을 절반으로 줄이면 그 기여도는 4분의 1이 됩니다.

레버 4. 지급 실행을 주 2회에서 매일로. 가장 비용 효율적인 레버로, 대부분 설정 변경입니다. 평균적으로 약 하루를 단축합니다.

네 가지 레버를 각각 계산하고 효과 대비 노력을 기준으로 정렬하세요. 이와 유사한 대부분의 모델에서 레버 2나 3이 레버 1보다 효과적입니다. 시장에서는 레버 1이 주로 제공됩니다.

이 예제의 상세 분석은 기사 Rechnungsfreigabe: warum OCR die Durchlaufzeit nicht halbiert에 나와 있습니다.

현재 상태를 확보하고, 한 레버를 변경한 뒤 두 번째 실행을 하면 비교 결과로 다음을 제공합니다:

• 변경 전/후 처리 시간을 P50 및 P90으로. 약속은 중앙값이 아니라 P90을 기준으로 합니다.
• 최고일의 단계별 활용률과 조치 후 새로운 병목 지점.
• 연간 인건비 영향을 수량, 시간 및 전원가율로부터 산출한 범위로 제시합니다.
• 가정 목록과 모든 추정 입력값. 예를 들어 "공급자에 대한 문의는 모델링되어 있지 않습니다"라는 문구는 가장 날카로운 반론이 제기되기 전에 그 날을 세웁니다.

결과물은 두 개의 PDF로 출력됩니다: 의사결정자를 위한 제안서와 추적 가능성을 위한 문서화 자료이며, 등록하신 경우 귀사의 편지지로 제공합니다.

• **주문처리**은 주문부터 주문확정까지 진행됩니다. 역할이 분리된 사례: 개별적으로는 편해 보이는 두 단계가 사실 같은 사람이 오후에 처리하는 업무입니다.
• **견적프로세스**는 문의부터 발송된 견적까지 진행됩니다. 처리시간이 비용이 아니라 매출에 직접 영향을 미치는 사례입니다.
• 청구서 승인은 이 페이지입니다.
• **불만처리**에서는 병목이 사내가 아닌 외부에 있으므로, 정직한 권고는 ‘자동화’가 아닙니다.
• **직원 온보딩**은 참여자가 많고 건수는 적으며 편차가 큽니다. 일정 연쇄가 처리시간을 결정하는 사례입니다.
• **IT 티켓**은 전형적인 대기행동과 분기가 나타나며 65%는 즉시 해결되고 35%는 두 번째 레벨로 넘어갑니다.

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