기업 비즈니스 솔루션은 요구사항 정의서에서 성패가 갈립니다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

“우리 회사에 필요한 기능을 적어 주세요”라는 요청을 받고 곧바로 제품 목록부터 검색하고 있나요? 기업 비즈니스 솔루션을 처음 도입할 때 가장 흔한 실수는 유명한 서비스와 많은 기능을 먼저 비교하는 것입니다. 하지만 같은 솔루션도 업무 목적과 요구사항이 분명한 기업에서는 성과를 내고, 기준이 모호한 기업에서는 비용만 늘릴 수 있습니다.

초보 담당자에게 필요한 출발점은 복잡한 기술 지식이 아니라 ‘누가, 어떤 업무에서, 무엇 때문에 불편한가’를 문서로 만드는 일입니다. 이 글에서는 요구사항 정의서를 처음 작성하는 단계부터 기능 우선순위, 비용 범위, 공급사 검증, FAQ와 실제 적용 사례까지 차근차근 설명합니다.

비즈니스 솔루션보다 업무 문제를 먼저 정의합니다

솔루션은 제품이 아니라 문제 해결 수단입니다

비즈니스 솔루션은 회계, 영업, 고객 관리, 협업, 인사, 재고처럼 기업의 반복 업무를 더 정확하고 빠르게 처리하도록 돕는 도구입니다. 비즈니스의 기본 개념을 넓게 보면 기업 활동에는 생산과 판매뿐 아니라 이를 지원하는 관리 과정도 포함됩니다. 따라서 솔루션 도입은 프로그램 하나를 구매하는 일이 아니라 업무 흐름을 다시 설계하는 프로젝트에 가깝습니다.

예를 들어 영업팀이 “CRM이 필요하다”고 말해도 실제 문제는 서로 다를 수 있습니다. 고객 연락 기록을 찾지 못하는 것인지, 견적 후 후속 연락이 누락되는 것인지, 영업 실적 집계에 사흘이 걸리는 것인지부터 구분해야 합니다. 문제를 구체화하지 않으면 필요하지 않은 기능까지 계약하거나 정작 중요한 자동 알림 기능을 빠뜨릴 가능성이 큽니다.

한 문장 문제 정의부터 시작합니다

문제는 ‘현재 상태, 불편, 기대 변화’가 드러나도록 한 문장으로 작성합니다. “영업 관리가 불편하다”보다 “담당자별 엑셀에 고객 이력이 흩어져 있어 인수인계에 이틀이 걸리므로, 한 화면에서 상담 이력을 검색할 수 있어야 한다”가 훨씬 좋은 정의입니다. 이 문장은 나중에 제품 시연을 평가하는 기준으로도 사용할 수 있습니다.

• 사용자: 실제로 입력하고 조회할 부서와 담당자는 누구인가?
• 현재 방식: 엑셀, 메신저, 이메일 중 무엇을 사용하고 있는가?
• 반복되는 손실: 시간 지연, 입력 오류, 중복 작업 중 무엇이 발생하는가?
• 목표 상태: 도입 후 처리 시간이나 오류율이 어느 수준으로 달라져야 하는가?
• 제약 조건: 예산, 일정, 보안 정책, 기존 시스템 중 반드시 지켜야 할 것은 무엇인가?

처음부터 완벽한 제품명을 찾으려 하지 마세요. 좋은 요구사항은 특정 제품을 지목하는 문장이 아니라 여러 제품을 같은 기준으로 평가할 수 있게 만드는 문장입니다.

요구사항 정의서는 다섯 가지 항목이면 시작할 수 있습니다

현업의 표현을 검증 가능한 문장으로 바꿉니다

요구사항 정의서라고 하면 수십 장짜리 문서를 떠올리기 쉽지만, 첫 버전은 표 한 장으로도 충분합니다. 핵심은 기능 이름을 많이 나열하는 것이 아니라 요구사항마다 사용자, 발생 상황, 기대 결과, 중요도, 확인 방법을 기록하는 것입니다. 이 다섯 항목이 있으면 담당자가 바뀌어도 같은 의미로 이해할 수 있습니다.

“모바일 지원”이라는 요구는 사람마다 다르게 해석됩니다. 모바일 웹에서 조회만 하면 되는지, 현장에서 사진을 첨부해야 하는지, 인터넷이 끊겨도 임시 저장되어야 하는지에 따라 비용과 구현 난도가 크게 달라집니다. “외근 직원이 휴대전화에서 고객 정보를 조회하고 방문 결과와 사진을 등록할 수 있어야 한다”처럼 행동과 결과를 함께 적어야 공급사도 정확하게 답할 수 있습니다.

요구사항 표를 직접 작성해 봅니다

문서는 혼자 완성하지 말고 현업 인터뷰로 검증해야 합니다. 업무를 지시하는 팀장과 실제 데이터를 입력하는 실무자의 답이 다를 수 있기 때문입니다. 하루 업무를 시간 순서로 설명해 달라고 요청한 뒤, 반복 입력과 승인 대기, 파일 재가공이 발생하는 지점을 표시하면 숨은 요구사항을 발견하기 쉽습니다.

1. 현재 업무를 시작부터 종료까지 5~10단계로 나눕니다.
2. 각 단계의 입력 자료, 담당자, 결과물을 적습니다.
3. 같은 정보를 두 번 입력하는 구간에 표시합니다.
4. 오류가 자주 생기거나 특정 직원에게 의존하는 지점을 찾습니다.
5. 개선 필요성을 시간, 건수 또는 금액으로 수치화합니다.

온라인 환경에서 주문, 계약, 고객 응대가 연결되는 기업이라면 이비즈니스의 개념과 범위도 참고할 수 있습니다. 업무가 어디까지 디지털로 이어지는지 이해하면 영업 솔루션만 볼지, 주문·정산 과정까지 함께 볼지 범위를 정하기 수월합니다.

필수 기능과 희망 기능을 나누면 예산이 선명해집니다

우선순위는 사용 빈도와 손실 규모로 정합니다

초보 담당자가 만든 요구사항에는 대개 모든 항목이 ‘필수’로 표시됩니다. 그러나 예산과 일정은 제한되어 있으므로 우선순위가 없는 요구사항은 실제 의사결정에서 힘을 발휘하지 못합니다. 하루에 여러 번 사용하는 기능, 법적·보안상 필요한 기능, 누락될 때 매출이나 고객 신뢰에 직접 영향을 주는 기능부터 필수로 분류해야 합니다.

반대로 있으면 편리하지만 기존 방식으로 당분간 처리할 수 있는 항목은 희망 기능으로 둡니다. 예를 들어 고객 상담 기록 통합은 필수지만 보고서 색상 변경은 희망일 수 있습니다. 필수 기능은 적을수록 평가 기준이 또렷해지고, 희망 기능은 단계적으로 추가할수록 초기 비용과 교육 부담을 낮출 수 있습니다.

표시 가격 밖의 총비용을 계산합니다

SaaS 서비스는 사용자당 월 몇만 원 수준에서 시작하는 경우가 있지만, 실제 견적은 사용자 수와 기능 등급, 저장 용량, 연동 범위, 교육 및 기술지원 조건에 따라 달라집니다. 구축형 역시 초기 개발비만 보면 안 됩니다. 서버나 클라우드 인프라, 데이터 정제, 유지보수, 보안 점검, 버전 업그레이드까지 포함한 총소유비용을 최소 3년 기준으로 계산하는 편이 안전합니다.

• 기본 구독료 또는 라이선스 비용
• 초기 설정과 업무 프로세스 구성 비용
• 기존 엑셀·시스템 데이터 정제 및 등록 비용
• ERP, 그룹웨어, 쇼핑몰 등 외부 서비스 연동 비용
• 관리자 교육과 일반 사용자 교육 비용
• 추가 저장 공간, 백업, 보안 인증 관련 비용
• 계약 종료 시 데이터 추출 또는 이전 비용

가격을 비교할 때는 같은 조건으로 1년 차와 2~3년 차를 따로 계산해 보세요. 초기 할인 종료 후 요금이 달라질 수 있고, 사용자가 증가하면 상위 요금제가 필요할 수도 있습니다. TS컴퍼니와 같은 기업 맞춤형 비즈니스 솔루션 파트너에게 상담할 때도 ‘저렴한 제품’을 요청하기보다 사용자 수, 필수 기능, 예상 데이터량, 연동 대상과 지원 범위를 전달해야 현실적인 비용을 받을 수 있습니다.

견적서의 숫자보다 중요한 질문은 “이 금액에 무엇이 포함되지 않았습니까?”입니다. 제외 항목을 확인해야 후보 간 비용을 같은 기준으로 비교할 수 있습니다.

제품 시연과 계약 전에는 실제 업무로 검증합니다

준비된 화면 대신 우리 회사 시나리오를 요청합니다

공급사가 준비한 시연은 제품의 강점을 보여주는 데 최적화되어 있습니다. 화면이 매끄럽다고 해서 우리 회사 업무도 같은 속도로 처리되는 것은 아닙니다. 요구사항 정의서에서 중요도가 높은 업무 세 가지를 골라 샘플 데이터로 직접 수행해 달라고 요청하세요. 담당자가 고객을 등록하고, 견적을 승인받고, 실적 보고서를 만드는 전 과정을 보면 클릭 수와 예외 처리 방식까지 확인할 수 있습니다.

이때 단순히 “지원합니다”라는 답만 기록하면 부족합니다. 기본 기능인지 추가 개발인지, 관리자 설정으로 바꿀 수 있는지, 모바일에서도 동일하게 작동하는지 구분해야 합니다. 관련 용어를 영문 자료에서 확인해야 한다면 business 용어 설명처럼 개념 자료를 함께 참고하면 공급사 문서의 표현을 이해하는 데 도움이 됩니다.

1. 시나리오 준비: 현업에서 자주 발생하는 정상 업무 두 건과 예외 업무 한 건을 선정합니다.
2. 직접 조작: 공급사 설명만 듣지 말고 실제 사용자에게 화면을 조작하게 합니다.
3. 시간 측정: 현재 방식과 솔루션 방식의 처리 시간을 각각 기록합니다.
4. 증빙 확보: 지원 여부와 추가 비용을 제안서나 이메일로 남깁니다.
5. 사용자 평가: 편의성, 정확성, 학습 난도를 동일한 점수표로 평가합니다.

초보 담당자가 자주 묻는 질문

Q. 요구사항은 몇 개가 적당한가요?
기업 규모보다 도입 범위가 기준입니다. 첫 도입이라면 핵심 업무 한 영역에 집중해 필수 요구사항 10~20개부터 만드는 것이 현실적입니다. 항목이 100개를 넘는다면 업무 범위가 너무 넓거나 비슷한 요구가 중복되었는지 살펴보세요.

Q. 무료 체험만으로 결정해도 될까요?
개인 사용 편의는 확인할 수 있지만 권한 관리, 대량 데이터 처리, 연동, 장애 대응은 무료 체험에서 충분히 검증하기 어렵습니다. 실제 사용자 일부가 참여하는 소규모 시험 운영을 진행하고, 공급사의 지원 절차와 응답 시간도 함께 확인하는 편이 좋습니다.

Q. 계약서에서 꼭 확인할 내용은 무엇인가요?
서비스 수준, 장애 통지, 백업과 복구, 개인정보 처리, 데이터 소유권, 계약 종료 후 반출 형식, 자동 갱신 및 해지 조건을 확인해야 합니다. 맞춤 개발이 있다면 산출물의 권리와 유지보수 범위, 요구 변경 시 비용 산정 방식도 명확히 적어야 합니다.

• 데이터를 CSV나 표준 형식으로 내려받을 수 있는가?
• 관리자와 일반 사용자의 권한을 세분화할 수 있는가?
• 장애가 발생했을 때 접수 채널과 목표 응답 시간은 얼마인가?
• 요금 인상이나 기능 종료 시 사전 통지 기간이 정해져 있는가?
• 맞춤 설정을 누가 관리하며 담당자 퇴사 시 인수인계가 가능한가?

견적 지연이 반복되던 유통팀은 한 장의 문서로 바뀌었습니다

막연한 자동화 요청을 세 가지 요구로 좁혔습니다

직원 35명의 생활용품 유통기업 A사는 거래처 견적 요청을 이메일로 받고 엑셀로 단가를 계산했습니다. 영업 담당자는 “견적 자동화 솔루션이 필요하다”고 생각했지만, 처음 받은 세 곳의 제안은 기능과 가격 범위가 달라 비교조차 어려웠습니다. 한 업체는 CRM 중심이었고, 다른 업체는 ERP 전체 교체를 제안했으며, 맞춤 개발사는 자동화 범위를 다시 알려 달라고 요청했습니다.

A사는 제품 선정을 잠시 멈추고 일주일 동안 견적 업무를 관찰했습니다. 확인 결과 가장 큰 문제는 계산 자체가 아니었습니다. 최신 단가표가 담당자별 폴더에 흩어져 있었고, 할인 승인을 메신저로 받아 누락되었으며, 발송된 견적의 후속 연락일이 관리되지 않았습니다. 팀은 목표를 견적 작성 시간 단축, 할인 승인 기록 보존, 후속 연락 누락 방지로 좁혔습니다.

1. 상품 코드 입력 시 승인된 최신 단가를 자동으로 불러옵니다.
2. 기준 할인율을 넘으면 팀장 승인 전 발송할 수 없게 합니다.
3. 견적 발송 후 3영업일이 지나면 담당자에게 알림을 보냅니다.
4. 거래처별 견적 이력과 승인자를 한 화면에서 조회합니다.
5. 월말에는 견적 건수와 수주 전환율을 파일 재가공 없이 확인합니다.

동일한 시험 과제로 후보를 평가했습니다

팀은 필수 요구 다섯 개와 희망 요구 네 개를 표로 만들고, 후보 솔루션마다 같은 거래처·상품 데이터를 제공했습니다. 시연에서는 정상 견적뿐 아니라 재고가 없는 상품, 할인율 초과, 승인자 부재 상황도 시험했습니다. 그 결과 화려한 분석 화면을 제공한 후보보다 승인 규칙을 관리자 설정으로 변경할 수 있고, 기존 회계 프로그램과 주문 데이터를 주고받기 쉬운 후보가 더 높은 점수를 받았습니다.

비용도 월 구독료만 보지 않았습니다. 사용자 12명, 초기 데이터 정리, 회계 프로그램 연동, 관리자 교육, 3년간 예상 인상분을 합산했습니다. 고급 기능이 많은 상위 요금제 대신 필수 기능이 포함된 중간 요금제와 제한된 연동 범위를 선택해 초기 부담을 낮췄고, 고급 수요 예측은 운영 6개월 후 데이터 품질을 확인한 뒤 검토하기로 했습니다.

• 도입 첫 주: 영업 담당자 3명이 기존 방식과 솔루션을 병행했습니다.
• 둘째 주: 잘못된 단가와 승인 알림 문제를 수정했습니다.
• 셋째 주: 사용자 교육 후 전체 영업팀으로 범위를 넓혔습니다.
• 첫 달 말: 평균 견적 작성 시간과 승인 누락 건수를 측정했습니다.
• 다음 달: 후속 연락 알림 사용률을 확인하고 알림 시점을 조정했습니다.

A사는 견적 작성 시간을 건당 약 25분에서 9분으로 줄였고, 메신저에서 사라지던 할인 승인 내역도 거래처 기록에 남길 수 있었습니다. 특히 처음 요청했던 ‘모든 견적 자동화’를 그대로 추진하지 않고 오류 가능성이 높은 단가 조회와 승인 흐름부터 개선한 것이 효과적이었습니다. 이후에는 한 달간 축적된 질문을 바탕으로 도움말을 보완하고, 사용 빈도가 낮았던 대시보드 하나를 제거해 화면도 단순하게 만들었습니다.

이 사례에서 출발점은 특정 제품이나 기술이 아니었습니다. 문제를 관찰하고, 검증 가능한 요구로 바꾸고, 실제 업무로 시험한 과정이 기업에 맞는 서비스를 찾게 했습니다. 처음 솔루션을 맡았다면 지금 사용하는 엑셀이나 메신저를 없애겠다는 목표보다, 내일 가장 먼저 처리할 업무 한 건을 골라 사용자·불편·기대 결과·확인 방법을 한 줄씩 적어 보세요. 그 한 장이 TS컴퍼니에 상담을 요청하거나 여러 비즈니스 솔루션을 평가할 때 가장 실용적인 출발 자료가 됩니다.