ERP 2.0: Post ERP의 전략

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

ERP 이야기<상>

80년대 중반, 필자는 대학 1학년 때 처음으로 PC를 샀다. 8088 CPU, 640Kb 메모리, 5.25inch Floppy Drive 2개가 달린 것으로 거금 80만원을 주고 산 첫 조립 PC였다(당시 한 학기 등록금이 대략 50만원 대 중반이었으니 엄청난 투자였다). 그때의 흥분은 지금도 가슴 속 깊이 아련하게 남아 있다. 20년 가까이 지난 지금, 본 기사를 쓰고 있는 이 PC의 사양은 Dual Core CPU, 2Gb Memory, 1TB Disk로 처음 산 PC에 비하면 가히 슈퍼급의 PC를 쓰 고 있는 것이다.

이제는 IT 업계의 발전 속도가 빠르다 못해 최신 제품도 1년만 지나면 골동품이 되고 전시장에나 처박혀야 하는 그런 시대라 할 수 있다. 이러한 발전에 힘입어 예전에는 가능하지 못했던 것들이 이제는 가능해져 Server의 용량이 과거 2-3년 전의 슈퍼 컴퓨터 급에서 대형 급으로 내려오고 대형 급은 다시 중형 급이 되는 상향 평준화의 속도가 빨라졌다. 그러기에 기업에서 추진하거나 그렇지 못하거나 관계없이 과거의 고민들이 이제는 HW의 용량이 부족하여 처리하지 못하는 시대는 끝난 것으로 보인다.

더불어 기업에게 필요한 SW 역시 매우 다양하여 이를 위해 많은 솔루션들이 개발 되었다. 이제는 없어서 사용하지 못하는 시대가 아니라 몰라서 사용하지 못하는 시대인 것이다. 이러한 관점에서 IT의 영원한 과제인 ‘통합’을 어떻게 잘 해내느냐 하는 것이 모든 기업들의 핫 이슈로 떠올랐고 이를 위해 많은 기업들이 ERP를 도입하고 실행하였으나 여전히 미완의 오케스트라로 남아있다. ERP에 기반한 미완의 오케스트라를 완성하기 위해 해야 할 최선의 노력은 SOA/BPM을 이용한 고객 프로세스 관점의 통합 및 완성이다.

Oracle은 이러한 Post ERP 구축 전략을 ERP 2.0이라 부른다.


통합을 향한 노력

현재 IT 시장에서는 HW뿐만 아니라 SW 역시 다양하게 개발되어 기업 에서 필요한 거의 모든 Enterprise Solution의 경쟁이 치열하다. 이렇게 멈추지 않는 변화의 흐름 가운데에서 변하지 않는 키워드가 있다면 그것 은 바로 “통합” 이다. 이는 IT 역사가 끝나는 날까지 고민해야 할 거대한 과제이자 숙제일 것이다. 아마도 빠르게 변화하는 비즈니스 상황을 지원하기 위해서 잘 정비된 통합시스템의 구축보다는 단편적으로 빠르게 Silo system을 구축하고 대응하는 것이 더 유혹적이고 매력적으로 느껴질 것 이다. 그러나 이러한 손쉬운 방법을 택함으로써 Needs by Needs 형태의 Silo system이 양산되고 운영되어 IT의 통합이 지속적이고 필수적인 과제로 떠오르고 있다. 때문에 많은 HW, SW 업체들이 신제품을 경쟁적으로 내놓고 더 낮은 TCO와 더 높은 성능을 자랑하지만 이 모든 것들이 결 국은 기업의 IT 통합을 위한 Solution에 관련 된 것이라고 말 할수 있을것 이다. 또한 모든 기업의 CIO들이 고민하는 것 중 가장 큰 부분은 주어진 비용 안에서 비즈니스를 신속하게 지원하고 모든 IT 자원들을 잘 통합하여 잘 정리된 Architecture를 구현하는 것이다.

비즈니스 통합, IT 통합의 노력은 계속 진행되어 왔고 90년대 초반부터 도입되기 시작한 ERP는 이러한 IT 성장을 배경으로 기업 업무의 통합을 지향하는 핵심 도입 솔루션이 되었다. ERP 시장이 이미 성숙해졌다고는 하지만 아직도 많은 기업들이 ERP 도입을 계속 추진하고있으며 기 도입 한 기업의 경우 ERP를 잘 활용하기 위하여 많은 노력과 투자를 여전히 진행하고 있다.
특히 90년대 말과 2000년대 초반에는 ERP를 도입하지 않으면 기업의 경쟁에서 도태되는 듯한 분위기 속에 많은 기업들이 ERP를 앞 다투어 도입 및 구축하였다. 그 결과로 ERP를 도입한 기업들은 과거에 구현해보지 못한 Process, Data 통합의 관점에서 많은 혜택을 얻었고 기업 경쟁력 강화에 많은 도움을 받기도 하였다(<그림1> 참조).

하지만 ERP가 모든 기업 IT의 문제점을 해결해주지는 못하였다. 기존 ERP 구축 프로젝트의 경우는ERP와 타 시스템간의 통합을 전체가 아닌 데이터적인 측면에서 수행하게 되었다. ERP 영역은Package Vendor에 의하여 제공되는 잘 정리된 Architecture를 구축하지만 ERP에 적용하지 못하는 Non-ERP 영역은 여러가지 방식이 혼재된 복잡한 Architecture를 구현하는 것이 대부분의 고객 현실이다. 이러한 방식의 Application Architecture 정책은 고객이 업무 프로세스를 수행하기 위해 여러 시스템을 사용하거나, 변화하는 기업의 정책을 반영하고, Globalization 통합을 구축하며, 사용자 편의성 등의문제를 해결 하는데에 완벽한 방법을 제시하지 못하고 있을 뿐 아니라 기업은 이러한 문제들을 해결하기 위해 많은 시행착오를 겪고 있다.

이러한 Post ERP의 문제점을 보완하고 개선하기 위한 작업이 SOA/BPM 등의 기술을 이용하여 진행되고 있으며 이러한 노력들을 필자는 ERP 2.0이라고 부르겠다. 본 기사에서는 SOA/BPM을 이용한 ERP 제약 조건 극복방안에 대하여 다룰것이며 다음 호 오라클매거진에서는 기술관점의 표준화와 비즈니스 프로세스 관점의 표준화를 통한 ERP 2.0에 대해서 연재하고자 한다.

ERP 2.0을 이야기 하기 전에 IT 통합의 흐름을 먼저 알아보자. 역사를 통하여 배우는 것은 과거의 경험을 바탕으로 미래를 예측하고 올바른 방향으로 IT를 Drive 할 수 있는 좋은 방법중의 하나이다. 또한 왜 ERP를 이용한 통합이 시작되었고 향후 발전 방향이 무엇인가를 파악할 수 있는 좋은 방법이기도 하다.


통합의 역사-1세대 Peer-to-Peer Architecture

기업의 최초 IT는 Needs by Needs 형태로 필요한 시스템이 하나씩 개발되는 형태였다. 당연히 전체 통합이란 측면은 고려되지 않았고 사용하면서 각 시스템간의 유기적인 통합이 필요하게 되어 나타난 것이<그림2>와 같은 형태의 Peer-to-Peer 방식의 가장 원초적인 단계이다. 총 시스템이 10개라면 모두 90개의 Interface 방식이 필요하며 통합의 기술 역시 표준화 되지 않아 최악의 경우, 90가지의 Interface 기술이 필요한 방식이다. 실시간적이지 못하고 단순 Data 관점의 통합방식이어서 지금은 모든 기업이 이런방식을 지양하고 있는 상황이다. 90년대 초반까지 이런 형태의 통합이 많았고 지금도 완전하게 없어지지 않고 일부 기업이나 시스템에서는 아직도 1세대적 Architecture를 유지하고 있다. 하나가 변경되면 관련된 모든 시스템이 변경되어야 하는 수작업이 많고 정보의 일관성을 유지하기도 힘든 매우 복잡한 Case를 유발하게 된다.

그 결과로써 외국의 모 통신업체의 전체 시스템 Architecture를 나타낸 <그림3>과 같이 구현된다. 보기에도 복잡하며 하나를 건져 올리면 실타래 처럼 여러 개가 따라 올라 오는 듯한 전형적인 Architecture다.


통합의 역사-2세대 EAI를 이용한 Data 중심의 통합

EAI의 등장은 2세대 통합의 시대를 열게 하였다.
각각의 시스템은 EAI의 Hub로 필요한 Data를 던져 주면 EAI는 모든 Interface를 관장하게 되는 방식이다. 기존 1세대 방식 대비 상당히 혁신적인 방법이며 아직도 많은기업들이 사용하고 있는 통합의방식이다. 하지만 EAI의 특징상 Data 중심의 통합이다. 사용자가 필요로 하는 프로세스 및 사용자 관점의 통합이 아니라 IT 부서의 내부 효율만을 강조하는 Data 관점의 통합인 것이다.
90년대 EAI Solution이 붐을 일으키면서 많은 IT 기획자들이 고민한 것이 바로 EAI 도입으로 Business 및 user의 사용상 이익을 계산하는 것 이었다. IT 내부 통합의 효율성을 극대화하면 자연스럽게 사용상 이익이 발생하지만 이것만으로는 설득하기가 무척 힘든 상황이었다. 또한 사용 되는 기술의 특성상 여전히 큰 문제가 남게 되는데 첫 번째는 Business Process 관점의 통합이 아니기 때문에 생기는 문제이다. 여전히 프로세스는 여러개의 시스템에 걸쳐 처리되며 Data 관점의 통합은 프로세스 통합이라는 관점까지 승화되지 못함을 보여주고 있다. IT System 간 Data 중심의 통합이다 보니 당연히 그럴수밖에 없는 부분이다. 두 번째 문제는 사용되는기술이 표준방식이 아니고 Data Interface Object 처리방식 이다 보니 서비스라는 개념까지 승화되지 못한 점이다. 결국 EAI 간의 호환성 문제가 발생하며 상대방의 시스템이 EAI Adapter를 지원하지 않을 경우 원천적인 문제로 복귀 할 수 밖에 없는 proprietary한 기술방식이다. 하지만 Data 관점의 통합에서 1세대 방식보다는 Logical 통합 시스템을 쉽게 구축할 수 있는 유용하고 일취월장한 방식이기도 하다.


통합의 역사-3세대 GSI & SOA를 이용한 End User/Process관점의 Virtual 통합

마지막인 3세대 통합의 Trend는 GSI(Global Single Instance) 및 SOA/ BPM을 이용한 Virtual  통합의 2가지 패턴으로 변화되고 있음을 알 수 있다. 먼저 GSI는 오라클에서 최초로 주창한 방식이며 말 그대로 하나의 통합 ERP를 중심으로 최대한 모든영역을 통합하여 하나의 Single Database를 운영하는 방식이다. 그렇게 함으로써 한번 발행한 Data는 단 한번의 저장을 통하여 모든 Application과 process에서 중복없이 사용하게 되는 가장 이상적인 구조라 말 할 수 있다. 이를 통해 통합 자체는 ERP에서 모든것을 처리하게 되므로 ERP 영역 내에 넣을 수만 있다면 정말로 손쉽게 업무간, 프로세스간의 통합을 구현할 수 있는 방식이다. 주로 ERP를 사용하는 고객에게서 많이 볼 수 있으며 LG전자/POSCO/삼성전자 같은 경우가 대표적인 경우이다.
LG전자의 경우 국내 4개의 사업부간 구축된 ERP와 본사 ERP 그리고 해외 70여개의 생산/판매 법인의 ERP를 하나의 ERP로 통합하는 작업이 성공리에 잘 진행되었고 지금도 그 범위를 확대해 가고있다. 하지만 ERP의 경우 Back Office 업무 통합에는유용하지만 기업의 Core system 통합에는 여전히 한계점이 존재한다. 예를 들면 은행의 Core Banking 영역, 통신업계의 Billing System 영역, 제조업계의 MES 영역에 있어서는 오라클이나 SAP 역시 마땅한 Solution을 제공하지 못하고 있고 극히 일부만 제공하고 있을 뿐이다.

결국 ERP를 이용한 GSI 방식은 ERP가 적용 가능한 업무영역에 대해서는 손쉽게 적용이 가능한 장점이 있지만 반대로 ERP를 적용하기 힘든 영역에 대해서는 한계점이 드러나는 방식이다.

ERP는 태생 자체가 MRP에서 시작되어 MRP2, ERP, Extend-ERP로 거치면서 제조/유통업에 맞게끔 최적화 된 Solution이며 최근 업종을 불 문하고 Back Office 중심(Fin, HR, 구매/자재 등)으로 확대해가고 있다. 그렇지만 여전히 특수 업종에 있어서는 적용하기 쉽지 않은 경우도 많이 발생한다. 이런 상황에서는 기업의 전체 업무를 ERP 수준의 고품질 통합 시스템으로 구축하는 것은 매우 힘들며 대부분 영역별 통합 혹은 개별적인 시스템으로 분리 운영되고 있다.
한계점을 극복하기 위하여 최대한의 Data, Technical 통합을 시도한 후 효과를 극대화하기 위한 방안을 조치 하고 있다. 이를 위해 최근 적용되는 기술이 바로 SOA 및 BPM 관점의 Solution 영역이다. 최대한 통합된 다수의 개별 시스템 위에 필요한 서비스를 도출하고 표준의 기술인 Web Service를 적용하여 서비스 레이어를 구축하며 서비스와 서비스를 조합하여 하나의 프로세스를 완성해 사용자 와 Process 관점의 통합성을 제공하는 것이 바로 3세대 통합의 2 번째 특 징이다. 가트너에서는 이러한 발전의 방향을 Fusion & Consolidation 이라 부르고 있다(<그림6> 참조).

결론적으로 최근 IT 통합의 Trend는 ERP 혹은 자체 시스템을 이용하여 최대한 업무 영역을 통합하고 Non-ERP 영역이나 통합되지 않은 영역에 대해서는 서비스 도출 및 SOA Based BPM을 이용하여 User와 Process 관점의 가상 통합을 시도하는 것 이라고 말 할 수 있다. 이러한 방식이 ERP 구축 이후 SOA/BPM을 이용한 Post ERP의 통합 작업, 즉 ERP 2.0의 설명이다(<그림7>). 그렇게 함으로써 ERP 영역과 Non-ERP 영역에 대하여 가상의 통합 시스템을 구축할 수 있고 사용자는 프로세스 관점으로 업무를 진행하므로 자신이 진행하는 프로세스가 ERP 영역인지 Non-ERP 영역인지 크게 신경을 쓰지않게 되므로 프로세스의 지연시간 최소 및 Lead Time 최소화 등의 Business & IT Agility를 확보할 수 있게 된다.

ERP 구축 후 발생하는 문제점

ERP 구축 후 발생하는 문제점은 사소한 UI의 불편함부터 매우 광범위하게 발생하고 있다.
전사 관점의 최적화를 위해서는 이러한 불편을 감내해야 하는 것 처럼 인식이 되고 있지만 구축 후 이러한 문제점을 적기에 해결하지 못하면 비싼 비용을 치르고 구축한 ERP의 무용지물이라는 위기까지 맞을 수도 있다. 실제 이런 문제를 해결하기 위하여 Post PI, Post ERP, PI2 등 다양한 명칭의 프로젝트를 지속하기도 한다. ERP 구축 후 발생하는 문제의 유형은 다음과 같으며 이를 개선하기 위하여 전통적인 방법의 보완 보다는 SOA/BPM Based ERP를 구축 한다면 개선/가상통합의 효과를 극대화 할 수 있다.

SOA/BPM을 이용한 ERP 구축의 문제점 해결 방안

그러면 ERP 구축 이후 발생하는 문제에 대하여 어떤방식으로 SOA/BPM 등을 이용하여 해결 및 개선하여 효과를 극대화하고 ERP에 추가적인 Value를 Add 할 수 있는지 구체적으로 알아 보도록 하겠다.

이는 3세대 통합에서 설명한 방식이다. 사이로(Silo)처럼 구축된 시스템을 Data 관점의 EAI를 이용한 통합의 방식에서 벗어나 각각의 시스템으로부터 재사용 가능한 Service를 도출하고 서비스와 서비스의 조합을 통하여 Business Process 관점에서 통합 구축하는 방식이다. 이렇게함으로써 IT 내부의 복잡함은 감춰지고 철저하게사용자와 프로세스관점에서 통합시스템을 구축하게 된다. 이것이 바로 가트너에서 이야기하는 Fusion 방식의 Consolidation 방법이다.

대부분의 ERP 사용자들이 토로하는 불만 중 하나가 UI의 불편함이다. 이는 ERP 태생 자체가 정보공학론 방법에 입각하여 개발 되었고 특히 한국 사람들은 한 화면에 정보가 오밀조밀 하게 나오는 형태를 매우 선호하는 취향을 가지기 때문에 발생하는 문제 이기도 하다. 특히 영업현장의 경우 조금이라도 UI가 불편하면 작은 문제임에도 불구하고 마치 굉장히 중요하고 심각한 문제로 왜곡되어 문제에 비하여 상당히 강하게 전달 되기도 한다. 실제 Oracle ERP의 대표적인 Reference Site에서도 이러한 문제가 있어 불가피하게 영업 Order 입력 화면을 개발하여 Add-on 형태로 사용하는 현상까지 발생하기도 하였다.

이런 경우 사용자 입맛에 맞는 화면을 X-Internet 등을 이용하여 디자인하고 ERP에서 제공되는 API를 Web Service화 하여 호출하는 형태 즉, Data Validation Check는 UI에서 처리하고 실제 등록/수정 등의 작업은 ERP에서 제공되는 Standard API를 이용하여 처리하면 ERP의 Logic을 벗어난 추가 개발도 최소화하고 사용자 입맛에 맞는 UI를 제공 할 수 있게 된다. 더불어 수시로 적용되는 ERP Patch로의 문제도 Standard API를 사용함으로써 기 개발된 화면 등을 재 수정없이 처리할 수 있는 장점이 있다. 하지만 모든 화면을 이런 방식으로 하게 되면 많은 개발 공수가 추가되므로 자주 사용하거나 UI상의 불편이 큰 화면 중심으로 일부 적용한다면 사용자 만족과 ERP의 Standard Rule도 적절히 맞출 수 있는 장점이 있다.

기업의 프로세스는 하나의 시스템에서 시작하여 그 안에서 종료되는 경우가 그리 많지 않다. 대부분이 여러개의 시스템을 걸쳐서 하나의 프로세스가 종료 된다. 대표적인 Order to Cash(고객주문으로부터 현금화까지의 프로세스) Process의 경우 주문시스템, CRM, SCM, Finance System 등의 여러 시스템을 걸쳐 완성된다. 이런 경우 사용자 입장에서는 고객의 주문이 현금화 되는 과정까지의 추적이나 진행 상태를 파악하기 위해서는 여러 시스템에 걸친 로그인 및 조회를 통하여 처리해야 하며 시스템간의 Data 이동 시에는 어디까지 처리되었는지 파악하기가 매우 힘든 경우가 종종 발생한다. 이런 문제점으로 인하여 고객 만족도 저하 및 Sales Lead Time 지연 등의 경영적 KPI 악화 상황까지 발생할 수 있게 된다.

이런 경우 프로세스 각각의 Task에 해당되는 부분을 Service화 하여 여러 시스템에 걸쳐져 있는 Service(Task)를 Process Layer로 분리된 SOA Based BPM을 이용하여 통합 정보 및 프로세스의 가시성을 제공한다면 영업/고객관점에서 상당한 만족도 및 고객주문 처리 속도개선의 효과를 볼 수가 있다. 지금까지의 BPM의 주 적용 대상이 SCM 혹은 고객주문/불만처리 프로세스인 것을 보면 이것은매우 검증된 분야라고 말 할 수있다. Order-to-Cash 뿐만 아니라 process visibility가 필요한 프로세스나 여러 시스템에 걸쳐 상태 파악이 힘든 모든 프로세스에 적용할 만한 하며 기대 효과 또한 매우 크다고 말할 수 있다.

개인적으로 십년 가까이 ERP Project를 수행 하였지만 매 프로젝트마다 발생하는 이슈가 바로 이미 구축하여 사용하는 Groupware와 새롭게 구축하는 ERP와의 연동이다. 하지만 Groupware 자체가업계표준의 기술로 명확히 자리 잡지 못한 상황에서 특별하게 Prebuilt된 Solution이 없어 매 프로젝트 마다 새롭게 정의하고 추가 개발하거나 여전히 불일치된 상황에서 운영을 해야하는 문제가 발생한다. 내부 통제의 어려움, 정보의 실시간 처리 지연, 정보의 부정확 등과 같은 상황이 생기는 것이다. 결국 ERP에서 처리되는 Data Flow와 Groupware에서 처리되는 Human approval Flow 간의 불일치 문제라 말할 수 있다.

이런 경우 SOA/BPM을 이용하여 Human work flow의 처리 결과를 실시간적으로 ERP의 Data Flow와 일치 시킴으로써 여러 가지 문제점을 한번에 해결할 수 있는 장점이 있다. 또한 Groupware에서 표준의 기술을 제공하지 않는다 하더라도 Web Service라는 업계 표준의 기술을 이용하여 처리함으로써 기술적인 문제도 용이하게 풀수가 있다. 최근 화두가 되고 있는 GRC(Governance, Risk, Compliance) 문제도 손쉽게 대응하여 프로세스상에서 발생할 수 있는 Risk 및 위험요소를 사전대응하기도 쉬운 장점이 있다.

수백 혹은수천억의 비용을 들여 구축한 ERP System을 경영진에서 나오는 질문 중 하나가 바로 “ERP 도입 후 뭐가 좋아졌는지 모르겠다”라는 우문에 가까운 질문이다. 재고의 정확성 및 실시간처리통합운영에 따른 여러 가지 Operational KPI의 수치 극대화 같은 것은 Operational Manager Level에서 좋아지는 것이고 실제 장부상의 숫자로 증명 되기는 어려운 부분이 있기 때문이다. 그래서 많은 IT 기획자나 CIO들이 Post ERP로서 BI/DW 등의 추가적인 시스템 구축을 통하여 경영진의 불만을 해결하기 위한 노력을 하고 있다. 실제 ERP는 Operation 관점의 최적화를 제공하기 때문에 경영층이 직접 접속하여 볼만한 정보는 별로 많지가 않다. 이런 부분을 해결하기 위하여 BI/DW 등에 많은 투자를 하지만 문제는 실시간적이지 않다는 데에 있다. 대부분의 BI/DW의 경우 ETL (Extraction, Transformation, Loading)의 과정을 거쳐 정보를 보여주게 되는데 ETL에 걸리는 시간이 짧게는 수 시간에서 길게는 수주까지 걸리는 문제가 발생한다. 많은 비용을 들이면 실시간정보를 손쉽게 볼 수 있다고 ERP 구축의 기안을 올린 담당자로서는 매우 위험한 상황(?)에 빠지게 되는 것이다. 또한 기업의 리스크 대응차원에서 이미 발생한 리스크를 누구나 알고 있는데 BI/DW 정보에서는 수일 혹은 수주 후에 정보를 표시하게 되면 신뢰성의 문제가 발생하는 것이다. 이런 문제를 해결하고 ERP의 효과를 극대화하기 위하여 BAM(Business Activity Monitoring)을 이용한 실시간 적인KPI Monitoring 방식이 이용되고 있다.

Oracle, SAP뿐만 아니라 대부분의 Global Package 업체들은 Event 처리방식을 System 내부에 내장하고 있다. 즉 고객생성/신용도 변경 등의 비즈니스적인 이벤트가 발생하면 처리를 위하여 Event가 자동발생하고 Event가 발생하게 됨과 동시에 등록된 Function이 자동처리 되는 메커니즘을 가지고 있는 것이다(Business Event System, Event Driven Architecture). 이러한 BES, EDA를 가진 시스템에 실시간 분석용으로 적절하지 못한 ETL이라는 시간 소요적인 방식을 사용하니 문제가 발생하는 것이다.

이에 대한 좋은 해결책은 이미 내장된 Event 발생 시 그 Event 정보를 BAM Engine에서 전달받아 실시간으로 KPI Modeling을 통하여 Push 형태로 전달하는 것이다. 혹은 프로세스 구간에서 내가 보고자하는 Task에 Software Sensor를 설치하여 프로세스가 진행되면서 센서가 설치된 구간을 지나게 되면 자동으로 해당 정보를 전달한다. 그래서 마찬가지로 BAM에서 정보를 실시간 분석하여 KPI의 변동 등을 전달하게 되면 기업의 Risk 및 KPI 등을 실시간 혹은 NRT(Near Real Time)방식으로처리 될 수가 있어 다양한 방면에서 유용하게 사용될 수 있다. Sensor 방식을 이용한 BAM은 Call Center 처리 건수 현황, 개통현황, 예/대출금 현황, 창고재고현황, 재고회전율 등 매우 여러 분야에 적용할 수 있다. 또한 기술적인 메커니즘이 Pull 방식이 아니라 Push 방식 이기에 변경되는 정보가 있으면 사용자의 액션없이 바로 화면에 Refresh 되는 장점이 있으므로 사장/회장실에 커다란 PDP/LCD TV를 통하여 기업의 핵심 KPI를 경영진에게 보여줌으로써 기대효과를 극대화하고 ERP 구축 기안을 올 렸던 담당자는 위험한 상황(?)을 모면하는 계기가 될 수도 있다.

결론

이상으로 ERP 구축 이후 통합의 가속화 및 문제점에 대한 극복방안으로써 SOA/BPM이 어떻게 적용되는 지에 대하여 설명하였다. 결론적으로 ERP 2.0이란, 통합된 Master Data를 기반으로, 비즈니스 프로세스는 BPM 기반으로 End-to-End 통합/표준화 되며, 아키텍처는 SOA 기반으로 표준화 되어, ERP & Non-ERP 영역의프로세스와 IT 인프라가 상호 유기적으로 동기화 되어 전체적으로 통합된 System을 의미한다. 따라서 사용자는 시스템에 제약을 받지 않으며, 시스템 또한 이 기종(H/W, S/W) 간의 제약에서 자유로워지게 되기 때문에 사용자는 보다 Agile한 업무 환경을 구축할 수 있게 된다.

이러한 SOA/BPM을 이용한 사용자관점, 프로세스관점의 Virtual 통합이 향후 통합의 새로운 방향이 될 것이다. 갈수록 사용자는 IT가 어떻게 구축되고 어떻게 운영되는지에 대한관심이 사라지고 있는 것이다. 즉, 내가 필요한 업무에 대한지원을 어떻게 받아서 효율적인 업무처리를 할 것 인가에 대한 관심이 높아지고 있고 IT 역시 내부의 기술적인 문제를 설명하면서 지원할 필요가 없어지게 될 것이다. 결국 내부의 효율적인 통합을 이룩하여 사용자 관점의 비즈니스 지원을 어떻게 신속하게 지원하느냐 하는 것이 가장 큰 이슈가 될 것이다. 그리고 이런 관점에서 ERP는 Back Office 중심의 업무 영역 통합과 Non-ERP 영역에 대해서는 SOA/BPM 기술을 이용하여 사용자/프로세스 관점의 통합을 시도하여 마치 하나의 거대한 시스템을 사용하는 것과 같은 통합의 효과를 제시할 것이다. 이것 이Post ERP의 IT 발전 방향이라고 생각한다.

또 다른 관점은 기업의 표준화 측면에서 ERP를 구축하면서 IT Architecture의 기술 관점의 표준화와 Business Process 관점의 표준화가 동시에 진행되어야 한다. 두 분야에 대한 표준화는 다시 Process 표준화, Master Data 통합 및 표준화, IT 표준화, Application 표준화로 나누어져 진행되어야 진정한 IT 통합 Architecture를 구현하였다고 말할 수 있다. 이에 대한 상세한 내용은 다음 호 오라클 매거진을 통해 자세하 게 설명하도록 하겠다.


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