http://blog.naver.com/insideinfo/100028955839
세계 최고의 컨설팅 회사 중 하나인 맥킨지 컨설팅의 일하는 방식을 설명한 책, "The McKinsey Way"의 첫 번째 파트인, 비즈니스 문제점에 관한 매킨지식 사고방식(The McKinsey way of thinking about business problems) 내용을 정리해 보았습니다. 사업을 하면서 부딪히게 되는 문제점들을 어떻게 풀어 나가는지에 관해 많은 힌트를 주는 책입니다.
맥킨지는 세계 최고의 컨설팅 회사 중 하나입니다. 우리 나라 정부가 몇 년 전 맥킨지에 국가 전체의 전략에 관해 컨설팅을 의뢰했다는 것에서 드러나 듯 맥킨지의 공신력과 실력은 정평이 나있습니다. 미국 MBA 과정 졸업생들이 맥킨지를 선망하는 이유도 맥킨지 특유의 사고방식과 일처리 방식을 배울 기회를 가져볼 수 있기 때문이기도 하겠지만, 세계 최고 수준의 기업, 조직들의 문제를 현장에서 접하고 해결해 볼 수 있기 때문입니다.
이 글에서 살펴볼 "The McKinsey Way"의 파트 1은 크게 3개의
작은 챕터로 나눠져 있습니다.
그리고 파트 1을 이루는 각 챕터의 제목은 다음과 같습니다.
① Building the solution
② Developing an approach
③ 80/20 and other rules to live by
맥킨지는 "3"을 매직넘버로 생각합니다.
무엇이든 세 가지로 정리하는 것이 원칙입니다.
"3"이라는 제한 속에서 어떤 것을 정리해 나가면 핵심만 간결하게 요약됩니다.
"1 Page Proposal"(1장짜리 기획서)처럼, "3"이나 "1장"이라는 분량의 제한을 엄격하게 지킴으로써 문제점의 진정한 핵심으로 보다 쉽게 접근할 수 있습니다.
해결책 구축 (Building the solution)
해결책 구축은 크게 세가지를 지키며 진행합니다.
① Fact-based
② Rigidly structured
③ 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("미씨" 라고 발음합니다)를 지키면 최대의 명확성과 최고의 완결성을 갖고 사고할 수 있습니다.
맥킨지식 사고 방식의 핵심 중 하나가 바로 MECE입니다.
"Mutually Exclusive"는 서로 중복되지 않는, 상호 배타적인 것을 찾아낸다는 의미입니다.
"Collectively Exhaustive"는 찾아낸 것들을 다 합치면 문제점 전체가 커버가 되어야 한다는 의미입니다. 특히 MECE의 원칙을 지키면서 가급적이면 항목 수가 세 개를 넘지 않으면 더욱 좋습니다.
각각은 분명하게 분리되어 있고 명확하면서도 문제점과 관련된 모든 이슈가 다 포함되게 3가지 핵심 항목을 찾아내는 것이 "MECE"입니다.
MECE라는 구조를 이용해서 파악한 내용과 일차적 사실의 조합으로부터 초기가설(Initial Hypothesis)을 세웁니다. 초기가설은 문제점을 구조적으로 분할하는 것에서 시작합니다.
MECE의 형태로 문제를 구조적으로 분석해 들어가면서 어떤 것이 핵심요인(key driver)인지를 파악하는 것입니다. 이렇게 파악된 핵심 요인 각각에 대해 '실행 가능한(actionable)' 행동 지침을 만들어 냅니다. 실행 가능한 것을 찾는다는 것이 중요합니다.
맥킨지 방식은 '그렇다면 지금 할 수 있는 일은 무엇인가'를 꾸준히 묻는 방식입니다.
완벽한 해결책이 아닌 현 상태에서 할 수 있는 최선의 실행 가능한 해결책을 제시합니다.
예를 들어 "우리 회사의 a제품 판매가 미흡합니다. 어떻게 매출을 늘릴 수 있을까요?" 라고 의뢰했다면 다음과 같이 MECE 프레임웍을 이용해서 초기가설을 세운 다음, 각각의 이슈에 대해 계속 MECE 방식으로 사고하며 가지를 쳐 나갑니다. 그 결과는 "issue tree"라 불리는 다음과 같은 도표입니다.
이처럼 막연히 바라보면 매우 복잡해 보이는 문제도 어떤 구조(structure)를 적용해서 분석해 들어가면 해결 가능한 작은 덩어리들로 쪼개어지면서 문제점 전체를 정확하게 파악할 수 있고 해결책도 쉽게 떠오릅니다. 그리고 'best'보다는 'better'를 찾는 태도, 즉 최선은 아닐지라도 즉시 실행가능한 사항을 찾아내야 합니다.
ø 이슈트리와 초기가설에 관한 자세한 내용은 맥킨지 식 문제 분석법: 이슈트리와 초기가설을 참고
하세요.
이렇게 구축된 해결책 시안을 바탕으로 접근법을 생각합니다.
접근법 도출 (Developing an approach)
앞에서 만들어본 해결책 시안은 실제 현장에 그대로 적용할 수 있는 것이 아닙니다. 문제점의 특성에 따라, 회사의 특징에 따라, 기타 특수한 환경 요인에 따라 변화를 줘야 합니다. 이렇게 접근법을 만들어 가는 데 도움이 되는 내용을 살펴봅시다.
(1) 문제점이 항상 문제점인 것은 아니다
어떤 의사도 환자가 호소하는 증상이 곧 문제의 원인이라고 생각하지 않습니다. 머리가 아프다는 환자의 호소에 두통약을 바로 처방하는 의사는 없습니다. 환자의 주소(chief complaints)는 환자의 진정한 문제점으로 접근해 들어가는 단서입니다. 환자의 이야기를 경청은 하되, '증상'의 진정한 원인을 생각해야 합니다. 컨설턴트도 그렇습니다.
"매출이 줄어서 걱정입니다"는 비즈니스맨이 회사의 증상을 표현한 것입니다. 매출이 줄어든 것이 가장 큰 문제일 수도 있지만 사실은 현재 활동하고 있는 시장에 대해 부정적인 생각을 하고 있는 것일 수도 있습니다. 컨설팅을 의뢰한 사람 자신이 그 사실을 느끼고 있을 수도 있고, 느끼지 못한 채 '매출'을 증상으로 무엇인가 문제점이 있다는 것을 호소하는 것일 수 있습니다. 컨설턴트는 경청은 하되, 그것이 진짜 문제인가에 대해 재평가를 하며 일을 진행해 나가야 합니다. 항상 문제점 자체에 문제의식을 갖고 있어야 합니다.
(2) "Forces at work"
문제점의 핵심요인(key drivers)을 파악하는 데 자주 활용되는 것이 "Forces at work" 분석입니다.
현재 회사에 영향을 미치는 힘들이 어떤 것이 있고 이들이 긍정적으로 작용하는지, 부정적으로 작용하는지를 분석하는 것입니다. 회사의 공급자, 고객, 경쟁자, 잠재적 대체재에 대해 이들이 어떻게 회사에 영향을 줄 수 있는지 분석합니다. 마이클 포터의 프레임웍과 같습니다.
① 팩트를 솔루션에 끼워 맞추려 하지 말라
초기가설이 최종 해결책이 되기를 바라는 유혹을 피해야 합니다. 문제해결은 초기가설이 옳았음을 증명하는 것이 아닙니다. 초기가설이 아무리 훌륭하게 생각되고 완벽해 보이더라도, 이것이 완전히 틀릴 수 있다는 사실을 늘 염두에 두고 유연하게 사고해야 합니다.
초기가설에 집착해서 수집된 팩트마저 거기에 끼워 맞추려 해서는 안됩니다. 이런 유혹을 이겨내는 좋은 방법 중 하나는 일이 진행되어가는 중간에, 지난 1주일(1달) 동안 무엇을 알아냈는지 그리고 그것이 초기가설에 얼마나 적합한지를 정기적으로 리뷰하는 것입니다. 만약 초기가설로 설명되지 않는 현상이 발견되면 가설 자체를 의심해 볼 수도 있어야 하며, 이런 리뷰를 정기적으로 해야 합니다.
② 솔루션이 의뢰한 회사에 잘 맞는지를 확인해라
아무리 명약이라고 하더라도 그것이 환자와 맞지 않으면 소용없습니다. 위장이 나쁜 관절염 환자에게 위에 부담이 가는 탁월한 관절염 약을 처방하는 것은 환자의 병을 치료하는 데 도움이 안됩니다.
약을 꾸준히 복용할 수도 없을 뿐만 아니라 환자의 건강을 해칠 수도 있습니다. 비록 그 약이 특효약이라도 그렇습니다.
솔루션도 마찬가지입니다. 그 솔루션이 아무리 완벽하더라도 의뢰인의 회사에 적합하지 않으면 아무 소용이 없습니다. 대대적인 IT 투자로 프로세스 개선을 하는 것이 가장 좋은 해결책이라고 해서 투자 여력이 부족한 회사에게 이 안을 권고하는 것은, 그것이 유일한 해결책인 것처럼 생각되어도 틀렸습니다.
'학문적 이상'과 '현실'이 부딪히면 항상 '현실'이 이깁니다. 그리고 비즈니스는 살아있는 사람이 활동하는 공간이고, '현실적 강점'과 '현실적 약점', '현실적 한계'가 가득 차 있습니다. 컨설턴트는 반드시 의뢰인은 한계를 알아야 합니다.
③ 도저히 해결이 안 되는 문제가 생기면... 어쨌든 해결한다
초기가설을 세울 수 없을 정도로 혼돈스러운 상황일 때, 굳이 억지로 초기가설을 세우는 데 집착할 필요는 없습니다. 일단 일을 하면서 팩트를 열심히 모으고, 팩트를 바라보며 생각하다 보면 어떤 해결책이 떠오를 수도 있습니다. 그리고 일을 진행해 가는 과정에서 해결이 안 될 것 같은 거대한 장벽에 부딪히면 굳이 계속 머리를 부딪히며 상처만 입을 필요가 없습니다.
특히 컨설팅에 있어서 가장 큰 장애물은 기업 내부의 '정치'입니다. 팩트를 모으는 단계에서부터 사내 정치의 벽에 부딪혀 일이 전혀 진행되지 않을 수 있습니다. '구조조정' 계획을 세우기 위해 불러들인 낯선 이방인들에게 회사의 실제 상황을 우호적으로 말해줄 것을 기대하는 것은 무리입니다.
자신의 안위에 영향을 미칠 지도 모르는 컨설턴트에 협조적이지 않는 것은 당연합니다. 그렇게 정치의 장벽에 부딪혀 일이 한 발짝도 진행되지 않는다면 거기에 머리를 부딪혀 봐야 회사에게나 컨설턴트에게나 아무 도움이 안됩니다.
그럴 때는, 1) 문제를 재정의합니다.
회사의 문제가 사실은 x가 아니라 y라고 이야기를 해줍니다. 특히 y를 해결하면 회사에 다른 측면에서 큰 도움이 된다면 더욱 좋습니다. 해결이 안 되는 x에 매달리다가 엉망이 되어버리는 것보다는 y를 해결해서 모두에게 도움이 되는 편이 좋습니다.
2) 서서히 섬세하게 조정해 나갑니다.
이상적인 조직 개편 솔루션이 조직내 정치 때문에 임플리멘테이션하기 힘들면, 즉시 솔루션대로 구축하려 하지 말고 서서히 진행해 나갑니다. 조직이 재편되어 감에 따라 점차 원안에 가깝게 바꾸어 나갈 수 있습니다.
3) 정치를 역이용합니다.
사람은 인센티브에 반응하게 되어 있습니다. 정치적 반대에 부딪혀서 일이 진행되지 않는 것은 회사 구성원들의 개인적 이해에 심대하게 영향을 미치기 때문입니다. 그것이 극복되기 힘들 정도로 큰 것이라면 다른 인센티브를 제시하세요. 정치는 가능성의 예술입니다. 다른 방향으로 인센티브를 제시하며 타협적이라도 해결책을 내놓는 것이 이상적인 것만 고집하다가 아무 결과를 못 만들어 내는 것보다 훨씬 낫습니다.
위와 같은 방식으로 구축된 해결책은 항상 "actionable"하고 "provable"해야 합니다.
다시 강조하지만, 고객이 실천 가능한 솔루션을 제시해야지 가장 이상적인 것을 강요하는 것은 의미가 없습니다. 고객의 상황에서 즉시 실행 가능한 대안을 제시해야 합니다. 그리고 또한 결과를 확인해 볼 수 있어야 합니다. 매출 부진이 문제점이었다면 제시된 해결책대로 시행한 경우 매출 증대가 있어야 합니다.
마지막으로 비즈니스 문제점을 접근하는데 있어 참고할 만한 몇가지 법칙과 방법론입니다.
문제 해결시 유용하게 활용할 수 있는 몇 가지 법칙들
(1) 80/20 원칙
80/20 원칙은 결과의 대부분을 좌우하는 것은 아주 소수의 핵심적인 부분이라는 의미입니다.
80/20 원칙은 실증적 데이타를 바탕으로 도출되고 검증된 법칙이기 때문에 현장에서 탁월한 효과를 발휘합니다.
매출이 줄었다는 문제점에 봉착했다면 매출의 80%가 어디에서 비롯되는지를 실제 데이타를 통해 분석해 봅니다. 고객이 줄었다면 고객의 80%가 20%의 지역에서 오는 것은 아닌지 점검해 봅니다.
이런 식으로 결과에 막대한 영향을 미치는 핵심 부분을 파악해서 그 핵심을 공략할 특화된 방법을 찾는다는 것이 80/20 원칙입니다. 힘을 분산해서는 안됩니다.
ø 자세한 내용은 "80/20 원칙: 적게 투입하고 많이 거둬들일 수 있는 비밀"을 읽어보세요.
(2) 바닷물을 끓이려 들지 말라
모든 것을 다 분석하려 해서는 안됩니다. 항상 선택하고, 일에 우선순위를 매겨야 합니다.
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.
(3) 핵심요인(Key drivers)을 찾아라
문제점이 2배로 복잡해지면 그 해결 시간은 4배로 늘어납니다. Gerald M. Weinberg의 "An introduction to general systems thinking"이란 책에 나오는 얘기입니다. 문제점에 영향을 미치는 여러 요소들을 가급적 단순화해서 가장 중요한 것에 집중해야 합니다.
핵심요인을 찾겠다는 것은 우선순위를 생각한다는 의미입니다. MECE로 파악한 이슈 중 어떤 것에 가장 우선순위를 둘 지 생각하세요.
(4) 엘리베이터 테스트
해결책은 고객(투자자)에게 30 초내에 완벽하게 설명할 수 있어야 합니다. 엘리베이터를 타고 올라가는 동안 다 설명할 수 있을 정도로 요약을 해야 합니다. 헐리웃에도 비슷한 테스트가 있습니다.
제작자에게 1분 내에 시나리오를 설명해서 확 끌리는 뭔가가 있어야 흥행합니다. "1 page proposal"도 마찬가지입니다. 제한을 엄격하게 가하며 내용을 압축하고 또 압축하면 훨씬 더 핵심에 가까우면서 이해가 쉬운 어떤 것이 나옵니다.
(5) 딸 수 있는 열매부터 따라
마지막 순간에 엄청나게 멋진 무엇인가를 보여줄 생각으로 눈앞에 보이는 쉬운 성취를 외면하는 것은 매우 어리석은 행동입니다. 일단 쉽게 할 수 있는 것부터 하나씩 하다 보면 어느새 일이 쉬워지고 또 사기가 올라가며 흥미도 배가됩니다. 시험 공부나 졸업 논문, 기타 많은 일들이 마지막에 뭔가 보여주리라며 미루다가 아예 아무 것도 안되는 경우가 많습니다. 쉽게 할 수 있는 것부터 하세요. 바로 보여줄 수 있는 성과는 보여줘 가며 진행하세요. 그래야 고객의 신뢰도 얻게 됩니다.
핵심은 이것입니다. 복잡해 보이는 문제들도 일단 MECE, Forces at Work 등의 구조를 적용해서 구체적으로 분할하고, 분할한 내용을 바탕으로 80/20법칙을 비롯한 몇 가지 방법을 활용해서 해결책을 찾은 다음, 이상적이지는 않더라도 즉시 개선시킬 수 있는 행동 지침을 끌어내는 것입니다.
여러 용어가 나왔는데 그런 용어자체는 큰 의미가 없습니다. 가장 중요한 것은 문제점을 마구잡이로 접근하지 않고 항상 "structure"를 갖고 풀어 나가라는 점입니다.
문제 분석의 4단계
맥킨지의 문제 분석 기법은 크게 네 단계로 이뤄집니다.
① Framing
② Designing
③ Gathering
④ Interpreting
'Framing'은 문제의 범위가 어디까지인지 파악하고 문제를 쉽게 다룰 수 있는 작은 단위로 나누는 단계입니다. 프레이밍 단계는 초기가설(initial hypothesis)을 도출해 내는 단계입니다.
'Designing'은 초기가설이 옳은지 아닌지를 증명하기 위해서는 어떤 분석이 필요한지를 규정하는 단계입니다.
'Gathering'은 그 분석에 필요한 데이타, 즉 '팩트'를 모으는 단계입니다.
'Interpreting'은 데이타를 바탕으로 초기가설의 유효성을 판단하고 결과를 해석해서 앞으로 어떤 액션을 취해야 할 지 결정하는 단계입니다.
아주 당연해 보이는 흐름인 것 같습니다. 그렇지요? 사실은 그렇지 않습니다. 우리가 어떤 문제점에 봉착했을 때 어떤 식으로 대응하는지를 생각해 봅시다.
'Framing'을 먼저 하나요? 특히 'Framing'을 엄격한 구조를 바탕으로 치밀하게 하나요? 별로 그렇지 않습니다. 대부분, 'Gathering'에 달려 듭니다.
매출이 떨어진다는 문제가 생기면 일단 뭐가 문제인지 부문별 실적부터 점검하려고 드는 것입니다.
일차적으로 해야 할 일은 '매출 감소'라는 문제의 범위를 명확히 하고, 이를 쉽게 다룰 수 있는 작은 단위로 구조적으로 나누는 것입니다. 그리고 그 구조를 바탕으로 초기가설을 세우고 이를 확인할 팩트를 모으는 것이 순서입니다. 팩트에서 출발하는 게 아니라 가설에서 출발합니다. 즉, 귀납적으로 접근하는 게 아니라 연역적으로 접근하는 것입니다. 문제해결에 있어서 왜 그게 더 효과적인지는 계속 읽어 가면서 생각해 보세요.
Framing
이 글은, 위의 네 단계 중 첫 단계인 "Framing"과 "Designing"에 관해서 정리한 것입니다. 나머지 단계 역시 문제점 분석에서 매우 중요한 것입니다만 조금은 일반론적인 얘기이거나 기술적인 내용들이므로 생략합니다. "Framing"에 관한 내용은 '사고방식'에 관한 부분이기 때문에 상대적으로 더 중요하고 또 여러 방면으로 활용될 수 있을 것입니다.
(1) 문제점의 프레임웍화
프레이밍은 위에서 얘기한 것처럼 문제의 범위를 결정하고 초기가설을 세우는 단계입니다. 즉, 프레이밍이 끝나면 'fact-based hypothesis'가 만들어져야 합니다.
모든 문제는 엄격한 구조를 바탕으로 해결가능한 작은 단위로 나누어서 분석해야 합니다.
많은 책과 자료로 심하게 어지럽혀진 책장을 생각해 봅시다. 이것을 무작정 이리저리 밀치면서 정리하는 것은 매우 어렵습니다. 제일 먼저 해야 할 일은 책과 문서자료를 따로 분리하는 것입니다.
그 다음, 내용을 기준으로 책을 몇 개의 큰 덩어리로 구분하고, 자료도 같은 식으로 구분해야 할 것입니다. 차분하게 내용을 읽어 보며 분류할 수 있을 정도의 작은 덩어리로 나눠진 상태가 되면 이제 어렵지 않게 정리할 수 있게 될 것입니다.
프레이밍은 그처럼 혼돈상태에 질서를 부여하는 단계입니다. 프레이밍 단계를 통해서 막연한 문제점이 구체적인 이슈로 정리되고 분류되는 것입니다. 프레이밍을 할 때 자주 활용되는 툴이 로직트리(logic tree)입니다. 로직트리는 가장 큰 문제점부터 논리적 순서에 따라 작은 단위로 나누어서 분류하는 것입니다. 예를 하나 들어 봅시다.
위와 같이 '이익감소'라는 혼돈상태에 있는 문제를 엄격한 프레임웍을 바탕으로 다루기 쉬운 단위로 나누는 것이 로직트리입니다. 로직트리를 통해 문제점에 대한 포괄적인 시각을 얻을 수 있으면서 동시에 어디를 해결하는 것이 문제해결에 가장 중요한지가 훨씬 명확해집니다.
이렇게 일단 문제의 프레임웍이 완성되면 이를 바탕으로 초기가설을 세웁니다.
(2) 초기가설(Initial Hypothesis)
로직트리 등을 통해 문제의 범위와 얼개를 파악하고 난 상태에서 일단 해결책을 생각해 보는 게 초기가설입니다. 초기가설은 아직 자세한 팩트가 조사되지 않은 단계에서 세우는 것입니다.
왜 팩트를 충분히 조사하지 않은 상태에서 초기가설을 우선 세우는 것일까요?
조사해야 할 팩트와 수행할 수 있는 분석은 사실상 무한히 많습니다. 특히 비즈니스 문제점은 정답이 없는 대단히 복잡한 변수와 요소들로 가득 차 있기 때문에 팩트를 조사한 뒤에 이를 바탕으로 해결책 시안을 만든다는 식의 접근은 시간과 노력만 잡아 먹는 결과로 이어질 수 있습니다.
제한된 팩트와 약간의 직관, 그리고 브레인스토밍을 통해서 일단 초기가설을 세우고, 그 가설이 맞는지 아닌지를 증명해 줄 수 있는 팩트를 찾아 나서는 순서로 진행하는 것이 훨씬 효과적이고 효율적입니다.
초기가설을 먼저 세우고 팩트를 분석하는 게 더 효율적인 이유는, 결론을 미리 알고 과정을 찾아 가는 게 반대의 경우보다 더 쉽고 빠르기 때문입니다. 미로찾기를 할 때 시작점에서 출발하는 것보다 출구에서 시작해서 반대로 거슬러 올라가는 게 더 빠른 것과 마찬가지입니다.
그리고 분석해야 할 팩트는 너무나 많기 때문에 초기가설이 옳은지 그른지 증명한다는 목적을 염두에 두고 팩트를 조사해 나가면 우선순위가 명확해지고 불필요한 곳에서 시간낭비를 하지 않을 수 있는 것입니다.
예컨데, 위와 같은 로직트리를 보면서 '지역A의 제품b 유통판매망을 강화하는 게 이익을 늘리는 데 가장 효과적일 것이다.'와 같은 초기가설을 세울 수 있습니다. 초기가설이 꼭 최종대안과 같을 필요는 없습니다. 중요한 것은 팩트를 조사하기 전에 상당히 설득력 있는 가설을 세워야 한다는 것입니다.
초기가설이 좋은 가설인지 아닌지를 테스트하는 좋은 방법으로 QDT(Quick and Dirty Test)가 있습니다.
QDT는, '그 가설이 사실이려면 어떤 전제가 되어 있어야 하느냐'를 묻는 것입니다. 그 전제(들)에 문제가 있거나 가능성이 낮다면 그 가설은 좋은 가설이 아닙니다. 또는, 반대로, '이 가설이 틀린 것이 되게 할 요인은 무엇이 있을까'를 물을 수도 있습니다.
위에서는 '제품b가 지역A에서 잘 팔릴 수 있다는 근거는 무엇인가', '제품b가 지역A에서 잘 팔리지 않은 게 접근성이 낮아서라는 근거는 무엇일까?', '제품c가 지역A에 더 적합하지 않을까', ... 등을 물어 보는 것입니다. 아주 간단하지만 실제로 해 보면 굉장히 유용합니다.
(3) 이슈트리(Issue Tree)
초기가설이 세워졌으면 이슈트리를 만듭니다. 프레이밍 단계는 이슈트리를 완성함으로써 마무리됩니다. 이슈트리는 로직트리와 비슷한 형태인데, 문자 그대로 '이슈', 즉, 초기가설이 옳은 지 아닌 지를 판별하는 기준이 되는 이슈를 MECE 원칙에 따라 트리 형태로 정리한 것입니다. 초기가설을 이슈로 나누어서 계층적 도식화를 한 것입니다. 위의 예를 계속 들어 봅시다.
위와 같이 초기가설을 최상위의 이슈로 해서 MECE의 원칙을 지키며 하부이슈(subissues)를 계속 트리형태로 만들어 나갑니다.
위 예의 경우, 지역A에 제품b를 주로 취급하는 신규매장과 공급망을 갖추는 것이 좋겠다는 초기가설을 세웠고 여기서부터 다시 하부이슈를 또 만들어 나갑니다. 이슈트리를 만들 때 주의할 점은, 이슈란 결국 초기가설이 맞느냐 아니냐를 증명해 줄 수 있는 질문이어야 한다는 점입니다. 그 점을 염두에 두고, MECE 원칙을 지키면서 하부이슈를 만들어야 합니다.
위와 같이 한 다음, 각각에 대해 타당성과 가능성을 생각해 봅니다. 만약 두 번째 안이 가장 좋다고 판단된다면 역시 같은 방식으로 하부이슈를 더 만들어 나갑니다.
이런 방식으로 이슈트리를 만들어 나가면 초기가설이 맞는지 아닌지를 검증하기 위해 던져 보아야 할 질문들이 논리적으로 구성되며, 전체적인 그림이 그려질 뿐만 아니라, 어떤 데이타를 조사해야 할 지도 한 눈에 파악됩니다.
이슈트리가 완성되면 분석 디자인 단계로 넘어 갑니다. 이슈트리에서 제기된 이슈들의 유효성을 검증하기 위해서는 어떤 분석을 해야 하고, 언제까지 할 것이며, 누가 할 것인가, 그리고 각 분석의 최종 결과물은 어떤 형태가 될 것이며, 어떤 소스를 활용해야 하는지 등을 계획표 형태로 만들어 내는 것이 분석 디자인입니다.
(4) Designing Analysis
이슈트리에서 제기된 이슈에 대한 대답을 위한 분석을 디자인하는 것은 "Work Plan"을 만드는 것으로 귀결됩니다. 우선 최종 산물이랄 수 있는 작업계획을 보고 얘기를 진행합시다.
쉽게 이해가 됩니다. 이런 형태로 분석을 진행해서 초기가설이 맞는지 아닌지를 확인하는 것입니다. 그러면 분석을 할 때 참고할 만한 가이드라인으로 어떤 것이 있는지 간단하게 살펴 봅시다.
① 키 드라이버(Key Drivers)를 찾아라
조사해야 할 팩트는 무한합니다. 하지만 결과에 막대한 영향을 미치는 핵심요소는 소수입니다. 그 핵심요소에 대한 심층적인 분석이 중요합니다. 많은 요소에 대한 분석보다 핵심적인 요소에 집중된 분석이 훨씬 좋습니다. 무엇이 키 드라이버인지를 우선 찾으세요.
② 큰 그림을 봐라
분석의 각론에 너무 깊게 들어 가서 이것이 최종적으로 어떤 것을 위한 분석인지를 잊게 되는 경우가 있습니다. 항상 큰 그림을 염두에 두고 분석을 해야 합니다. 이 분석의 최종 결과물이 어떤 것이 될 지를 생각하면서 분석을 진행해야 합니다.
③ 너무 정확하게 하려 하지 말라
정확한 값으로 틀리는 것보다는 대략 옳은 방향으로 가는 게 수백 배 낫습니다. 분석은 '어느 방향으로 가는 것이 옳다'는 정도만 제시할 수 있으면 되는 것이지 정밀한 숫자가 중요한 게 아닙니다.
이상으로 맥킨지에서 문제점을 어떤 식으로 분석해 들어 가는지 개괄적으로 살펴 보았습니다. 어느 기업이나 다들 문제점을 분석하는 나름의 틀과 기법이 있습니다. 하지만 상대적으로 구조가 허술하거나 경영진의 직관에만 지나치게 의존하는 경우가 생각보다 많습니다. 직관도 물론 중요하지만, 맥킨지처럼 팩트 기반의 초기가설을 검증하는 형태로 문제점을 분석해 들어 가면 훨씬 더 포괄적이고도 효과적인 문제 분석 및 대응이 가능할 것입니다.
출처: http://www.emh.co.kr
+ 사실을 중시하라
" 사실은 우리가 해결책을 찾고 그것을 뒷받침하기 위한 기초자료이다. 사실을 두려워하지말라."
맥킨지의 문제해결은 사실에서 시작한다.
프로젝트가 발생한 첫날, 맥킨지의 팀원들은 문제의 본질을 잘 파악할 수 있는 충분한 사실들을 수집하기 위해 각종 자료들을 샅샅이 수집하고, 첫 회의를 준비한다. 문제해결을 위한 초기가설을 세운 후에, 맥킨지의 팀원들은 즉시 필요한 사실들을 모아(적절한 분석을 거친 후에) 가설을 검증하기 시작한다.
맥킨지에 입사하면 사실 수집과 분석은 가장 중요한 활동 중의 하나가 된다.
전에 SEM으로 일했던 한 사람의 말을 들어보자
" 맥킨지의 문제해결과정은 결국, 매우 신중하고 체계적인 분석과 자료수집을 위한 적극적인 자세로 대변됩니다."
맥킨지의 업무 방식에서 사실이 왜 그렇게도 중요한가? 거기에는 두 가지 이유가 있다.
첫째, 사실은 육감(gut instinct)의 한계를 보충한다.
대부분의 맥킨지인들은 제너럴리스트(generalist)들이다. 이들은 만물박사처럼 다양한 것에 대해 조금씩 알고 있다. 물론 경험을 쌓고 지위가 높아지면 다양한 것에 대해 많은 것을 알게 될 수도 있다. 쉬운 음식물의 재고관리 기술에 대해서는, 10년 동안 해당 회사의 유통 분야에서 일을 한 사람보다는 아는 것이 적을 것이다. 식품회사의 직원들은 육감으로 재고관리 문제의 해결책을 즉시 알아낼 수도 있다.(물론 이 경우에도 사실을 확인하는 것이 현명할 것이다). 반면에 맥킨지인들은 먼저 사실부터 수집한다.
둘째, 사실은 신뢰감을 형성한다.
맥킨지의 직원은 처음 입사할 때 (적어도 미국에서는) 대학을 최상위권으로 졸업한 뒤 2,3 년 동안 대기업에서 일을 하고, 그런 후에 명문 경영대학원에서 MBA를 받았을 것이다. 그리고 나이는 20대 중반에서 후반일 것이다. 이런 상태에서 맡은 첫 프로젝트에서 이들은 <포춘> 선정 50대 기업의 경영자에게 분석 내용을 제시해야 할지도 모른다. 이와 같은 대기업의 경영자가 풋내기 컨설턴트의 말을 무시할 수도 있다. 이들에게 신뢰감을 주려면 엄청난 양의 사실제시로 자신들의 주장을 뒷받침해야 한다. 이 점은 회사의 중견 간부가 자신의 상사에게 어떤 제안을 할 때도 마찬가지로 적용된다.
사실이 갖는 힘에도 불구하고(혹은 그것 때문에) 비즈니스를 하는 많은 사람들이 사실을 두려워한다. 이들의 두려움은 사실을 알게 될 때 자신들이나 상사들이 그것을 싫어하게 될지도 모른다는 이유 때문일 것이다. 이들은 사실을 외면하면 골치 아픈 사실이 없어진다고 생각하는지도 모른다. 그러나 현실은 그렇지가 않다. 사실을 외면하면 실패를 자초하게 된다. 결국에는 진실이 드러나기 때문이다. 사실을 겁내지 말아야 한다. 사실을 찾고 활용하되, 그것을 두려워하지는 말라.
+ 항상 'MECE'를 생각하라
" 문제의 해결을 위해 생각을 구조화하려면 혼란과 중복을 피하면서 전체를 볼 수 있어야 한다."
MECE는 ‘서로 배타적이면서, 부분의 합이 전체를 구성하는 (mutually exclusive, collectively exhaustive)’ 것을 의미한다. 그리고 이것이 맥킨지의 문제해결과정에서 선결조건이다.
입사할 때부터 맥킨지 신입 컨설턴트들은 이 말을 귀가 따갑도록 듣는다. 맥킨지인이라면 모든 서류(내부 메모를 포함해서), 모든 제안, 모든 E-mail, 그리고 모든 음성 사서함을 MECE 원칙에 의해 처리해야 한다. 맥킨지 출신들에게 회사의 문제해결 방식 가운데 가장 기억에 남는 것이 무엇이냐고 물어 보라. 그러면 백이면 백 이렇게 대답할 것이다. "MECE, MECE, MECE."
MECE는 우리의 사고를 최대한의 명확성(따라서 최소한의 혼란)과 최대한의 완벽성으로 구조화시킨다. MECE는 문제를 구성하는 이슈(issue)들을 규정할 때 시작된다.
이슈들을 규정했다고 생각한 후에 잠시 곰곰이 생각해 보라.
각각의 이슈가 서로 구분되고 명확한 항목인가? 그렇다면 당신의 이슈 리스트는 '서로 배타적'이다.
문제의 모든 측면들이 그 이슈들의 어느 하나(그리고 오직 하나) 밑에 들어 있는가? 다시 말해서 모든 것을 생각했는가? 그렇다면 당신의 이슈리스트는 '전체적으로 포괄적인(collectively exhaustive)'이다.
가령 당신의 팀이 미국의 제조회사 애크미 상품(Acme Widget)의 프로젝트를 맡았다고 생각해보자. 이제 당신이 해결할 문제는 '우리는 더 많은 상품을 팔아야 한다'이다. 당신의 팀은 다음과 같은 방식들로 상품 판매를 늘리고자 할지도 모른다.
• 우리가 소매점들에 상품을 파는 방식을 바꾼다.
• 우리가 소비자들에게 마케팅하는 방식을 개선한다.
• 우리 상품들의 단위 원가를 낮춘다.
이 목록이 다소 일반적으로 보여도 상관없다. 더 자세한 얘기는 곧 이어서 다루게 될 것이다. 중요한 것은 이 목록이 MECE하다는 점이다.
우리가 다른 항목을, 가령 '우리의 상품 생산과정을 재정비한다'라는 이슈를 추가한다고 생각해 보자. 이것이 방금 얘기한 세 가지 사항과 어떻게 들어맞는가? 이것은 틀림없이 중요한 주제이지만, 이것을 다른 것들과 함께 네 번째 사항으로 만들 수는 없다. 이것은 '단위 원가를 낮춘다' 밑에 들어가며, '유통 체계를 강화시킨다'나 '재고관리를 개선한다'와 같은 세부사항들 역시 그러하다.
왜 그런가? 왜냐하면 이 모든 것들이 제품의 단위 원가를 낮추는 방식이기 때문이다.
이중에서 어느 하나를(혹은 전부를) 위에 든 세 가지 사항과 나란히 놓는 것은 중복을 초래한다. 그러면 목록에 오르는 항목들이 서로 배타적이 될 수 없다. 중복된 요소는 작성자의 뒤섞인 사고를 나타내고 그것은 고객에게 혼란을 초래한다.
모든 항목들이 별도의 독립적인 특성을 갖는(즉, 서로 배타적인) 목록을 만든 후에는, 그 목록을 통해 문제와 관련된 모든 항목들이 포함되는지(즉, 그것이 전체적으로 포괄적인지) 확인해야 한다.
잠시 '상품 생산과정을 재정비한다'는 문제로 돌아가 보자. 당신은 이것을 단위 원가를 낮춘다' 밑에 놓았다. 이제 팀원 중 한 명이 이렇게 얘기한다. "우리는 생산과정을 통해 상품의 질을 개선하는 방식들을 생각해야 합니다."
맞는 말이다. 그렇다면 다시 재정비의 문제를 독립적인 항목으로 만들어야 하는가? 그렇지는 않다.
하지만 목록을 더 정교하게 만들어서 '단위 비용을 낮춘다' 밑에 '단위 비용을 낮추기 위해 생산과정을 재정비한다'는 세부항목을 놓고, '마케팅 하는 방식을 개선한다' 밑에 '상품의 질을 개선하기 위해 생산과정을 재정비한다'는 세부항목을 놓아야 한다. 그러면 이제 다음과 같은 목록이 나오게 된다.
• 우리가 소매점들에 상품을 파는 방식을 바꾼다.
• 우리가 소비자들에게 마케팅 하는 방식을 개선한다.
- 상품의 질을 개선하기 위해 생산과정을 재정비한다.
• 우리 상품들의 단위 원가를 낮춘다.
- 단위원가를 낮추기 위해 생산과정을 재정비한다.
가령 당신의 팀이 이런 항목들과 상관없는 흥미로운 아이디어를 냈다고 하자. 이럴 때는 어떻게 해야하는가? 이런 사항들을 무시할 수도 있지만, 그렇게 하는 것은 애크미 회사에 도움이 되지 않는다. 이것들은 독립적인 항목으로 만들 수도 있지만, 그렇게 하면 너무 많은 항목들을 갖게 된다.
맥킨지의 이슈 목록에는 적어도 2개 이상, 그리고 많게는 5개 이하의 주요 항목만이 있어야 한다.(물론 '3개'가 가장 좋다)
그러나 이런 난제에도 해답은 있다. 바로 '기타 사항(Other Issues)'이라는 마술의 범주이다.
당신에게 빛나는 아이디어가 떠오를 때마다 늘 '기타 사항'을 사용할 수 있다. 그렇지만 단서가 하나 있다. 이 기타 항목을 목록의 첫 단계(top-line list)에 놓는 것은 피하는 것이 좋다.(그것은 경우에 맞지 않는다) 우선 먼저 새로운 아이디어를 집어넣을 수 있도록 노력해 보라. 그래도 안 될 경우에는 기타사항을 사용해서 여전히 MECE를 유지하라.
