Lean Six Sigma와 DMAIC: 데이터 기반 Lean 프로세스 개선

Lean 프로세스 개선은 업무 시간이나 품질이 저하되는 지점을 찾고, 근거를 바탕으로 변경을 시험할 수 있는 체계적인 방법입니다. 이 가이드에서는 Lean Six Sigma와 DMAIC가 개선 활동에 어떻게 활용되는지, 각 단계에 어떤 데이터가 필요한지, 주문부터 대금 회수까지의 프로세스에 어떻게 적용할 수 있는지 설명합니다. 신뢰할 수 있는 기준선, 가정을 검증하는 분석, 개선을 지속하는 관리 방안에 중점을 둡니다.

Lean 프로세스 개선은 도구를 모아놓은 것 이상입니다. DMAIC는 프로세스를 조사하고 변경 사항을 결정하는 데 실용적인 틀을 제공합니다.

Lean Six Sigma란 무엇이며, 무엇이 아닌가요?

Lean, Six Sigma, Lean Six Sigma는 서로 관련이 있지만 각기 다른 문제를 다룹니다.

Lean은 대기, 불필요한 인계, 재작업처럼 가치를 더하지 않는 업무를 줄이는 데 목적이 있습니다. Six Sigma는 변동과 결함을 줄이는 데 목적이 있습니다. Lean Six Sigma는 두 목표를 체계적인 개선 활동으로 결합합니다.

가치 흐름 매핑을 비롯한 Lean 매핑은 업무가 어떻게 흘러야 하는지 나타내는 데 도움이 됩니다. 프로세스 데이터를 더하면 케이스가 실제 시스템에서 어떻게 처리되는지도 확인할 수 있습니다. 프로세스 맵과 데이터를 함께 살펴보면 예상과 실제 프로세스의 차이를 논의할 근거가 생깁니다.

Lean Six Sigma가 무엇이 아닌지도 알아두면 좋습니다.

• 자격증 프로그램이 아닙니다. 벨트는 교육 형식입니다. 자격증이 측정된 기준선이나 실제 개선 프로젝트를 대신하지는 않습니다.
• 프로세스 지식을 대신하지 않습니다. DMAIC는 조사에 구조를 제공하지만, 팀은 여전히 업무와 제약 조건을 이해해야 합니다.
• 일회성 프로젝트가 아닙니다. Control 단계는 프로젝트 팀이 업무를 마친 뒤에도 프로세스를 모니터링할 방법을 제공합니다.
• 제조업에만 적용되지 않습니다. 사무 업무에도 대기, 재작업, 인계, 불필요한 단계가 있습니다.

DMAIC에 의견이 아닌 데이터가 필요한 이유

프로세스가 개선됐는지 판단하려면 먼저 기준선이 필요하기 때문에 DMAIC에는 Measure 단계가 있습니다. 기준선이 없으면 Analyze 단계가 누구의 기억이 맞는지를 두고 논쟁하는 자리가 될 수 있습니다.

직접 관찰하고 표본을 조사하면 프로세스를 이해하는 데 도움이 되지만, 관찰한 케이스와 단계만 확인할 수 있습니다. 사무 프로세스는 ERP, CRM, 티켓 관리 시스템, 스프레드시트에 걸쳐 진행될 수 있습니다. 한 명의 관찰자가 모든 케이스를 처음부터 끝까지 볼 수는 없습니다.

시스템에 케이스 참조 정보, 활동, 타임스탬프가 기록된다면 이벤트 기록을 활용해 케이스가 프로세스를 어떻게 거쳤는지 재구성할 수 있습니다. 각 관찰을 일일이 수집하는 대신 데이터를 확인하고 결과를 해석하는 데 집중할 수 있습니다. process mining은 프로세스 전반의 기록을 살펴보는 한 가지 방법입니다.

문서화된 업무와 실제 업무를 비교하면 다음 두 가지 차이를 확인할 수 있습니다.

• 프로세스 다이어그램에는 있지만 실제로는 수행하지 않는 단계. 통제가 더는 이루어지지 않거나 승인이 더 이상 필요하지 않을 수 있습니다.
• 실제로 수행하지만 다이어그램에는 없는 단계. 명확한 담당자나 검토 절차 없이 임시방편이 일상적인 방식으로 굳어졌을 수 있습니다.

Lean 프로세스 개선을 위한 DMAIC 5단계

DMAIC는 Define, Measure, Analyze, Improve, Control의 다섯 단계로 진행됩니다. 각 단계는 서로 다른 질문에 답하고 결과물도 다릅니다. 이 Lean 프로세스 개선 단계에 따라 문제를 정의하고 변경 사항을 모니터링할 수 있습니다.

Define: 문제, 범위, CTQ 설정

데이터로 대체하는 것: 범위에 포함할 케이스와 활동에 대한 추정.

해결할 문제와 프로세스의 경계, 고객이나 비즈니스에 중요한 품질 특성(CTQ) 지표를 정의합니다. 먼저 케이스 하나를 어떻게 정의할지 합의합니다. 주문, 티켓, 송장, 청구 건 등이 케이스가 될 수 있습니다. 이 선택에 따라 어떤 이벤트를 하나로 묶을지 정해지고, 이후 모든 지표에도 영향을 미칩니다.

프로세스 데이터를 활용해 팀의 초기 이해가 현재 업무 흐름과 일치하는지 확인합니다. 분석 과정에서 워크숍에서 언급되지 않은 변형이나 지표가 드러날 수 있습니다. 팀이 같은 내용을 검토할 수 있도록 프로세스 맵이나 BPMN 다이어그램에 범위를 문서화합니다.

기대할 수 있는 결과: 한 팀이 책임질 수 있는 범위, 모두가 이해하는 케이스 정의, 보유 데이터로 측정할 수 있는 CTQ.

Measure: 처리 시간, 비용, 재작업의 기준선 설정

데이터로 대체하는 것: 현재 성과를 대신 나타내는 추정치와 소규모 표본.

Define 단계에서 합의한 CTQ를 기준으로 프로세스를 측정합니다. 데이터와 프로젝트 범위에 따라 케이스별 처리 시간, 비용, 재작업을 포함해 기준선을 설정할 수 있습니다.

프로세스가 여러 시스템에 걸쳐 있다면 각 시스템의 기록을 어떻게 연결할지 확인합니다. 합의한 케이스 식별자를 기준으로 로그를 결합하면 여러 시스템에서 케이스를 추적할 수 있습니다. 결과를 활용하기 전에 결합 방식과 타임스탬프를 검증하세요. 일부 기록이 빠지거나 잘못 결합되면 기준선이 실제보다 정확해 보일 수 있습니다.

목표를 정하기 전에 기준선으로 현재 성과를 설명합니다. 추출하기 쉽다는 이유만으로 지표를 고르지 말고, 문제 정의와 연결된 지표를 사용합니다.

기대할 수 있는 결과: 프로세스 책임자가 검토할 수 있는 기준선과 그에 적용된 가정 및 데이터 한계.

실제 프로세스 데이터로 기준선을 설정하는 방법 알아보기.

Analyze: 병목, 변형, 규정 준수 격차 찾기

데이터로 대체하는 것: 실제 프로세스 동작과 대조하지 않은 워크숍 가설.

근거를 분석해 성과가 달라지는 이유를 파악합니다. 지연이 어디에 쌓이는지, 어떤 프로세스 변형이 발생하는지, 덜 일반적인 경로를 따르는 물량은 얼마나 되는지, 케이스가 의도한 프로세스와 어디에서 달라지는지 살펴봅니다.

프로세스 변형은 케이스가 프로세스를 거치는 여러 경로 가운데 하나입니다. 변형을 비교하면 지연이 널리 발생하는지 특정 경로에 집중되는지 알 수 있습니다. 규정 준수 분석은 실제 동작과 의도한 프로세스를 비교해 차이가 나는 지점을 찾는 데 도움이 됩니다.

잠재 원인을 영향도에 따라 우선순위화하고 데이터를 통해 검증합니다. 분석 결과 팀의 초기 가설이 확인될 수도 있지만, 주요 제약이 다른 곳에 있다는 사실이 드러날 수도 있습니다. 실무 예시는 프로세스를 분석하고 병목을 찾는 방법을 참조하세요.

기대할 수 있는 결과: 근거로 뒷받침되고 검증 가능성이 열려 있는 근본 원인 후보와 우선순위.

Improve: 적용 전에 변경 사항의 우선순위를 정하고 시험하기

데이터로 대체하는 것: 익숙하거나 발표하기 쉽다는 이유로 변경을 선택하는 방식.

분석 결과를 바탕으로 확인된 원인을 해결할 변경 사항을 찾습니다. 예상 효과와 필요한 노력, 위험을 비교합니다. 가능하다면 목표 프로세스를 모델링하고 적용 전에 여러 시나리오를 시뮬레이션합니다. 시뮬레이션을 실제 결과의 보장으로 여기지 않으면서 변경이 프로세스에 미칠 영향을 살펴볼 수 있습니다.

실무자가 새로운 흐름을 이해할 수 있도록 목표 프로세스를 문서화합니다. 적용 후에는 기준선에 사용한 지표를 그대로 측정합니다. 이를 비교하면 변경으로 성과가 개선됐는지, 다른 곳에 새로운 제약이 생겼는지 평가할 수 있습니다.

기대할 수 있는 결과: 기준선과 비교해 시험한 변경 사항과 적용 후 실제 성과를 확인할 계획.

Control: 성과, 대시보드, 담당자 모니터링

데이터로 대체하는 것: 간헐적인 감사나 기억에 의존해 성과 변화를 알아차리는 방식.

Control 단계는 개선을 유지하는 데 도움이 됩니다. 모니터링할 지표와 검토를 시작할 임계값을 정하고, 대응 책임자를 지정합니다. 대시보드를 통해 프로세스 책임자는 성과 변화 여부와 조사할 지점을 확인할 수 있습니다.

검토 주기와 지표가 예상 범위를 벗어났을 때 취할 조치를 합의합니다. 물량이나 케이스 구성이 바뀌면 프로세스와 목표가 여전히 적절한지 검토합니다.

기대할 수 있는 결과: 명확한 담당자와 검토 기준, 성과 저하를 파악하고 다음 조치를 결정하는 데 도움이 되는 지표. 지속적인 측정에 대한 자세한 내용은 프로세스를 지속적으로 모니터링하는 방법을 참조하세요.

실제 사례: 주문부터 대금 회수까지

주문부터 대금 회수까지의 프로세스에 5단계를 적용하면 다음과 같습니다. 아래 수치는 예시일 뿐, 보장되는 결과가 아닙니다.

Define. 한 제품군의 주문부터 대금 회수까지를 프로젝트 범위로 설정합니다. 주문이 접수되면 케이스가 시작되고 송장 대금이 지급되면 종료됩니다. CTQ는 송장 정확도와 현금 회수까지 걸리는 시간입니다. 현금 회수가 늦어지는 것이 문제라면 배송보다 대금 지급을 종료 시점으로 삼는 편이 적절합니다.

Measure. 팀은 주문 번호를 기준으로 ERP와 청구 시스템의 이벤트 데이터를 결합합니다. 기준선에 따르면 주문 접수부터 대금 지급까지 걸리는 시간의 중앙값은 34일입니다. 이 중 11일은 송장 생성부터 발송까지 걸립니다.

Analyze. 지연은 특정 경로에 집중됩니다. 이 예시에서는 주문의 22%가 수동 신용 검토를 거치며 9일이 추가되고, 송장 6건 중 1건은 재발행되어 대금 지급 기간이 다시 시작됩니다. 두 경로 모두 문서화된 프로세스 모델에는 없습니다.

Improve. 팀은 예외 건에 수동 검토를 집중하도록 신용 한도를 높이는 방안을 검토합니다. 과거 데이터를 활용한 시뮬레이션에서는 해당 데이터의 대손이 늘지 않으면서 주문의 18%에서 9일을 단축할 가능성이 나타납니다. 적용 후 실제 성과를 검토해야 합니다.

Control. 팀은 수동 경로를 거치는 주문의 비율을 추적하고 검토 기준을 설정합니다. 주문 처리 담당 부서가 지표를 관리하며, 프로세스 담당 팀이 대시보드를 확인할 수 있습니다.

Lean 프로세스 개선에서 흔히 발생하는 실패 원인

DMAIC 프로젝트가 문서상으로는 올바른 단계를 따르더라도 실질적인 변화를 만들지 못할 수 있습니다. 다음과 같은 패턴에 주의하세요.

• 벨트 중심의 관료주의. 팀이 프로세스나 데이터를 확인하기 전에 프로젝트 문서 작성에 시간을 씁니다. 프로젝트 헌장과 이해관계자 맵은 도움이 될 수 있지만, 그 자체로 진척을 입증하지는 않습니다.
• 신뢰할 수 있는 기준선이 없음. Measure 단계를 건너뛰거나 설문에만 의존하면 Analyze 단계에서 검증할 근거가 부족합니다. 시작점이 없으면 나중에 타당한 비교를 할 수 없습니다.
• 프로그램 수준에서 범위를 설정함. 범위가 넓은 프로그램은 단일 책임자나 케이스 정의가 없고, 한 팀이 영향을 미칠 수 있는 지표도 없을 수 있습니다. 경계와 책임이 분명한 프로세스로 범위를 좁히세요.
• 분석 전에 개선 방안을 선택함. 팀이 자동화하거나 재설계할 대상을 이미 정했다면 그 선택을 뒷받침하는 근거만 찾을 수 있습니다. Analyze 단계에서는 미리 정한 해결책을 정당화하지 말고 원인 가설을 검증하세요.
• Control 단계가 없음. 프로젝트 종료 후 지표를 관리하는 사람이 없으면 성과 변화를 놓칠 수 있습니다. 프로젝트를 마무리하기 전에 담당자와 임계값, 검토 주기를 정하세요.

ProcessMind가 DMAIC 각 단계를 지원하는 방법

ProcessMind를 활용해 프로세스 데이터를 살펴보고, 프로세스 흐름을 문서화하고, 성과를 분석하고, 제안된 변경을 시뮬레이션할 수 있습니다. 조사 과정은 지원하지만, 변경 사항을 결정하고 실행하는 것은 팀의 역할입니다. 이 Lean 프로세스 개선 도구는 프로세스 전문성이나 책임을 대신하지 않으면서 DMAIC 주기에 근거를 더합니다.

각 단계는 동일한 프로세스 정의를 공유합니다. 단계마다 다른 데이터나 프로세스 관점을 사용하면 팀은 개선 효과를 평가하기보다 차이를 조정하는 데 시간을 쓸 수 있습니다.

분석 워크플로 개요는 프로세스 데이터를 분석하는 방법을 참조하세요. 프로세스 모델링과 process mining이 서로 어떻게 보완하는지 알아보려면 프로세스 모델링과 process mining의 결합된 역할을 읽어보세요.

DMAIC 프로젝트 시작하기

다음 단계에 따라 포괄적인 개선 목표를 팀이 측정할 수 있는 프로젝트로 구체화하세요. 이 Lean 프로세스 개선 모델은 팀이 정의하고 측정하고 검토할 수 있는 프로세스에 첫 주기의 초점을 맞춥니다.

1. 책임자가 명확한 프로세스를 선택합니다. 프로세스 책임자가 없으면 Control 단계의 책임을 지정하기 어렵습니다.
2. 케이스 정의에 합의합니다. 케이스의 시작과 종료를 기록하고, 해당 이벤트를 포착하는 시스템을 확인합니다.
3. 개선 전에 측정합니다. 워크숍이나 재설계 작업에서 목표 상태를 정하기 전에 기준선을 설정합니다.
4. 첫 주기의 범위를 좁게 잡습니다. 팀이 조사하고 검토할 수 있는 범위에서 시작한 뒤, 얻은 정보를 바탕으로 다음에 살펴볼 대상을 정합니다.

변경 사항을 검증한 후 개선 사항을 실행에 옮기세요.

다음 단계

측정된 기준선으로 DMAIC 프로젝트를 시작하세요.

측정된 기준선으로 DMAIC 프로젝트 시작하기