당신의 Excel은 계산이 맞지만 여전히 틀립니다

모두가 아는 그 엑셀입니다. 왼쪽에 프로세스 단계, 오른쪽에 평균 소요 시간, 아래에는 합계가 있습니다. 여섯 단계, 각 단계 평균 3일, 합계 18일의 처리 시간입니다. 이 숫자는 제안서, 수용력 계획 또는 고객 약속으로 들어갑니다.

그리고 실제로는 더 오래 걸립니다. 항상 그런 것은 아니지만 너무 자주 그렇습니다. 흔한 설명은: “추정이 너무 낙관적이었다.”입니다. 편리한 설명이지만 대부분 틀립니다. 추정이 완전히 정확할 수 있고 계산은 그럼에도 틀릴 수 있습니다.

불편한 부분부터 시작하겠습니다: 엑셀은 계산을 잘못하지 않습니다.

먼저 엑셀의 변호

프로세스가 정말로 일렬의 연결(1단계, 그다음 2단계, 그다음 3단계, 대기 시간 없음, 공유 자원 없음)이라면, 평균의 합은 합의 평균과 정확히 같습니다. 이는 근사치나 경험칙이 아니라 기댓값의 선형성입니다. 각 분포가 얼마나 치우쳤든 항상 성립합니다.

우리는 이를 재계산했습니다: 여섯 단계, 각 단계 평균 3일인 오른쪽으로 치우친 분포, 400,000건의 시뮬레이션.

[
  { "label": "Excel: Summe der Mittelwerte", "value": "18,0", "unit": "Tage" },
  { "label": "Simulation: echter Mittelwert", "value": "18,0", "unit": "Tage", "tone": "positive", "note": "Abweichung: 0 %" },
  { "label": "P90 der Simulation", "value": "24,3", "unit": "Tage", "tone": "critical", "note": "+35 % gegenüber dem Excel" },
  { "label": "Vorgänge über 18 Tagen", "value": "44", "unit": "%", "tone": "critical" }
]

엑셀은 평균을 정확히 맞춥니다. 바로 그래서 아무도 그것을 의심하지 않습니다. 특정 한 질문에 대해서는 옳기 때문입니다. 다만 그것이 우리가 실제로 묻는 질문은 아닙니다.

여기서 이미 두 번째 행이 문제입니다: 44%의 경우 처리 시간이 18일을 넘깁니다. 평균은 그것이 얼마나 자주 지켜지는지 말해주지 않습니다. 평균은 많은 건들의 평균에 대한 진술일 뿐, 지금 약속하려는 개별 건에 대한 진술이 아닙니다.

옆의 숫자는 P90입니다. 그것이 정확히 무엇을 의미하고 어떤 백분위로 수용력을 계획할지는 FlowVisual에 있습니다: P10, P50, P90 richtig lesen. 통계는 거기 있고, 여기서는 그 결과입니다: 합의 평균이 맞더라도 왜 그것이 약속에 부적절한 숫자인지.

단, 귀하의 프로세스는 일렬이 아닙니다

실무에서 순수한 일렬은 거의 없습니다. 사실상 모든 프로세스에 세 가지 구성 요소가 등장합니다. 각 요소가 계산을 망가뜨립니다.

게이트(문). 두 가지가 완료되어야 다음으로 진행합니다: 기술적 확인과 신용검사, 그 다음에 제안서가 나갑니다. 둘 다 평균 3일이 걸립니다. 엑셀은 3일이라고 적습니다. 현실은 둘 중 느린 쪽을 기다리고, 그 느린 쪽의 평균은 대개 3일이 아닙니다.

반복(루프). 어떤 단계는 때때로 다시 해야 합니다. 15%의 재작업은 단순한 반올림 오류처럼 보일 수 없습니다. 사실 그렇지 않습니다.

대기열. 한 사람이 여섯 단계 중 두 단계를 수행합니다. 엑셀에는 그 사람의 순수 처리 시간만 적혀 있습니다. 거기에 적혀 있지 않은 것은 해당 업무가 그 사람 책상에 올라와 다른 일을 하느라 기다리는 시간입니다.

같은 단계 소요, 같은 평균 3일. 단지 구조가 다릅니다:

{
  "caption": "Abweichung der echten Dauer vom Excel-Wert, je Prozessbaustein (Simulation, je 300.000 Vorgänge)",
  "unit": "%",
  "data": [
    { "label": "Kette: A, dann B, dann C", "value": 0, "tone": "positive" },
    { "label": "Schleife: 15 % Nacharbeit", "value": 18 },
    { "label": "Tor: A und B müssen fertig sein", "value": 33 },
    { "label": "Schleife: 30 % Nacharbeit", "value": 43 },
    { "label": "Tor: A, B und C müssen fertig sein", "value": 54 },
    { "label": "Warteschlange bei 67 % Auslastung", "value": 124, "tone": "critical" },
    { "label": "Warteschlange bei 80 % Auslastung", "value": 231, "tone": "critical" },
    { "label": "Warteschlange bei 90 % Auslastung", "value": 531, "tone": "critical" }
  ]
}

대기열은 이 목록에서 가장 충격적입니다. 67% 이용률을 편안하다고 생각하는 사람이 많습니다. 그 지점에서 실제 체류 시간은 순수 처리 시간보다 두 배 이상입니다. 90%일 때는 여섯 배입니다. 이는 나쁜 조직의 문제가 아니라 수학입니다: 이용률이 100%에 가까워질수록 대기 시간은 가혹하게 커집니다. 그것은 선형적으로 증가하지 않고 폭발적으로 증가합니다.

직원을 90%로 가동하는 것은 효율적인 것이 아닙니다. 단지 대기 시간을 장부에서 빼서 고객의 처리 시간으로 옮겼을 뿐입니다.

왜 오차의 부호가 항상 같다

그래프의 패턴은 우연이 아닙니다. 이름이 있습니다.

엑셀은 **f(평균)**을 계산합니다: 각 단계에 평균을 넣고 전체 프로세스를 계산합니다. 현실은 **평균(f(X))**을 제공합니다: 변동하는 실제 소요로 각 건을 처리한 다음에 평균을 냅니다.

이 둘은 같지 않습니다. 젠센의 부등식에 따르면 함수가 볼록(convex)이라면 결과들의 평균이 평균들의 결과보다 큽니다.

그리고 결정적 관찰: 게이트, 루프, 대기열은 모두 볼록입니다. 최대값은 볼록이고, 기하학적 반복도 볼록합니다. 대기열은 특히 심합니다. 그래서 그래프의 편차는 결코 음수가 되지 않습니다.

즉: 엑셀의 오류는 단순한 잡음이 아니라 편향입니다. 때때로 높게, 때때로 낮게 맞추는 것이 아닙니다. 체계적으로 낙관적입니다. 프로세스에 구조가 많을수록 편차는 커집니다.

같은 프로세스, 두 계산 방식

실제와 같은 여섯 단계 프로세스를 살펴보겠습니다: 2단계와 3단계는 병렬로 진행되며 둘 다 완료되어야 하고, 5단계는 15%의 재작업이 있습니다. 그 외에는 특별할 것 없음: 대기열 없음, 공유 인력 없음. 각 단계 평균 3일.

엑셀은 평균을 대입해 15일이라고 계산합니다. 이 계산은 깔끔합니다. 병렬 게이트도 올바르게 모델링되어 있습니다.

[
  { "label": "Excel: Mittelwert je Schritt", "value": "15,0", "unit": "Tage" },
  { "label": "Simulation: Mittelwert", "value": "16,5", "unit": "Tage", "tone": "critical", "note": "+10 %" },
  { "label": "Simulation: P90", "value": "22,8", "unit": "Tage", "tone": "critical", "note": "+52 %" },
  { "label": "Termin von 15 Tagen gehalten", "value": "43", "unit": "%", "tone": "critical" }
]

약속된 시간은 15일입니다. 그 약속이 지켜지는 경우는 43%뿐입니다.

이것이 핵심입니다. 엑셀이 10% 정도 빗나가는 것이 문제가 아니라(그 정도는 감수할 수 있습니다) 엑셀이 약속처럼 보이는 숫자를 내고 실제로는 동전 던지기라는 점입니다. 이 숫자를 기준으로 계획하면 존재하지 않는 프로세스를 계획하는 것입니다.

아래에서 직접 시뮬레이션을 실행해 보실 수 있습니다. 시뮬레이션은 단지 소요 시간만 보여주지 않고, 어떤 단계가 어떤 상황에서 병목이 되는지도 보여줍니다. 상황이 바뀌면 정답도 바뀝니다.

한 가지 구성요소, 반대로 작동하는 것

모든 볼록 구조가 엑셀을 낙관적으로 만든다면, 반대로 볼록이 아닌, 즉 오목(concave)인 요소가 있을까요? 평균으로 계산하면 비관적이 되는 경우가 있을까요?

있습니다. 그리고 이것이 가장 비용 효율적인 개선이 종종 소프트웨어가 아닌 이유입니다.

두 명의 사무원이 있다고 가정하세요. 각자 전문 분야가 있고, 각자 대기열이 있습니다. 한 명은 신규 고객 담당, 다른 한 명은 기존 고객 담당입니다. 둘 다 처리 속도와 이용률이 같습니다.

이제 한 가지를 바꿉니다: 공동 대기열 하나로 합치기. 누가 비어 있든 다음 작업을 가져갑니다. 같은 두 사람, 같은 처리 시간, 같은 작업량입니다.

{
  "caption": "Verweilzeit bei gleicher Kapazität und gleicher Last: getrennte gegen gemeinsame Warteschlange (Simulation)",
  "unit": "Tage",
  "data": [
    { "label": "Zwei Spezialisten, je eigene Schlange (Mittel)", "value": 20.7, "tone": "critical" },
    { "label": "Zwei Spezialisten, je eigene Schlange (P90)", "value": 43.5, "tone": "critical" },
    { "label": "Zwei Generalisten, eine Schlange (Mittel)", "value": 12.5, "tone": "positive" },
    { "label": "Zwei Generalisten, eine Schlange (P90)", "value": 23.9, "tone": "positive" }
  ]
}

체류 시간은 40% 감소, P90은 45% 감소합니다. 추가 인원 없이, 소프트웨어 없이, 월간 비용이 드는 도구 없이 가능합니다.

이유도 수학입니다만, 이번에는 반대 방향입니다: 두 개의 분리된 대기열은 서로 도와줄 수 없습니다. 한쪽은 놀고 있고 다른 쪽에 일이 쌓입니다. 이 빈시간은 재활용할 수 없습니다. 공동 대기열은 바로 이 손실을 제거합니다. 여러 명의 유휴 인력 중 최소값을 취하는 것은 오목 함수이며, 그래서 부호가 반전됩니다.

이 결과는 이 글에서 가장 솔직한 발견입니다. 분석이 귀하의 병목이 대기열이라고 보여준다면, 적절한 권고는 종종 “소프트웨어를 사라”가 아니라 “두 개의 담당을 하나로 합치세요”입니다. 비용도 들지 않고 우리도 프로젝트가 하나 줄어듭니다.

실무에 대한 시사점

첫째: 점 추정값은 프로세스 분석에 적합하지 않습니다. 소요 시간은 숫자가 아니라 범위입니다. 각 단계마다 낙관적 값, 전형적 값, 비관적 값을 기록하세요. 평균 하나를 어림잡는 것과 같은 시간밖에 걸리지 않습니다. 이것이 계산에 사용할 수 있는 유일한 입력입니다.

둘째: 평균을 약속하지 마십시오. 평균은 연간 평균에 대한 진술이지 다음 건에 대한 약속이 아닙니다. 약속은 P90으로 해야 합니다. 평균을 약속하면 약속의 절반을 어기겠다고 약속하는 것입니다.

셋째: 구조가 추정보다 중요합니다. 단계 소요를 10% 정확도로 추정하더라도 게이트와 대기열을 놓치면 훨씬 큰 오차가 납니다. 반대로 대략적인 추정치와 올바르게 모델링된 구조로는 의외로 정확한 결과를 얻을 수 있습니다.

넷째: 이용률은 목표가 아닙니다. 90% 이용률은 좋은 리더십처럼 느껴집니다. 그것이 바로 처리 시간이 폭발하는 이유입니다.

그래서 FLOW에 O가 있는 이유

우리 방법은 FLOWREFY이고 처음 네 글자는 측정입니다: Find — 어떤 프로세스가 대상인지 찾습니다. Lay bare — 현재 상태의 비용을 유로로 산정합니다. Observe — 시뮬레이션합니다. Weigh — 저울질합니다.

F, L, W에 대해 저희는 무료 계산기를 제공합니다. O에 대해서는 없습니다. 숨겨진 유료 장벽 때문이 아니라 시뮬레이션은 입력 필드 하나로 담을 수 없기 때문입니다. 시뮬레이션은 프로세스의 구조가 필요합니다: 누가 누구를 기다리는지, 누가 무엇을 공유하는지, 어디서 재작업이 발생하는지. 바로 엑셀의 합계식에 들어가지 않는 것이며 15일과 22.8일의 차이를 만드는 요소입니다.

이를 위해 저희는 FlowVisual를 만들었습니다: 프로세스를 그려서 범위를 입력하고 상황을 재생해 보세요. 얼마나 걸리는지뿐만 아니라 수요가 증가할 때 어디가 막히는지, 지금 개선하려는 병목이 부하 시에도 동일한지 여부까지 보여줍니다.

가장 비용이 큰 병목이 연간 얼마인지 먼저 알고 싶으시면 여기에서 시작하세요. 비용이 들지 않으며 10분 정도 걸립니다.

---

방법론에 대하여

이 글의 모든 숫자는 고객 프로젝트가 아닌 Monte Carlo 시뮬레이션에서 나왔습니다. 단계 소요는 평균 3.0일인 로그정규분포이며 변동계수가 약 0.65가 되도록 분산을 설정했습니다. 분포는 현실의 처리 시간처럼 오른쪽으로 치우쳐 있습니다: 0보다 작을 수는 없고 위로는 크게 튈 수 있습니다. 각 구성요소별로 300,000에서 400,000건을 시뮬레이션했고, 대기열은 80,000번의 도착과 컷오프된 초기 안정화 단계를 사용했습니다.

구체적인 백분율 값은 이러한 가정에 따라 달라집니다. 그러나 **방향(부호)**은 달라지지 않습니다: 젠센의 부등식에서 나오며 분산이 0보다 큰 모든 경우에 적용됩니다. 분포가 더 좁으면 편차는 작아지지만 결코 부호가 바뀌지는 않습니다.