글로벌 지능형 엔터프라이즈
상태바
글로벌 지능형 엔터프라이즈
  • Intelligent Enterprise
  • 승인 2002.07.29 00:00
  • 댓글 0
이 기사를 공유합니다

세계화는 현재 업계의 주요 유행어가 되었다. 하루가 멀다 하고 세계 곳곳에서 새로운 IT 프로젝트들이 시작되고 있고, IT의 진보는 그러한 프로젝트들의 세계화를 더욱 용이하게 해주고 있다. 그런 프로젝트들을 실시하는 이유는 대개 대기업의 여러 로케이션(또는 티어)들이나 여러 비즈니스 유닛들이 지리적으로 흩어져서 서로 다른 비즈니스 활동에 참여하고 있을 때 그 로케이션들이나 비즈니스 유닛들 전반에 걸쳐서 공통된 솔루션을 구현하는데 있다.

이런 프로젝트들은, 그것이 ERP든, CRM이든, BI든, 또는 레거시 통합 시스템이든, 하나의 패키지로부터 비롯될 수도 있고 기업 내부에서 생겨날 수도 있다. 여하튼 다계층 글로벌 전략 비즈니스 시스템을 구현하는 일은 단독형(스탠드얼론) 시스템을 실행하는 것과는 전혀 다르다.

이 글에서는 그런 다계층 구현과 관련해 문제가 될 수 있는 몇몇 분야를 살펴보고, 그런 문제들을 극복하는 방법에 대한 얘기하고자 한다.

모든 다층적 구현 프로젝트의 최대 쟁점은 최종 결정권을 누가 갖느냐 하는 것이다. 예를 들어, HR(인적자원부) 시스템을 구현할 때 한 사이트에서는 직원들의 업무수행 능력을 매월 평가해서 1년에 한 번 보너스 계산에 활용하기로 결정할 수 있는 반면, 다른 사이트에서는 6개월마다 한 번씩 실시할 수도 있다. 업무 프로세스에 광범위한 영향을 미치는 그런 결정권한을 두 사이트 모두에 허용할 경우, 공통된 솔루션이 아닌 제 각각의 솔루션들이 만들어질 것이다.

프로젝트 제어권

향후 프로젝트 제어권을 둘러싼 갈등을 피하기 위해서는 기업이 프로젝트의 운영권한을 유지해야 하고, 프로젝트를 이끌어갈 광범위한 권한을 가진 프로그램 사무국(program office)을 구성해야 한다. 프로그램 사무국은 경험 있는 고위 중역이 지휘하고 기술-직무-프로젝트 관리 분야에서 우수한 능력을 가진 인력들로 구성되어야 한다. 프로그램 사무국은 프로젝트의 취지를 실현하기 위해서 프로젝트에 참여하는 여러 사이트들과 협력해야 한다. 프로젝트를 위한 주개발팀이 하나 있어야 하고, 그 팀이 프로그램 사무국과 협력을 해야 한다.

프로그램 사무국은 최종 결정권한을 부여받되 프로그램 시행자로서보다는 조정자로서의 역할을 수행해야 한다. 시스템의 소유권은 결국 구현 사이트에 돌아가게 된다.

프로그램 사무국은 애초에 모든 팀들이 앞으로 준수할 단일한 프로젝트 라이프 사이클과 관리 방법론을 결정해야 한다. 그 프로세스는 검토 및 문서화 작업에 대한 규정들을 포함하고 있어야 한다. 때로는 이런 규정들을 고수하는 것이 프로젝트의 속도감을 떨어뜨리는 것처럼 보이기도 해서, 어떤 사이트들은 그 프로세스를 피해 「우선 구현하고 보자」는 유혹에 빠지는 경우도 종종 있다. 프로그램 사무국은 그런 모든 유혹을 감독하고 제거해야 한다. 그런 유혹은 공통된 솔루션 구현이라는 목표로부터 일탈을 초래할 수 있기 때문이다.

지능적인 디자인

IT는 기업의 사업목표를 반영해야 한다. 따라서 대부분의 시스템 솔루션들은 2가지 방식으로 디자인 될 수 있다. 비즈니스 트랜잭션에 기반을 둔 방식과 비즈니스 룰들을 공동 가동하는 방식이다.

다계층 비즈니스 시스템을 구현하기 위해서는 공통된 디자인이 필수적이다. 대부분의 비즈니스 트랜잭션은 비즈니스 룰들의 부산물이다. 다양한 디비전이나 로케이션들이 비슷한 비즈니스 활동에 참여하고 있고 공통된 역사를 공유하고 있다면 이들은 공통된 한 세트의 비즈니스 룰들을 공유하고 있다. 하지만 인수 및 확장을 위해 급격한 변화가 생기고 자연히 다양한 비즈니스 방식이 생겨난다. 그리고 바로 이 때문에 수많은 개별적 레거시 시스템들이 등장한다.

기업 레벨에서 광의의 비즈니스 룰들이 정의되면 공통된 디자인을 허용할 수도 있고, 또 로컬 레벨에서 어느 정도 운영상의 유연성을 지원할 수도 있다. 따라서 다계층 프로젝트를 위한 디자인에 들어가기에 앞서 반드시 구현 로케이션들의 비즈니스 프로세스들을 조사해야 할 것이다.

구현 로케이션들의 비즈니스 프로세스들은 ① 앞으로 구현될 공통된 시스템의 한 부분을 구성하는 프로세스와 ② 로케이션별 비즈니스 요구에 맞는 프로세스 등 2개 그룹으로 범주화 될 수 있다. 공통된 비즈니스 프로세스에 어떠한 차이라도 있으면 프로그램 사무국이 그 사이트를 위해서 단일 세트의 비즈니스 룰들을 실행해야 한다. 디자인 단계에서는 솔루션을 위한 공통된 철학을 수립해야 하고 이 철학은 반드시 지켜져야 한다.

가령, 한 가공의 기업이 2개 국가에 DC1과 DC2라는 2개의 유통센터를 가지고 있다고 가정해보자. DC1은 유통 채널별로 제품가격을 정하는데 반해, DC2는 고객군별로 가격을 정하고 있다. DC1의 경우에는 채널식별능력이 굉장히 중요하고, DC2는 개별고객관계 식별이 중요하다. 그 2가지 능력이 기업-고객 관계의 토대를 이루기 때문이다. 이러한 이분법은 제품가격 등급(클래스)과 코드들의 복잡한 그물망을 만들어낸다.

그러나 이 2가지 방법을 서로 이어주는 공통된 연결고리가 있다. 동일한 물건이라도 구매자마다 구매 가격이 다르다는 것이다. 따라서 공통된 비즈니스 룰은(채널과 고객이 아니라) 파트너 클래스마다 가격 차이가 존재한다는 정의를 내릴 수 있다. 이렇게 하면 DC1과 DC2는 둘 다 자유롭게 그들의 파트너 클래스를 정의할 수 있다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.