□ 사전준비란 ERP를 통해 겪게 될 변화를 대비하는 단계
□ ERP패키지의 결정이나, 앞으로 발생하게 될 비용, 조직이 겪을 변화와 혼란이 무엇인지를 파악
(2) 2단계 - ERP 패키지의 선택
□ ERP의 도입에 앞서 어쩌면 가장 중요한 것은 ERP 패키지를 어떻게 선정할 것인가 하는 문제
- ERP는 기업의 기간시스템(Backbone System)이므로 잘못 선정하면 두고두고 문제가 되기 때문
□ 우선 ERP 패키지를 선정할 때에는 일반적으로 기능성과 통합성을 고려
- 기능성은 패키지가 제공하는 기능이 회사의 요구 사항을 만족시키는 수준을,
- 통합성은 패키지가 회사에서 운용하고 있는 다른 시스템과 데이터를 주고받으면서 유연하게 사용될 수 있는 수준을 의미
□ 이때 기능성을 우선시해서 각 모듈별로 기능성 측면에서 가장 적합한 패키지들을 선택하고 이들을 연계해서 사용하는 전략을 Best of breed 전략이라고 함
- 예를 들면, 재무시스템은 A사의 제품을, 조달시스템은 B사의 제품을, 그리고 인사시스템은 C사의 제품을 구축하여 연계하는 것
- 이 전략은 기능성의 측면에서 우수
□ 반면에 통합성을 중시해서 일부 분야에서는 기능이 부족하더라도 가능하면 하나의 패키지를 이용하는 것을 토털 패키지 전략이라고 함
□ 그렇다면 Best of breed 전략과 토털 패키지 전략 중에서 어떤 것을 선택할 것인가가 문제인데, 우선 정답은 상황에 따라서 달리 분석해야 한다는 것임
□ ERP를 처음 도입할 때에는 일반적으로 한 패키지만을 선택하기 때문에 문제가 되지 않는 것이 보통
□ 문제가 되는 것은 이미 ERP의 일부 모듈이 운영되고 있는 상태에서 다른 모듈을 추가하거나CRM, SCM, SEM, DW 등과 같은 확장형(Extended) ERP를 도입하는 경우
□ 이미 ERP의 일부 모듈을 운영하면서 추가로 모듈을 선택해야 할 경우에는 기능성보다는 통합성을 고려하여 기존의 패키지와 동일한 패키지를 선정하는 것이 바람직
- 그 이유는 ERP 시스템의 모듈간에는 주고받는 데이터의 양도 많지만 주고받는 방식도 매우 복잡해서 서로 다른 패키지를 EAI나 다른 프로그램을 통해 연계시키는 것이 매우 어려우며, 또한 ERP 모듈의 기능에 있어서도 패키지별로 차이가 별로 크지 않기 때문
□ 그러면 ERP를 운영하고 있는 회사에서 CRM, SCM, SEM, DW 등과 같은 확장형 ERP를 도입할 경우에는 어떤 전략을 적용해야 할지 생각해 볼 문제
□ ERP의 핵심기능에서는 우수하다고 인정받는 ERP패키지도 CRM이나 SCM 또는 SEM에 있어서는 아직 제대로 된 기능을 제공하지 못하는 경우가 존재
- 이런 점을 고려하면 기능성이 매우 중요하다고 할 수 있음
□ CRM을 예로 들면, CRM의 현업 사용부서라고 할 수 있는 마케팅이나 영업부서가 CRM 프로젝트를 추진할 때에는 일반적으로 CRM 패키지가 제공하는 기능에 초점을 맞추어 패키지를 선정
- 통합성에 대해서는 대부분의 패키지사들이 문제가 없다고 주장하고 있고, 또 문제가 있어도 전산실이나 컨설턴트들이 해결할 수 있을 것으로 생각하곤 함
- 하지만 통합이라는 것은 해결하기 쉽지만은 않은 문제
- CRM과 ERP를 한 패키지사에서 Bundle로 만들어진 토털 패키지를 사용하지 않고 각기 다른 회사의 제품을 사용하는 것은 통합적으로 시스템을 구축할 때뿐만 아니라 새로운 버전으로 업그레이드할 때에도 많은 어려움이 존재
□ 물론 분야별로 또는 모듈별로 최고의 기능을 갖춘 패키지만을 선택하여 회사 전체 시스템을 구축하려는 전략인 Best of breed 전략은 한때 대기업들이 주로 선호
- 하지만 이들 기업은 시스템 통합에 많은 어려움을 겪음
□ 요즘은 통합성을 보다 중시하는, 그러니까 가능하면 기능성이 좀 떨어지더라도 회사의 기간시스템과 동일한 패키지 또는 가장 통합성이 높은 third?party 패키지로 회사 전체 시스템을 구축하는 경향이 증가
(3) 3단계 - 도입순서의 결정
□ ERP는 BPR을 위한 도구라는 말처럼, ERP 도입에는 업무 프로세스를 개선하는 것이 중요한 목적이 되고 있는 것이 사실
□ 따라서 ERP 프로젝트에는 반드시 BPR 작업을 수행하게 되는데 이 BPR 작업을 ‘ERP 프로젝트를 시작하기 전에 수행할 것인가, 아니면 ERP 프로젝트 과정에서 수행할 것인가’가 이슈가 되고 있음
□ 그렇다면 기업들은 어떻게 우선순위를 결정할 것인가가 문제인데, 그것은 다음의 각각에 대한 설명을 토대로 기업에서 판단해야 할 문제
첫째, BPR을 먼저 수행하는 경우, ERP와는 관계없이 먼저 회사 업무 프로세스 전반에 걸쳐 문제점을 파악하고 개선방향을 도출하여 TO?BE 프로세스를 설계
- 이런 작업은 앞으로 추진할 ERP 도입의 타당성을 검토하는 역할을 겸하게 됨
둘째, BPR을 ERP 구축과정에서 수행하는 경우는, ERP가 제공하는 기능 중에서 필요한 기능을 선택하기 위한 목적으로 업무 프로세스의 TO?BE 모습을 설계
- 이런 경우의 BPR 작업은 일반적으로, 선정된 ERP 패키지를 기반으로 수행되기 때문에 신속하게 수행할 수 있다는 큰 장점을 지님
□ 그밖에도 BPR을 ERP 구축 과정에서 동시에 수행할 것을 주장하는 사람들은 그 이유를 다음과 같이 설명하고 있음
- 먼저 ERP 프로젝트 이전에 BPR을 수행해서 그에 따라 ERP 프로젝트의 타당성을 검토한다고 하지만 실제로는 대부분의 경우 ERP 프로젝트는 경영자의 전략적인 결정에 의해 추진
. BPR을 통해 ERP 프로젝트의 타당성을 검토한 기업들이 ERP 프로젝트를 추진하지
않기로 결정한 경우는 극히 드묾
- 그리고 ERP와 관계없이 BPR을 수행할 경우에는 일반적으로 설계한 TO?BE 모습이 ERP와 갭이 매우 크기 때문에 ERP로 제대로 구현되기가 어려움
. TO-BE 모습이 ERP로 제대로 구현되기 위해서는 BPR 작업이 ERP 프로젝트 과정에서
ERP를 기반으로 수행되는 것이 바람직
- 마지막으로, BPR을 수행한 다음, 그에 따라 ERP를 도입할지 여부를 검토하고, 그 다음에 ERP 프로젝트를 진행하게 되면 결국 6개월에서 1년 정도의 기간이 지연될 가능성이 있음
□ 하지만 ERP 프로젝트와 BPR을 함께 수행하면 프로젝트가 보다 복잡해지며, TO?BE 모습이ERP가 제공하는 기능 범위 내로 제한될 가능성이 크다는 문제를 내포
□ 어떤 선택을 할 것인지는 각각의 기업 상황에 따라 상대적
□ 그것을 선택해야 하는 기업을 위해 다음의 몇 가지 예를 들어 각 수행 방법에 어울리는 기업의 상황을 설명해보도록 함
□ 우선 BPR을 ERP 프로젝트 전에 수행하는 것이 바람직한 경우는 다음과 같음
- 첫째, 기존 시스템이 잘 활용되고 있고 앞으로도 기존 시스템의 일부는 계속 유지될 예정이어서 ERP 모듈 중에서 일부 모듈만 필요한 경우
. 따라서 도입할 모듈의 범위를 사전에 판단할 필요가 있는 경우
- 둘째, 기업의 경영환경과 업무 프로세스가 매우 특이해서 ERP 패키지가 제공하는 기능이 기본적으로 기업이 원하는 것과 갭이 큰 경우
. 따라서 부족한 기능을 보완하기 위해 ERP 프로젝트 과정에 많은 프로그램 작업이 필요한 경우
- 셋째, 은행이나 통신회사와 같이 프로세스나 시스템의 안정적인 운영이 필수적이고, ERP도입에 대해서 신중한 접근이 필요한 경우
□ 반면에 다음과 같은 경우에는 BPR을 ERP 프로젝트와 동시에 수행하는 것이 바람직
- 첫째, 시스템을 신속히 가동하는 것이 매우 중요한 경우
- 둘째, 회사의 업무가 특이하지 않아서 회사 업무를 패키지에 맞추는 것이 유리한 경우
- 셋째, 회사의 규모가 크지 않아서 ERP 도입에 많은 비용을 투자하는 것이 부담스러운 경우
(4) 4단계-내 몸에 맞는 패키지사와 컨설팅사의 선택
□ ERP프로젝트에서 가장 중요한 것은 패키지와 컨설팅사의 선정이라고 할 수 있음
- 패키지가 기업의 업무와 맞지 않거나 컨설턴트의 경험과 능력이 충분하지 못할 경우 프로젝트가 실패할 가능성이 크기 때문
- 따라서 패키지와 컨설팅사의 선정에 공을 많이 들일수록 프로젝트의 성공 가능성은 커지며, 그 기간도 단축 가능
□ 최상의 패키지와 컨설팅 업체를 선정하기 위해서는 여러 업체들을 면밀하게 비교 분석하고 이미 ERP를 도입한 업체들을 벤치마킹 하는 것도 좋은 방법
- 이 과정에서 ERP구축에서 나타날 문제점들을 미리 파악하고 그 해결방안을 마련
□ 어떤 방식으로 패키지와 컨설팅사를 선정할 것인지는 참으로 어려운 문제
- ERP를 도입하려는 기업들은 일반적으로 ERP패키지를 잘 모르고 ERP프로젝트에 대한 경험이 없어서 자신들에게 어떤 패키지가 가장 적합하며, 그 패키지를 구축하는 프로젝트에 어떤 경험과 지식이 필요한지 사전에 알기 어렵기 때문
□ 이런 상황에서 기업이 택할 수 있는 방법은 크게 세 가지로 구분
- 첫째, 컨설팅사를 먼저 선정해서 컨설팅사의 자문을 받아서 패키지를 선정
- 둘째, 패키지를 먼저 선정하고 패키지에 가장 적합한 컨설팅사를 선정
- 셋째, 패키지와 컨설팅사에게 컨소시엄을 형성하게 하여 컨소시엄 중에서 하나를 선정
□ 패키지를 선정한 후, 컨설팅사를 선정하는 방법을 선택할 경우에 중요한 것은 선정된 패키지에 대한 경험과 지식을 가장 많이 갖고 있는 컨설팅사를 선정하는 것
- 이 방법의 장점은 기업이 패키지 선정에 집중할 수 있으며, 패키지 선정 후에는 패키지사의 도움을 받아서 컨설팅사를 선정할 수 있다는 것
- 통상 패키지사들은 자신들이 공급하는 패키지에 대한 컨설팅사들의 경험과 지식수준을 가장 잘 알고 있기 때문에 컨설팅사의 선정에 많은 도움을 받을 수 있음
□ 하지만 문제점이 없는 것은 아닌데, 가장 중요한 문제는 패키지를 선정함에 있어서 컨설팅사의 도움을 받지 못한다는 점
- 패키지를 선정하기 위해서는 패키지사들이 제출한 제안서를 분석하고 해당 패키지를 이미 도입해서 사용하고 있는 회사들에 대한 벤치마킹을 수행해서 그 결과를 종합적으로 분석해야 함
- 이것은 ERP 프로젝트 경험이 없는 회사로서는 매우 부담스러운 작업
□ 그래서 일부 회사는 패키지 선정만을 위한 컨설팅을 받기도 함
- 이런 경우에는 패키지 선정에 참여한 컨설팅사는 구축 프로젝트에는 제외시키는 것이 바람직
- 패키지 선정에 참여한 컨설팅사가 본 프로젝트에도 참여할 수 있다면 아무래도 자신들에게 유리한 패키지를 선정하도록 유도할 가능성이 크기 때문
□ 패키지 선정작업에 외부 컨설턴트들을 참여시킬 경우에는 이왕이면 컨설턴트와 함께 ERP프로젝트의 비전 및 목표를 설정하고 간단하더라도 TO?BE 설계작업을 하는 것이 바람직
□ 패키지와 컨설팅사를 동시에 선정하는 방법은 패키지사들과 컨설팅사들에게 컨소시엄을 만들게 해서 두 회사가 마치 한 회사처럼 함께 제안서를 작성하여 제출하도록 하는 것을 의미
- 이 방식의 장점은 패키지와 컨설팅사의 선정 작업을 단순화할 수 있다는 점
□ 이 방식은 컨소시엄의 주도권에 따라 다음과 같은 두 가지 접근 방법이 존재
- 첫째, 패키지사로 하여금 주도권을 갖고 컨설팅사를 선정하도록 하는 방법
- 둘째, 컨설팅사로 하여금 주도권을 갖고 패키지사를 선정하도록 하는 방법
□ 먼저 패키지사가 컨설팅사를 선정해서 제안하는 방법은 패키지사가 주도적으로 컨설팅사를 선정해서 패키지가격, 컨설팅비용, Hardware 사양 등 모든 내용을 일괄적으로 제안하는 것을 의미
- 따라서 제안에 참여하는 패키지사의 수만큼 제안서가 제출될 수 있음
- 이 방법은 선정절차가 단순하다는 장점이 있지만, 컨설팅사의 선정이 패키지사에 의해 좌우되기 때문에 패키지사가 가격 기준만으로 컨설팅사를 선정할 경우 우수한 컨설팅사가 배제될 수 있다는 문제점이 존재
□ 두 번째로, 컨설팅사가 패키지사를 선정해서 제안하는 방법은 컨설팅사가 주도적으로 패키지사를 선정해서 패키지가격, 컨설팅비용, Hardware 사양 등 모든 내용을 일괄적으로 제안하는 것을 의미
- 제안에 참여하는 컨설팅사 수만큼 제안서가 제출
- 이 방법도 선정절차가 단순하다는 장점이 있지만, 패키지의 선정이 컨설팅사에 의해 좌우되기 때문에 회사에 가장 적합한 패키지보다는 컨설팅사가 선호하는 패키지가 선정될 가능성이 커진다는 문제점이 있으므로 신중해야 함
(5) 5단계 - 계약서의 작성
□ 패키지와 컨설팅사가 선정되면 이들 회사와 계약을 체결
□ 계약은 프로젝트와 관련된 기본적인 권리와 의무 및 책임에 대하여 프로젝트에 참여하는 회사들간의 합의내용을 기술한 것
□ 여기서 패키지 공급에 관한 계약은 일반적으로 큰 문제가 없음
- 패키지는 소프트웨어 제품이어서 일반적인 소프트웨어 공급 계약 방식을 그대로 활용할 수 있기 때문
□ 하지만 컨설팅은 눈에 보이지 않는 서비스여서 계약 내용이 회사별로 상황에 따라 달라질 수 있기 때문에 매우 복잡해 질 수밖에 없는 실정
□ 따라서 컨설팅 계약은 일반적으로 컨설팅사가 자체적으로 만들어 놓은 표준계약서를 사용
□ 이런 표준계약서는 컨설팅사에게 유리하도록 만들어진 경우가 많기 때문에 회사에서는 각별한 주의가 필요
□ 컨설팅사가 준비한 표준계약서를 그대로 이용할 때에는 여러 가지 문제가 있을 수 있는데, 일반적으로 발견할 수 있는 가장 큰 문제는 프로젝트 실패의 책임 문제를 비켜가고 있다는 점
□ 그러면 컨설팅사가 준비한 표준계약서를 이용해서 계약을 할 때 어떤 점에 주의해야 하는지 알아보도록 하는데, 먼저 표준계약서에 일반적으로 포함되는 내용은 어래와 같음
- 첫째, 컨설팅 서비스 수수료 및 경비 지급과 관련된 제반 내용
- 둘째, 결과물에 대한 승인과 같은 고객의 책임에 대한 내용
- 셋째, 결과물에 대한 권리
- 넷째, 컨설팅 Tool에 대한 권리
- 다섯째, 기밀유지 의무
- 여섯째, 컨설팅 서비스에 대한 품질보증
- 일곱째, 컨설팅과 관련하여 제3자로부터 손해배상 청구에 대한 컨설팅사가 부담하는 책임의 한계
- 여덟째, 컨설턴트의 교체에 대한 내용
- 아홉째, 계약의 해지 등
□ 컨설팅사의 표준계약서는 컨설팅 계약의 일반적인 내용만 기술하고 있기 때문에 회사의 상황을 반영한 구체적인 내용은 부록에서 별도로 기술하는 것이 바람직
□ 또한 계약서에 별도의 조항이 없을 경우에는 컨설팅사가 제출한 제안서를 계약 내용으로 포함한다는 것을 명확히 하는 것이 바람직
- 컨설팅사들은 계약을 따내기 위해 제안서에 고객 회사에게 유리한 내용들을 많이 포함시키고 있기 때문
- 만약 제안서에 일부 중요한 내용이 빠져있다면 계약하기 전에 그러한 내용이 포함된 수정 제안서를 제출 받아야 할 것
- 명심해야 할 것은 컨설팅사들은 일반적으로 제안서 제출 단계에서는 회사가 요구하는 것을 모두 들어주지만, 일단 선정되고 나서 계약 단계에 접어들면 일반적인 관행이 아니라는 이유로 회사의 요구를 가능한 한 거절하려고 한다는 것
□ 다음으로 패키지 및 컨설팅 가격의 계약은 가장 중요한 부분
□ 일반적으로 패키지 가격에 대해서는 큰 문제가 없으나 컨설팅 가격에 대해서는 많은 논란이 있기 마련
- 눈에 보이지 않는 서비스에 대한 가격은 시비 거리가 되기 쉽기 때문
□ 일단 패키지의 구입 가격은 가능한 한 저렴하게 구입하는 것이 바람직
- 일반적으로 시스템 가동 후에도 유지보수 비용을 매년 지불해야 하는데, 이 유지보수비용이 구입가격의 일정 비율로 정해지기 때문
- 따라서 최초 구입가격이 비싸면 자연적으로 유지보수비용도 높아지는 것이 사실
- 패키지 구입가격은 사용자 1인당 가격으로 정해져서 총 구입가격은 사용자 1인당 가격에 총 사용자 수를 곱해서 결정
- 따라서 패키지 구입가격을 낮추기 위해서는 사용자 1인당 가격을 낮추거나 사용자 수를 작게 하는 방법이 존재
- 물론 사용자 1인당 가격을 낮추는 것이 유리
. 사용자 수는 시스템을 구축하고 사용하는 과정에서 얼마든지 달라질 수 있기 때문
□ 컨설팅 비용은 프로젝트에서 가장 비중이 커서 일반적으로 총 프로젝트 비용의 20～60%를 차지
□ 따라서 컨설팅 비용을 가능한 한 많이 낮추는 것이 프로젝트 계약에서 매우 중요
- 컨설팅 비용은 고무줄과 같아서 대부분의 컨설팅사는 프로젝트 가격을 할인해 줌
□ 컨설팅 금액의 계약에는 요구사항의 변경에 따른 가격 변경에 대해 명확히 하는 것이 중요
- 일부 컨설팅 회사들은 저가로 계약한 뒤에 고객회사가 요구사항의 변경을 요청할 때 과도한 금액을 청구
- 컨설팅 회사의 다른 고객들을 조사해서 그들의 요구사항 변경이 어떻게 진행되었는지를 살펴보는 것도 바람직
- 사소한 모든 변경 사항에 돈을 요구했는지, 아니면 커다란 변경에만 돈을 요구했는지를 확인해 볼 필요가 있음
□ 패키지의 구입 범위 계약 또한 중요
□ 기업은 현재 시점에서 필요한 모듈만 구입할 것인지 아니면 장래를 고려하여 전체 패키지를 구입할 것인지를 고민해야 함
□ 전체 패키지라고 하면 패키지사에서 공급하는 모든 모듈을 Bundle화해서 제공되는 것을 의미
- 즉 회계, 생산, 판매, 구매, 인사 등의 기간 시스템뿐만 아니라, DW, CRM, SCM, SEM 등을 포함한 전 시스템을 의미
. 예를 들면, SAP사는 자신들이 공급하는 모든 모듈을 mySAP.com이라는 이름으로 공급
. 이 제품을 구매한 회사들은 SAP사가 제공하는 거의 모든 모듈을 사용 가능
□ 패키지사와의 계약에서 계약 금액을 최소화하기 위해서는 계약 시점에 필요한 모듈만을 계약해야 하지만 ERP를 도입한 대부분의 회사들이 ERP 시스템을 사용하면서 추가적으로 새로운 모듈을 구입하고 있는 것이 현실
□ 이런 점을 고려하면 ERP를 처음 도입할 때 필요한 모듈만 계약할 것이 아니라 전체 패키지를 구입하는 것이 바람직하다고 할 수 있음
- 패키지사들은 ERP를 처음 도입하는 기업들과의 계약 시에는 대폭적인 가격 할인을 제공하지만, 일단 자사 ERP를 도입한 기업들이 추가적으로 도입하는 모듈에 대해서는 가격 할인을 별로 해주지 않음
- 어차피 추가도입에는 자신들의 모듈이 선택될 가능성이 크기 때문
□ 하지만 Best of breed전략을 추구하는 기업의 경우에는 당연히 필요한 모듈만을 계약
□ 마지막으로 지불유예항목에 대한 점검도 필요
□ 일반적으로 프로젝트에서 정해진 모든 작업이 종료되고 해당 작업에 대한 결과물이 제출되면 사전에 정해진 계약 금액을 컨설팅사에게 지불해야 함
□ 하지만 단순히 결과물이 제출되었다고 해서 계약 금액을 지불하는 것이 아니라 기업이 그 결과물에 대해서 적정하다고 인정해야 계약 금액을 지불
□ 만약 기업이 적정하다고 인정하지 않으면 지불을 유예할 수 있도록 하는 것이 바람직
- 일반적으로 지불 유예의 범위는 계약금액의 10～50% 정도
□ 이와 같은 지불 유예는 컨설팅사의 관심을 촉구하기 위한 것
- 만약 프로젝트의 각 단계에서 제출되는 결과물들이 만족할 만한 수준이 아닐 경우에는 상당한 돈이 프로젝트의 마지막 단계까지 지불 보류되면서 축적
□ 계약 시 대비해야 하는 것은 계약의 파기에 대한 것
□ 시스템이 예정대로 가동되지 못했거나 프로젝트의 결과물이 기대 수준에 못 미칠 경우에 프로젝트는 실패했다고 할 수 있는데, 이런 경우에 계약 위반을 선언하고 금전적인 보상을 확보할 수 있는 탄탄한 계약서를 갖는 것이 매우 중요
□ 대부분의 경우 이런 권한을 사용하는 것은 해당 컨설팅사뿐만 아니라 회사도 손해를 볼 가능성이 있음
□ 하지만 중요한 것은 이런 권한을 회사측이 갖고 있는 것이 컨설팅사로 하여금 최선을 다해 프로젝트가 성공하도록 노력하게 한다는 것
□ 프로젝트가 제대로 진행되지 않을 때 계약을 파기하거나 지불을 유예할 수 있도록 하는 조항보다 더 바람직한 것은 패키지사나 컨설팅사가 프로젝트 성공을 위해 최선을 다해 노력하지 않으면 안되도록 계약하는 것
□ 이와 관련한 대표적인 예로는 시스코사의 경우를 들 수 있음
- 시스코사는 하드웨어 사이징 작업이 정확하지 않을 것을 우려하여 하드웨어 공급사와 하드웨어 용량에 대해 계약하지 않고 원하는 성능에 대해 계약
- 테스트 결과 시스템 성능이 기대했던 수준에 도달하지 않았고, 이에 하드웨어 공급사는 계약에 따라 하드웨어를 추가적인 비용 청구 없이 신속하게 증설해주었음