비즈니스 프로세스 컨설팅은 솔루션 도입 실패를 줄인다

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

새 시스템을 도입했는데도 엑셀 파일이 줄지 않고, 승인 요청은 여전히 메신저에서 누락됩니다. 기능이 부족해서일까요, 아니면 업무 방식과 솔루션의 연결이 잘못된 것일까요? 이라이즈는 이 질문을 비즈니스 프로세스 컨설턴트 정유찬에게 던졌습니다. 이번 인터뷰에서는 기업 솔루션을 구매하기 전에 무엇을 진단하고 어떤 숫자로 성과를 확인해야 하는지 깊이 있게 짚습니다.

솔루션보다 업무 흐름을 먼저 봐야 하는 이유

Q. 기능이 많은 솔루션을 골라도 실패하는 이유는 무엇입니까?

A. 기업이 실제로 해결해야 할 대상은 기능 부족이 아니라 업무의 지연과 단절인 경우가 많습니다. 담당자가 고객 요청을 받은 뒤 어느 시스템에 입력하는지, 누가 승인하며, 다음 부서에는 어떤 형식으로 전달되는지부터 확인해야 합니다. 이 흐름을 보지 않고 제품을 선택하면 기존의 복잡한 절차가 새 화면 안으로 그대로 옮겨갈 뿐입니다.

비즈니스의 용어적 배경처럼 기업 활동은 여러 기능이 연결되어 가치를 만드는 과정입니다. 따라서 비즈니스 프로세스 컨설팅은 부서별 요구 기능을 모으는 데서 끝나지 않고, 고객 요청부터 결과 제공까지 이어지는 전체 흐름을 분석해야 합니다. 영업팀의 편의만 높였는데 재무팀의 정산 시간이 늘어난다면 기업 전체 관점에서는 개선이라고 보기 어렵습니다.

인터뷰를 시작할 때 컨설턴트가 먼저 확인하는 항목은 다음과 같습니다. 여러분의 조직에서도 같은 질문에 담당자마다 다른 답을 내놓는다면 솔루션 선정 전에 프로세스 정의가 필요하다는 신호입니다.

• 업무의 시작 조건과 최종 완료 기준이 명확한가
• 입력한 정보를 다른 부서가 다시 타이핑하고 있지 않은가
• 승인 대기와 실제 작업 시간을 구분해 측정하는가
• 예외 상황을 특정 직원의 경험으로만 처리하지 않는가

현장 인터뷰는 불편한 우회 업무를 찾아낸다

Q. 업무 프로세스 진단에서는 누구를 만나야 합니까?

A. 팀장만 인터뷰해서는 실제 업무를 충분히 알기 어렵습니다. 관리자는 표준 절차를 설명하지만 실무자는 파일 변환, 중복 입력, 전화 확인처럼 문서에 없는 우회 업무를 수행합니다. 요청자, 처리자, 승인자, 결과를 넘겨받는 후속 부서에서 각각 한 명 이상을 선정해야 흐름의 끊어진 지점이 보입니다.

예를 들어 견적 승인 절차가 시스템상 2단계라고 해도 담당자가 승인 전에 메신저로 팀장의 의중을 묻는다면 사실상 3단계입니다. 이 비공식 확인을 무시한 채 전자결재만 바꾸면 직원들은 새 솔루션과 메신저를 동시에 사용합니다. 컨설팅에서는 이런 행동을 잘못이라고 지적하기보다 왜 공식 절차만으로 안심할 수 없는지를 질문해야 합니다.

좋은 인터뷰는 의견보다 최근 사례를 기준으로 진행합니다. “평소에 불편한 점이 무엇입니까?”보다 “어제 처리한 주문 한 건을 처음부터 보여주세요”라고 요청하면 실제 화면 전환과 대기 시간이 드러납니다.

1. 최근 완료된 정상 업무 한 건을 화면과 함께 재현합니다.
2. 반려되거나 수정된 예외 업무 한 건을 별도로 추적합니다.
3. 사용한 파일, 메신저, 이메일과 시스템을 순서대로 기록합니다.
4. 각 단계에서 기다린 시간과 직접 작업한 시간을 나눠 적습니다.
5. 같은 업무를 다른 담당자에게 물어 절차 차이를 확인합니다.

“직원이 규정을 우회했다면 사람보다 먼저 구조를 살펴야 합니다. 우회로는 공식 프로세스가 충족하지 못한 속도나 정보가 무엇인지 알려주는 단서입니다.”

현재 프로세스는 시간과 오류로 수치화해야 한다

Q. 업무 흐름을 그림으로 그리는 것만으로 충분하지 않습니까?

A. 프로세스 맵은 출발점일 뿐입니다. 개선 우선순위를 정하려면 처리 건수, 직접 작업 시간, 승인 대기 시간, 오류율, 재작업률을 붙여야 합니다. 한 달에 한 번 4시간 걸리는 업무보다 매일 30명이 10분씩 반복하는 입력 작업이 더 큰 비용을 만들 수 있기 때문입니다.

측정 기간은 업무 주기를 포함해야 합니다. 일상 업무는 최소 2주, 월말 정산이나 급여처럼 특정 시점에 몰리는 업무는 한 사이클 이상 관찰하는 편이 안전합니다. 로그가 없다면 5영업일 동안 간단한 타임시트를 기록하고, 시스템 생성 시각과 승인 시각을 대조하는 방법도 사용할 수 있습니다. 측정 자체가 지나치게 복잡해져 현장 업무를 방해해서는 안 됩니다.

아래 지표는 솔루션 도입 전후를 동일한 기준으로 비교하기 좋습니다. 모든 수치를 완벽히 수집하려 하지 말고 기업의 핵심 문제와 직접 연결되는 3~5개를 선택하십시오.

• 리드타임: 요청 접수부터 최종 완료까지 걸린 전체 시간
• 터치타임: 직원이 실제 입력·검토·수정에 사용한 시간
• 재작업률: 전체 처리 건 중 반려나 수정이 발생한 비율
• 이관 오류율: 부서 간 전달 과정에서 누락·오입력이 발생한 비율
• 자동 처리율: 사람의 개입 없이 규칙대로 완료된 업무 비율

Q. 비용 효과는 어떻게 계산합니까?

A. 월 절감 시간에 참여 인원과 시간당 내부 원가를 곱하되, 그 전부가 현금 절감으로 이어진다고 과장해서는 안 됩니다. 확보된 시간이 추가 영업, 고객 대응, 오류 예방에 어떻게 재배치되는지까지 정의해야 현실적인 투자 효과가 됩니다.

요구사항은 기능 목록이 아니라 업무 시나리오로 써야 한다

Q. 제안요청서에는 어떤 내용을 담아야 합니까?

A. “대시보드 제공”, “모바일 지원”, “AI 기능 포함”처럼 짧은 기능 목록만 적으면 공급사마다 다른 의미로 답변합니다. 대신 누가 어떤 조건에서 업무를 시작하고, 어떤 데이터를 조회하며, 예외가 발생했을 때 누구에게 알리고, 완료 결과를 어디에 남겨야 하는지를 시나리오로 작성해야 합니다. 그래야 데모에서 실제 업무 적합성을 확인할 수 있습니다.

이비즈니스의 개념에서 살펴볼 수 있듯 디지털 환경의 업무는 기업 내부뿐 아니라 고객과 협력사까지 연결됩니다. 요구사항에도 외부 사용자의 접근 권한, 데이터 전달 형식, 동의와 보관 절차를 포함해야 합니다. 내부 화면만 편리하고 협력사가 매번 파일을 다시 만들어야 한다면 전체 프로세스는 개선되지 않습니다.

요구사항은 중요도와 검증 방법을 함께 적어야 합니다. 다음 세 등급을 사용하면 모든 기능을 한 번에 구현하려는 부담을 줄이고, 필수 업무가 화려한 부가기능에 밀리는 상황도 예방할 수 있습니다.

• 필수: 없으면 법적 의무나 핵심 영업 활동을 수행할 수 없는 기능
• 중요: 수작업으로 대체할 수 있지만 시간과 오류가 크게 늘어나는 기능
• 선택: 사용 경험을 높이거나 향후 확장 단계에서 필요한 기능

Q. 데모에서는 무엇을 요청해야 합니까?

A. 준비된 소개 화면 대신 익명화한 샘플 데이터를 제공하고, 정상 주문과 반려 주문을 각각 처리해 달라고 요청하십시오. 권한 변경, 대량 업로드 실패, 중복 고객 발견처럼 불편한 상황까지 보여달라고 해야 솔루션의 실제 운영 난도를 판단할 수 있습니다.

표준화와 맞춤 개발의 경계가 운영비를 결정한다

Q. 우리 회사 방식에 맞춰 모두 개발하면 더 편하지 않습니까?

A. 초기에는 편해 보이지만 맞춤 개발이 늘수록 버전 업데이트, 오류 수정, 담당자 교체 때 비용이 커집니다. 반대로 업무 특성을 무시하고 솔루션의 표준 절차만 강요하면 현장에 별도 엑셀이 생깁니다. 중요한 것은 핵심 경쟁력을 만드는 프로세스와 관행 때문에 남아 있는 절차를 구분하는 일입니다.

예컨대 업종 고유의 가격 산정 공식이나 품질 승인 규칙은 맞춤 구성이 필요할 수 있습니다. 그러나 부서마다 다른 날짜 표기, 중복 승인, 개인별 보고서 양식은 표준화 후보에 가깝습니다. “오래 해왔기 때문에 필요하다”는 설명만으로는 맞춤 개발 근거가 되지 않습니다. 고객 가치, 위험 통제, 법적 요구 가운데 적어도 하나와 연결되어야 합니다.

의사결정 회의에서는 아래 기준을 동일하게 적용하십시오. 예외를 허용할 때는 개발비뿐 아니라 향후 3년간 테스트와 변경 관리 비용도 함께 기록해야 합니다.

맞춤 개발 여부를 기능 단위로 결정하지 말고, 그 기능이 없을 때 발생하는 연간 손실과 3년 운영비를 같은 표에 올려 판단하십시오.

파일럿은 사용률보다 업무 성과를 검증해야 한다

Q. 시범 운영은 몇 명으로 어떻게 시작하는 것이 좋습니까?

A. 인원이 많다고 좋은 파일럿은 아닙니다. 하나의 업무가 시작부터 완료까지 끊김 없이 지나갈 수 있도록 요청자, 처리자, 승인자, 후속 업무 담당자를 포함한 8~15명 정도의 작은 팀이 실용적입니다. 단순 로그인 수를 늘리는 대신 실제 업무 유형 2~3개를 완주하도록 설계해야 합니다.

파일럿 기간은 일반적으로 준비 1~2주, 실제 운영 3~4주, 결과 분석 1주 정도를 가정할 수 있습니다. 다만 월말 업무를 검증한다면 해당 기간을 반드시 포함해야 합니다. 첫 주에는 교육 효과 때문에 처리 시간이 길어질 수 있으므로 첫날 수치만 기존 방식과 비교해서는 안 됩니다. 2주차 이후의 중앙값과 예외 처리 결과를 함께 살펴보는 편이 정확합니다.

business의 사전적 의미가 경제적 활동과 거래의 맥락을 포함하듯, 기업 솔루션도 단순한 사용 편의가 아니라 실제 가치 창출로 평가해야 합니다. 다음과 같은 통과 기준을 도입 전에 합의하면 담당자의 인상이나 공급사의 설명에 흔들리지 않습니다.

1. 핵심 업무 리드타임이 기준 대비 20% 이상 줄어드는지 확인합니다.
2. 중복 입력 횟수와 필수 입력 누락이 실제로 감소했는지 측정합니다.
3. 예외 사례의 80% 이상을 별도 엑셀 없이 처리할 수 있는지 봅니다.
4. 신규 사용자가 2시간 이내 교육으로 핵심 시나리오를 완료하는지 시험합니다.
5. 장애 발생 시 데이터 복구와 수작업 대체 절차를 실행해 봅니다.

Q. 파일럿이 기대에 못 미치면 바로 제품을 바꿔야 합니까?

A. 원인을 제품 기능, 프로세스 설계, 데이터 품질, 교육 부족으로 나눠야 합니다. 해결 가능한 설정 문제라면 한 차례 수정 실험을 진행하고, 핵심 요구사항 자체를 충족하지 못한다면 매몰비용에 끌려가지 말고 후보를 다시 검토해야 합니다.

도입 판단은 6주와 3년의 숫자를 함께 본다

Q. 현실적인 예산과 일정은 어떻게 잡아야 합니까?

A. 제품 구독료만 예산으로 잡으면 실제 지출을 놓칩니다. 프로세스 진단, 데이터 정제, 초기 설정, 연동 개발, 사용자 교육, 운영 지원을 분리해 계산해야 합니다. 특히 고객·상품 코드가 중복되어 있거나 담당자별 엑셀 형식이 다르면 데이터 정제에 예상보다 많은 시간이 듭니다. 견적을 받을 때는 일회성 구축비와 월간 반복비를 반드시 구분하십시오.

중소 규모의 단일 프로세스를 대상으로 한 사전 진단은 인터뷰와 현황 분석에 약 2~3주, 요구사항 및 개선안 작성에 1~2주가 필요할 수 있습니다. 파일럿까지 포함하면 최소 6~8주의 일정을 확보하는 편이 현실적입니다. 이는 고정 기준이 아니라 업무 복잡도에 따른 계획용 범위이며, 여러 법인이나 외부 협력사 연동이 포함되면 별도 검증 기간을 추가해야 합니다.

최종 의사결정표에는 다음 숫자를 한 화면에 배치하십시오. 초기 구축비가 낮아도 운영 인력이 매달 많이 필요하면 3년 총비용이 커질 수 있고, 반대로 초기 컨설팅 비용이 있더라도 재작업과 연동 장애가 줄면 회수 기간이 짧아질 수 있습니다.

• 진단 기간: 2~3주, 핵심 인터뷰 6~12명
• 파일럿 범위: 사용자 8~15명, 핵심 시나리오 2~3개
• 전체 검증 일정: 최소 6~8주, 월말 업무 포함 시 한 사이클 추가
• 예산 항목: 구독료·구축비·연동비·교육비·연간 운영비를 분리
• 투자 판단: 12개월 효과와 3년 총소유비용을 동시에 비교

Q. 경영진에게는 어떤 한 장을 제시해야 합니까?

A. 현재 월간 처리량, 평균 리드타임, 재작업률, 3년 총비용, 목표 회수 기간을 나란히 보여주십시오. 여기에 도입하지 않을 때의 연간 오류 비용과 지연 손실을 더하면 단순한 제품 구매안이 아니라 기업 성장에 필요한 비즈니스 솔루션 투자안으로 논의할 수 있습니다.