IT Life

누구나 전략 기획 고수가 될 수 있다 - 문제 해결 프로세스 #2

2017.03.24 09:30

지난 편부터 본격적으로 문제 해결 프로세스에 대한 이야기를 시작했습니다. 이어서, 이번 편에서는 ‘문제’에 대해 추가적인 보충설명을 한 후 프로세스 설명을 이어가도록 할 텐데요. 전 편을 보시지 않고, 이 글을 읽으시는 분이 계신다면, 아래의 ‘문제’에 대한 보충설명을 읽으신 후 지난 편을 먼저 읽어보시길 바랍니다. 그리고 이번 14편을 함께 하시기를 권해 드립니다. 


 누구나 전략기획 고수가 될 수 있다. 13편 문서 해결 프로세스 #1

http://blog.lgcns.com/1343


제가 잠깐 설명해 드리기는 했습니다만, 사실 우리가 회사 업무를 수행하면서 부딪히는 모든 것을 제가 여기에서 기술하고 있는 ‘문제 해결’이라고 생각하시면 됩니다. 그래서, 문제 해결 역량을 갖춘 사람은 당연히 회사 업무를 잘하는 사람으로 인식될 수밖에 없는 것입니다. 이것을 이해하기 위해, 먼저 ‘문제’에 대해서 좀 더 추가적인 설명을 드리고자 합니다.



 문제에 대한 보충 설명

지난 편에서 문제 해결 프로세스에 대해 말씀드렸는데요. 사실, 이것을 정말 간단하게 2개의 프로세스로 나눈다면 첫 번째문제가 무엇인지를 인식하는 것이고, 두 번째는 그 문제의 해결책을 찾아내는 것이라고 할 수 있겠습니다. 즉, 그만큼 ‘문제’가 무엇인지를 인식하는 것이 중요하다는 것인데요. ‘문제’를 정확히 인식하지 못한다면, 당연히 그 솔루션도 엉뚱한 결과가 나올 것이 뻔하기 때문입니다. 

말씀드렸다시피, 문제는 현재와 목표와의 GAP을 의미합니다. 이러한 사례를 우리 주변에서 한 번 찾아볼까요? 여러분이 보험회사 영업사원이라고 가정해 보겠습니다. 이번 달 목표가 5건의 계약을 하는 것입니다. 그런데, 이달의 2/3가 지난 시점인데 아직 계약 건수가 한 건도 없습니다.


그렇다면, 현재는 0건, 목표는 5건이므로 양 측간에는 5건의 GAP이 발생하게 됩니다. 바로 이것이 문제인 것입니다. 이것을 다르게 과제 형식으로 표현하면, ‘목표 계약 5건 달성 전략’이라고 표현할 수도 있겠습니다. 그리고 고민하겠죠. “목표와 5건의 GAP, 이 문제를 어떻게 해결할 수 있을까?” 라고 말입니다.




다른 예를 또 하나 들어 보겠습니다. 여러분이 시스템을 운영하는 운영자라고 가정해 보겠습니다. 작년에 장애가 30건이 났었고, 장애시간이 120시간 정도 되어서 고객의 불만이 상당했습니다. 심지어 어떤 고객은 장애에 따른 손실이 발생했다고, 이에 대한 손해배상을 청구하기까지 했습니다. 

여러분의 보스가 이를 개선하라고 지시를 했습니다. 지시를 들은 여러분은 먼저, 목표를 세울 것입니다. 예를 들어, 고객과 서비스 레벨을 정의할 때 장애를 올해는 15건, 장애 시간을 60시간으로 합의했다고 합시다. 그럼, 여기서 발생하는 작년 실적 현황과 올해 목표 간의 ‘GAP’을 문제라고 할 수 있겠습니다. 이를 다르게 과제 형식으로 표현하면, ‘전년 대비 장애 50% 개선 전략’으로 표현할 수 있겠죠.


자, 어떠세요, 여러분들이 항상 하시는 업무(또는 과제)들이 모두 ‘문제’와 동일하다고 생각되지 않으신가요? 앞선 예시에서는 현재 상태와 목표 상태를 정량적 수치로만 들었지만, 꼭 정량적으로 나오지 않아도 관계없습니다. 가급적 정량적으로 하는 것이 여러모로 명확하기는 하겠지만요. 


예를 들어, 여러분 회사가 현재는 로컬(국내) 시장에서만 제품•서비스를 판매하고 있는데, 해외 시장으로 확대하고자 한다면, 이 또한 현재와 목표(Should be)간의 GAP이 존재하게 되므로 ‘문제’로 인식할 수 있습니다. 그러나, 실제로 회사에서는 ‘해외 시장 개척 전략’등의 과제명으로 표현하기 때문에 ‘문제 해결’과 연결을 시키지 못한 게 아닌가 생각됩니다.


모든 문제(과제)는 목표상태(Should be)에 어떻게 도달할 것이냐에 대한 물음이며, 그 물음에 대한 답변(전략, 전술 등)을 찾는 것이 바로 ‘문제 해결’이라고 생각하시면 됩니다. 사실 회사 내 업무가 아니더라도 개개인에게도 이러한 문제는 존재합니다. 예를 들어, 여자 친구를 만들고 싶거나 결혼을 하고 싶은데 아직 여자친구가 없다면, 어떻게 해야 여자친구를 사귀고 결혼할 수 있을까에 대한 고민과 자기만의 해결책을 찾는 행위도 같은 문제 해결이라는 것입니다. 


여러분들도 아시겠지만, 이에 대한 솔루션은 정말로 다양합니다. 정답이 있는 건 아니라는 것입니다. 각자의 상황, 주변 환경 등 수없이 많은 인자를 검토하여 자신에게 혹은 문제에 가장 최적의 솔루션을 찾아가야 하는 것이죠. 



 ‘이슈 확인’ 단계 Summary

여러분과 ‘문제 해결’이라는 주제가 무관하다고 생각하지 마시길 바랍니다. 자기 개인의 문제 또는 회사 업무 중에 갖게 되는 문제를 생각하시면서 글을 읽어 주시기 바랍니다. 그럼, 지난 시간의 ‘이슈 확인’ 단계에 대해 간단히 요약하고 넘어 가겠습니다.

문제해결 프로세스 그 첫 번째 내용으로 아래 이미지처럼 ‘이슈 확인’ 프로세스의 세부 단계인 ① 문제 정의 ② 문제의 구조화 ③ 가설 수립에 대한 설명을 드렸습니다. 
 

 

① 문제 정의, 상황을 분석하여 문제와 과제(목표 상태)를 명확히 정의해야 합니다. 


이 부분에 대해서는 앞에서 충분히 보충 설명을 해서 그냥 넘어 가겠습니다. 



② 문제의 구조화, 문제를 이슈로 세분하여 분석 구조를 설계합니다. 일반적으로 '로직트리'를 활용합니다.


이슈는 문제를 해결하기 위해 의사결정을 해야 하는 질문입니다. 그래서, 가능한 Yes 혹은 No라고 분명히 대답할 수 있도록 정의해야 합니다. 근본 원인을 밝히기 위해서 가능한 세부적인 단계까지 로직트리를 벌려 나가야 그 해결책을 ‘문제 뒤집기’식(취약 ↔ 강화)이 아닌 구체적인 ‘Action’ 형태로 도출할 수 있습니다.



③ 가설 수립, 개별 이슈에 대한 잠정적인 해결안을 가정해 봅니다.

 

가설 수립은 새로운 시각과 사실, 경험, 직관 등 여러 통합적인 역량을 바탕으로 수립하는 것이 좋으므로, 가급적 여러 사람이 참여하는 것이 좋습니다. 그리고, 가설은 반드시 검증할 수 있어야 합니다. 또한, 전 단계에서 도출한 이슈에 대한 답변이 이루어져야 합니다. 



 ‘자료 수집’ 단계 속 계획 수립과 자료 수집

그럼 지금부터는 지난 편에 이어 ‘문제 해결 프로세스’ 그 두 번째 단계인 ‘자료 수집’에 대해 설명을 드리겠습니다. ‘자료 수집’ 단계를 상세화하면, 아래 그림과 같이 두 단계로 이루어질 수 있겠습니다. 첫 번째 ‘계획 수립’과 두 번째 ‘자료 수집’ Task입니다.
 


① (작업) 계획 수립 단계 


계획 수립은 크게 두 가지 관점에서 작성이 필요한데요. 첫 번째는 어떤 자료를 어떤 방식으로 수집할 것인지에 대한 정의가 필요합니다. 이 경우를 다르게 표현하면, ‘수집자료 관리대장’을 작성해야 한다는 것입니다. 두 번째는 앞에서 정의한 자료 수집 계획에 대한 세부 일정을 수립하는 것입니다. 이것은 ‘작업 계획서(일정표)’로 표현할 수 있겠습니다.

그럼, 첫 번째 ‘수집자료 관리대장’부터 하나씩 살펴보겠습니다. 먼저 드리고 싶은 말씀은 이 작업은 여러 사람이 작업할 때 유용하기도 하지만 혼자 작업할 경우에도 반드시 작성하는 것이 효율적입니다. 

‘자료 수집’의 전 단계인 ‘이슈 확인’ 단계에서 최종적으로 가설을 설정했습니다. 가설은 반드시 검증할 수 있어야 한다고 했습니다. 가설의 검증을 하기 위해, 어떤 자료와 분석이 필요하며, 누가 담당할 것인지, 시간은 얼마나 줄 것인지 그리고 최종 Output(산출물)은 어떤 형태로 할 것인지 등을 정의해야 합니다. 우리는 이를 ‘작업 Framework’이라고도 부릅니다. 아래는 지난 편에 세웠던 가설의 예시를 가지고 작성해 보았습니다. 

l 작업 Framework 또는 자료수집 관리대장 예시


예시와 같이 작성하여, 이를 관리대장으로 계속 사용합니다. 각 담당자가 작업 완료 여부와 최종 산출물 자료명 등을 다른 이들도 한눈에 알 수 있도록 관리합니다. 


여기에서 필자가 가장 중요하게 생각하는 항목이 바로 ‘자료 소스’ 입니다. 실제 자료를 수집하는 방법에 해당되는데요. 여러 가지 방식이 있지만 가장 많이 사용하는 방법이 ‘설문조사’, ‘인터뷰’, ‘자료요청’, ‘자료검색(인터넷)’, ‘자료구매’, ‘현장조사’ 등입니다. 간혹, 우리는 흔히 쉬운 방법을 선택하려는 경향이 많은데요. 가장 최적의 방법을 선택하는 것이 중요합니다. 


하나를 검증하기 위해서 여러 가지 방식을 동시에 수행하기도 합니다. 예를 들어, 인터뷰의 경우 사실과 다른 경우가 많은데요. 이런 경우, 자료 요청이나 자료 검색 등을 통해 가급적 사실 여부를 확인하거나 증빙을 함께 수집하는 것이 좋습니다. 


두 번째는 ‘작업 계획서(일정표)’입니다. 이 작업의 경우, 여러 사람이 작업하고 또 윗분들에게 정기적으로 보고해야 하는 경우에 반드시 작성해야 합니다. 그러나, 한두 명이 하는 작업일 경우에는 저는 개인적으로 이 계획서를 작성하는 것을 권하지는 않습니다. 이미 앞에서 자료수집 관리대장에 담당자와 기한이 나와 있기므로, 그 정도로 충분하다고 생각합니다. 이 작업계획서는 우리가 평소에도 많이 작성해 보셨을 것 같아 상세한 예시는 생략하겠습니다. 


가급적 주 단위로 주요 Task 별로 일정을 막대 그래프로 해당하는 주 만큼 표시하게 되면 한 눈에 일정을 잘 확인할 수 있을 겁니다.



② 자료 수집 단계

자료 수집 단계는 ‘전 단계에서 정의한 작업 Framework대로 담당자가 자료를 수집하고 관리대장에 기재하기만 하면 되는 것 아닌가?’하고 간단하게 생각할 수 있는데요. 실제로는 이 단계가 문제 해결 결과의 품질(Quality)을 좌우하는 경우가 많습니다. 

문제 해결의 모든 프로세스는 중요합니다. 그러나, 실제 이 부분이 잘못되어 재작업을 해야 한다면 상당한 시간 낭비하게 됩니다. 자료가 다음 단계에도 영향을 주기 때문에, 후속 프로세스도 전부 다시 해야 하는 일이 발생할 수 있습니다. 신경을 많이 써야 하고 시간 효율적으로 업무를 수행해야 하는 단계입니다.


자료 수집은 사실에 근거한 문제 해결과 가설의 검증을 위해서 필수적인 단계입니다. 그 질적 수준이 매우 중요하죠. 담당자는 본인의 자료 수집 작업을 다시 상세하게 어떻게 할 것인지 계획을 세울 필요가 있습니다. 왜냐하면, 주어진 시간에 최고의 품질의 자료를 수집해야 하기 때문입니다. 그래서, 가급적 Output이 확실히 나올 방법에 시간 투자를 해야 합니다. 


예를 들어, 품질팀 인터뷰를 한다고 가정해 보겠습니다. 이 경우, 담당자는 제일 먼저 품질팀과의 인터뷰 일정을 잡아야 합니다. 그리고 나서, 인터뷰 질문지를 작성해야 합니다. 인터뷰 질문지를 어떻게 작성하느냐에 따라 인터뷰 결과의 품질이 달라지게 될 것입니다. 그래서, 가급적 여기에 시간을 많이 할애하는 것이 좋습니다. 



인터뷰 질문지가 작성이 완료되면 인터뷰 날짜까지 기다리지 말고, 인터뷰 대상(예시 상 품질팀)에 미리 전달하여 사전에 질문 내용을 충분히 숙지해 올 수 있도록 해야 합니다. 그리고, 필요한 경우, 증빙자료를 제출해 줄 것을 사전에 공지해야 합니다. 그리고 중요한 것은 인터뷰하고 난 후입니다. 인터뷰가 끝나면 반드시 그 날 인터뷰 결과서를 작성하는 것이 좋습니다. 필요한 경우, 사전에 인터뷰 대상자의 양해를 얻어 인터뷰를 녹음하는 것도 좋은 방법이겠습니다. 


앞서 몇 번 언급하였지만, 인터뷰를 뒷받침할 수 있는 자료를 함께 받는 것도 중요합니다. 즉, 인터뷰 시에 인터뷰 대상자가 하는 말 중에 사실이 아닌 추정이나 자기 생각이 들어가 있는지를 잘 구분하여야 합니다. 예를 들어, “사실 저희에게 보안 가이드가 있지만, 대부분 개발자가 보안 가이드에 대해 알지 못할 겁니다. 저희가 한 번도 교육을 한 적이 없었으니까요.”라고 인터뷰했지만, 시간이 허락하는 한도 내에서 이게 사실 인지를 확인해 봐야 합니다. 


보안 가이드가 있다고 했으니, 실체가 있는지 자료를 요청해야 합니다. 그리고, 실제로 개발자들이 보안 가이드에 대해 모르는지 설문결과를 확인해 봐야 한다는 것이죠. 즉, Cross 체크를 할 필요가 있다는 것입니다. 그러나, 실제 현장에서 인터뷰에 너무 의존하다 보면 실제가 아닌 데이터로 분석해서 잘못된 솔루션을 제시하는 경우를 많이 접하게 됩니다. 이 부분은 항상 주의해야 합니다. 


오늘은 ‘문제’에 대한 보충설명과 문제 해결 프로세스 중 두 번째 단계인 ‘자료 수집’에 대해 설명을 드렸습니다. 개인의 일이나 회사 일에서 우리가 항상 접하는 것이 ‘문제’입니다. 물론, 과제라고 생각해도 무방합니다. 여기에서 제가 소개해 드린 절차의 주의사항들을 잘 숙지하셔서 실제로 여러분 업무에 적용해 보시기를 권합니다.


백 번 읽는 것보다는 실제 여러분 업무에 한 번 적용해 보는 것이 훨씬 기억에 남고 도움이 됩니다. 다음 편에서는 이어서 ‘분석’, ‘솔루션 도출’ 단계에 대해 설명해 드리겠습니다.


글 | 김영주 부장 | LG CNS 블로거 



* 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 LG CNS 블로그에 저작권이 있습니다.

* 해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.




저작자 표시 비영리 변경 금지
신고
Posted by IT로 만드는 새로운 미래를 열어갑니다 LG CNS
위로