1 ) ERP 도입 에 실패 하 는 이유 우선 , 어떻게 해야 ERP 를 성공 적 으로 구축 하 고 기업 의 경쟁력 을 획기적으로 끌어올릴 수 있 을 것 인가 를 고민 하 기 전 에 , 왜 많 은 기업 들 이 ERP 를 도입 하 면서 난관 에 봉착 하 게 되 고 극단 적 으로 는 오랜 노력 과 시간 , 자금 , 인력 을 투입 하 고 도 그 에 상응 하 는 효과 를 보 지 못하 고 실패 하 게 되 는지 그 요인 들 을 짚 어 보 자 . 대부분 의 실패 하 는 기업 에서 공통 적 으로 도출 되 고 있 는 요소 들 은 우리 도 당할 수 있 는 함정 일 수 가 있 기 때문 이 며 , 이 를 통해 사전 에 이 함정 들 을 피해 갈 수 있 는 대비책 을 마련 하 기 위해서 라도 ERP 도입 을 고려 하 는 모든 기업 들 이 한 번 쯤 신중히 판단 해 보 아야 하 는 부분 이 라고 할 수 있 다 . * 잘못 된 개념 에서 출발 위 에서 언급 했 듯이 ERP 는 과거 의 전산 소프트웨어 와 는 질 적 으로 틀리 게 됨 에 도 불구 하 고 많 은 기업 의 실무자 들 은 패키지 를 이용 한 새로운 전산 화 방법 정도 로 이해 하 는 경우 가 많 다 . 더 나아가 과연 패키지 를 가지 고 우리 업무 를 통합 할 수 있 을까 하 는 의구심 으로 까지 증폭 된다 . 이렇게 되 면 ERP 를 도입 하 여 얻 고자 하 는 목적 자체 가 불 가능 해진다 . ERP 는 단순히 현재 존재 하 는 업무 자체 를 보조 하 기 위해 도입 되 는 것 이 아니 기 때문 이 다 . 사실 나중 에 이야기 하 겠 지만 기업 에 따라서 는 ERP 구축 의 목표 가 어떻게 설정 되 느냐 에 따라 다양 한 접근 방법 이 있 기 는 하 다 . 하지만 이 또한 도입 하 는 기업 에서 ERP 의 사상 을 어느 정도 까지 수용 할 것 인가 의 수위 조절 은 있 을 수 있 어도 현행 업무 를 단순히 보조 하 는 차원 에서 전산 화 하 겠 다는 관점 에서 는 벗어나 야 성공 할 수 있 음 을 명심 해야 한다 . 그렇 지 못하 면 과거 와 달라질 것 이 하나 도 없 게 된다 . ­ * 목표 설정 상 의 오류 출발 부터 잘못 된 개념 의 영향 이 기 는 하 겠 지만 ERP 도 입시 전사 적 인 경영 혁신 으로 추진 되 지 못하 고 전산 부서 내지 는 실무 부서 의 담당자 들 수준 에서 업무 용 소프트웨어 하나 를 도입 한다는 식 으로 진행 되 는 경우 , 시스템 구축 이 야 끝낼 수 있 을지 는 몰라도 그 효과 는 기대 하 지 않 는 것 이 좋 다 . 사용자 의 호응도 문제 겠 지만 , 현재 기업 이 처해 있 는 근원 적 인 문제 해결 에 는 거의 도움 이 되 지 않 을 것 이 뻔하 기 때문 이 다 . * 구성원 들 의 적극 적 인 참여 부진 도입 된 ERP 시스템 을 사용 하 게 될 주체 는 기업 내 의 구성원 이 지 도입 담당자 몇몇 이 아니 다 . 잘못 된 개념 에서 출발 하 거나 목표 설정 상 의 오류 가 있 게 되 면 구성원 들 의 적극 적 인 지지 를 얻 어 내 기 는 요원 하 다는 사실 을 명심 해야 한다 . 특히 간부 들 이 무 관심 할 경우 에 는 그만큼 실패 할 확률 이 높 다는 사실 을 사전 에 인지 하 는 것 이 좋 다 . 현재 간부 들 이 무 관심 하 다면 ERP 시스템 을 검토 하 기 전 에 그 들 로부터 광범위 한 동의 와 지지 를 이끌 어 내 는 작업 부터 진행 되 어야 한다 . 특히 ERP 를 구축 하 게 되 면 근본 적 으로 업무 프로세스 가 변화 하 게 될 수 도 있 기 때문 에 극단 적 으로 는 실무 현장 의 조직 적 인 반발 과 거부 에 직면 하 게 될 수 도 있 다 . 이렇게 되 면 그 결과 는 불 을 보 듯 자명 하 다 . * 확고 하 지 못한 추진 주체 ERP 를 구축 하 게 되 는 기간 동안 에 는 사실 도입 기업 의 ERP 추진 주체 야말로 도입 후 기업 의 운명 을 결정지 을 수 도 있 는 핵심 적 인 역할 을 수행 하 고 있 는 것 임 을 명심 해야 한다 . 따라서 주위 방관자 들 의 불 필요 한 간섭 과 견제 를 배제 할 수 있 는 파워 가 필요 하 게 되 고 , 그렇 기 때문 에 ERP 구축 은 Top _ Down 방식 으로 진행 되 어야 한다고 모든 사람 들 이 말 하 는 것 이 다 . 또한 ERP 구축 에 참여 하 는 사람 들 또한 사명감 과 책임 감 을 가지 고 그 조직 내 최고 의 엘리트 들 로 구성 되 어야 배 가 산 으로 가 지 않 게 된다 . 2 ) ERP 를 도입 하 고자 하 는 기업 이 고려 해야 할 10 가지 요소 자 이제 구체 적 으로 공급 업체 를 접촉 하 고 우리 기업 에 맞 는 ERP 시스템 을 선별 해 내 는 작업 을 시작 하 기 전 에 다음 에 열거 하 는 열 가지 요소 는 꼭 점검 해 보 고 만반 의 준비 를 갖추 도록 하 자 . 일반 적 으로 ERP 를 도입 하 는 기업 이 계약 하 는 마지막 순간 까지 도 아무리 치밀 한 분석 과 평가 를 진행 했 다고 하 더라도 파악 한 내용 은 빙산 의 일각 에 불과 하 다고 밖 에 볼 수 없 다 . 그만큼 최종 적 으로 도입 이 끝난 후 얻 게 될 Output Image 는 정확히 그려낼 수 없 고 , 구축 과정 상 의 다양 한 변수 가 존재 하 기 때문 이 다 . 따라서 다음 에 열거 하 는 열 가지 요소 는 이러 한 미래 의 불 확실 성 을 최소 화 하 고 만일 검토 과정 에서 예측 치 못했 던 변수 가 발생 하 더라도 효과 적 으로 극복 해 낼 수 있 는 내성 을 기르 는데 도움 이 되 는 내용 이 다 . * ERP 를 소프트웨어 라고 생각 하 지 말 라 이 말 은 필자 가 조금 극단 적 으로 주장 하 는 말 일 수 도 있 다 . 사실 ERP 도 마지막 결과물 은 소프트웨어 로서 제공 되 기 때문 에 넓 게 보 면 소프트웨어 라고 볼 수 있 다 . 하지만 좀 과장 을 해서 라도 소프트웨어 가 아니 라고 주장 하 는 이유 는 아직 우리 들 이 과거 의 전산 화 에 대한 견해 와 한계 를 완전히 세척 해 내 지 못하 고 있 고 , 그 로 인해 ERP 검토 에 있 어서 많 은 장애물 을 스스로 오밀조밀 쳐 놓 고 있 기 때문 이 다 . 필자 는 이미 앞 에서 ERP 는 정보 기술 이 사람 을 보조 하 는 소극 적 인 개념 이 아니 라 부 가 가치 를 창출 하 는 적극 적 인 개념 으로 해석 했 다 . 결국 , 최종 적 으로 는 정보 기술 ( 즉 , 소프트웨어 ) 로 기업 내 의 모든 조직 및 업무 프로세스 를 재편 한다는 전 제하 에 구축 을 시도 하 는 것 이 라는 의미 이 다 . 이 를 좀 더 자세히 이야기 해 보 자 . 사람 이 일 을 할 때 는 꼭 필요 했 던 일 들 이 ERP 를 도입 하 게 되 면 전혀 필요 없 어 지 는 경우 가 있 다 . 일례 로 경리 부서 의 직원 은 매일 매일 의 회계 전표 를 발행 하 는 것 에 많 은 시간 을 소비 하 게 된다 . 하 지만 ERP 를 도입 하 게 된다면 각 해당 부서 에서 업무 활동 과정 에서 발생 하 게 되 는 모든 회계 처리 사항 들 은 자동 으로 반영 되 어 무 전표 시스템 이 가능 해 지 게 된다 . 과연 경리 직원 이 전산 시스템 이 도입 된 후 에 도 과거 처럼 전표 작성 작업 을 해야 할 필요 가 있 을까 ? 반 대로 사람 이 일 을 할 때 는 불 가능 했 던 일 들 이 ERP 를 도입 하 게 되 면 너무 도 당연 한 것 이 되 어 업무 처리 의 깊이 가 심화 될 수 도 있 다 . ERP 의 핵심 개념 중 의 하나 라고 볼 수 있 는 계획 기능 ( APO : Advanced Planning Optimizer ) 을 보 면 충분히 이해 가 될 수 있 는데 ERP 에서 는 제품 을 생산 도 해 보 기 전 에 미리 예측 하 여 몇 개 를 생산 해 내 야 하 는지 , 그러 기 위해서 는 얼마 만큼 의 생산 자원 이 필요 하 게 되 는지 어떤 생산 라인 에 과부하 가 발생 하 는지 , 이 를 해소 하 기 위해서 는 어떠 한 정책 과 의사 결정 이 가장 효율 적 인지 하 는 등 의 고난도 의 업무 처리 가 가능 하 게 된다 . 이 를 만약 사람 이 수행 하 게 된다면 그 정확 성 은 둘째 치 고 아마도 기업 이 이미 문 을 닫 은 이후 에 나 그 결과 가 나올까 ? 오늘날 처럼 초스피드 가 요구 되 는 경영 환경 에서 는 이러 한 일 들 을 사람 이 일일이 수행 하 는 것 은 답 이 될 수 없 다 . 그 외 에 도 사람 이 일 을 할 때 는 필요 없 었 던 일 들 이 ERP 를 도입 하 니까 새로 생겨나 는 그런 일 도 있 게 된다 . 필자 가 무엇 을 설명 하 기 위해서 이렇게 장황 하 게 예 를 들 었 겠 는가 ? 한마디 로 요약 하 면 과거 에 전산 화 하 듯 우리 업무 에 맞추 어 가 는 소프트웨어 를 도입 한다는 생각 을 버리 고 필요 하 다면 업무 자체 를 혁신 해서라도 최적 의 프로세스 를 만들 어 내 겠 다는 것 이 우선 이 라는 말 이 다 . 더 부연 하 자면 현재 비만 한 몸 에 맞 는 옷 을 골라 보 는 것 이 아니 라 건강 하 고 늘씬 한 몸 에 맞 는 옷 을 보 면서 내 몸 을 어떻게 효과 적 으로 맞출 수 있 도록 다이어트 할 것 인가 가 주 라는 말 이 다 . 이 말 을 다시 뒤집 으면 무엇 일까 ? 바로 ‘ 업무 프로세스 의 혁신 = 경영 혁신 ’ 이 라는 ERP 의 사상 에 충실 하 라는 말 이 된다 . 그렇 다고 교과서 적 인 ERP 개념 에 맞춰 가 자는 이야기 는 아니 니까 다음 을 계속 읽 어 보 자 . * ­ ERP 도입 목적 을 명확히 정립 하 라 사실 우리 나라 에서 ERP 에 대하 여 소개 되 고 있 는 책자 들 은 모두 가 외국 을 기준 으로 하 고 있 다 . 게다가 초기 ERP 를 도입 했 던 대 규모 기업 을 대상 으로 정리 되 었 기 때문 에 우리 나라 중견 , 중소기업 의 실정 에서 는 거리 가 먼 내용 도 많 다 . ERP 시스템 을 공급 하 고 있 다는 벤더 들 도 양극 화 가 되 어 있 다 . 한마디 로 과거 의 Bookkeeping 수준 의 업무 용 소프트웨어 제품 을 시장 조류 에 편승 ( ? ) 하 여 이름표 만 갈 아 치운 제품 들 이 있 는 반면 에 초기 ERP 에 대한 수요 를 독점 하 고 있 었 던 대 규모 기업 의 구축 경험 에 입각 한 거창 한 기준 을 제시 하 는 벤더 도 있 다 . 이 경우 최상 의 목적 을 제시 하 고 있 다는 측면 에서 는 맞 는 말 이 겠 지만 그 기준 대로 ERP 를 이해 하 고 도입 하 려고 할 때 과연 우리 나라 중소 , 중견 기업 의 몇 % 가 수긍 할 수 있 을까 ? 그 취지 와 목적 이 아무리 좋 아도 우리 가 수용 할 수 없 는 수준 이 라면 그림 의 떡 이 아닌가 ? 여기 에서 이론 을 우리 의 실정 에 맞 게 재 해석 하 는 지혜 가 필요 하 게 된다 . 가장 최상 의 수준 은 프로세스 혁신 ( PI : Process Innovation ) 이 다 . 정보 시스템 은 거짓말 을 하 지 못한다 . Input 이 있 으면 정의 되 어 있 는 처리 절차 를 거쳐 Output 을 생산 해 낸다 . 이 말 은 정확 한 자료 가 Input 되 어야 한다는 말 이 기 도 하 다 . 이 는 쓰레기 가 들어가 면 그 결과 도 그 수준 을 벗어나 지 는 못 한다는 말 도 된다 . 따라서 현행 프로세스 의 개선 과 통합 , 선진 모델 의 도입 을 통한 경영 의 혁신 , 사람 이 하 지 못했 던 일 들 을 정보 기술 을 통해 고도 화 함 으로써 기업 경쟁력 의 획기 적 개선 을 원한다면 적어도 쓰레기 가 정보 시스템 으로 흘러 들어가 는 일 은 없 어야 한다 . 또한 마지막 Output 이 기업 이 원 하 는 목적 에 부합 한다면 , 이제 까지 의 비 효율 적 인 업무 프로세스 는 과감히 뜯 어 고쳐져야 한다 . 이럴 때 비 로서 ERP 는 단순히 소프트웨어 라는 차원 을 넘 어 경영 혁신 의 도구 이 자 유일 한 방법 으로서 의 지위 를 획득 하 게 되 며 사람 의 보조 적 수단 이 아니 라 그 자체 가 부가 가치 를 창출 하 는 무기 가 되 는 것 이 다 . 이 말 은 업무 가 고도 로 분업 화 되 어 있 고 프로세스 가 복잡 한 대 기업 의 경우 에 는 백 번 맞 는 말 이 다 . 그 들 에게 는 소프트웨어 그 자체 가 필요 한 것 이 아니 라 혁신 , 통합 된 업무 프로세스 , 그리하여 고객 의 요구 에 신속히 부응 할 수 있 는 전략 체계 가 주 가 되 고 그럴 때 비 로서 ERP 를 도입 한 효과 가 있 게 된다 . 하지만 우리 나라 중소기업 의 경우 를 보 자 . 중소기업 은 업무 가 분화 되 어 있 기 보 다는 집중 되 어 있 는 구조 가 많 다 . 한 사람 이 여러 분야 의 일 을 처리 하 고 있 는 경우 도 다 반사 이 다 . 극단 적 으로 말 해서 우리 나라 중소기업 은 업무 를 더 분업 화 시켜야 지 통합 해야 할 단계 는 아니 다 . 또 한 대 기업 들 처럼 업무 처리 구조 가 복잡 하 지 도 않 은 편 이 다 . 이런 상황 에서 분업 화 된 업무 프로세스 를 통합 하 고 부서 를 통폐합 하 는 프로세스 혁신 이 무슨 의미 가 있 겠 는가 ? 프로세스 와 조직 구조 가 비교 적 단순 하 다면 ERP 패키지 에 반영 되 어 있 는 표준 프로세스 를 기반 으로 관리 체계 의 흐름 을 개선 하 고 업무 흐름 을 자동 화 함 으로써 일 의 주체 인 조직원 들 이 보다 생산 적 인 직무 에 충실 할 수 있 도록 개선 하 는 작업 이 더 중요 하 게 되 는 것 은 너무 도 당연 하 다 . 아직 전산 화 의 경험 도 전혀 없 는 기업 이 라면 장부 기록 및 문서 의 체계 를 정립 하 고 축적 된 데이터 로 분석 과 경영 평가 를 하 는 데 1 차 적 인 목표 를 두 는 것 이 더 현실 적 인 목표 일 수 도 있 다 . 결국 한 번 에 달려가 야 더 효과 적 인지 , 몇 단계 로 나누 어 가 야 적절 한 것 인지 를 도달 하 고자 하 는 최상 의 목표 를 기준 으로 기업 실정 에 맞 게 고려 해 보 아야 한다는 것 이 다 . 세 살 박이 어린 자식 에게 아버지 가 입 는 양복 을 입혀 놓 게 되 면 몇 걸음 못 가 서 옷 에 걸려 넘어져 무릎 팍 깨지 는 수 밖 에 별 도리 가 없 지 않 을까 ? 더구나 프로세스 혁신 을 위한 컨설팅 비용 은 아직 우리 중소기업 에게 는 터무니 없이 비싸 다 . 대 기업 은 비싼 만큼 의 효과 가 있 기 때문 에 이 를 지불 할 용이 가 있 을지 모르 겠 으나 적어도 중소기업 의 업무 프로세스 에 있 어서 는 대가 만큼 의 반대급부 는 없 다고 볼 수 도 있 다 . 물론 모든 중견 , 중소기업 이 그렇 다는 것 은 아니 다 . 개중 에 는 프로세스 혁신 이 필요 할 만큼 이미 업무 규모 가 방대 해 지 고 효율 성 이 저하 되 고 있 으며 , 대대 적 인 수술 이 없이 는 시장 에서 살아남 을 수 없 다는 위기감 을 가지 고 있 는 기업 도 많이 보 았 다 . 요지 는 각 기업 실정 에 맞 는 도입 의 목적 및 도달 하 고자 하 는 목표 가 명확히 설정 되 어야 한다 . 그리고 그 목적 을 달성 할 수 있 는 최적 의 솔루션 을 찾 아야 한다 . 그리고 그 솔루션 은 적어도 앞 에서 설명 한 ERP 의 사상 과 관점 을 모두 수용 한 솔루션 이 어야 하 며 , 최종 목표 를 달성 해 가 기 위한 확장 성 이 보장 되 어 있 어야 한다 . * 경영 층 의 적극 적 참여 가 보장 되 어야 한다 . ERP 도입 의 수준 이 프로세스 혁신 이 든 , 관리 체계 의 개선 이 든지 상관없이 모든 전산 프로젝트 의 성공 을 위해서 는 최고 경영 층 의 관심 과 지원 이 필수 적 이 다 . 조직 구성원 들 에게 는 단기 적 으로 보 면 전산 시스템 의 도입 은 업무 가 늘어나 는 것 이 다 . 적응 하 기 위한 시간 도 필요 하 며 , 익숙 해 져야 하 고 이전 의 일 처리 방식 을 고쳐야 하 는데 이 는 사람 이 변해야 하 는 것 이 기 때문 에 그리 만만 한 것 은 아니 다 . 아무리 시스템 이 좋 아도 안 쓰 면 무슨 소용 이 있 겠 는가 ? 조직 구성원 들 의 저항 을 극복 하 는 최대 의 수단 은 역시 경영 층 이 발벗고 나서 는 것 이 다 . 기업 에서 상사 의 말 을 무시 할 정도 로 용감 ( ? ) 한 사람 은 없 다 . 이해 와 설득 , 교육 으로 해소 되 지 않 는 경우 도 상사 , 그것 도 최고 경영자 의 말 한마디 면 만사 OK 이 다 . 만약 에 프로세스 혁신 차원 에서 ERP 를 도입 한다면 경영 층 의 적극 적 참여 는 필수 불가결 한 요구사항 이 다 . 그 이유 는 이미 잘 알 고 있 으리라 생각 되 므로 더 이상 의 언급 은 않 도록 하 겠 다 . * 패키지 에 대한 편협 한 시각 을 버려라 ERP 도입 과 관련 한 관계자 들 을 만나 보 면 거의 보편 적 으로 물 어 오 는 질문 이 있 다 . ‘ 패키지 는 우리 업무 하 고 는 맞 지 않 는다 . 커 스터 마이 징 은 어디 까지 가능 한가 ? ’ 혹은 ‘ 패키지 가 뭐 이리 비싸 ? ’ 와 같 은 유형 의 반응 이 다 . 심지어 는 요즘 은 거의 없 어 진 것 같 지만 ‘ 도입 하 면 소스 코드 는 제공 해 줄 수 있 는가 ’ 식 의 반응 들 이 다 . 이 는 다 과거 수주 개발 식 의 전산 화 에 길들여져 있 는 선입관 들 때문 이 다 . 이제 는 이런 선입관 들 은 깨끗 하 게 버리 는 것 이 필요 하 다 . 한번 생각 해 보 자 . 과거 에 우리 입맛 에 맞 게 수주 개발 을 해서 그 결과 에 얼마 만큼 만족 했 나 ? 혹시 얼마 못 가 서 업무 가 변하 게 되 어 용도 폐기 하 거나 , 시스템 을 수시로 커 스터 마이 징 해야 하 거나 , 수많 은 개발 인력 을 거느리 고 유지 하 기 위하 여 시간 을 보내 지 않 았 는가 ? 더구나 오랜 기간 동안 개발 하 다 결국 실패 하 게 된 경우 는 없 었 는가 ? 솔직히 말 해 기업 내 의 전산 인력 들 이 개발 전문 업체 수준 의 IT 를 확보 할 수 있 을까 ? 개발 전문 업체 들 은 그 자체 가 직업 이 고 그일 밖 에 할 것 이 없 지만 , 기업 내 의 전산 인력 들 은 개발 도 해야 하 고 , 교육 도 해야 하 고 , 운영 상 의 소소 한 장애 까지 모두 처리 해 주 어야 하 는 등 연구 개발 을 위한 충분 한 시간 과 여유 가 없 다 . 게다가 정보 기술 은 자 고 나 면 변해 있 을 정도 로 그 진화 의 속도 가 빠르 다 . 소스 코드 를 제공 해 주 느냐는 질문 은 자체 적 으로 유지 보수 를 하 겠 다는 의지 인데 , 오늘날 에 는 자체 인력 을 써서 유지 보수 하 느니 공급 업체 와 유지 보수 계약 을 체결 하 는 것 이 더 경제 적 이 다 . 더욱 중요 한 것 은 ERP 는 지금 있 는 그대로 를 전산 화 하 는 소프트웨어 가 아님 을 앞 에서 누누이 강조 했 다 . 업무 처리 목적 에 위배 되 지 않 는다면 패키지 에 반영 되 어 있 는 선진 프로세스 에 맞추 어 가 는 것 이 곧 조직 내 업무 프로세스 의 개선 효과 를 증폭 시켜 준다 . 좋 은 패키지 는 이미 수많 은 기업 의 업무 처리 프로세스 를 분석 하 고 그 결과 에 기초 해서 소프트웨어 로 반영 할 수 있 는 최적 의 Best Practice 를 제공 하 고 있 기 때문 이 다 . 앞 으로 업무 용 소프트웨어 는 그 규모 가 커지 고 복잡 해 질수록 패키지 로 갈 수 밖 에 없 다 . ERP 를 도입 하 고 도 그 에 상응 하 는 효과 를 보 지 못하 는 이유 중 의 하나 가 바로 패키지 에 반영 되 어 있 는 프로세스 를 필요 이상 으로 훼손 하 기 때문 이 라는 사실 도 명심 해야 한다 . 그렇 다고 패키지 가 만능 이 라는 말 은 아니 지만 , 아무튼 현 시점 에서 선택 할 수 있 는 가장 최선 의 대안 임 은 분명 하 다 . * 전산 인력 의 위상 은 변화 되 어야 한다 . 오늘날 에 는 경쟁력 이 확보 되 지 않 으면 도태 될 수 밖 에 없 다 . 위 에서 도 언급 했 지만 소프트웨어 개발 과 관련 해서 도 이 명제 는 유효 하 다 . 현재 전 세계 적 으로 전산 시스템 운영 과 관련 한 Outsourcing 바람 이 거센 이유 가 여기 에 있 다 . 기업 은 본업 에 더 충실 해야 하 고 부수 적 인 영역 의 일 들 은 보다 경쟁력 있 는 전문가 집단 에 일임 하 는 것 이 여러 가지 측면 에서 더 효과 적 이 라는 말 이 다 . 따라서 기업 내 의 전산 조직 의 위상 과 역할 도 이러 한 변화 를 한 번 쯤 고려 해야 된다고 생각 된다 . 이제 기업 의 전산 요원 들 은 일일이 구성원 들 에게 고기 를 잡 아 줄 것 이 아니 라 고기 잡 는 법 을 가르치 는 방향 으로 전환 해야 한다 . 그것 이 이제 까지 그 분야 에서 축적 한 경험 과 기술 , 그리고 잠재력 을 충분히 활용 하 게 되 어 결과 적 으로 조직 에서 없 어서 는 안 되 는 생산 적 인 역할 을 수행 하 게 되 는 것 이 고 기업 의 이익 창출 에 기여 하 게 되 는 길 이 다 . 더구나 ERP 와 같이 방대 한 시스템 들 은 초기 구축 도 중요 하 지만 이 의 효과 적 인 활용 을 위한 다양 한 지원 및 교육 활동 과 향후 의 정보 전략 계획 의 수립 등 이 그 무엇 보다 도 중요 하 다고 볼 때 ERP 를 도입 하 면서 기존 의 전산 조직 을 어떻게 활용 해야 할지 를 신중히 생각 해 보 아야 한다 . * 과거 의 실패 에 연연 해 하 지 말 라 ERP 도입 과 관련 하 여 많 은 사람 들 이 주저 하 는 또 하나 의 요소 는 과거 전산 화 실패 의 경험 이 다 . 앞 에서 도 언급 했 듯이 ERP 시스템 은 그 결과 를 도입 하 는 순간 에 100 % 확신 할 수 는 없 다 . 따라서 미래 의 불 확실 성 에 대한 부분 이 중요 한 결정 을 지연 시키 는 요인 으로 작용 하 기 도 하 는데 이 는 부질없 는 고민 이 다 . 오히려 실패 의 쓰라린 경험 이 ERP 를 도입 하 면서 또 다른 실패 의 가능 성 을 줄여 주 는 순기능 으로서 작용 할 수 있 도록 능동 적 으로 생각 해야 한다 . ‘ 구더기 무서워 장 못 담그 랴 ! ’ ERP 시스템 구축 은 필자 가 생각 할 때 해도 되 고 안 해도 되 는 선택 사항 이 아니 라 꼭 해야 하 는 , 그것 도 빠르 면 빠를수록 이로운 투자 다 . 더구나 앞 에서 설명 해 온 내용 에 동의 한다면 , 과거 전산 시스템 구축 과 는 180 도 다른 시각 과 관점 에서 출발 하 게 되 므로 과거 와 똑같 은 실패 를 되풀이 하 지 않 을까 하 는 걱정 은 접 어도 된다 . ERP 는 과거 전산 화 의 문제점 을 반성 하 는 과정 에서 나온 것 이 기 도 하 다 . 아직 도 실패 에 대한 경험 때문 에 부담감 이 크 다면 아직 과거 의 관점 을 벗어나 지 못한 것 이 아닐까 ? * 내용 도 보 기 전 에 비용 부터 고민 하 지 말 라 눈 에 보이 지 않 는 지식 상품 은 그 가치 를 가격 으로 가늠 해 보 기 가 상당히 힘든 상품 임 에 는 틀림없 다 . 텔레비전 이나 냉장고 를 사 고 팔 듯이 가격 을 정할 수 도 없 는 노릇 이 다 . 소프트웨어 는 , 예 를 들 어 같 은 회계 시스템 이 라고 하 더라도 각각 의 제품 마다 , 또 그 시스템 이 내장 하 고 있 는 기능 에 따라서 그 가격 이 천차만별 이 고 그 폭 도 상당히 크 다 . 적 게 는 몇 만 원대 부터 많 게 는 수천만 원 대 에 이르 기 도 하 고 수억 원 이 될 수 도 있 는 게 소프트웨어 이 다 . 그런데 아직 도 우리 기업 에서 는 소프트웨어 의 가격 을 매길 때 이런 지식 상품 으로서 의 특성 을 전혀 고려 하 지 못하 고 있 는 듯 하 다 . 지식 상품 의 가격 은 그것 이 기업 에 가져 다 줄 수 있 는 효용 가치 에 의하 여 정해진다 . 따라서 그 실체 나 내용 을 검토 해 보 기 전 에 는 몇 만 원 짜리 가 비싼 건지 , 수천만 원 짜리 가 싼 건지 판단 을 할 수 가 없 다 . 회계 시스템 을 수만 원 에 샀 다고 저렴 하 게 도입 했 다고 할 수 있 을까 ? 그 소프트웨어 가 현업 에서 전혀 사용 하 지 못하 고 있 다면 저렴 한 것 이 아니 라 비싸 게 도입 한 것 이 될 것 이 고 , 반 대로 수천만 원 짜리 회계 시스템 을 도입 해서 그 이상 의 효과 를 보 고 있 다면 그것 이 바로 저렴 한 것 이 되 는 것 이 다 . 솔루션 을 검토 해 보 기 도 전 에 가격 이나 예산 에 너무 연연 하 다 보 면 정말 자기 기업 에서 추구 하 는 목적 에 부합 하 는 효과 적 인 솔루션 을 검토 조차 못 해 보 게 될 수 도 있 다 . 만약 예산 은 생각 보다 더 들 더라도 우리 기업 에 가장 적합 하 겠 다는 판단 이 들 고 그 이상 의 효과 가 있 겠 다는 판단 이 든다면 비용 이 좀 더 추가 된다고 해서 손해 보 는 것 은 아니 지 않 는가 ? 오히려 제한 된 예산 에 맞추 어 도입 하 려다가 도입 목표 에 미달 되 고 효과 가 불 충분 하 다면 바로 그것 이 손해 인 것 이 다 . * 사례 는 참조 만 하 라 도입 관계자 들 과 상담 하 다 보 면 많이 듣 는 질문 이 한 가지 더 있 다 . 바로 ‘ 어느 기업 에서 쓰 고 있 나요 . 우리 와 같 은 업계 를 한 군데 소개 해 주 시 죠 ’ 라는 유형 의 질문 이 다 . 물론 많 은 사이트 에서 성공 적 으로 운영 이 되 고 있 는 제품 이 우리 기업 에서 도 성공 할 확률 이 높 다는 것 은 전문 지식 이 없 어도 상식 적 으로 이해 될 수 있 는 말 이 다 . 하지만 여기 에 도 꼭 경계 해야 할 요소 가 없 는 것 은 아니 다 . 가끔 외국 의 정보 통신 관련 잡지 를 보 다 보 면 ERP 와 관련 하 여 대표 적 인 솔루션 제공 업체 의 제품 을 도입 한 기업 들 의 180 도 다른 상반 된 견해 들 이 대비 되 어 기사 화 되 어 있 는 경우 를 볼 수 있 다 . 한쪽 은 거의 찬양 에 가까운 예찬 론 을 펼치 지만 , 그 반대편 에서 는 거의 적대감 에 가까운 비난 을 서슴 지 않 고 있 음 을 볼 수 가 있 는데 , 이 는 무엇 을 말 해 주 고 있 는 것 인가 ? 동일 한 솔루션 도 성공 의 가능 성 과 실패 의 가능 성 을 동시 에 가지 고 있 다는 것 이 다 . 이 는 ERP 구축 의 성공 이 소프트웨어 의 성능 만 으로 판단 되 어 지 는 것 도 아니 고 , 많 은 기업 에서 쓰 고 있 다고 해서 우리 도 성공 할 것 이 란 보장 을 해 줄 수 도 없 다는 것 이 다 . ERP 시스템 구축 의 성패 여부 는 그 책임 이 공 급사 , 도입 사 모두 에게 똑같이 존재 하 며 , 그 구축 과정 에서 있 게 되 는 수많 은 변수 와 이 에 대한 대응 및 처리 능력 에 따라 다양 한 성패 의 인자 들 이 산재 되 어 있 는 아주 복잡 하 고 섬세 한 공정 이 다 . 우리 가 자동차 를 살 때 는 그 모델 을 직접 사용 하 고 있 는 주변 사람 들 의 평가 가 비교 적 정확도 를 가지 고 있 게 되 고 , 본인 이 평가 해도 그 결과 가 크 게 달라지 지 는 않 는다 . 하 지만 ERP 와 같 은 섬세 한 지식 상품 은 전혀 그렇 지 않 다 . 똑같 은 솔루션 을 가지 고 어떤 기업 은 성공 하 기 도 하 고 또 다른 기업 은 실패 하 기 도 하 는 것 이 다 . ERP 도입 관계자 들 이 소위 ‘ 레퍼런스 사이트 ’ 에 관심 을 집중 하 게 되 는 또 다른 요인 은 도대체 이 솔루션 이 우리 기업 에 도입 되 어 과연 성공 할 수 있 을 것 이 지 , 아니면 실패 할 것 인지 예측 하 거나 평가 해 보 는 것 이 힘들 기 때문 이 다 . 내 가 확신 을 할 수 가 없 고 도입 하 기 전 에 평가 를 해 보 기 가 어렵 기 때문 에 사실 은 허점 이 더 많 은 구태의연 한 방식 으로 시스템 평가 를 해 보 고 싶 은 것 이 다 . 가장 좋 은 방법 은 스스로 가 평가 할 수 있 는 안목 을 가져야 하 며 한 번 선택 하 면 성공 을 위해 모든 노력 을 경주 하 는 자세 를 견지 하 는 것 이 다 . 그 정도 의 분별력 이 없 다면 이후 도입 과정 에 있 어서 도출 되 게 되 는 여러 가지 난관 들 을 자력 으로 돌파 할 힘 도 자연히 약할 수 밖에 없 고 따라서 그만큼 실패 할 가능 성 만 커지 게 된다 . 만약 다른 기업 의 사례 를 보 게 되 더라도 완성 물 을 보 기 보다 는 그 완성 물 을 얻 기 까지 그 들 이 어떠 한 시행착오 와 좌절 들 을 겪 어 왔 는지 에 더 주목 하 라 . 그 들 이 누리 는 성공 의 열매 는 도입 과정 에서 맺 어 진 결실 이 지 어느 날 갑자기 하늘 에서 뚝 떨어진 것 이 아니 기 때문 이 다 . 똑같 은 씨 를 뿌려도 그 수확량 은 다 제각각 임 을 명심 하 자 . 대부분 사이트 도입 사례 를 보 러 가 게 되 면 피상 적 으로 그 들 이 설명 해 주 는 데 로 만 듣 고 온다 . 그러 다 보 니 그렇게 몇 개 업체 보 고 나 면 그 다음 은 뭐 가 뭔지 헷갈리 기 시작 한다 . 그래서 각각 의 솔루션 에 대하 여 좀 더 분별력 이 생기 기 보 다는 사례 방문 을 하 기 전 보다 더 애매 모호 해진다는 말 을 많이 듣 는다 . 타 기업 의 구축 사례 를 우리 조직 의 관점 에서 비교 , 분석 해 보 기 위해서 라도 치밀 한 준비 가 필요 하 다 . * 숲 을 보 아야지 나무 만 쳐다보 지 말 라 ERP 시스템 의 특징 중 의 하나 가 프로세스 의 횡 적 통합 이 라고 한다 . 이 는 과거 의 전산 시스템 이 단위 업무 별 로 내포 되 어 있 는 기능 중심 으로 만들 어 진 업무 단위 ( 혹은 태 스 크 단위 ) 의 수직 적 인 시스템 인 반면 에 ERP 는 이 를 단위 업무 중심 으로 보 는 것 이 아니 라 프로세스 의 흐름 으로 이해 하 고 구성 되 어 있 다는 말 이 다 . 과거 에 는 소프트웨어 를 개발 할 때 각 부서 별 의 시스템 을 만들 기 때문 에 다양 한 부서 와 복수 개 의 업무 들 과 의 횡 적 통합 을 고려 한다는 것 이 불 가능 했 기 때문 에 개별 단위 업무 시스템 이 될 수 밖에 없 었 으며 , 각 모듈 간 의 통합성 도 미약 했 지만 ERP 시스템 은 그 기본 사상 이 하나 의 행위 가 흘러가 면서 서로 연계 통합 되 는 전체 업무 의 영역 을 하나 의 프로세스 라 규정 하 고 이 의 최적화 를 추구 하 기 때문 에 모든 시스템 의 기능 이 독립 적 으로 분산 되 어 있 는 것 이 아니 라 횡 적 으로 강한 통합 을 이루 고 있 다 . 이렇게 ERP 시스템 은 각각 의 의미 없 는 개별 기능 의 나열 을 잡아내 는 시스템 이 아니 라 이 를 상호 간 에 통합 하 고 재 배치 하 는 특성 을 띠 기 때문 에 개별 기능 을 비교 검토 하 는 것 은 별 의미 가 없 게 되 며 , 이러 한 개별 기능 이 통합 되 어 나타나 는 프로세스 의 최적 화 여부 가 중요 한 요인 이 된다 . 그러나 아직 까지 도 이러 한 개념 과 설계 사상 에 익숙 하 지 못한 검토 자 들 은 각각 의 기능 이 어떠 한지 에 초점 을 맞추 어 시스템 을 분석 하 는 경향 이 강한 것 이 사실 이 다 . ERP 시스템 에서 각각 의 개별 기능 은 아무 의미 가 없 다 . 이 는 분업 화 된 기업 조직 에서 각각 의 단위 업무 가 전체 적 으로 연결 되 지 않 는다면 그 자체 로 는 아무런 의미 가 없 다는 것 과 동일 한 관점 이 다 . 이렇게 과거 의 관점 그대로 , 숲 을 보 기 보 다는 나무 에 집착 하 는 검토 방식 은 ERP 를 검토 하 는 것 이 아니 라 과거 와 유사 한 좀 더 기능 이 개선 된 소프트웨어 를 검토 하 는 것 과 다를 게 없 게 된다 . ERP 를 도입 하 면서 필요 하 다면 업무 까지 도 뜯어고치 겠 다는 결심 이 필수 적 인 요소 라고 볼 때 , 이러 한 방식 으로 는 최적 의 솔루션 을 판단 해 보 려고 할 때 옥석 을 가리 기 는 요원 해진다 . 전체 업무 처리 의 관점 에서 볼 때 지장 을 초래 하 지 않 는 개별 나무 들 이 라면 소프트웨어 를 뜯 어 고치 려 하 지 말 고 업무 를 시스템 에 맞추 는 것 이 훨씬 경제 적 이 며 효과 도 크 게 됨 을 이해 해야 한다 . * 확실 한 솔루션 과 풍부 한 경험 있 는 파트너 의 선택 이 중요 하 다 . 오늘날 ERP 시스템 은 과거 와 같이 개발 전문가 들 이 만들 수 가 없 다 . 그 들 은 전산 전문가 이 지 업무 전문가 는 아니 기 때문 에 기업 현장 의 업무 프로세스 를 이해 하 고 이 를 최적 화 하 는 대안 을 줄 능력 은 없 기 때문 이 다 . 뿐 만 아니 라 ERP 시스템 은 과거 의 업무 시스템 과 비교 한다면 그 깊이 와 방대 함 과 섬세 함 에 있 어서 비교 할 수 조차 없 다 . 따라서 단순히 소프트웨어 코딩 능력 만 가지 고 는 ERP 와 같 은 방대 한 솔루션 을 만들 수 는 없 다 . 나아가 ERP 시스템 에 있 어서 파트너 쉽 은 대단히 중요 하 다고 말 할 수 있 다 . 기업 의 업무 프로세스 는 고정 되 어 있 는 것 이 아니 라 항상 진화 하 게 된다 . 이 에 따라 기 구축 된 ERP 시스템 도 그러 한 진화 에 발 맞추 어 지속 적 으로 개선 되 어 나가 야 한다 . 도입 하 고 1 , 2 년 후 다른 시스템 으로 또 교체 할 생각 이 라면 모르 겠 지만 기업 경영 의 전략 적 수단 으로서 ERP 를 구축 했 다면 장기 적 안목 에서 파트너 의 선택 이 솔루션 의 선택 만큼 이나 중요 한 성공 요인 이 된다 . 또한 파트너 가 보유 한 경험 과 기술 , 업무 노하우 가 풍부 하 여 ERP 구축 과 운영 과정 에서 많 은 도움 과 아이디어 를 원활 하 게 공급 받 을 수 있 다면 성공 의 가능 성 은 그만큼 높 아 지 게 된다 . [ 출처 ] http : / / www . seri . org / APS - 생산 스케줄링 연구회 / 자료실 내용 출처 : 공유 하 기 글 요소 비 영리 동일 조건