이 글은 “The Mckinsey Way”의 후속편으로 나온 “The Mckinsey Mind”의 문제점 분석에 관한 내용을 정리한 것입니다. “The Mckinsey Mind”는 전작에서 간단하게 소개했던 맥킨지 방식을 기술적으로 더 자세히 설명한 책입니다. “MECE”, “issue tree”라는 단어가 생소하신 분은 일단 위 문서를 읽고 오세요.
“The Mckinsey Way”가 가볍게 읽을 수 있는 책이라면 이 책은 로직트리, 이슈트리, 실제 데이타 수집 방법, 인터뷰 기법, 프리젠테이션 기법 등, 훨씬 더 세부적인 내용을 실례를 들어 가면서 자세히 설명하고 있습니다. (둘 중의 한 권만 구입해야 한다면 “The Mckinsey Mind”를 구입하는 게 더 좋을 것 같습니다.)실제 컨설팅 관련 일을 한다면 자세한 기법과 팁들이 도움이 큰 도움이 될 수 있습니다만, 컨설턴트가 아니라면 아무래도 문제점 분석 및 분석 결과를 만들어 내는 과정을 설명한 부분이 더 유용하리라 생각합니다.
맥킨지의 사고방식은 한 마디로 ‘structure에 대한 강조‘라고 할 수 있을 것 같고, 이처럼 구조적으로 문제점을 분석하고 해결해내는 것은 비단 비즈니스 현장뿐만 아니라 개인적인 문제나 사회적 이슈 등을 판단하는 데에도 큰 도움이 될 것입니다.
문제 분석의 4단계
맥킨지의 문제 분석 기법은 크게 네 단계로 이뤄집니다.
· Framing
· Designing
· Gathering
· Interpreting
‘Framing’은 문제의 범위가 어디까지인지 파악하고 문제를 쉽게 다룰 수 있는 작은 단위로 나누는 단계입니다. 프레이밍 단계는 초기가설(initial hypothesis)을 도출해 내는 단계입니다.
‘Designing’은 초기가설이 옳은지 아닌지를 증명하기 위해서는 어떤 분석이 필요한지를 규정하는 단계입니다.
‘Gathering’은 그 분석에 필요한 데이타, 즉 ‘팩트‘를 모으는 단계입니다.
‘Interpreting’은 데이타를 바탕으로 초기가설의 유효성을 판단하고 결과를 해석해서 앞으로 어떤 액션을 취해야 할 지 결정하는 단계입니다.
아주 당연해 보이는 흐름인 것 같습니다. 그렇지요? 사실은 그렇지 않습니다. 우리가 어떤 문제점에 봉착했을 때 어떤 식으로 대응하는지를 생각해 봅시다. ‘Framing’을 먼저 하나요? 특히 ‘Framing’을 엄격한 구조를 바탕으로 치밀하게 하나요? 별로 그렇지 않습니다. 대부분, ‘Gathering’에 달려 듭니다. 매출이 떨어진다는 문제가 생기면 일단 뭐가 문제인지 부문별 실적부터 점검하려고 드는 것입니다. 일차적으로 해야 할 일은 ‘매출 감소‘라는 문제의 범위를 명확히 하고, 이를 쉽게 다룰 수 있는 작은 단위로 구조적으로 나누는 것입니다. 그리고 그 구조를 바탕으로 초기가설을 세우고 이를 확인할 팩트를 모으는 것이 순서입니다. 팩트에서 출발하는 게 아니라 가설에서 출발합니다. 즉, 귀납적으로 접근하는 게 아니라 연역적으로 접근하는 것입니다. 문제해결에 있어서 왜 그게 더 효과적인지는 계속 읽어 가면서 생각해 보세요.
Framing
이 글은, 위의 네 단계 중 첫 단계인 “Framing”과 “Designing”에 관해서 정리한 것입니다. 나머지 단계 역시 문제점 분석에서 매우 중요한 것입니다만 조금은 일반론적인 얘기이거나 기술적인 내용들이므로 생략합니다. “Framing”에 관한 내용은 ‘사고방식‘에 관한 부분이기 때문에 상대적으로 더 중요하고 또 여러 방면으로 활용될 수 있을 것입니다.
문제점의 프레임웍화
프레이밍은 위에서 얘기한 것처럼 문제의 범위를 결정하고 초기가설을 세우는 단계입니다. 즉, 프레이밍이 끝나면 ‘fact-based hypothesis’가 만들어져야 합니다.
모든 문제는 엄격한 구조를 바탕으로 해결가능한 작은 단위로 나누어서 분석해야 합니다. 많은 책과 자료로 심하게 어지럽혀진 책장을 생각해 봅시다. 이것을 무작정 이리저리 밀치면서 정리하는 것은 매우 어렵습니다. 제일 먼저 해야 할 일은 책과 문서자료를 따로 분리하는 것입니다. 그 다음, 내용을 기준으로 책을 몇 개의 큰 덩어리로 구분하고, 자료도 같은 식으로 구분해야 할 것입니다. 차분하게 내용을 읽어 보며 분류할 수 있을 정도의 작은 덩어리로 나눠진 상태가 되면 이제 어렵지 않게 정리할 수 있게 될 것입니다.
프레이밍은 그처럼 혼돈상태에 질서를 부여하는 단계입니다. 프레이밍 단계를 통해서 막연한 문제점이 구체적인 이슈로 정리되고 분류되는 것입니다. 프레이밍을 할 때 자주 활용되는 툴이 로직트리(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”을 만드는 것으로 귀결됩니다. 우선 최종 산물이랄 수 있는 작업계획을 보고 얘기를 진행합시다.
쉽게 이해가 됩니다. 이런 형태로 분석을 진행해서 초기가설이 맞는지 아닌지를 확인하는 것입니다. 그러면 분석을 할 때 참고할 만한 가이드라인으로 어떤 것이 있는지 간단하게 살펴 봅시다.
· 키 드라이버(Key Drivers)를 찾아라: 조사해야 할 팩트는 무한합니다. 하지만 결과에 막대한 영향을 미치는 핵심요소는 소수입니다. 그 핵심요소에 대한 심층적인 분석이 중요합니다. 많은 요소에 대한 분석보다 핵심적인 요소에 집중된 분석이 훨씬 좋습니다. 무엇이 키 드라이버인지를 우선 찾으세요.
· 큰 그림을 봐라: 분석의 각론에 너무 깊게 들어 가서 이것이 최종적으로 어떤 것을 위한 분석인지를 잊게 되는 경우가 있습니다. 항상 큰 그림을 염두에 두고 분석을 해야 합니다. 이 분석의 최종 결과물이 어떤 것이 될 지를 생각하면서 분석을 진행해야 합니다.
· 너무 정확하게 하려 하지 말라: 정확한 값으로 틀리는 것보다는 대략 옳은 방향으로 가는 게 수백 배 낫습니다. 분석은 ‘어느 방향으로 가는 것이 옳다‘는 정도만 제시할 수 있으면 되는 것이지 정밀한 숫자가 중요한 게 아닙니다.
이상으로 맥킨지에서 문제점을 어떤 식으로 분석해 들어 가는지 개괄적으로 살펴 보았습니다. 어느 기업이나 다들 문제점을 분석하는 나름의 틀과 기법이 있습니다. 하지만 상대적으로 구조가 허술하거나 경영진의 직관에만 지나치게 의존하는 경우가 생각보다 많습니다. 직관도 물론 중요하지만, 맥킨지처럼 팩트 기반의 초기가설을 검증하는 형태로 문제점을 분석해 들어 가면 훨씬 더 포괄적이고도 효과적인 문제 분석 및 대응이 가능할 것입니다
