bobozzang.

모든 일상업무, 통계로 통한다
통계는 쉽지 않다고 말한다. 통계를 포함한 6시그마는 더욱 쉽지 않다고 한다. 하지만 직장 생활의 커뮤니케이션 대부분은 통계로 이뤄지고 있다. 우리 주변에서 자주 마주치는 상황을 알아보자.
가령 “요즘 중앙SUNDAY에 대한 구독자 반응이 어떤가?”라는 질문에 “꽤 많은 구독자가 좋다고 하던데요”라고 답하기 보다 “○개월간 평균 중지율 자료를 확인해 보니 ○%로 본지 대비 낮습니다”라거나, “구독자 1000명을 조사한 결과 62%가 ‘매우 만족한다’고 했는데, 여성보다 남성 독자의 만족도가 높습니다”라고 답한다. 보다 분명한 의사결정이 가능해지기 때문이다.
또한 마케팅 회의나 영업 보고 등 업무 회의가 있는 자리에는 늘 ‘보고 대상에 대한 그래프’가 화면이나 보고서에 출력되는 것을 볼 수 있다. 관심 대상에 대한 자료를 수집·분석하여 ‘의미 있는 정보’를 얻기 위해서다.
이처럼 관심 대상에 대한 자료를 수집하고, 수집된 자료를 정리·요약하여 새로운 정보를 얻어내거나, 모든 가능한 정보를 기초로 미지의 사실에 대한 추측 및 의사결정을 하는 것, 이를 통계라 한다. 일반 업무를 수행하는 우리의 현재 모습과 어떻게 다른가? 6시그마가 통계를 강조하는 것이 아니라, 일상 업무가 통계가 아닌 방식으로 이뤄진다는 것을 상상하기 어려울 뿐이다.
6시그마 프로젝트를 지도하는 위원들은 프로젝트의 정의(DMAIC의 Define) 단계를 매우 중요하게 여긴다. 프로젝트 수행의 목적과 목표, 범위를 담고 있기 때문이다. 그중에서도 보고서의 도입 부분인 문제 기술, 개선 기회 파악에 많은 시간을 투입한다. 심지어 이 과정을 통해 ‘의미 있는 정보’를 담아내느냐 그렇지 못하느냐에 따라 프로젝트의 성공과 실패가 나뉘기도 한다.
문제를 기술하고 개선 기회를 파악하기 위해, 즉 관심 대상에 대한 자료를 수집·분석하기 위해 사용하는 통계 도구가 바로 막대·원·띠·꺾은선 등의 ‘그래프’다. 그래프는 데이터를 도형으로 나타내어 수량의 크기를 비교하거나 수량의 변화 형태를 알기 쉽게 나타낸 것이다. 그래프로 정보를 의미 있게 나타내고 해석하는 것이 통계의 시작이다.

▶추천 동영상 : 황금알을 낳는 숫자, 통계(통계교육원 e러닝 센터(http://elearn.nso.go.kr/) →열린 공부방→공개 동영상→게시물 No3.‘황금알을 낳는 숫자, 통계’ 클릭
이효정 부장·6시그마사무국

때는 1920년대 어느 무더운 여름날 오후…. 영국 케임브리지에서 몇 명의 사람이 앞 마당 탁자에 앉아 차를 마시고 있었다. 그 중 한 부인이, 우유에 차를 부어 마실 때와 차에 우유를 부어 마실 때 차 맛이 다르다고 주장했다. 대부분의 사람들은 그녀의 말에 반박했다. 이 때 한 남자가 부인 이야기의 진위를 가릴 수 있는 실험 방법을 제안했다.
만일 그녀가 차 한잔을 건네 받았을 때 맛을 알아낼 능력이 없더라도 그 혼합의 각각에 대해 혼합순서를 맞힐 확률은 50%다. 그녀가 맛에 대한 감각이 예민해서 두 잔의 차를 마셨을 때 맛의 차이를 알아 낼 수 있다면 여전히 두 잔을 맞힐 수 있을 것이다. 역으로 그녀가 혼합순서에 따른 차 맛의 차이를 정확하게 분간 할 수 있는 능력을 가졌더라도 물이 충분히 뜨겁지 않았을 때 차와 우유가 제대로 섞이지 않을 가능성 때문에 제대로 답을 못하는 경우도 있다.
이러한 의사결정의 오류를 줄이기 위해서 우리는 실험을 정교하게 계획하는 것이 필요하다. 우선 혼합된 차를 마시는 순서를 무작위로 선택해 실시함으로써 차와 우유의 혼합순서 이외의 다른 원인이 결과에 미치는 영향을 최소화하도록 해야 한다(랜덤화의 원리). 또 같은 방법으로 만들어진 차를 2번 이상 반복하게 해 판단 결과의 오차를 정확하게 추정하고 신뢰성을 높여야 한다(반복성의 원리).
또 실험의 결과를 해석하기 위해서는 참값과 부인의 의사결정 값의 비교, 부인의 의사결정 간의 비교 방법을 이용할 수 있을 것이다. 실험 결과 부인의 말이 사실임이 입증되었다.
이 실험은 어떤 계측 시스템이 정확하게 실제 값을 읽어낼 수 있는 능력이 있는지를 가늠하기 위해 사용하는 ‘측정시스템 분석(MSA)’에 자주 사용되는 기법이다. 즉, 부인의 ‘혀’라는 측정시스템이 맛을 정확하게 구별하는 능력이 있는지 계획된 실험에 의해서 검증해 나가는 방법이다.
또 비슷한 방법으로 가장 좋은 맛을 내도록 우유와 차의 혼합비율을 결정해야 한다면 이는 ‘실험계획법’에 해당한다. 통계라는 것을 ‘참(truth)을 찾기 위한 과정의 연속’이라고 보면, 나이팅게일이 말한 ‘신의 생각을 이해하기 위해서는 통계학을 공부해야 한다. 통계학이야말로 신의 의도를 측정하는 것이니까’라는 말이 의미를 더해 간다.
성기욱 위원·누리혁신연구소

처음 6시그마 과제를 수행하는 리더들이 가장 힘들어하고 어려움을 호소하는 것 중에 하나가 바로 ‘통계’다. 그러나 통계에 대한 기본적인 원리와 개념을 이해한다면 관련 소프트웨어를 이용해 프로젝트에 충분히 활용할 수 있다.
향수의 냄새만으로 고급 향수와 모조품의 향을 구별할 수 있을까? 일반적으로 ‘냄새를 구분할 수 없다’는 것이 정설이다. 향수 냄새를 구별할 수 있는지 없는지를 테스트해 보면, 첫 번째 시도에서 우연히 맞힐 확률은 2분의 1이다. 두 번째 시도에서도 연속해서 우연히 맞출 확률은 4분의 1이다. 이런 식으로 5회 모두 연속해서 정답을 맞힐 확률은 　 , 3%다.
즉, 어떤 사람이 ‘테스트에서 구별 능력 없이 아무렇게나 말하고 있다’라고 가정하면 5회 모두 정답을 맞힐 확률은 3%밖에 안 된다는 것이다.
‘향수의 판별능력이 있다’라고 하는 이 판정은 3%의 확률로 틀릴지 모르지만, 반대의미는 97%는 옳다는 것으로 이 판정을 인정해도 좋다. 이와 같이 ‘어떤 사람에게 향수 판별능력이 있다’라는 가정을 세워 그것이 옳은지 아닌지를 판정하는 것을 통계학에서는 ‘검정(檢定)’이라 하며, 이때의 가정을 통계학에서는 관례적으로 ‘가설(hypothesis)’이라고 한다. 또한 검정이 틀릴 확률 즉, 5회 연속 정답의 사례에서는 3%를 ‘유의수준(Level of Significance)’ 혹은 ‘위험률’이라고 한다.
결론적으로 어떤 한정된 데이터에서 우열이나 상이(相異)의 유무 등을 판정해야 할 때, 어떤 가설을 세워 그 가설이 옳은지의 여부를 어느 정도 틀릴 위험을 각오한 다음 판정하는 것이 검정이다.
또한 통계학에서는 보통 5% 이하의 확률은 작다 ‘1% 이하의 확률은 매우 작다’ 0.5% 이하의 확률은 극히 작다고 간주한다.
결국 위험수준을 5%로 타협을 한다면 5회 연속 정답을 맞히면 확실히 ‘향수의 식별능력’이 있다고 판정할 수 있고, 위험수준을 1%로 한다면 7회 연속 정답을 맞히야 식별능력이 있음을 증명할 수 있는 것이다.
위 사례와 같이 여러분도 6시그마 과제뿐만 아니라 일상생활에서도 평소 관심이 있었던 가정에 대해 실험을 통해 판정능력을 테스트해 볼 수 있을 것이다.
◆사례 인용 : 통계를 알면 인생이 달라진다.(오오무라 히도시)
김재배 이사·누리혁신연구소

관리(Control) 단계는 프로젝트 결과물의 지속적인 유지에 초점을 맞추고 있다. 이 과정에서 프로젝트 리더가 종종 실수하는 대목은 무엇일까.

▶유형 1. 실수방지책도 개선안이다.
효과적인 개선안이라 하더라도 그것을 적용하는 데는 크고 작은 위험이 존재한다. 이러한 실수를 방지하기 위해 Control 단계에서 Fool-Proofing(실수방지책)이 강조된다. 그러나 사실은 이미 이전 단계(Improve)에서 개선안을 수립할 시점부터 그런 실수의 위험을 예측하고 사전에 방지할 수 있는 방안을 개선안에 포함시키는 것이 훨씬 더 효과적이다. 이후에도 발생할 수 있는 실수에 대비해 추가적인 대책을 수립하자는 것이 Control 단계에서 잠재위험 분석을 하는 목적이다.

▶유형 2. 관리의 초점은 CTQ(Y)보다 Vital Few X’s에 두자
Control 단계에서는 개선안의 지속적인 유지관리를 위한 Process Control Plan을 수립한다. 이상 징후가 발견되면 즉시 대응할 수 있도록 하자는 것으로 일종의 조기경보 시스템인 셈이다. 그런데 많은 프로젝트들이 결과지표인 CTQ(Y)에 대해서만 관리의 초점을 맞춘다. 그러나 결과지표를 관리하는 것보다는 핵심원인에 대한 지표를 관리하는 것이 훨씬 효과적임을 알아야 한다. 결과만을 모니터링하다가는 문제가 생겼을 때 원인을 즉시 파악할 수 없게 되고, 그에 따른 조치를 취하는 데 많은 시간이 들기 때문이다.

▶유형 3. 프로젝트 제출은 곧 프로젝트 종료?
우리가 추진하는 프로젝트는 범위·난이도·특성 등이 매우 다양하다. 그러나 관리 목적상 Wave(반기) 단위로 프로젝트가 동시에 진행되다 보니 많은 사람이 프로젝트 문서를 제출함과 동시에 프로젝트가 종료된 것으로 인식한다는 것이다. 실제 여러 가지 자원·환경의 제약으로 인해 DMAIC가 다 끝나도 개선안이 적용되지 못하는 경우가 많다. 심지어 시험 적용(Pilot Test)도 제대로 하지 못한 채 프로젝트를 종결시키는 경우도 있다. 모든 개선안을 적용시킬 때까지 프로젝트가 끝난 게 아니라는 것을 잊지 말자.
6시그마의 진정한 성과는 Control 단계의 노력에 달려 있다. 철저한 사후관리 계획과 이를 지속적으로 실행하는 노력이 있어야만 그 성과를 오래도록 누릴 수 있다.
성기욱 위원·누리혁신연구소

힘들고 어려웠던 과정을 지나 드디어 개선안을 도출하고 구체화해 당초 목표했던 성과를 이루는 Improve 단계. 여기에서 너무 성급한 개선안을 도출한다거나 이론적으로 당연하리라 예상했던 결과가 현실화되지 못한 사례를 흔히 볼 수 있다.

▶유형1. 분석 결과에 따라 개선안이 선정되었는가?
분석단계에서 다양한 정성적 분석과 통계적 가설검정 결과에 따라 확정된 핵심원인변수들에 대해 개선단계에서는 각각의 해결 방안들을 도출한다. 하지만 일부 사례에서 보면 이미 과제선정 단계부터 염두에 두었던 개선안 위주로 실행계획을 세우다 보니 결국 분석된 핵심원인변수와는 연관성이 부족하거나 완전히 별개의 개선안이 선정되는 경우가 발생하기도 한다. 이런 경우 이전 단계까지의 활동결과와는 무관하게 진행되면서 문제해결을 위한 과정상의 논리성이 떨어지게 되고, 과제 목표에도 미달되는 결과를 가져온다. 따라서 이미 인지된 해결안이라면 이전 단계에서 즉개선(Quick Fix)으로 개선안을 조기에 구체화하여 실행하고, Improve단계에서는 분석된 핵심원인변수별로 효과성 있는 개선안을 선정해야 한다.

▶유형2. 이론적인 해답이 적절한 실질적 해답으로 전환되었는가?
팀 활동을 통해 핵심 인자에 대한 실질적인 개선안을 충분히 검토했다고는 하나 통계적인 개선안의 경우, 결과가 좋을 것이라고 믿었던 개선안이라도 위험성 예측과 시험 적용(Pilot test)을 거치지 않으면 안 된다. 이 경우 개선안을 실행하고 꾸준히 관리한다 하더라도 당초 예상했던 결과값에 크게 못 미치는 결과를 초래하게 되므로 시간에 쫓긴다고 해서 너무 성급하게 결론을 내리거나 과신하지 않는 것이 바람직하다.

▶유형3. 실험계획법을 사용하기 전에 목적을 생각해 보았는가?
실험계획을 하기 전에 목적을 명확히 해야 한다. 실험의 초점이 프로세스에 영향을 덜 미치는 인자를 걸러내기 위한 것인지, 아니면 소수의 핵심인자를 가지고 최적 조건을 도출하기 위한 것인지 확실히 해야 하는 것이다. 만약 실험의 목적을 명확히 하지 않으면, 너무 많은 인자를 가지고 실험을 하여 비효율적이 될 수 있고, 반대로 너무 적은 인자를 가지고 실험하게 됨에 따라 정확한 최적값을 도출하지 못하는 경우가 있다.
우리가 원하는 목표를 달성하기 위해서는 6시그마 문제해결 각각의 단계마다 최선을 다해야 할 것이다. 특히 Improve 단계야말로 그동안 정의·측정·분석한 결과에 대한 개선안을 구체화하는 단계니 만큼 성급한 결론이나 개선 효과에 대한 충분한 검증이 없다면 그동안 쌓아 온 노력이 사상누각이 될 수 있음을 명심하자.
김재배 위원·누리혁신연구소

과제를 수행하면서 흔히 우리는 처음부터 문제의 원인을 알고 있다고 전제하는 경우가 많다. 결국 “그 원인은 다 알고 있으니 그것만 해결하면 된다” 는 식의 접근이 우리의 6시그마 활동에서도 역시 빈번하게 나타나고 있는 것이다. 이러한 ‘이미 알고 있다고 믿고 있는 문제의 원인들’ 로 인해 성공적인 과제수행에 얼마나 큰 장애가 되는지 한번 생각해 보자.

▶유형1. 그거 뻔한 거 아니야?
고질적인 문제를 해결하고자 6시그마 과제를 선정하고 시작한다. 그럼 문제가 발생하는 원인을 정확하게 찾아야만 한다. 그러나 앞에서 언급했듯이 과거의 경험이나 누군가에게 전해들은 이야기들, 몇몇 제한된 자료를 가지고 그것이 마치 문제의 근본 원인인 것으로 오해하고 접근하는 경우가 많다. 6시그마에서는 이러한 선입견을 과감하게 버려야 한다. 그리고 “이렇게 까지 해야만 하나”하는 생각이 들 만큼 추적 가능한 모든 원인들이 문제의 근원일 수 있다는 전제하에 진행해야 한다.

▶유형2. 프로젝트의 목표와 스펙 잊지 말기
유형1의 오류를 범하지 않기 위해 모든 원인들을 찾는 작업을 한다. 그러나 현업의 일이라는 것이 여러 가지 복합적 요소들로 2~3쪽 이상의 LOGIC TREE를 그리는 것으로 문제의 원인들을 다 도출했다고 하기엔 부족한 경우가 많다. 결국 끝이 보이지 않는 원인 도출 과정에 지치게 되고, 결국 이 문제는 해결이 불가능하다며 포기하게 된다. 이 경우는 자신이 수행하고 있는 ‘프로젝트의 목표와 스펙’이 존재한다는 것을 잊는 경우라 할 수 있다. 예를 들어 과제 목표가 “입주 아파트를 대상으로 하는…” 였다면 ‘전국의 아파트’ 가 아닌 내 프로젝트 대상 지역의 ‘입주 아파트’ 라는 특이한 상황을 전제로 해 작업을 해야 한다는 것이다.

▶유형3. 꼭 가설검정을 해야 하나?
결론적으로 말하면 해야 한다. 회사의 중요한 문제를 아주 꼼꼼하게 목표와 스펙에 맞춰 모든 가능한 원인을 도출했다면 적어도 수십 가지의 원인이 도출되어야 맞다. 그럼 이 수십 가지의 원인들이 과연 우리가 예상한 대로 모두 핵심 원인일까? 실제로 과제를 가설검정을 통해 들여다보면 60% 정도의 원인만이 진짜 원인으로 판정되고, 나머지는 그렇지 못한 것으로 나타난다. 만약 가설검정이 없다면 우리는 이 불필요한 40%에 많은 자원을 투입해야 하는 것이다. 대부분 현업과 과제를 병행하는 리더들이 많은 우리에게는 이 가설검정이 쉽고, 효율적으로 일 할 수 있도록 하는 중요한 과정임을 잊으면 안 된다.
많은 사람들이 6시그마의 꽃은 Analyze라고 믿는다. 6시그마를 통해 문제를 해결해야 한다면 보다 효율적으로 가장 큰 효과를 낼 수 있는 핵심 원인을 찾아 공략해야 하는것이다. 그 핵심을 찾아주는 과정이 바로 이 단계이기 때문이다.
박영진 차장·6시그마사무국

섣부른 예단은 ‘프로젝트의 적’
6시그마 프로젝트의 주요 수행 단계인 DMAIC. 이번 주부터는 이 다섯 단계 중 단계별로 잘못 적용돼 오류를 낼 수 있는 사례를 분석해 그 대안을 제시한다. 첫 회 ‘Define’ 단계에 관한 것이며 앞으로 5주간 연재된다.
과제를 수행할 때, 특히 정의 단계에서 형식적으로는 논리적 절차를 따르는 듯 보이지만 실질적으로는 한정된 정보, 과거의 경험 또는 주관적 판단에 따라 결과를 예단하고 거기에 과정을 거꾸로 맞춰나가는 사례를 흔히 볼 수 있다. 다음은 그 사례를 소개한다.

▶유형1 - 고객의 요구도 안 듣고 핵심 고객 요구사항이 나온다?
CTQ(고객의 핵심 요구 특성)는 고객의 요구사항에서 출발한다. 그런데 고객의 요구사항을 파악하기도 전에 ‘○○○발생률 감소’라는 프로젝트 타이틀로 CTQ를 미리 못박는가 하면 그 타이틀에 맞도록 고객 요구사항의 중요도 평가를 거꾸로 끼워 맞춘다.
눈 가리고 아웅하는 격이다. 충분히 고객 요구사항을 파악한 뒤 기존에 잡았던 프로젝트의 방향이 그 요구에 부합하지 않는다면 과감히 진로를 바꿀 일이다.

▶유형2 - 고객의 말에 숨은 뜻을 파악하라!
어느 고객이 “A설비의 A-1 기능을 추가해 달라”는 요구를 했다고 하자. 이때 ‘A설비의 A-1 기능 구축’이 핵심 요구사항이라고 철썩 같이 믿고 프로젝트를 수행한다면 기껏 그 기능을 잘 구현하는 것 외에는 달리 문제에 접근할 수 없을 것이다.
고객이 A-1 기능을 언급한 것은 제품에 그 기능과 관련된 중대한 문제나 희망사항이 있으니 그것을 해결해 달라는 뜻이지, A-1기능을 안 만들어서 불만인 것은 아니다. 또 만약 고객이 마일리지를 요구한다면 이는 장기 ·우수고객에 대한 혜택을 원하는 것이고, 배터리가 커서 불만이라면 휴대성에 문제가 있다고 파악해야 할 것이다. 고객의 말하는 의도를 제대로 파악해야 한다.

▶유형3 - 정의 단계에서 웬 핵심 원인과 개선안이?
프로젝트 차터는 팀원과 챔피언 간의 계약이자 종합계획서다. 그중 ‘문제 기술서’에 “A 때문에 B라는 문제가 생겨 시급해 해결해야 한다”고 핵심 원인을 명시해버린다. 또 ‘목표 기술서’에 “○월 말까지 A를 개발(구축)함으로써 B문제를 해결하겠다”는 용감무쌍한(?) 개선안을 적는 경우가 있다. 현안에 대한 문제도 명확히 정의되지 않았는데 어떻게 핵심 원인과 개선안이 언급될 수 있을까? 이와 같이 다음 단계에서 해야 할 일을 미리 단정적으로 명시하게 되면 구성원 간에 문제 그 자체에 대한 이해와 공감대 형성을 스스로 저해하게 만들 뿐 아니라 사고의 폭을 현저히 제한시킨다.

6시그마에서는 성급히 결론으로 비약하는 것(Jumping to conclu sion)을 경계한다. 과정 하나 하나의 의미와 목적을 정확히 이해하고 충실히 따르는 것이 좋은 과제 수행의 필요조건임을 잊지 말자.
백창현 차장ㆍ6시그마사무국