처음 기업 비즈니스 서비스를 고르는 담당자라면 요구사항부터

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

새 솔루션을 알아보라는 업무를 맡았는데 어디서부터 손대야 할지 막막한가요? 검색창에 ‘기업 비즈니스 서비스’를 입력하면 협업, 보안, 회계, 고객관리, 자동화처럼 서로 다른 제품이 한꺼번에 등장합니다. 이때 유명한 제품부터 비교하면 정작 우리 회사가 해결해야 할 문제가 뒤로 밀리기 쉽습니다.

초보 담당자가 가장 먼저 해야 할 일은 제품 선택이 아니라 요구사항 정의입니다. 이 글에서는 필요한 기능을 찾는 법부터 공급사 문의, 체험 운영, 계약 직전 확인 사항까지 실제 업무 순서에 맞춰 설명합니다.

제품을 찾기 전에 해결할 업무부터 한 문장으로 적습니다

서비스 이름이 아닌 문제를 정의하는 법

‘CRM이 필요하다’는 말은 요구사항이 아닙니다. 왜 필요한지, 누가 어떤 상황에서 불편한지, 개선 결과를 무엇으로 판단할지가 빠져 있기 때문입니다. 예를 들어 ‘영업팀이 고객 상담 이력을 개인 파일로 관리해 담당자 부재 시 후속 연락이 늦어진다’라고 적으면 필요한 기능과 사용자가 자연스럽게 드러납니다.

비즈니스의 기본 개념이 낯설다면 지식백과의 비즈니스 용어 설명을 먼저 읽어도 좋습니다. 기업 활동은 단순히 도구를 구매하는 일이 아니라 고객에게 가치를 전달하고 운영 성과를 만드는 과정입니다. 따라서 기업 솔루션은 기능 수가 아니라 업무 성과에 기여하는 정도로 평가해야 합니다.

문제 문장은 ‘누가, 무엇 때문에, 어떤 손실을 겪고 있으며, 어느 수준까지 개선하려는가’의 네 요소로 작성합니다. 수치가 없다면 일주일 동안만이라도 담당자의 반복 작업 시간, 오류 건수, 승인 대기 시간을 기록해 보세요. 완벽한 통계보다 현재 상태를 보여 주는 작은 기준값이 훨씬 유용합니다.

• 사용자: 실제 입력자, 승인자, 결과를 확인하는 사람을 구분합니다.
• 현재 문제: 중복 입력, 누락, 긴 대기 시간처럼 관찰 가능한 현상으로 씁니다.
• 사업 영향: 인건비 증가, 고객 응답 지연, 보안 위험 등과 연결합니다.
• 목표: ‘편리하게’ 대신 처리 시간 30% 단축처럼 확인 가능한 표현을 사용합니다.

초보 담당자에게 가장 유용한 질문은 “이 서비스를 도입하지 않으면 다음 분기에 어떤 문제가 반복되는가?”입니다. 답하기 어렵다면 아직 구매보다 문제 관찰이 먼저입니다.

필수 기능과 있으면 좋은 기능을 같은 칸에 넣지 않습니다

요구사항을 세 단계로 나누기

현업 인터뷰를 하면 모든 요청이 필수처럼 들립니다. 그러나 기능을 많이 담을수록 후보가 줄고 구축 비용과 교육 부담은 커집니다. 요구사항을 필수, 우선, 선택의 세 단계로 나누면 공급사의 화려한 시연에 흔들리지 않고 비교 기준을 유지할 수 있습니다.

필수 요구사항은 없으면 업무 자체가 불가능하거나 법적·보안상 도입할 수 없는 조건입니다. 우선 요구사항은 첫 운영 기간에 생산성을 높이는 기능이며, 선택 요구사항은 향후 확장을 위한 편의 기능입니다. 예를 들어 고객관리 솔루션이라면 접근권한 설정과 데이터 내보내기는 필수, 자동 리포트는 우선, 화면 색상 변경은 선택이 될 수 있습니다.

초보자가 바로 쓸 수 있는 요구사항 표

각 항목에는 기능명만 쓰지 말고 사용 장면과 검증 방법을 함께 적어야 합니다. ‘모바일 지원’보다 ‘외근 직원이 휴대전화에서 고객 메모를 등록하고 관리자가 즉시 조회할 수 있어야 한다’가 좋은 요구사항입니다. 온라인에서 주문·계약·고객 대응이 이어지는 구조는 이비즈니스 개념 설명과 함께 살펴보면 업무 흐름을 이해하는 데 도움이 됩니다.

• 요구사항마다 요청 부서와 최종 승인자를 기록합니다.
• ‘지원함’이라는 답변 대신 실제 화면, 도움말 또는 테스트 결과를 근거로 남깁니다.
• 예외 상황도 포함합니다. 담당자 퇴사, 대량 업로드 실패, 인터넷 장애 등을 가정합니다.
• 전체 항목 중 필수 기능이 지나치게 많다면 비슷한 항목을 합치거나 단계 도입을 검토합니다.

공급사 비교는 기능 개수보다 운영 조건을 봅니다

같은 월 이용료라도 실제 비용이 달라지는 이유

기업 비즈니스 서비스의 가격표에는 보통 사용자 수와 기본 기능이 크게 표시됩니다. 하지만 실제 지출에는 초기 설정, 데이터 이전, 관리자 교육, 외부 시스템 연동, 추가 저장공간, 기술지원 등급, 계약 종료 후 데이터 추출 비용이 더해질 수 있습니다. 무료 체험에서 잘 작동하던 기능이 유료 상위 요금제에만 포함되는지도 확인해야 합니다.

비교 기간은 최소 1년으로 맞추고, 내부 직원이 투입하는 시간까지 별도 열로 기록하세요. 월 이용료가 낮아도 매주 수작업 보정에 여러 시간이 필요하다면 총비용은 더 커집니다. 반대로 초기 구축비가 있더라도 반복 업무를 확실히 줄이고 기존 시스템과 안정적으로 연결된다면 장기적으로 유리할 수 있습니다.

공급사 설명을 들을 때는 ‘가능합니다’라는 말 뒤의 조건을 물어야 합니다. 기본 기능인지 별도 개발인지, 개발 주체는 누구인지, 업데이트 후에도 유지되는지 확인하세요. 계약 전에 서면으로 확인되지 않은 약속은 평가 점수에서 제외한다는 원칙을 세우면 판단이 훨씬 단순해집니다.

1. 기본 비용: 사용자당 요금, 최소 계정 수, 월간·연간 결제 차이를 확인합니다.
2. 도입 비용: 설정, 데이터 정제·이관, 교육, 맞춤 개발 비용을 분리합니다.
3. 운영 비용: 관리자 업무, 문의 대응, 연동 유지에 필요한 시간을 추산합니다.
4. 변경 비용: 사용자 증가, 기능 추가, 계약 중도 변경 때 적용되는 단가를 묻습니다.
5. 종료 비용: 데이터 반환 형식, 추출 기간, 삭제 확인서 제공 여부를 확인합니다.

견적서에는 ‘포함’과 ‘별도’만 표시하지 말고 별도 비용의 산정 방식까지 요청하세요. 단가가 미정이면 예산 상한을 만들 수 없습니다.

점수표는 단순하게 유지하기

평가표는 필수 기능 충족 40점, 보안·관리 20점, 사용성 15점, 총비용 15점, 지원 체계 10점처럼 회사 상황에 맞게 가중치를 부여할 수 있습니다. 다만 점수 합계만 믿지 말고 필수 조건 미충족 시 탈락하는 기준을 따로 두세요. 핵심 데이터 내보내기가 불가능한 제품이 예쁜 화면 덕분에 1위를 차지하는 오류를 막을 수 있습니다.

• 모든 공급사에 동일한 질문서와 동일한 업무 시나리오를 제공합니다.
• 데모는 공급사가 준비한 화면보다 우리 회사의 샘플 업무를 기준으로 요청합니다.
• 평가자는 영업 설명을 들은 사람뿐 아니라 실제 사용자와 관리자도 포함합니다.

작은 체험 운영으로 도입 뒤의 불편을 먼저 발견합니다

2~4주 파일럿의 범위를 정하는 법

체험 계정을 받은 뒤 자유롭게 눌러 보는 것만으로는 기업 솔루션을 제대로 검증하기 어렵습니다. 실제 업무 한 가지를 골라 시작부터 종료까지 수행해야 합니다. 예를 들어 문의 접수, 담당자 배정, 답변 승인, 고객 발송, 결과 보고까지 연결하면 데이터 흐름과 권한 문제를 동시에 확인할 수 있습니다.

파일럿 참여자는 너무 많지 않아도 됩니다. 실제 사용자 3~5명, 관리자 1명, 보안 또는 IT 담당자 1명 정도로 시작하되 부서와 숙련도가 다른 사람을 섞는 편이 좋습니다. 특정 직원만 능숙하게 사용할 수 있다면 전사 도입 후 교육 비용이 예상보다 커질 수 있기 때문입니다.

시험용 데이터에는 실제 개인정보나 영업기밀을 그대로 넣지 마세요. 이름과 연락처를 가명으로 바꾼 샘플을 사용하고, 체험 종료 뒤 계정과 업로드 자료의 삭제 방법도 확인합니다. 외부 서비스와 연동할 때는 테스트 환경을 우선 사용하며 관리자 권한을 불필요하게 넓게 주지 않는 것이 안전합니다.

1. 1일차: 성공 기준과 담당자를 정하고 테스트 계정을 발급합니다.
2. 1주차: 기본 업무 시나리오를 실행하며 막힌 지점과 문의 횟수를 기록합니다.
3. 2주차: 대량 입력, 승인 반려, 권한 변경 같은 예외 상황을 시험합니다.
4. 종료일: 처리 시간, 오류 건수, 사용자 만족도, 관리자 부담을 도입 전과 비교합니다.

체험에서 꼭 측정할 네 가지

평가 항목은 많을 필요가 없습니다. 업무 완료 시간, 오류나 재작업 건수, 도움 없이 완료한 사용자 비율, 공급사 문의 응답 시간을 기록하면 실무 적합성을 상당 부분 파악할 수 있습니다. 만족도는 5점 척도만 묻지 말고 ‘가장 불편했던 한 단계’를 함께 적게 해야 개선 가능성을 판단할 수 있습니다.

• 첫 사용자가 교육 없이 핵심 작업을 완료하는 데 걸린 시간
• 엑셀 업로드와 다운로드 시 한글·날짜·숫자 형식의 유지 여부
• 권한이 없는 사용자가 제한된 정보에 접근할 수 없는지 여부
• 장애나 질문 발생 시 도움말과 고객지원으로 해결하는 데 걸린 시간
• 기존 메일, 회계, 그룹웨어와 연결할 때 필요한 추가 작업

우리 회사의 속도와 위험도에 맞춰 첫 선택을 달리합니다

계약 직전 FAQ로 빈틈 점검하기

Q. 사용자 의견이 서로 다르면 누구의 요구를 우선해야 하나요?
매일 서비스를 사용하는 실무자의 업무 빈도와 회사가 감당해야 할 위험을 함께 봅니다. 편의 기능은 다수 사용자의 의견을 따르되, 보안·법무·재무 조건은 해당 책임자의 승인을 받는 방식이 현실적입니다.

Q. 무료 체험만으로 계약해도 되나요?
소규모 표준 업무라면 가능하지만 데이터 이전, 시스템 연동, 여러 부서의 권한 설정이 필요하면 제한적 파일럿을 거치는 편이 안전합니다. 체험판과 실제 계약 요금제의 기능, 저장공간, 지원 범위가 같은지도 반드시 비교하세요.

Q. 계약 기간은 길수록 저렴하니 연간 계약이 좋은가요?
할인율만 보면 연간 계약이 유리할 수 있지만 첫 도입이라면 중도 해지, 사용자 수 축소, 자동 갱신 조건이 더 중요합니다. 짧게 검증한 뒤 확대할 수 있는지 묻고, 갱신 통보 기한은 담당자 캘린더와 계약 관리대장에 동시에 기록하세요.

• 계약 범위: 선택한 요금제, 계정 수, 교육 횟수, 연동 항목을 명시합니다.
• 서비스 수준: 장애 접수 채널, 응답 시간, 점검 공지 방식을 확인합니다.
• 데이터 관리: 보관 위치, 백업, 반환 형식, 계약 종료 후 삭제 절차를 묻습니다.
• 변경 관리: 가격 인상과 주요 기능 변경의 사전 통보 기간을 확인합니다.
• 책임 배분: 회사 내부 관리자와 공급사 담당자의 업무 범위를 문서화합니다.

빠른 개선이 필요한 팀과 신중한 도입이 필요한 팀

반복 업무가 단순하고 사용자 수가 적으며 별도 연동이 필요 없는 팀이라면, 필수 기능을 5개 안팎으로 좁혀 표준형 서비스를 짧게 체험한 뒤 월 단위로 시작하는 선택이 어울립니다. 초기에는 맞춤 개발을 줄이고 사용률과 처리 시간의 변화를 한 달마다 확인하세요. 실제 사용이 안정되면 계정과 자동화 범위를 넓히면 됩니다.

반면 고객정보나 민감한 기업 데이터를 다루고 여러 부서·지점이 함께 쓰거나 기존 시스템 연동이 필요한 조직이라면 속도보다 검증을 우선하세요. 요구사항 문서, 보안 검토, 실제 시나리오 파일럿, 데이터 반환 조건을 차례로 통과한 후보와 제한된 범위로 계약하는 편이 적합합니다. 빨리 효과를 볼 팀은 작게 시작해 측정하고, 실패 비용이 큰 조직은 증거를 확보한 뒤 단계적으로 확대하는 것이 서로에게 맞는 첫 선택입니다.