Define단계를 해보자 - SixSigma Chapter9

하핫..드디어 저만의 로고 파일이 생겼습니다. EOS.CAFE Korea DAC의 벧엘님이 기부해주셨습니다. 감사합니다.

Previously

전 시간에는
[비율을 비교해 보자 - SixSigma Chapter8]
에서 하나의 측정된 데이터에 대해서 비율을 비교해 보는 방법을 알아보았습니다.

이번 시간에는 로고가 생긴 기념으로, Six sigma의 제일 첫 단계인 define에 대해서 알아보려고 합니다.

무엇을 해야 하는가?

https://steemit.com/busy/@jeaimetu/dmaic-sixsigma-chapter7 에서 본 것처럼, define은 문제를 정의하는 단계입니다. 사실 정의는 굉장히 여러가지의 광의입니다. define만 주어지면 무엇을 할지 난감하죠. 문제가 무엇인지 글로 쓰기만 해도 정의일수 있으니까요..

그래서 구체적으로 무엇을 해야 하는지에 대해서, 혹은 define단계에선 적어도 이런 것들을 해야 define이다 라는 것을 이야기 하려고 합니다.

Big Y 전개

Six sigma에서 잘 쓰이는 몇몇 용어중에 하나 입니다. define에서 갑자기 무슨 이야기냐구요?

Six sigma의 큰 모토중에 하나는 "smarter than harder"입니다. 즉 열심히 하기보단 잘하자가 모토죠.
그래서 Six sigma는 자원을 매우 효율적으로 쓰는 것을 중요하게 생각합니다.

그런 의미에서 주로 six sigma는 Big Y에 기반한 과제를 진행하게 됩니다.

Big Y는 그 단체 혹은 회사의 큰 목표를 의미합니다. 예를 들면 재료비, 매출등이 되겠죠. 그럼 Big Y전개는 그 매출에 기여하는 것들을 MECE등에 대해서 나열하는 것을 의미합니다. 여기서 MECE는 다 합치면 전체집합이고, 각각은 교집합이 공집합인 것을 의미합니다.

예를 들어 우리 집 음식비용을 절감하는 것이 Big Y라면 여기에 기여하는 것은, 음식의 식재료 비, 음식을 만드는 인거비, 음식을 하는 데 사용되는 조리기구의 비용, 음식을 하는데 사용되는 전기, 가스비 등이 포함됩니다. 여기에서 나열한 각각을 little y라고 이야기를 하고, 이 little y들은 서로 MECE를 만족합니다. 그런데, 만약 음식을 만드는 인건비가 아니라 "비용"이라고 용어를 바꾸면, 전기, 가스비가 여기에 포함되어 MECE를 만족하지 못하게 됩니다.

즉 Big Y전개는 어떤 목표를 달성하기 위해서 devide 하는 과정이라고 볼 수 있습니다.

문제의 설명

지금 당면한 문제 대한 설명을 해야 합니다. Six sigma는 나중에 여러 곳에 쓰이는 것을 전제로 합니다. 따라서 가능한 자세히 설명이 되어야 하고 그런 의미에서 문제가 발생한 domain에 대한 설명이 들어가야 합니다. 즉 음식비용이 왜 우리집에서 문제가 되었는지, 음식 비용이 어떤 의미인지...누구나 보아도 이해가 가게 설명을 해야 합니다.

목표의 설정

조금 이상하겠지만, 처음에 목표를 잘 잡아야 합니다. 그런데 문제를 정의하면서 어떻게 분석도 없이 목표를 설정하냐구요? 이건 주로 현재의 상황과 gut-feeling에 기반합니다. 그리고 이렇게 설정한 목표는 나중에 지속적으로 수정되어야 합니다. 다만, 그 수정에는 꼭 이유가 있어야 겠죠.

사실 분석을 하지 않고도 세울수 있는 목표는 많이 있습니다. 지각하는 학생의 수를 줄이는 것이 문제의 핵심이라고 하면 지각하는 학생의 수가 현재 30명인데, 이를 0명으로 줄이겠다고 할수 있는 것이죠. 다만 현재 30명인 것은 정확한 측정을 바탕으로 되어야 하니 결국 약간의 분석은 들어가야 합니다.

또한 목표는 정량적, 정성적 목표 2가지가 필요합니다.

정량적 목표는 숫자에 기반한 것이고, 정성적 목표는 이를 통해서 얻어지지만 숫자로 측정하기 어려운 것입니다. 예를 들어 지각하는 학생의 수를 0명으로 하는 것은 정량적 목표이고, 이를 통해서 학생의 건강증진 혹은 학생의 학습태도 변화등은 부가적으로 얻어지는 정성적 목표 입니다.

그리고 많이 쓰이는 목표의 수치 기준으로 30%의 룰이 있습니다.

5%는 안되도 30%는 된다는 말이 있습니다.

듣기에 어불성설인것 같고, 매우 이상한 말이지만, 그 의미를 새겨 보면 생각보다 깊게 다가 옵니다.

즉 5%를 개선하기 위해서는 기존의 것을 조금 바꾸자고 접근하게 되지만, 30%를 바꾸기 위해서는 기존의 것을 아예 새로운 것으로 바꾸자는 방향으로 더 잘 접근할수 있게 된다는 의미입니다.

팀의 구성과 일정

Define에서 빠지지 말아야 하는 것은 팀의 구성과 일정입니다.
팀의 구성은 이 프로젝트를 하기 위해서 누가 필요한지, 그리고 그 사람들의 역할은 무엇인지에 대해서 생각해 보는 것입니다.

또한 일정은 DMAIC의 단계를 어떤 일정으로 할지, 그리고 각 단계의 완료 조건은 무엇으로 할지를 생각해 보는 것입니다.

즉 software의 개발도 마찬가지 이지만, 모든 프로젝트에서 계획을 세우는 매우 중요한 단계입니다. 물론 이 계획도 실제 진행을 하면서 바뀔수 있습니다.

이렇게 하면...즉 이렇게 위의 모든 내용들에 대해서 생각을 해보고, 기술을 하게 되면 Define단계가 끝나게 되는 것입니다.

다만 중요한 것은 끝났다고 완전히 잊어 버리는 것이 아니고, 중간 중간 DMAIC의 단계들에서 다시 define단계를 돌아보고 업데이트 할 필요가 있습니다.

지속적인 업데이트

아까 본문에서 일정이나 목표등을 바꿀수 있다고 했습니다. 이 의미는 나중에 진행하면서 잘안되면 목표를 "조작"하자는 것이 아니라 의미있게 변경하자는 것입니다. 왜냐하면 처음에 가지는 데이터보다 진행하면서 생기는 데이터가 더 정확할테니까요..

다만, 그 목표의 수정에 있어서는 꼭 의미를 부여해야 합니다.

기술적으로 달성이 불가능하다던가
주어진 기간으로 달성이 불가능하다던가..
주어진 인원으로 달성이 불가능하다던가..

적절한 납득가능한 사유가 있어야 합니다.

혹은 초기에 목표는 수정하지 말고, DMAIC가 끝나고 나서 lessons learned로 왜 달성하지 못했는지를 회고해 보는 것도 좋은 방법입니다.

중요한 것은 모든 수치의 변경은 그 의미가 있고, 설사 달성하지 못하더라고 그 의미를 찾는 것에 중점을 두어야 한다는 것입니다.

마치며..

오늘은 define단계에 대해서 알아보았습니다.

당연히 잘 와닿지 않으실수 있습니다. 그래서..다음 시간에는 제가 품질경영학회에 아주 오래전에 기고했던 실제 사례와 함께 찾아오도록 하겠습니다.

감사합니다.