문제해결 프로세스

전체 플로우

요건정의➡설계➡실장➡검증

요건정의 : 문제 인식, 문제 정의, 목표 구체화, 문제의 유형설정

요건정의에서는 문제의 스코프를 명확히 정하고, 수치화하여 구체적인 목표를 수립하는 단계입니다. 가령, 이익을 2배 올리고 싶다는 문제에서는 기간은 1년간인지, 2년간인지, 이익을 2배 상승시킴에 있어서 매출과 코스트의 비중은 제시되었는지 등을 파악하여, 매출을 2.5배 상승시키고 코스트는 1.5배만 상승시켜 이익을 2배로 만든다 라는 구체적인 목표를 수립할 수 있게 됩니다.

일단 Input, Input, Input..!: 모든 어프로치의 첫 발

SVE리더 파트너인 시노하라상과 히가시상에게 새로운 문제에 대한 어프로치를 어떻게 할 것인지에 대해 질문 했을 때, 그들이 가장 먼저 언급했던 것이 Input 이었습니다. 최근 잡 인터뷰에서 그들이 원하는 질문에 대한 답을 PT로 발표할 것을 요구했는데, 이것을 하나의 프로젝트라는 관점에서 보면, 역시나 Input이 무엇보다 중요하다는 경험을 하게 되었습니다.
　
(거의 대부분이 open research가 되겠지만) 오픈 리서치 이든, 레포트를 찾아 보든, 전문가에게 면담을 요청하든, 해당 요건에 대해서 먼저 Input이 없으면 그 요건을 제대로 이해하는 것 조차 불가능합니다.
　
따라서, 해당 요건에 대한 목표를 명확히 할 수 있고, 요건을 만족시키는 설계가 머리 속에 그려질 정도로 충분한 Input을 먼저 수집하는 것이 좋습니다.
　
Input을 획득하기 위한 리서치방법으로는 다음의 포스트를 참고하길 바랍니다.

문제 인식, 문제의 정의, 목표의 구체화

문제란 목표와 현상의 GAP이므로, 목표와 현상을 명확히 해야 문제가 무엇인지 인식할 수 있습니다.

1. 목표의 구체화(목표 = 요건)
   목표가 없으면 문제가 존재할 수 없습니다. 목표를 명확히 하는 요령 중 하나는 주어진 과제를 목적형으로 바꾸어 보는 것입니다. 특히 실전에서는 다듬어지지 않은 워딩이 등장하여 문제를 해결하는데에 혼란을 줄때가 많습니다. 때문에 목적을 명확히 한 후 목적을 띈 워딩으로 수정하면 문제의 정의에 도움이 됩니다. 가령, 헤드쿼터를 어느 지역에 세울지 에 대한 문제는 목표가 분명하지 않습니다. 이를 시장에 대한 접근성이 좋고, 인프라가 건실한 곳에 해드쿼터를 세우기 위해서는 어느지역이 좋을지 라는 명확한 워딩으로 고치면 이후 문제해결 어프로치에 큰 도움이 됩니다.목표가 어긋나면, 목표를 중심으로 세워둔 설계도 모두 변경해야 하므로, 문제해결에 있어서 목표설정이 가장 중요한 단계임을 반드시 인식해주세요.
2. 목표에서 등장하는 각 정의 들을 더욱 명확히 할 필요가 있습니다. 위의 예에서는, 시장에 대한 접근성이 좋다는 건 어떤 기준인지 어떤 의미인지, 또한 인프라가 건실하다는건 어떤 의미인지 어떤 기준인지 명확히 해야만 구체적인 목표를 세울 수가 있고, 일이 진행되는데 어긋남이 없습니다.
3. 현재 상태 파악 　
4. 목표의 상위 배경(목적)을 고려하기
   why 트리(이후 현상분석에서 등장하는 키워드)를 통해 목표의 상위 배경인 목적을 고려해봅니다. 목적을 고려해 봄으로써 사고의 깊이를 깊게 이끌어갈 수 있고, 근본적인 요건을 고려할 수 있으므로 어긋난 해결책을 초기 단계에서 배제하기 쉬워집니다.
   　
   기존 상품의 새로운 상품 라인 개발이라는 목표의 목적을 생각해봅니다. 클라이언트와의 미팅결과, 새로운 상품 라인 개발의 목적은 시장에서의 자사 영향력 강화입니다. 하지만, 시장에서의 자사 영향력을 강화시키기 위해서는 새로운 상품라인의 개발이 아닌 다른 방법이 더 효율적일 수 있습니다.가령 인수합병처럼요. 이처럼, 클라이언트가 제시하는 목표를 명확히 하기 이전에 목적을 파악함으로써 목표 자체가 타당한 것인지 판단하고 올바른 방향을 제시할 수 있게 됩니다.

문제의 유형설정

앞으로 마주치는 모든 문제는 다음 세 가지 중의 하나에 속하게 됩니다.

1. 발생형 문제
2. 탐생형 문제
3. 설정형 문제

제시된 문제가 어떤 유형의 문제인지에 따라 문제해결을 위한 어프로치가 달라집니다.

1. (optional)탐색형 문제를 발생형 문제로 바꾸어 생각해보기
   생각을 편하게 할 수 있는 하나의 팁정도로 생각해두세요.「영어를 말할 수 있기 위해서는」이라는 문제는 「영어를 말할 수 없는 이유는」이라고 생각해 보는 것처럼, 어프로치하기 힘든 탐색형 문제를 오프로치하기 쉬운 발생형 문제로 바꾸어 생각해보는 것입니다. 하지만, 발생형 문제의 어프로치는 탐색형 문제의 어프로치보다 생각의 범위가 좁기 때문에 생각의 누출이 발생할 수 있다는 점에 매우 유의하여야 합니다.

설계

설계에서는 요건정의에서 설정한 구체적인 목표를 달성하기 위해 어떠한 어프로치로 문제해결까지 나아갈 것인지 정하는 단계입니다. 아래의 현상분석은 목표를 여러 가지 방면으로 모델화해 어프로치에 대한 힌트를 얻는 방법입니다. 　

본격적 설계에 들어가기 전 가장 먼저 게임의 전체적인 판을 이해하기(전략적 사고): 거시적 변수의 이해부터 미시적 변수의 이해까지

문제해결에는 다양한 변수들이 관여합니다. 예를 들어, 기업의 매출이라는 문제해결에는 어떠한 변수들이 관련되어 있는지 살펴볼까요? 구체적인 예를 위해, A라는 자동차 회사의 매출을 생각해 보겠습니다.
　
A회사의 매출을 구조화하면, 아래와 같습니다

A회사의 매출 = 신규고객매출 + 기존고객매출
1. 신규고객매출 = 신규고객 * 단가
= (전체인구 * A사 자동차미소유율 * A사 자동차구매율 * 구매대수) * 단가

2. 기존고객매출 = 기존고객 중 재구매 고객수 * 단가
= (전체인구 * A사 자동차소유율)/내용년수 * A사 자동차재구매율 * 구매대수) * 단가

　
이때 미시적인 관점으로 A사 자동차구매율 A사 자동차재구매율에 영향을 미치는 변수를 생각하면, 'A사 제품은 차량 종류' 'B사 자동차' 'A사의 마케팅'와 같은 것을 직관적으로 생각해 낼 수 있겠네요. 하지만 이게 전부일까요?
　
다음의 기업문제 해결에 있어서 가장 기본이 되는 5C-extension을 봅시다.(기존 5C는 company, clinet, competition, channel, cost이지만 그외의 요소들을 개인적으로 확장했습니다.) 　

직관적으로 언급했던, 'A사 제품은 차량 종류' 'B사 자동차' 'A사의 마케팅'과 같은 요소는 경쟁요소에 의한 변수와, 고객요소에 의한 변수밖에 다루지 않고 있습니다. 매우 미시적인 관점의 분석입니다. 하지만, 5C-extension과 같은, 거시적인 판을 사전에 이해하고 있었다면, A사 자동차구매율 A사 자동차재구매율에 영향을 미치는 변수를 아래와 같이 더욱 폭넓게 생각하고, 각 변수에 따른 가설들을 세울 수 있었을 것입니다. 거시적인 틀을 파악하고 거시적인 시야에서 점점 미시적인 시야로 옮겨가는 사고를 전략전 사고라고 합니다.

1. International external env FACTORs

2. Domestic external env FACTORs

3. Alternative FACTORs

4. Complementary FACTORs

5. Competitor FACTORs
   - 경쟁 기업의 차별화

6. Client FACTORs
   - 가격전략
   - 유통채널
   - UX
   - 성장전략(CLMMT)
   - 차별화
   - 회사 이미지, 고객 충성도

7. Suplier FACTORs
   - 교섭력

8. Company FACTORs
   - 밸류체인
   - 7S

이는 기업의 문제해결 뿐만 아니라 어떤 문제에 대해 어프로치할 때도 마찬가지 입니다. 예를 들어, 해외로 취직을 할지 말지에 관한 개인의 문제를 해결할 때도 전체적인 판을 거시적으로 파악하고 문제해결에 대한 설계 페이즈에 들어가는 것이 합당합니다.

해외로 취직을 할지 말지를 결정하는데, 단순히 일적인 요소 여자친구만을 고려하면 생각치 못한 리스크와 마주할 가능성이 있습니다. 국내 외부 환경과 국외 외부 환경이 자신의 결정에 어떠한 영향을 미치는 변수일지도 함께 고려해야 리스크 미리 인지하고 대응책을 준비할 수 있습니다.

설계 단계에서 INPUT을 활용하기

어떤 문제든 문제를 해결하기 위해 도움이 될만한 INPUT이 존재합니다. 아무것도 없이 문제를 해결하라는 태스크는 잘 없습니다. 참고할만한 자료들을 몇 개 주고 시작하죠. 설계를 한 뒤에는 설계의 각 페이즈에서 설계대로 문제를 해결하기 위해서는 어떠한 자료들이 필요한지가늠할 수 있게 되는데요. 설계대로 문제를 해결하기 위해서 INPUT이 어떻게 활용할 수 있을지 고려해야 합니다. 멀쩡히 주어진 기회(자료)들을 그냥 버리고 가기에 너무 아까우니까요.
　
반대로 INPUT이 반드시 문제해결에 필요한 정보라는 전제가 있다면, INPUT에 맞추어 설계를 해 나가는 것도 하나의 방법입니다.

問題：CMOのM&Aコストはいくらで適正なのか？

# 定義
- 適正というのはどのぐらいの数値を意味するのか？
- EVがほしいのか、EBITDA*7~10倍がほしいのか？

# アプローチ
-Inputデータ
　- 製薬会社のCMO利用率：30％
　- 対象企業のシェア：20％
　- 対象企業のEBIT率：17％
　- CMO業界のEV/EBITDA Multiple：4.2

-設計
　-EVを求める
　-EV＝ターゲット企業のEBITDA * CMO市場のEV/EBITDA Multiple
 　　➡INPUT活用可能

①EBITDA＝EBIT（営業利益）-償却額

현상분석

현상분석이 반드시 필요한건 아니다

현상분석이란 문제에 대한 해결 방법을 마련하기 전에 과제를 여러각도로 분석하여 논리적인 문제해결 방안을 이끌어 내도록 돕는 방법입니다. 본 포스트에서는 과제를 why, what, 5W1H로 분석할 것입니다.
　
문제해결 방안에는 대표적으로 직관적 문제해결 계획적 문제해결 분석적 문제해결이 존재합니다. 참고이번 포스트에서 설명하는 문제해결이란 일반적으로 분석적 문제해결을 가르킵니다. 하지만, 분석적 문제해결이 항상 옳은 옵션은 아닙니다. 경험을 통한 직관적인 문제해결로 일일이 분석하지 않아도 해결방안을 마련할 수 있는 케이스도 존재하기 때문입니다. 예를 들어 aws ec2서버를 만들어달라는 과제를 받습니다. aws에 능숙한 사람이라면 굳이 과제를 현상분석하지 않아도 다음과 같은 해결책이 머리속에 자리잡을 것입니다.

 음, aws ec2 서버는 뭐 많이 세워봤어.
 1. 일단 aws에서 프로젝트 아이디로 로그인해서
 2. ec2 콘솔을 켜야지
 3. 인스턴스를 세울 때, 이미지 파일을 사용할까 스냅샷을 사용할까 처음부터 세울까? 이 부분은 확인해봐야겠네
 4. 인스턴스 스펙은 어떻게하지? 어느정도 크기의 cpn mem volume으로 세우라는 걸까?
 5. 네트워크는? 어떤 vpn 어떤 subnet에 세워야할까? 시큐리티 팀과 상의 해봐야겠어.

aws ec2서버를 세우는 과제에 생각보다 꽤나 많은 생각들이 필요하긴 하군요. 여하튼 aws에 익숙해져 있는 사람이라면 위와 같은 해결방안을 굳이 세세하게 현상분석하지 않아도 경험을 통해 직관적으로 알 수 있게 됩니다. 이것이 직관적 문제해결 입니다.
　
하지만 aws ec2서버를 처음 접해보는 사람은 어떨까요? 누구하나 알려주는 사람도 없다면 그 사람에게 이것은 꽤나 복잡한 과제일 것입니다. aws가 무엇인지, ec2가 무엇인지, 그것을 구성하는 것은 무엇인지, 왜 그렇게 해야하는지 등 꼼꼼한 현상분석과 가설설정, 검증, 자료조사 뒤에야 문제 해결방안을 마련할 수 있겠죠. 이것은 분석적 문제해결입니다.
　
결론은 문제 해결을 위해 반드시 분석적 문제해결만을 사용할 필요는 없다는 것입니다. 과제에 대해 충분한 경험과 배경지식의 Pool이 있다면 직관적 문제해결도 시간과 비용을 절약할 수 있는 훌륭한 문제해결법이라는 것입니다. 하지만 직관적 문제해결을 시행할 때 주의해야 할 점은 문제해결이란 상황에 변할 수 있는 리스크가 존재하기 때문에, 직관적 경험을 근거로 세운 플랜에 대해서는 정말 타당한 인과관계인지 검증을 해야한다는 점입니다!

경영전략에는 현상분석과 해결책을 하나로 묶은 시스템이 있다?

경영전략에서 많이 사용하는 현상분석과 그에 따른 어프로치(설계)를 제시하는 시스템이 존재합니다. 이를 IB케이스 시스템이라고 합니다. 경영전략에서 자주 등장하는 아래의 토픽에 따라, IB케이스 시스템에서는 각 토픽에 어떤 식으로 어프로치를 하여 문제를 해결할 것인지 제시하고 있습니다. 구체적인 내용은 「戦略コンサルティング・ファームの面接試験：CASE IN POINT」 이라는 책을 참고해주세요.

- 시규시장참입
- 업계분석
- M&A분석
   - M&A적정 가격 설정(EV/EBITDA, EBITDA* 7~10배)
   - M&A 타당성 분석(=장래 성장률 분석)
- 신제품발매
- 가격전략
- 성장전략
- 기업/신규사업 타당성 분석
- 경쟁기업에 대한 대응책
- 매출 증가
- 코스트 삭감
- 이익 증가
- 턴어라운드
- 수요공급 균형전략

WHAT트리(feat.구조화, Segment화)

WHAT트리는 그냥 생각하기에는 막막한 탐색형, 설정형 문제를 해결하는데 도움이 됩니다. 한번에 생각하기 어려운 문제를 의미있는 기준에 의해 나누어 생각할 수 있기 때문입니다.
　
WHAT트리가 탐색형, 설정형 문제를 해결하는데 가장 유용한 도구이기는 하지만, 어떠한 문제든 WHY트리, WHAT트리를 모두 구성해보는 것이 생각의 누출을 막기때문에 훨씬 유리하다는 걸 기억해주세요.

WHAT트리의 핵심: 구조화

WHAT 트리는 구조화를 통해서 작성할 수 있습니다. 구조화란 한번에 정복하기 힘든 문제가 있을때, 이를 세부적인 부분까지 나누어서 분할한 뒤 각각의 문제를 해결하여 전체적인 문제해결을 도모하는 것입니다. (각개격파하기!)
　
역시나 정의로만 보면 무슨 소리인지 모르겠습니다. 예를 통해 보도록 하겠습니다. 다음과 같은 발생형 문제를 생각해보겠습니다. 스타벅스의 1일매출을 15퍼센트 늘이기 위해서는? 이라는 과제가 있습니다. 자, 어떤 해결방법들을 생각해낼 수 있을까요? 읽기를 멈추고 생각해보세요.
　
막막합니다 역시..곧바로 머리속에 드는 생각은 '호객을 열심히 한다' '신메뉴를 개발한다' '커피 값을 올린다' 정도가 되겠네요. WHAT트리나 WHY트리와 같은 분석도구 없이는 직관적인 해결방법에 의존하게 됩니다. 하지만 직관적인 해결방법은 생각의 누출이 많고 논리성을 보장하기 어렵습니다.
　
그럼 어떻게 접근해야할까요?
　
먼저 스타벅스의 1일 매출을 구조화 해보겠습니다.

스타벅스 1일 매출 = 구매자수 * 1인당 평균 구매액
= [판매형태에 따라서 구조화] (테이크아웃하는 구매자수 * 1인당 평균 구매액) + (점포내 구매자수 * 1인당 평균 구매액)
= [점포내 구매자수를 더 세분하게 구조화] (테이크아웃하는 구매자수 * 1인당 평균 구매액) + (업소내의 좌석개수 * 시간당 가동율 * 시간당 회전율) * 1인당 평균 구매액

- 테이크 아웃하는 1인당 평균 구매액을 늘이기 위해 : 테이크아웃하는 고객에 대해서 할인 행사를 시행해 더 많이 사가게 하도록 유도한다.
- 업소내의 좌석개수를 늘이기 위해 : 카페내의 빈공간을 효율적으로 사용하고 stand-bar나 카운터석을 늘인다(고객의 만족도가 하락하기 때문에 이후의 검증 과정에서 폐기될 해결방책이긴 하겠지만..)
- 시간당 회전율을 높이기 위해 : 고풍스럽지만 딱딱한 의자를 준비하여 오래 앉아 있지 못하게 한다.
- 1인당 평균 구매액을 늘이기 위해 : 커피 뿐만 아니라 베이커리나 셀러드나 샌드위치와 같은 간단한 식사류를 준비하여 함께 구매하도록 유도한다.

　
자, 그럼 이번에는 아까보다 생각하기가 훨신 수월해졌다는걸 느낄 수 있겠죠? 문제를 막연히 하나의 큰 덩어리로 보는 것이 아니라 조그만한 덩어리로 쪼개고 보면, 비교적 덜 부담스러운 조그만한 덩어리들에 대해서 각각의 해결책에 어프로치 할 수 있게 됩니다. 또한 각 구조화에서는 MESE가 적용되어 있기 때문에, 생각의 누출이 없고 논리성을 보장할 수 있습니다.
　
구조화에는 다음의 네 가지 방법이 존재합니다. 이를 통해 상황별로 유연하게 대상을 구조화할 수 있습니다.

1. 사칙연산을 통한 구조화
2. 축을 통한 구조화
3. MESE프레임워크를 통한 구조화
4. 프로세스 분석을 통한 구조화

1. 사칙연산을 통한 구조화

수식으로 구조화를 시행했을 때 구조화가 수월합니다. 수식으로 표현했을 때는 변수 간의 +-÷× 관계를 명확히 파악할 수 있습니다. 또한, 하나의 변수를 더 세분화된 하위 변수로 나누기 쉬워집니다.

-스타벅스의 갯수(존재어프로치) = 도시의 역수 * 역당 스타벅스 개수 + 도시가 아닌 곳의 역수 * 역당 스타벅스 개수

-도쿄역 유동인구수 = 열차이용객수 * 환승률 = ((한차량 정원수 * 가동률 * 한 전차의 전체차량 수) * 시간당열차대수 * 운용시간 * 선개수 * 환승률) 

-칼로리 축척량 =   肥満=カロリーIn－カロリーOut
    ・カロリ-In　=　摂取カロリー＊カロリー吸収率
          =（食事回数＊一回当たり量＊量当たりカロリー）＊カロリー吸収率
    ・カロリ-Out　=　基本代謝＋基本代謝外
    　   =　基本代謝＋（通常運動＋特別運動）

-고층건물 건설비 = 工事費＝土地＋(1階当たり工事費*階数)*高層による加重値＝土地＋((人件費＋原材料費＋機械レンタル費)*階数)*高層による加重値

2. 축을 통한 구조화

시스템의 경우 구성요소를 물리적/논리적 기준으로 명확하게 구분할 수 있지만, 비즈니스의 경우 어떤 축으로 구조화 하느냐에 따라 구성요소가 달라집니다. 　

# 소비자 구조화
age sex time area sku channel EL E/N busi natl

# 시장 구조화
valueChain sku client-type

프로그래밍의 예: 네트워크의 구성-> ec2, elb, subnet, vpc...  
비즈니스의 예: 회사의 구성-> 
   (부서를 기준으로) 인사부, 법무부, 개발부, 영업부.. 
   (자본을 기준으로) 부채, 누적 자본...

따라서, 의미 있는 축(기준) 을 선정하여야 합니다. 가령, 맥도날드 점포의 일일 매출 확대라는 과제가 있을 때 이를 해결하기 위한 현상분석으로 점포의 매출을 WHAT트리(구조화작업)로 분해합니다. 매출은 객수 * 객단가으로 나뉠 수 있습니다. 이때 객수를 시간대, 나이대, 성별이라는 축으로 나누는 것은 의미가 있지만 구매자가 입은 옷색깔, 구매자의 안경 착용여부 라는 축으로 나누는 것은 의미가 없습니다.
　
그렇다면 축설정은 어떻게 하면 의미가 있는 것일까요? 축설정이 의미가 있기 위해서는, 축설정과 문제의 목표가 타당한 인과관계인가를 증명해야 합니다. 위의 맥도날드 매출 확대의 예에서 시간대나 나이대가 의미있는 축이 될 수 있는 이유는 시간대 나이대라는 축에 의해 매출에 영향을 미칠 수 있기 때문입니다. 하지만 구매자의 안경 착용여부가 매출과 관련이 있다는 인과관계는 납득하기 어렵습니다.
　
또한 복수개의 축설정을 통해 정확도가 높은 구조화를 이루어 낼 수 있습니다. 위의 예에서와 같이, 고객을 시간대라는 하나의 축으로만 나누는 것보다 시간대와 나이대라는 복수의 축으로 나눌 경우 더 정확도가 높은 결과물을 얻어낼 수 있습니다.

3. MESE프레임워크를 통한 구조화

위에서 언급한대로 비즈니스 사이드는 구조화가 축의 설정에 따라 달라지므로 축설정이 중요합니다. 그런데 문제는 대상에 대한 배경지식이 존재하지 않는 이상 어떤 의미있는 축을 선정할지 자체가 굉장히 까다롭습니다. 이를 돕기 위한 것이 MESE 프레임워크입니다. 일반적으로 사용되는 의미있는 축을 그때그때 대입해 사용할 수 있게됩니다.
　
프레임워크는 이미 MESE화 되어 있으므로 문제의 구조화에 있어 큰 도움이 됩니다. ppt자료를 만들때 레퍼런스가 있고 없고의 차이를 크게 경험해봤을 것입니다. 레퍼런스는 요건에 따라 완벽하지는 않지만 사고에 큰 도움이 됩니다. 축의 프레임워크는 이러한 레퍼런스와 같습니다. 혹은 개발 경험이 있으신 분들은 외부 라이브러리를 사용하는 것이 얼마나 편리한지 아실 것입니다. 프레임워크는 외부 라이브러리를 사용하는 것과 같습니다. 보장된 로직을 사용함으로써 나의 부담을 줄이는 것이죠.

긍정적/부정적
내부/외부
온/오프
개인/환경
물리적/정신적
의식적/무의식적
공급/수요
사람/물건/돈/정보
연령/성별
사회인/학생
시각/청각/미각/촉각/후각
개인/법인
신규/기존
프로덕트/서비스
가상/실제
사적/공적
질/양
4p(product, price,place,promotion)
AIDMA
3C

예) 개인의 수입을 구조화면?
└── Stock  
        └── 有形資産売却  
        └── 無形資産売却  
└── Flow  
        └── 支出  
                └── 変動費  
                └── 固定費  
        └── 収入  
                └── 他力  
                        └── 金借りる  
                        └── 金もらう  
                └── 自力  
                        └── 仕事する  
                                └── 仕事もらう  
                                └── 仕事作る  
                        └── 仕事しない：株式・FXなど

예) 정체에 영향을 미치는 변수를 구조화하면?
일시적
    └── 하드웨어
                    └── 눈,비 등 기상
                    └── 교통사고
                    └── 도로공사
    └── 소프트웨어
                    └── 팬텀정체현상

비일시적
    └── 하드웨어
                     └── 도로상태
                     └── 도로수(병목현상)
    └── 소프트웨어
                      └── 교통체계(신호체계, 차선이용 제한등)

4. 프로세스 분석을 통한 구조화

매출은 객수*단가 = 인구*선택률*1인당구매개수*단가와 같이 구조화 될 수 있습니다. 웹어플리케이션은 레이어 라는 축으로 구조화하면 DB, 서버, 클라이언트 로 구조화 될 수 있습니다. 그렇다면 다음으로 승진이라는 개념은 어떻게 구조화할 수 있을까요?
　
좀 막막합니다. 승진이라는 개념은 한 시점에 발생하는 STOCK개념이 아니라 시간적 흐름에 의해 발생하는 FLOW개념이다보니 이를 STOCK 요소로 분해하려는 시도에서 머리가 말을 듣지 않는 것입니다.
　
승진은 FLOW이기 때문에, 그 요소를 분해함에 있어서도 시간적 흐름에 따라 분해하면 됩니다. 이를 고객 여정 분석(customer journey analysis)라고 합니다. 즉, 고객 여정 분석에 따르면 승진이라는 flow는 퍼포먼스 - 인사평가 - 인사권한자 승인 - 인사적용의 흐름으로 구성됩니다.
　
다른예로는, 엘리베이터의 사용을 편리하게 하기 위해서는, 웹사이트의 이용을 편리하게 하기 위해서는, 보조금 제도의 리스크 시이레를 구조화하면 과 같은 flow의 과제를 분석할 시 프로세스 분석은 유효하게 사용됩니다.
　
시간적 FLOW와 STOCK의 구분이 어렵다면, 구조화의 대상이 동사이면 FLOW, 명사이면 STOCK이라고 생각해보세요.

* 고객의 웹사이트 여정분석
①브라우저를 켠다
②할일을 한다
③광고에 노출된다
④광고를 클릭한다
⑤클라이언트의 웹사이트에 접속한다
⑥사이트를 둘러본다
⑦마음에 드는 것을 발견한다
⑧타사와 가격을 비교한다
⑨구매를 결정한다
⑩쇼핑카트에 담는다
⑪결제한다
⑫구매완료
⑬배송을 기다린다
⑭배송완료

* 해외 공장에서 생산한 소화기의 시이레 여정분석
①배에 실는다
②배로 나른다
③항구에 도착한다
④검사한다
⑤배에서 짐을 내린다
⑥차나 기차에 짐을 실는다
⑦창고까지 운송한다
⑧창고에 도착한다
⑨운송수단에서 창고로 짐을 옮긴다
⑩재고를 체크한다

* 고객의 엘리베이터 이용의 여정분석
①엘리베이터가 어딨는지 찾는다
②엘리베이터 앞까지 간다
③엘리베이터를 기다린다
④사람들이 타고내릴 때까지 기다린다
⑤엘리베이터에 탄다
⑥목적지 층을 누른다
⑦기다린다(중간중간에 사람들이 들락날락한다)
⑧내린다
⑨목적지까지 간다

구조화를 위한 팁

• MESE
  내용 생략 　
• 귀납적 축설정
  축의 설정에 어려움을 겪는 문제라면, 귀납적 인수분해를 사용할 수 있습니다. 귀납적 인수분해란, 축을 생각하기전 머리속에서 떠오르는 구성요소들을 먼저 생각해, 그 구성요소들의 분류에 따라 축을 역으로 설정해 나가는 것입니다. MESE를 만족하지 않는 축이 설정될 리스크가 존재하지만, 축을 설정하는 것보다 구성요소를 생각해내는 것이 비교적 쉬우므로 생각이 막혔을 때는 도움이 될 수 있습니다. 　
• 여러방면으로 축설정을 재실행 　

What트리와 시스템개발

개발을 해보신 분이 아니라면 이게 뜬금없이 왠 개발 이야기 인지 의아해하실 분이 있을 실 겁니다. 저는 IT컨설턴트이기 때문에, 컨설턴트적인 생각을 해야할 뿐만 아니라, 개발도 하고 있어요. 때문에 문제해결법을 생각할 때, 일반적인 전략/기획 문제해결법 뿐만아니라 그 방법이 소프트웨어 개발을 할 때도 확장성있게 사용할 수 있는 프레임워크인지 확인합니다. What트리는 시스템 개발을 할 때도 매우 유용하게 상용됩니다. 물론 트리의 생김새는 다르지만, 결국 본질은 같습니다.
　
개발을 해보신 경험이 있으신 분이라면, 네트워크 설계도나 시컨스 설계도를 보신분이 계실겁니다. 네트워크 설계도는 막연하게 느껴지는 '데이터 흐름'이라는 것을 데이터가 어떤 네트워크의 리소스를 통해 움직이는 지를 보여주는 그림입니다. 이는 네트워크라는 키워드를 (예를 들어) api gateway, ec2, rds, kinesis 등의 리소스로 인수분해하여 나타낸 것이므로, 생김새는 what트리와 다를지 모르지만 인수분해라는 시점에서 그 본질은 같습니다.

　
또한 조금 더 세부적인 소프트웨어의 흐름을 보자면 시컨스 설계도가 있겠군요. 설계자의 의도에 따라 굉장히 세부적으로 설계도를 그릴지(파일단위), 마이크로서비스 단위로 설계도를 그릴지 생각을 한후 데이터의 흐름을 기재하는 방법입니다. 이 또한, 데이터의 흐름이라는 추상적인 개념을 구체적인 리소스들, 파일들, 알고리즘들로 인수분해하여 생각하는 방법이기 때문에 what트리와 본질이 같습니다. 어플리케이션을 개발하는 프레임워크를 조금더 구체적으로 알고싶다면링크

　
What트리는 시스템을 구축할 때도 매우 도움이되는 방법입니다.

WHY트리

WHY트리는 원인분석이 요구되는 발생형 문제일 경우 유용하게 사용될 수 있습니다. WHY트리는 인과관계의 파악이 핵심입니다. 인과관계에 관해서는 별도의 포스트에서 구체적으로 다루고 있습니다. 다음의 링크에서 확인해주세요.

WHY트리를 위한 팁

• MESE
• 프레임워크 사용하기
• 원인을 구조화하기
• 거시적 요소부터 미시적인 요소까지
  기업의 선택률과 시장의 성장률에 영향을 미치는 변수는?
• 1. International external env FACTORs 2. Domestic external env FACTORs 3. Alternative FACTORs 4. Complementary FACTORs 5. Competitor FACTORs - 경쟁 기업의 차별화 6. Client FACTORs - 가격전략 - 유통채널 - UX - 성장전략(CLMMT) - 차별화 - 회사 이미지, 고객 충성도 7. Suplier FACTORs - 교섭력 8. Company FACTORs - 밸류체인 - 7S
• 몇 퍼센트 짜리 인과관계일까?
  각 인과관계의 타당성은 수치로써 그 관계가 표현됩니다. 위의 그림에 의하면 배송시스템문제 -> 배송지연문제 라는 인과관계로 표시되어 있지만, 정말 저러한 인과관계가 도출되는 것이 타당한지를 매 포인터 마다 고려해 보는 것입니다. 각 노드 간의 인과관계를 수치로 표현하여 구체화 할 수 있습니다. 수치는 물론 가설이지만, 수치를 통해 인과관계를 표현함으로써 논리적 비약을 방지할 수 있습니다.
• 예1. 바람이 불면 통장사가 잘된다?? 바람이 분다 -> 50% 모래먼지가 날린다 -> 1% 눈에 모래가 들어간다 -> 0.1% 실명하여 맹인이 된다 -> 5% 맹인이 샤미센을 연주한다 -> 100% 샤미센 수요가 증가한다 -> 100% 샤미센을 만들 고양이 가죽이 필요하다 ->100% 고양이가 줄어든다 -> 10% 쥐가 증가한다 -> 50% 쥐가 통을 갉아먹는다 -> 10% 통장사가 잘된다 0.5 * 0.05 * 0.001 * 0.05 * 1 * 1 * 1 * 0.1 * 0.5 * 0.1 = 약 10억분에 1확률 따라서, 바람이 불면 통장사가 잘된다라는 가설은 논리적 비약 예2. 기준금리가 올리가면 부동산 가격이 하락한다? 기준금리가 상승한다 -> 100% 시장금리가 상승한다 -> 100% 대출금리가 상승한다 -> 90% 대출받아 부동산을 구매하는 수요가 감소한다 -> 80% 부동산 수요가 하락한다 -> 100% 부동산 가격이 하락한다 1 * 1 * 0.9 * 0.8 * 1 = 0.72 따라서 기준금리가 상승하면 부동산 가격이 하락한다는 타당한 인과관계
• 핵심적인 원인이 보일때까지 계속 파고들기
  발생형 문제 해결의 핵심은 원인 분석입니다. 피상적인 원인 분석부터 시작하여 근본적인 원인 분석으로 이어나갑니다. 근본적인 원인의 분석은 원인에 대한 원인의 규명을 반복하여 접근합니다. 이렇게 나뉘어진 원인의 계층에서 각 층의 원인은 피상적이든 근본적이든 해결책 마련의 근거가 됩니다. 이때 원인 분석은 MESE의 의해서 종류가 나뉘어지면 좋지만(생각이 누출을 막기 위해), 이러한 구분보다 중요한 것은 근본적 원인을 밝혀내는 것이라는 방향성을 유지하는 것입니다.
• 인과관계가 충분히 세부적으로 step by step을 이루고 있는지 검증
  발생형 문제의 원인을 파악해 나갈 때, 인과관계의 粒度가 충분히 구체적인지 고려해야합니다. 예를 들어, 「꽃가루 알레르기 환자를 줄이기 위해서는」이라는 문제에서, 「꽃가루 -> 알레르기 발생」 이라는 인과관계는 중간의 세부적 인과관계가 생략되어 수많은 정보를 놓치고 있습니다. 이를 더욱 구체적인 인과관계로 분석하면 다음과 같습니다.어떠한가요? 이처럼 인과관계를 세부적으로 나타내면 그만큼 더욱 세부적인 원인을 분석할 수 있고, 세부적으로 발전한 원인에 대해 더 많은 해결책을 마련할 수 있게 됩니다. 「꽃가루 -> 알레르기 발생」이라는 생략된 인과관계에서는 그에 대한 해결책으로 꽃가루를 어떻게 줄일 것인지, 알레르기를 어떻게 줄일 것인지에 대한 해결책밖에 떠오를 수 없습니다. 하지만, 구체적인 인과관계의 분석으로, 꽃가루가 공기로 전달되지 않는 방법, 꽃가루가 함유된 공기를 흡입하지 않는 방법, 기관지에 쌓이지 않게하는 방법, 기관지에서 방위작용을 하게 하지 않는 방법 등 더 구체적인 해결책들이 제시될 수 있습니다.
• 꽃가루 발생 -> 꽃가루가 공기로 전달 -> 공기를 흡입 -> 기관지에 쌓임 -> 기관지에서의 방위작용 -> 기침,눈물 등의 알레르기 발생

BRAIN STORMING트리

문제 해결방안 마련

HOW트리

HOW트리를 위한 팁

• 인과관계의 타당성 검증
  인과관계의 타당성 검증이란, 로직 트리의 각 박스를 잇고 있는 화살표들이 정말 타당한지를 검증하는 것입니다. 아래 그림에서 예를 들어 볼까요. 유기농 제품의 판매량 증대 -> 영업 사원의 생산성재고 라는 인과관계가 정말 타당한지 검증하는 것입니다. 유기농 제품의 판매량을 증대시키기 위해서 영업 사원의 생산성을 재고하는게 정말 타당한 인과관계인가?라고 자문해 보는 것이죠.

검증 : Feasibility 검증

feasibility(실현가능성)은 두 가지의 축으로 나뉘어 질 수 있습니다.

1. Impact
2. Time
3. Cost
4. Risk(코스트, 수익률, 성장률, 회수기간 등)

과제추출

우선순위 설정

우선순위는 각 태스크가 가지고 있는 중요도, 리드타임에 따라 결정됩니다. 　

중요도

먼저 중요도를 볼까요? 중요도란 무엇에 의해 결정될까요? 중요도를 결정하는 기준은 무엇일가요? 저는 다음의 세 가지 기준에 따라 중요도를 결정합니다.

1. 해당 태스크가 얼마나 많은 다른 태스크에 영향을 미치는가?
2. 해당 태스크의 데드라인은 언제인가?

리드타임

어떤 태스크는 리드타임을 갖기도 합니다. 리드타임이란 태스크를 시행함에 있어서 외부의 요인에 따라 대기해야하는 시간을 의미합니다. 예를 들면, 물건을 주문하는 것이 있겠습니다. 물건을 주문하면 주문하는 것은 금새 끝나지만 배송까지 시간이 걸리게 됩니다. 만약, 주문받은 물건이 다음의 태스크의 필요 조건 이라면 리드타임을 제대로 계산하지 못해 의미없는 시간과 공수를 날려버리게 됩니다. 때문에 리드타임이 걸리는 물건 주문과 같은 경우는 리드 타임을 계산하여 미리미리 시행하여야 합니다.

실행

태스크의 실행할 시, 디테일한 부분의 작업을 하고 있다고 하더라고 애초의 태스크와 문제해결을 위한 설계라는 큰 그림을 잊으면 안됩니다. 세부적인 작업에 집중해 큰 그림을 잊고 작업을 진행하면, 설계의 목적과 부합하지 않는 작업으로 빠져버릴 가능성이 큽니다.

자료 참고

• https://www.slideshare.net/WoongseokYun/i-8875850
• https://blog.lgcns.com/1179