기업 비즈니스 솔루션, 전 부서 요구를 다 반영하지 않아도 되는 이유

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

영업팀은 고객관리 기능을, 재무팀은 결재 통제를, 현장팀은 모바일 입력을 먼저 요구합니다. 기업 비즈니스 솔루션을 검토하다 보면 요구사항이 수십 개로 늘어나고, 담당자는 어느 기능도 빼지 못한 채 견적서만 계속 고치게 됩니다. 이번 글에서는 기업 솔루션 기획과 구축을 담당해 온 박준형 비즈니스 프로세스 컨설턴트에게 요구사항을 선별하는 현실적인 기준을 물었습니다.

요구사항이 많을수록 좋은 솔루션이 되나요?

Q. 현업 의견을 모두 반영해야 만족도가 높아지지 않습니까?

A. 의견을 충분히 듣는 것과 모든 요청을 제품에 넣는 것은 전혀 다른 일입니다. 부서별 요구를 빠짐없이 반영하면 처음에는 공평해 보이지만, 실제로는 화면과 승인 단계가 복잡해져 전 직원이 불편한 시스템이 될 수 있습니다. 특히 사용 빈도가 낮은 예외 업무까지 기본 프로세스에 넣으면 핵심 업무의 처리 시간이 길어집니다.

요구사항은 ‘누가 강하게 주장했는가’보다 얼마나 자주 발생하고 어떤 손실을 줄이는가로 판단해야 합니다. 가령 월 1회 발생하는 보고서 서식 변경보다 매일 200건씩 반복되는 고객정보 이중 입력을 먼저 해결하는 편이 효과가 큽니다. 비즈니스라는 표현의 폭이 궁금하다면 지식백과의 비즈니스 설명도 참고할 수 있지만, 기업 솔루션에서는 그 넓은 범위를 실제 업무 단위로 좁히는 작업이 핵심입니다.

인터뷰 과정에서 박 컨설턴트는 요청을 기능명이 아닌 문제 문장으로 바꾸라고 강조했습니다. ‘대시보드가 필요하다’가 아니라 ‘팀장이 매주 네 시간씩 여러 파일을 합친다’고 적으면 다른 해결책도 검토할 수 있습니다. 기존 기능의 설정 변경이나 보고서 자동 발송만으로 해결된다면 별도 개발은 필요하지 않습니다.

• 빈도: 해당 업무가 하루·주·월 단위로 몇 번 발생하는지 확인합니다.
• 영향: 지연, 오류, 고객 불만, 규정 위반 중 무엇을 줄이는지 적습니다.
• 사용자 범위: 전사 공통인지 일부 담당자의 예외 업무인지 구분합니다.
• 대체 가능성: 표준 기능, 설정 변경, 운영 규칙으로 풀 수 있는지 살펴봅니다.

“요구를 거절하는 것이 아니라, 요청 뒤에 숨어 있는 업무 문제를 더 단순한 방식으로 해결하는 것이 요구사항 관리입니다.”

부서 인터뷰에서는 무엇을 먼저 물어야 하나요?

Q. ‘필요한 기능을 말해 달라’고 질문하면 부족한가요?

A. 그 질문만 던지면 현업은 익숙한 제품의 기능이나 오래된 불편을 나열하게 됩니다. 먼저 업무가 시작되는 조건, 처리 순서, 다음 담당자에게 넘기는 정보, 완료 여부를 판단하는 기준을 물어야 합니다. 이 흐름을 확인해야 기능 요청이 실제 병목을 해결하는지 판단할 수 있습니다.

예를 들어 영업팀이 ‘고객 메모 자유 입력란을 늘려 달라’고 요청했다고 가정해 보겠습니다. 인터뷰를 더 진행했더니 메모 자체가 목적이 아니라, 계약 가능성이 높은 고객을 인수인계할 때 중요한 정보를 놓치지 않으려는 요구일 수 있습니다. 이 경우 자유 입력란을 늘리기보다 필수 선택 항목과 후속 일정 알림을 제공하는 편이 검색과 집계에 유리합니다.

인터뷰 참석자도 직급별로 섞는 것이 좋습니다. 팀장은 관리 지표를 잘 알지만 실제 입력 과정의 마찰을 놓칠 수 있고, 실무자는 반복 작업을 잘 알지만 다른 부서에 미치는 영향을 모두 보기는 어렵습니다. 담당자, 승인자, 결과 데이터를 받는 사람을 각각 만나면 기업 맞춤형 서비스의 범위가 훨씬 선명해집니다.

1. 업무가 시작되는 사건과 요청자를 확인합니다.
2. 현재 사용하는 파일, 메신저, 이메일과 시스템을 펼쳐 놓습니다.
3. 중복 입력과 대기 시간이 생기는 지점을 표시합니다.
4. 오류가 발생했을 때 누가 어떻게 발견하는지 묻습니다.
5. 개선 후 줄어들어야 할 시간이나 오류 건수를 합의합니다.

Q. 인터뷰 기록은 어떤 형태가 실용적입니까?

긴 회의록보다 ‘현재 문제-원인-원하는 변화-측정 방법-책임자’ 다섯 칸으로 기록하는 방식을 권합니다. 같은 문제가 여러 부서에서 반복되면 공통 요구로 묶고, 표현만 비슷할 뿐 처리 규칙이 다르면 별도로 표시합니다. 이렇게 해야 솔루션 업체도 개발 범위를 과도하게 추정하지 않고 구체적인 제안을 내놓을 수 있습니다.

기능 우선순위는 누구의 목소리로 결정합니까?

Q. 임원 요청은 무조건 최우선으로 두어야 하나요?

A. 경영진이 제시하는 방향과 통제 기준은 중요하지만, 구체적인 화면 구성까지 자동으로 최우선이 되는 것은 아닙니다. 최종 결정권자는 사업 목표를 정하고, 실무 책임자는 빈도와 난도를 검증하며, 보안·재무 담당자는 위험을 확인하는 식으로 역할을 나누어야 합니다. 한 사람의 선호가 아니라 공개된 평가 기준으로 순위를 정해야 갈등도 줄어듭니다.

실무에서는 영향도 40점, 긴급성 25점, 사용자 범위 20점, 구현 난이도 15점처럼 가중치를 둘 수 있습니다. 구현 난이도는 점수가 낮을수록 유리하게 환산합니다. 숫자가 절대적인 답을 주는 것은 아니지만, 왜 어떤 기능이 다음 단계로 밀렸는지 설명할 공통 언어가 됩니다.

아래 표처럼 요구사항별 근거를 한 줄로 공개하면 부서 간 협의가 빨라집니다. 특히 법적 의무와 정보보안 통제는 단순 편의 기능과 같은 줄에 놓지 말고 별도 필수 등급으로 관리해야 합니다. 최근 기술기업 지원 사례처럼 사업 환경과 기술 투자 방향도 달라질 수 있으므로, 외부 변화가 중요한 조직이라면 딥테크 기업 관련 산업 기사와 같은 자료를 참고해 전략적 요구의 시급성을 교차 검토할 수 있습니다.

• 점수와 별도로 법무·보안 필수 여부를 표시합니다.
• 요청 부서가 기대 효과를 한 문장으로 작성하게 합니다.
• 동점이면 사용 빈도와 데이터 품질 개선 효과를 먼저 봅니다.
• 보류 사유와 재검토 조건을 함께 남겨 단순 거절로 보이지 않게 합니다.

맞춤 개발 비용은 어떻게 통제해야 합니까?

Q. 요구사항을 많이 빼면 견적이 바로 낮아집니까?

A. 대체로 낮아지지만 기능 개수만 세어서는 정확하지 않습니다. 외부 시스템 연동, 데이터 이관, 복잡한 권한, 승인 규칙처럼 보이지 않는 작업이 비용과 기간을 크게 좌우합니다. 버튼 하나를 추가하는 요청이라도 여러 시스템의 상태를 확인해야 한다면 단순 화면 수정 이상의 분석과 테스트가 필요합니다.

초기 검토에서는 비용을 라이선스료, 설정·구축비, 맞춤 개발비, 데이터 이전비, 교육비, 운영 지원비로 나누어 받아야 합니다. 예컨대 저렴한 월 구독료를 선택했더라도 매번 수작업으로 데이터를 정리해야 한다면 총비용은 커집니다. 반대로 표준 기능에 업무 절차를 일부 맞추면 개발비뿐 아니라 향후 버전 업데이트 때 발생할 재검증 비용도 줄일 수 있습니다.

가격대는 사용자 수, 연동 대상, 보안 수준과 지원 시간에 따라 편차가 커서 ‘기업 솔루션은 얼마’라고 한 숫자로 단정하기 어렵습니다. 따라서 동일한 요구사항 문서를 최소 두 가지 시나리오로 견적받아 보십시오. 하나는 표준 기능 중심, 다른 하나는 핵심 맞춤 개발 포함안으로 만들면 무엇에 비용이 붙는지 확인하기 쉽습니다.

• 시나리오 A: 표준 기능과 기본 설정만 사용해 빠르게 운영합니다.
• 시나리오 B: 매일 반복되는 핵심 병목에만 맞춤 개발을 적용합니다.
• 시나리오 C: 향후 확장이 필요한 연동은 설계만 확보하고 개발을 미룹니다.
• 견적 확인: 부가세, 데이터 정제, 추가 교육, 야간 지원 포함 여부를 구분합니다.

“견적을 깎기 전에 범위를 나누십시오. 무엇을 사지 않을지 결정하는 일이 가격 협상보다 큰 비용을 줄일 때가 많습니다.”

Q. 보류 기능은 결국 잊히지 않나요?

보류 목록에는 재검토 날짜보다 재검토 조건을 적는 편이 낫습니다. ‘수기 처리 월 100건 초과’, ‘오류율 3% 이상’, ‘사용 부서 세 곳 이상’처럼 조건을 정하면 실제 필요가 커졌을 때 자연스럽게 투자 결정을 내릴 수 있습니다. 근거가 생기지 않은 요구는 다음 분기에도 개발하지 않아도 됩니다.

선택한 기능이 실제로 쓰이는지는 어떻게 확인하나요?

Q. 오픈 뒤 로그인 수만 보면 충분합니까?

A. 로그인은 접근 여부만 보여 줄 뿐 업무가 개선됐는지는 알려 주지 않습니다. 계약 등록 소요 시간, 승인 반려율, 중복 입력 건수, 고객 문의 처리 시간처럼 기능과 연결된 업무 지표를 함께 봐야 합니다. 사용량이 높아도 불필요한 단계를 강제로 거치느라 클릭이 많아진 것일 수 있습니다.

측정 기간은 업무 주기에 맞춰야 합니다. 일상 업무는 2~4주 안에 패턴이 보일 수 있지만 월말 정산이나 분기 보고는 최소 한 번의 전체 주기를 지나야 판단할 수 있습니다. 또한 도입 직후에는 교육 효과와 호기심 때문에 사용량이 일시적으로 높아질 수 있으므로 첫 주 수치만으로 성공을 선언해서는 안 됩니다.

사용자 피드백은 만족도 점수 하나보다 구체적인 행동 질문으로 받는 것이 좋습니다. ‘이 기능이 편리한가요?’ 대신 ‘지난주에 이 기능을 몇 번 사용했으며, 사용하지 않았다면 어떤 방식으로 처리했나요?’라고 물어보십시오. 그러면 숨은 엑셀 작업이나 메신저 승인처럼 시스템 밖으로 빠져나간 업무를 찾을 수 있습니다.

• 기능별 활성 사용자와 반복 사용률을 구분합니다.
• 처리 시간은 평균뿐 아니라 가장 오래 걸린 사례도 확인합니다.
• 오류 건수와 수정에 든 시간을 함께 측정합니다.
• 사용하지 않는 이유를 교육 부족, 권한 문제, 기능 부적합으로 나눕니다.
• 삭제 후보 기능도 기록해 화면과 운영 절차를 가볍게 유지합니다.

Q. 성과가 낮으면 바로 기능을 없애야 합니까?

먼저 데이터가 정확히 수집됐는지, 사용자가 해당 기능의 존재와 목적을 이해하는지 확인해야 합니다. 권한 설정이나 느린 응답 속도가 원인이라면 기능 자체의 가치와 무관할 수 있습니다. 원인을 고친 뒤에도 이용률과 업무 효과가 낮다면 기능을 숨기거나 종료하고, 확보한 예산을 더 중요한 기업 서비스 개선에 돌리는 판단이 합리적입니다.

반영하지 않아도 된다는 원칙이 멈추는 지점

Q. 끝까지 제외하면 안 되는 요구도 있습니까?

A. 있습니다. 개인정보 보호, 회계·세무 기록, 산업별 보존 의무, 접근권한 통제, 장애 대응처럼 법적 책임이나 사업 연속성에 연결되는 요구는 사용 빈도가 낮아도 제외해서는 안 됩니다. 이런 항목은 편의성과 투자수익률만으로 평가하지 말고 법무, 보안, 회계 전문가의 검토를 거쳐야 합니다.

또한 소수 사용자의 요구라고 해서 항상 가치가 낮은 것도 아닙니다. 장애가 있는 구성원의 접근성, 해외 법인의 언어·시간대 처리, 위험 설비 담당자의 비상 절차처럼 사용자는 적어도 실패했을 때 피해가 큰 업무가 있습니다. ‘몇 명이 쓰는가’와 함께 ‘작동하지 않으면 어떤 일이 생기는가’를 질문해야 합니다.

마지막으로 새로운 사업 모델이나 연구개발 업무는 과거 사용량만으로 평가하기 어렵습니다. 아직 고객과 거래가 적더라도 전략적으로 검증해야 할 기능이 있을 수 있으며, 기술 기반 기업의 성장 경로처럼 불확실성이 큰 영역에서는 가설과 중단 기준을 먼저 정하는 편이 유용합니다. 영어권에서 쓰이는 의미까지 살펴볼 필요가 있다면 business 용어 설명을 참고해 조직이 말하는 사업 범위를 명확히 맞출 수 있습니다.

• 무조건 별도 검토: 법령, 계약 의무, 개인정보, 보안, 회계 관련 요구
• 빈도보다 피해 규모 우선: 안전사고, 서비스 중단, 데이터 유실 대응
• 포용성 예외: 접근성과 필수 업무 수행을 보장하는 기능
• 전략적 예외: 신규 사업 가설을 제한된 범위에서 검증하는 기능
• 판단의 경계: 업종별 규정과 실제 계약 조건은 솔루션 공급사의 일반 설명만 믿지 말고 해당 분야 전문가에게 확인

Q. 요구를 덜 반영하는 방식에도 한계가 있다는 뜻인가요?

그렇습니다. 선택과 집중은 비용을 아끼기 위한 구호가 아니라 핵심 업무를 선명하게 만드는 방법입니다. 다만 TS컴퍼니와 기업 비즈니스 솔루션 범위를 논의할 때도 현장 인터뷰, 위험 검토, 실제 사용 데이터가 빠진 채 ‘최소 기능’만 강조하면 중요한 예외를 놓칠 수 있습니다. 규제 적용 여부와 맞춤 견적은 기업의 업종, 규모, 데이터 종류에 따라 달라지므로 이 글의 우선순위 기준만으로 최종 법률·보안 판단을 대신해서는 안 됩니다.