ERP 2.0: Process 및 Data 표준화

저자: 이석진, 한국오라클 Fusion Middleware Strategic Business Unit

ERP 이야기<하>

글을 쓴다는 것은 매우 힘들다. 차라리 10배 분량의 책을 읽는 것이 더 편하다. 그만큼 머리를 쥐어 짜고 논리적인 작업을 해야 하는 어려운 일임을 지난 호 오라클 매거진에 실린“ERP 이야기(상)”을 쓰며 알게 되었다. 그 기사 덕분에 오랫동안 만나지 못한 몇 명의 고객들이 연락이 오기도 하였고, 한편은 언제 나오느냐는 성원 어린 재촉을 받기도 하였다. 이에 힘입어 다시 한번 굳은 머리를 풀어가며 기쁜 마음으로 이 기사를 쓴다.

ERP 이야기<상>


IT의 이상향 - 통합 Architecture

“ERP 이야기 (상)”을 기고한 후 지난 3개월 간 틈틈이 많은 생각을 하였다.
과연 기업의 IT의 이상향은 무엇인가?
그리고 그 이상향은 가능한 것 인가?

결론부터 말한다면 IT의 이상은 최적으로 통합 된 Architecture를 바탕으로 빠르게 비즈니스를 대응하는 전략적 수단으로의 자리 매김이라는 결론에 도달하였다.
IT의 목적은 비즈니스를 지원하고 전략적인 도구로 활용되어야 하며 이를 위해서는 Business와 IT의 Gap을 최소화하여 빠르게 대응하기 위해 잘 정비된 통합 Architecture를 구축하는 것이다. 그러 기 위하여 많은 IT 부서들이 통합된 Architecture를 지향하고 노력하고 있다고 생각한다. 하지만 완벽하게 통합된 Architecture는 정말로 힘들 다는 것이 또 다른 결론이다.

통합을 이루기 위하여 많은 시간과 노력을 들이지만 비즈니스 변화의 흐름은 그렇게 기다려 주지않기때문이다. IT의 이상향인 통합되고 잘 정비된 IT Architecture는 찾아보기 힘들고 Need by Need로 구현된 Silo의 시스템 혹은 부분적으로 통합된 시스템이 대부분의 현실이며 이상향을 쫓는 이러한 노력에도 불구하고 거의 실현 가능성이 없어 보이는 것이다. 하지만 완벽하게 물리적으로 통합된 Architecture 구현은 불가능할지라 도 표준화된 기술을 이용한 가상의 통합은 충분히 가능하다. 이상향 대신 적절하게 조화로운 시스템을 구현하는 것이다.

이를 위해서는 IT Architecture의 기술 관점 표준화와 Business Process 관점의 표준화가 동시에 진행되어야 한다. 두 분야에 대한 표준화는 다시 Process 표준화, Master Data 통합 및 표준화, IT 표준화, Application 표준화로 나누어져 진행 되어야 진정한 IT 통합 Architecture를 구현하였다고 말할 수 있다. 이에 대하여 각 분야별로 방안을 소개하고자 한다.


기업의 IT 표준화 모델

기업이 IT에 투자를 하는 궁극적인 이유는 기업의 경쟁력 강화를 통해 이윤을 추구하는데 있다. 또한IT는 투자를 통하여 표준화 및 통합의 과정을 거치면서 발전을 하게 된다.

이때 통합의 방향은 크게 2가지 분야로 나누어지는데 첫 번째가 비즈니스 프로세스 관점의 표준화 및 통합이다. 각기 다른 사업부에서 상이한 프로세스가 운영되는 것을 PI 같은 작업을 통하여 표준화 시키는 것이 바로 그런 것이다. 또 하나는 Architecture 관점의 표준화 및 통합이다. 도입되는 솔루션에서 사용하는 Technical Stack이 서로 상이하여 Integration 상의 많은 문제점들이 있으며 이를 해결하기 위하여 표준의 Web Service 기술같은 것을 이용하여 표준기반의 통합을 시도하는 것이 두 번째이다. ERP를 도입하면서 프로세스 및 Architecture에 대한 표준화를 동시에 시도하는 경우가 많으나 여전히 Non-ERP 영역에 대해서는 명쾌한 답을 주지 못하는 상황이다.

<그림 1> 기업의 표준화 모델


프로세스 관점의 표준화 및 통합

일반적으로 ERP를 도입하면서 다른 SI Project와 다른점은 시스템구축 전에 PI(Process Innovation)라 불리는 BPR(Business Process Reengineering) 작업을 수행한다는 것이다.
이를 통하여 전사 프로세스를 대상으로 표준화 작업을 수행하며, 시스템적으로는 여러 이기종 시스 템을 프로세스라는 관점에서 표준화하는 것을 의미한다. 즉 사업부 별로 혹은 유형별로 조금씩 상이한 프로세스를 통합 및 표준화 하면서 이에 따른 불필요한 관리 요소를 제거하고 System 통합작업을병행하면서 PI의 효과를 극대화 할 수 있는 것이다.

이러한 표준화 작업은 반드시 표준화된 BPM(여기서 말하는 BPM은 System만을 말하는 것이 아니라 경영기법의 하나인 BPM의 관리 기법도 같이 의미한다) 환경에서 작업을 해야한다. 그래야만 전체 비즈니스프로세스를 통합된 시스템 환경에서 관리를 할 수 있기 때문이다.

<그림 2> 프로세스 관점의 표준화 및 통합


Architecture 관점의 표준화 및 통합

기술관점에서의 표준화란 기업의 Infrastructure를 EA 기반으로 통합하는 것을 의미한다. EA는 기업의 비즈니스, 데이터, 관리 프로세스, 정보 기술 간의 관계를 현재(AS-IS)와 목표시점(TO-BE)에 따라 명시적으로 기술한 것으로 기술 관점의 표준화를 만든다는 것은 기업의 비즈니스 프로세스부터 Infrastructure 내의 시스템까지 전반에 걸쳐 표준을 작성한 다는 의미 이기도 하다. 상이한 시스템의 여러 가지 기술을 하나의 공통된 표준 기술로 통합하여 Architecture Layer 상의 추상화된 서비스를 제공하는 방법이다. 그러므로 System Integration에 투입되는 노력을 최소화 할 수 있다.

앞 부분의 비즈니스 프로세스의 표준화를 거쳐 기술 관점의 표준화를 완성하는 것이 기업 IT 표준화 모델의 커다란 방향이다.

<그림 3> Architecture 관점의 표준화 및 통합


IT 표준화를 위한 4가지 전략적 방안

프로세스 및 기술 Architecture의 표준화를 좀더 구체적이고 실현 가능 한 분야로 나누면 다음과 같이 크게4가지로 구분된다.

① Data 표준화
② Process표준화
③ IT 표준화
④ Application 표준화

이중 어느 한 가지라도 부족하게 되면 댐의 벽 수위가 가장 낮은 위치에서 결정 되듯 가장 낮은 영역의 수준에서 IT의 수준도 결정될 것이다. 즉 IT 발전의 4가지 측면에서 균형 있는 발전을 해야 한다는 것이다. ERP를도 입하면서 상당 부분 해소가 되지만 전체 관점에서 보면 또 하나의 Silo System이 양성 될 가능성도 있다.


1) Data 표준화

Data의 표준화는 크게 Master Data의 표준화 및 Data의 Cleansing 문제로 정리 될 수 있다. 어느고객사는 ERP를 도입하며 Master Data를 표준화 하는 과정에서 2개의 공장에 납품하는 동일한 부품업체로부터 받는 부품이 한 공장보다 다른 공장이 약 3배 정도 입고 가격이 비싼 것을 발견하였다. 이는 마스터 코드가 통합 표준화 되기 전 까지는 서로 다른 부품으로 인식이 되어 담당자도 쉽게 찾아 내지 못한 경우이다. Master Data는 기업의 모든 Data의 기준이 되는 핵심 Data로써 크게 고객마스터/상품마스터/회계마스터/자산마스터 등을 들수가 있으나 이중 가장 중요한 것은 역시 고객마스터 및 상품마스터이다.

대표적으로 유무선 통합시장이 확대되고 있는 통신시장에서 본인의 Mobile No.로 Call Center에 요청을 한 후 통화를 끊지 않고 유선 전화번호 혹은 다른 서비스번호로 서비스 요청을 해보라. 다른 전화번호를 알려 주고 그쪽으로 문의하라는 대답이 돌아올 것이다. 이보다 상황이 좋은 회사는 “잠시만 기다려 주십시오”라는 안내 멘트와 함께 Call Center 요원이 다른 시스템에 접속하여 해당 식별번호를 조회하고 해당 이슈에 대하여 처리 할 것이다. 거의 모든 통신업체들이 유무선 통합에 매달려 있지 만 고객정보에 대한 통합 및 고객의 상품 가입정보/상품에 대한 정보가 통합 및 표준화 되어 있지 못해 발생하는 문제이다. 정말 중요한 문제는 고객이 기다리는 시간의 문제가 아니라 고객의 로열티 저하 및 매출 증가에 대한 기회 손실이 발생하여 비즈니스에 영향을 주는 것이다“. 해당 고객이 가입한 상품이 무엇인가?”, “ 무엇을 더 팔 수 있는가?” 가장 기본적인 질 문이지만 쉽게 답하지 못하는 것이 바로 이런 고객/상품의 Master Data가 표준화 되어 있지 않기 때문이다.

ERP를 도입하면서 많은 정제와 표준화를 거치지만 ERP에서만 모든 고객/상품의 정보가 담겨 있는 것은 아니기에 한계가 드러나는 것이고 이를 극복하기 위하여 Master Data Management(MDM)의 Solution을 별도 도입 구축하고 있다.

<그림 4> MDM을 이용한 Master Data 통합 및 표준화

MDM의 Master Data 통합효과는 ERP, Non-ERP 영역을 아울러 통합성을 제공하므로 Process의 어떤 구간이나 어떤 System에서라도 동일한 잣대와 동일한 정보로 판단할 수 있는 기반을 제공한다. MDM은 크게 3가지의 Key Component로 구성되어 있다.

<그림 5> MDM 3 key component


** Data Model
모든 Industry 및 Customer Requirement를 만족할 수 있는 Setup 기반의 매우 유연한 Data 구조(Create table… 이라는 명령어를 사용하는 것이 아니라 클릭으로 필요한 데이터 모델을 구성한다)이다.

** Integration Service
In/Out bounding 등 Master Data를 필요로하는 모든 곳에 표준기반에 Integration 시킬 수 있는 기능으로 MDM은 마스터의 통합 저장소 이기에 Master data를 필요로 하는 곳으로 Provisioning 등의 역할을 수행해야 한다.

** Data Quality service
Data 정제, Policy, Governance 등의 Data Cleansing 및 관리 정책을 수용하는 기능으로 물리적인 합병이 중요한 것이 아니라 잘 정제되고 정확한 정보를 제공해야 하는 핵심 기능이다.

여기서 MDM을 도입하면서 타 시스템과의 연동에 대한 방법을 여러 가지로 결정할 수가 있다. 그중 가장 효과가 큰 것은 SOA 방식으로 구 현하는 것이다.

결국 ERP를 구축하면서 많은 부분의 Data 표준화 및 정제작업을 하지만 ERP 자체가 MDM의 기능을 제공하지 않으므로 Post ERP 혹은 상품/고객 정보의 통합을 위하여 MDM을 도입한다. MDM의 도입효과는 Data에 대한 전사적인 표준화, Governance 정책을 통한 Cleansing 등의 작업을 수행하여 일관되고 적시에 정확한 정보를 제공하는 역할을 한다. 이런 MDM은 SOA 기반의 시스템으로 구축하여 유관 시스템과의 유기적인 표준방식의 연동을 통하여 Data의 표준화 방안을 제공한다. 결론적으로 Process가 여러 시스템에 걸쳐져 있는 경우 상호 간의 기준이 되는 Master Data의 표준화 및 통합이야 말로 IT 표준화의 첫걸음이자 가장 중요한 대목이라 할 수 있겠다.


2) 프로세스의 표준화

ERP를 도입하면서 대부분의 기업은 전략을 달성하기 위한 과제 수행 및 Process Innovation 작업을 병행하게 된다(<그림6> 참조 ).

<그림 6> Build Vision to System

<그림6>은 Vision부터 System 구현까지의 각 단계를 추상적으로 정리 한 자료다. 이중 Vision 수립부터 PI까지는 주로 Paper work라 할 수 있고 PI 산출물을 받아서 시스템을 구축하는 것은 말 그대로 IT를 이용한 구축과정이라 할 수 있다. 문제는 PI 결과가 System 구축의 Input 자료로 활용 되어야 하는데 Paper 기반의 산출물로 인해 실제 이 부분에서 많은 괴리가 발생하고 이로 인해 용두사미 격의 구축이 되는 경우가 많다.

실제로 모 고객사를 방문하여 CIO를 면담하는데 두껍게 바인딩 된 책자를 보여 주면서 이것이 수십 억을 들여 수행한 PI Consulting Project의 산출물이라고 자랑을 하였다. 면담 후 몇몇 담당자를 만나면서 PI 결과물을 읽어 보았냐고 질문을 던지니 담당자의 대답은 “PI Project를 수행한 것은 아는데 결과를 모두 읽어 보지는 못했다.” 였다. 한마디로 PI Consulting과 IT 담당자의 System 구축은 별개였던 것이다.

또 다른 경우, Process를 수행하는 협업부서에서 Process consulting에 대하여 산출물로 정리된 것 조차 정보를 파악하지 못하는 상황이 발생한다. 즉 몇몇의 프로젝트 멤버가 몇 달간 고생하여 PowerPoint로 작성한 문서가 CIO/CxO 보고 이후 파일서버에서 쉬고 있는 것이다.

PI Consulting을 수행한 목적이 무엇인가 반문하고 싶다. 기업의 정형화 되지 못한 Process를 수술하여 최적화 되고 민첩한 Process를 구현하고자 함이 아닌가? 그럼에도 불구하고 프로세스에 참여하는 당사자들도 이런 내용을 모르고 있으니 과연 이것이 제대로 된 Consulting 투자라고 말할 수 있는지 의문이다.

<그림 7> Deform PI to System

또 하나의 문제는 Process 표준화 작업인 PI를 수행하면서 산출물이 전체가 공유하기 힘든 PPT로 작성되고 이 결과가 시스템 구축에서 필요한 Input Data를 활용되지 못함으로써 각 구간별 작업이 변질되고 전체적인 정렬이 되지 못하는 것이다(<그림7> 참조).

비싼 외부 컨설턴트의 PI 산출물의 논리적 오류, 시스템을 감안 하지 않은 이상적인 디자인을 예방하기 위해서는 프로세스 표준화 작업 시 표준 기반의 프로세스 표기법(BPMN: Business Process Modeling Notation)을 사용하여 논리적 오류 예방 및 시스템을 감안한 디자인이 되도록 해야 한다. 더불어 매 단계에서 작성되는 모든 프로세스의 정보는 Business Process Repository를 통하여 모든 단계에서 공유가 되고 참조가 되어 단계별 단절을 최소화 하는 제도적인 장치가 필요하다. Process 표준화에 대한 작업은 BPMN을 이용하여 작성이 되고 이 정보가 Process DB에 저장이 되어 다음 단계인 시스템 구축에서는 BPEL로 자동 변환되어 개발자가 Integration 항목만 개발하여Business Process 표준화의 산출물이 시스템 구현까지 디지털화 된다. 그러므로 단계별로 전달이 되어져야 진정 한 프로세스에 대한 표준화 및 PI가 시스템까지 정렬되는 효과를 누릴 수 있다(<그림8> 참조).

<그림 8> Transform PI to System

이렇게 각 단계별로 프로세스 DB를 통하여 공유되고 저장된 프로세스의 표준화정보를 Web Service/BPEL/Sensor/BAM 등의 표준기술을 이용 한 업무 시스템으로 구축함으로써 지금까지 뒷 작업을 고려하지 않은 PowerPoint 출력물에 의존하는 외부컨설팅 산출물에 대한 품질강화 및 기업의 비전부터 시스템의 구현까지 전략적 Alignment를 달성할 수 있 게 되는 것이다. 이것이 IT 표준화를 위한 단절 없는 프로세스 표준화에 대한 구현 방안이다.


3) IT 표준화

IT를 표준화 한다는 말은 매우 광범한 의미이다. 여기에서 언급 하고자 하는 것은 각각의 다른 기술을 사용하는 시스템과의 표준에 근거한 연동이다. ERP를 도입하면서 이뤄지는 Non-ERP 영역과의 통합은 조금 특이 한 방식이다. Oracle Applications 같은 경우 OIT(Open Interface Table) 혹은 API를 이용하는 방식의 연동 방법을 제공한다. 즉 OIT에 Interface Data를 넣으면 자동화된 절차에 의해 Data Validation Check를 수행하여 ERP DB로의 Insert/Integration 작업이 이루어지며 실시 간적인 방법은 API 호출 및 연동에 의하여 처리 된다. SAP도 이름만 다르지 큰 차이가 없다. iDocs를 통하여 연동이 되며 BAPI라는 API를 통하여 실시간 연동이 이루어 진다.

ERP 뿐만 아니라 최근의 IT 개발의 Trend는 Build 전략보다는 Buy 전략으로 넘어가고 있다. 즉 기업의 핵심 경쟁은 IT 개발이 아니라 IT를 이용한 Business Value 창출이라는 것이다. 그런 관점에서ERP가 아니어도 많은 PKG제품들이 도입되고 있는 상황이다. 이것은 PKG업체의 기술적 Stack을 그대로 용인한다는 의미이며 모든 PKG가 동일한 기술 Platform에서 개발되지 않았으므로 이 기종, 이 기술간의 연동은 가면 갈수록 문제가 커질 것이다. 이를 해결하고자 나온 것이 바로 Web Service라는 표준의 기술을 이용하여 Architecture Design 패턴을 서비스 중심으로 변경, 서비스 단위의 변화 및 개발을 통한 IT Agility를 확보 하고자 하는SOA 도입이다. 바꾸어 말하면 시스템 내부의 표준은 부서단위/프로젝트단위로 수행되고 전체 IT의 통합 표준은 SOA/Web Service를 이용한다는 의미이다.

<그림 9> 전통적인 IV vs SOA

SOA에 대해서는 이미 많은 사람들이 알고 있으므로 간단한 오디오 그림 을 통해 어떻게 IT 표준화를 하여야 하는지 설명해 보겠다.
전통적인 IT 에서는(<그림9>의 왼쪽) 기능 추가가 힘들다. 설계도와 부품을 구해 스스로 디자인/개발/조립을 하여야 하며 Lead time 역시 장시간 소요되므로 빠른 변화에 부적합하다고 할 수 있다. SOA는 Component Audio system 처럼(<그림9>의 오른쪽) 내가 필요한 기능을 구매 혹은 단위 개발하여 오디오의 표준인 RCA 단자를 이용, 타 회사 제품(시스템)간의 연동을 Plug-in 방식으로 구축하는 것이다. 예를 들어 마란츠의 앰프가 마음에 안 들어 매킨토시의 앰프로 변경한다 하더라도RCA단자를 이용하여 교환만 하면 되는 방식이다. 이때 매킨토시의 내부 부품/회로까지 내가 원하는 대로 표준화할 수는 없다. 즉 PKG 혹은 기 개발된 시스템의 내부까지 표준화 하면서 완벽히 통합하기는 불가능하며 단위 시스템의 내부는 어느정도 독립성을 용인을 하지만 각 시스템간의 연동은 철저히표준기반의 연동을 통하여 표준의 대상이 되는 Layer를 한 레벨 위로 올리는 것 이다. 이것이 실질적인 IT 표준화라 할 수 있다. 기업 내의 모든 시스템에 대하여 완벽하게 표준화를 하면 좋지만 그렇게 하기 위해서는 엄청난 인력/시간/비용이 소요되므로 거의 불가능하다고 볼 수 있다. SOA를 이용 하여 표준화의 대상을 한 단계 높여서 추상화 한다면 상대적으로 적은 비용을 가지고 큰 효과를 볼 수 있는 것이다.

최근의 신문 혹은 고객들에게서 나오는 질문중 하나가 “SOA가 도입 되어 실질적인 ROI가 검증된 것이 정말 있는가?”, “ SOA는 벤더에 의한 제품 팔기 논리가 아닌가?”라는 것이다. 실제 국내에서 SOA를 도입하여 드라마틱하게 성공한 사례는 많지 않다. 이유는 도입 담당자가 너무 급하게 실질적인 효과를 기대하고 있는 것이다. 이에 대하여 간단히 설명한다면 SOA를 구현하기 위하여 도입하는 Web Service라는 기술은 말 그대로 표준의 기술이다. 즉 기업 IT 전체가 표준기술(Web Service)로 구축이 되어야 효과가 있는 것이지 일부 단위의 시스템이나 일부분에 적용하고 결과를 기대하는 것은 너무 이른 것이다. 정책으로 정한 표준이 모든 시스템에 확대 적용되고 지속적으로 표준을 유지할 수 있어야 표준의 기대 효과를 볼 수 있는 것이지 단순하게 일부 영역에 도입하였다고 해서 기대효과가 창출되는 것은 아니다. 일부만 도입하고 중단한다면 Web Service/SOA도 결국에는 많은 기술 중의 하나로 전락하고 말 것이다. 그런 관점에서 IT 표준화는 지속적으로 목표점에 도달하기 위한 많은 노력 과 투자의 Governance 부분이 매우 중요한 것이다. 고속도로 톨게이트의 정체를 피하고자 개발된 하이패스가 이 같은 사례이다. 아직은 많은 차량들이 하이패스를 사용하지 않고 있어 그 효과가 크지않다. 하지만 모든 차량들이 이를 사용한다면 톨게이트의 정체 등의 문제는 단번에 해소될 것 이다. 이 처럼 표준정책을 확대 적용하기 위한 노력은 지속적으로 유지 되어야 한다.


4) Application 표준화

Application 표준화는 개발되는 Application에 대한 표준화를 지향하는 것이다. 이는 응용 프로그램의 구조와 작성 서식 등을 표준화하여 이해하기 쉽고 유지보수가 쉽게끔 하는 것이다. 표준화 된 Application Layer는 Application 개발자에게 있어 개발을 손 쉽게 할 뿐만 아니라 변경관리 추적 등의 많은 장점을 제공하여 준다.

필자는 몇년 전 모 회사의 차세대프로젝트의 Architect로서 2년간 프로젝트를 수행하였었다. 개발의 근간은 CBD방식을 취하는 것이었다. MVC Model을 근간으로 한 J2EE Framework 기반의 개발이었는데 문제는 개발자의 개발이 아니라 Component 및 Service에 대한 통제와 관리조직이 부실하였다는 것이다. 개발자들이 개발에 들어가기 전에 관련 된 개발표준 Rule과 공통Component/Service들은 사전 제공이 되어야 한다. 그렇지만 개발단계 중간에 이것들이 제공되어 시점상 많은 문제가 발생하였다. 개발자에게 비슷한 내용의 중복 개발을 하게끔 만들고 표준을 준수하지 않음으로써 생산성 및 판독난이 등의 문제와 서비스 변경에 따른 영향도 파악과 유지보수를 힘들게 하는 문제가 발생한 것이다. 결국 Application 표준화의 중요성 및 적절한 시점에 관련된 정책 및 관리 방안을 제공하지 않아 발생하는 문제였다.

ERP의 경우 개발 Framework와 표준 개발 방법론이 제공되고 있다(Oracle ERP의 경우 OAF: Oracle Applications Framework 및 방법론 표준화된 개발 가이드를 제공한다). ERP의 장점은 수천명의 개발자에 의하여 개발이 되기 때문에 이런 방법/표준화 된 Asset이 매우 잘 되어 있다는 것이다. 심지어는 표준화된 방법을 따르지 않으면 Add-on 형태의 개발이 무척이나 힘든 반면, 이를 준수 한다면 높은 생산성과 통합성을 제공하는 장점이 있다.

<그림 10> Application 표준화를 위한 Enterprise Repository

Non-ERP로 개발되는 경우, 대부분 자체 방법론과 표준화된 정책을 가지고는 있으나 이런 방법에 의하여 제대로 개발이 되고 적절히 유지보수 되느냐 하는 것에 대한 문제를 가지고 있다. 즉 정책을 수립하고 표준화된 방안을 제시하지만 개발자나 유지보수하는 사람에 의하여 준수가 되지 않는다면 불필요한 존재가 될 것이다. 특히 Outsourcing을 많이 하는 추세에서 IT 개발자가 본인에게 익숙하지 않은 가이드를 준수할 것으로 기대하는 것은 큰 착오이다.

이를 강제화하고 통제하여 Application Layer에 대한 표준화를 기대할 수 있는데 이런 것들은 Application Governance 관리체계의 강제화 및 시스템화를 통해서 구현될 수 있다.

Application Governance는 통합 Enterprise(Software Asset) Repository를 통하여 모든 Application의 구성 요소를 데이터로써 관리하고 통제하는 방식으로 효율적이고 효과적인Governance를 유지하는것이다.

<그림 11> Enterprise Software Repository Overview

<그림11>에서 보는 것 처럼 Application Layer에서의 모든 Component 및 SOA에서의 Service를 Software 자산화하여 등록, 관리 한다면 변경 의존성 분석, 중복제거, 재사용성 정도 측정, Guide 준수 여부 등을 통하여 손쉽게 통제할 수 있게 된다. 개발자는 기 개발된 Software 자산 조회 및 재사용을 통하여 활용성을 높이고 본인의 핵심 개발 내역인 비즈니스 로직 개발에만 충실하게 되어 생산성도 좋아지게 된다. Enterprise Repository를 이용한 Application 표준화는 이런 노력 없이 개발되는 Application과는 품질 차이가 클 수 밖에 없게 된다. 이것이 Application Layer에 대한 표준화이며 IT 표준화를 더 강화할 수 있는 방법 중의 하나 이다.


맺으며

이상 2회에 걸쳐 ERP 구축 이후 발생하는 문제점 및 SOA/BPM을 이용한 극복 방안과 IT Architecture 표준화, 프로세스 표준화에 대하여 간단히 소개하였다.

최근 통합의 방향은 궁극적으로 ERP 혹은 차세대 시스템을 통하여 최대 한의 업무통합을 시도하는 것이다. Non-ERP/Non-NGS(Next Generation System) 영역에 있어서는 Data 표준화, IT 표준화, Process 표준화, Application 표준화를 통하여 고객 및 Business Process 관점의 통합을 시도하는 것이 바로 ERP 2.0의 핵심이라 말 할 수있다. 표준을 통한 통합이 가장 중요하다. 표준이야말로어떤 경우에도 가장 민첩하고 손쉽게 대응 할 수 있는 유일한 방법이기 때문이다. 표준 기반의 통합은내부 시스템이 ERP, Non-ERP 등으로 분산되어 있다 하더라도 고객에 대하여 고객의 관점에서 통합된 Single View를 제공하는 이점이 있는 동시에 가장 현실적인 IT 통합의 대안이라고 말할 수 있다.

기업의 비즈니스가 어떻게 변화 할지 알수 없고 HW, SW Solution들이 어떠한 방향으로 변모 할지는알 수 없지만기업의 IT 발전 방향은 통합의 방향으로, 통합을 위한 Web Service같은 표준 기술 기반의, 통합을 하기 위한 Solution의 출현으로 발전할 것은 확실하다.

<그림 12> IT 관점의 통합이 아닌 고객 관점의 통합


출처 : 한국 오라클
제공 : DB포탈사이트 DBguide.net