 |
| 제안서에서 문제점 작성하는 |
제안서에서 문제점 작성하는 법
제안서를 작성할 때 생각보다 시간이 오래 걸리는 부분이 문제점을 정리하는 과정이다. 해결 방안이나 기대효과는 비교적 쉽게 작성할 수 있지만, 정작 무엇이 문제인지 명확하게 설명하는 것은 쉽지 않다.
나도 제안서나 기획 문서를 작성할 때 바로 해결 방안부터 생각했던 적이 많다. 하지만 문제 정의가 제대로 되지 않은 상태에서 해결 방안을 먼저 정하면 뒤에서 논리를 맞추기 어려워진다. 제안 내용은 좋아 보이지만 왜 이 제안이 필요한지 설득력이 부족해지는 경우도 생긴다.
그래서 제안서를 작성할 때는 현재 상황을 먼저 살펴보고, 그 안에서 문제를 찾아낸 뒤 해결해야 할 핵심 문제를 구체적으로 정리하는 과정을 거치는 것이 좋다.
이번 포스팅에서는 제안서에서 현황 분석과 문제 정의의 차이, 문제점 작성 방법, 실제 문제 정의 예시를 정리해봤다.
01. 현황 분석과 문제 정의 차이
현황 분석과 문제 정의는 비슷해 보이지만 역할이 조금 다르다.
현황 분석은 현재 어떤 상황이 발생하고 있는지를 객관적으로 정리하는 과정이다. 반면 문제 정의는 현황 분석을 통해 확인한 여러 내용 중에서 해결해야 할 핵심 문제를 구체적으로 정리하는 과정이다.
👉 현황 분석은 현재 상태를 보여준다
예를 들어 회사에서 고객 문의 처리 시간을 줄이기 위한 프로젝트를 추진한다고 가정해보자.
현황 분석에서는 다음과 같은 내용을 확인할 수 있다.
- 월평균 고객 문의가 지속적으로 증가하고 있다.
- 문의 접수 채널이 전화, 이메일, 홈페이지 등으로 분산되어 있다.
- 상담 담당자가 문의 내용을 수기로 정리하고 있다.
- 담당자별 문의 처리 방식이 다르다.
- 문의 처리 현황을 한눈에 확인하기 어렵다.
이 단계에서는 문제라고 단정하기보다는 현재 업무가 어떻게 이루어지고 있는지 보여주는 것에 초점을 맞춘다.
👉 문제 정의는 해결해야 할 내용을 좁힌다
현황을 확인한 다음에는 그중 실제로 해결해야 할 문제를 정리한다.
예를 들면 다음과 같이 표현할 수 있다.
현황 분석에서 여러 개로 흩어져 있던 내용을 하나의 문제로 연결한 것이다.
실제로 문서를 작성해보면 현황 자료를 많이 넣는 것보다 이 자료를 통해 무엇이 문제인지 명확하게 보여주는 것이 더 중요했다. 데이터를 많이 보여주더라도 결론이 없으면 읽는 사람 입장에서는 결국 무엇을 개선하겠다는 것인지 이해하기 어렵다.
02. 제안서 문제점 작성하는 법
제안서 문제점을 작성할 때는 단순히 부정적인 상황을 나열하는 것보다 원인과 영향을 함께 생각하는 것이 좋다.
나는 보통 현상 → 원인 → 영향의 순서로 정리한 뒤 문장으로 만드는 방법을 사용한다.
1) 먼저 현재 나타나는 현상을 찾는다
가장 먼저 현재 실제로 나타나고 있는 상황을 적어본다.
예를 들어 내부 업무 시스템을 개선하는 프로젝트라면 다음과 같은 내용이 현상이 될 수 있다.
- 동일한 데이터를 여러 시스템에 반복 입력한다.
- 업무 자료를 엑셀과 이메일로 관리한다.
- 담당자가 바뀔 때 업무 인수인계에 시간이 오래 걸린다.
- 진행 상황을 확인하려면 담당자에게 직접 문의해야 한다.
가능하다면 수치나 실제 업무 사례를 함께 활용하는 것이 좋다.
'업무 처리가 느리다'라고 쓰는 것보다 '자료를 여러 시스템에 중복 입력하고 있어 업무 처리 시간이 증가하고 있다'라고 작성하면 문제 상황을 훨씬 구체적으로 이해할 수 있다.
2) 왜 이런 현상이 발생하는지 원인을 찾는다
다음으로 현상이 발생하는 원인을 생각한다.
예를 들어 업무 처리 시간이 오래 걸리는 이유가 무엇인지 살펴보면 다음과 같은 원인을 찾을 수 있다.
- 시스템 간 데이터 연동이 되어 있지 않다.
- 표준화된 업무 프로세스가 없다.
- 담당자별 관리 방식이 다르다.
이 과정에서 주의할 점은 현상과 원인을 같은 것으로 작성하지 않는 것이다.
예를 들어 '업무 처리 시간이 오래 걸린다'는 현상이고, '수작업으로 데이터를 반복 입력하고 있다'는 원인이 될 수 있다.
3) 문제로 인해 발생하는 영향을 정리한다
마지막으로 현재 문제가 지속될 경우 어떤 영향이 발생하는지를 확인한다.
- 업무 처리 시간 증가
- 담당자 업무 부담 증가
- 데이터 오류 가능성 증가
- 고객 응답 지연
- 관리 비용 증가
문제점을 작성할 때 영향까지 연결하면 제안의 필요성이 자연스럽게 만들어진다.
결국 제안서는 단순히 문제가 있다는 것을 설명하는 문서가 아니라 왜 지금 이 문제를 해결해야 하는지 설득하는 문서이기 때문이다.
03. 제안서 문제점 작성 예시
실제 제안서에서는 문제를 너무 길게 설명하기보다 한눈에 구조를 이해할 수 있도록 정리하는 것이 좋다.
나는 문장을 작성하기 전에 먼저 핵심 내용을 짧게 정리하고, 필요하면 이를 문장이나 도식으로 확장하는 편이다.
예시 1. 고객 문의 관리 시스템 개선
현황
고객 문의가 전화, 이메일, 홈페이지 등 여러 채널을 통해 접수되고 있으며 담당자가 각각의 문의 내용을 별도로 관리하고 있다.
문제점
문의 정보가 여러 채널에 분산되어 있어 고객 문의 이력을 통합적으로 관리하기 어렵고, 담당자별 처리 방식의 차이로 인해 응답 시간이 길어지고 있다.
개선 필요성
문의 접수 및 처리 과정을 통합하여 고객 문의 현황을 실시간으로 확인하고 업무 처리 기준을 표준화할 필요가 있다.
예시 2. 사내 업무 프로세스 개선
현황
부서별로 엑셀 파일을 사용해 데이터를 관리하고 있으며 동일한 자료를 여러 시스템에 반복 입력하고 있다.
문제점
데이터 관리 방식이 표준화되어 있지 않고 수작업이 반복되면서 업무 시간이 증가하고 입력 오류가 발생할 가능성이 높다.
개선 필요성
업무 프로세스를 표준화하고 시스템 간 데이터를 연계하여 반복 업무를 줄일 필요가 있다.
예시 3. 교육 프로그램 운영 개선
현황
교육 프로그램은 매년 운영되고 있지만 교육 종료 후 만족도 조사 중심으로 성과를 확인하고 있다.
문제점
교육 참여자의 만족도는 확인할 수 있지만 실제 업무 역량 향상이나 교육 후 행동 변화까지 측정하기 어려워 프로그램의 실질적인 효과를 판단하기 어렵다.
개선 필요성
교육 전후의 역량 변화와 업무 적용 수준을 측정할 수 있는 성과지표를 마련할 필요가 있다.
👉 문제점을 작성할 때 피하면 좋은 표현
문제점을 작성하다 보면 다음과 같이 너무 추상적인 표현을 사용하기 쉽다.
- 관리가 제대로 이루어지지 않고 있다.
- 시스템이 비효율적이다.
- 고객 만족도가 낮다.
- 업무 환경에 문제가 있다.
이런 표현만으로는 정확히 무엇이 문제인지 파악하기 어렵다.
예를 들어 '시스템이 비효율적이다'라는 표현 대신 다음과 같이 구체적으로 작성할 수 있다.
제안서를 검토하는 사람도 해당 업무를 잘 알고 있기 때문에 막연하게 문제를 과장하기보다는 현재 확인할 수 있는 사실을 근거로 문제를 설명하는 방식이 더 설득력이 있었다.
마무리 하며
제안서의 문제점은 해결 방안을 제시하기 위한 출발점이다.
문제가 명확하게 정의되면 이후에 작성하는 목표, 추진 전략, 세부 실행 방안, 기대효과도 자연스럽게 연결된다. 반대로 문제 정의가 모호하면 좋은 아이디어를 제시하더라도 왜 이 방법이 필요한지 설명하기 어려워진다.
나는 제안서를 작성할 때 해결 방법을 바로 작성하기보다 먼저 현재 상황을 정리하고 현상 → 원인 → 영향 → 개선 필요성의 순서로 문제를 정리하려고 한다. 이렇게 한번 구조를 잡아두면 이후 페이지를 구성할 때도 내용이 훨씬 수월하게 이어졌다.
제안서의 문제점을 작성해야 한다면 먼저 현재 나타나는 현상을 구체적으로 적어보고, 왜 이런 상황이 발생했는지 원인을 찾아보는 것부터 시작해보면 좋다. 문제를 제대로 정의하는 것만으로도 제안서 전체의 논리가 훨씬 명확해질 수 있다.
댓글
댓글 쓰기