식스 시그마란? DMAIC 실무 가이드

식스 시그마란 무엇일까요? 목표이자 방법입니다. 결함의 기준을 정하고, 발생 빈도를 측정하고, 편차의 원인을 찾아 제거한 뒤, 개선 효과가 유지되는지 계속 확인합니다. Define, Measure, Analyse, Improve, Control의 약자인 DMAIC는 문제를 정의하는 것부터 안정적으로 운영되는 프로세스를 만드는 것까지 이어주는 개선 사이클입니다.

식스 시그마는 널리 알려진 방법론이며, 실제로 적용하는 사람 대부분은 효과가 있는지 논쟁하기보다 개선 효과를 입증하는 데 관심이 있습니다. 개선이 검증 가능해야 하고, 그 검증에 1년이 아니라 몇 주가 걸리기를 바랍니다. 이 가이드에서는 식스 시그마의 의미와 DMAIC의 단계별 역할, 개선 사이클의 엄밀성을 유지하면서 process intelligence로 실행을 앞당기는 방법을 살펴봅니다.

식스 시그마란 무엇인가요?

식스 시그마는 편차를 줄여 결함을 덜 발생시키고 결과의 예측 가능성을 높이는 방법입니다. 프로세스가 매번 같은 방식으로 같은 결과를 내면 품질을 유지하기 쉽습니다. 비슷한 케이스에서 결과가 달라진다면 식스 시그마는 그 차이를 줄이는 데 초점을 둡니다.

Motorola가 1986년에 이 방법을 개발했고, General Electric이 1990년대에 도입했습니다. 품질을 측정할 수 있는 대상으로 바꿔준 덕분에 제조, 의료, 금융 서비스, 공유 서비스 분야로 확산됐습니다.

이름은 표준편차를 나타내는 통계 기호에서 유래했습니다. 식스 시그마의 의미는 성과 목표입니다. 프로세스의 자연스러운 산포가 규격 한계 안쪽으로 표준편차 6개만큼 들어오면 결함이 드물게 발생합니다.

이 수치는 식스 시그마에서 표준으로 사용되지만, 주의가 필요합니다. 결함률은 기회를 어떻게 정의하는지, 이를 뒷받침하는 데이터가 얼마나 완전한지에 따라 달라집니다. 그래서 DMAIC의 첫 단계는 통계가 아니라 기준을 명확히 하는 일입니다.

DMAIC 프로세스는 어떻게 진행되나요?

DMAIC는 기존 프로세스를 개선하는 5단계 사이클입니다. 각 단계는 서로 다른 질문에 답하고 다음 단계에서 활용할 근거를 만듭니다. 이 덕분에 식스 시그마를 통한 프로세스 개선을 일회성 프로젝트가 아니라 반복 가능한 방식으로 진행할 수 있습니다.

DMAIC의 5단계를 순차적으로 끝내는 방식이 아니라 하나의 사이클로 보면, 대부분의 개선 활동이 어떤 순서로 진행되는지 알 수 있습니다. 프로세스를 파악하고, 측정하고, 측정 결과를 설명하고, 변경을 적용하고, 그 상태를 유지합니다. 불편하다는 이유로 단계를 건너뛰지 않는 것이 단계 이름보다 중요합니다.

데이터를 보기 전에 문서화해야 하는 이유는 무엇인가요?

Define 단계는 DMAIC 프로젝트의 성패를 좌우합니다. 통계보다 기준을 명확히 하는 일이 더 중요합니다. 결함을 측정하려면 먼저 프로세스가 무엇인지, 어디서 시작하고 끝나는지, 누가 책임지는지, 어떤 상태를 좋은 결과로 볼지 정해야 합니다.

많은 프로젝트가 이 단계를 건너뜁니다. 워크숍에서 문제에 합의하고 곧바로 데이터를 추출한 뒤에야 시스템에 병목으로 여겼던 단계가 기록되지 않거나, 세 부서가 같은 이름으로 서로 다른 프로세스를 설명한다는 사실을 발견합니다. 합의되지 않은 프로세스는 측정만으로 바로잡을 수 없습니다.

문서화는 나머지 개선 사이클을 진행하는 데 필요한 기반입니다.

• 팀이 현재 이해하는 단계, 의사결정, 인계를 보여주는 프로세스 모델을 슬라이드가 아닌 BPMN 2.0으로 작성합니다.
• Measure 단계에서 Define 단계에서 합의한 것과 같은 대상을 측정하도록 모델에 연결된 결함 정의를 마련합니다.
• 활동별 역할과 책임을 정해 Improve 단계에서 변경을 승인할 담당자를 지정합니다.
• 실제 업무에 사용하는 문서, 즉 절차, 정책, 템플릿, 화면별 작업 안내를 관련 활동에 연결합니다.

ProcessMind에서는 시간이 지나며 낡아가는 폴더에 문서를 보관하는 대신, 모델과 함께 최신 상태로 유지할 수 있습니다. 팀은 AI 지원 프로세스 생성으로 초안을 만들고 모델링 캔버스에서 다듬은 다음, 관련 절차나 화면별 작업 안내를 자료로 첨부하고 버전 기록을 활용해 검토를 진행할 수 있습니다. 게시된 버전은 실제 업무를 담당하는 사용자가 Process Portal에서 확인할 수 있으므로 프로젝트에서 측정하는 프로세스를 모두가 살펴볼 수 있습니다. 프로세스 문서와 모델을 한 작업 공간에서 관리하면 서로 다른 내용으로 바뀌는 일을 막을 수 있습니다.

DMAIC 각 단계에서는 어떤 일을 하나요?

각 단계에는 정해진 결과물이 있습니다. 이 표에는 보통 어느 부분에서 시간이 많이 드는지도 함께 담았습니다. 마지막 항목이 바로 process intelligence로 달라지는 부분입니다.

대부분의 프로그램에서 병목이 되는 단계는 측정입니다. 기준선을 수작업으로 만들면 몇 주가 걸리고, 검토할 시간이 있었던 사례만 표본으로 삼게 됩니다. 분석 단계가 시작되기도 전에 기준선은 낡기 시작합니다. process mining은 DMAIC의 이 부분을 바꿉니다.

process mining은 DMAIC를 어떻게 지원하나요?

process mining은 시스템에 이미 기록된 이벤트 데이터를 바탕으로 사례가 실제 프로세스에서 어떻게 진행됐는지 재구성합니다. 사례 식별자, 활동, 타임스탬프가 있는 로그만으로도 실제 경로와 변형, 대기 시간, 재작업을 확인할 수 있습니다.

근거가 설명이 아니라 측정값이므로, DMAIC 반복 과정에서 다음 세 가지를 구체적으로 지원합니다.

• 측정: 검토할 시간이 있었던 일부 사례가 아니라 기록된 모든 사례를 바탕으로 기준선을 만듭니다.
• 분석: 변형을 비교해 지연과 재작업이 집중되는 지점을 찾고, 회의에서 가장 목소리가 큰 사람의 의견이 아니라 데이터로 원인을 검증합니다.
• 관리: 프로젝트가 끝난 뒤에도 같은 측정을 이어가 예전 업무 방식으로 되돌아가는 징후를 조기에 파악합니다.

process mining은 Six Sigma를 대체하지 않으며, 정의나 개선 단계에서 필요한 사고 과정을 대신하지도 않습니다. 측정에 시간이 오래 걸리고 관리가 불안정해지는 원인인 수작업 데이터 수집과 검토를 줄여줍니다. 기능은 process mining 페이지에서 확인하거나, 흐름을 재구성하는 방법은 process mining 문서에서 살펴보세요. 분석을 시작할 때 DMAIC 팀이 가장 먼저 활용하는 두 가지 관점은 프로세스 변형과 적합성 검사입니다.

프로세스 분석과 대시보드는 개선 효과를 어떻게 유지하나요?

관리 단계에서는 개선 효과가 조용히 사라질 수 있습니다. 프로젝트가 끝난 뒤 측정하지 않는 변화는 근거를 들어 설명할 수 없으며, 아무도 열어보지 않는 대시보드는 관리 수단이 아닙니다.

프로세스 분석을 활용하면 측정 결과를 프로세스 담당자가 실행에 옮길 수 있는 정보로 바꿀 수 있습니다. 기준선 대비 사이클 타임과 결함 추이, 문서화된 모델 대비 규정 준수 여부, 단순히 수치를 보고하는 데 그치지 않고 조치가 필요한 시점을 알려주는 기준값을 확인할 수 있습니다. ProcessMind에서는 북마크에 검토에 필요한 필터와 측정값을 저장하고, 프로세스 상태에서 각 지표의 기준 범위를 설정하며, 대시보드와 KPI를 통해 담당자가 결과를 확인할 수 있습니다. 이러한 화면을 구성하는 방법은 맞춤형 대시보드 문서에서 확인하세요.

관리도를 볼 때 전문가가 확인하는 기준은 간단합니다. 이 화면과 기준값만으로 담당자가 지난달과 비교해 프로세스가 달라졌는지 알 수 있나요? 그렇지 않다면 관리 단계는 관리 수단이 아니라 문서에 그칩니다.

Six Sigma 벨트 역할은 무엇을 의미하나요?

벨트 명칭은 Six Sigma 프로그램에서의 역할을 나타냅니다. 누가 어떤 프로젝트를 이끌 수 있는지 간략하게 구분할 때 유용합니다. 조직마다 책임 범위는 다르지만, 일반적으로 다음과 같이 나뉩니다.

• 챔피언 또는 스폰서: 리소스를 확보하고 장애물을 해결하는 관리자입니다.
• 마스터 블랙벨트: 프로젝트 팀을 코칭하고 방법론을 지키는 숙련된 실무자입니다.
• 블랙벨트: DMAIC 업무를 이끄는 프로젝트 책임자입니다.
• 그린벨트: 주로 한 부서에서 본업과 함께 프로젝트를 이끄는 실무자입니다.
• 옐로벨트 또는 화이트벨트: 프로세스 지식이나 데이터를 제공하는 팀원입니다.

데이터를 활용하는 DMAIC 반복 과정은 벨트 색상에 좌우되지 않습니다. 필요한 것은 변화를 승인할 수 있는 프로세스 담당자, 근거를 읽을 수 있는 사람, 측정 결과를 있는 그대로 살펴볼 의지가 있는 팀입니다. 직함은 이런 역할을 가늠하는 기준일 뿐, 중요한 것은 실제 업무입니다.

Lean, Six Sigma, Lean Six Sigma는 어떻게 다른가요?

Lean과 Six Sigma는 서로 다른 질문에 답합니다. 두 방법론을 혼동하는 경우는 대부분 이름에서 비롯됩니다.

• Lean은 낭비를 줄이고 흐름을 개선합니다. 업무 흐름에서 대기, 인수인계, 과잉 처리, 재고, 이동, 결함을 살펴봅니다.
• Six Sigma는 변동과 결함을 줄입니다. 측정과 분석을 통해 비슷한 두 사례가 서로 다른 결과로 이어지는 이유를 파악합니다.

Lean Six Sigma는 lean 6 sigma라고도 쓰며, 두 방법을 결합합니다. Lean으로 업무 흐름을 개선하고, Six Sigma로 결과의 예측 가능성을 높입니다. 혼란스럽게도 “lean and six sigma”와 “six sigma and lean six sigma”를 별개의 방법론처럼 말하는 경우가 있지만, 두 표현은 같은 조합을 가리킵니다. 적용 순서는 문제에 따라 달라집니다. 느리지만 안정적인 프로세스라면 Lean 관점에서 먼저 살펴보고, 빠르지만 일관성이 없다면 변동을 줄이는 작업부터 시작합니다. 가치 흐름 매핑 가이드에서 Lean 측면을 다루며, 프로세스 개선 기법 목록에서는 두 방법을 process mining 및 시뮬레이션과 비교합니다.

우리가 DMAIC를 중심에 두는 이유는 무엇인가요?

반복해서 활용할 수 있는 것은 DMAIC의 순환 과정이기 때문입니다. 벨트, 통계, 프로젝트 헌장은 모두 어떤 팀이든 어떤 프로세스에든 적용할 수 있는 순환 과정을 지원합니다. 이 과정을 거듭할수록 다음 개선은 더 적은 비용으로 진행할 수 있습니다.

Six Sigma만이 프로세스를 개선하는 유일한 방법이라고 생각하지 않으며, 방법론을 옹호해야 한다고 보지도 않습니다. DMAIC가 개선의 순환 과정이고, 도구는 그 과정을 더 빠르게 진행하도록 도와야 한다고 생각합니다.

이것이 플랫폼의 방향입니다. Six Sigma를 배제하는 것이 아니라, 팀에 필요한 것은 개선의 순환 과정이며 그 과정에서 이미 보유한 데이터로 측정해야 한다는 판단입니다. Lean Six Sigma 및 DMAIC 가이드에서 각 단계에 데이터 결과물을 연결한 이유도 여기에 있습니다.

Six Sigma가 적합하지 않은 경우는 언제인가요?

결함을 정의하고 안정적으로 측정할 수 있으며, 줄일 만한 변동이 충분할 때 Six Sigma의 효과가 가장 큽니다. 대량으로 반복되는 프로세스나 규정에 따라 품질 기준이 정해지는 산업에 잘 맞습니다. 반면 주요 문제가 변동이 아니라 흐름에 있거나, 프로세스가 새로 만들어졌거나, 아직 데이터가 충분하지 않다면 적합성이 떨어집니다.

그렇다고 DMAIC를 포기할 이유는 없습니다. 문제를 정의하고, 가능한 범위에서 측정하고, 원인을 찾고, 변화를 적용하고, 그 변화를 유지하는 순환 과정은 여전히 유효합니다. 달라지는 것은 통계 기법을 얼마나 활용하느냐입니다. 온보딩, 영업 파이프라인, 서비스 데스크를 개선하는 팀에는 실험 계획법이 필요하지 않을 수 있지만, 생산 라인의 결함을 줄이는 팀에는 거의 반드시 필요합니다. 프로세스가 고장 난 것이 아니라 새로 만드는 것이라면 Design for Six Sigma(DMADV)를 살펴보세요. 변동보다 대기가 문제라면 Lean 도구가 더 큰 도움이 됩니다.

Six Sigma 프로젝트는 어떻게 시작하나요?

몇 달이 아니라 몇 주 안에 근거를 얻을 수 있는 방식으로 시작하는 것이 가장 빠릅니다.

1. 프로세스를 문서화합니다

   시작점과 종료점, 담당자, 해결하려는 결함을 정합니다. 회의보다 모델에서 프로세스를 두고 논의하는 편이 효과적입니다.

2. 표본을 뽑기 전에 데이터를 확인합니다

   프로세스의 사례 식별자, 활동, 타임스탬프를 시스템에 기록하고 있는지 확인합니다. 그렇다면 로그를 활용해 측정 단계부터 시작할 수 있습니다.

3. 변형을 포함해 실제 흐름을 측정합니다

   예상과 다른 경로를 거치는 사례를 셉니다. 변동이 분석 대상이므로 평균을 내어 차이를 없애면 문제의 원인을 놓칩니다.

4. 한 번에 하나씩 변화를 검증합니다

   전면 도입 전에 시뮬레이션으로 선택지를 비교합니다. 근거가 뒷받침하는 변화를 시범 적용한 뒤 무엇이 달라졌는지 측정합니다.

5. 담당자에게 관리 책임을 넘깁니다

   기준선과 측정값, 기준값을 프로세스 담당자가 업무를 수행하는 곳에 두고, 검토를 통해 개선 효과가 유지되는지 확인합니다.

Six Sigma 첫 프로젝트부터 이어져 온 원칙은 같습니다. 개선 방안을 정하기 전에 프로세스를 측정해야 합니다. 달라진 점은 이제 수작업으로 측정하지 않아도 된다는 것입니다. 전체 방법은 데이터 기반 DMAIC 가이드에서, 모니터링 방법은 프로세스를 지속적으로 모니터링하는 방법에서 확인하세요.