완성된 IT-Ticket 프로세스 계산 모델

입력: 연간 24 000건의 티켓, 즉 근무일 기준 하루 약 96건이며 일일 변동 폭은 28%이고 최고치 계수는 8%의 날에 1.35입니다. 설치, 롤아웃, 장애.

"비율" 열이 이 템플릿을 다른 템플릿과 다르게 읽어야 하는 이유입니다: 2차는 전체 티켓의 3분의 1만 처리합니다. 그 부하를 전체 건수에 대해 환산하면 155%가 되어, 실제로는 57%인 단계를 과부하로 잘못 판단하게 됩니다.

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

이 열은 합계가 100%입니다: 각 실행마다 그날 가장 높은 이용률을 보이는 정확히 하나의 구속 단계가 계산됩니다.

사내에서 긴 처리 시간의 원인으로 여겨지는 2차는 실행의 14%에서만 병목입니다. 티켓을 단지 5~10분 동안 접수하는 서비스데스크는 75%에서 병목입니다. 프로세스는 작업 중이 아니라 작업 전에 시간이 소모됩니다.

그리고 표의 한계가 드러나는 지점입니다: 티켓당 5분은 눈에 띄지 않습니다. 그러나 96건에 5~10분은 그렇지 않습니다.

1. 근무일당 티켓 수. 지난 해 티켓 수 ÷ 근무일 수. 헬프데스크 보고서에 기재되어 있으며 중복 및 묶음 티켓을 세는 방식과 동일한 정의를 사용하세요. 나중에 재측정할 때도 동일한 정의를 사용해야 합니다.
2. 최고치 요인. 평상시 대비 가장 많은 티켓이 들어오는 날의 비율은 얼마인가요? 월요일, 롤아웃 다음 날, 장애가 발생한 날 등. 보통 1.3에서 2 사이입니다. 이 값을 입력하지 않으면 서비스데스크가 결코 부하를 받지 않는 것으로 계산되며 티켓에서는 부하가 정상 상태입니다.
3. 서비스데스크 인원과 분류에 할당된 시간. 팀의 인원 수가 아니라 실제로 분류에 할당되는 시간이 중요합니다. 통화도 병행하는 사람은 접수에 8시간 전부를 쓸 수 없습니다.
4. 분류의 처리 범위. 하한과 상한. 비밀번호는 5분, 먼저 재구성이 필요한 장애 신고는 20분 등입니다. 바로 그 범위가 대기시간을 만듭니다.
5. 즉시 해결 비율. 템플릿에서는 65 대 35입니다. 이 수치는 헬프데스크 보고서에서 "First Contact Resolution"로 표기되며 실제로 측정할 수 있는 유일한 값입니다. 이 값은 브랜치 간 부하를 옮길 뿐 사전의 부하를 이동시키지 않습니다.
6. 역할별 총비용율. 총급여 × 1.5에서 1.8을 곱한 뒤 연간 약 1 500 생산시간으로 나눕니다. 연간 24 000건의 처리에서 단 1유로의 요율 차이도 큰 영향을 줍니다. 급여 ÷ 2 080 시간 같은 단순 계산은 나중에 유로 산출을 공격받기 쉽습니다.

계산 전 검증: 시스템에 열린 티켓 수를 세어 하루에 닫는 티켓 수로 나누어 보세요 (Little's Law). 평소 아는 처리시간이 나온다면 모델이 유효합니다. 크게 차이나면 대기열이 빠졌거나 티켓에서 거의 항상 빠지는 상태인 "사용자 응답 대기"가 누락된 것입니다.

템플릿에 포함되지 않은 항목. 처리시간은 실제 처리 시간과 작업일 기준 대기시간의 합입니다. 우선순위 지정은 모델에 반영되어 있지 않습니다: 모델은 입력 순서로 작업합니다. 실제 우선순위가 있다면 별도 용량을 가진 두 번째 분기로 모델링하세요. 그렇지 않으면 모델은 긴급 티켓에 대해 너무 느리게, 나머지에 대해서는 너무 빠르게 계산합니다. 또한 티켓이 사용자 응답을 기다리는 휴지기(대기시간)도 포함되어 있지 않습니다.

레버 1. 입력 시 양식 하나. 장비, 애플리케이션, 오류유형과 긴급도 필수항목. 재구성이 필요없어 트리아지 시간이 5–10 분에서 3–6 분으로 줄어듭니다. 효과: P90 처리시간이 4,9 일에서 0,22 근무일로 감소하고, 성수기 당일의 이용률이 129 %에서 77 %로 낮아집니다. 현장에서는 가장 비용이 적게 드는 레버이며, 인력을 추가하지 않아도 되는 유일한 조치입니다.

레버 2. 서비시데스크에 세 번째 인원. 역시 유의미한 효과가 있지만(0,38 일), 한 자리의 인건비가 듭니다. 이 표의 핵심 메시지는 레버 1과의 비교입니다.

레버 3. 티켓의 20 %를 선제적으로 걸러내는 지식베이스. 티켓 수가 줄어드는 것은 항상 유리하지만 병목을 해소하지는 않습니다: 트리아지는 전체 시나리오의 75 %에서 계속 결정 단계로 남아 있으며, 성수기 당일의 부하는 129 %에서 103 %로만 떨어집니다. 양이 5분의 1 줄어드는 것은 한 단계를 간신히 넘기는 수준입니다.

레버 4. 1차에서 더 많은 티켓을 해결. 가장 흥미로운 무효결과입니다. 첫 접촉 해결률을 65 %에서 75 %로 올리는 것은 지원의 표준 권고이며, 효과가 있습니다: 비싼 2차 대응 분이 저렴한 1차 대응 분으로 대체되어 티켓당 작업비용이 28,82 €에서 25,34 €로 떨어집니다. 처리시간은 오히려 약간 증가해 5,0 일이 됩니다. 이 레버는 시간을 절약하지 못하고 비용을 절감합니다. 이를 처리시간 단위의 조치로 팔면, 동일한 올바른 조치에 대해 잘못된 주장을 하는 것입니다.

네 가지 레버를 각각 계산하고 비용 대비 효과로 정렬하세요. 레버 1은 양식, 레버 2는 인력 한 자리이며, 모델상 이 둘의 차이는 0,16 일입니다.

20 000번의 시뮬레이션에서 각 단계의 백분율이 어떻게 생성되는지는 기사 Monte-Carlo-Simulation für Prozesse에 설명되어 있고; 왜 85 %의 이용률도 과다한지에 대해서는 Engpass berechnen에 나와 있습니다.

기준 상태를 저장하고, 레버를 변경한 뒤 두 번째 실행을 하면 비교에서 다음을 제공합니다:

• 처리시간 이전/이후를 P50과 P90으로 제시합니다. 서비스 약속은 중앙값이 아니라 P90으로 주어야 합니다. 이 점이 SLA 진술과 평균 진술의 차이입니다: 중앙값은 0,08일이라고 말하지만 매 열 번째 날 약속이 지켜지지 않습니다.
• 피크 일자의 단계별 이용률과 조치 후의 새로운 병목. 이 모델에서는 네 개 레버 중 두 개에서 병목이 첫 번째 레벨로 이동합니다.
• 처리량을 주당 티켓 수로 들어오는 양과 비교합니다: 기준 상태에서 480건 중 455건입니다. 차이는 매주 서비스데스크가 새로 쌓아두는 대기분입니다.
• 티켓당 및 연간 작업시간비용을 수량, 시간과 총원가율로 계산합니다. 연간 24 000건에서는 한 센트까지도 영향을 미치며, 템플릿은 티켓당 28,82 €로 계산합니다.
• 가정 목록에는 모든 추정 입력값이 들어갑니다. "우선순위와 휴지시간은 모델에 반영되지 않았습니다"라는 문장은 가장 날카로운 반론의 날을 미리 무디게 만듭니다.

결과물은 두 개의 PDF로 출력됩니다: 의사결정권자를 위한 제안서와 추적 가능성을 위한 문서로, 귀하의 레터헤드(등록해 두셨다면)를 사용합니다.

동일한 템플릿, 두 가지 질문. 이 페이지는 계산에 관한 질문에 답합니다: 75 %는 어디서 나왔고 왜 티켓이 5분의 1 줄어들어도 병목이 해소되지 않는가. 다른 질문(무엇을 권고할 것인가, 미해결 티켓 하나의 비용은 얼마인가)은 방법론에 속하며 도구가 아닙니다. 그 내용은 Flowrefy의 분석 아카이브와 이 템플릿이 나온 절차에 있습니다. 하나의 데이터셋, 두 가지 질문, 두 집단의 독자입니다.

• **주문 처리**는 주문부터 주문확인까지 진행됩니다. 역할이 분리된 사례에서는, 개별적으로 보면 편해 보이는 두 단계가 같은 사람의 오후 일정입니다.
• **견적 프로세스**는 처리시간이 비용이 아니라 매출에 영향을 주는 사례입니다.
• **송장 승인**는 변동성 사례입니다: 평균적으로는 용량 이하이나 월말에는 이를 넘습니다.
• **클레임**에서는 병목이 외부에 있고 그래서 정직한 권고는 ‘자동화’가 아닙니다.
• **직원 온보딩**는 처리량은 적고 참여자는 많으며 한 단계가 86 %의 처리 건을 묶어 둡니다.
• IT 티켓은 이 페이지입니다.

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