가장 비용이 큰 병목: 실제로 돈이 드는 프로세스를 찾는 방법

대부분의 중견기업에서 시작점은 비슷합니다: 문제가 하나가 아니라 열다섯 개입니다. 견적 작성이 너무 오래 걸립니다. 청구서 승인 절차가 지연됩니다. 영업 담당자가 데이터를 중복으로 관리합니다. 신규 직원 온보딩은 혼란입니다. 이러한 문제들 각각은 현실이며, 각각 돈이 듭니다 – 그래서 결국 아무 일도 일어나지 않습니다. 누구부터 손대야 할지 모르기 때문입니다.

Flowrefy 방법은 첫 번째 단계인 F = Find에서 이 질문에 답합니다: 모든 것을 동시에 건드리지 말고 하나의 가장 비용이 큰 병목을 찾으세요. 주기당 병목 하나. 이 글은 그 하나의 병목을 어떻게 식별하고 유로로 환산하며 다른 후보들과 우선순위를 매기는지 보여줍니다 – 솔루션에 한 푼도 쓰기 전에요.

사전 구분 하나: 여기서는 선택 문제입니다 – 귀하의 프로세스들 중 어느 것이 가장 비용이 큰가. 선택된 프로세스를 어떻게 수치로 계산하는지 – 이용률, 대기열, 변동성, 그리고 이용률이 85퍼센트부터 왜 대기시간이 폭발하는지 – 는 자매 페이지에 나와 있습니다: Engpass berechnen. 선택은 여기서, 계산은 거기서 합니다.

왜 병목이 모든 것을 결정하는가

F 단계 뒤에는 제약이론(Theory of Constraints)에서 나온 단순하지만 불편한 진실이 있습니다: 프로세스의 처리량은 항상 정확히 한 지점에 의해 제한됩니다. 체인이 가장 약한 고리에서 끊기는 것과 같습니다 – 아홉 개의 튼튼한 고리가 아니라요.

이것은 우선순위 설정에 대한 엄격한 결과를 낳습니다. 열 군데를 동시에 개선하면 병목이 아니었던 아홉 군데도 개선됩니다. 시간과 돈과 주의를 그런 최적화에 투자하지만 전체 처리량은 0퍼센트 증가합니다 – 실제 병목은 손대지 않았기 때문입니다. 이것이 프로세스 작업에서 가장 비싼 실수입니다: 많은 움직임, 효과 없음.

반대로 한 제약 지점을 해결하면 전체 프로세스의 처리량이 튀어 오릅니다. 그리고 중요한 일이 일어납니다 – 병목이 이동합니다. 다른 지점이 새로운 제한이 됩니다. 바로 이것이 FLOW가 일회성 프로젝트가 아니라 루프(순환) 인 이유입니다: 주기마다 정확히 하나의 병목을 해결하고 측정한 뒤 다음으로 넘어갑니다.

F 단계의 소유 가능한 원칙은 다음과 같습니다: 주기당 하나의 병목. 더 많이 한다고 못하는 것이 아니라, 더 많이 해도 소용이 없기 때문입니다.

병목과 골칫거리는 다르다

가장 흔한 사고 오류: 가장 시끄러운 문제를 병목으로 생각하는 것입니다. 이것은 거의 일치하지 않습니다. 가장 많이 불평하는 영업 책임자가 자동으로 가장 비용이 큰 병목을 가진 것은 아닙니다 – 단지 목소리가 가장 클 뿐입니다.

여기서 바로 시험해 보실 수 있습니다. 같은 다섯 단계, 네 겹의 관점: 상황을 바꿔 병목이 어떻게 이동하는지, 결국 사람인지 시스템이 경계인지 지켜보세요.

이 시뮬레이션의 두 번째 발견은 더 불편합니다: 평균값들의 합은 처리 시간이 아닙니다. 각 단계 소요 시간을 더하면 현실에서 거의 발생하지 않는 숫자가 나오고, 그 숫자에 맞춰 일정을 계획하게 됩니다.

진짜 병목에는 전형적인 징후가 있습니다. 다음 다섯 증상에 주의하세요:

• 그 앞에 정체가 쌓임: 이 지점 앞에 작업들이 쌓입니다. 이메일함에서, 승인 폴더에서, 상태가 “대기 중”인 곳에서.
• 그 뒤는 유휴: 후속 지점들이 정기적으로 여기서 오는 입력을 기다립니다.
• 처리시간보다 대기시간이 큼: 실제 처리 시간보다 훨씬 오래 방치됩니다. 대기 시간이 진짜 킬러입니다.
• 재질문과 재작업: 가장 많은 반복, 수정, 즉석 정리가 여기서 발생합니다.
• 개인 의존성: “이건 오직 베르거 씨만 할 수 있다” – 한 사람이 병목인 전형적인 경우입니다.

어떤 지점이 이 증상 중 세 가지 이상을 보이면 유력한 후보입니다. 하지만 후보라고 해서 확정은 아닙니다. 최종 결정은 돈으로 합니다.

1단계: 탐색 범위 좁히기

측정하기 전에 후보 목록이 필요합니다. 여기서 프로세스 맵이 도움이 됩니다 – 어떤 프로세스들이 존재하고 어떻게 연결되는지 보여줍니다. 하지만 주의: 지도는 위치를 보여줄 뿐 우선순위를 정하지 않습니다. 지도는 ‘견적에서 수주까지’라는 프로세스가 있다고 알려주지만, 그것이 가장 비용이 큰 병목인지 말해주지는 않습니다. 아직 깔끔한 개요가 없다면 사전에 프로세스맵 만들기를 보는 것이 좋습니다 – 이것은 전제 조건이지 병목 분석의 대체물이 아닙니다.

F 단계에는 실용적인 후보 목록으로 충분합니다. 운영 실무자 두세 명과 한 시간 동안 다섯 가지 병목 증상 중 적어도 하나를 보이는 지점들을 모두 모으세요. 완전성을 기대하지 마세요 – 다섯에서 열 후보면 충분합니다. 더 많으면 우선순위 선정이 복잡해집니다.

2단계: 각 후보를 유로로 환산하기

이제 FLOW를 일반 가이드와 구분짓는 단계가 나옵니다. 두 번째 소유 가능한 원칙:

유로로 말할 수 없다면 손대지 마세요.

주관이나 목소리 크기나 ‘중요하게 느껴짐’으로 우선순위를 정하지 않습니다. 유로로 우선순위를 정합니다. 그리고 이를 위해 완벽한 데이터가 필요한 것은 아닙니다 – 후보당 믿을 만한 추정치 세 가지면 충분합니다:

1. 월별 건수 – 이 지점을 통해 한 달에 몇 번의 작업이 흐르는가?
2. 건당 손실 시간 – 대기, 검색, 재질문, 재작업으로 인해 건당 몇 분이 손실되는가?
3. 내부 시급(총비용) – 이 인력의 한 시간당 실제 비용은 얼마인가? 프로세스 비용 계산에서 쓴 것과 같은 경험법칙: 연봉 총액에 1.5~1.8배를 곱해(부대비용 및 비례 간접비) 약 1,500 유효 근무시간으로 나눕니다. 연봉 50,000유로인 포지션은 이렇게 약 53유로/시간의 총비용이 되며, 단순히 연봉을 2,080으로 나눈 24유로와는 다릅니다.

후보별 계산식:

월별 건수 × 건당 손실시간(시간 단위) × 시급 × 12 = 연간 병목 비용.

예시 시나리오(단지 설명용, 실제 수치 아님)

직원 60명인 회사의 청구서 승인 절차를 가정해 보겠습니다. 가정: 월 400건의 청구서, 서류 담당자와 승인자의 왕복으로 건당 평균 12분(0.2시간)의 대기·검색 시간이 손실되고, 혼합 시급은 42유로입니다.

400 × 0.2시간 × 42유로 × 12 = 약 40,300유로/년.

반면 CRM과 발송 도구 간의 연락처 데이터 이중 입력은 월 150건, 건당 5분 손실, 동일 시급이면 연간 약 6,300유로입니다 – 일상에서 더 성가신 문제 같아도 규모는 완전히 다릅니다.

이 시나리오의 요점은 정확한 숫자가 아니라 깨달음입니다: 두 항목을 유로로 나란히 놓으면 우선순위는 더 이상 의견 문제가 아닙니다. 데이터 중복 입력은 매일 더 짜증나지만, 청구 승인 지연은 6배의 비용을 초래합니다.

측정으로 수치화하면 이런 모습입니다. 숫자는 샘플 분석 AN-2026-01에서 나왔습니다(구성한 것이며 고객에게서 수집한 것이 아님):

{
  "caption": "Wie oft war dieser Schritt der Engpass? (500 simulierte Durchläufe)",
  "unit": "%",
  "data": [
    { "label": "Technische Klärung", "value": 62, "tone": "critical" },
    { "label": "Freigabe", "value": 19 },
    { "label": "Kalkulation", "value": 11 },
    { "label": "Angebot schreiben", "value": 4 },
    { "label": "Anfrage erfassen", "value": 2 }
  ]
}

전체 조직은 ‘Kalkulation(원가산정)’이 느리다고 의견을 모았습니다. 하지만 그것은 11퍼센트로 세 번째입니다.

이 유로 환산은 Prozesskosten-Analyzer가 구조화해 자동으로 계산해 주는 바로 그 내용입니다. 직접 공식을 만들 필요는 없습니다.

3단계: 유로만이 전부는 아니다 — 세 가지 기준

유로가 주된 기준이지만 유일한 기준은 아닙니다. 두 가지 추가 요소가 비용이 큰 병목이 실제로 적절한 시작점인지 결정합니다:

• 비용 규모(유로/년) – 앞서 계산한 주된 기준입니다.
• 레버리지 가능성(개선 가능성) – 개선이 현실적으로 가능한가? 외부 기관이나 공급업체에 묶여 있는 병목은 내부에서 해결하기 어렵습니다.
• 위험과 전략 연관성 – 그 병목이 유동성, 규정 준수, 고객 만족 같은 중요한 것을 위협하는가? 그러면 추가로 고려합니다.

간단한 의사결정 논리: 2단계에서 가장 비용이 큰 두세 후보를 골라 이들만 레버리지 가능성을 점검하세요. 실제로 영향 줄 수 있는 가장 비싼 병목이 우선입니다. 최상위 후보가 완전히 외부에 의해 막혀 있다면, 레버리지가 높은 두 번째로 비싼 후보를 선택하세요. 열두 항목 가중치의 점수표에 빠져들지 마세요 – 그건 컨설턴트식 쇼입니다. 세 가지 기준, 하나의 결정.

4단계: 병목 요약서 작성

이제 하나의 병목을 확보했습니다. 다음으로 넘어가기 전에 네 줄짜리 요약서에 기록하세요 – 이렇게 해야 현업에서 통찰이 사라지지 않습니다:

• 어디: 어떤 프로세스의 어떤 구체적 지점인가?
• 얼마나 비용이 큰가: 연간 유로(2단계에서 나온 수치).
• 증상들: 다섯 징후 중 어떤 것이 해당되는가?
• 측정 지표: 나중에 성공을 입증하기 위해 어떤 단일 숫자를 측정할 것인가? (예: 청구서의 평균 처리시간)

이 마지막 항목은 FLOW의 나머지 단계에 결정적입니다. 원칙은: 먼저 측정하고, 그다음 정교화하는 것. 지금 기준값을 남기지 않으면 나중에 개선이 실제로 이루어졌는지 증명할 수 없습니다. 그때는 단지 느낌만 있을 뿐이며, 경영진에게 느낌은 통화 수단이 될 수 없습니다.

Find 다음에는 무엇이 오는가?

Find는 첫 단계일 뿐이며 해결책은 아닙니다. 하나의 병목을 식별하고 대략 금액을 산출하면 F 단계는 다음으로 넘깁니다:

• L = Lay bare: 병목을 유로로 정확히 산정하고 성숙도를 판단합니다 – 두 가지를 합쳐서 FLOW 값, 즉 출발 기준을 만듭니다.
• O = Optimize: 먼저 정리하고, 그 다음 정확히 하나의 레버를 선택합니다. “Optimize before Software” 원칙은 망가진 프로세스를 비싸게 디지털화하는 일을 막습니다.
• W = Wire & Watch: 레버를 실행하고 동일한 FLOW 값을 다시 측정합니다 – 진짜 전후 비교를 유로로 합니다.

F 단계를 건너뛰고 바로 해결책으로 뛰어들면 지붕에서 집을 짓는 꼴이 됩니다. 이러한 순서 오류가 대부분의 실패한 디지털화 프로젝트 뒤에 있습니다 – 자세한 내용은 IT 없이 프로세스 개선 글을 참조하세요. 정리만으로도 소프트웨어 도입 전 상당한 효과를 얻을 수 있습니다.

미니 체크리스트: F를 마쳤나요?

다음 다섯 항목을 모두 예라고 답할 수 있어야 다음 단계로 가십시오:

• 후보 병목 목록을 5~10개 만들었습니다.
• 그중 가장 비싼 세 개를 연간 유로로 대략 산정했습니다.
• 시작점으로 정확히 하나의 병목을 선택했습니다 – 세 개가 아닙니다.
• 그 하나의 병목을 한 문장으로 설명할 수 있고 비용을 하나의 숫자로 말할 수 있습니다.
• 나중에 성공을 확인할 측정 지표를 하나 정했습니다.

이 다섯 항목이 모두 충족되면 F 단계를 완료한 것입니다. 이제 문제가 있다는 것뿐 아니라, 먼저 어느 하나를 왜 해결해야 하는지 알고 있습니다.

무료 FLOW 진단: 가장 비용 큰 병목을 찾아보세요

병목 분석을 F 단계 도구로 사용하면 정확히 이 과정을 따라갑니다: 후보 수집, 유로 환산, 하나의 시작점 우선순위 결정. 메모장에 대충 적고 싶지 않다면 Engpass-Analyse로 시작하세요 – 무료, 가입 불필요, 몇 분 안에 신뢰할 수 있는 대략치가 나옵니다. 먼저 측정하고, 그다음 정교화하세요. 주기당 하나의 병목입니다.