근본 원인을 알아야
문제를 해결할 수 있다
근본 원인 분석
아이디어를 내기 위해 제일 먼저 해야 하는 것은 문제를 제대로 아는 것이다.
그렇다면 문제는 무엇인가?
문제에 대한 뜻은 여러 사전을 참고해 보면 알 수 있다. 그중 첫 번째 뜻은 ‘해결을 요구하는 것’이다.
또한 원하는 이상적 목표와 현실 사이의 차이를 문제라고 정의할 수 있다.
문제를 해결할 때 우리는 직관적으로 당장 눈앞에 있는 문제를 해결하려고 한다.
하지만 그 문제를 해결해도 또 다른 문제가 계속 발생한다.
따라서 처음부터 근본적인 문제를 찾아서 근본 원인을 제거하는 것이 효과적인 방법이다.
문제 해결은 근본 원인에서 파생된 문제를 해결하는 것이 아니라 근본 원인을 찾아서 해결하는 것이다.
문제 해결을 위해서는 문제 원인을 순서대로 찾아낸 후 근본 원인을 제거하면 된다.
근본 원인을 찾는 법은 다양하다.
기존에 알려진 왜(why)라는 질문을 하다 보면 근본 원인에 도달할 수 있다.
좋은 질문이 좋은 답을 끌어내는 법이다.
질문은 의도하든 아니든 답을 끌어내는 하나의 방법이다.
질문을 할 때는 스토리를 갖고 진행하는 것이 원인을 찾는 데 유리하다.
하지만 원인을 찾는 것 못지않게 중요한 것은 그 원인으로 일어날 결과를 예측하는 것이다.
원인을 찾는 것도 중요하지만 그 원인으로 인해 나타나는 결과가 중요한지를 먼저 생각해야 한다.
원인으로 인해 나타나는 결과가 심각하지 않을 수도 있고 문제가 아닐 수도 있다.
이런 경우에는 굳이 원인을 찾아 해결할 필요가 없다.
때로는 근본적인 원인을 찾다 보면 도저히 해결할 수 없는 경우에 이르게 되거나 이미 생각한 원인이 그럴듯한 논리에 맞춰져 나타나는 예도 있다.
문제를 알게 되면 우리는 먼저 문제를 해결하려고 한다.
이때 사람들은 원인을 찾아서 제거하는 것보다 문제를 해결하는 것에 중점을 둔다.
비슷한 문제를 예전에 한 번 해결해 본 방법으로 새로운 문제가 우연히 해결되면 우린 원인을 찾아서 해결했다고 생각한다.
하지만 이런 경우는 일시적으로 개선된 현상과 타협하는 경우다.
사람들은 일반적으로 자신이 가진 고정관념에 기반해 실제 원인이 아닌 원인을 예측하고 해결 방향을 결정한다.
이렇게 예측한 해결안이 맞을 수도 있고 틀릴 수도 있다.
우리가 가진 경험과 부족한 정보로 고정관념이 형성되면 이러한 고정관념은 하나의 신념으로 바뀌기도 한다. 우리가 학교에서 배운 내용이 참인지 거짓인지 생각해 볼 수 있다.
예를 들어 한글 맞춤법도 좋은 예가 될 것이다.
‘했읍니다’와 ‘했습니다’의 변화를 보면 알 수 있다.
과거에는 ‘했읍니다’가 표준어였지만 이제는 ‘했습니다’로 변경되었다.
여러 상황과 과학기술의 발전으로 우리가 진실이라 믿었던 내용이 사실은 진실이 아니라고 말해준다.
지구는 둥글다는 사실이 진실로 밝혀진 것은 먼 예전이 아니다.
어쩌면 우리는 문제를 바라볼 때 자기만의 시점에서 바라보는 것은 아닐까 생각해 봐야 한다.
문제를 바라볼 때도 여러 관점에서 바라보아야 한다.
내 관점이 항상 옳다는 생각에서 접근하는 것은 이미 스스로 예측한 원인을 찾아가는 논리는 만들 수 있으나 실제 현상과 문제를 찾는 과정에서 내 관점과 더불어 다양한 관점에서 고민해 봐야 한다.
창의적 문제 해결 이론인 트리즈에서 문제를 찾는 방법은 근본 원인 분석(Root Cause Analysis) 또는 원인- 결과 분석(Cause-Effect Chain Analysis)이 있다.
이 방법의 목적은 근본 원인을 정확하게 밝혀내서 문제를 해결하는 것이다.
문제를 구조화하고 하위 문제(Sub-problem)와 관계를 도식화해 문제를 찾을 수 있고, 예측적 모순이 아닌 분석적 모순 분석을 통해 문제를 트리즈 문제 모델로 만드는 것이 목적이다.
근본 원인을 분석하기 전에 먼저 해야 할 일은 목표를 제대로 정하는 것이다.
해결해야 할 목표가 정의되어 있지 않으면 문제는 계속 바뀐다.
근본 원인 분석에 적당한 인원은 최소 3명에서 최대 7명 정도이다.
사람이 적으면 충분한 토의가 일어나지 않고, 사람이 많으면 참여하지 않는 사람이 많아진다.
따라서 실제 참여하는 인원은 7명까지 가능하다.
개인적인 경험으로는 5명에서 6명 정도가 적당하다.
이런 규모가 가장 활발한 분석이 진행되고 좋은 결과를 얻을 수 있기 때문이다.
이때 참여할 사람은 문제를 이해하는 사람이면 더욱 좋다.
기술 문제를 분석한다면 인사, 마케팅 담당자가 참가하는 것보다 연구원과 엔지니어가 참여하는 것이 효과적이다.
진행하기 전에 문제를 구체적으로 설명할 수 있는 전문가가 주관해야 한다.
단지 말로만 설명하는 것이 아니라 실물을 보여 주면서 설명해야 모든 참석자가 공통적인 생각을 할 수 있다. 말로만 설명하면 문제에 대한 충분한 이해 없이 분석이 시작된다.
실물이 없으면 설계도 또는 그림이라도 보여 주면서 분석해야 한다.
문제를 처음에 인지하고 참석자들에게 설명하는 사람은 회의에 참석한 모든 사람이 현재의 문제를 이해할 수 있도록 유도해야 하고, 문제 정의에 대해서는 모든 사람의 동의를 받아야 한다.
이때 문제는 한 문장으로 정리하는 것이 좋다.
이 문제를 시작으로 계속 질문과 대답을 반복하면서 문제 구조도를 만들어 가는 것이다.
우리가 아는 5 Why 방법에서는 “왜 그런 일이 일어났을까?”를 질문한다.
하지만 근본 원인 분석은 “어떤 현상이 그 결과를 만드는가?”라는 방식으로 질문한다.
질문 방식이 ‘왜’가 아니라 ‘어떤 원인으로 결과가 일어났는가'라고 시작해야 한다.
질문에 대한 대답은 구체적이고 명확해야 한다.
예를 들어 기분이 나빠서, 마음에 안 들어서, 신뢰성이 낮아서, 품질이 안 좋아서 등과 같이 명확하지 않게 대답하면 안 된다.
또한 빠른 속도, 높은 온도와 같은 대답도 명확한 대답이 아니다.
‘빠른 속도’의 기준점이 있어야 한다.
시내 도로를 주행하는 자동차의 속도에 대한 명확한 설명은 ‘비행기보다는 느리지만 걷는 것보다는 빠르다’라고 할 수 있다.
일반적으로 시내에서 시속 60km로 진행하는 것이 기준이라고 하면 차량 정체로 시속 20km로 가는 것은 느린 것이다.
‘빠른 속도’라고 원인을 작성하지 말고 시속 60km보다 빠르게 간다’고 명확하게 작성해야 한다.
이런 질문들을 반복하면서 아래와 같이 근본 원인 분석을 완성해 나가는 것이다.
미세먼지를 예로 들어 보자.
미세먼지가 나쁨을 나타낼 때는 단지 미세먼지가 많은 것뿐 아니라 바람의 방향이 중요하다.
미세먼지가 많다는 원인에 ‘중국에 미세먼지 발생이 잦다’와 ‘동풍이 분다’라는 두 가지 원인이 동시에 발생해야 한국의 미세먼지 수준이 나쁨으로 되는 것과 같다.
미세먼지는 실제로 여러 원인이 복합적으로 작용한다.
이런 식으로 계속해서 원인을 찾다 보면 모순이 도출된다.
여기서 말하는 모순은 기술적 모순이다. 기술적 모순은 한쪽을 좋게 하니까 다른 쪽이 나빠지고, 그 다른 쪽을 좋게 하려고 하니까 한쪽이 나빠지는 것을 말한다.
근본 원인 분석을 하기 전에는 서로 연관이 되어 있는지 명확하지 않았지만, 근본 원인 분석을 통해 명확하게 정의되는 것이다.
근본 원인 분석을 진행할 때는 다양한 관점에서 문제를 도출해야 한다.
기술 및 공정 문제는 4 M1 E(Method, Man, Machine, Material, Environment)로 볼 수 있고, 다른 분야에서는 4P(Product, Price, Place, Promotion) 등과 같이 검토할 수 있다.
근본 원인 분석을 계속 진행하다가 고객 문제 또는 어떠한 방법으로도 결과를 낼 수 없는 문제에 다다르면 분석을 멈출 수 있다.
근본 원인 분석이 종료되면 핵심 문제를 찾아야 한다.
보통 하단에 있는 모든 것들을 핵심 문제로 지정할 수 있다.
결과에 영향을 주는 모든 원인을 제거해야 문제는 해결되는 것이다.
가장 큰 원인을 해결한다고 해도 남아있는 원인으로 인해 문제는 재발할 수 있다.
핵심 문제를 지정하고 난 후에 해결하는 순서는 해결하기 쉬운 것부터 시작하자.
바로 적용할 수 있는 것과 적은 변형으로 결과에 영향을 미치는 것도 먼저 해결해야 한다.
핵심 문제는 보통 최하단에 있는 원인을 선택하는 데 중간 단계를 동시에 선택해도 된다.
각각 원인에서 아이디어를 도출할 수 있다.
이전에 근무한 회사에서 트리즈 과제를 근본 원인 분석을 활용하여 진행했다.
당시 신소재 개발 과제를 진행 중이었는데, 제조 장비 설계에 많은 문제가 발생했다.
장비 설계에 대한 근본 원인 분석을 진행했는데 진행 기간이 3주가 넘게 걸렸다.
실제 문제에 적용할 때는 원인 하나하나를 다 검증하면서 그려야 한다.
5명이 매일 8시간씩 회의실에 모여서 하나씩 검증해 나갔고, 논문, 특허, 실험 결과 등을 확인하면서 원인을 찾아갔다.
시작하는 문제를 크게 정의하고 아래쪽으로 전개한 결과, 회의실 한쪽 벽이 모두 근본 원인 분석 트리로 변했다.
핵심 문제의 수준이 분자 단위까지 내려갔다.
근본 원인 분석 결과로 우리는 확보해야 할 기술이 무엇인지, 중장기 계획과 해결해야 하는 핵심 문제를 도출했다.
또한 근본 원인 분석 결과로 특허도 출원할 수 있었다.
앞서 예를 들었던 미세먼지 발생에 대해 근본 원인 분석을 진행하려면 준비할 자료들이 많다.
지난 한 달 동안의 미세먼지 수치가 필요하다.
어떠한 원인으로 미세먼지가 급증했는지 분석해야 한다.
날씨 영향도 물론 있겠지만 국내 상황과 해외 상황을 동시에 볼 수 있어야 한다.
우리는 경험적으로 비가 오면 미세먼지가 감소한다는 것을 알 수 있다.
하지만 근본 원인을 분석할 때는 비가 오면 미세먼지가 감소한다고 작성할 수 없다.
실제로 비가 오면 미세먼지가 감소한다는 근거를 확보해야 근본 원인 분석 그림에 이러한 내용을 추가할 수 있다.
객관적인 사실로 원인을 분석하고 이렇게 찾아내는 데이터를 정리하고 다양한 관점에서 데이터를 분석해야만 한다.
누구나 아는 사실을 추가할 때도 반드시 검증을 거쳐야 한다.
누구나 안다고 검증을 거치지 않으면 잘못된 정보가 추가될 수 있기 때문이다.
사람들이 문제를 분석할 때 가장 많이 하는 실수는 우리가 당연하게 생각하는 것이라고 여겨 근거를 확인하지 않고 분석하게 된다.
여기서 근거를 찾을 때는 주로 실험 결과, 논문, 특허 등을 통해 정보를 얻은 후에 검증된 사실만을 추가한다. 따라서 근본 원인 분석에 걸리는 시간은 생각보다 길게 걸린다.
이런 과정을 거치고 난 후에는 우리가 알고 있다고 믿는 사실들을 다시 검증할 수 있으며 의외의 결과를 얻을 수 있다.
모든 결과는 단순한 원인에 의해 나타나지 않고, 또한 원인은 우리가 생각하는 것과 같이 명확하지 않은 경우도 많다.
간단한 예를 들면 아침에 지각한 문제에 대해 원인을 찾아본다.
“이 사람은 왜 아침에 지각했는가?”라고 질문하지 말고 “무엇이 이 사람을 지각하게 했는가?”라고 질문해 보자.
질문을 시작하기 전에 ‘아침에 지각했다’라는 것이 제대로 된 문제인지 확인해야 한다.
지각이라고 하면 도대체 몇 분을 지각한 것일까?
10분 늦게 도착해도 지각이고 1시간 늦게 도착해도 지각이다.
이 사람이 ‘아침에 30분 늦게 도착했다’라고 문제를 변경해야 한다.
‘30분 늦게 도착했다’에 대한 질문이 ‘무엇이 이 사람을 30분 늦게 만들었는가?’로 바뀐다.
아침에 지각한 이유를 찾는 것과 30분이라는 구체적인 시간 지연에 대한 원인을 찾는 것은 다르다.
아침에 지각한 이유는 대부분 늦게 일어나거나 차가 막혔기 때문이라고 대답할 수 있다.
늦게 일어난 것은 사실이지만 아직 구체적이지 않다.
정확하게 30분 늦게 일어났다고 하면, 일어난 이후에 모든 일은 지각하지 않은 날과 같은 시간이 걸렸음을 예측할 수 있지만 실제로는 모두 확인해 봐야 한다.
차가 막혔기 때문이라는 원인은 구체적이지 않다.
차가 막혔기 때문이 아니라 이동 시간이 평소 50분 걸렸는데 오늘은 55분 걸렸다고 구체적으로 작성해야 한다.
30분 늦은 원인 중에 5분은 이동 시간에서 찾을 수 있다.
다음 단계로는 이동 시간이 55분 걸렸다는 문제에 대해 원인을 찾아야 한다.
무엇이 50분 걸리던 것을 55분 걸리게 했는가?
이 부분의 원인을 찾기 위한 가장 좋은 방법은 실제 거리에서 원인을 찾는 것이다.
하지만 실제 거리로 향해도 이미 과거가 되어버렸다.
아무리 유사한 시간에 같은 거리를 가더라도 원인은 유사할 뿐이지 똑같지 않다.
당일 사고가 났는지, 고장 차량이 서 있었는지 등을 검토해 볼 수 있다.
차량이 정체되는 원인을 찾으려면 많은 조사가 필요하다.
하지만 차량 정체 원인을 조사한 후 근본 원인을 찾아내도 우리가 개선할 방법은 존재하지 않을 수 있다.
아무리 사고가 일어나지 않도록 해도 실제로 사고는 일어난다.
따라서 이 부분은 더는 원인 분석을 진행하지 않아도 된다.
근본 원인 분석은 실제로 해 보는 것이 가장 빠르게 이해할 수 있다.
근본 원인 분석을 진행하면서 고민하고 원인을 찾아가는 과정에서 미처 생각하지 못했던 새로운 원인을 찾아낼 수 있다.
근본 원인 분석을 제대로 진행하려면 상당히 많은 단계를 거쳐야 한다.
근본 원인 분석이 끝났다고 생각하면 근본 원인부터 결과를 향해 반대 방향으로 검증해봐야 한다.
“사고 차량이 있으므로 이동 시간이 55분 걸렸다.”
이렇게 검증하면 무엇인가 생략된 것이 있음을 눈치챌 수 있다.
다시 생략됐다고 생각한 원인을 추가해 보자.
“사고 차량이 있어 도로에 차량 흐름이 느리므로 이동 시간이 55분 걸렸다.”
이제 논리가 제대로 되어 가고 있다고 생각된다.
이동 시간이 55분 걸린 원인 중 하나는 사고 차량이 있었다는 것이다.
다른 원인을 찾아야 한다.
많은 사람이 근본 원인 분석을 진행하기 어렵다고 한다.
제대로 진행하려면 관련 지식도 있어야 하지만 더욱 중요한 것은 충분한 시간이다.
트리즈를 적용하면 바로 아이디어가 나온다고 생각하며 기다리지 않는 것이 가장 큰 문제다.
문제를 해결할 기간이 100이면 그중 10은 목표 설정에 사용하고, 50은 문제 분석에 사용하고, 20은 아이디어를 도출하고, 나머지 20은 아이디어를 분석 및 적용하는 것으로 시간 분배를 해야 한다.
아이디어는 빨리, 많이 내는 것이 중요한 게 아니라 문제를 해결할 수 있는 아이디어가 중요하다.
제대로 된 아이디어는 근본 원인을 먼저 찾고 난 후에 근본 원인을 제거할 수 있어야 한다.
