기능 많은 기업 솔루션과 직원이 쓰는 비즈니스 서비스

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

새 기업 솔루션을 열었는데도 직원들이 엑셀과 메신저로 돌아간다면 무엇이 잘못된 걸까요? 기능표에서는 압도적이었던 서비스가 현장에서는 외면받는 이유를 찾기 위해, 기업의 디지털 업무 전환과 사용자 정착을 지원해 온 업무경험 컨설턴트 문해준에게 실무자가 가장 궁금해하는 질문을 물었습니다.

이번 인터뷰의 초점은 기능 개수나 브랜드 인지도가 아닙니다. 직원이 실제 업무에서 서비스를 선택하는 순간, 도입 비용을 판단하는 기준, 사용률을 높이는 운영 방식까지 살펴봅니다. 계약을 앞둔 담당자뿐 아니라 이미 도입한 기업 비즈니스 서비스의 활용도가 낮아 고민하는 운영자에게도 적용할 수 있는 내용입니다.

기능 수와 현장 사용률은 왜 함께 늘지 않을까요?

Q. 기능이 많으면 더 좋은 기업 솔루션 아닌가요?

A. 기능이 많다는 사실은 처리할 수 있는 업무 범위가 넓다는 뜻이지, 직원이 더 편하게 일한다는 뜻은 아닙니다. 사용자는 제품 소개서에 적힌 기능 수가 아니라 업무를 끝낼 때까지 거쳐야 하는 화면, 입력 항목, 승인 단계로 서비스를 평가합니다. 휴가 신청 하나를 위해 메뉴 네 개를 이동하고 같은 정보를 두 번 입력해야 한다면, 고급 분석 기능이 아무리 많아도 체감 품질은 낮습니다.

기업은 구매 과정에서 기능 비교표를 만들기 쉽기 때문에 항목 수에 끌리는 경향이 있습니다. 반면 검색 시간, 입력 부담, 예외 상황 처리처럼 실제 사용성을 좌우하는 요소는 숫자로 비교하기 어렵습니다. 비즈니스의 기본 개념이 조직의 목적과 활동을 폭넓게 다룬다는 점을 생각하면, 비즈니스 서비스 역시 기능 보유 여부보다 조직의 목적을 얼마나 빠르고 안정적으로 달성하게 하는지로 평가해야 합니다.

예를 들어 영업관리 솔루션에 견적, 계약, 재고, 캠페인, 고객지원 기능이 모두 들어 있어도 영업사원이 이동 중 고객 메모를 30초 안에 남기지 못하면 핵심 데이터가 쌓이지 않습니다. 반대로 기능은 단순하지만 모바일에서 고객명과 다음 행동만 빠르게 기록할 수 있다면 팀장은 훨씬 정확한 영업 현황을 보게 됩니다. 기능의 총량보다 핵심 행동의 완료 확률이 실제 성과에 가깝습니다.

• 도달 시간: 로그인 후 핵심 업무 화면까지 몇 초와 몇 번의 클릭이 필요한지 확인합니다.
• 완료 시간: 자주 수행하는 업무 한 건을 끝내는 데 걸리는 시간을 측정합니다.
• 오류 회복: 잘못 입력했을 때 사용자가 스스로 수정하거나 이전 상태로 돌아갈 수 있는지 살펴봅니다.
• 예외 처리: 표준 절차에서 벗어난 반품, 대리 승인, 긴급 요청도 별도 수작업 없이 처리되는지 시험합니다.
• 학습 부담: 매뉴얼 없이도 처음 접한 직원이 주요 기능을 찾아갈 수 있는지 관찰합니다.

기능표에 표시된 동그라미는 구매 담당자를 안심시키지만, 짧아진 업무 시간은 매일 서비스를 쓰는 직원을 움직입니다.

표준형 서비스와 맞춤형 구축은 무엇부터 비교해야 하나요?

Q. 우리 업무가 특수하면 처음부터 맞춤 개발해야 할까요?

A. 특수한 업무가 존재한다는 이유만으로 전체를 맞춤 개발할 필요는 없습니다. 먼저 업무를 공통 영역과 차별화 영역으로 분리해야 합니다. 로그인, 권한, 알림, 문서 보관처럼 여러 기업이 비슷하게 수행하는 일은 검증된 표준형 서비스가 효율적입니다. 반면 가격 산정 공식, 업종별 승인 규칙, 고객에게 제공되는 고유한 결과물처럼 경쟁력과 직접 연결된 과정은 맞춤 설정이나 별도 개발의 가치가 큽니다.

표준형은 초기 도입이 빠르고 업데이트와 보안 패치를 공급사가 맡는다는 장점이 있습니다. 다만 제공 범위를 벗어난 절차를 억지로 맞추면 우회 업무가 늘어날 수 있습니다. 맞춤형은 조직의 언어와 흐름을 세밀하게 반영할 수 있지만 요구사항 변경, 테스트, 유지보수 인력까지 기업이 책임져야 합니다. 지금 구현할 수 있는가보다 3년 동안 변경을 감당할 수 있는가를 물어야 선택이 선명해집니다.

온라인 주문, 전자계약, 고객 포털처럼 디지털 네트워크에서 거래와 업무가 연결되는 구조는 이비즈니스 개념 설명과도 맞닿아 있습니다. 이런 서비스는 화면 하나만 고쳐서 끝나지 않고 결제, 인증, 회계, 물류 데이터에 연쇄 영향을 줍니다. 따라서 맞춤 범위를 결정할 때 화면 요구보다 데이터 흐름과 책임 경계를 먼저 그리는 편이 안전합니다.

Q. 비용은 월 구독료와 개발 견적만 보면 충분한가요?

A. 실제 비용은 라이선스 외부에 더 많이 숨어 있습니다. 데이터 정리와 이전, 계정 및 권한 설계, 다른 시스템 연동, 직원 교육, 관리자 운영 시간, 계약 종료 시 데이터 반출까지 포함해야 합니다. 가령 이용료가 월 200만원인 서비스라도 담당자 두 명이 매달 수작업으로 데이터를 보정한다면 내부 인건비가 구독료를 넘어설 수 있습니다. 반대로 초기 설정비가 크더라도 반복 업무를 매월 수백 시간 줄인다면 총비용은 낮아집니다.

가격 검토 기간은 최소 24개월, 조직 변화가 큰 기업이라면 36개월로 잡는 것이 현실적입니다. 사용자 수 증가에 따른 요금, API 호출량, 저장 용량, 고객지원 등급, 추가 교육 비용을 세 가지 시나리오로 계산해 보세요. 현재 인원, 예상 인원, 사업 확장 인원을 나누면 낮은 시작 가격에 가려진 확장 비용을 발견할 수 있습니다.

1. 현재 반복 업무에 투입되는 월간 인건비와 오류 수정 비용을 계산합니다.
2. 구독료, 구축비, 연동비, 교육비, 데이터 이전비를 같은 기간 기준으로 환산합니다.
3. 사용자 수가 30%, 60% 늘었을 때의 요금 변화를 공급사에 서면으로 요청합니다.
4. 계약 해지와 서비스 변경에 필요한 데이터 추출 비용과 작업 기간을 반영합니다.
5. 절감 시간의 전부를 금액으로 잡지 말고 실제 재배치 가능한 시간만 편익으로 인정합니다.

관리자 만족과 직원 정착 사이의 간격은 어떻게 줄이나요?

Q. 교육까지 했는데 사용률이 낮은 진짜 이유는 무엇입니까?

A. 교육 부족으로만 보면 해결이 늦어집니다. 사용률이 낮은 가장 흔한 이유는 기존 방식보다 새 방식의 보상이 늦기 때문입니다. 직원은 데이터를 입력하자마자 얻는 이익이 없는데 관리자는 한 달 뒤 보고서를 편하게 받는 구조라면, 현장에는 입력 노동만 추가된 셈입니다. 그래서 새 서비스는 관리자용 통계보다 직원이 즉시 체감할 검색, 자동 완성, 중복 입력 제거부터 제공해야 합니다.

또 하나는 공식 절차와 실제 업무의 차이입니다. 설계자는 모든 요청이 정상 경로로 들어온다고 가정하지만 현장에는 전화 주문, 급한 구두 승인, 정보가 덜 갖춰진 고객 문의가 존재합니다. 이런 예외를 시스템이 받아주지 못하면 직원은 메신저에 임시로 남겼다가 나중에 옮겨 적습니다. 시간이 지나면 임시 채널이 본 업무 공간이 되고 기업 솔루션에는 보고용 데이터만 남게 됩니다.

사용자 인터뷰에서는 무엇이 불편한가요라고만 묻지 마세요. 어제 처리한 실제 업무 한 건을 처음부터 다시 보여 달라고 요청하는 편이 정확합니다. 어느 단계에서 다른 창을 열고, 누구에게 메시지를 보내며, 어떤 정보를 개인 메모장에 복사하는지 관찰하면 설명만으로 드러나지 않는 우회 경로를 찾을 수 있습니다. 독자님의 조직에서도 공식 매뉴얼에 없는 복사와 재입력이 하루에 몇 번 발생하는지 떠올려 보시기 바랍니다.

• 첫 주: 핵심 사용자 5~10명을 정해 실제 업무 장면을 관찰하고 막히는 순간을 기록합니다.
• 둘째 주: 필수 입력값을 줄이고 자주 쓰는 화면의 기본값과 자동 완성을 조정합니다.
• 셋째 주: 부서별 우회 채널을 조사해 서비스 안에서 처리할 예외 규칙을 만듭니다.
• 넷째 주: 로그인 수가 아니라 업무 완료율, 처리 시간, 재작업률 변화를 공유합니다.

직원에게 사용을 독려하기 전에 새 서비스가 직원의 어떤 수고를 당장 없애 주는지 한 문장으로 답할 수 있어야 합니다.

Q. 사용률은 어떤 지표로 측정해야 왜곡이 적을까요?

A. 월간 로그인 사용자만 보면 실상을 놓치기 쉽습니다. 자동 로그인 상태로 화면을 열기만 해도 활동으로 집계될 수 있고, 반대로 월말에 한 번만 수행하는 중요한 결산 업무는 낮은 빈도 때문에 과소평가될 수 있습니다. 지표는 접속이 아니라 업무 목적에 맞춰야 합니다. 고객지원 서비스라면 문의 접수부터 답변 완료까지 걸린 시간, 지식관리 서비스라면 검색 성공 후 문서를 다시 찾지 않은 비율이 더 유용합니다.

좋은 측정 구조는 채택, 효율, 품질, 지속성의 네 층으로 구성됩니다. 채택은 대상자 중 실제 핵심 기능을 사용한 비율, 효율은 처리 시간과 클릭 수, 품질은 오류와 재작업, 지속성은 4주 또는 8주 뒤에도 사용이 유지되는지를 봅니다. 여러 지표를 함께 보면 직원이 억지로 접속한 것인지, 업무 방식이 실제로 바뀐 것인지 구분할 수 있습니다.

• 핵심 행동 완료율: 로그인한 사람이 아니라 지정 업무를 끝낸 사람의 비율입니다.
• 중앙 처리 시간: 일부 극단값에 흔들리지 않도록 평균과 함께 중앙값을 확인합니다.
• 재작업률: 잘못된 입력, 반려, 중복 등록으로 다시 처리한 건의 비율입니다.
• 우회 채널 비중: 메신저, 이메일, 개인 문서에서 처리된 동일 업무의 양을 추적합니다.
• 잔존 사용률: 도입 직후가 아닌 4주차와 8주차의 핵심 사용자 비율을 비교합니다.

자동화 욕심과 운영 공백이 만날 때 생기는 세 가지 실수

Q. 기업이 도입 막바지에 가장 자주 놓치는 것은 무엇인가요?

A. 첫 번째 실수는 정상 흐름만 자동화하는 것입니다. 구매 요청이 정확히 입력되고 담당자가 자리에 있으며 연동 시스템이 항상 정상이라는 가정으로 설계하면, 한 요소만 어긋나도 전체 업무가 멈춥니다. 대리 승인, 담당자 휴가, 중복 고객, 연동 지연 같은 상황을 시험 데이터로 만들어 직접 통과시켜야 합니다. 자동화 범위가 넓을수록 수동 복구 절차와 책임자도 더 분명해야 합니다.

두 번째 실수는 모든 알림을 켜 두는 것입니다. 도입 초기에는 누락을 막겠다며 이메일, 앱, 메신저로 같은 알림을 반복 전송하기 쉽습니다. 하지만 중요도가 구분되지 않은 알림은 곧 배경 소음이 됩니다. 사용자는 정말 긴급한 승인까지 미루게 되므로 즉시 대응, 당일 처리, 주간 확인으로 등급을 나누고 동일 사건의 중복 알림을 제한해야 합니다.

세 번째 실수는 오픈 날짜를 프로젝트의 종료일로 보는 것입니다. 서비스 공개 후에는 실제 데이터에서만 나타나는 권한 오류와 예외 업무가 쏟아집니다. 최소 4주 동안은 질문 접수 창구, 수정 우선순위, 장애 대응 담당자, 변경 공지 방식을 유지해야 합니다. 이 운영 공백을 방치하면 작은 불편이 개인 엑셀과 비공식 메신저 방을 다시 만드는 씨앗이 됩니다.

1. 예외 시나리오를 생략하지 않습니다. 퇴사자 계정, 조직 이동, 승인자 부재, API 실패, 잘못된 파일 업로드를 실제처럼 시험합니다.
2. 알림 수를 성과로 착각하지 않습니다. 알림 이후 제때 완료된 행동의 비율을 측정하고 반응 없는 알림은 합치거나 제거합니다.
3. 운영 책임을 공급사에만 넘기지 않습니다. 공급사는 제품 장애를 해결할 수 있지만 사내 승인 규칙과 데이터 기준까지 대신 결정할 수는 없습니다.

Q. 계약 직전 30분 동안 무엇을 확인하면 효과적일까요?

A. 데모에서 준비된 성공 화면을 다시 보는 대신, 우리 회사에서 자주 발생하는 까다로운 사례 하나를 즉석에서 처리해 달라고 요청하세요. 필수 정보가 빠진 고객 요청을 등록하고, 담당자를 바꾸고, 승인을 반려한 뒤, 잘못 입력한 값을 복구하는 과정까지 보면 제품의 실제 유연성이 드러납니다. 공급사가 그 자리에서 답하지 못한 항목은 불가능하다고 단정하지 말고 구현 방식, 추가 비용, 예상 기간을 계약 부속 문서에 남겨야 합니다.

마지막으로 관리자 권한에서 데이터 내보내기, 변경 이력 조회, 계정 비활성화, 접근권한 회수를 직접 실행해 보세요. business 용어의 의미처럼 기업 활동은 사람과 자원, 거래가 연결된 과정이므로 한 화면의 편리함만으로 서비스 전체를 판단하기 어렵습니다. 잘 고른 기업 솔루션은 기능이 가장 많은 제품이 아니라 핵심 업무가 빠르게 끝나고, 예외가 생겨도 조직이 스스로 회복할 수 있는 서비스입니다.

• 샘플이 아닌 우리 업무 데이터로 검색과 등록 속도를 확인합니다.
• 관리자가 없이도 현업 사용자가 오류를 수정할 수 있는 범위를 확인합니다.
• 서비스 장애 시 임시 처리 방식과 데이터 재동기화 절차를 질문합니다.
• 추가 기능 요청의 접수 기준, 유상 여부, 평균 반영 기간을 문서화합니다.
• 도입 4주 뒤 사용 중단 기준과 개선 책임자를 미리 지정합니다.