기본 콘텐츠로 건너뛰기

제안서에서 개선방안 작성하는 법|문제점에서 해결방안 도출하기

제안서에서 개선방안 작성하는 법
제안서에서 개선방안 작성하는 법


제안서에서 개선방안 작성하는 법

제안서를 작성하다 보면 문제점까지는 비교적 잘 정리했는데, 그다음 개선방안을 작성하는 단계에서 막히는 경우가 있다. 문제를 발견한 것과 그 문제를 어떻게 해결할 것인지 정리하는 것은 또 다른 작업이기 때문이다.

나도 제안서나 기획 문서를 작성할 때 문제점을 먼저 적어놓고 그에 맞는 해결방안을 붙이려고 했던 적이 많았다. 그런데 이렇게 작성하면 문제와 개선방안이 정확하게 연결되지 않는 경우가 있었다. 문제는 A인데 해결방안은 B를 제시하고 있는 식이다.

그래서 개선방안을 작성할 때는 먼저 문제의 원인을 한 번 더 확인하고, 그 원인을 줄이거나 없앨 수 있는 방법을 찾는 방식으로 정리하는 것이 좋다.

이번 포스팅에서는 제안서에서 문제점과 개선방안을 연결하는 방법, 개선방안 작성하는 법, 그리고 실제 문서에서 활용할 수 있는 예시를 정리해봤다.


01. 문제점과 개선방안은 어떻게 연결할까?

제안서에서 개선방안은 문제점에 대한 답이 되어야 한다. 단순히 좋아 보이는 아이디어를 제시하는 것이 아니라, 현재 발생하고 있는 문제의 원인을 해결할 수 있어야 한다.

나는 보통 문제점 → 원인 → 개선방안의 순서로 연결해서 생각한다.


👉 문제점만 보고 바로 해결책을 정하지 않는다

예를 들어 고객 문의 처리 시간이 오래 걸린다는 문제가 있다고 가정해보자.

이 문제만 보고 바로 '고객 관리 시스템을 도입한다'고 작성할 수도 있다. 하지만 실제 원인이 무엇인지 확인하지 않으면 이 해결책이 적절한지 판단하기 어렵다.

처리 시간이 오래 걸리는 원인은 다음처럼 여러 가지일 수 있다.

  • 문의 접수 채널이 여러 곳으로 분산되어 있다.
  • 담당자별 처리 기준이 다르다.
  • 문의 이력을 수기로 관리하고 있다.
  • 담당자 배정이 늦어지고 있다.
문제점
고객 문의 처리 시간이 오래 걸리고 있다.

같은 문제라도 원인이 다르면 개선방안도 달라져야 한다.


원인
전화, 이메일, 홈페이지 등 문의 접수 채널이 분산되어 있고 담당자가 각각의 문의를 별도로 관리하고 있다.

개선방안
여러 채널에서 접수되는 고객 문의를 하나의 시스템에서 통합 관리하고 담당자별 처리 현황을 실시간으로 확인할 수 있도록 업무 프로세스를 개선한다.

이렇게 문제점과 원인을 먼저 정리해두면 개선방안을 훨씬 구체적으로 작성할 수 있다.


👉 개선방안은 문제의 원인을 해결해야 한다

제안서를 작성할 때 새로운 시스템 도입, 프로세스 개선, 교육 실시처럼 익숙한 해결책을 먼저 생각하기 쉽다. 하지만 해결책 자체보다 중요한 것은 왜 이 방법이 필요한지 설명할 수 있는가이다.

문제점과 개선방안을 나란히 놓고 봤을 때 자연스럽게 이어지지 않는다면 원인 분석이나 개선방안을 다시 확인해보는 것이 좋다.


02. 제안서 개선방안 작성하는 법

개선방안은 '개선한다', '강화한다', '효율화한다'처럼 추상적인 표현만 사용하면 실제로 무엇을 하겠다는 것인지 알기 어렵다.

나는 개선방안을 작성할 때 원인을 구체화한 뒤 개선 방향을 정하고, 마지막으로 실행할 수 있는 형태의 문장으로 바꾸는 순서를 사용한다.


1) 문제의 원인을 구체적으로 정리한다

먼저 문제점이 발생한 이유를 구체적으로 적어본다.

예를 들어 '업무 효율이 낮다'는 문제점만으로는 개선방안을 만들기 어렵다. 어떤 부분 때문에 업무 효율이 낮아졌는지를 찾아야 한다.

  • 동일한 데이터를 여러 시스템에 반복 입력하고 있다.
  • 담당자별로 다른 양식을 사용하고 있다.
  • 업무 진행 상황을 수기로 관리하고 있다.

원인이 구체적일수록 개선방안 역시 구체적으로 작성할 수 있다.


2) 개선 방향을 먼저 정한다

원인을 확인한 다음에는 어떤 방향으로 개선할 것인지 정한다.

예를 들어 위와 같은 문제가 있다면 다음과 같은 개선 방향을 생각할 수 있다.

  • 중복 입력 최소화
  • 업무 양식 표준화
  • 업무 진행 현황 통합 관리

이 단계에서는 문장을 길게 작성하기보다 핵심 방향을 짧은 키워드로 먼저 잡아두는 것이 편했다.


3) 실제 실행할 수 있는 내용으로 작성한다

마지막으로 개선 방향을 실제 제안서에 들어갈 수 있는 문장으로 바꾼다.

예를 들어 '업무 효율화'라고만 작성하는 것보다 다음처럼 작성할 수 있다.

부서별로 분산되어 있는 업무 양식을 표준화하고, 반복 입력되는 데이터를 시스템 간 연계하여 수작업을 줄인다.

이렇게 작성하면 무엇을 어떻게 개선하겠다는 것인지 한눈에 알 수 있다.


4) 추상적인 표현은 한 단계 더 구체화한다

개선방안을 작성할 때 다음과 같은 표현을 자주 사용한다.

  • 관리 체계를 강화한다.
  • 업무 효율성을 높인다.
  • 고객 서비스를 개선한다.
  • 성과 관리 체계를 구축한다.
애매한 표현
고객 문의 관리 체계를 강화한다.

이런 표현이 틀린 것은 아니지만, 그 문장만으로는 실제 실행 내용을 알기 어렵다.

가능하면 무엇을, 어떤 방식으로 바꿀 것인지를 한 단계 더 붙여주는 것이 좋다.


구체적인 표현
고객 문의 접수 채널을 통합하고 문의 유형별 담당자 배정 기준과 처리 절차를 표준화하여 문의 관리 체계를 개선한다.


03. 개선방안 도출 예시

실제 제안서에서는 문제점과 개선방안이 서로 연결되어 있다는 것이 한눈에 보여야 한다.

문제점, 원인, 개선방안을 순서대로 정리해두면 이후 추진 전략이나 세부 실행계획을 작성할 때도 활용하기 쉽다.


👉 예시 1. 고객 문의 관리 개선

문제점

고객 문의가 전화, 이메일, 홈페이지 등 여러 채널로 분산되어 있어 문의 이력과 처리 현황을 통합적으로 확인하기 어렵다.

원인

문의 채널별로 별도의 관리 방식을 사용하고 있으며 담당자별 처리 기준도 다르게 운영되고 있다.

개선방안

문의 접수 채널을 통합하고 문의 유형별 담당자 배정 및 처리 절차를 표준화하여 고객 문의를 일관되게 관리할 수 있는 체계를 구축한다.


👉 예시 2. 사내 업무 프로세스 개선

문제점

동일한 데이터를 여러 시스템에 반복 입력하고 있어 업무 시간이 증가하고 입력 오류가 발생할 가능성이 높다.

원인

시스템 간 데이터가 연동되지 않고 부서별로 다른 관리 양식을 사용하고 있다.

개선방안

시스템 간 데이터 연계 기능을 구축하고 공통 업무 양식을 적용하여 반복 입력을 줄이고 데이터 관리 방식을 표준화한다.


👉 예시 3. 교육 프로그램 운영 개선

문제점

교육 종료 후 만족도 조사만 실시하고 있어 교육을 통해 실제 역량이 얼마나 향상되었는지 확인하기 어렵다.

원인

교육 전후의 역량 변화나 업무 적용 수준을 측정할 수 있는 별도의 성과지표가 마련되어 있지 않다.

개선방안

교육 전후 역량 평가와 교육 후 업무 적용도를 측정할 수 있는 지표를 마련하여 만족도뿐만 아니라 교육의 실질적인 성과를 함께 관리한다.


👉 문제점과 개선방안을 1:1로 확인한다

문제를 여러 개 작성했다면 각 문제마다 대응되는 개선방안이 있는지 확인하는 것도 중요하다.

예를 들어 문제점은 세 가지인데 개선방안은 하나만 제시되어 있거나, 반대로 개선방안은 많은데 어떤 문제를 해결하기 위한 것인지 명확하지 않다면 제안서의 논리가 약해질 수 있다.

나는 문서를 검토할 때 문제점과 개선방안을 나란히 놓고 하나씩 연결되는지 확인하는 편이다. 이렇게 확인하면 빠진 내용도 쉽게 찾을 수 있고, 필요하지 않은 해결방안도 정리하기 쉬웠다.


마무리 하며

제안서에서 개선방안은 단순히 새로운 아이디어를 제시하는 항목이 아니다. 앞에서 정리한 문제점과 원인을 실제로 해결할 수 있는 방법을 보여주는 부분이다.

따라서 개선방안을 작성할 때는 먼저 문제의 원인을 구체적으로 확인하고, 문제점 → 원인 → 개선 방향 → 구체적인 개선방안의 순서로 정리하는 것이 좋다.

특히 '개선한다', '강화한다', '효율화한다'처럼 추상적인 표현으로 끝내기보다 무엇을 어떤 방식으로 바꿀 것인지까지 작성하면 제안 내용이 훨씬 명확해진다.

문제점과 개선방안이 자연스럽게 연결되면 이후에 작성하는 추진 전략, 실행계획, KPI, 기대효과까지 논리적으로 이어가기 쉬워진다. 제안서를 작성할 때 개선방안이 잘 떠오르지 않는다면 새로운 아이디어부터 찾기보다 먼저 문제의 원인을 다시 살펴보는 것부터 시작해보면 좋다.


함께 보면 좋은 글

댓글

이 블로그의 인기 게시물

정성적 목표와 정량적 목표 차이|작성 방법과 예시

제안서나 사업계획서를 작성하다 보면 목표를 정리해야 하는 경우가 많다. 이때 자주 등장하는 표현이 정성적 목표와 정량적 목표이다. 둘 다 프로젝트가 어떤 결과를 만들고자 하는지 보여주는 항목이지만, 작성하는 방식에는 차이가 있다. 정량적 목표는 숫자로 측정할 수 있는 결과를 중심으로 작성하고, 정성적 목표는 숫자로 표현하기 어려운 변화나 방향을 중심으로 작성한다. 둘 중 어느 것이 더 좋다기보다는 프로젝트의 성격에 따라 정성적 목표와 정량적 목표를 선택 또는 함께 사용한다. 이번 포스팅에서는 정성적 목표와 정량적 목표의 차이와 작성 방법, 실제 문서에서 활용할 수 있는 예시를 정리해봤다. 정성적 목표란? 정성적 목표는 숫자로 바로 측정하기 어려운 변화나 상태를 의미한다. 단순히 수치를 제시하기보다 프로젝트를 통해 어떤 변화나 개선을 만들고 싶은지 방향을 나타내는 데 의미를 둔다. 서비스 품질 향상, 고객 만족도 개선, 업무 효율성 강화, 조직 역량 향상처럼 프로젝트를 통해 만들고 싶은 방향을 표현할 때 주로 사용한다. 예를 들어 직원 교육 프로그램을 운영한다고 가정해보자. ✔️  직원의 업무 역량을 강화한다. 이 문장은 구체적인 숫자는 없지만 교육을 통해 어떤 변화를 만들고 싶은지 알 수 있다. 이런 형태가 정성적 목표에 해당한다. 정성적 목표는 프로젝트의 방향을 보여주기에는 좋지만, 표현이 너무 추상적이면 실제 성과를 판단하기 어렵다는 단점도 있다. 따라서 '강화한다', '개선한다', '활성화한다'와 같은 표현만 사용하는 것보다는 무엇을 어떻게 변화시키고 싶은지 조금 더 구체적으로 작성하는 것이 좋다.  정량적 목표란? 정량적 목표는 수치로 확인하고 측정할 수 있는 목표이다. 매출, 이용자 수, 참여율, 처리시간, 비용 절감률, 만족도 점수처럼 숫자로 나타낼 수 있는 지표를 사용한다. 예를 들어 같은 직원 교육 프로그램이라면 다음과 같이 작성할 수 있다. ✔️  교육 참여율 90% 이상 달성 ✔️  교육 후 업무 이...

SWOT 분석 하는 법|뜻과 작성 방법, 분석, 전략도출 예시

SWOT 분석 경영을 전공하고 전략기획팀에서 근무하며 쌓은 경험을 바탕으로 SWOT 분석 방법과 예시를 정리해 봤다. 예시에는 분석 과정부터 전략 도출까지 담았다. SWOT 분석은 기업의 강점과 약점뿐만 아니라 외부 환경에서 찾을 수 있는 기회와 위협까지 함께 정리하는 방법이다. 사업계획서, 제안서, 마케팅 전략, 취업 비 등 다양한 상황에서 활용할 수 있다. SWOT 분석을 통해 현재 상황을 객관적으로 파악할 수 있고, 이를 토대로 프로젝트의 전략을 세운다. SWOT 분석이란? SWOT 분석은 조직이나 프로젝트의 내부 환경과 외부 환경을 분석하는 방법이다. SWOT은 다음 네 가지 단어의 앞 글자를 의미한다. ✔️ S trengths: 강점 ✔️ W eaknesses: 약점 ✔️ O pportunities: 기회 ✔️ T hreats: 위협 강점, 약점은 기업이나 조직 내부 에서 찾을 수 있는 요소이며, 기회와 위협은 경쟁 환경 같은 외부 요인 이 해당한다. 분석을 진행할 때 네 가지 항목에 생각나는 내용을 단순히 나열하는 것만으로는 충분하지 않다. 각 요소를 구분한 뒤 서로 연결해 실제 전략까지 도출해야 SWOT 분석의 의미가 있다. 예를 들어 직원의 전문성이나 높은 품질은 내부 강점이 될 수 있다. 반면 시장의 환경 변화, 정부 지원 정책은 조직이 직접 통제하기 어려운 외부 기회에 해당한다. SWOT 분석을 할 때는 먼저 내부 요인과 외부 요인을 정확하게 구분하는 것이 중요하다. SWOT 분석 4가지 요소 1. Strengths|강점 강점은 경쟁사와 비교했을 때 기업이나 프로젝트가 잘하고 있는 부분이다. 단순히 긍정적인 특징을 적는 것이 아니라, 고객이 선택할 만한 이유나 목표 달성이 도움이 되는 역량을 찾아야 한다. 강점 예시 ✔️ 높은 제품 품질 ✔️ 전문 인력 보유 ✔️ 자체 기술 또는 특허 보유 ✔️ 안정적인 유통망 ✔️ 빠른 고객 대응 2. Weaknesses|약점 약점은 기업 내부에서 개선이 필요한 부분이다. 경쟁사보다 부족한 요소나 목표 달...

맨먼스 계산하기 | 인력 비용 단가 기준, 계산 예시

맨먼스 계산하기 제안서나 사업계획서를 작성하다 보면 프로젝트에 필요한 인력 비용을 산정해야 하는 경우가 있다. 개발자, 기획자, UI/UX 디자이너 등 여러 인력이 투입되는 프로젝트라면 단순히 총금액만 작성하기보다 어떤 인력이 얼마 동안 투입되는지를 함께 정리하는 것이 중요하다. 특히 클라이언트 입장에서는 제안된 비용이 어떤 기준으로 계산되었는지 확인할 수 있어야 한다. 동일한 프로젝트라도 투입되는 인원의 수, 기간, 업무 비중에 따라 인력 비용이 달라질 수 있기 때문이다. 따라서 비용 산정 근거를 구체적으로 보여주는 것은 제안서의 신뢰도를 높이는 데 도움이 된다. 이때 활용할 수 있는 개념이 맨먼스(Man Month) 이다. 맨먼스를 이용하면 프로젝트에 몇 명의 인력이 얼마 동안 투입되는지 정리할 수 있고, 이를 바탕으로 전체 인력 비용도 계산할 수 있다. 실무에서는 프로젝트 수행 인력을 계획하거나 견적을 작성할 때 자주 활용되는 방식이다. 이번 포스팅에서는 맨먼스 정의, 단가 기준, 계산 예시, 주의 사항에 대해 정리했다.   01. 맨먼스(Man Month)란? 맨먼스는 프로젝트에 투입되는 인력의 작업량을 월 단위로 나타낸 것이다. Man Month 또는 M/M으로 표현한다. 쉽게 말하면 한 사람이 한 달 동안 프로젝트에 100% 투입되는 경우를 1M/M으로 볼 수 있다. 예를 들어 앱 개발 프로젝트를 진행한다고 가정해 보자. 1명이 5개월 동안 투입된다면 → 5M/M 5명이 1개월 동안 투입된다면 → 5M/M 2명이 3개월 동안 투입된다면 → 6M/M 이처럼 맨먼스는 단순히 사람 수를 의미하는 것이 아니라 인원과 투입 기간을 함께 고려한 전체 작업량 을 의미한다. 그래서 프로젝트 규모를 비교하거나 전체 인력 비용을 계산할 때 유용하게 사용할 수 있다. 프로젝트에 100% 투입되지 않고 다른 ...