앱 개발 RFP나 웹 개발 제안요청서를 준비하는 기업·기관 담당자를 위한 RFP 작성법입니다. 요구사항 정리부터 검수·인수 조건까지 작성할 RFP 양식을 제공합니다. 같은 항목으로 작성하면 업체별 견적의 포함 범위와 전제 조건을 비교하기 쉽습니다.
DOCX의 회색 작성 안내를 참고해 사업 내용을 작성하고, 배포 전 안내 문장을 삭제하세요. 확정 사항과 미정 사항을 구분하고 기능 목록에는 첫 출시 포함 여부를 표시합니다.
가상 예시: 중견 유통사의 배송 기사용 앱과 관리자 웹. 아래 예시는 모두 이 가상 회사의 배송 업무를 기준으로 작성했습니다. 실제 고객 사례가 아니며, 예시 내용은 내려받는 양식에 미리 입력되어 있지 않습니다.
사업명, 추진 배경, 대상 업무와 도입 목적을 작성합니다.
내부 품의서와 제안요청서의 대상 업무가 맞는지 확인하세요. 도입 목적은 처리하려는 업무로 설명하고, 근거가 없는 개선 수치는 작성하지 않습니다.
사업명은 배송 기사용 앱 및 관리자 웹 구축입니다. 중견 유통사의 배송 배정, 기사별 작업 확인, 배송 결과 등록을 대상으로 합니다. 배송 결과와 미완료 사유를 같은 주문번호로 조회하는 것이 목적입니다.
지금 누가 어떤 문서나 시스템으로 업무를 처리하는지, 어느 조건에서 문제가 발생하는지 정리합니다.
업무 시작부터 완료까지 순서대로 작성하세요. 현재 쓰는 문서의 항목과 계속 유지할 승인 절차도 함께 정리합니다.
배송 담당자는 ERP에서 주문을 확인해 배차표를 작성하고 기사에게 전달합니다. 기사는 배송 결과를 메신저로 보고합니다. 배차 변경 시 기사에게 전달한 내용과 배차표가 달라질 수 있어, 최종 배정 내역을 확인하는 절차가 필요합니다. 배차 변경 승인은 배송 담당자가 맡습니다.
앱과 웹의 사용자 유형, 담당 업무, 조회 범위와 처리 권한을 작성합니다.
조회·수정·승인을 구분하세요. 담당자 변경이나 퇴사 시 계정과 권한을 누가 회수할지도 확인합니다.
배송 기사는 본인에게 배정된 주문을 조회하고 배송 완료 또는 미완료 사유를 등록합니다. 배송 담당자는 담당 물류센터의 주문을 조회하고 배차를 변경합니다. 운영 관리자는 계정을 발급하고 센터별 담당 권한을 설정합니다.
고객용 앱·웹과 관리자 기능을 나누고, 기능별 입력 내용과 처리 결과를 작성합니다. 현장 사용자용 앱이 있으면 별도 구분합니다.
기능 이름만 나열하지 말고 대상 데이터와 처리 조건을 작성하세요. 취소, 입력 오류, 중복 등록, 통신 단절 상황도 포함합니다. 필요 없는 사용자 채널은 제외로 표시합니다.
기사 앱은 배정된 배송 업무를 처리하고, 관리자 웹은 배차와 결과를 관리합니다. 고객용 앱·웹은 이번 발주 범위에서 제외합니다.
| 구분 | 기능 | 설명 | 첫 출시 포함 여부 |
|---|---|---|---|
| 기사 앱 | 배차 확인 | 본인에게 배정된 주문과 배송지를 조회 | 포함 |
| 기사 앱 | 배송 결과 등록 | 완료 상태 또는 미완료 사유를 등록하고 주문별 처리 결과를 확인 | 포함 |
| 관리자 웹 | 배차 변경 | 담당 센터 주문의 배정 기사를 변경하고 변경 이력을 조회 | 포함 |
| 관리자 웹 | 배송 결과 조회 | 기사·주문별 배송 상태와 미완료 사유를 조회 | 포함 |
| 관리자 웹 | 자동 배차 | 배송 조건에 따른 자동 배정 | 제외, 후속 검토 |
통신 단절 시 배송 결과를 기기에 임시 저장하고 재전송 상태를 표시하도록 요청합니다. 중복 전송은 주문번호와 작업 식별값으로 확인하며, 배차가 변경된 주문은 담당자 확인 대상으로 표시합니다.
첫 출시에서 처리할 업무, 후속 검토 기능, 이번 발주에서 제외할 범위를 구분합니다.
앞 항목의 기능 목록과 포함 여부를 맞추세요. 결정하지 못한 기능에는 확인 담당자와 결정 시점을 작성합니다.
첫 출시에는 배차 확인, 배송 결과 등록, 관리자 배차 변경과 결과 조회를 포함합니다. 자동 배차와 경로 추천은 후속 검토로 분류하고 이번 견적에서 제외합니다. 고객용 배송 조회 웹도 이번 발주 범위에서 제외합니다.
ERP, 지도, 알림 등 연동 대상과 주고받을 데이터, 방향, 처리 시점을 작성합니다.
연동 대상의 담당자, API 문서와 시험 환경 제공 여부를 확인하세요. 연동 방식을 모르면 확인 중으로 표시하고 제안에 필요한 자료를 요청합니다.
ERP에서 확정된 주문번호와 배송지를 앱 서버로 전달하고 앱 서버에서 배송 완료 상태를 ERP로 전달합니다. 주문번호로 중복 반영을 확인합니다. ERP 담당자가 API 문서와 시험 계정의 제공 가능 여부를 확인하며, 연동 실패 내역 조회와 재처리 방안을 제안서에 요청합니다.
새 시스템으로 이전할 데이터의 보관 위치, 형식, 규모와 이전 대상 기간을 작성합니다.
과거 기록의 조회와 업무 재처리 범위를 구분하세요. 정제·제공 담당자, 이전 결과 대조 기준과 실패 시 복구 방법도 정합니다.
거래처와 배송지 기준정보를 이전하고, 과거 배송 실적은 기존 ERP에서 조회합니다. ERP 담당자가 기준정보를 추출하고 배송 담당자가 중복 주소와 누락 항목을 정리합니다. 시험 이전 후 원본과 거래처 코드, 주소, 자료 건수를 대조합니다. 오류 시 원본으로 복구하는 절차를 제안받습니다.
개인정보 처리 항목, 역할별 접근 권한, 사내 보안 기준, 서버와 운영 담당을 확인합니다.
정해진 숫자를 복사하지 말고 계정 회수, 접속·변경 이력, 암호화, 보관·삭제, 백업·복구, 배포 승인과 장애 연락 절차를 확인하세요. 미정 사항에는 담당자를 지정합니다.
배송지와 수령인 연락처는 배정받은 기사와 담당 센터 직원에게만 표시합니다. 운영 관리자가 계정 발급과 회수를 맡습니다. 개인정보 보관·삭제 기준, 서버 설치 위치, 백업 복구 절차는 사내 IT 담당자가 확인하고 제안 전 공유합니다. 시험 데이터의 개인정보 마스킹과 관리자 변경 이력도 확인 항목에 포함합니다.
희망 일정과 확정된 제약을 나누고, 단계별 제출 자료와 검수 담당자, 통과 조건을 작성합니다.
개발 완료일 외에 요구사항 확정, 연동 시험, 사용자 검수와 인수 단계를 구분하세요. 어떤 입력을 했을 때 어느 화면과 데이터에서 무엇을 확인할지 작성합니다.
요구사항 확정 시 기능 목록과 화면안을 배송 담당자가 승인합니다. 연동 시험에서는 확정 주문이 기사 앱에 표시되고 배송 결과가 ERP에 반영되는지 확인합니다. 사용자 검수에서는 배차 변경 후 이전 기사의 조회가 차단되는지, 통신 복구 후 결과가 중복 없이 반영되는지 점검합니다. 보완 사항 재검수 후 인수 여부를 결정하며, 단계별 날짜는 ERP 시험 환경 제공 일정과 함께 확정합니다.
발주자가 요청할 문서·파일·계정과 전달 형식, 인수 시점, 인수 담당자를 작성합니다.
기능 정의서, 화면 설계서, 시험 결과서, 운영 매뉴얼 등을 요청 목록으로 정리하세요. 소스코드·디자인 원본·배포 자료를 요청한다면 제공 범위와 이용 권한, 외부 구성요소의 제약을 제안 및 계약 협의에서 확인합니다.
기능 정의서, 화면 설계서, 연동 명세서, 시험 결과서와 운영 매뉴얼을 요청합니다. 소스코드와 배포 절차 문서의 인수 가능 범위, 재사용 구성요소의 이용 조건도 제안서에 명시하도록 요청합니다. 배송 담당자는 업무 문서를, IT 담당자는 운영 계정과 기술 자료를 확인하며 인수 범위는 계약 협의에서 확정합니다.
구현 방안, 수행 인력, 일정, 항목별 견적, 제외 범위와 운영 지원 내용을 요청합니다. 평가 항목마다 판단 자료를 정합니다.
필수 요구사항의 충족 여부와 업체별 제안 내용을 비교하세요. 우선순위나 배점은 내부 선정 방식에 맞게 정하고 제안 요청 전에 공유합니다.
제안서에 기사 앱·관리자·ERP 연동별 구현 방안과 견적 내역을 요청합니다. 업무 이해도는 배차 변경과 미완료 처리 설명으로, 수행 역량은 유사 업무 경험과 담당 인력으로 확인합니다. 검수 계획과 인수 조건, 운영 지원 범위도 평가합니다. 필수 기능 누락 여부를 확인한 뒤 같은 포함 범위를 기준으로 견적을 비교합니다.
제출 기한, 접수 채널, 문서 형식, 담당 부서와 연락처, 질의 접수 및 답변 방법을 작성합니다.
공란을 그대로 배포하지 않도록 제출 안내를 확인하세요. 질의 답변으로 요구사항이 달라지면 같은 내용을 참여 업체에 공유하고 문서 버전을 구분합니다.
물류기획 담당자가 제안서와 견적서를 회사 지정 접수 채널로 받습니다. 파일명은 사업명_제안사명_문서명으로 지정합니다. 제안 요청 발송 전 제출 기한과 실제 문의 연락처를 확정합니다. 질의는 담당자가 취합하고 답변 및 변경된 요구사항은 참여 업체에 함께 전달합니다.
견적 요청서는 필요한 작업과 가격 산정 조건을 전달하는 데 초점을 둡니다. RFP는 사업 목적과 요구사항에 더해 수행 방법, 일정, 산출물, 평가 기준 등 업체가 제안할 내용까지 요청합니다. 문서 이름보다 실제 요청 범위를 확인하세요.
분량을 정해 놓고 작성할 필요는 없습니다. 업체가 같은 범위로 제안할 수 있도록 사용자, 기능, 연동, 검수 조건을 작성하세요. 화면안이나 기존 업무 자료가 있으면 첨부 문서로 연결할 수 있습니다.
사업 목적과 요구사항을 정리하는 항목은 참고할 수 있습니다. 공공기관 발주는 해당 공고와 기관의 지정 서식·절차를 확인하고, 민간기업 발주는 내부 구매·계약 기준에 맞춰 작성하세요. 이 양식만으로 기관별 필수 문서를 대신할 수는 없습니다.
발주 범위와 제출 조건에 맞게 수정한 뒤 사용하세요. 회색 작성 안내를 삭제하고 빈 항목, 미정 사항, 문의처를 확인해야 합니다. 해당 없는 항목은 삭제하거나 해당 없음과 사유를 표시합니다.
확정한 내용부터 작성하고 미정 항목에는 확인 담당자와 결정 시점을 표시하세요. 첫 출시 포함 여부를 정하지 못한 기능은 확정 범위와 구분해 업체가 견적의 전제 조건을 명시하도록 요청합니다.
작성법과 같은 순서의 DOCX 양식입니다. 작성 안내와 빈 표를 사업 내용에 맞게 수정해 사용하세요.
요구사항을 정리하다 막힌 항목은 케이엠웍스와 함께 검토할 수 있습니다. 작성 중인 기능 목록이나 연동·검수 항목 중 확인이 필요한 부분을 알려 주세요.
무료 상담 신청