기업 업무 진단에서 맞춤 솔루션 요구사항을 확정하는 과정

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

“직원들이 불편하다고 말하는 기능부터 추가하면 될까요?” 맞춤형 기업 솔루션을 검토하는 담당자가 가장 자주 던지는 질문입니다. 하지만 여러 부서의 요청을 그대로 모으면 요구사항은 빠르게 늘어나고, 정작 해결해야 할 업무 문제는 흐려집니다. 도입 비용도 예상보다 커지고 일정까지 밀리기 쉽습니다.

이번 인터뷰에서는 기업 업무 프로세스를 진단하고 비즈니스 서비스의 요구사항을 설계해 온 컨설턴트 정우림 소장에게 실무적인 순서를 물었습니다. 불편 사항을 수집하는 방법부터 우선순위 결정, 제안요청서 작성, 검증과 변경 관리까지 실제 프로젝트에서 놓치기 쉬운 지점을 Q&A 형식으로 짚어봅니다.

첫 질문, 솔루션보다 업무 흐름을 먼저 보는 이유는 무엇인가요?

Q. 현업은 기능을 빨리 보여 달라고 하는데 왜 진단부터 시작해야 하나요?

정우림 소장: 기능 목록은 눈에 잘 보이지만 문제의 원인을 설명하지는 못합니다. 예를 들어 영업팀이 “자동 알림 기능이 필요하다”고 요청했더라도 실제 원인은 담당자 변경 정보가 고객관리 시스템에 늦게 반영되는 데 있을 수 있습니다. 이때 알림만 추가하면 잘못된 담당자에게 더 빠르게 메시지가 전달될 뿐입니다.

먼저 업무가 시작되는 조건, 담당자, 입력 정보, 승인 기준, 최종 산출물을 연결해 봐야 합니다. 비즈니스라는 말 자체도 단순한 거래가 아니라 여러 활동과 이해관계가 결합된 개념입니다. 용어의 기본 범위는 지식백과의 비즈니스 설명을 참고할 수 있습니다. 기업 솔루션 역시 개별 기능보다 전체 활동의 연결 구조 안에서 평가해야 합니다.

진단 첫날부터 모든 프로세스를 세밀하게 그릴 필요는 없습니다. 고객 문의 접수, 견적 승인, 계약, 서비스 제공, 청구처럼 기업의 매출이나 고객 경험에 직접 영향을 주는 흐름을 골라 현재 상태를 있는 그대로 기록하는 것이 우선입니다.

• 시작 조건: 어떤 사건이나 요청이 업무를 발생시키는지 확인합니다.
• 담당 역할: 사람의 이름이 아니라 직무와 권한을 기록합니다.
• 입력 데이터: 업무 수행에 필요한 문서와 시스템 정보를 찾습니다.
• 판단 기준: 승인·반려·보류를 나누는 규칙을 확인합니다.
• 완료 기준: 누가 무엇을 확인해야 업무가 끝나는지 정의합니다.

“좋은 기업 솔루션은 복잡한 업무를 화면 안에 옮기는 제품이 아니라, 불필요한 판단과 이동을 줄이는 서비스입니다.”

둘째 질문, 현업의 불편을 어떻게 증거로 바꿉니까?

Q. 인터뷰에서는 모두 자기 부서의 문제가 가장 크다고 말합니다

정우림 소장: 그래서 의견과 사실을 분리해야 합니다. “승인이 너무 늦다”는 의견이라면 최근 30건의 요청에서 접수부터 승인까지 걸린 시간, 반려 횟수, 대기 구간을 확인합니다. 평균만 보면 특정 고액 계약의 긴 검토 시간이 전체 수치를 왜곡할 수 있으므로 중앙값과 최대값도 함께 보는 편이 좋습니다.

인터뷰 대상도 관리자에게만 한정하면 안 됩니다. 관리자는 정책과 목표를 잘 알지만 실제 복사·붙여넣기, 엑셀 재입력, 메신저 확인 같은 숨은 작업을 놓칠 수 있습니다. 업무를 수행하는 직원, 승인자, 결과를 전달받는 다음 부서까지 한 흐름에서 만나야 기업 업무의 실제 병목이 드러납니다.

Q. 어떤 자료를 요청해야 과도한 조사 없이 판단할 수 있을까요?

처음에는 완벽한 데이터보다 반복 패턴을 찾을 수 있는 표본이 유용합니다. 최근 한 달 또는 정상 기간과 성수기를 각각 포함한 사례를 확보하고, 개인정보와 거래 기밀은 수집 전에 마스킹해야 합니다. 기록이 없는 수작업은 담당자의 화면 공유를 받아 관찰하되, 감시로 오해받지 않도록 목적과 보관 기간을 미리 알립니다.

1. 업무별 처리 건수와 평균·중앙 처리 시간을 수집합니다.
2. 재작업, 반려, 중복 입력이 발생한 횟수를 표시합니다.
3. 사용 중인 문서와 엑셀 양식의 필수 필드를 비교합니다.
4. 메일, 메신저, 전화처럼 시스템 밖에서 이뤄지는 전달을 기록합니다.
5. 오류 한 건이 매출, 고객 응대, 규정 준수에 미치는 영향을 계산합니다.

예를 들어 직원 12명이 하루 15분씩 동일 정보를 재입력한다면 월 20일 기준으로 약 60시간이 소요됩니다. 이 수치에 인건비만 곱하는 데서 멈추지 말고 입력 오류 수정, 승인 지연, 고객 재문의 비용도 함께 살펴야 합니다. 그래야 편의 기능이 아니라 투자 근거가 있는 개선 과제로 설명할 수 있습니다.

셋째 질문, 요구사항의 우선순위는 누가 어떤 기준으로 정하나요?

Q. 모든 부서가 필수라고 주장할 때 무엇부터 남겨야 합니까?

정우림 소장: 목소리의 크기가 아니라 사업 영향과 구현 조건으로 판단합니다. 먼저 요구사항을 법률·보안·계약상 반드시 충족해야 하는 항목, 매출과 운영 성과를 높이는 항목, 사용 편의를 개선하는 항목으로 나눕니다. 그다음 발생 빈도, 영향 범위, 위험 감소 효과, 예상 비용을 같은 척도로 평가합니다.

간단한 점수표를 활용하면 부서 간 대화가 훨씬 구체적으로 변합니다. 사업 영향 5점, 사용자 범위 3점, 위험 감소 4점, 구현 난이도 2점처럼 근거를 함께 적는 방식입니다. 총점이 같더라도 개인정보 유출이나 청구 오류를 막는 요구사항은 편의성 개선보다 먼저 처리할 수 있습니다.

Q. 필수·선택 구분만으로 충분하지 않은가요?

필수라는 단어는 사람마다 다르게 해석됩니다. “검색 기능 필수” 대신 “고객번호 또는 계약번호를 입력하면 3초 이내에 해당 계약을 찾을 수 있어야 한다”처럼 사용 상황과 성공 기준을 붙여야 합니다. 그래야 SSMO 같은 비즈니스 서비스 제공사도 구현 범위와 비용을 현실적으로 산정할 수 있습니다.

• Must: 없으면 업무 개시, 법적 준수 또는 핵심 거래가 불가능한 항목
• Should: 운영 성과에 큰 영향을 주지만 임시 절차로 단기간 대응 가능한 항목
• Could: 사용자 만족을 높이지만 초기 개통을 막지는 않는 항목
• Later: 효과와 사용 빈도를 더 확인한 뒤 다음 배포에서 판단할 항목

초기 범위에는 예외 상황도 포함해야 합니다. 정상 승인만 정의하고 담당자 휴가, 중복 주문, 계약 취소, 시스템 장애를 빼놓으면 개통 직후 수작업이 되살아납니다. 다만 모든 희귀 사례를 처음부터 자동화하면 비용이 급증하므로, 발생 빈도가 낮은 예외는 관리자가 안전하게 처리할 수 있는 보조 화면과 기록 기능을 마련하는 편이 합리적입니다.

“우선순위 회의의 목표는 누군가의 요청을 탈락시키는 것이 아닙니다. 제한된 예산 안에서 어떤 업무 결과를 먼저 만들지 합의하는 과정입니다.”

넷째 질문, 맞춤 솔루션 요구사항 문서는 어떻게 구체화합니까?

Q. 개발사나 서비스 업체가 다르게 해석하지 않게 쓰는 법이 있나요?

정우림 소장: 한 문장에 하나의 행동과 하나의 검증 기준을 담는 것이 좋습니다. “직관적이고 편리한 고객관리 화면”은 검수할 수 없습니다. 반면 “상담원은 고객번호를 입력해 최근 상담 이력 10건을 한 화면에서 조회할 수 있어야 한다”는 대상 사용자, 입력값, 행동, 결과가 명확합니다.

온라인에서 주문, 계약, 결제, 고객지원이 이어지는 기업이라면 단일 화면만 설계해서는 안 됩니다. 이비즈니스의 개념과 범위에서 확인할 수 있듯 디지털 기반 비즈니스는 정보 교환과 업무 수행이 함께 연결됩니다. 따라서 화면 요구사항과 더불어 데이터 흐름, 외부 시스템 연동, 권한, 감사 기록을 함께 정의해야 합니다.

Q. 요구사항 문서에는 어떤 열이 필요합니까?

문서가 길다고 정확한 것은 아닙니다. 각 항목을 고유 번호로 관리하고 변경 이력을 남겨야 회의록, 견적서, 테스트 결과를 연결할 수 있습니다. 특히 “가능”, “지원”이라는 답변만 받지 말고 기본 제공인지, 설정이 필요한지, 별도 개발인지 구분해 달라고 요청해야 예상 비용을 통제할 수 있습니다.

• 요구사항 ID와 업무명: 추적 가능한 번호와 관련 프로세스를 표시합니다.
• 사용자 시나리오: 누가 어떤 상황에서 무엇을 해야 하는지 씁니다.
• 수용 기준: 속도, 정확도, 결과값 등 검수 가능한 조건을 정합니다.
• 데이터 조건: 필수 필드, 보관 기간, 소유 부서, 이관 범위를 기록합니다.
• 권한과 보안: 조회·등록·수정·삭제 권한 및 로그 요건을 구분합니다.
• 연동 조건: 대상 시스템, 전송 주기, 실패 시 재처리 방법을 적습니다.
• 제공 방식: 표준 기능, 환경 설정, 맞춤 개발, 외부 제품 여부를 표시합니다.
• 책임자와 확정일: 질문에 답하고 최종 승인할 담당자를 지정합니다.

비용은 제품명보다 범위에 따라 크게 달라집니다. 사용자 수 기반 구독료 외에도 초기 구축, 데이터 정제와 이관, 외부 API 사용량, 교육, 운영 지원, 추가 저장 공간, 변경 개발 비용이 발생할 수 있습니다. 견적을 받을 때는 초기 1회 비용과 월·연간 반복 비용을 나누고, 최소 계약 기간과 해지 시 데이터 반환 비용까지 동일한 조건으로 요청하십시오.

다섯째 질문, 계약 전에 작은 검증은 어떻게 운영해야 합니까?

Q. 데모만 보고 선택하면 왜 위험한가요?

정우림 소장: 데모는 제품이 가장 잘 작동하는 데이터와 시나리오로 진행되는 경우가 많습니다. 기업이 실제로 사용하는 긴 상품명, 누락된 주소, 중복 고객, 복잡한 승인 조건을 넣으면 전혀 다른 결과가 나올 수 있습니다. 따라서 최종 후보에게 동일한 대표 시나리오를 제공하고 직접 처리하도록 해야 비교가 가능합니다.

검증 범위는 작게 잡되 핵심 흐름은 끝까지 이어져야 합니다. 예를 들어 견적 자동화 솔루션이라면 고객 검색만 확인하지 말고 상품 선택, 할인 승인, 견적서 발행, 수정 이력 조회까지 수행합니다. 외부 회계나 고객관리 시스템으로 데이터를 보내야 한다면 성공 사례뿐 아니라 연결 실패와 중복 전송도 시험합니다.

Q. 짧은 검증에서 확인할 지표를 추천한다면요?

기능 개수보다 업무 성과를 측정하십시오. 기존 방식과 새 솔루션으로 같은 업무를 처리해 시간, 클릭 수, 오류, 문의 횟수를 비교하면 됩니다. 표본이 작을 때는 절감률을 확정 수치처럼 홍보하지 말고, 어떤 조건에서 측정했는지 남겨야 합니다.

1. 완료율: 도움 없이 시나리오를 끝낸 사용자의 비율을 확인합니다.
2. 처리 시간: 정상 건과 예외 건을 분리해 기존 방식과 비교합니다.
3. 오류율: 누락, 중복, 잘못된 승인 및 데이터 불일치를 집계합니다.
4. 학습 부담: 교육 시간과 반복 문의 내용을 기록합니다.
5. 복구 가능성: 잘못 입력하거나 연동에 실패했을 때 되돌릴 수 있는지 봅니다.
6. 운영 대응: 공급사가 질문과 장애에 답하는 시간 및 답변의 정확도를 평가합니다.

테스트 참여자는 솔루션을 제안한 관리자만으로 구성하지 않는 것이 좋습니다. 숙련 사용자, 신규 입사자, 승인자, 시스템 관리자처럼 관점이 다른 사람을 포함하십시오. 테스트가 끝난 뒤에는 단순 만족도 대신 “현재 방식보다 나아진 점”, “업무가 더 늘어난 지점”, “도입 전 해결해야 할 위험”을 각각 적게 하면 의사결정에 쓸 수 있는 피드백이 나옵니다.

운영 환경이 바뀔 때 요구사항을 다시 여는 시점은 언제입니까?

Q. 한 번 확정한 요구사항을 자주 바꾸면 프로젝트가 흔들리지 않나요?

정우림 소장: 근거 없는 변경은 일정을 흔들지만 변화 자체를 막는 것도 위험합니다. 계약 체결 후 신규 사업이 시작되거나 개인정보 보관 정책, 외부 시스템, 조직의 승인 권한이 바뀌면 기존 요구사항이 더는 맞지 않을 수 있습니다. 중요한 것은 요청을 즉시 개발에 넣지 않고 영향과 비용을 평가하는 통로를 두는 것입니다.

변경 요청에는 요청 이유, 영향받는 사용자, 기대 효과, 미적용 위험, 희망 시점이 포함돼야 합니다. 서비스 제공사는 개발 및 테스트 비용을 제시하고, 기업 담당자는 일정과 기존 범위에 미치는 영향을 확인합니다. 이후 업무 책임자와 예산 승인자가 수용, 보류, 대체 절차 적용 중 하나를 선택하도록 하면 구두 요청이 범위를 잠식하는 일을 줄일 수 있습니다.

Q. 운영을 시작한 뒤에는 어떤 주기로 다시 살펴봐야 합니까?

개통 직후 2~4주는 사용자 적응 문제와 설계 결함을 구분하는 관찰 기간으로 두는 편이 좋습니다. 이후에는 월별 운영 지표를 확인하고 분기 또는 반기마다 업무 책임자와 요구사항을 재검토할 수 있습니다. 다만 보안 사고, 법령 변화, 핵심 연동 서비스 종료처럼 영향이 큰 사건은 정기 회의를 기다리지 말고 즉시 평가해야 합니다.

• 처리 시간이 도입 전 기준보다 지속적으로 늘어났는지 확인합니다.
• 엑셀이나 메신저를 이용한 우회 업무가 다시 생겼는지 살핍니다.
• 권한이 없는 직원의 조회 시도와 비정상 접근 기록을 점검합니다.
• 사용하지 않는 기능과 라이선스가 비용만 발생시키는지 확인합니다.
• API 버전, 요금 정책, 데이터 보관 조건의 변경 공지를 추적합니다.
• 조직 개편 후 승인자와 데이터 소유 부서가 여전히 유효한지 검토합니다.

요구사항 문서는 계약을 위한 일회성 산출물이 아니라 기업과 솔루션 제공사가 공유하는 운영 기준이어야 합니다. 제품의 가격 정책, 외부 API 사양, 보안 인증 범위, 관련 제도는 시간이 지나면서 달라질 수 있습니다. 최초 작성일과 마지막 검토일을 문서에 남기고, 변경된 조건이 비용·데이터·업무 책임에 어떤 영향을 주는지 확인하는 절차까지 운영 체계에 포함해야 합니다.