[경영서적] 맥킨지 방식(The Mckinsey way), MECE, 이슈 트리(issue tree)

Divide and Conquer

2003-2-19

 

세계적인 컨설팅 회사 중 하나인 맥킨지 컨설팅의 일하는 방식을 설명한 책, "The McKinsey Way"의 첫 번째 파트인 비즈니스 문제점에 관한 매킨지식 사고방식(The McKinsey way of thinking about business problems) 내용을 먼저 살펴 보겠습니다.

 

 

 

이 글에서 살펴볼 "The McKinsey Way"의 파트 1은 크게 세 개의 작은 챕터로 나눠져 있습니다. 파트 1을 이루는 각 챕터의 제목은 다음과 같습니다.

 

 (1) Building the solution

 (2) Developing an approach

 (3) 80/20 and other rules to live by

 

맥킨지는 "3"을 매직 넘버로 생각해서, 가급적 세 가지로 요약하는 것을 추구한다고 합니다. "3"이라는 제한 속에서 정리해 나가면 아무래도 핵심만 요약될 것 같습니다.

해결책 구축(Building the solution)

해결책 구축은 크게 세 가지를 지키며 진행한다고 하는데,

 

(1) Fact-based

(2) Rigidly structured

(3) Hypothesis-driven

 

입니다. 해결책 구축의 첫 단계는 정확한 현실 인식입니다. 책에는 이렇게 써 놓았습니다.

 

"Don't fear the facts."

 

사실은 외면한다고 덮어지지 않습니다. 그렇지만 사실을 있는 그대로 받아 들이는 것은 두렵습니다. 컨설팅 회사라는 제3 자를 회사 내부에까지 끌어 들이는 가장 큰 이유가 객관적 사실을 있는 그대로 보기가 힘들기 때문일 것입니다. 전임 맥킨지 매니져는 이렇게 말했다고 합니다.

 

When you strip away a lot of the high-minded language with which McKinsey dresses up its problem-solving process, it comes down to very careful, high-quality analysis of the components of the problem combined with an aggressive attitude toward fact gathering.

 

맥킨지의 문제 해결 과정이란 것은, 벗겨 놓고 보면 사실을 공격적으로 모으고 문제점의 구성 요소를 매우 신중하고 수준 높은 방식으로 분석하는 것에 다름 아니라는 얘기입니다. 여기서 중요한 부분은 공격적으로 사실을 모은다는 부분인 듯합니다. 말은 쉽지만, 어려운 문제에 봉착한 상태에서는 사실 굉장히 어려운 일입니다.

 

Hiding from the facts is a prescription for failure - eventually, truth will out. You must not fear the facts. Hunt for them, use them, but don't fear them.

 

사냥꾼이 사냥감을 쫓 듯 팩트를 찾아 내야 합니다. 팩트를 두려워 할 필요가 없습니다. 모든 문제점은 해결책이 있기 때문입니다.

 

다음으로 해결책 구축에서 중요한 것은 엄격한 구조(rigidly structured) 속에서 사고하는 것입니다. 맥킨지는 "MECE"라는 용어로 구조적 사고방식을 설명합니다. MECE는 "Mutually Exclusive, Collectively Exhaustive"의 약자입니다.
MECE("미씨"라고 발음합니다.)를 지키면 최대의 명확성과 최고의 완결성을 갖고 사고할 수 있을 것 같습니다.

"Mutually Exclusive"는 서로 중복되지 않는, 상호 배타적인 것을 찾아 낸다는 의미입니다. "Collectively Exhaustive"는 찾아낸 것들을 다 합치면 문제점 전체가 커버가 되어야 한다는 의미입니다. MECE의 원칙을 지키면서 가급적이면 항목 수가 세 개를 넘지 않으면 더욱 좋을 것 같습니다. 각기 분명하게 분리되어 있으면서 모든 이슈를 포괄할 수 있는 세 가지 핵심 항목을 찾아내는 것이 "MECE"입니다.

 

MECE라는 구조를 이용해서 파악한 내용과 일차적 팩트의 조합으로부터 초기가설(Initial Hypothesis)을 세웁니다. 초기가설은 문제점을 구조적으로 분할하는 것에서 시작합니다. MECE의 형태로 문제를 구조적으로 분석해 들어가면서 어떤 것이 핵심요인(key driver)인지를 파악하는 것입니다. 이렇게 파악된 핵심 요인 각각에 대해 실행 가능한(actionable) 행동 지침을 만들어 냅니다.  지금 할 수 있는 일은 무엇인가를 꾸준히 묻는 것입니다. 완벽한 해결책이 아닌 현 상태에서 할 수 있는 최선의 실행 가능한 해결책을 제시하는 것입니다.

 

예를 들어 "우리 회사 A 제품 판매가 부족합니다. 어떻게 매출을 늘릴 수 있을까요?" 라고 의뢰했다면 다음과 같이 MECE 프레임웍을 이용해서 초기가설을 세운 다음 각각의 이슈에 대해 계속 MECE 방식으로 사고하며 가지를 쳐 나갑니다. 그 결과는 이슈 트리(issue tree)라 불리는 다음과 같은 도표입니다.

막연히 바라보면 매우 복잡해 보이는 문제도 이와 같이 어떤 구조(structure)를 적용해서 분석해 들어가면 해결 가능한 작은 덩어리로 나눠지면서 문제점 전체를 정확하게 파악할 수 있고 해결책도 쉽게 떠오를 수 있습니다. 최상책(best)보다는 개선책(better)을 찾는 태도가 중요하구요. 이렇게 구축된 해결책 시안을 바탕으로 접근법을 생각합니다.

접근법 도출 (Developing an approach)

해결책 시안은 실제 현장에 그대로 적용할 수 있는 것이 아닙니다. 문제점의 특징 또는 회사의 특징에 따라 그 외 환경 요인에 따라 변화를 줘야 합니다. 이렇게 접근법을 만들어 가는 데 도움이 되는 힌트가 몇 가지 있습니다.

문제점이 항상 문제점인 것은 아니다

컨설턴트는 비즈니스 문제에 대한 의사입니다. 어떤 의사도 환자가 호소하는 증상이 곧 근본 원인이라고 생각하지 않습니다. 머리가 아프다는 환자의 호소에 두통 약을 바로 처방하는 의사는 없습니다. 환자의 주소(chief complaints)는 환자의 진정한 문제점으로 접근해 들어가는 단서입니다. 환자의 이야기를 경청은 하되, 증상의 진정한 원인을 생각해야 합니다. 컨설턴트도 그렇습니다. "매출이 줄어서 걱정입니다."는  기업의 증상을 표현한 것입니다. 매출이 줄어든 것이 가장 큰 문제일 수도 있지만 사실은 주력 시장에 대해 부정적인 생각을 하고 있는 것일 수도 있습니다. 컨설팅을 의뢰한 사람 자신이 느끼고 있을 수도 있고 느끼지 못한 채 매출을 증상으로 문제점이 있다는 것을 호소하는 것일 수 있습니다. 컨설턴트는 경청은 하되 그것이 진짜 문제인가에 대해 재평가를 하며 일을 진행해 가야 합니다. 항상 문제점 자체에 문제의식을 갖고 있어야 합니다.

"Forces at work"

문제점의 핵심요인(key drivers)을 파악하는 데 자주 활용되는 것이 "Forces at work" 분석입니다. 현재 큰 영향을 미치는 힘이 어떤 것이 있고 이들이 긍정적으로 작용하는지, 부정적으로 작용하는 지를 분석하는 것입니다. 공급자, 고객, 경쟁자, 잠재적 대체재에 대해 이들이 어떻게 회사에 영향을 줄 수 있는 지 분석합니다. 

팩트를 솔루션에 끼워 맞추려 하지 말라

초기가설이 최종 해결책이 되기를 바라는 유혹을 피해야 합니다. 문제해결은 초기가설이 옳았음을 증명하는 것이 아닙니다. 초기가설이 아무리 훌륭하게 생각되고 완벽해 보이더라도 완전히 틀릴 수 있다는 사실을 염두에 두고 유연하게 사고해야 합니다. 초기가설에 집착해서 수집된 팩트마저 끼워 맞추려 해서는 안됩니다. 유혹을 이겨내는 좋은 방법 중 하나는 일이 진행되어 가는 중간에, 지난 일 주일 동안 무엇을 알아냈는지 그리고 그것이 초기가설에 얼마나 적합한지를 정기적으로 리뷰하는 것입니다. 만약 초기가설로 설명되지 않는 현상이 발견되면 가설 자체를 의심해 볼 수 있어야 하며 이런 리뷰를 정기적으로 해야 합니다.

솔루션이 의뢰한 회사에 잘 맞는지를 확인해라

아무리 명약이라고 하더라도 그것이 환자와 맞지 않으면 소용없습니다. 위장이 나쁜 관절염 환자에게 위를 크게 손상시키는 관절염 특효약을 처방하는 것은 환자 전체로 봐서는 바람직하지 않습니다. 약을 꾸준히 복용할 수도 없을 뿐만 아니라 건강을 도리어 해치니까요.

 

솔루션도 마찬가지입니다. 솔루션이 아무리 완벽하더라도 그 기업에 적합하지 않으면 아무 소용이 없습니다. 대대적인 IT 투자로 프로세스 개선을 하는 것이 가장 좋은 해결책이라고 해서 투자 여력이 부족한 회사에게 이 안을 권고하는 것은 그것이 유일한 해결책인 것처럼 생각되어도 틀렸습니다. 학문적 이상과 현실이 부딪히면 항상 현실이 이깁니다. 그리고 비즈니스는 살아있는 사람이 활동하는 공간이고 현실적 강점과 현실적 약점, 현실적 한계가 가득 차 있습니다. 컨설턴트는 반드시 한계를 알고 솔루션을 찾아야 합니다.

도저히 해결이 안 되는 문제가 생겨도, 어쨌든 해결한다

초기가설을 세울 수 없을 정도로 혼돈스러운 상황일 때, 굳이 억지로 초기가설을 세우는 데 집착할 필요는 없습니다. 일단 일을 하면서 팩트를 열심히 모으고 팩트를 보며 생각하다 보면 해결책이 떠오를 수 있습니다. 일을 진행해 가는 과정에서 해결이 안 될 것 같은 거대한 장벽에 부딪히면 굳이 계속 머리를 부딪히며 상처 입을 필요가 없습니다. 특히 컨설팅에 있어서 가장 큰 장애물은 기업 내부의 정치입니다. 팩트를 모으는 단계에서부터 사내 정치의 벽에 부딪혀 일이 전혀 진행되지 않을 수 있습니다. 구조 조정 계획을 세우기 위해 불러 들인 낯선 이방인에게 회사의 상황을 우호적으로 말해줄 것을 기대하는 것은 무리입니다. 컨설턴트에 협조적이지 않는 것은 당연합니다. 

 

그럴 때는,

 

(1) 문제를 재정의합니다. 회사의 문제가 사실은 x가 아니라 y라고 이야기를 해줍니다. 특히 y를 해결하면 회사에 다른 측면에서 큰 도움이 된다면 더욱 좋습니다. 해결이 안 되는 x에 매달리다가 엉망이 되는 것보다는 y를 해결해서 모두에게 도움이 되는 편이 좋습니다.

 

 (2) 서서히 섬세하게 조정해 나갑니다. 이상적인 조직 개편 솔루션이 조직내 정치 때문에 임플리멘테이션하기 힘들면 즉시 솔루션대로 구축하려 하지 말고 서서히 진행해 나갑니다. 조직이 재편되어 감에 따라 점차 원안에 가깝게 바꾸어 나갈 수 있습니다.

 

 (3) 정치를 역이용합니다. 사람은 인센티브에 반응하게 되어 있습니다. 정치적 반대에 부딪혀서 일이 진행되지 않는 것은 회사 구성원의 개인적 이해에 심대하게 영향을 미치기 때문입니다. 그것이 극복되기 힘들 정도로 큰 것이라면 다른 인센티브를 제시하는 것을 생각해 봅니다. 정치는 가능성의 예술입니다. 다른 방향으로 인센티브를 제시하며 타협적이라도 해결책을 내놓는 것이 이상적인 것만 고집하다가 아무 결과를 못 만들어 내는 것보다 훨씬 낫습니다.

 

위와 같은 방식으로 구축된 해결책은 항상 actionable하고 provable해야 합니다. 실천 가능한 솔루션을 제시해야지 이상적인 것을 강요하는 것은 의미가 없습니다. 매출 부진이 문제점이었다면 제시된 해결책대로 즉시 해볼 부분이 있어야 하며, 시행한 경우 매출 증대가 있어야 합니다.

문제 해결시 유용하게 활용할 수 있는 몇 가지 법칙들

80/20 원칙

80/20 원칙은 결과의 대부분을 좌우하는 것은 소수의 핵심적인 부분이라는 의미입니다. 80/20 원칙은 실증적 데이타를 바탕으로 도출되고 검증된 법칙이기 때문에 현장에서 큰 효과가 있습니다. 매출이 줄었다는 문제점에 봉착했다면 매출의 주된 부분이 어디로부터 비롯되는 지 데이타 분석을 합니다. 고객이 줄었다면 고객의 대다수가 일부 지역에서 오는 것은 아닌지 점검합니다. 이런 식으로 결과에 큰 영향을 미치는 핵심을 파악해서 그 핵심을 공략할 특화된 방법을 찾는 것이 80/20 원칙입니다.

 

바다 물을 끓이려 들지 말라

모든 것을 다 분석하려 해서는 안됩니다. 항상 선택하고, 일에 우선순위를 매겨야 합니다.

 

Work smarter, not harder.
There's a lot of data out there relating to your problem, and a lot of analyses you could do. Ignore most of them.

핵심요인(Key drivers)을 찾아라

문제점이 두 배로 복잡해지면 해결 시간은 네 배 늘어 납니다. Gerald M. Weinberg의 "An introduction to general systems thinking"이란 책에 나오는 얘기입니다. 문제점에 영향을 미치는 여러 요소를 가급적 단순화해서 가장 중요한 것에 집중해야 합니다. 핵심요인을 찾겠다는 것은 우선순위를 생각한다는 의미입니다. MECE로 파악한 이슈 중 최우선이 무엇인지 파악해야 합니다.

엘리베이터 테스트

솔루션은 클라이언트나 투자자에게 30 초 내에 완벽하게 설명할 수 있어야 합니다. 엘리베이터를 타고 올라 가는 동안 다 설명할 수 있을 정도로 요약해야 합니다. 헐리웃에도 비슷한 테스트가 있습니다. 제작자에게 1 분 내에 시나리오를 설명해서 확 끌리는 뭔가가 있어야 흥행한다고 합니다. "1 page proposal"도 마찬가지입니다. 제한을 엄격하게 가하며 내용을 압축하고 또 압축하면 가장 핵심만 남게 됩니다.

딸 수 있는 열매부터 따라

마지막 순간에 멋진 무엇인가를 보여 줄 생각으로 눈 앞에 보이는 쉬운 성취를 외면하는 것은 어리석은 행동입니다. 일단 쉽게 할 수 있는 것부터 하나씩 하다 보면 어느 새 일이 쉬워지고 사기가 올라가며 흥미도 배가됩니다. 시험 공부나 졸업 논문, 기타 많은 일이 마지막에 뭔가 커다란 것을 보여 주겠다며 미루다가 아예 아무 것도 안되는 경우가 많습니다. 쉽게 할 수 있는 것부터 해야 합니다. 즉시 보여 줄 수 있는 성과는 이뤄가면서 진행해야 클라이언트의 신뢰를 얻습니다.

정리

이상의 내용을 정리해 보면,

 

 (1) 복잡해 보이는 문제들도 일단 MECE와 Forces at Work의 구조를 적용해서 구체적으로 분할하고,

 (2) 분할한 내용을 바탕으로 80/20법칙을 비롯한 몇 가지 방법을 활용해서 해결책을 찾은 다음,

 (3) 이상적이지는 않더라도 즉시 개선시킬 수 있는 행동 지침을 끌어낸다.

 

여러 용어가 나왔는데 용어 자체는 큰 의미가 없습니다. 중요한 건 문제점을 마구잡이로 접근하지 않고 항상 structure를 갖고 풀어 간다는 점입니다. 전임 맥킨지 직원은 이런 말을 했습니다.

 

Structure, structure, structure.
MECE, MECE, MECE.

 

 

 

---

다음으로 "The Mckinsey Mind"라는 책의 문제점 분석에 관한 내용을 정리해 봅니다. "The Mckinsey Mind"는 전작 "The Mckinsey Way"에서 간단하게 소개했던 맥킨지 방식을 기술적으로 더 자세히 설명한 책입니다.

 

맥킨지의 사고방식은 한 마디로 'structure에 대한 강조'라고 할 수 있을 것 같고, 이처럼 구조적으로 문제점을 분석하고 해결하는 것은 비단 비즈니스 현장뿐만 아니라 개인적인 문제나 사회적 이슈를 판단하는 데에도 큰 도움이 될 것 같습니다.

문제 분석의 4단계

문제 분석은 크게 네 단계로 이뤄집니다.

 

 (1) Framing : 문제의 범위가 어디까지인지 파악하고 문제를 쉽게 다룰 수 있는 작은 단위로 나누는 단계

 

 (2) Designing : 초기가설이 옳은지 아닌지를 증명하기 위해서는 어떤 분석이 필요한지를 규정하는 단계

 

 (3) Gathering : 필요한 데이타와 팩트를 모으는 단계

 

 (4) Interpreting : 데이타를 바탕으로 초기가설의 유효성을 판단하고 결과를 해석해서 앞으로 어떤 액션을 취해야 할 지 결정하는 단계

 

당연해 보이는 흐름 같습니다만, 우리가 실제 문제점에 봉착했을 때 어떤 식으로 대응하는지를 대비해 보면 생각해 볼 포인트가 있습니다

 

문제에 맞닥뜨렸을 때 우리는 보통 'Framing'을, 특히나 엄격한 구조를 바탕으로 치밀하게 할까요? 보통은 Gathering에 달려 들기 쉽습니다. 매출이 떨어진다는 문제가 생기면 일단 뭐가 문제인지 부문별 실적부터 점검하려고 드는 것입니다. 일차적으로 해야 할 일은 매출 감소라는 문제의 범위를 명확히 하고 이를 쉽게 다룰 수 있는 작은 단위로 구조적으로 나누는 것입니다. 그리고 그 구조를 바탕으로 초기가설을 세우고 이를 확인할 팩트를 모으는 것입니다. 팩트에서 출발하는 게 아니라 가설에서 출발합니다. 귀납적으로 접근하는 게 아니라 연역적으로 접근하는 것입니다. 문제해결에 있어서 왜 그게 더 효과적인지는 앞으로 나올 내용을 바탕으로 더 생각해 봅시다.

Framing

프레이밍은 위에서 얘기한 것처럼 문제의 범위를 결정하고 초기가설을 세우는 단계입니다.  프레이밍이 끝나면 fact-based hypothesis가 만들어져야 합니다.

 

모든 문제는 엄격한 구조를 바탕으로 해결 가능한 작은 단위로 나누어서 분석해야 합니다. 많은 책과 자료로 심하게 어지럽혀진 책장을 생각해 봅시다. 이것을 무작정 이리 저리 밀치면서 정리하는 것은 매우 어렵습니다. 제일 먼저 해야 할 일은 책과 문서 자료를 따로 분리하는 것입니다. 그 다음 내용을 기준으로 책을 몇 개의 큰 덩어리로 구분하고 자료도 같은 식으로 구분합니다. 내용을 파악할 수 있을 정도의 작은 덩어리로 분류가 되면 어렵지 않게 정리할 수 있게 될 것입니다.

 

프레이밍은 그와 같은 혼돈에 질서를 부여하는 단계입니다. 프레이밍 단계를 통해 막연한 문제점을 구체적인 이슈로 정립합니다. 프레이밍을 할 때 자주 활용되는 툴이 로직 트리(logic tree)입니다. 로직 트리는 가장 큰 문제점부터 논리적 순서에 따라 작은 단위로 나누어서 분류하는 것입니다. 예를 하나 들어 봅시다.

 

로직 트리(logic tree)

위와 같이 이익 감소라는 혼돈 상태에 있는 문제를 엄격한 프레임웍을 바탕으로 다루기 쉬운 단위로 나누는 것이 로직 트리입니다. 로직 트리를 통해 문제점에 대한 포괄적인 시각을 얻을 수 있으면서 동시에 어디를 해결하는 것이 문제 해결에 가장 중요한지 명확해집니다. 이렇게 문제의 프레임웍이 완성되면 이를 바탕으로 초기가설을 세웁니다.

초기가설(Initial Hypothesis)

로직 트리를 통해 문제의 범위와 얼개를 파악하고 난 상태에서 일단 해결책을 생각해 보는 게 초기가설입니다. 초기가설은 아직 충분한 팩트가 조사되지 않은 단계에서 세우는 것입니다. 왜 팩트를 충분히 조사하지 않은 상태에서 초기가설을 세우는 것일까요? 조사해야 할 팩트와 수행할 수 있는 분석은 사실상 엄청나게 많습니다. 비즈니스 문제는 특히나 정답이 없는 대단히 복잡한 변수와 요소로 가득 차 있기 때문에 팩트를 조사한 뒤에 이를 바탕으로 해결책 시안을 만들려는 접근은 시간과 노력만 낭비하는 결과로 이어질 수 있습니다. 제한된 팩트와 약간의 직관, 그리고 브레인스토밍을 통해서 일단 초기가설을 세우고 그 가설이 맞는지 아닌지를 확인할 수 있는 팩트를 찾아 나서는 순서로 진행하는 것이 훨씬 효과적이고 효율적입니다.

 

초기가설을 먼저 세우고 팩트를 분석하는 게 효율적인 또 하나의 이유는, 결론을 미리 알고 과정을 찾아 가는 게 반대의 경우보다 쉽고 빠르기 때문입니다. 미로 찾기를 할 때 시작 점에서 출발하는 것보다 출구에서 시작해서 반대로 거슬러 올라 가는 게 더 빠른 것과 마찬가지입니다. 분석해야 할 팩트는 너무나 많기 때문에, 초기가설이 옳은지 아닌지를 증명한다는 목적 하에 팩트를 조사하면 우선순위가 명확해지고 불필요한 곳에서 시간낭비를 하지 않을 수 있습니다.

 

예컨데, 위와 같은 로직트리를 보면서 "지역 A의 제품 b 유통판 매망을 강화하는 게 이익을 늘리는 데 가장 효과적일 것이다."와 같은 초기가설을 세울 수 있습니다. 초기가설이 꼭 최종안과 같을 필요는 없습니다. 중요한 것은 팩트를 조사하기 전에 상당히 설득력 있는 가설을 세워야 한다는 것입니다.

 

초기가설이 좋은 가설인지 아닌지를 테스트하는 좋은 방법으로 QDT(Quick and Dirty Test)가 있습니다. QDT는, "그 가설이 사실이려면 어떤 전제가 되어 있어야 하느냐."를 묻는 것입니다. 전제에 문제가 있거나 가능성이 낮다면 그 가설은 좋은 가설이 아닙니다. 또는, 반대로, "이 가설이 틀린 것이 되게 할 요인은 무엇이 있을까?"를 물을 수도 있습니다.

 

위의 예에서는,

 

"제품 b가 지역 A에서 잘 팔릴 수 있다는 근거는 무엇인가?",

"제품 b가 지역 A에서 잘 팔리지 않는 것이 접근성이 낮아서라는 근거는 무엇일까?",

"제품 c가 지역 A에 더 적합하지 않을까?"

 

등을 물어 보는 것입니다. 

이슈 트리(Issue Tree)

초기가설이 세워지면 이슈 트리를 만듭니다. 프레이밍 단계는 이슈 트리를 완성함으로써 마무리됩니다. 이슈 트리는 로직 트리와 비슷한 형태인데, '이슈', 즉, 초기가설이 옳은 지 아닌 지를 판별하는 기준이 되는 이슈를 MECE 원칙에 따라 트리 형태로 정리한 것입니다. 초기가설을 이슈로 나누어서 계층적 도식화를 한 것입니다. 

위와 같이 초기가설을 최상위의 이슈로 해서 MECE의 원칙을 지키며 하부 이슈(subissues)를 계속 트리 형태로 만들어 나갑니다. 위 예의 경우, 지역 A에 b 제품을 주로 취급하는 신규 매장과 공급망을 갖추는 것이 좋겠다는 초기가설을 세웠고 여기서부터 다시 하부 이슈를 또 만들어 나갑니다. 이슈 트리를 만들 때 주의할 점은 이슈란 결국 초기가설이 맞느냐 아니냐를 증명해 줄 수 있는 질문이어야 한다는 점입니다. 그 점을 염두에 두고, MECE 원칙을 지키면서 하부 이슈를 만들어야 합니다.

 

위와 같이 한 다음, 각각에 대해 타당성을 생각해 봅니다. 만약 두 번째 안이 가장 좋다고 판단된다면 역시 같은 방식으로 하부이슈를 더 만들어 나갑니다.

 

 

이런 방식으로 이슈트리를 만들어 나가면 초기가설이 맞는 지 아닌 지를 검증하기 위해 던져 보아야 할 질문이 논리적으로 구성되며, 전체적인 그림이 그려질 뿐만 아니라, 어떤 데이타를 조사해야 할 지도 한 눈에 파악됩니다.

 

이슈트리가 완성되면 분석 디자인 단계로 넘어 갑니다. 이슈트리에서 제기된 이슈의 유효성을 검증하기 위해서는 어떤 분석을 해야 하고, 언제까지 할 것이며, 누가 할 것인가, 그리고 각 분석의 최종 결과물은 어떤 형태가 될 것이며, 어떤 소스를 활용해야 하는 지 등을 계획표 형태로 만들어 내는 것이 분석 디자인입니다.

Designing Analysis

이슈 트리에서 제기된 이슈에 대한 대답을 디자인하는 것은 "Work Plan"을 만드는 것으로 귀결됩니다. 우선 최종 산물이랄 수 있는 작업계획을 보고 얘기를 진행합시다.

 

이런 형태로 분석을 진행해서 초기가설이 맞는 지 아닌 지를 확인하는 것입니다. 분석을 할 때 참고할 만한 가이드라인은 다음과 같습니다.

 

 (1) 키 드라이버(Key Drivers)를 찾아라

조사해야 할 팩트는 무한합니다. 하지만 결과에 커다란 영향을 미치는 핵심 요소는 소수입니다. 그 핵심 요소에 대한 심층적인 분석이 중요합니다. 많은 요소에 대한 분석보다 핵심적인 요소에 집중된 분석이 훨씬 좋습니다.

 

 (2) 큰 그림을 봐라

분석의 각론에 너무 깊게 들어 가서 이것이 최종적으로 어떤 것을 위한 분석인지를 잊게 되는 경우가 있습니다. 항상 큰 그림을 염두에 두고 분석을 해야 합니다. 이 분석의 최종 결과물이 어떤 것이 될 지를 생각하면서 분석을 진행해야 합니다.

 

 (3) 너무 정확하게 하려 들지 마라

정확한 값으로 틀리는 것보다는 대략 옳은 방향으로 가는 게 수백 배 낫습니다. 분석은 어느 방향으로 가는 것이 옳다는 정도만 제시할 수 있으면 되는 것이지 정밀한 숫자가 중요한 게 아닙니다.

 

 

이상으로 맥킨지에서 문제점을 어떤 식으로 분석해 들어 가는지 개괄적으로 살펴 보았습니다. 어느 기업이나 다들 문제점을 분석하는 나름의 틀과 방법이 있을 것입니다. 그런데, 상대적으로 구조가 허술하거나 경영진의 직관에만 지나치게 의존하는 경우가 생각보다 많습니다. 직관도 물론 중요하지만 위에서 설명한 것처럼 팩트 기반의 초기가설을 검증하는 형태로 문제점을 분석해 들어 가면 훨씬 더 포괄적이고도 효과적인 문제 분석 및 대응이 가능할 것으로 생각됩니다.