T-Tiger

1. RFP(제안요청서)

: 용역 회사와 시스템 공급사 등 제안 업체들에게 제안 요청을 하는 것으로, 간략하게 표현하면 '이러한 기능이 포함된 시스템을 어느 정도 금액 범위 내에서 이때까지 만들어주실 분 찾습니다!'라는 문서이다.

2. 제안서

: 상품 및 서비스를 제공하는 기업이 자신이 사업을 어떻게 수행할 것인가에 대해 포괄적으로 정리한 자료로서, 보통 RFP를 보고 거기서 요청한 기능이나 인력 구성, 유지보수계획 등에 맞게 작성하여 '우리 너희 사업에 참여할래!'라고 신청하는 문서이다.

3. 착수계

:  용역 대행 착수 시 작성하는 문서로 사업 계약에 따른 시작을 문서상으로 알리는 용도로 사용된다.

4. 산출물 관리대장

: 프로젝트를 진행함에 있어 어떤 산출물까지 작성하고 고객사에 제공할 건지에 대한 문서이다.

5. 인력투입계획서

: 프로젝트 착수시점에 투입하려는 인력 구성과 업무 등에 대해 작성하는 문서이며, 사업수행계획서와 함께 전달해야 하는 문서로 알고 있다.

6. WBS(일정관리)

: 일을 세분화하여 일정을 짜서 역할 분담을 한 문서로 프로젝트를 관리할 때 일정관리 기능으로 많이 사용하는 편이다.

7. 사업수행계획서

: 이 문서는 내가 제일 쓰기 싫어하던 문서이기도 한데 간단히 설명하면 프로젝트를 시작하기에 앞서 미리 해당 일에 대한 계획을 세우는 문서를 말한다. 이 문서는 사업을 성실하게 수행할 것임을 증빙하는 자료로 나중에 이 계획서를 바탕으로 사업이 정상적으로 종료되었는지를 확인하기도 하므로 대충 쓰거나 거짓, 과장해서 쓰는 것은 삼가는 것이 좋다.

8. 장애 및 유지보수 계획서

: 보통 새로운 시스템을 구축하거나 리뉴얼을 하고 나면 최소 3개월에서 1년 정도씩 유지보수를 해주게 된다. 시스템 구축을 요청한 업체 입장에서는 '만약 장애가 날 경우 어떻게 대처를 해줄 건지', '유지보수는 어떤 식으로 할 건지'에 대한 궁금증이 있는데 이를 문서화시켜 고객사에서 보여준다.

9. 진척관리대장

: 계획 대비 실제 수행률이 어느 정도인지를 나타내는 문서로 보통 주간보고를 진행할 때 많이 활용한다. 기본적으로 WBS를 기반으로 계획을 세우고 일/주/월 단위로 진척현황을 표기해 진척률을 확인한다.

10. 인력관리대장

: 프로젝트에 참여하는 인력 구성원과 담당업무, 투입 시기 등에 대해서 기입하는 문서이며, 인력 구성이 변경된  경우에는 인력관리대장에 기입하고 공문이나 기타 문서 등을 통해서 증빙을 하는 편이다.

11. 회의록

: 단어 그대로 회의에서 주고받은 의견이나 결정된 사항, 특이사항을 기재하는 문서이다. 추가적으로 사람의 기억은 변질되고 요구사항은 계속 변할 수 있으니 회의록은 최대한 꼼꼼하게 작성하고 경우에 따라서는 녹음을 하는 것도 추천한다.(회의 참석자 동의필요)

12. 착수/중간/완료보고서

: 일반적으로 프로젝트를 참여하는 시점, 사업 중반 시점, 완료 시점에 보고서를 한다. 기본적으로 PPT를 이용하여 발표를 하지만 때에 따라 생략을 하기도 하고 문서는 형식상으로만 만들고 실제 산출물(디자인, 퍼블, 개발)을 통해서 진행하기도 한다.

13. 주간/월간보고서

: 프로젝트를 진행하면 주 단위, 월 단위로 보고를 해야 하는데 그때 작성하는 문서이다. 기본적으로 이번 주에 진행한 업무와 차주에 진행할 업무, 특이사항 등을 기재한다.

14. 위험이슈관리대장

: 프로젝트를 진행함에 있어 아직 발생되지 않았거나 발생될 가능성이 있는 것, 발생된다면 프로젝트에 차질이 생기는 것 등에 대해서 기재하는 문서이다. 보통 이슈가 발생하면 이를 클라이언트와 공유하고 해결하거나 피해 가는 방향을 택하며 이렇게 결정한 근거와 의사소통한 담당자들에 대해서도 함께 회의록이나 위험이슈관리대장에 기재해야 한다.

15. 요구사항정의서

: 단어 그대로 고객의 요구를 정리하는 문서이다. 보통 요구분류, 요구사항ID, 요구사항명, 요구사항내용, 수용여부, 우선순위, 요구적용일자 등으로 구성한다.

16. 요구사항추적표

: 보통 RFP와 제안서를 바탕으로 프로젝트에 착수하지만 실제 현업 담당자들은 RFP에 있는 내용과 상충되는 얘기를 하는 경우가 있다. 감리가 있는 프로젝트는 달성률을 RFP에 있는 내용으로 하기 때문에 RFP에 있는 내용이 어떤 식으로 왜, 누구와 협의해서 바꿨는지에 대해서 추적표를 만드는 것을 말한다. 기본적인 구성은 RFP 내용-요구사항정의서-이후 변경된 부분 순으로 구성하면 된다.

이외에도 장비반출입 관리대장, 수신자료 관리대장, 검사기준서, 변경관리대장, 품질관리계획서, 품질관리대장 등의 문서가 있다.

오늘은 직장인이 꼭 알아야 할 용어 중 제안서와 관련된 RFP, RFI, RFQ에 대한 의미와 작성법을 알려드리도록 하겠습니다.

RFP의 의미

Request For Proposal이라 의미로, 흔히 제안 요청서라고 불립니다.

프로젝트 담당할 최종 업체를 선정하기 전, 1차로 선별된 업체들에게 보내는 문서인데요.

원하는 요구 사항을 체계적으로 정리한 문서라고 볼 수 있습니다.

제안 요청서에는 프로젝트의 주제, 목적, 목표, 내용, 기대성과 등 진행할 업무 내용에 대한 자세한 사항이 들어가는데요.

요청한 프로젝트의 과정과 결과를 확인할 때, 기입된 내용을 토대로 측정해볼 수 있기 때문입니다.

또한, 추후에 발생할 수 있는 업체 간 의견 충돌을 최소화해주는 역할까지 담당하고 있습니다.

작성법

제안 요청서의 핵심은 상대방이 RFP만 보고 업무에 대한 성격과 목적을 명확하게 이해할 수 있도록 하는 것입니다.

따라서, 일목요연하게 작성해야 하는데요.

진행할 업무 전체의 대략적인 내용, 입찰 규정, 낙찰자 선정 기준 그리고 목표, 목적, 기간, 기대성과 등이 모두 포함되어야 합니다.

RFI의 의미

Request For Information의 약자입니다.

흔히, 사전 정보 요청이라고 일컫는데요.

RFP를 작성하기 전 동향이나 정보를 취합하기 위한 자료로 쓰입니다.

RFI에서는 프로젝트를 추진할 때 필요한 기술이나 흐름 등을 기재하여, 공급업체에 게에 진행 또는 제공 가능 여부를 사전에 확인할 수 있습니다.

또한, 이를 통해 1차 공급업체를 가려낼 수 있는 역할을 하기도 합니다.

작성법

기존에는 RFI를 생략하는 기업들도 많았지만,

최근에는 빠른 트렌드 변화와 이를 반영하려는 목적으로 RFI를 요구하는 기업들이 늘어나고 있습니다.

특히, 트렌드에 민감한 시장이라면 RFI는 필수인데요.

주로, 회사의 현황(해당 업무를 담당 인원, 회사 연혁, 매출액 등 회사에 대한 신뢰도를 높일 수 있는 정보)와

현재 회사가 보유하고 있는 기능, 성능, 향후 기술적 추이, 고객사 현황, 기존 작업 내역 및 예시 등이 포함됩니다.

또한, 시장, 트렌드 분석 및 이를 반영할 수 있는 지표도 함께 필요합니다.

RFQ의 의미

Request For Quotation이라는 의미로 제안 견적 요청서를 뜻합니다.

어떻게 보면 가장 중요한 것이 예산이나 견적인데요.

아무리 좋은 내용이어도 터무니없는 금액을 요구한다면 프로젝트 진행이 어렵기 때문입니다.

그래서, 보통 RFP를 요청할 때 RFQ를 같이 요구하는 경우가 많은데요.

RFQ는 RFP와 함께 검토하여, 최종 공급 업체를 선택하는 중요한 역할을 합니다.

작성법

RFQ 역시 입찰 참여 조건을 갖춘 업체만 작성할 수 있는데요.

견적이 나와있는 문서인 만큼 제공할 기술이나 제품에 대한 상세한 정보와 스펙을 기재해야 합니다.

특히, 진행할 업무에 사용할 기술과 제품이 다양하며, 여러 부서와 협력해야 하는 사항이라면

누락된 사항이나 조정이 필요한 부분은 없는지 더욱 꼼꼼하게 작성해야 하는데요.

RFP에 기재한 기한, 담당 인력 그리고 RFQ에 기재한 기술과 제품으로 해당 프로젝트를 수행하고,

목표를 달성할 수 있는지 중점적으로 보기 때문에 이를 사전에 확실하게 점검해보는 것이 좋습니다.

지금까지 직장인이 알면 유용한 제안서 관련 용어들을 알아보았는데요.

실제 서식이나 예시는 프로젝트 성격, 업체 성격, 시장 성격에 따라 많이 상이하기 때문에 특정한 양식을 올려드릴 수는 없었습니다.

하지만, 용어 대한 기본적인 이해와 진행할 프로젝트에 대한 준비가 되어있다면 더 쉬워지겠죠?

그럼, 메대리는 앞으로 더 유용한 꿀 팀으로 다시 찾아오겠습니다. 감사합니다.

[출처] 제안서 용어, RFP/RFI/RFQ의 의미와 작성법|작성자 메일플러그

1. 아젠다 (Agenda)

완수해야하는 업무 내용을 사전에 정리해 둔 항목들을 의미합니다. 보통 회의 전에 준비하여 이 아젠다에 따라 논의를 결정지어 나갑니다.

2. 애자일 (Agile)

기민하면서도 민첩하다는 의미를 지니고 있습니다. 특히 IT업계에서는 경영환경에 따른 변화에 빠르게 대응할 수 있는 유연한 시스템 개발방법 등을 의미하는 용어로 자주 사용됩니다.

3. 이슈 (Issue)

비즈니스 상의 과제, 문제점, 논점, 중요 포인트 등을 의미합니다. 매일 사용하는 용어입니다.

4. 컨센서스 (Consensus)

여러 명의 동료들과의 합의, 동의를 구한 일을 의미합니다. 이 동의를 구할 때 보통 '컨센서스를 구하다'로 말하곤 합니다.

5. 스테이크홀더 (Stakeholder)

주주, 거래처, 고객은 물론 동료까지 기업환경을 둘러싼 이해관계자를 영어로 자주 표현합니다.

6. 태스크 (Task)

주어진 임무를 의미합니다. 영어로 자주 말합니다.

7. 픽스하다. (Fix)

업무를 최종 의사결정 지을 때 '픽스하다'라고 표현합니다.

8. 베스트 프랙티스 (Best Practice)

과거 사례 중 가장 효과적이었던 방안을 의미합니다. 이 베스트 프랙티스에 따라 업무를 진행해 나가는 일이 많습니다. 

9. 퍼소나 / 페르소나 (Persona)

심리, 마케팅 쪽에서는 페르소나로 부르고 UX업계에선 퍼소나로 많이 부릅니다. 정확히 말하면 두가지 의미가 조금은 다릅니다. 하지만 보통 회사에서는 상품이나 서비스를 제공할 때 가장의 인물을 세우는데 이 인물상을 의미합니다.

10. 팬딩된다. (Pending)

보류된다는 의미를 영어로 많이 사용합니다. 

11. 마일스톤 (Milestone)

중요한 업무 진척도를 관리하기 위한 일종의 업무 진척표입니다. 일정, 태스크 등에 따라 마일스톤이 달라집니다.

12. 공수 (영문은 아니지만 많이 사용)

인적, 물적 자원을 의미합니다. '공수가 많이 들어요'라는 의미는 시간이 촉박하고 업무에 관련된 사람이 많이 필요하다고 해석하면 좋습니다.

13. 런칭 (Launching)

서비스가 시장에 발매될 때 런칭된다고 말합니다. IT 업계에서는 서비스가 정식 공개되는 걸 의미합니다. 정식 공개가 아닌 사전 공개는 '베타', '베타 오픈' 등으로 부릅니다.

14. ROI (Return On Investment)

투자수익률이라고 해석하면 됩니다. ROI=이익÷비용X100으로 계산할 수 있으며 이 수치가 클수록 이율이 좋게 나와 효과 높은 투자라고 볼 수 있습니다. 

15. KPI (Key Performance Indicator)

목표달성 프로세스 진척 상황을 수치로 측정하여 나타내는 것입니다. '중요업무평가지표'라고 해석됩니다. 부서의 KPI, 개인별, 서비스별 KPI가 모두 다르며 IT 서비스에서 중요한 KPI로는 회원가입자수 등을 예로 들 수 있습니다. 

16. ROAS (Return On Advertising Spend)

광고비 1원당 매출액을 ROAS(광고비용대비효과)라고 부릅니다. 이 수치가 높을 수록 광고 효과가 높습니다. 

ROAS는 ROAS=매출액÷100으로 계산할 수 있습니다.

17. 포지셔닝 (Positioning)

자사제품을 경쟁사와 비교해 분석하는 것을 포지셔닝분석이라 말합니다. 자세제품이 현재 경쟁사대비 어디에 위치해있는가를 가리킵니다.

18. 스킴 (Scheme)

업무상의 계획을 의미합니다.

19. 컨버전 (Conversion)

기업의 목표(이커머스 사이트를 예시로 든다면 제품구매) 행위를 고객이 달성함을 의미합니다. 성과로도 해석되며 전환율이 높을 수록 매출이 높아집니다.

20. 어사인 (Assign)

하나의 업무를 나누어 각자 실무자에게 맞게 나누는 일을 의미합니다. 마찬가지로 영어로 꽤 많이 사용합니다.

e-HR은 기업 HR의 관리적 특징이 달라짐에 따라 함께 변화하는 성향을 가집니다.

물론, 시대의 흐름을 바꿀만한 IT 기술의 발달이 e-HR의 변화에 대한 동인이 되기도 합니다. 이를테면,  ‘웹의 폭발적 보급’, ‘스마트 폰의 등장’, ‘소셜 네트웍 서비스(SNS) 활성화’, ‘빅 데이터 활용에 대한 기대감 상승’과 같은 것들이죠.

e-HR을 변화시키는 가장 큰 동인은 기술보다 HR 자체의 변화입니다

하지만 무엇보다 기업이 성장하며 겪는 HR 자체의 변화가 e-HR을 변화시키는 가장 큰 이유입니다.

모든 기업은 인적자원 선발부터 배치, 관리, 육성을 거쳐 퇴직에 이르는 HR 수명주기에 대해 각자 나름의 규칙과 프로세스를 가집니다. 크든 작든, 기업이 개방적 문화를 가졌든 권위적 문화를 가졌든 모두 자신의 역사와 함께 체계를 갖춘 HR 체계가 있죠. 벤처에서 대기업까지 치열한 경쟁에서 살아남은 기업이라면, 창업 이래로 전해진 독특한 기업 문화와 경영 철학이 있습니다.

모든 기업은 HR 수명 주기를 관리하는 나름의 독특한 체계가 있습니다

과거에 비해 요즘의 e-HR에 요구하는 것이 조금 달라진 부분이 있다면, 그 이유는 예전에 비해 지금의 기업들이 좀 더 민첩하게, 보다 다양한 방법으로 시장에서의 우위를 점하기 위해 노력하기 때문에, 조직의 성장에 따른 HR의 변화가 좀 더 입체적이 되었기 때문일 겁니다.

최근 e-HR의 변화를 이끄는 몇 가지 HR 이슈로는 다음과 같은 것을 꼽을 수 있겠습니다.

• 조직의 성장 방향이 좀 더 수평적이고 기능적으로 되는 사례가 늘고 있다.
• 통합 / 분화되는 조직의 크기가 다양하다, 아울러 조직간 HR 체계의 성숙 레벨이 서로 다르다.
• 통합 / 분화되는 조직의 국적도 다양하다.
• 거의 모두 이미 전산화 된 e-HR 시스템을 가지고 있다.

이 밖에도 여러 이슈들이 있겠지만, 서로 다른 제도와 문화, 경영철학을 가졌던 조직들이 기업의 성장에 따라 융합되며 같은 체계 안에서 함께 움직일 수 있도록 하는 것이 HR에서 특히 쉽지 않은 도전이 됩니다. 그러므로, HR과 발 맞추어야 하는 e-HR 도 이런 복잡한 상황에 대응할 수 있는 능력을 필요로 하게 됩니다.

기업 HR은 그 발달 과정이 서로 다른 만큼,
HR이라는 큰 틀 안에서는 유사하지만 서로 다른 체계를 가집니다

이런 상황에서 주로 요구되는 e-HR의 대응 능력은 아래와 같은 것들입니다.

• 데이터 통합성 지원
• 프로세스 통합성 지원
• 커뮤니케이션 지원

첫 번째의 ‘데이터 통합성 지원’은 이런 상황에서 e-HR이 갖추어야 할, 어찌 보면 가장 기본적인 능력입니다.

기업 내에서 기존에 수기로 관리하던 데이터를 전산화 해야 하는 것은 물론이고, MS엑셀로부터, 자체 개발된 e-HR 시스템까지 HR 정보를 관리했던 다양한 IT 체계를 가지고 있기 때문에, HR 데이터를 하나의 맥락에서 관리 될 수 있도록 하는 것이 하나의 정보체계를 구축하기 위한 필요 조건이 되기 때문입니다. 조직 속성, 인사 관리 항목, 역량, 직무, 급여 항목 등 전산화된 HR을 지원하기 위해 필요했던 정형화된 거의 모든 데이터 요소들이 통합성 지원이 필요한 대상이 됩니다. 데이터 통합의 관점에서 e-HR 시스템은 ‘통합관리체계 제공’ 과 ‘일관된 해석장치’ 에 대한 능력을 요구 받습니다.

기존의 데이터는 존재 방식과 관리 방식이 다를 수 있기 때문에, 하나의 체계 안에서 회사별로 구분할 수 있는 관리체계를 갖도록 하는 것은 많은 노력이 드는 일입니다. 보통 여러 체계를 통합할 때 가능한 한 많은 경우의 수를 대응하려다 보니 막상 만들어지는 결과물은 관리가 힘들 정도로 필요 이상의 복잡한 체계를 가지게 되는 경우가 있습니다. 이 경우, e-HR은 가능한 한 명료하면서도 다양한 상황에 유연하게 대처할 수 있는 적절한 관리 도구를 통해 이를 지원해야 합니다.

같은 의미의 데이터라도 관리되는 형식과 체계에는 차이가 있을 수 있습니다
기존 데이터는 일반 텍스트, 마스터형 코드, 이력 방식의 코드 등 여러 형태로 존재합니다.

회사별로 구분된 데이터관리 체계를 갖는 것과 더불어, 데이터들은 경영정보 시스템(EIS) 이나 타 시스템과의 연계를 위한 하나의 방식으로 해석되어야 할 필요가 있습니다. e-HR은 하나의 메타 정보를 기반으로 해서 데이터를 일관된 방법으로 해석 할 수 있는 변환도구나 매핑 도구를 통해 이를 지원해야 합니다.

최근의 구축사례에서 이수 OPTI-HR은 자동화된 시스템간 코드 변환 체계를 지원하는 패키지를 납품했습니다.
( HR 시스템 직무와 – 채용 시스템 모집 코드간 동기화 사례 )

두 번째, ‘프로세스 통합성 지원’ 측면에서 e-HR은 기업 내 IT 시스템 통합의 주체적 역할을 할 확률이 적기 때문에 주체적으로 해결할 수 있는 ‘이종 HR 프로세스간의 통합’과 더불어, ‘수기 프로세스의 전산화’, ‘기간 시스템과의 연계’에 대한 요구를 받습니다.

HR 프로세스 통합은 데이터 통합의 경우와 마찬가지로 하나의 체계 안에서 회사별로 독자적인 프로세스를 운영할 수 있도록 해야 합니다. 그렇기 때문에 이 관점에서의 e-HR 역시 통합 프로세스를 설계하고, 분화되어 개별화된 여러 프로세스의 흐름을 수용할 수 있는 도구적 지원능력을 갖춰야 합니다.  

e-HR은 결국 IT 관점에서 프로세스 통합을 지원하게 되기 때문에, 바탕이 되는 데이터 통합이 먼저 요구되는 경우가 많습니다.

이 경우, 통합 프로세스를 만드는 과정에서 기존에 수기로 처리되던 부분이 전산화 되기도 하는데, 인사 담당 부서가 아닌 일반 임직원이 해 오던 기존 작업방식이 바뀌게 되는 만큼, e-HR은 직관적이고 사용성 높은 사용자 인터페이스를 가진 도구를 통해 이를 지원해 주어야 합니다.

최근의 구축 사례에서 이수 OPTI-HR은 기존에 수작업으로 진행되던 면접 평가를
직관적 인터페이스를 갖춘 온라인 면접 평가 방식으로 전환했습니다.

또한, 하나의 큰 IT 체계 속에서 e-HR은 기업 내 기간 시스템과 함께 쓰일 수 있어야 합니다. 그룹웨어부터 시작해서 ERP, 출입 관리 시스템까지 기업 내의 다양한 시스템이 각자의 방식으로 기업의 복잡한 프로세스를 지원하며, e-HR의 필요와 상관 없이 변경되거나 교체될 수 있습니다. 프로세스 통합 관점에서 e-HR은 기업 내 다양한 시스템 환경 변화에 일관되며 유연한 방식으로 대응할 수 있어야 합니다. 그렇기 위해서는 일반적이고 표준화된 시스템 인터페이스 체계와 손쉬운 유지보수 체계가 필요합니다.

마지막으로 ‘커뮤니케이션 지원’ 측면에서 e-HR은 다양한 방법으로 HR 주체들을 연결해 주어야 합니다.

변화하는 제도나 HR 부서의 의도가 조직에 쉽게 전파될 수 있어야 하고, 성과관리를 위한 팀 간의 소통이 원활이 지원되어야 합니다. 또한 경영자는 HR관점에서 놓치지 말아야 할 중요한 지표들에 대한 피드백을 받을 수 있어야 합니다. e-HR은 이를 위해서 HR시스템의 이벤트를 수집하여 정보화 하고, 다양한 채널을 통해 이를 전파할 수 있는 쉽고 직관적인 수단을 제공해야 합니다.

지금까지 성장하는 기업에서 HR 의 변화가 이끄는 e-HR의 변화에 대한 몇 가지 특징적 요소를 살펴봤습니다. 다음 글에서는 위에서 나열한 e-HR의 각 대응 능력에 대해 구체적으로 사례를 통해 살펴보도록 하겠습니다.

보고서, 의사 전달의 도구 이상도 이하도 아닌

기업 내의 많은 의사소통은 메일이나 보고서 등으로 이루어집니다. 사람과 일이 많기에 짧은 시간에 효율적인 의사결정을 내리기 위해서는 중요 내용만 있는 유형의 전달 도구를 통해 많은 사람에게 단기간에 전달되는 게 효율적이기 때문입니다. 그렇지만 이게 과해서 아무 말 보고서로 하드디스크를 낭비하고 아까운 종이를 버리고 인생을 낭비하는 일도 있습니다. 이것은 본질과 맞지 않는 것입니다. 이런 것을 차치하면 관리직의 숙명 중 하나는 효과적인 의사 소통에 있습니다. 특히 제안서나 보고서, 메일 같은 한 번 쓰면 빼도박도 못하는 종류의 것을 잘 사용하는 것 말이죠.

특히 기획자는 보고서가 많습니다. 세상의 수 많은 기획자들의 과업이 조금씩 다르지만 기본적으로는 보이지 않는 것을 설명해야 하는 일이 많기에 효율적인 의사 전달이 어렵습니다. 아직 나오지 않은 서비스나 상품을 설명하는 것부터 조직의 비전과 문화에 대한 설명, 역량의 발전과 시장 상황에 대한 내용은 말로도 어려운데 이걸 글로 쓰자니 쉬운 일이 아닙니다. 더군다나 한국 기업의 문제점 중 하나인 윗 사람이 시키지만 시키는 사람 조차 이게 뭘 하란 건지 모르는 일인 경우에는 더 그렇습니다. 제목은 알지만 내용은 계속 수정해 나가면서 어렴풋이 모두 알게 됩니다.

이런 많은 보고서를 잘 쓰는 것도 능력입니다. 몸이 거부할 수 있겠지만 현실이 그렇습니다. 자신의 생각을 잘 전달하는 것은 비단 기업 뿐 아니라 살아가는 모든 상황에서 큰 성취를 만들곤 합니다. 전략 기획자의 효과적인 보고서는 불필요한 행동을 없애고 기업 내부에서 정확한 방향으로 사업을 추진하는 역할을 합니다. 지지부진 하던 모두의 생각을 하나로 모으고 일을 실행하는 전환점이 되는 것입니다. 잘 쓴 보고서는 길지 않아서 읽는 사람이 잘 이해가 되고 핵심만 나와 있습니다. 그리고 그것을 부연하는 정확한 숫자와 사례가 나와서 누가 봐도 맞는 말이라는 인상을 줍니다. 과하지도 모자라지도 않는 것이죠.

하지만 이렇게 보고서를 쓰는 것은 쉬운 일은 아닙니다.  쓰고 싶은 것을 쓰지 못하게 만드는 외압도 문제지만 설령 뚜렷하게 주제를 알았다고 해도 표현력이 약해서 효과적으로 의사 전달을 못하는 경우도 있습니다. 어렵게 고민해서 창작을 하면 격려는 커녕 다시 쓰라는 핀잔만 날라오는 경우도 있습니다. 회사나 직장 상사가 잘못되었다면 어쩔 수 없지만 비교적 합리적인 사람이 그런 반응이 나온다면, 계속 나온다면 자신의 보고서 쓰는 방법을 바꾸어야 합니다.

먼저 소위 칭찬 들었던 보고서와 자신을 비교하지만 이런 경우 눈에 먼저 들어오는 것은 보고서 디자인과 화려한 그래프일 것입니다. 내용의 배열과 주장과 근거를 대는 것보다 당장 나의 보고서에서는 보여주지 못한 효과들에서 보고서 쓰기는 어렵다는 결론으로 포기할 수도 있습니다. 하지만 보고서의 기본적인 목적이 그런 데에 있지 않기 때문에 핵심적인 목적을 달성하는 데 필요한 것만 보면 됩니다. 읽는 사람을 이해시키는 방식 말이죠. 눈에 화려한 것보다 다 읽고 나서 이해가 되고 핵심적인 주장이 이건데 왜 이렇게 말하는지 머리에 남느냐에 대한 것이죠. 세부적으로 글자가 틀리고 줄이 안 맞고 이런 것은 부차적인 문제입니다. 그런데 시간을 낭비하면 정말 인생을 낭비하는 것입니다. 그러기에 핵심적인 부분만 보면 됩니다. 아래 내용들은 효과적인 보고서를 쓰는 방법에 대한 지극히 개인적인 생각이니 필요하시면 참고 하면 좋을 것 같습니다.

1. 반드시 고유명사를 쓴다

보고서의 결론은 고유명사가 있어야 합니다. 구체적인 대상을 지칭하지 않으면 인사이트가 없고 실행할 수 없는 보고서가 될 수 있습니다. 보고서가 문제를 진단해서 핵심 원인을 찾고 대안을 찾아서 실행 방법에 대해 탐구하는 것이 보통의 흐름이라면 각 과정에서 고유명사로 핵심적인 내용이 다루어져야 합니다. 예를 들어 핵심적인 문제가 무엇인지 다루는 내용에서는 '4분기 매출 악화의 원인은 가전 분야의 부진이었습니다'라는 말보다는 '4분기 매출 악화의 원인은 가전, 그 중에 청소기 000 모델의 부진이었습니다'라고 하는 것이 보다 정확한 문제 인식을 환기해 줍니다. 가전이 부진하다는 것보다 000 모델을 언급하는 것이 무엇을 바꾸어야 할지 구체적인 방향을 지시하기 때문입니다. 하지만 이런 것은 보통 민감한 사안이므로 내부에서는 안쓰는 것과 다름없는 대명사 위주의 보고서가 넘쳐납니다. 하지만 실무진 입장에서는 고유명사로 설명을 해야 이해가 쉽고 전사적으로 빠른 행동이 가능합니다. 대안의 경우에도 그렇습니다. 단순히 '1분기에는 비용을 절감하는 것과 함께...' 이런 식의 나열보다는 '1분기에는 영업외 비용인 000 비용을 00% 줄이고...' 이런 식의 구체적인 결론이 나야 실제 일을 진척한 기간의 성과가 온전히 드러나고 이후 정말 회사를 바꾸는 일에 이어질 수 있습니다. 고유명사를 말할 수 없다는 것은 실제로 핵심 내용을 알지 못하고 있든지 회사 문화가 굉장히 폐쇄적이고 정치적이든지 하는 원인이 많습니다.

2. 핵심이 되는 숫자와 사례를 함께 표기

주장의 정도와 근거의 핵심 변곡점은 숫자로 표현할 수 있다면 하는 것이 좋습니다. 방향은 고유명사 등으로 구체적으로 표현이 가능하지만 정도는 숫자로 표현하는 것이 서로 이해가 가능합니다. 목표 숫자라는 것은 막무가내식의 활동 혹은 전혀 하지 않는 활동 모두를 막아줍니다. 구체적인 근거가 동반된 상태에서 얼마까지 어떻게 하자는 표현은 전체적인 목표를 설정하는 일이기도 합니다. '생산라인의 리드타임을 현재 일 20분에서 크게 줄여야 한다'는 것보다는 '생산라인의 리드타임을 현재 일 20분에서 15분 수준으로 단축시켜야 한다'라는 표현이 더 좋습니다. 그리고 15분의 근거가 되는 우수 사례나 기술적인 변화를 함께 언급한다면 실제로 일이 될 확률이 높을 것입니다. 실제 이 정도를 보고할 수 있다는 것은 생각의 정리가 완결되었음을 의미하기 때문입니다. 특히 향후의 행동을 주장할 때는 숫자로 표현하는 것이 좋습니다. 숫자로 나타내지 않으면 단순한 구호에 그치는 일이 많습니다. '00 지점은 올해 매출 2배를 하겠습니다'라는 구호성 말보다 '00 지점은 000을 통해 2억, 000을 통해 4억을 추가하여 매출 6억을 추가하겠습니다'라는 게 더 구체적이고 나중에 확인할 수 있는 방법입니다. 물론 이런 숫자 자체를 정치적으로 오용하거나 확인할 수 없는 상태로 방치하면 그게 더 문제가 되겠지만요. 그러기에 목표 자체보다 이것이 가능한 근거들을 기술적으로 설명하는 데 더 많은 분량을 할애하는 것이 맞습니다.

3. 페이지 순서는 읽는 사람의 생각 순서로

보고서에서 중요한 것은 페이지의 순서입니다. 두괄식이 좋다는 것은 다 아실 것입니다. 결론을 앞에 쓰는 것은 어디서나 공통적입니다. 다만 결론 이후의 페이지 구성이 문제입니다. 이후 페이지의 구성은 처음 이 분야를 접하는 사람이 알아야 하는 배경부터 이것의 현상과 원인, 결론으로 이어지는 자연스러운 흐름을 취하는 것이 좋습니다. 반드시 알아야 할 전제를 뒤에 설명하면 전체적으로 혼란을 야기시키고 보고서는 곧 덮이게 됩니다. 페이지의 넘버링이나 타이틀에 신경을 많이 쓰지만 그보다는 페이지는 읽는 사람의 생각의 흐름에 맞추는 게 기본적인 접근이고 가장 시간을 많이 가져가야 할 부분입니다. 이런 관점으로 보다보면 필요없는 페이지가 많이 나옵니다. 흐름을 방해하거나 중간에 액자 형식으로 들어가 있어서 당장 없어도 대세에 영향이 없는 페이지가 발견됩니다. 그런 것은 빼면 됩니다. 보고서는 간명해야 만드는 사람이나 읽는 사람의 시간을 효율적으로 만들 수 있습니다. 정말 더 많은 분량의 배경 설명이 필요한 것이라면 그것은 보고서가 아닌 구두의 형태로 따로 하는 것이 맞습니다. 그걸 보고서로 요구하는 일은 없어져야 하겠습니다.

4. 원인이 있으면 대안이 있어야

초보자와 숙련자와의 결정적인 차이입니다. 대안을 제시하는 능력 말입니다. 문제와 원인만 잔뜩 나열하고 보고자의 지능과 배경지식을 자랑하는 보고서는 기업에서는 그리 필요하지 않습니다. 중요한 것은 대안을 가지고 발전시키고 바꾸어 나가는 것이니까요. 따라서 장황한 사례나 숫자의 나열로 많은 페이지를 써가며 문제를 파헤친 후 1~2장의 대안으로 막을 내리는 보고서는 우수한 보고서로 보기 어렵습니다. 보고 시점이 원인 진단에 그치는 경우가 아니라면요. 이것은 대안에 대한 생각 없이 이 보고서를 받는 사람에게 전적으로 맡기는 것입니다. 보고자의 두뇌는 여기 전혀 사용하지 않았다는 것이죠. 사실 보고자만큼 이 사안에 대해 고민한 시간이 많은 사람은 조직에 드물텐데 그렇게 되면 최선의 대안은 항상 나오기 어렵게 됩니다. 보고자는 반드시 1개 이상의 대안, 되도록이면 경우에 따라 몇 개의 대안을 준비하고 그것의 기대효과와 근거 필요한 역량에 대해 구체적인 서술 후 보고 받는 사람이 그것을 선택하게 만드는 것이 좋습니다. 보고 받는 사람이 뭔가 할 게 있는 보고회여야 하니까요. 다만 보고자의 생각이 들어가야 합니다. 이런 대안 중에 나는 보통의 경우 이게 더 낫다고 생각한다는 약한 의사 개진이 반드시 필요합니다. 없다면 보고자는 어렵게 일해 놓고 남들이 자신의 밥그릇을 가져가는 모습을 많이 보게 될 것입니다.

5. 대안은 구체적인 실행 방법으로

대안은 실행 대안입니다. 대안의 형태는 구체적 실행이 가능한 형태여야 합니다. 가령 대안의 아웃라인을 보여주는 것이죠. '이런 식의 아웃풋이 될 거다'를 이미지로 보여주거나 어디까지 할 거다라는 것을 미리 언급하거나 누가 얼마를 써가면서 언제까지 대략 가능하다는 스케쥴을 언급하거나 해야 한다는 것입니다. 대안이 구체적이지 않으면 애써 쓴 보고서 자체가 무의미한 것으로 취급되기 쉽습니다. 그리고 대안에 대한 지불 비용을 반드시 언급하는 것이 좋습니다. 효과만 잔뜩 쓴 것보다는 실제 이 정도의 비용이 발생한다든지 이게 필요하다든지 하는 비용의 언급이 있어야 일을 실체를 가지고 움직이고 보고 후 다른 소리가 기업 내부에서 나오지 않습니다. 이게 없다면 보고는 보고대로 했지만 일은 안되고 보고한 사람의 입장이 난처해지는 경우가 생깁니다. 보고회 역시 문제의 진단이 잘 되었는가에 많은 시간을 쓰는 게 맞지만 대안에 초점이 맞추어진 내용이라면 대안의 구체성과 성과의 정의, 성과가 되게 하는 방법에 많은 시간을 쏟는 게 맞습니다.

6. 페이지 아래 부분에 근거를 쓰고, 발전된 내용은 다음 페이지에

한 페이지는 두 개 이상의 메세지가 있으면 안 좋다는 것은 많이 아실 것입니다. 보통 페이지의 구성은 페이지의 타이틀, 그 아래 핵심적인 주장, 그리고 그것의 근거가 나오는 순서입니다. 위에서 다룬 내용은 대부분 주장에 대한 내용이었습니다. 하지만 근거 없는 주장은 소용이 없습니다. 대부분 프로젝트 기간에는 근거를 잡는데 많은 시간을 쓰게 되어 있습니다. 그 근거를 효과적인 것만 형상화해서 표현하는 것이 페이지 하나를 완성하는 핵심입니다. 근거는 보통 조직도, 순서도 같은 도면 형식부터 사례와의 비교, 현재와 미래의 변화, 핵심 원인이나 카테고리 분석 등 다양한 형식을 취할 수 있습니다. 핵심은 주장에 있는 숫자와 고유명사가 아래 근거를 통해 설명될 수 있느냐는 것입니다. 페이지를 구성하면서 논의가 발전될 수 있는데 그런 내용은 반드시 다음 페이지에 오도록 합니다. 한 페이지에 화살표로 시계열적인 다음 주제를 던지거나 더 세부적인 내용을 다루는 경우가 있는데 이런 것은 페이지 내 핵심 내용을 흐릿하게 만들면서 읽는 사람이 많은 공을 들여야 하게 만드는 원인이 됩니다.

7. 근거 데이터, 출처를 반드시 표기

근거 데이터, 출처를 표기하는 것은 기본입니다. 하지만 많이 빠트립니다. 특히 숫자나 사례는 어디서 나온 것인지 어딘가에 있어야 하며 그것의 시점, 누가 했는지, 어디서 확인할 수 있는지가 함께 표기 되어야 합니다. 처음 페이지를 보는 사람은 항상 그것을 의심하는 경우가 많기 때문에 이런 표기가 필요합니다. 표기하다보면 이 출처가 신뢰성이 있는지 없는지 스스로 알게 될 것입니다. 이왕이면 성공한 경험이 있고 유사한 사례, 권위를 인정받는 곳의 데이터를 가지고 하는 것이 더 낫다는 생각이 들 것입니다. 구호성에 그치는 보고서들은 근거 데이터가 없거나 빈약합니다. 작성하는 사람 스스로 제대로 된 합리적인 주장인지 검증할 수 있습니다.

8. 단위나 주석은 읽는 사람을 위해

단위 표기나 주석을 아래에 넣는 것에 인색해서는 안됩니다. 다만 이런 표기가 본문을 가리거나 본문보다 더 눈에 잘 보이면 안됩니다. 단위 중에서는 우리가 일상적으로 많이 쓰는 것을 다 알거라고 생각하고 표기하지 않는 경우가 있는데 모든 숫자는 단위가 다 나와 있어야 합니다. 통화의 '원'이나 사람의 '명' 등은 많이 누락하는 단위입니다. 주석도 예외 사항이나 주의점을 반드시 설명해야 합니다. 나중에 백의 하나라도 다른 경우가 나오면 그것을 언급하지 않았었다는 이유만으로 나머지 부분들이 신뢰를 잃게 되는 경우가 많기 때문입니다. 대부분의 경우는 보고서를 읽는 사람이 이 내용에 대해 잘 모른다고 가정하고, 또 이 내용을 기본적으로 신뢰하지 않는다고 가정한 상태에서 읽는 사람에 대한 배려가 되는 장치를 만드는 게 좋은 보고서를 만드는 데 도움이 됩니다.

9. 핵심만 보이도록

페이지를 구성하고 나면 다시 한 번 봐야 합니다. 가장 먼저 무엇부터 눈에 들어오는지를 봐야 하기 때문입니다. 욕심으로 여기저기 디자인을 한 페이지는 정작 내용이 보이지 않습니다. 화려한 컬러로 덧칠한 레이아웃은 눈에 잘 보이지만 주장하고자 하는 것은 자세히 읽어야 알 수 있습니다. 그렇게 되면 짧은 시간 핵심적인 메세지를 전달하려는 본래의 취지를 잃어버린 것입니다. 차라리 이런 껍데기는 아예 없는 게 더 낫습니다. 전체적으로 사용하는 컬러는 2개 내지 3개 이내에서 정리되어야 합니다. 사실 1개로도 충분합니다. 컬러만 아니라 폰트나 글자의 크기로 얼마든지 주목받는 문장이나 단어를 만들 수 있습니다. 이런 수고는 오히려 화려한 디자인에 비해 만드는 시간이 더 들지는 않지만 고민은 더 필요한 부분입니다. 이왕이면 문장은 길지 않게 주어와 술어의 간격이 멀지 않고 주술 관계의 구조가 단순한 게 좋습니다. 그러면 문장은 자연스레 짧아지게 됩니다. 굳이 만연체로 쓸 필요가 없어집니다. 사례를 문장에 마구 집어 넣는다는 것은 그것을 관통하는 공통적인 성질에 대한 이해가 덜 되었음을 반증하는 것입니다. 사고가 정리가 되면 짧게 나오지 길게 늘어지지 않습니다.

소속된 집단마다 각 민족과 국가처럼 저마다 문화가 다릅니다. 그래서 보고서나 문체는 그 집단의 영향을 받는 것이 당연합니다. 위에서 다룬 내용들도 고지식하게 따로 존재하지는 않습니다. 현재 조직에서 만들어지고 읽혀지고 있는 토대 위에 이런 생각들을 잘 대입해 보면 보고서는 대학원 논문을 쓰는 것과 비슷한 구성, 혹은 뉴스 기사가 시작해서 자료가 나오고 인터뷰를 따고 맺음말을 맺는 구성과 매우 닮았다는 것을 알게 될 것입니다.중요한 것은 이런 토대 위에 말하고자 하는 내용, 그 자체인 것이죠. 이것은 이런 스킬만으로는 해결되지 않습니다. 오직 생각하는 것에 달려 있으니까요. 또 어떻게 해야 여기서 주장하는 아젠다를 실행하게끔 만드느냐를 생각해야 합니다. 일은 이제부터 시작이니까요.