식스시그마의 철학
식스시그마는 그야말로 인간으로서 극복해야 할 최고의 가치인듯 싶다. 불량률을 Zero로 만들기 위해서 통계적으로 불량율을 만들어내는 원인을 프로세스별로 분석하여 이를 해결하는 하나의 학문적 Term이다.
출발은 일본에서
최초 고안은 모토롤라를 만들었던 Mikel J. Harry에 의해서 1987년 창안되었으니 그 철학이 유명해진 것은 GE의 잭월치에 의해서 유명해졌다. 그런데 두 회사다 지금 망해버린 터라 쓸모가 있는 Term인지 의심스러운 건 자명한 일... 그런데 이 시작이 50~80년대 최전성기를 맞이한 일본에서 SQC, TQM으로 부터 출발하였다. 그리고 이러한 일본의 자동차와 전자제품이 세계시장을 장악하자 미국에서 일본을 배우자 운동에서 시작된 것이 6시그마였다.
나도 사실 식스시그마의 검은띠(Black Belt)의 소유자이다. 그런데 경험디자이너로서 식스시그마는 언제 써야 하는 것인가?
경영관점의 식스시그마
식스시그마는 에러율의 인간한계를 정의한 것이다. 생산한 제품이 품질에러를 만들어, 이로 인해서 A/S등을 통해서 제품에러수정, 신품교환, Republish등을 이용한 일련의 서비스 비용을 발생시키면 제품판매에서 얻어지는 수익을 급감시키는 결과를 초래한다. 특히나 제조업체는 제조된 제품의 수년 혹은 수십년간의 품질의 유지를 보장해주는 Warranty를 차용하여 판매를 촉진시키고 있으니 수년 또는 수십년간의 품질비용을 보장해주는 꼴이 된다.
식스시그마는 이러한 품질비용을 처음에 원천적으로 차단하여 이로 인해서 품질보증의 빚에서 벗어나도록 하자는 품질개선활동이다. 제품은 각기 부품들이 개별적인 조립과정을 거쳐서 완결품을 이루므로 조금은 수월한 면이 있는데 소프트웨어 기반의 제품 혹은 서비스들은 이러한 품질개선이 물리적으로 잡히지 않으므로, 해결이 어려운 측면이 있으며 상호 유기적으로 연결되어 있기 때문에 딱히 누구의 잘못으로 분업화하기가 어렵다는 단점이 있다.
산출물의 에러율을 줄임으로서 문제를 거의 Zero로 수렴하겠다는 목표이다. 정확하게는 백만개의 생산품중에 3.4개의 문제점을 없애겠다는 뜻이다. 소프트웨어의 경우는 원제품의 카피이기에 생산단계에서의 조립이라기 보다는 최초의 제품을 그대로 복제함으로서 얻어지므로 개념상 문제정의가 새롭다.
[출처 : GE, Six Sigma]
http://www.ge.com/sixsigma/sixsigstrategy.html
http://ko.wikipedia.org/wiki/6_%EC%8B%9C%EA%B7%B8%EB%A7%88
식스시그마의 생존법
모든 기능과 프로세스가 복잡하게 얽혀있는 대기업(LG, 삼성)에서도 SCM이나 ERP중심으로 이를 해결하는 경향이 크다. 즉 부품수급과 프로세스단계마다 품질 검증 및 조립에 집중하여 사용하고 있다. 다만, 기업정신자세를 위해서 일부 관련부서에서 오류를 최소화 하기 위한 개념으로 이를 도입하여 수준을 조정하여 활용하고 있다. 특히 1996년 최초로 도입한 LG는 2007년부터 2010년 까지 6시그마의 부흥기가 된다. Again 6시그마... 로서 사장된 툴을 다시 꺼내어 다시 다듬어 이를 낭비제거에 대거 몰입했다. 즉 Defact가 Waste로 둔갑하여 다시 망령이 살아난 것이다.
http://www.edaily.co.kr/news/NewsRead.edy?SCD=JC41&newsid=02873286602841392&DCD=A00304&OutLnkChk=Y
소프트웨어 기반의 식스시그마
IBM이 식스시그마 도입에 실패하였다. 그 이유는 무엇일까? IBM은 제품(or 하드웨어)과 소프트웨어로 이루어진 기업이다. 이러한 소프트웨어 기반의 기업의 경우에는 식스시그마는 맞지 않는다. 즉 인간이 공장에서 찍어낼 수 있는 산물의 경우는 식스시그마가 지식의 높낮이에 상관없이 적용이 가능하지만 물리적이지 않은 제품의 경우는 문제를 정의하기도 문제를 개선하기도 또 정확한 R&R을 정의하기도 어렵기 때문에 개선을 하기가 어려운 것이다.
http://blog.naver.com/PostView.nhn?blogId=de2quyofa&logNo=100067359829
특히나 소프트웨어 중에서도 Version이 명확한 단위 제품이 아닌 변화하는 서비스의 경우에는 문제를 정의하는 동안 제품의 성격이나 소스코드가 변화하기 때문에 이러한 해결점을 찾고 그 효과를 측정하기가 어려워진다. 때문에 식스시그마를 정의하는 시간에 문제를 개선하고 바로 그 효과에 대해서 고객검증을 실시하면 그만이지 이를 프로세스로 태우고 그동안 소스코드 혹은 소프트웨어의 버그를 개선하지 못하게 할수는 없는 노릇이다.
게다가 UX디자이너는 이러한 소프트웨어 코드를 다루는 분야가 아니라, 소프트웨어의 사용성을 개선하고 전체적인 경험을 향상시키는 창의력에 해당하는 것이라, 창의력 자체의 품질정의도 어렵고 안정적인 제품이 아닌 매번 새로운 경험을 창조하는 경우에는 이러한 경험을 관리하는 것이 불가능하다. 관리에 들어가는 순간 오래되어 버려야 하는 경험일 수도 있기 때문에 6시그마는 사라지게 된 것이다.
특히나 이미 세계수준에 올라와 있는 기업의 경우 사업을 거의 독점적으로 유지하여 수년간 같은 제품을 변화없이 간직해야 하는 경우가 아니라면 6시그마를 찾을 일은 없는 것이다. 6시그마 이제는 헤어져야 할 시간인 것 같다.
2014/03/21 초안
2019/08/25 NPI와 식스시그마 분리
나쌤