Marketing Arcadia RSS FEED

마인드맵에 대해서 저도 정확한 정의와 활용법을 잘 알고 있는 것은 아닙니다. 정확하게 제가 쓰는 방법은 로직트리의 형식으로 이슈, 리서치 아이템을 마인드맵 프로그램으로 정리한다가 맞을 것입니다. 예를 들면 A라는 서비스의 개선이 필요하다는 프로젝트 목적이 있을 때 해당 목적의 주요 이슈와 해당 이슈를 해결하기 위한 리서치아이템(질문)을 마인드맵으로 쭉 정리해 보는 것이죠.

프로젝트 기획 단계에서 이렇게 하나의 set을 정리해 두면 이후 프로젝트 종료까지 매우 많은 도움이 됩니다.

1. 프로젝트의 중요한 가이드가 되어 이후 설문설계, 보고서 작성에서 방향을 잃지 않게 해줍니다. 즉 설문 설계 단계에서 내가 어떤 질문을 넣어서 설문을 구성해야 하는지? 그 질문이 어떤 이슈를 해결할 수 있는지? 더 추가해야 할 질문이 없는지 쉽게 파악이 가능합니다. 또한 보고서에서 목적 달성을 위해서 어떤 이슈에 대해서 답을 해야 하고 그 답을 어떤 데이터를 통해서 도출이 가능한지? 알려 줍니다. 정신 없이 프로젝트를 진행하다 보고서 작성 시점에 이슈 해결을 위해서 필요한 질문(데이터)이 누락되는 경우가 아마 한, 두번은 있으실 겁니다. 물론 마인드맵을 통해 정리한다고 해서 그 부분이 100% 해결되는 것은 아니지만 critical한 상황은 모면하게 해준다고 생각합니다.

2. 방법론을 결정할 때도 도움이 됩니다. 즉 A라는 이슈를 해결하기 위해서 B,C에 대한 질문에 대한 답을 찾아야 한다면 B는 내부 매출 데이터로로 C는 인터뷰와 FGD를 병행해서 얻으면 되겠군 과 같은 판단이 수월해 지는 것이죠.

리서치 프로젝트에서 실제 제일 중요한 것은 목적달성을 위해 어떤 이슈에 대한 답을 찾아야 하는지? 그 답을 어떤 방법으로 얻을 것인지? 2가지라고 생각하는데 그 모두에 도움이 되는 것이죠.

하지만 마인드맵으로 정리를 하는 것이 쉽지는 않습니다. 저도 매번 정리할 때 마다 꽤 고통스럽습니다. 제가 워낙 활용지식이 없어서인지 모르겠지만 그래도 한번 정리를 해 두면 참 요긴하고 그렇게 정리한 프로젝트와 그렇지 않은 프로젝트의 결과가 차이가 나더군요.

간략하게 설명하면 우선 프로젝트의 목적을 적고 그 다음에 그 목적 달성을 해결해야 할 이슈를 정리합니다. 그리고 그 이슈를 해결해야 할 질문을 생각나는 대로 쭉 적습니다. 일단 쏟아내는 것에 집중합니다. 이때 저 같은 경우 MECE에 연연해 하지 않습니다. 로직트리에서는 MECE하게 정리하는 것을 굉장히 중요하게 여기는데요. 필수적으로 충족되어야 하는 조건이죠. 물론 최종 결과는 MECE하게 되야 하는 것은 맞지만 처음부터 MECE를 고려하게 되면 정리하는데 너무 스트레스를 받습니다. 그래서 일단 MECE는 개나 줘버리고^^ 머리 속의 내용을 잘 생각이 안 날 때까지 쏟아냅니다(이 과정은 목적과 이슈에 기반한 top-down 방식으로 정리를 하는 것이죠.)

다음으로는 해당 프로젝트 관련한 중요한 메일, 문서, 대행사 제안서 등을 보면서 떠오르는 것을 다시 한번 정리합니다. 분명 새롭게 떠오르는 아이디어들이 있으실 겁니다. 이 내용들을 또 넣습니다.(이건 bottom-up으로 정리하는 것이죠) 여기까지 진행하면 대부분의 것들은 일단 정리가 된 상태입니다. 적어도 중요한 부분에 대한 누락은 없게 된다고 봅니다.

이 다음에 목적달성을 위해 불필요한 이슈나 아이템들은 제거합니다. 만약 좀 애매한 것들은 표시만 해 둡니다.(애매한 것들은 이후 진행과정에서 리소스나 시간이 허락하면 파악해 보고 그렇지 않을 경우 우선순위를 미룹니다) 그 다음 이제 정교하게 MECE하게 다듬습니다. 이때 아이템이나 상위의 이슈가 합쳐지거나 어떤 아이템들은 A라는 이슈 하위에 있었는데 B라는 이슈 하위로 움직이기도 하고 이슈자제의 분류도 달라지기도 합니다. 여기까지 했다면 일단 목적 달성을 위한 이슈, 아이템 정리는 완료가 된 것입니다.

물론 프로젝트의 성격상 이후 상황에 따라 이슈가 변경되거나 추가되기도 하고 정성조사를 하고 정량조사를 할 경우 정성조사 후에 혹은 다른 어떤 데이터를 보다가 새로운 생각들이 생겨날 수 있습니다. 그때마다 마인드맵으로 정리한 이슈트리(저는 이렇게 정리된 set을 개인적으로 이슈트리라고 부릅니다)를 또 업데이트 합니다.

글로 설명을 하니 이해가 되실지 모르겠고 이 방법이 얼마나 좋은지? 효과적인지?는 모르겠습니다. 하지만 저는 꽤 많은 도움을 받고 있습니다. 어쩌면 중요한 것은 어떤 방법이든지 자신의 프로젝트에 관한 사고의 흐름을 하나의 프레임으로 정리하는 것인지도 모르겠습니다. 그런 관점에서 마인드맵을 사용하시면서 자신만의 방법을 만들어 보는 것도 좋다고 생각합니다.

어떤 마인드맵 프로그램이 좋지?라는 의문이 드실텐데요. 검색해 보면 많은 프로그램을 보실 수 있으실 겁니다. 취향에 맞게 선택하시면 되겠습니다.

참고포스트1: 인사이트에 대한 아주 개인적인 생각1

참고포스트2: 인사이트에 대한 아주 개인적인 생각2 문제 정의에 관하여

앞 선 2개의 포스트에서 인사이트에 대한 제 나름의 정의, 그리고 문제 정의에 대해서 이야기를 했는데요. 이번 포스트에서는 문제해결에 대해서 이야기를 하고자 합니다.

인사이트를 찾기 위해 수 많은 노력을 하고, 분석을 하고 또 하는 이유는 결국 문제해결을 하기 위함입니다. 결국 인사이트를 통해 문제를 명확하게 정의하고 그 문제를 가장 잘 해결할 수 있는 솔루션을 줄 수 있어야 의미가 있겠지요. 매번 그런 마음으로 문제를 대하지만 얼마나 좋은 솔루션들을 이야기했나 생각해보면 참으로 부끄럽기 짝이 없습니다. 하지만 그런 실패의 경험들 속에서 몇 가지의 유의사항(?), 팁들을 발견하게 되었습니다. 그 이야기를 좀 하고자 합니다.

1. 문제를 해결해야 할 실질적인 조직의 현황 파악이 필요함.

어떤 아이디어, 솔루션, 전략이라도 실행되지 않으면 아무 의미가 없습니다. 개념적으로 아무리 훌륭한 생각이라도 현실적으로 실행이 불가능하다면 그 또한 빛 좋은 개살구에 불과하죠. 그런 관점에서 솔루션이 실제 실행 조직의 현황에 비추어 봤을 때 실행이 가능한 것인지? 더 좋은 방안은 없는지 한번 정도는 고민이 필요합니다.

2. 실행의 최종적인 의사결정권한을 갖고 있는 key-player가 누구인지 파악하고 그에 대한 고려가 필요함.

대단히 현실적인 이야기인대요. 실제 실행에 있어서 key-player의 동의를 얻지 못하면 대다수가 지지하더라도 절대 현실화되기 힘듭니다. 그렇기 때문에 key-player가 누구인지? 그를 설득할 수 있게 솔루션을 다듬을 필요가 있습니다. 그의 생각과 취향에 맞추라는 말이 아닙니다. 설득의 논리를 더 튼실하게 만들라는 의미입니다.

3. 어떤 식으로 커뮤니케이션 할지 고려가 필요함.

내 머리 속에 아무리 좋은 것이 들어 있어도 이를 상대방에게 이해시키거나 설득시키지 못한 다면 아무 의미가 없습니다. 그것은 전적으로 커뮤니케이션에 달려 있습니다. 최적이라고 생각한 솔루션을 이해, 설득시키기 위해서 어떤 식으로 커뮤니케이션 할지 많은 고민이 필요합니다. 좀 오버해서 가슴으로 이해하지 못하는 것에 대해서 행동하는 사람은 많지 않습니다.

4. 현실적인 상황을 고려할 때 실행이 불가능한 부분은 없는지 검토가 필요함.

시간과 비용, 인력의 리소스를 무한정 투자한다면 불가능한 것은 없을지 모릅니다. 하지만 현실적으로 리소스는 한계가 있고, 가능하면 최소 투여로 최대의 효과를 얻어야겠지요. 그런 관점에서 아주 현실적인 시각으로 솔루션을 평가할 필요가 있습니다. 교과서적인 이상적인 이야기만을 하고 있지는 않은지 다시 한번 보는 것이죠.

5. 문제의 원인 전달에서 멈추지 않아야 하며 가능한 구체적인 실행방향과 우선순위를 던져야 함.

실제 문제를 해결하는 입장에서 가장 큰 관심은 문제의 원인은 부차적이 되고 결국 어떻게 문제를 해결해야 하냐에 집중됩니다. 그런 관점에서 문제가 이러하니 이 문제를 해결해야 합니다는 좀 무책임하다고 할 수 있습니다.(물론 이조차 쉬운 것은 아니지만요) 또한 거친 아이디어는 누구라도 던질 수 있습니다. 문제 해결이 큰 도움이 되지 않습니다. 가능하면 바로 적용할 수 있을 정도로 솔루션은 구체적이면 좋고 만약 그 부분이 불가능하다면 실행방향, 우선순위 정도는 이야기를 해 줄 수 있어야 합니다.

6. 문제해결방법을 적용했을 때 효과를 검증할 수 있는 추가적인 계획 수립.

솔루션을 제공했으면 그 소임을 다한 것이 아닙니다. 과연 그 솔루션이 효과가 있는지? 만약 실행되지 않는다면 어떤 문제가 있는지? 파악을 해야 합니다. 그 이유는 작게는 향후 좀 더 실행력이 담보된 솔루션을 도출하기 위해서, 크게는 해당 문제를 해결할 방법을 찾기 위해서 입니다. 도출한 솔루션도 해당 시점에서 가장 가능성 높다고 판단되는 하나의 안이지 완벽한 것이 아니기 때문입니다. 판단이 잘못되었거나 부족한 부분이 있다면 또 바로 잡아야 할 필요도 있는 것이죠.

이상이 제가 문제 해결 방법, 솔루션을 도출할 때 발견한 유의사항들입니다. 저도 이것들을 항상 챙기고 있지는 못합니다. 또 여러 현실적인 상황으로 인해서 포기하는 경우도 있고요. 하지만 항상 이러한 방향으로 접근하겠다는 노력을 계속적으로 하고, 현실적인 어려움을 하나 하나 해결해 가는 것이 필요합니다. 해본 사람만이 필요함을 알고 더 나은 방법을 찾기 때문입니다.

본 포스트는 Research Insight Team Blog에도 포스팅 됩니다.  

참고포스트: Insight에 대한 아주 개인적인 생각1

지난 번 포스트에서 인사이트에 대한 개인적인 정의를 했는데요. 솔직히 너무 확장한 감이 있습니다. 하지만 제 경험상 인사이트는 결국 문제 정의와 문제 해결의 수단으로서 기능해야 의미가 있더군요. 그런 관점에서 이해를 해주시면 좋겠네요.

이번 포스트에서는 그 연장선에서 문제 정의에 대해서 이야기를 좀 더 해볼까 합니다. 문제만 잘 정의를 해도 50%는 해결한 것이다 라고 많이 이야기 합니다. 하지만 저는 문제의 핵심을 진단하는 것은 문제 해결의 필수 조건이다 라고 생각합니다. 정확한 문제 정의 없이 문제 해결은 이루어질 수 없는 것이죠. 문제를 정의하는 데 있어서 아주 많은 이야기들이 있지만 제가 생각하는 몇 가지 중요한 점을 이야기 해보겠습니다.

1. 문제에 연결되어 있는 대상이 누구인지 파악한다.

문제가 발생하면 해당 문제는 수 많은 대상들과 연결되어 있습니다. 서비스나 제품이라면 해당 서비스나 제품을 중심으로 무수히 많은 소비자, 내부 조직, 인원, 그리고 프로세스 등등 유, 무형의 모든 것들과 연결이 되어 있죠. 대다수의 문제는 이런 관계에 문제가 생기거나 각각의 관계된 대상들이 본연의 역할을 다하지 못하거나, 잘못된 방법을 사용하고 있기 때문입니다. 따라서 문제에 연결되어 있는 대상이 누구인지 파악하는 것은 문제의 원인을 파악하는데 있어서 1차적으로 이루어져야 할 작업입니다. 만일 이 지점에서 중요한 대상의 누락이 발생하게 되면 문제의 원인을 파악하지 못할 수도 있습니다.

2. 해당 문제에 각각의 대상이 어떤 영향을 미치고 있는지 파악한다.

연결되어 있는 대상들은 각각의 역할이 다르고 그렇기 때문에 영향력이 다릅니다. 연결되어 있는 모든 대상이 문제 해결에 동일한 중요도를 갖는 것도 아닙니다. 중요도가 다르기 때문에 당연히 분석해야 할 우선순위도 달라지게 되는 것이죠. 대상의 영향력 분석을 통해서 영향력이 미약하거나 중요도가 낮은 대상은 분석에서 제외하기도 합니다.

3. 각각의 대상에 적합한 질문을 던지거나 적합한 방법으로 의견, 태도, 의도 등을 파악한다.

그런데 각각의 대상이 문제를 바라보는 시각, 문제에 영향을 미치는 모습이 다르기 때문에 이들의 정확한 정체를 파악해야 하는데요. 이를 위해서는 각각의 대상에 따라 적합한 방법이 필요합니다. 설문조사를 할지? 인터뷰를 할지? 아니면 내부의 데이터를 분석할지? 각각의 특성에 맞게 선택을 하게 되는 것이죠.

4. 수집된 데이터를 직접적으로 해석하지 말고 복합적으로 고려하거나 이면에 숨겨진 의미의 해석에 중점을 둬야 함.

어떤 질문에 대해서 1번이라고 응답한 사람이 몇%인지도 의미가 있지만 왜 그런 결과가 나왔는지?가 훨씬  중요합니다. 단순한 응답결과 데이터의 양적인 측면만 포커스를 맞추다 보면 데이터가 진정으로 이야기하는 의미를 놓칠 수가 있습니다. 다양한 형태의 분석과 많은 가설, 호기심 들이 필요한 순간이죠.

5. 문제를 해결해야 할 주체(조직, 인원, 상품, 서비스, 마케팅, 연구 개발 등)가 기간 동안 어떤 활동을 해왔는지 살펴보고 그 활동과 문제의 연관성을 살펴본다.

문제는 그냥 발생하지 않습니다. 분명 어떤 이유가 있고 그 이유는 누군가 행한 행위가 시작입니다. 그 누군가는 문제를 발생시킨 주범이기도 하지만 반대로 문제를 해결해야 할 주체이기도 합니다. 그런 관점에서 다양한 주체들의 기간의 활동을 살펴볼 필요가 있습니다. 그리고 활동과 데이터를 통해서 도출된 결과들을 연관 지어 보면 아주 중요한 문제 원인에 대한 스토리들을 발견할 수 있습니다.

6. 문제와 문제를 일으킨 대상, 문제를 해결해야 할 주체를 모두 고려해서 문제의 핵심, 인과관계를 도출한다.

그냥 단순하게 데이터를 통해 드러난 문제에만 집중하면 문제 정의가 좀 이상하게 되는 경우가 있습니다. 아주 거칠게 예를 하나 들어 보겠습니다. 어떤 서비스의 이탈이유가 개인 여유 시간이 없어져서 70% 가격이 너무 높아서 50%, 서비스를 기다리는 시간이 너무 길어서 40%라고 할 때 여유 시간이 없어져서가 가장 큰 문제니까 이게 핵심이다라고 생각하면 안 된다는 것이죠. 예외는 있겠으나 개인의 여유 시간을 더 늘려준다거나 여유시간이 없는데도 우리 서비스를 이용하게 한다는 것은 불가능에 가깝습니다. 따라서 현실적으로 봤을 때 대응할 수 있는 문제가 아니기 때문에 문제의 핵심이 아니죠. 가격이 너무 높아서가 다음이니 가격 조정이 필요하다로 문제를 정의하는 것도 문제입니다. 가격은 굉장히 많은 이슈와 연관이 되어 있기 때문입니다. 서비스를 제공하는데 소요되는 비용, 이익을 얻기 위한 최저 가격, 가격 1단위를 내리는데 늘어나는 수요에 따른 적합한 수준의 가격 설정 등과 같은 굉장히 중요하고도 복잡한 것들과 연결되기 때문에 가격 수준의 조정이 가능한지? 가능하다면 어느 수준까지 할지도 분석을 해야 해당 사항이 문제의 핵심이라고 말 할 수 있게 됩니다. 서비스를 기다리는 시간이 너무 길어서도 서비스 제공의 flow를 모두 살펴봐야 문제의 핵심을 비로소 볼 수 있게 됩니다.

이처럼 표면적인 문제 이면에 연결되어 있는 모든 것들을 모두 고려 할 때 문제의 핵심이 도출되게 됩니다.

실제 문제 정의는 어찌 보면 가능한 모든 경우의 수를 열어두고 통합적으로 밑바닥까지 분석한다가 답이라고 할 수 있습니다. 그리고 스마트한 방법의 선택으로 이 맨땅의 헤딩스러운 일을 조금은 쉽게, 적은 리소스를 들여서 하는 것이 내공이고 요령이겠죠.

문제 정의에 대한 개인적인 의견은 이 정도로 정리하고 다음에는 문제 해결 방법의 도출에 대해서 이야기를 해보도록 하겠습니다.

이 포스트는 Research Insight Mavens Team Blog에도 포스팅 됩니다.