Photo by Kampus Production on Pexels
수천만 원에서 수억 원의 예산을 들여 ERP, CRM, MES나 자체 업무 시스템을 도입하기로 결정한 중소기업 대표님들이 자주 빠지는 착각이 있습니다. 바로 "실력 있는 개발사나 솔루션 업체를 선정했으니, 이제 계약금 주고 기다리기만 하면 멋진 시스템이 완성되겠지"라는 생각입니다.
하지만 현실은 참혹합니다. 계약 기간이 지나도 오픈을 못 하거나, 막상 오픈을 해도 직원들이 쓸 수 없다며 불만을 토로하고 결국 기존처럼 엑셀로 돌아가는 일이 비일비재합니다. 소프트웨어 구축 프로젝트 실패 원인의 70% 이상은 개발사의 기술력 부족이 아니라, 사업을 발주한 기업 내부의 프로젝트 관리(PM) 부실에서 발생합니다.
시스템 도입을 검토 중이거나 이제 막 프로젝트를 시작한 중소기업 대표가 현장에서 가장 흔히 저지르는 4가지 관리 실수와 이를 즉시 바로잡을 수 있는 실무 해결책을 구체적으로 정리해 드립니다.
실수 1: "외주업체가 알아서 정해주겠지" - 요구사항 정의 유보와 범위 확정 지연
많은 중소기업이 "우리가 프로세스를 잘 모르니 전문가인 개발사가 알아서 베스트 프랙티스를 적용해 달라"고 요청합니다. 그러나 공급업체나 SI 개발사는 우리 회사의 세부 영업 규칙, 예외 상황, 현장 특수성을 알지 못합니다. 사업 초기 단계에서 요구사항을 명확히 정의하지 않고 넘어가면, 프로젝트 중반 이후 "이 기능이 왜 없느냐"와 "추가 개발 비용을 내라"는 주장이 대립하며 프로젝트가 멈춰 서게 됩니다.
실제로 정밀 부품 제조업체 A사는 MES(생산관리시스템) 구축 당시 요구사항을 구체화하지 않은 채 계약을 체결했습니다. 개발 중반에야 현장 작업자의 설비별 세부 세팅값 입력 방식이 빠졌음을 확인했고, 이 수정 작업으로 인해 전체 납기가 4개월 지연되고 추가 개발비 3,500만 원이 발생했습니다.
해결책: AS-IS vs TO-BE 갭 분석표 작성 및 현업 요구사항 문서화
계약 전후 단계에서 대표이사는 현업 부서장에게 기존 업무 방식(AS-IS)의 문제점과 시스템 도입 후 바뀔 방식(TO-BE)을 아래와 같은 표준 양식으로 정리하도록 지시해야 합니다. 공급업체에게는 이 문서를 바탕으로 견적과 일정을 산출하도록 해야 범위 팽창을 막을 수 있습니다.
| 요구사항 ID | 업무 구분 | 현행 방식 (AS-IS) | 개선 요구사항 (TO-BE) | 우선순위 |
|---|---|---|---|---|
| REQ-REQ-01 | 영업 견적 관리 | 담당자별 개인 엑셀 파일로 견적서 작성 후 이메일 발송 | 시스템 내 단가표 기반 자동 견적 생성 및 승인 이력 저장 | 필수(Must) |
| REQ-PROD-02 | 생산 실적 등록 | 퇴근 전 작업지시서 종이에 손글씨 기입 후 반장이 일괄 입력 | 태블릿 터치 방식으로 작업 완료 즉시 실시간 데이터 반영 | 필수(Must) |
| REQ-STAT-03 | 경영진 보고 | 매주 월요일 아침 팀별 엑셀 취합 후 보고서 제작 (3시간 소요) | 대시보드 통한 실시간 매출/생산성 지표 조회 기능 제공 | 선택(Should) |
실수 2: 기존 업무량 유지 상태에서 실무자에게 구축 TF 겸직 발령
시스템 도입 프로젝트가 시작되면 회사에서 일을 가장 잘하는 에이스 팀장이나 과장을 PM(프로젝트 리더) 또는 TF(Task Force) 팀원으로 투입합니다. 문제는 이들에게 기존 영업, 생산, 회계 업무를 100% 그대로 맡기면서 시스템 구축 작업까지 병행시킨다는 점입니다.
본업 업무 과중에 시달리는 실무자는 개발사와 진행하는 미팅을 '추가 야근을 유발하는 짐'으로 인식하게 됩니다. 결과적으로 개발사가 가져온 설계안을 깊이 검토하지 않고 대충 승인해 주었다가, 시스템 오픈 직전에 "이렇게 만들어 놓으면 우리는 일을 못 한다"라며 대대적인 재작업을 요구하는 대참사가 벌어집니다.
해결책: 업무 전담률(Allocation) 명시 및 이관 지시 스크립트 활용
프로젝트에 투입되는 내부 핵심 인력에게는 반드시 투입 비율을 공식 명시하고, 그 비율만큼 기존 업무를 다른 팀원에게 이관해주어야 합니다. 대표이사는 직접 부서장 회의에서 이를 공식 선언해야 합니다.
[대표이사 내부 공지/지시 스크립트 예시]
"이번 ERP 구축 사업의 성공적인 완수를 위해 박 과장의 프로젝트 투입 비율을 50%로 설정합니다. 박 과장이 맡고 있던 기존 A 고객사 관리 및 주간 매출 취합 업무는 프로젝트 완료 시까지 이 대리와 김 사원에게 이관합니다. 박 과장의 인사평가는 프로젝트 마일스톤 달성 여부를 50% 반영할 것이며, 각 부서장은 박 과장의 프로젝트 수행 시간에 대해 업무 이기주의를 부리지 않고 적극 협조하기 바랍니다."
실수 3: 개발 중간 과정 검수 생략과 최종 오픈일 일괄 검수
많은 경영진이 계약서에 찍힌 '시스템 완료 예정일'만 다이어리에 표시해 두고 중간 과정을 점검하지 않습니다. 개발사가 매월 보내오는 "잘 진행되고 있습니다"라는 구두 보고만 믿고 있다가, 완료 2주 전 시연회(Demo)에서 엉뚱하게 만들어진 화면을 보고 분통을 터뜨립니다.
소프트웨어 개발은 건축과 같습니다. 기초 공사(디자인/화면 설계), 골조 공사(DB 설계), 인테리어(기능 구현) 단계별로 검수를 거치지 않고 완공 일에 집을 확인하면, 벽을 헐고 다시 지어야 하는 상황이 발생합니다.
해결책: 마일스톤 기반 4단계 승인 절차 및 검수 체크리스트 운영
대표이사는 전체 구축 일정을 4단계 마일스톤으로 나누고, 각 단계별 산출물이 서면으로 승인되지 않으면 다음 단계 대금(중도금)을 지급하지 않는 구조를 만들어야 합니다.
| 단계 | 점검 시기 | 핵심 검수 항목 (산출물) | 대표이사 확인 포인트 |
|---|---|---|---|
| 1단계: 분석/설계 | 프로젝트 시작 후 1~2개월 | 화면 설계서(StoryBoard), 프로세스 정의서 | 현업 실무자가 실제 일하는 동선과 맞는지 확인했는가? |
| 2단계: 핵심 기능 구축 | 프로젝트 50% 시점 | 주요 메뉴 단위 테스트 시연 영상 또는 환경 | 입력-저장-조회 기본 프로세스가 오류 없이 작동하는가? |
| 3단계: 통합 테스트 | 오픈 1개월 전 | 실데이터 이관 결과, 사용자 시나리오 테스트 내역 | 과거 3개월치 실제 데이터를 넣었을 때 계산 오류가 없는가? |
| 4단계: 최종 안정화 | 오픈 후 2주~1개월 | 사용자 교육 수료율, 시스템 에러 조치율 현황판 | 현업 부서 전원이 엑셀 대신 시스템으로 업무를 처리하는가? |
실수 4: 변화 관리(Change Management) 부재와 기존 방식 병행 방치
모든 개발이 완료되고 시스템이 정상 오픈되어도, 직원들의 강력한 저항에 부딪힙니다. 기존에 엑셀로 처리하던 방식이 훨씬 익숙하기 때문에 "새 시스템은 버튼이 너무 많아서 불편하다", "조회 속도가 둔하다"라는 핑계를 대며 은밀히 옛날 방식으로 업무를 처리합니다.
경영진이 이를 강하게 통제하지 않고 "적응할 때까지 당분간 엑셀과 시스템을 병행하라"고 지시하는 순간, 시스템 도입 프로젝트는 사실상 실패로 끝납니다. 직원들은 이중 입력의 피로감을 호소하며 결국 새 시스템 입력을 포기하게 됩니다.
해결책: 단계별 셧다운(Shutdown) 전략 및 시스템 연동 평가 반영
변화 관리는 설득이 아닌 '제도와 환경의 전환'으로 달성해야 합니다. 기존 방식을 물리적으로 차단하는 단계적 셧다운 전략과 시스템 입력 데이터를 기반으로 경영 보고를 일원화하는 조치가 필요합니다.
- 1단계 (오픈 후 1~2주 차): 병행 운영 및 데이터 비교 점검
- 기존 방식과 새 시스템을 동시에 운영하되, 발생한 데이터 불일치는 개발사가 매일 수정 조치합니다.
- 2단계 (오픈 3주 차): 기존 양식 및 엑셀 보고서 전면 폐기 (Hard Cut-over)
- 대표이사 주간 간부회의 시 엑셀 출력물 보고를 일체 금지하고, 오직 신규 시스템의 대시보드 화면을 빔프로젝트로 띄워 보고받습니다. 시스템에 입력되지 않은 실적은 인정하지 않습니다.
- 3단계 (오픈 1개월 이후): 시스템 정착 마일리지 및 KPI 연동
- 부서별 데이터 입력 기한 준수율, 에러 제보 건수 등을 수치화하여 부서 KPI 평가 점수에 가산점을 부여하거나 정착 이벤트를 통해 포상합니다.
시스템 도입 사업 성공을 위한 발주사 실무 거버넌스 가이드
대표이사가 개발 과정 내내 모든 미팅에 참석할 수는 없습니다. 따라서 외부 개발사와 내부 TF 팀이 균형을 이루며 이탈 없이 프로젝트를 완수할 수 있도록 최소한의 프로젝트 관리 체계(Governance)를 구축해야 합니다.
- 주간 진행 상황 보고서의 수치화
- 개발사로부터 "잘 진행되고 있다"는 구두 보고 대신, 전체 WBS(작업분할구조도) 대비 '계획 진척률 vs 실제 진척률'을 퍼센티지(%) 숫자로 매주 서면 보고받으세요. 갭이 5% 이상 발생 시 즉시 지연 사유와 회복 계획(Catch-up Plan) 제출을 요구해야 합니다.
- 의사결정권자의 명확화 및 대표이사 직속 승인 라인 구성
- 현업 부서 간 기능 요구사항이 충돌할 때(예: 영업부는 관대한 기준 요구 vs 회계부는 엄격한 승인 절차 요구) 이를 정리할 최종 의사결정권자를 대표이사 또는 전담 PM 이사로 단일화해야 개발 혼선을 막습니다.
- 계약서 내 계약 변경(Change Order) 절차 명시
- 프로젝트 진행 중 추가 기능 요구가 나올 경우, 구두 합의를 금지하고 반드시 '범위 변경 요청서'를 통해 추가 비용과 일정 지연 예측치를 대표이사의 최종 승인을 받은 후 진행하도록 통제합니다.
대표이사가 즉시 실행해야 할 핵심 관리 항목 4가지
신규 시스템 도입을 앞두고 있거나 이미 진행 중인 기업의 경영진은 오늘 당각 아래 4가지 항목을 점검하고 현장에 적용해야 합니다.
- 요구사항 사전 문서화: 공급업체 미팅 전 현업의 업무 프로세스 갭(AS-IS vs TO-BE) 분석표를 내부적으로 먼저 작성하여 제공하십시오.
- 내부 PM/TF 자원 확보: 핵심 담당자의 본업 업무를 최소 30% 이상 타 직원에게 이관하고, 프로젝트 전담률을 공식 선언하십시오.
- 단계별 마일스톤 검수: 4단계 마일스톤 승인(설계-단위개발-통합테스트-안정화) 절차 없이 중도금 및 잔금을 지급하지 마십시오.
- 기존 방식의 과감한 셧다운: 시스템 오픈 3주 차부터는 기존 엑셀 보고를 전면 금지하고 시스템 대시보드로만 경영 보고를 받으십시오.