- Standish Group이 2020년 발표한 CHAOS 보고서에 따르면, 소프트웨어 프로젝트의 66%가 예산을 초과하거나 일정을 넘겼습니다. 가장 빈번한 원인 중 하나는 전환기 운영 계획의 부재였습니다.
- 구 시스템과 새 시스템이 동시에 운영되는 기간에, 팀은 같은 데이터를 두 곳에 입력하고, 두 시스템의 수치가 다를 때 어느 것이 기준인지 판단해야 합니다. 이 이중 부담은 학습 곡선보다 오래 지속됩니다.
- 새 시스템 도입 계획에 구 시스템 종료 날짜가 없으면, 프로젝트 종료 시점에 시스템이 두 개가 됩니다.
도입 직후가 가장 느린 이유
제조업 중견기업의 생산관리시스템(MES) 교체 프로젝트에서 새 시스템 가동 3개월 후 생산 현황 보고에 혼선이 생겼습니다. 시스템 오류가 아니었습니다. 현장 담당자들이 기존 엑셀 보고를 계속 작성하면서 새 시스템에도 같은 데이터를 따로 입력하고 있었습니다. 이유를 물었을 때, '새 시스템 숫자가 맞는지 아직 확신이 없어서 기존 방식도 병행하고 있다'는 답이 돌아왔습니다. ERP 자체 개발 경험에서도 같은 패턴을 반복해서 봤습니다.
새 시스템이 처음에 느린 것은 학습 곡선 때문입니다. 이것은 예상된 비용입니다. 그러나 더 오래 지속되는 병목은 따로 있습니다. 구 시스템을 끄지 않으면 팀은 두 시스템을 동시에 유지합니다. 새 시스템에 익숙해지면 속도가 나야 하는데, 구 시스템 데이터까지 병행 관리하는 이중 부담이 남습니다. 이 상태가 6개월을 넘으면 구 시스템이 사실상 정규 운영으로 굳어집니다.
새 시스템 도입 계획에 구 시스템 종료 날짜가 없으면, 프로젝트 종료 시점에 시스템이 두 개가 됩니다.
이중 운영이 만드는 세 가지 숨은 비용
첫째는 데이터 이중 입력 부담입니다. 같은 거래나 생산 실적을 두 시스템에 각각 입력하는 시간은 단순 합산이 아닙니다. 입력 맥락을 전환하는 인지 비용이 추가됩니다. 현장 담당자는 하루 업무 중 특정 시간을 두 시스템 관리에 씁니다. 이 시간은 보고서에 잡히지 않는 비용입니다.
둘째는 의사결정 기준의 혼선입니다. 두 시스템의 수치가 다를 때, 어느 것이 기준인지 매번 판단이 필요합니다. 특히 경영 보고에서 어느 시스템 데이터를 쓸지 정해지지 않으면, 보고 자료마다 숫자가 달라지고 신뢰도가 낮아집니다. John Kotter가 정리한 조직 변화 실패 패턴 중 하나가 조기 승리 선언 후 변화를 완수하지 않는 것입니다. 구 시스템 유지는 이 패턴의 전형입니다.
셋째는 IT 지원 이중화 비용입니다. 두 시스템을 동시에 유지하면 라이선스, 유지보수, 내부 지원 인력이 두 배에 가깝게 필요합니다. 신규 시스템 구축에 쓴 예산과 별개로, 구 시스템 유지 비용이 계속 발생합니다. 이 비용은 도입 예산에 포함되지 않았기 때문에 무형의 지출로 남습니다.
전환기를 설계하는 조건
Ahn Partners 판단: 아래는 ERP, MES, CRM 등 업무 시스템 교체 프로젝트를 직접 경험한 관찰에서 나온 제안입니다. 프로젝트마다 조건이 다르므로, 원칙이 아닌 검토 기준으로 씁니다.
첫째, 계약 전에 구 시스템 종료 일정을 확정합니다. 새 시스템 가동일과 함께 구 시스템 접근 차단일을 명시합니다. 이것이 계획에 없으면, 종료일은 없는 것과 같습니다. '안정화가 되면 끄겠다'는 조건은 대개 끄지 않겠다는 의미입니다.
둘째, 이중 운영 기간을 명시적으로 설계합니다. 두 시스템이 동시에 운영되는 기간의 데이터 입력 기준, 보고 기준, 의사결정 기준을 미리 정합니다. 이 기간을 최대 3개월로 제한하고, 그 이후에는 새 시스템만을 기준으로 운영하는 일정을 계획에 포함시킵니다.
새 시스템이 더 느리다는 불만이 나올 때, 시스템 기능 문제인지 이중 운영 부담인지를 먼저 분리해야 합니다. 이 두 원인은 처방이 다릅니다. 기능 문제는 커스터마이징으로 해결하고, 이중 운영 부담은 구 시스템을 끄는 것으로 해결합니다.
점검 목록
- 지금 사용 중인 시스템 중 '보조 도구'라고 부르지만 실제로는 의사결정 기준 데이터를 가진 것이 있는가
- 신규 시스템 도입 계획서에 구 시스템 종료 일정이 날짜로 명시되어 있는가
- 두 시스템의 데이터가 불일치할 때 어느 것을 기준으로 보고할지 기준이 정해져 있는가
출처
- Standish Group. (2020). CHAOS Report 2020. Standish Group Research. (소프트웨어 프로젝트 성공률 및 실패 원인 분석)
- Kotter, J.P. (1996). Leading Change. Harvard Business School Press. (조직 변화 실패 패턴 8단계 분석)
- Venkatesh, V., Morris, M.G., Davis, G.B., & Davis, F.D. (2003). User Acceptance of Information Technology: Toward a Unified View. MIS Quarterly, 27(3), 425-478.