KR20030013742A

KR20030013742A - 이벤트와 관계를 이용한 비즈니스 모델 구축 방법과 그적용 시스템

Info

Publication number: KR20030013742A
Application number: KR1020010047916A
Authority: KR
Inventors: 박헌재
Original assignee: 박헌재
Priority date: 2001-08-09
Filing date: 2001-08-09
Publication date: 2003-02-15

Abstract

이제까지 제시된 비즈니스 모델, 즉 프로세스 모델과 객체지향 모델등은 정보시대에 정보를 가공하고 분류 및 처리에 초점이 맞추어져 있어, 복합적으로 이루어지는 기업 경영(관계관리, 시나리오, 프로세스, 프로젝트, 지식)에 효과적으로 대처하지 못하는 문제점을 안고 있었다.

본 발명에서는 이벤트와 관계이론을 이용한 새로운 기업환경에 맞는 비즈니스 모델과 모델 구축에 필요한 모델 정의 그리고 5단계의 정의 단계, 속성 단계, 시나리오 단계, 커뮤니케이션과 모듈화 단계 그리고 보안 단계를 통해 모델의 구체적인 특징과 비즈니스에 적용할 수 있는 방법을 제공하게 되며, 또한 모델을 적용한 관계관리시스템과 작동 방법을 제시한다.

그리고 본 발명에서 제시하는 비즈니스 모델과 관계관리시스템이 영업과 마케팅 분야에 국한되지 않으며, 기업이 비즈니스를 수행함에 있어 모든 분야에 적용할 수 있으며, 그로 말미암아 산만한 정보시스템의 통합화와 기업의 경쟁력 강화 및 생산성 향상에 도움을 줄 수 있다.

Description

이벤트와 관계를 이용한 비즈니스 모델 구축 방법과 그 적용 시스템 {Implementation Method and Application System for Business Model based on Event and Relationship}

본 발명에서는 기존에 컴퓨터 제작과 객체지향 프로그램에서 사용하였던 이벤트라는 개념과 관계 이론(Relationship Theory)을 사용하여 객체간의 관계와 이벤트의 진화과정을 통해 비즈니스를 서술하는 비즈니스 모델의 구축 방법과 그 모델을 응용하는 시스템에 관한 것으로 2001년 6월 26일에 출원되어 계류중인 출원번호 제10-2001-0036594의 "이벤트 개념을 이용한 모듈 컨트롤 시스템"에 일부 계속된 것이다.

모델은 우리 주위의 세계를 이해하는 방법으로 경험을 통해 얻어진 지식과 이성적인 전략과 사고에 의존하며, 복잡성의 조절과 제한이 모델을 구분하는 핵이라고 말할 수 있다. 또한 모델은 현실세계의 경험과 지식을 우리가 쉽게 인지하고 차이를 구분시켜 줄 수 있으며, 또한 주위 환경에 적용시켜 지금까지 알지 못하였던 새로운 지식과 경험을 창출하는 방법으로 이미 자연과학 분야(수학, 물리, 화학), 사회과학분야(철학, 경제, 심리학, 경영)등에서 많이 사용하고 있다.

1980년대 앨빈 도플러의 "제 3의 물결"에서 멈출 수도 피할 수 없는 정보시대의 새로운 파라다임을 소개하였다. 그리고 조직간의 업무 협조와 정보 교류 등을 조직간 기능의 합으로 표시한다든가 하는 기존 모델로는 새로운 정보시대에서 맞지 않음을 알게 되었으며, 따라서 새로운 시대에 새로운 기업의 모델이 필요하듯이 기업의 비즈니스 목적과 전략을 위하여 엔드-투-엔드(end-to-end)의 프로세스 내에 조직을 구성하고 관리하는 모델을 채택하게 되었다.

기업의 생산방식은 과거 대량생산 체계에서 점차적으로 고객 니즈에 따른 다품종 소량 생산 체계로 이동하였으며, 향후 기업에서 고객관계관리(Customer Relationship Management)의 도입이 가속화됨에 따라 거의 모든 상품과 서비스가 고객 각 개인의 요구에 따른 주문 제작 방식 형태로 변경될 것으로 예측되고 있어, 현재의 프로세스 모델만으로 변화되는 새로운 기업환경에 모두 적용될 수 있을 것으로는 생각하기 힘들게 되었다.

Berry에 의한 관계 마케팅(Relationship Marketing)의 개념이 처음 소개(1983)된 이후 18년이 지난 지금 비즈니스의 모든 분야(기업 및 학계)에서 관계(Relationship)에 관한 폭 넓은 연구와 발전을 거듭한 결과 전통적인 마케팅 개념의 변화를 이룩하게 되었다.

그것은 과거 정보기술과 네트워크가 부족한 시절에는 사람의 마음속에 있는 가치판단이라고 해석하여 개인의 자질로 인식하고 기업경영에 적용하지는 못하였지만 지금은 정보 관련 인프라와 기술의 발달 그리고 지속적인 사내교육을 통하여 고객 및 직원 개개인의 행동과 사고까지 영향을 미치고 그로 말미암아 점진적인 관계경영이 실현되고 있는 실정에 있다고 말 할 수 있다.

과거 정보사회에서는 기업의 어플리케이션이 자료의 가공처리 위주이었기 때문에 주로 모든 어플리케이션의 프로그램이 데이터베이스 시스템 중심으로 개발되고 운영하였지만 점차적으로 네트워크와 기술의 발달에 따라 단순 자료 처리에서 자료를 분석하고 전략을 수립하고 시행 평가하는 방식으로 비즈니스가 변모하게 되어, 정보시스템의 개발 추이도 단순 자료 처리의 오퍼레이션에서 정보의 분석을 통한 지식의 축적과 응용으로 변모하고 있다.

기업 내부의 프로세스는 법칙(Rule)과 처리절차 그리고 관행에 의하여 정형화되어 있고 안정화되어 있는 반면에 기업 외부는 고객이나 협력업체와 접촉할 수 있는 다양한 채널, 사회/문화의 변화에 따른 개인의 의식 변화 그리고 정보통신기술의 비약적인 발전과 더불어 시장 경쟁이 증가됨에 따라 미래의 비즈니스 환경을 예측할 수 없으며, 따라서 기업이 시장에서 경쟁 우위를 지속적으로 유지하기 위한 전략과 전략을 지원하는 프로세스의 변화로 말미암아 자료를 취합하고 가공하는 시스템이 빠르면 2 년 내지 길어야 5 년밖에 존속할 수 없다는 점이다.

또한 전략에 따른 시스템 구축과 운영이라는 제약조건이외에도 고객은 지역, 민족, 국가제도에 따라 그리고 고객의 취향, 나이, 성별에 따라 다양한 방법으로 상품을 선별하며 평가하고 있어, 이러한 국가별 또는 민족별 고객 세그먼트 단위별로 요구를 수용하고 처리하기에는 지금 현재의 영업/서비스 지원 시스템으로는 한계가 있다고 할 수 있다.

따라서 기존 기업자원관리 패키지(Enterprise Resource Planning)의 업무 적용 방식과 같이 정해진 프로세스에 기업의 프로세스를 맞추는 방법 또는 기존 프로세스에 맞추어 시스템을 개발하는 방법만으로는 비즈니스 세계에서 살아남을 수 없으며, 기업은 독자적인 비즈니스 모델과 프로세스에 자유로운 시스템을 통해 경쟁사와 차별화하고 지속적으로 전략 프로세스를 개선하고 업무와 기술의 진화를 통한 변화만이 시장에서 경쟁 우위를 지속적으로 유지할 수 있게 되었다.

하지만 프로세스를 지원하는 정보시스템을 개발하거나 패키지를 도입하여 설치, 기업이 원하는 프로세스와의 갭(Gap) 차이에 따른 개발과 구축, 직원의 의식변화 그리고 관행으로 작용하였던 기업 문화를 변화시키는데 2년 이상 소요되는 기간이 가장 커다란 장애물로 작용하고 있다. 물론 과거 여러 가지 방법으로 시스템 개발 기간을 단축시키는 노력을 하였지만 커다란 성과를 얻지는 못하였는데, 이는 개발 언어, 모듈 구축 방법 그리고 시스템 적인 역학관계 만으로는 비즈니스를 지원하기에는 한계가 있으며, 결과적으로 비즈니스를 분석하고 설계하는 방법 그리고 그러한 모델을 기초로 실질적으로 적용하는 방법과 효과적으로 시스템을 구축할 수 있는 개발 언어 및 모델을 지원하는 시스템이 도입되지 않으면 해결할 수 없는 분야인 것이다.

현재 고객관계관리를 언급하고 있는 시스템들은 인터넷을 기반으로 둔 e-CRM, 영업업무자동화(Sales Force Automation)나 데이터웨어하우스를 이용한 데이터마이닝(Data Mining)처럼 기업 내부의 영업과 관련된 내부보고, 분석 등의 독립적인 기능 위주의 솔루션들로 이러한 솔루션들을 하나의 집약된 프로세스 형태로 처리하기에는 복잡하다는 점 이외에 기업의 측면에서 바라보는 고객 분석의 한쪽 면만으로는 시장의 변화와 경쟁력을 확보할 수 없다는 점이다.

따라서 고객의 관점, 경쟁사나 협력업체의 관점 그리고 시장 동향의 폭 넓은 시각에서 관계관리의 이론적으로 검증된 방법, 기업이 비즈니스를 수행하면서 축적한 지식, 고객의 의견 등의 총괄적인 근거로 시스템이 구축되어야 진정한 의미의 관계관리 시스템이라 이야기 할 수 있으며, 따라서 전 세계적으로 관계 관리를 구축하여 효과를 보는 회사는 손꼽을 정도로 얼마 되지 못하고 있는 실정이며, 대부분 이러한 기업은 자사의 경험을 토대로 고객과의 관계를 지속적으로 유지할 수 있는 독자적인 모델을 적용한 전략 프로세스에 대해 시스템을 구축하여 운영하고 있다는 점이다.

그러나 현재 이러한 시스템을 구축하기 위하여 몇 가지 해결하여야 할 숙제가 있다. 예를 들어 도 1처럼 과거 협력업체나 고객과의 관계는 상하 종속적인 관계에서 현재 도 2처럼 수평적인 관계로 발전하고 있으며, 고객과 기업, 기업과 기업 그리고 관련된 인프라스트럭쳐(Infrastructure)등 거래 유형도 복잡하게 이루어지고 있어, 특정 유형에 따라 프로세스를 규정 할 수 없다는 점과 기업과 거래하는 고객 또는 기업은 자체 특성에 따라 다른 프로세스를 유지하고 있어 기업과 기업이프로세스로 연결되지 못하고 그때 그때마다 필요한 업무 협의가 이루어지고 있다는 점이다.

본 발명에서는 전략과 전술에 의한 프로세스를 통하여 시장 경쟁에서 성공하는 방식이 아닌 시장을 구성하는 고객과 협력업체들과의 관계와 시장 변화에 대한 전략 시나리오에 따른 유기체처럼 시장 환경에 적응하는 기업의 시스템을 구축하기 위한 것이다.

본 발명은 과거 프로세스 방식처럼 일정한 패턴에 따라 업무처리가 진행되는 정적인 방법이 아니라, 이벤트를 이용하여 정보를 수집하고 기업 내부의 프로세스와 연결시키는 것은 물론이고 학계에서 검증된 관계관리(Relationship Management) 이론, 시나리오 경영, 비즈니스를 수행함으로써 축적한 지식(Knowledge) 및 기업의 전략을 기준으로 입력된 자료를 실시간으로 가공하는 것은 물론이고 그에 따른 행위에 대한 평가와 검증을 원하는 시간 내에 수행할 수 있는 시스템과 방법에 관한 것이다.

따라서 시장에 나타난 예상되는 변화, 마케팅 이론, 기업의 영업과 마케팅 전략 또는 고객 행동에 관한 지식 그리고 비즈니스 관행을 기반으로 사전에 시나리오를 구축하게 되며, 구축한 시나리오에 따라 내부 프로세스나 정보시스템을 연결하게 된다. 그리고 운영과정에서 파악하지 못한 돌발 상황이 발생되었을 경우 예측되는 해결방안의 시나리오를 작성하게 되고 그에 따라 시스템의 기능을 맞추어 짧은 기간이내에 시스템과 프로세스를 구축하는 방법을 제시하게 된다.

기업에서 관계 관리를 추구하는 궁극적인 목표는 고객 결속(Customer Bonding)이다. 고객 결속이라는 개념은 고객에게 영향을 주는 프로세스이며, 고객 충성은 그 행위의 결과이다.

기업 입장에서 고객결속은

☞ 고객을 중심으로 접점 형성,

☞ 고객 입장에서 공급업체 변경사항에 관한 장애 요인 제공,

☞ 공급자에 대한 선호도 향상을 포함한 의도적인 관계 설정을 위한 활동으로 정의 할 수 있다.

그리고 그에 대한 결과로써 고객 충성은 경쟁사의 노력, 경영환경의 변화에도 불구하고 가까운 장래에 자사의 제품과 서비스를 재 구매하고자 하는 고객의 믿음으로 충성도는 고객과 공급자간의 거래 질과 금액에 의하여 측정되어 질 수 있는 지표이다. 실 예로

☞ 거래가 되기까지 접촉의 횟수,

☞ 쇼핑 방문 횟수,

☞ 고객이 년 간 구매하는 수량/금액에 차지하는 공급자의 제품이 차지하는 수량/금액

고객 입장에서는 충성을 공급자에 대한 선호도와 긍정적인 태도, 감정과 만족 여부로 파악 할 수 있으며, 고객이 공급자로부터 다시 구매를 하는 것을 의미한다.

만족은 사람의 기대에 부응하던가 또는 초과 이루는 것으로 이는 각 개인의 경험과 지식을 기초로 한다 - Stauss 1999. 따라서 표 1의 고객결속과 고객충성의 정의와 같이 고객의 낮은 만족도와 기업의 높은 고객 결속은 지속적인 충성을 나타내지만 고객 추천이나 친근하고 긍정적인 고객 피드백은 기대할 수 없는 결과를 나타내며, 또한 높은 만족도에 비하여 낮은 고객결속은 충성에 가능성을 나타내고 있지 지속적인 거래를 유발하는 충성을 나타낸다고 볼 수 없다는 사실이다. 현실이 어떻든 고객이 피하든 또는 기업이 적극적이지 못하든 관계를 증진시키기 위한 장애물이 존재한다는 점이다.

따라서 고객 만족이 고객 충성으로 이어지지 않는다는 점이고 대부분의 고객들은 언제든지 이탈 할 수 있는 가능성 때문에, 기업이 추구하고 있는 비즈니스의 궁극적인 목표는 높은 고객 만족과 높은 고객 결속으로 파악할 수 있다.

본 발명에서는 관계 관리 시스템을 구축하기 위해서는 두 가지 개념을 기준으로 모델과 시스템을 구축하게 된다.

하나는 기업 업무와 업무 흐름을 기능과 프로세스라는 관점에서 파악하지 않고 이벤트라 표현하는 객체와 행위들로 구성된 집합체와 이벤트를 연결하여 순차적으로 또는 동시에 발생하는 이벤트의 네트워크(Network)로 파악하게 되며, 따라서 기업의 업무 흐름과 고객 행동에 대한 분석은 이벤트의 단위로 이루어지게 되며, 프로세스와 전략은 이벤트와 이벤트의 수행으로 처리한다.

그리고 이벤트내의 모듈 설계는 별도 객체별로 모아 설계하고 필요한 모듈들을 작성하게 된다. 그러나 시스템과 고객 또는 고객과 직원과 같이 객체와 객체간의 커뮤니케이션 모듈과 특정 장치를 제어하는 모듈은 필요에 따라 또는 목적에 따라 툴(Tool)과 해당 지원 언어로 개발하게 된다.

또 다른 하나는 이벤트 내에서 이루어지는 고객과 직원 또는 직원과 직원 등의 다양한 관계(예로써 고객 요구 사항과 해결 방안 그리고 직원들의 대응 행위 등)는 관계 이론(Relational Theory)을 통해 필요한 비즈니스 모델을 제시하고 모델을 중심으로 비즈니스 업무를 분석하고 설계하는 방법 및 실질적으로 모듈 개발에 필요한 원칙 그리고 직원들에 대한 필요한 교육 등과 관련된 일련의 방법 및 그와 관련된 툴(Tool)을 제시한다.

고객 결속과 고객 충성의 세부정의.

공급자	공급자와 고객간의 관계	고객
고객 결속 활동	구매 행위	태도와 의지
접점형성, 공급자 변경의 장애요인 제공, 고객 선호도	공급자와 고객사이의 상호관계,공급자와 고객의 환경	만족, 선호, 공급자 또는 공급 채널에게 다시 구매한다는 의지
고객 결속 = 더욱 밀접한 관계 설정을 위한 고객에 접근하는 활동들	고객 충성 = 특정기간동안 좋은 관계로 고객과 공급자사이의 지속적인 거래	고객 충성 = 거래에 있어 공급자에 우선적으로 배려하는 태도와 의지

도 1은 과거 기업과 협력업체 그리고 고객과의 수직적인 관계 개념도

도 2은 현재 기업과 협력업체 그리고 고객과의 수평적인 관계 개념도

도 3은 이벤트 모델을 구축하기 위한 구축 단계

도 4는 고객 라이프사이클의 5 단계

도 5는 비즈니스와 이벤트 그리고 모듈의 시스템 3 계층 구조도

도 6은 관계관리 시스템 구조도

도 7은 이벤트와 이벤트리스트 그리고 프로세스의 상태 변화도

도 8은 관계관리시스템의 에러처리 흐름도

도 9는 데이터의 분산 환경을 지원하는 방법

본 발명의 목적은 이벤트와 관계관리를 이용한 비즈니스 모델과 모델을 적용한 시스템을 제공하는데 있으며, 이 에 따른 시스템 구축에 이용하는 분산 객체간 환경은 특정 규격의 환경에 종속되지 않는다.

따라서 제시하는 모델을 이용하여 이 기종의 분산 객체간의 통신 규격인 CORBA (Common Object Request Broker Architecture)나 윈도우 환경의 DCOM (Distributed Component Object Model) 그리고 자바의 RMI(Remote Method Invocation)에서 적용할 수 있는 것은 물론이며, 또한 새로운 분산환경에서 모듈들을 사용하는 규격이 나오거나 또는 상업용으로 시스템 효율을 극대화시킬 목적으로 자사의 독자적인 규격을 적용할 수 있는 시스템을 포함하여 필요한 개념과 방법 그리고 기능을 제공하는데 있다. 본 발명에서는 별도 언급이 없을 경우 시스템에서사용하는 모듈들간의 인터페이스(Interface) 규격은 CORBA을 따르는 것으로 한다.

본 발명의 또 다른 목적은 시스템 구축하기 위하여 이벤트에 의한 비즈니스 모델(이하 "이벤트 모델"이라 한다.)이 제공하는 수학적인 이론과 관계관리 이론을 통해 비즈니스의 원인과 결과를 해석하고 또한 기업의 업무 흐름을 해석하는 메커니즘(Mechanism)을 제공하는데 있다.

본 발명의 또 다른 목적은 이벤트 모델과 관계관리 이론이 영업과 마케팅 분야에 관한 사항으로 국한되지 않으며, 생산이나 물류를 포함하여 비영리를 목적으로 하는 공공 기관, 공익 단체 또는 민간 단체 및 영리를 목적으로 하는 기업의 비즈니스 수행과 관련하여 현상을 해석하고 기업의 업무처리 및 시스템을 구축하여야 하는 모든 분야에 적용할 수 있는 방법을 제공하는데 있다.

본 발명의 또 다른 목적은 프로세스 모델과 같이 프로세스에 어플리케이션 (Application)과 데이터 그리고 조직을 맞추는 방식에서, 이벤트별로 문제를 해결하는 지식(Knowledge)과 정보를 축적하고, 전략 시나리오와 이벤트간의 인과 관계에 따라 이벤트를 연결시킴으로써 기업의 목표를 달성할 수 있는 시스템에 관한 것이다.

따라서 본 발명에서 제시하는 시스템은 영업/마케팅과 관련된 검증된 이론과과학적인 사실을 근거로 비즈니스 흐름을 시스템내의 이벤트와 이벤트의 연결로 처리하며 또한 사용자가 사용하는 단말기와 이벤트를 연결시키는 방법을 제공한다.

본 발명의 또 다른 목적은 지금까지 정보통신시스템이 데이터를 가공 처리하는 기능 위주에서 비즈니스를 직접 수행할 수 있는 주체로써 실무자에게 필요한 행동 지침을 제시하거나 실시간으로 직원들이 수행하여야 할 업무 목표 배정 및 결과에 대한 성과 측정등을 시행하는 방법을 제공하는데 있다.

본 발명의 목적, 이점과 특징은 기술 분야와 해당 업무에 종사하는 담당자들은 이해할 수 있으며, 청구범위에 의하여 실현되고 달성될 수 있다.

본 발명에 적용되는 모델을 설명하기 전에 가장 중요한 이벤트(Event)와 클러스터(Cluster)를 우선 정의하면,

이벤트(Event)란 어원적으로 중요한 사건과 행사로 시간의 개념을 포함한 객체들의 상태에 순간적인 변화를 주는 사건으로 표현한다. 따라서 기업에서의 이벤트란 고객과의 만남, 전화통화 또는 인터넷과 같은 통신 매체를 통한 의사소통, 편지, TV 광고, 뉴스 및 민원 등 이 모든 접촉을 이벤트로 표현하게 되며, 모든 업무는 이러한 이벤트의 발생과 처리에 초점이 맞추어서 진행하게 된다.

클러스터(Cluster)는 다음과 같이 정의한다.

a) 이벤트에 의하여 이루어진 동시적인 상태의 객체들로 이루어진 집합으로 그러한 집합을 클러스터(Cluster)라 부르는데, 클러스터(Cluster)는 구체적인 목적을 갖고 있는 객체들간의 관계(Relation)와 행위(Action)라는 그물(Network)속에 체계적인 구조로 모여있으며, 클러스터의 상태에서는 객체들이 안정화되어 있고, 선형적인 연산이 가능한 상태이다.

b) 클러스터 내에서는 시간이 동시적으로(Synchronous) 진행하는 것이 아니라 비 동시적으로(Asynchronous) 진행하고 따라서 정해진 시간 이내에 하나의 안정된 클러스터의 상태에서 다음 안정된 클러스터의 상태로 마치 순간 이동하는 것처럼 점프이동을 한다.

c) 시스템에서 클러스터의 상태변화는 다른 클러스터의 상태변화에 중요한 영향을 주는데 영향을 주는 시간과 속도는 의미가 없다.

또한클러스터(Cluster)를 위의 정의 a)와 별도로 다음과 같이 보조 정의(Lemma)를 할 수 있다.

a-1) 목적을 갖고 있는 객체들간의 관계와 행위를 표현하는 방법으로 객체간의 커뮤니케이션과 행위를 기준으로 관련된 동일 성격과 속성의 객체들의 집합을 클러스터라 하며, 개별 클러스터는 안정화되어 있다.

a-2) 다른 목적을 갖은 객체의 행위는 또 다른 클러스터를 구성하며 또한 객체들의 행위에 의한 클러스터 변화의 결과를 새로운 클러스터로 인식하며, 그들간의 관계와 변화를 클러스터들의 네트워크 형태로 표시할 수 있다.

여기서 레마(Lemma) a-1)의 객체간의 커뮤니케이션과 행위를 a)의 정의에 이벤트로 인식하면 된다.

결과적으로클러스터는 목적에 있어 다른 객체들과 구분되어 질 수 있고 안정화되어 있는 동시적인 상태의 객체 집합으로 정의된다. 그리고 클러스터의 속성을 이용하여 클러스터과 클러스터의 네트워크로 비즈니스와 시스템의 세계를 표현하는 것이 본 발명에서 제공하는 모델 구축 방법이라 할 것이다.

원래 객체지향모델에서는 시스템을 "현실 세계에서 발생하는 현상들을 객체(Objects), 객체들간의 관계 그리고 객체 행위의 모임으로 특성화한 집합으로 구체적인 목적을 위해 사용한다."라고 표현되어 있다. 그러나 본 발명에서는 시스템을 "클러스터들의 집합과 클러스터들간의 네트워크"로 표현한다. 또한 엔티티 (Entity)이란 "시스템 내에서 이벤트를 발생시킨 주체"로 정의한다.

하나의 이벤트는 하나 이상의 클러스터를 형성할 수 있는데, 본 발명에서는 별도 구분하지 않는다면 이벤트와 클러스터의 용어를 혼용하여 사용한다. 그리고 주의하여야 할 점은 클러스터에서 언급하고 있는 객체란 반듯이 객체지향모델에서 언급하는 객체는 아니다. 개념상으로 독립적으로 구분 할 수 있는 단위로 직원, 고객, 자동차, 정보 등을 의미하며, 또한 개별 객체는 각각의 특성에 따라 분리할 수 있다. 예를 들어 고객은 가족, 주택 보유 여부, 생활수준, 거래가 되기까지 접촉의 횟수, 쇼핑 방문 횟수, 고객이 년 간 구매하는 수량/금액에 차지하는 공급자의 제품이 차지하는 수량/금액 또한 가장 쉬운 방법은 개개인을 식별할 수 있는 주민등록번호와 사회보장번호가 있다. 더불어 이벤트라는 개념은 일반적으로 시스템과 객체지향모듈에서 사용하는 이벤트란 용어와 개념상에 차이점이 있을 수 있으며, 이는 비즈니스에서 적절하게 사용하는 용어가 없기 때문이다.

우리 몸은 아미노산과 DNA와 같은 분자로 구성되어 있다고 할 수 있는데 야구공이나 축구공으로 몸에 맞았을 때 맞은 자료는 멍이 들지만 몸 전체로 아픔을 느끼게 된다. 따라서 현실 세계의 객체와 객체와의 관계를 본 발명에서는 클러스터와 클러스터의 관계로 해석하게 된다.

더 구체적으로 객체에 대하여 언급하면 클러스터 정의에서 제시하는 객체는 크게 비즈니스를 수행하는 주체를 언급한다. 그리고 비즈니스를 수행하기 위하여필요한 수단 또는 비즈니스의 주체간의 관계를 형성하는 수단으로 사용하는 도구로써의 객체(전화, 서류, 인터넷, ...)에 대해서는 본 발명의 시스템이 제어하는 범위 내에서 정보 시스템을 하나의 비즈니스 주체로 인식하여 처리하며 개별 객체로 구분하지 않는다. 따라서 정의와 속성 단계에서 별도 객체로 구분하지는 않으나 정보 시스템의 기능적인 요건으로 구분하게 되며, 정보 시스템으로 개발하는 모듈화 단계에는 클러스터와 관련된 비용(Cost)과 수행속도(Time)를 고려하여 별도 개발의 객체로 구분하여 처리한다.

이벤트와 클러스터에 관하여 다시 언급한다면, 클러스터를 구성하는 객체가 다르면 다른 클러스터로 인식할 뿐만 아니라, 같은 객체들로 이루어진 클러스터라 하더라도 목적이 다르다면, 다른 클러스터로 인식하게 된다. 그러나 현실세계에서는 특정 이벤트들에 따라 상세하게 객체를 구분하는 지 않는다. 즉, 캠페인 작업은 사전에 준비하고 이행하는 과정에서 같은 조건과 같은 제품 선호도를 갖고 있는 고객을 대상으로 타깃 고객(Target Customer)을 선정하므로 이벤트 모델에서는 각 개별 객체로 구분할 수 없어 같은 고객으로 인식하게 된다, 또는 고객 세그먼트로 고객을 분류하여 작업하는 활동과 행위도 같은 고객으로 인식한다. 또한 같은 업무를 수행하는 직원이 인수인계 없이 업무를 진행할 수 있다면 같은 객체로 인식하게 된다. 그리고 같은 목적을 갖고 같은 사람들의 만남은 시간 경과에 따라 다른 클러스터로 변화하는데, 비즈니스는 이벤트에서 다른 이벤트로 진화 또는 이동하는 과정에서 가치가 창출되어야 한다는 점이다. 따라서 비즈니스를 수행하고자 하는 목적과 다른 친목이나 직원들간의 회식 등은 비즈니스의 클러스터로 인식하지 않는다는 점이고, 또한 한 장소에서 사람들이 하나의 정해진 주제에 대한 연구개발과 같은 목적을 갖고 근무 하다면 아무리 오랜 시간(여기서 출퇴근은 근무의 연장으로 파악)이 경과하더라도 목적과 객체가 변화하지 않으므로 하나의 이벤트와 클러스터로 인식된다. 그리고 앞에서 서술한 이벤트와 클러스터에 비즈니스 이론과 실무가 적용 되었을때 비로소 비즈니스 모델이 되게 된다.

기업에서 추구하는 영업과 마케팅은 고객과 거래를 성립하기 위한 관계 설정을 목표로 하고 있다고 말씀드릴 수 있고, 고객과의 관계에 놓여 있는 상태에서 발생한 이벤트는 고객에게 영향을 주고 따라서 영향을 받은 고객은 다음 이벤트를 발생시키게 된다. 이미 마케팅에서 알려져 있는 사실 즉,

☞ 영업 활동은 고객에게 직접 또는 간접적인 제품 구매에 영향을 준다는 점과

☞ 제품 브랜드 이미지, 기업 마케팅 활동 그리고 고객의 긍정적인 발언

이 상품/서비스 판매에 영향을 준다는 점과 일치한다.

위와 같은 관계 형성 과정을 수학적인 논리로 표현한다면 다음과 같다.

클러스터를 구성하는 객체가 같다면 클러스터의 상태 변화는 객체의 함수로표시할 수 있는데, t 시간의 클러스터 상태(S_t)에서 t+dt 시간에 내부 또는 외부 이벤트에 의해 발생한 클러스터 상태(S_t+dt)는 St 상태의 객체들간의 역학관계 및 객체들간 관련 행위(Action) 그리고 다른 이벤트에서 주는 영향을 통한 내부 객체의 변화(D)로 표시할 수 있다.

S_t+dt= f(S_t, D, d_t) 와 D = ∑w_iC_i

( w_i: 비중, C_i: 다른 클러스터와 관련된 함수)

결과적으로 클러스터의 상태 변화(같은 객체로 구성된 클러스터가 시간이 진행됨에 따라 변화하여 다른 클러스터가 된 상태)는 클러스터내의 객체들간에 주고, 받는 관계의 함수와 다른 이벤트에 의하여 발생한 외부 클러스터가 주는 영향을 받은 내부 객체의 변화가 주원인이라는 점이다. 따라서 현실세계에서 모든 관리의 초점은 객체, 특히 엔티티에게 직접/간접적으로 영향을 주는 클러스터 관리와 클러스터 내의 엔티티와 객체들에게 직접적으로 영향을 미치는 객체의 관리로 귀착될 수 있으며, 객체간의 관계 발전은 새로운 클러스터의 발생을 의미하게 된다.

그리고 D는 기업 내부의 클러스터(w_iC_i)와 기업 외부의 클러스터(w_jC_j)로 구분할 수 있으며, 여기서 기업 외부의 클러스터는 기업에서 관리하는 객체(직원, 정보시스템, 기기 등)가 전혀 포함되지 않으므로 관리차원에서 무시하게 된다. 여기서 관리할 수 있다면 물론 포함하여야 한다.

클러스터 A의 상태에서 C의 상태로 가기 위한 방법에 있어,

함수 f : A -> B 와 함수 g : B -> C의 합인 f+g : A -> C 와

함수 h : A -> C는 결과적으로 같은 결과를 낳는다.

h = f+g

참고 : + 는 순차적으로 발생하는 상태 변화의 연산자 또는 함수

또한 일반적으로 소요되는 클러스터의 상태 변화에 따른 시간과 비용의 함수가 T라 하면,

T(f+g) = T(f)+T(g) ≥T(h)가 된다.

이는 클러스터의 상태 변화의 단계가 2 단계 보다 1 단계가 적은 비용과 시간이 소요됨을 의미한다. 그리고 상태 변화의 함수와 다른 시간과 비용의 함수인 T는 추후 일반적인 클러스터의 모듈보다 조건 클러스터로 사용하게 되는데, 이는 클러스터의 목적이 가치 창조나 클러스터의 상태 변화가 아닌 조건 파악하여 다른 클러스터를 선택하는 기능을 갖고 있기 때문에 다른 일반 기능의 모듈과 구분되는 특성이 있다.

이때 상태 변화의 소요되는 시간(t)이 거의 같고 | T(f+g)-T(h) | << T(h) or T(f+g)이거나 A 와 B의 이벤트 객체가 같다면 T(f+g) ≒ T(h)라고 고려하여도 무방할 것이다. 즉, 소모되는 리소스와 시간 차이는 무시할 수 있다.

또한 앞에서 설명한 마케팅에서 알려져 있는 사실과 클러스터의 정의 c)에 의하여 첫 번째 접촉(i=1)이 이루어지는 순간(불특정 고객이 우연이 찾아오는 경우)을 제외하고 엔티티에 의해 현재 발생한 이벤트(i > 1)는 각각 이벤트의 비중이 다를 수 있지만, 엔티티와 관계가 있는 과거의 모든 이벤트 집합의 결과 또는 합으로 표시할 수 있다. 이는 앞서 마케팅과 영업의 결과로써 다음의 이벤트가 발생한다는 의미로 해석하면 될 것이다.

S_i= ∑w_i-1f(S_i-1) ( i : 접촉 횟수, f : 클러스터와 관련된 함수 )

따라서 현재 엔티티와 접점을 이루어진 상태인 클러스터는 엔티티의 요구 사항에 대하여 사전에 접촉하여 얻은 정보와 지식 그리고 객체간의 관계와 행위에 의하여 각각의 객체가 원하는 결과를 얻을 수 있다는 이야기가 되며, 각각 객체의 정보와 지식은 각 객체별로 기록 보관하게 되며, 클러스터의 요구에 따라서 객체의 정보를 제공하게 된다.

본 발명에서는클러스터간의 정보 교류에 있어 세 가지 방안이 제공된다.

a) 이벤트에 의한 클러스터 내 객체간의 작업을 의뢰에 따른 직접 정보 제공이며,

b) 클러스터에 존재하는 인터페이스 파일을 사용하여 다른 클러스터에 정보를 제공하는 방법으로 주로 배치 작업의 속성이 있는 클러스터와 인터페이스 할 경우 사용하며,

c) 클러스터 내 소속된 객체들의 정보와 지식의 축적과 공유을 통한 간접 정보를 제공하게 된다.

현실세계에서의 문제점은 객체에 따라 다양한 형태의 이벤트가 나타난다는 점이다. 따라서 관계 마케팅과 같은 경영이론들은 이러한 함수의 방정식을 풀기 위한 방법이라고 말씀드릴 수 있으며, 또한 결정적인 이벤트 또는 핵심 이벤트에 의한 통계적인 방법과 기업의 지식을 기초로 함수(Algebra)의 해석 없이 다음 이벤트를 예측하거나 필요한 관리를 할 수 있다고 말씀드릴 수 있을 것이다.

엔티티에 의해서 발생한 이벤트에 대하여 부가적으로 발생한 이벤트를 서브이벤트(Subevent)라 표현한다. 이는 이벤트에 대하여 클러스터 자체로 해결하지 못하는 업무의 경우 다른 조직에 필요한 협조 요청을 하게 되고 그 과정에서 발생하는 이벤트 또는 이벤트의 발생에 따라 통계적인 일정시간이 지나면 발생할 수 있을 것으로 예측되는 이벤트를 위한 사전 준비 성격의 이벤트 그리고 실제 작업 이외의 특정 목적의 이벤트를 의미하게 된다. 물론 캠페인 프로그램처럼

☞ 기업 내에서 특정고객을 대상으로 신상품의 홍보 목적으로 하는 상품설명의 자료 송부와

☞ 신상품의 캠페인 이후 전화로 유사 상품을 문의한 신규고객에 대해 신상품의 홍보 및 상품 설명을 위한 자료 송부는

규모의 차이가 있지 접근방법은 동일하므로 이벤트는 서브이벤트가 될 수도 있다는 점이다.

이벤트 모델을 이용하여 시스템을 구성할 경우 고객, 협력업체 그리고 기업의 직원은 물론 송장, 제품 등도 각각 객체로 인식하고 그들간의 요구사항에 따른 이벤트를 발주(고객->기업) : 고객이 기업에 요구하여 발생한 이벤트, 계약(고객<->기업) : 고객과 기업이 상호 약속에 의하여 이루어지는 이벤트와 같은 표기 방식으로 정의하게 되며, 이벤트에 의하여 유발된 프로세스에 대한 완료 이벤트도 배달(기업->고객)과 같은 방식(->,<->)으로 표기하게 된다. 그리고 기업내부의 조직과 시스템에 따라 계약검토(영업->관리)등과 같이 서브 이벤트로 세분화시키게되며, 궁극적인 목표는 최초 이벤트를 발생시킨 엔티티에 초점이 맞추어지게 된다.

이벤트의 관점에서 비즈니스를 파악하는 방법은 객체의 관점에서 엔티티의 변화관리와 그 과정(엔티티와 객체간의 상호 작용)상 가치 창조가 주 관심 대상이라면 프로세스의 관점에서 비즈니스를 파악하는 방법(이하 "프로세스 모델"이라 한다.)은 객체의 구분과 행위를 무시한 엔티티(여기서는 상품, 정보를 의미한다)의 흐름을 기준으로 엔티티에 가치를 부여하는 활동이 주요 관심 사항이라 할 수 있다.

이벤트 모델에서 프로세스처럼 다른 클러스터의 영향을 무시하고 오로지 클러스터에 직접적으로 영향을 주는 이벤트를 중심으로 클러스터에 의한 가치부여만을 고려할 경우 f : S_t-> S_t+dt또는 f(S_t)로 표시할 수 있으며, 이 때 현재 클러스터의 S_t상태에서 클러스터를 구성하는 객체와 객체간의 행위 그리고 객체간의 커뮤니케이션에 의하여 다양한 결과(S_t+dt)가 나타난다고 말할 수 있으며, 프로세스 모델에서 이야기하는 관리란 객체간의 행위와 커뮤니케이션을 정형화하여 일정 수준의 결과를 낳기 위한 작업이라고 할 수 있다.

그러므로 현재의 프로세스는 이벤트의 흐름을 빠르게 하는 엔티티(정보)의 시스템 구축, 프로세스 향상, 직원의 교육, 사무 자동화와 같은 분야에 중점 투자가 이루어진다고 할 수 있으며 그로 인하여 프로세스는 수익을 높이기 위하여 같은 이벤트와 같은 유형의 고객 세그먼트 그리고 교육을 통한 같은 유형의 직원 등을 만드는 방법으로 한정된 이벤트에 의하여 유발된 클러스터의 비용을 최소화하는데 중점을 두고 있다고 할 수 있다.

이벤트의 객체와 행위는 프로세스 모델의 데이터와 활동으로 원투원 매핑(One-To-One Mapping)이 가능하고 또한 객체의 변화가 작고 엔티티 관점에서 발생되는 이벤트가 한정시킬 수 있어 이벤트 모델이든 프로세스 모델이든 비즈니스 수행에 별반 차이가 없어지게 된다. 따라서 상대적으로 초기 개발비용이 많이 발생하지만 유지보수 비용이 적은 이벤트 모델보다 모델 개념이 간단하며 초기 개발비용이 적지만 프로세스 변화에 대한 유지보수 비용이 높은 비즈니스 모델을 선호하게 된다.

예를 들어 독점기업의 경우 고객의 선택은 사용하거나 사용하지 않거나 두 가지 선택의 권리밖에 주어지지 않는다. 따라서 기업은 고객 차별화와 같은 마케팅은 관심이 없고 전체 비용 절감을 통한 상품가격 하락 등의 오로지 다른 기업이 시장에 진입하지 못하도록 하는 진입장벽에만 관심을 갖게 된다. 그러므로 이러한 기업의 전산화는 프로세스 모델을 이용하여 원가절감이 가능한 대규모 업무에 대한 전산화 작업을 지향하게 되는 것이다.

몇 가지 제한된 조건으로 이벤트 모델을 프로세스 모델과 같은 형태로 만드는 방법에 대하여 설명하였지만 현실적으로 두 모델사이의 인테그레이션의 고려를 할 경우 객체의 상태가 변화하더라도 특정 시점에 발생한 이벤트에 대해

☞ 클러스터 내 객체가 수행하는 행위와 프로세스 모델을 구성하는 기능의 활동이 일치하고

☞ 클러스터 내 데이터 요건과 프로세스 모델의 데이터 요건이 맞는 상황이 되었을 때

이벤트에 의하여 프로세스 모델에 필요한 자료와 기능을 제공할 수 있게 된다.

객체의 변화가 크다 할지라도 이벤트의 관점에서는 프로세스 모델은 정적인 상태이므로 이벤트 모델에서 필요로 하는 자료는 어떠한 조건에서도 프로세스 모델이 갖고 있는 기능과 자료에 대한 인테그레이션이 가능하다. 즉, 모든 시스템이 정지되어 있는 상태를 제외하고 실시간으로 작업을 할 경우에는 이벤트가 주체가 되어 인터그레이션(Integration)이 가능하게 된다.

예를 들어 기업에서 사용하는 고객정보에 관하여 이야기하여 보자.

프로세스 모델의 고객정보는 주어진 형태(Format)에 따라 데이터베이스 내에 관계(Relation)형태로 정보를 갖고 있다고 할 수 있다. 그리고 이벤트 모델에서 사용하는 고객정보는 프로세스 모델에서 보관하는 고객정보를 언제 어느 장소에서도 조회와 수정이 가능하지만 이벤트 모델 내에 있는 고객정보는 자체로는 정보지만 프로세스 모델에서 사용하기에는 불완전한 정보로 프로세스 모델에서 인터페이스 하여 사용할 수 없고 이벤트의 진화과정을 통해 프로세스에서 요구하는 완전한 자료가 되었을 때 인터페이스를 담당하는 서브 이벤트에 의하여 프로세스 모델에 자료를 제공하여 줄 수 있게 된다.

은행업무의 예를 보면, 인터넷에 가입한 고객정보 또는 통장 개설에 따른 고객정보만으로는 신용카드 발급이나 신용 대출 또는 담보 대출과 같이 고객과 신뢰의 단계가 높은 업무에서 사용하기에는 정보의 신뢰성과 업무의 성격상 필요한 정보가 부족하다. 그리고 그러한 자료를 활용하였을 경우 프로그램이 대출 목적에 따라 정상적으로 입력된 자료와 그렇지 못한 자료를 구분하기 힘들고 따라서 시스템의 오류를 방지하기 위하여 기존 프로세스 모델에서는 별도 프로세스로 처리하게 되며, 각 각 별도 정보를 유지하게 되고 필요한 자료는 EAI라는 툴을 사용할 수밖에 없는 실정이 되지만, 이벤트 모델에서는 고객이라는 엔티티와 객체의 변화 관리가 주안점으로 고객 정보는 개별 데이터베이스와 모듈에 의하여 인터넷에 가입한 정보와 신용카드 발급에 따라 추가되는 정보, 대출에 사용한 모든 정보를 관리하고 보관하게 되고, 그 이외에 신용 불량자 여부, 고객 통장의 년 평균 잔고와 월 평균 홈뱅킹 사용 현황만으로 신용카드를 발급이 가능한지 체크가 가능하며, 또한 본인임을 확인할 수 있는 주민등록증의 제시와 소유 구좌의 패스워드 확인으로 즉시 발급이 이루어질 수 있게 된다.

시스템은 각 모델의 특성에 따라 구축된다고 할 수 있다. 예를 들어 프로세스 모델에서는 시스템의 작업 방법이 정보의 흐름에 주안점을 둔 프로세스 형태로 만들어지며, 또한 선형 대수학의 이론을 모델로 적용한 관계형 데이터베이스는 정보를 행과 열의 테이블과 연산으로 표시하게 된다. 따라서 관계관리 시스템이 효율적으로 작동하기 위해서는 기존의 프로세스 모델로는 논리적으로 설명하기가 곤란하고 또한 복잡하여 시스템 구축이 사실상 불가능하므로 이벤트 개념을 기초로 비즈니스 모델을 수립하여야 한다.

따라서 본 발명에서는 시스템의 구성요소와 적용 방법에 관하여 설명하기 이전에 도 3과 같이 단계별로 이벤트 모델의 특성과 구축에 관하여 방법을 서술하도록 한다.

첫 번째 단계로이벤트 정의(31)작업

시스템으로 구축하는데 가장 커다란 어려움으로 현실세계에서 이루어지고 있는 이벤트의 수가 거의 무한대에 가깝다는 것이고 그에 따른 이벤트의 분류와 속성을 파악하는 것도 상당히 어려운 작업이다. 따라서 비즈니스 세계에서 발생되는 모든 이벤트를 파악하여 비즈니스 전략과 연계시키는 것이 아니라, 관계를 이루는 객체들의 관점에서 상호 접점이 되는 이벤트를 파악하고, 비즈니스 전략과 연계하거나 유사한 속성을 갖고 있는 이벤트들을 묶어 하나의 표준 이벤트로 만드는 방법을 취하게 된다.

본 발명에서 이벤트 모델을 구축하기 위하여 2가지 관계이론의 관점에서 접근하게 되는데, 하나는 행동관점(Behavioral perspective)에서 고객 유지 (Retention), 신뢰(Trust)와 만족(Satisfaction)을 위한 프로세스의 구축 및 개선을 목표로 고객의 행동과 조직 내부와의 관계 정립에 주안점을 두며, 또 다른 하나는 네트워크 관점(Network perspective)에서 기업/기업/고객간의 상호연관 관계와 의존 및 사회와 관계 네트워크에서 기업의 역할을 중심으로 접근하게 되는데 주로 신제품 개발에 필요한 공동 연구 개발과 고객 클럽을 통한 고객과 기업의 상호 신뢰 증진 및 협력 또는 기업 수익의 사회 환원 등이 주요 대상이 된다.

그리고 이벤트를 정의하기 위해서는 각각의 객체 입장에서 파악하게 되는데, 본 발명에서는 관계 이론의 관점을 기준으로 마케팅과 영업의 이벤트를 구성하는 4가지 주요 관점에서 파악하게 된다.

따라서 고객의 행동에 주안점을 두는 고객의 시각, 이벤트로 말미암아 발생되는 기업 리소스(Resource)를 관리하여야 하는 리소스의 시각(프로세스나 원가) 및 이벤트를 연결시키게 되는 방법과 이벤트 내의 객체와 객체간의 정보 전달 방법에 의한 기술의 시각 그리고 시장에서 경쟁 우위를 점하기 위한 전략과 고객의 마음을 사로잡기 위해 이벤트를 유발하는 직원이나 협력업체의 입장인 기업의 시각(Company View)에 따라 이벤트를 정의하게 된다.,

고객관점(Customer View)에서는 고객과 기업의 거래형태와 유형에 의한 이벤트를 고객의 관점에서 정의하는 방법으로 사회 과학과 사회 통계적으로 도출된 자료(소비자 심리 자료, 검증된 연구논문), 회사에 축적된 지식을 토대로 또는 고객 세그먼트와 고객의 라이프사이클에 따라 발생하는 이벤트를 정의하게 되며, 고객과 기업의 관계 발전 단계별 원하는 니즈(Needs)에 따라 기업에서 제공할 수 있는 상품/서비스라는 리소스를 고객이 원하는 시간 내에 제공하게 된다.

고객과 접촉하거나 또는 거래하는 과정에서 고객의 라이프사이클의 시작과 완료까지 맞춘 정보에 따라 시스템에서 단계별로 고객이 요구하는 인-바운드(In-Bound) 이벤트와 기업에서 고객 충성도 향상과 고객 유지이라는 목표를 위하여 고객과 협력업체에게 아웃-바운드(Out-Bound) 이벤트를 제공하게 된다. 이 때 시스템에서는 담당자에게 작업에 필요한 정보와 행위에 대한 방법(업무 수행과 관련된 매뉴얼 또는 정보를 입력하는 자료 포맵 형태)을 제공하게 된다.

따라서 고객관계관리의 궁극적인 목표인 고객 개개인별 개인화가 이룩될 수 있으며, 고객에게 발생한 이벤트에 대하여 기업은 이전의 유사한 고객의 경험을 토대로 필요한 컨설팅 업무까지 수행할 수 있는 단계가 될 수 있으며, 고객과 더욱 가깝게 접근할 수 있게 된다.

은행의 업무를 예를 들어 보면 정상적인 고객이 대출을 하는 시점은 크게 주택을 구입하는 경우, 또는 사업 자금이 필요한 경우 그리고 자녀가 결혼을 하는 경우로 물론 이들 경우라 하더라도 고객은 대출 상품에 대하여 이자율 그리고 대출기간 파악하고 가장 좋은 조건을 제공하는 은행에서 대출을 받게 될 것이다. 이 때 다른 은행과 차별화를 할 수 있는 방법은 은행마다 유사한 대출 상품에 있는 것이 아니라 고객의 판단에 영향을 주는 내용 즉, 고객이 지속적으로 은행과 거래함으로써 얻을 수 있는 이점과 다른 은행에서 제공되지 않는 서비스 그리고 대출업무를 수행하는 직원의 컨설팅 능력에 있다고 할 수 있다.

관계 설정의 5단계(보통 라이프사이클이라 표현한다.)

관계라는 개념의 속성은 정적인 것이 아니라, 관계를 형성하고 있는 파트너간의 활동에 따라 변경될 수 있는 역동적인 것으로 간주하는데 일반적으로 아래와 같이 5단계의 진행과정을 거치는 것으로 파악하고 있다.

① 인지(Awareness)

② 탐색(Exploration)

③ 확대(Expansion)

④ 이행(Commitment)

⑤ 해체(Dissolution)

고객들은 회사를 우선 파악한 후 그 회사와 거래에 대한 기대 또는 이익을 조사하게 되며, 경우에 따라 시험버전을 갖고 원하는 결과가 나오는지 시험을 수행할 수 있다.

첫 거래 후 거래에 관한 기대가 만족할 만한 수준인 경우 지속적으로 거래를 확대하게 되며, 필요한 상품의 공동 개발하거나 제품 검사가 없는 이행 상태에 도달하게 된다. 그러나 시간이 지남에 따라 여러 가지 이유에서 거래를 중단(상품 공급 업체를 다른 회사로 바꾸거나 또는 시장에 상품 공급을 중단하는 경우)할 수 있다.

리소스 관점(Resource View)에서는 고객과 기업의 거래 형태와 유형에 의한 이벤트를 제공되는 리소스 관점(직원, 장비, 부대 비용등)에서 정의하는 방법으로 이벤트와 관련하여 소모되는 리소스를 파악하게 되는데, 보다 중요한 것은 리소스의 사용은 기업 내부의 프로세스와 연관되어 업무 처리가 이루어진다는 점이다.

현업에서 발생되는 이벤트는 리소스(Resource)를 제공하면서 복합적인 프로세스로 연결이 되어

☞ 발생되는 이벤트에 대하여 속성에 따라

☞ 조직과 위치에 따라

여러 가지 이벤트로 구분할 수 있다. 그리고 기업에서는 이벤트에 대응하여 작업을 수행하고 필요한 결과를 산출하기 위하여 의식적으로 아니면 무의식적으로 하나 하나의 서브 이벤트를 수행하게 되는데, 이 과정에서 기업이 원하는 목표를 달성하게 된다.

영업직원의 비용과 같이 소모성 경비를 제외하고 기업의 리소스를 직접 이용하는 이벤트를 핵심 이벤트라 하는데, 핵심 이벤트의 예는 견적, 발주와 같이 기업의 프로세스를 유발시키는 이벤트를 의미한다. 그리고 핵심 이벤트를 제외한 이벤트는 속성상 핵심 이벤트로 진행하는 과정에서 발생하는 이벤트들로 기업 입장에 하나의 목표를 달성하기 위한 추적 관리, 일정 관리, 고객의 라이프사이클에 따른 분석 자료 활용 및 거시적인 마케팅 목표(고객별 라이프사이클 단계별 목표) 또는 영업의 계약 및 수주를 위한 파이프라인 분석과 기회 분석 및 업무 처리 지침을 위한 자료 형태로 이벤트를 기록 보관하게 된다.

프로세스와 연결되고 영업 목적의 분석이외에 담당자가 이벤트를 수행함으로써 활동기준원가 시스템에 담당자가 수행한 활동 내역의 제공이 필요하며, 담당자의 이벤트 수행에 따른 결과에 대한 성과측정 및 관련 기관에 필요한 업무 협조를 얻기 위한 정보 제공 그리고 고객과 협력업체에게 공급하는 상품과 서비스의 가치평가와 분석, 프로세스의 처리속도 및 관련 비용, 기업 내부에서 처리하여야 할 사무자동화 방향과 방법 및 업무분석을 위한 자료(원가나 현금흐름 또는 자산에 대한 활용)등을 자동으로 제공할 수 있다.

기술 관점은 크게 두 가지 관점에서 접근하는데, 첫 번째 시스템도 이벤트를 구성하는 하나의 객체로 인식하고 있기 때문에 이벤트 발생과 더불어 시스템이 고객 또는 직원에게 제공하는 서비스를 파악하여야 한다는 점과 두 번째 실제 업무에 대하여 이벤트를 구분하는 것보다 시스템으로 구현하기 위하여 개념적으로 필요한 이벤트를 규정하는데 그 목적이 있다.

따라서 정보통신기술의 발달에 따라 객체와 객체(고객과 고객, 고객과 기업, 기업과 기업)를 연결하고 필요한 커뮤니케이션의 툴(Tool) 및 방법과 시스템에 의하여 발생한 이벤트를 통한 정보 전달에 관한 방안을 제공한다.

그리고 이 단계의 기술관점에서 고려하여야 할 사항은 아니지만 정보통신과 같은 기술의 발달(예를 들어 클라이언트/서버, 인터넷, 무선 인터넷, HTML, XML, JAVA, 전화 서비스)에 따라 지속적으로 시스템이 도입되고 별도 개발하여야 하는 방식을 지양하게 되는데, 따라서 통신기술은 고객과 기업, 기업과 기업 간을 연결시키는 단순한 통신 매체로 별도 구분하여 처리한다는 점이다.

기업 관점은 고객 정보(거래내역, 전화내용, 요청사항 및 불만사항, 구매 내역 그리고 거래선의 채권/채무 관계 등의 자료)를 활용하여 분석/평가 등을 통해 얻은 지식을 활용하여, 홍보 및 자사의 상품과 서비스에 맞는 고객(Lead)을 선발하고 그에 따른 캠페인 활동을 수행하는 것과 관련된 이벤트들과 고객별 신용등급 평가, 기만 및 사기, 그리고 지식축적과 지식 활용에 관련된 이벤트들로 구성된다.

참고로 분석과 개발과 관련된 이벤트들은 객체들의 변화 없이, 조직 내부의 기획을 통해 분석 및 일정계획 등 기능적인 성격이 강하게 나타나는 특징이 있어, 시스템 개발시 별도 시스템 또는 하나의 이벤트로 구분하게 된다.

이벤트 분류 작업 시 주위 하여야 할 점은 이벤트는 물리적으로는 연결되어 있다하더라도 각기 개념적으로 독립적인 속성과 특징을 갖고 있어야 한다는 점과 4가지 관점에서 분류할 수 있는 최소 단위로 나누어 관점에 따른 충돌 없이 이벤트의 조합으로 관점이 요구하는 이벤트의 형태로 이루어진다. 또한 별도 기업의 관리 목적에 따라 특정 카테고리(Category)로 이벤트들을 분류할 수 있으며 또는 실험과 분석 목적으로 따로 이벤트를 분류할 수 있는데 이때 다른 이벤트와 중복되지 않도록 처리하여야 한다.

그리고 이벤트의 정의에서 또 다른 중요한 사항은 이벤트를 구성하고 있는 각각의 객체에 따른 기능, 데이터 및 목적을 달성하고자 하는 행위 등 필요한 요건을 정의하여야 한다. 즉, 이벤트를 이루는 집합에서 엔티티가 요구하는 사항에 대하여 문제를 해결하고자 할 때 사전에 비즈니스를 수행하는 객체들이 갖추어야 하는 지식 수준을 위해 필요한 작업을 시행하여야 한다. 즉, 직원들은 이벤트를 해결하기 위하여 실제 업무 추진에 필요한 지식을 습득하고자 필요한 교육을 받아야하고, 개발자는 해당 이벤트에 대한 작업 매뉴얼을 작성하게 되고, 또한 시스템은 직원, 고객, 협력업체에 업무 추진에 필요한 정보와 제공하여야 할 기능과 구체적인 방법을 고려하게 되며, 그리고 고객이 이벤트를 발생시킬 수 있도록 기업은 홍보와 마케팅을 사용하여 고객에 대한 잠재적인 교육을 시행하여야 한다.

이벤트 모델을 수립하기 위한 두 번째 단계로이벤트의 속성과이벤트 분류(32)

이벤트를 세분화하여 속성을 파악하는 것은 관계관리시스템이 전산 적으로 처리하여야 할 작업에만 국한하는 것이 아니라 필요에 따라 담당자에게 e-mail을 통하여 또는 담당자의 게시판 형태로 필요한 행동지침은 물론 작업 목표를 할당하는 일과 필요한 지침과 관련된 정보를 제공하는 일은 물론 객체의 퍼포먼스를 체크하는 일까지 수행하기 때문이다. 이는 시스템이 이벤트 모델의 객체로 존재한다는 점과 이벤트에 의하여 소모되는 두 가지 리소스(시간과 비용) 때문인데, 하나는 고객이 요구한 사항은 고객만족의 시간 범위 내에서 이루어져야 한다는 점, 따라서 고객과 약속한 사항은 담당자의 스케줄 관리에서 관리하고 예정시간을 이-메일, 작업화면 또는 다른 방법으로 표시하여야 하며, 또 다른 하나는 고객에게 제공되는 이벤트에 따라 서비스의 질이 다르기 때문이다. 예를 들어 이벤트가 ATM 장비, 인터넷처럼 기계가 주체가 되는 경우와 고객 담당 직원이 직접 고객 사이트를 방문하여 상담하는 것은 같은 목적이라도 비용과 효과에 있어 엄청난 차이가 있을 뿐만 아니라, 기계적으로 수행하는 것은 필요한 제어와 관련된 모듈의 개발이 필요하고 사람이 수행하기 위해서는 필요한 정보와 작업 지침서가 있어야 하기 때문이다.

이벤트 모델에서는 이벤트들간의 영향력과 결과 이외에 시간을 하나의 차원으로 이벤트의 발생과 소멸 그리고 이벤트를 해결하는데 걸리는 평균 시간 및 최대 시간 등을 평가지표로 활용하게 된다. 따라서 기존에는 개인의 능력에 따라 맡겨진 영업 활동이 시스템에서 제공하는 템플리트(Template)에 맞춘 작업으로 바뀔 수 있다는 이야기가 된다.

클러스터의 속성에 따른 클러스터 구분

이벤트 속성	구분
비용	비용에 따른 이벤트
작업 과정	시작, 중간 작업, 완료의 속성에 따른 이벤트
시간	시간적인 변수를 가지는 이벤트
시간	일반적인 정적인 상태에 관한 이벤트
작업의 주체	직원 및 협력업체 직원이 수행 주체
	기계가 수행 주체
	전산 시스템이 수행 주체
처리 방법	엔티티의 요구를 대처하는 수동적인 이벤트
	엔티티에 영향을 주는 능동적인 이벤트
	내부 관리 이벤트
	조건 이벤트

고객이라는 엔티티는 다른 객체와 다르게 시스템의 내부와 외부를 오가는 객체로 이벤트를 유발하는 핵심요소이며 클러스터 영역(Boundary)의 외각에 위치하게 된다. 그리고 엔티티를 제외한 클러스터 내의 객체 관점에서 엔티티의 요구사항을 처리하기 위하여 다음과 같이 구분되어 질 수 있다.

☞ 엔티티의 요구를 대처하여야 할 수동적인 이벤트(고객이 엔티티인 경우는 인-바운드 이벤트라 부름)

☞ 기업이 전략적으로 수행하여 엔티티에 영향을 주고자 하는 능동적인 이벤트(고객이 엔티티인 경우는 아웃-바운드 이벤트라 부름)

☞ 내부 관리 이벤트

☞ 조건 이벤트로 나누어 질 수 있다.

수동적인 이벤트는 담당자가 고객 상담, 업무 협의, 계약 체결, 고객 불만접수 등의 이벤트를 통해 처리하는 가장 기본적인 내용이 위주가 된다.

능동적인 이벤트는 주로 오퍼레이션 레벨에서 기본적으로 처리하여야 할 이벤트 이외에 회사가 추구하고자 하는 전략 및 이벤트와 함께 부수적으로 관리하여야 할 내용으로 담당자에게 메시지와 처리 메뉴, 그리고 게시판 형태로 정보 전달 그리고 아래와 같이 전산 적으로 자동적으로 처리하는 작업들로 구성하게 된다.

☞ 고객별 신용 등급에 관한 평가

☞ 지식의 축적과 활용

☞ 기만 또는 사기 행위 적발 및 처리

☞ 리스크 평가와 관리

☞ 포트폴리오 관리

☞ 고객 서비스 자동화

☞ 마케팅 캠페인 관리 등의 업무.

내부 관리 이벤트는 주 업무를 수행하고 나서 최종적으로 보고서를 작성하는 업무와 팀 전체의 퍼포먼스 분석과 BSC에 의한 평가 지표등 부수적으로 수행할 업무로 조직 내부에서 보고서를 작성하는 것을 주목적으로 하고 고객이라는 엔티티가 배제되고 기업 내부의 직원들이 이벤트를 유발하는 엔티티가 되는 것이 특징이다.

조건 이벤트는 이벤트의 생성에는 외부적인 요인과 기업 내부의 지침이나 캠페인 작업 또는 고객, 협력업체와 직원간의 진행되는 관계에 따라 새로운 이벤트와 프로세스가 발생하게 되는데, 본 발명에서는 두 가지 방법으로 문제를 해결하는데 하나는 객체간의 조건을 조사하여 다른 이벤트를 발생시키는 조건적인 성격의 이벤트가 있으며, 또 다른 방법은 이벤트와 이벤트의 연결을 관여하는 모듈(이벤트리스트에서 이벤트와 이벤트를 연결시키는 방법가운데 하나)을 통해 조건에 따라 다른 이벤트를 발생시키는 방법이 있다. 여기서 첫 번째 방법이 조건 이벤트라 한다. 예로 방문 고객과 업무 성격에 따라 방문 고객이 해당 리드(lead)에 포함되어 있는 고객인지를 판별하는 작업을 수행하게 되고 리드 고객인 경우는 담당자에게 필요한 지침 및 서비스를 제공하게 된다.

이벤트 모델에서 이벤트의 속성을 구분하는 이유는 작업을 주도하고 보조하는 주체에 따라 서브 이벤트를 세부적으로 구분하여야 한다는 점과 기업이 제공하는 리소스에 있어 각각 비용과 시간의 경제적인 요건에 따라 서브 이벤트를 분리하여야 한다는 점이다.

이벤트 모델을 수립하기 위한 세 번째 단계로이벤트간의 시나리오 작성(34).

관계는 보통 직접 또는 간접 방법을 통해 이루어지게 되는데 행동 과학적으로 관계 형성을 설명한다면 아래와 같은 단계를 거쳐 고객과의 관계를 형성되며,관계를 위한 가장 근본적이고 중요한 키는 고객을 위해 기업 자신을 맞추는 행동과 방법에 있다.

☞ 고객이 행동하고 있다.

☞ 고객이 행동하고 있다는 사실을 내가 알고 있다.

☞ 내가 행동하고 있다는 것을 고객이 알고 있다.

☞ 결과적으로 고객이 행동하고 있다는 사실을 내가 알고 있고 고객은 내가 행동하는 것을 알고 있다.

간단히 설명한다면 관계란 내가 고객을 인지하거나 행동을 이해하고 있다는 사실을 고객이 알고 있는 상태를 의미하며 이러한 상황에 놓였을 때 관계에 있다고 말할 수 있다.

따라서 기업은 고객에 대한 신뢰할 만한 정보(Information)를 지속적으로 확보하여야 하며, 그것들을 기초로 고객 관계를 원할하게 할 수 있는 기초자료를 만들어야 한다. 따라서 이벤트 시나리오 작성 시 가장 중요한 포인트는 고객과의 접점(이벤트)으로

☞ 기업 외부와 직/간접적으로 접점을 이루어지는 채널을 통해 필요한 정보를 수집하여야 하고,

☞ 고객과의 접점을 통해 기업의 모든 프로세스가 움직이도록 되어 있어야 하며,

☞ 그와 동시에 고객과 접점을 이루는 순간에 필요한 행위가 이루어 질 수 있도록 사전에 준비가 되어있어야 한다.

이 단계에서는 현재와 미래의 기업 전략과 시나리오 그리고 고객관점에 따른 시나리오에 따라 필요한 작업 준비와 그에 따른 이벤트를 개발하고 이벤트와 이벤트의 집합 또는 기업의 내부 프로세스와 연결하게 되며, 또한 이벤트를 유발하는 엔티티와 이벤트의 속성을 표준화하게 된다. 이 단계에서 반듯이 고려하여야 하는 사항은 이벤트 발생에 따라 필요한 행위를 이행하기 위하여 사전에 준비하여야 하는 정보, 행위, 전 단계 이벤트의 고려이다.

기업 외부에서 발생한 이벤트는 시나리오에 따라 기업 내부에서 또 다른 이벤트를 낳게 되는데, 이 것이 본 발명에 핵심사항으로 하나의 이벤트 발생은 이벤트의 속성과 이벤트들간의 인과관계에 따라 연쇄 반응을 일으키게 되며, 이때 사전에 설정된 시간과 조건에 따라 그리고 우선 순위와 이벤트 작업의 주체(시스템이 주체가 되거나 직원이 주체)에 따라 이벤트가 발생된다는 점이 다를 뿐이다. 그리고 본 단계에서 고려하여야 할 사항은 앞에서 정의한 이벤트 정의와 속성 그리고 시나리오에 따라 이벤트와 이벤트간의 공동 목적의 작업을 위한 작업 조건과 정보 교환 그리고 작업 환경에 대한 이벤트간의 인터페이스이다.

현재의 은행 시스템에서는 접촉하는 고객의 수가 많아 다양한 고객 정보를갖고 마케팅 부서에서 수시로 분석 작업하여 대출을 원하는 고객 정보를 파악하고 캠페인 작업을 수행하는데 반하여, 본 발명에서는 주택 구입을 위하여 고객이 대출을 받고자 움직일 경우 고객은 인터넷을 통해 정보를 수집하든 또는 은행 창구에서 상담을 하든, 전화 상담을 하든 자신이 갖고 있는 여러 가지 채널을 통해 정보가 수집하게 되고, 이러한 움직임은 하나 하나의 이벤트를 통해 기업 정보시스템에 자료가 축적되며, 그 정보는 자체적인 분석을 통해 고객이 단순 호기심으로 파악하고 있는지 아니면 어떠한 목적으로 자료를 수집하고 있는지 동기를 파악하고 고객의 현재 상태에 맞게 기업 내부의 캠페인 프로세스를 유발시키게 되며, 동시에 영업직원에 필요한 업무 목표의 배정을 위한 기초 자료(타겟 고객 리스트와 그에 따른 상품별 매출 목표)로 사용하게 된다. 이는 상품과 서비스 판매가 이루어지는 시점이 대부분 고객이 원하는 시점에 이루어진다는 점이다. 또한 수집된 정보는 작은 규모 단위인 지점에서 고객 요구하는 시점에 시스템이 자동적으로 캠페인과 관련된 이벤트를 발생시켜 작업을 수행하게 되며, 또한 본사 차원의 같은 형태의 캠페인 작업의 중복을 방지할 수 있게 된다.

앞에서 설명하였던 것처럼 관계 이론에서는 핵심 이벤트의 발생은 고객이 무작정 찾아와서 계약하거나 발주하는 행위로 이루어지는 사건이 아니라, 사전에 다른 이벤트를 통해 접촉이 이루어지고 그리고 고객 판단에 따라 핵심이벤트가 발생한다고 가정할 수 있으며, 따라서 고객이 원하는 순간에 모든 작업이 가능할 수 있도록 사전에 모든 자료를 준비되어 있어야 한다는 이야기가 된다. 이에 따라 단순한 변화에 대해서도 직감할 수 있으며 또한 시장을 읽고 해석하며 준비하는 시나리오가 중요하게 된다.

이벤트 모델에서 시나리오를 작성하는 방법에 있어 두 가지 기능을 제공하는 데 그 차이점은 시간이라는 개념에서 유발한다.

즉, 이벤트란 어원부터 시간의 개념이 포함되어 있으며 모델의 속성상 시간을 중요한 관리 포인트로 두고 시간에 대한 집중적인 관리를 수행하는데, 이는 담당자가 자율적으로 작업을 선택하여 수행하는 업무 방식에서 벗어나, 프로젝트처럼 조직적인 시간관리를 통한 기업 전략 수행이라는 방식을 채택하고 있어, 칸트 차트(Gantt Chart)와 퍼트(PERT)처럼 외부 또는 내부에서 발생한 하나의 이벤트에 대하여 동시 다발적으로 여러 가지 이벤트들을 발생시켜 여러 조직에서 같은 목적을 위해 움직이게 되고 결과적으로 이러한 이벤트들의 결과가 초기 발생한 이벤트의 최종적인 결과로 나타나게 하는 방식(이하 "프로젝트"라고 한다.)을 사용하거나,

또한 일반적인 프로세스처럼 시간에 대하여 관리가 없는 경우와 같이 이벤트를 엮어 시나리오로 만드는 방식이 이용된다.(이하 "프로세스"라고 한다.)

결과적으로 이벤트 모델은 기존의 프로세스나 프로젝트가 활동 위주로 기술되고 활동의 담당자와 리소스를 배정하고 마일스톤으로 관리 방법에서 시스템이 관리의 핵심 객체로 진행사항을 추적 처리하게 되며, 이벤트로 말미암아 발생된 클러스터 내 객체들의 행위 형태로 활동들을 관리하게 된다.

그리고 위와 같이 서술된 시나리오에 대해 시스템에서는 두 가지 기능을 제공하게 된다.

하나는 프로젝트나 프로세스에 대해 여러 조직에서 같은 목적을 위해 움직일 수 있도록 관련된 모든 이벤트와 객체의 행위를 관리하고 처리하는 기능을 제공하게 되는데, 이러한 기능은 조직의 모든 담당자의 스케줄 관리와 조직의 모든 리소스를 동시에 관리할 수 있다는 이점이 있다. 물론 이 경우 시스템에서는 이벤트 내 객체의 행위에 대한 효율적인 관리를 위한 칸트 차트와 퍼트(PERT)를 차트와 도면 형태로 관리할 수 있는 툴들이 제공하게 된다.

또 다른 하나는 일반 직원과 같이 시스템도 자신의 작업 내용과 처리 결과를 기록하고 보관하여야 하기 때문에 시스템이 주체가 되어 처리가 이루어지는 이벤트(이하 "이벤트리스트"라 한다.)의 관리가 필요하다.

이벤트 모델은 지금까지 기업 내부에서 이루어지는 일정한 업무흐름에 귀착되는 것이 아니라, 시나리오 형태로 업무 흐름을 제공할 수 있어 시장의 변화에대하여 유연성을 확보하고 있다고 할 수 있다. 그리고 프로젝트와 프로세스를 기존에는 활동의 결과에 따른 산출물 형태로 관리하거나 완료의 결과 표시로 기록도 가능하지만 그것보다 행위에 따른 결과 또는 균형성과관리의 지표(KPI) 형태로 표시하며 관리할 수 있는 방안을 제시하게 된다.

이벤트 리스트는 이벤트들과 연관되어 시스템으로 자동 수행하여야 할 이벤트들을 의미하게 되는데, 이들 이벤트는 개념적으로 연결되어 있고, 비슷한 속성들을 지녔으며 동일 라이프사이클(Lifecycle)을 갖는 것이 특징으로 처리하고자 하는 이벤트와 관련된 프로세스나 프로젝트들의 부분 집합의 합집합으로 표시 할 수 있다. 이는 이벤트에 의한 클러스터는 시나리오에 따라 하나 이상의 프로세스와 연관되며, 또한 시스템이 수행하여야 할 이벤트리스트는 최소 한개 이상의 프로세스와 연관됨을 의미하게 된다.

일반적으로 이벤트리스트에는 프로세스와 프로젝트에는 없는 조건 이벤트가 있는데, 따라서 본 발명에서 제시하는 프로세스나 프로젝트는 조건적인 활동이 포함되어 있는 것으로 간주할 수 있다.

경우에 따라 이벤트 리스트에는 같은 이벤트가 하나 이상 있을 수 있는데 이는 같은 이벤트에 다른 객체의 기능 또는 같은 객체의 다른 기능을 요구하는 필요성이 있기 때문이다. 그러나 추천하는 방법은 이벤트리스트에는 같은 종류의 이벤트가 없도록 하나의 이벤트가 한번에 모든 작업이 가능할 수 있도록 이벤트에 전송하는 파라미터를 잘 활용하는 것이 시스템 성능에 중요한 변수가 된다.

본 발명은 오퍼레이션 레벨의 시스템(Operation System) 구축만을 의미하지 않는다. 이는 기업이 비즈니스를 수행하면서 축적한 노하우(Knowhow)나 지식 그리고 전략을 단순히 분석하여 시스템으로 구축하고 실무 담당자들에게 교육 통해 조회하고 자료를 보고 스스로 판단하는 것이 아니라 이벤트 발생과 동시에 필요한 정보 가공과 담당자에게 필요한 정보 제공을 위하여 지식관리시스템에 속한 조건 이벤트를 호출하게 되고, 조건 이벤트에 따라 다양한 이벤트리스트를 호출하게 된다. 예를 들어 병원의 경우 직접 의사와의 상의하기 이전에 간호원들은 일반 프로세스의 업무처럼 환자의 증상을 입력하였을 경우 이벤트가 발생하고 증상에 따른 병명을 준비하기 위하여 지식관리의 이벤트를 호출하고 필요한 정보를 미리 준비할 수 있어, 사전에 담당 의사에게 필요한 정보를 전달하고 진찰과 동시에 최종 확인 작업으로 오진을 최소화 할 수 있게 되며, 최종 입력된 병명에 관하여 유사환자의 처방전을 조회할 수 있으며, 또한 입력된 처방전의 출력은 물론 인터넷을 통해 필요한 약국에 전달할 수 있는 방법도 제공할 수 있다.

은행과 같이 많은 고객을 상대하는 기업은 고객의 금융정보와 신용 상태 그리고 거래 실적과 유관 기관의 통계 정보를 근거하여 각 각 별도 수행한 작업내역에 따라 필요한 분석을 수행할 수 있어, 최적에 금융상품에 대하여 순서적으로 고객에 제시할 수 있으며 또한 은행 전략에 따라 각각의 정보와 연관되어 있는 서비스와 상품을 결합한 새로운 맞춤 상품으로 고객의 요구에 맞출 수 있을 것이다.

보통 업무 수행은 하나의 업무에 하나의 작업을 수행하게 된다. 그러나 본 발명에서는 하나의 이벤트에 두 가지 다른 시나리오에 따라 사전에 준비된 다른 모듈을 동시에 호출하여 작업을 시행할 수 있으며, 또한 시나리오에 따른 프로세스는 각각 해당되는 이벤트들을 연결함으로써 가능하고 만약 같은 이벤트가 각각 다른 프로세스에 있다하더라도 이벤트에 속한 객체(Object)에 따라 또는 객체를 호출하고 작업을 의뢰하는 아규먼트(Argument)에 따라 다르게 작동할 수 있다.

이벤트 모델을 수립하기 위한 네 번째 단계로이벤트 객체간의 커뮤니케이션 및 모듈화작업(36)

이벤트 모델에서는 도 5와 같이 비즈니스(500)(510)와 이벤트(520)(530) (550) 그리고 모듈(540)을 이루는 객체로 세 가지 레벨에 따라 시스템을 구성하게 되는데 각각의 특성과 주요 기능은 사용자가 사용하는 화면(이하 "디스플레이 모듈"이라 한다.)이 담당자의 기능 위주로 구성되든 아니면 기존 프로세스의 활동방식이 되든 담당자의 요구에 의하여 구성되든 이벤트와 모듈에 독립하여 작동하게 된다. 그리고 개별 클러스터의 객체를 대표하는 마스터 모듈 및 업무의 흐름과 프로세스와 프로젝트의 관리를 위한 별도 기능으로 구성된 프로세스(550)을 포함하여시스템이 주체로 동시 또는 순차적으로 작업하여야 하는 클러스터를 모든 이벤트리스트로 구성하며, 최종적으로 실행하는 모듈들로 구성하게 된다. 이 때 실행 모듈은 기업 내부 외부에 존재할 수 있으며, 또한 하나의 작업을 위하여 여러 개의 모듈로 구성될 수 있으며, 또한 같은 모듈이 여러 시스템에 분산되어 동시 또는 비 동시적으로 작업할 수 있어 시스템의 구성 요소인 모듈과 업무 흐름을 분리시킬 수 있는 장점이 있으며, 어떠한 외부의 충격에도 견고하게 작업할 수 있는 환경을 만든다.

그러나 시스템의 실질적인 작업은 모두 객체(고객, 자동차, 직원 등)와 객체의 행위에 의하여 이루어지게 되는데, 기존 객체 지향 모델에서 시스템을 구축하기 위한 업무의 분석과 설계에서는 기본 가정이 시스템을 이루는 모든 객체(Object)를 기준으로 이루어진 반면에 이 단계에서는 3 가지 관점에서 분석과 기능적 설계를 통한 객체의 모듈화 작업이 이루어진다.

a) 이벤트가 갖고 있는 객체들을 모아 최적화하게 되고 필요한 분석과 설계 작업이 이루어지게 되며,

b) 시간을 기준으로 엔티티에 의하여 유발된 그 시점에 관계를 갖는 객체들로 구성된 클러스터를 기준으로 분석과 기능적 설계가 이루어지게 되며,

c) 이벤트리스트와 관련되어 이벤트에 대해 필요한 파라미터 제공과 관련된 분석과 기능적 설계가 이루어지게 된다.

이와는 별도로 이벤트를 이루는 객체간의 커뮤니케이션 방법을 고려하여야 하는데 고객과의 접촉하는 채널은 가장 전통적인 방법인 영업직원들이 현장에서 직접 고객을 만나는 작업을 통해 이루어지기도 하고, 인터넷의 화면, 서비스 센터나 콜 센터의 전화, 금융기관인 경우 ATM 단말기(Automatic Teller Machines), 음성응답시스템, 카드 형태로 접촉이 이루어지게 된다. 이 모든 경우에 대하여 근본적인 차이는 시스템을 제어하는 방법에 차이가 있으며, 기기들은 별도 비즈니스를 수행하는 객체와 같이 필요한 행위를 수행할 수 없으며 도구로 인식하게 되는 반면 시스템은 행위를 수행하는 주체로써 필요한 응답을 시행하게 되는데 이때 여러 가지 커뮤니케이션 도구를 고려하게 된다.

실제 모듈의 개발은 객체지향기술을 이용하여 개발이 이루어지는데, 모아진 모든 정보는 기능적인 검증 작업과 더불어 시스템 구성의 최적화 방안이 강구된다. 요구사항에 대한 단순히 전산에 대한 방안만 연구하는 것이 아니라 앞에서 언급하였던 것처럼 개별 교육 자료와 커뮤니케이션 방법을 취합하여 적정한 것인지 알아보게 된다.

본 단계에서는 이벤트와 이벤트(59), 화면 모듈과 이벤트(57) 그리고 이벤트와 객체간(58)의 인터페이스를 고려하여야 한다. 이는 최종적으로 각각의 모듈에 일치되는 작업환경과 작업을 위한 정보제공이 필요하기 때문이며, 정보제공 방법은모듈의 파라미터 제공과 데이터베이스를 이용하는 방법을 주로 사용하는데, 시스템의 퍼포먼스와 이벤트간의 독립성 문제로 모듈간의 파라미터 사용을 권장하게 된다. 그리고 인터페이스는 이벤트 내 개별 객체에게 직접 파라미터를 전송하는 것이 아니라 클러스터의 상태를 대표하는 마스터 모듈을 통해 필요한 객체들의 모듈이나 메소드들(Method)(55)를 호출하고 필요한 파라미터를 전달하는 간접 방식으로 역할을 수행하게 된다. 이와 같은 방법은 화면 모듈과 다른 이벤트에서 직접 모듈을 호출하였을 때 이벤트의 독립성이 상실되는 문제가 있기 때문이다.

결과적으로 클러스터를 대표하는 상태의 모듈(St)와 이벤트를 대표하는 파라미터와 개별 기능의 모듈들을 결합하여 함수 f : S_t-> S_t+dt를 표현하게 된다.

도 5의 디스플레이 모듈이 객체의 메소드를 직접 호출하는 경우(56)가 있는데 이는 다음과 같은 경우에 대하여 허용될 수 있다.

첫 번째 시스템의 논리차원에서 모듈이 기술하는 기능이 일부 업무에만 귀착되는 경우,

두 번째 초기 시스템 가동을 위하여 기초자료를 입력하는 경우 그리고 시스템 에러로 말미암아 정상적인 작업을 수행할 수 없는 경우,

세 번째 디스플레이 모듈의 기능 중에 시스템 제어와 화면 처리와 관련하여기능이 중복되어 공동으로 사용하는 경우,

그리고 각각 58과 54의 경우는 별도의 디스플레이 모듈과 다른 시스템의 요청 없이 사전에 설정된 작업에 대하여 주기적으로 객체들을 호출하여 자료를 체크하고 객체들이 작업할 수 있도록 도와주는 작업과 별도의 클러스터내 모듈 호출 없이 클러스터와 프로세스에 관한 정보만을 조회하고 경우에 따라 클러스터의 기능을 부여하는 작업하는 경우를 말한다.

이는 시스템의 퍼포먼스와 자원의 재활용 그리고 모델을 구성하는 논리 범위 내에서 이루어지는 사항이다.

그러나 분석단계에서는 마스터 모듈이 완성되어 있지 않으므로 개발자 입장에서는 개념을 명확히 하기 위하여 이벤트와 객체의 모듈 또는 메소드를 연결하여 표시하게 되는데, 고객만남의 고객 프로파일 정보 조회는 고객만남 : 고객 : 정보조회라는 기호로 표시한다.

이벤트는 객체의 집합인 반면에 현재의 시스템 운영방식이 회계, 생산, 영업과 같이 기능 위주로 되어 있어 이벤트 내 객체의 모듈들을 호출하기 위해서는 최소 하나 이상의 어플리케이션 서버와 하나 이상의 데이터베이스 서버에서 자료를 호출하여야 하는 문제점이 있다. 따라서 현재의 방식으로 시스템을 개발하거나 또는 이벤트를 구성하는 객체의 메소드나 모듈을 세분화 할 경우 시스템은 필요한 작업의 수행보다 모듈을 호출하는 I/O 작업에 많은 시간을 소모하는 문제점을 낳는다는 점을 유념하여야 한다. 따라서 이벤트 중심으로 시스템을 구성할 경우 모듈들은 공동으로 사용할 수 있도록 라이브러리 형태로 보관하고 작업은 서버에 분배하여 작업할 수 있도록 하는 것이 전체 시스템 퍼포먼스를 향상시킬 수 있는 방법이 된다.

이벤트 모델을 수립하기 위한 다섯 번째 단계로이벤트 보안작업(38)

이벤트에 의하여 유발된 이벤트리스트는 이벤트와 동시에 작업이 이루어져야 하는 서브이벤트로 구성된다. 따라서 시스템은 이벤트리스트의 속한 이벤트들이 정상적으로 작동하고 있는지 지속적으로 체크하고 그 결과를 기록 관리하며 또한 에러가 발생 시 담당자에게 통보하는 역할도 수행하여야 한다. 그러한 개별 이벤트의 관리는 결과적으로 이벤트리스트의 시작과 완료 여부를 지속적으로 관리하게 됨을 의미한다.

프로세스의 시작은 엔티티에 의하여 발생된 이벤트이며, 프로세스의 완료는 이벤트를 발생시킨 엔티티(고객 또는 협력업체)에 의한 제품 인도 확인서에 서명하거나 A/S 서비스 확인 서명 그리고 대출정보에 의한 캠페인 작업과 같이 완료와 발생의 속성을 지닌 이벤트에 의하여 프로세스가 완료된다.

이처럼 이벤트리스트와 프로세스의 상태를 관리하는 목적은 단순히 시스템 적으로 작업이 정상적으로 완료되어 있는지를 체크하기 위한 목적만 있는 것이 아니다. 고객 또는 협력업체 그리고 담당 직원들은 비즈니스를 수행함에 있어 고객의 요구사항, 즉 주문 또는 발주에 관하여 현재 진행되고 있는 작업 정보를 고객이 원하는 시점에 즉시 알려 주어야 한다는 점이다. 이 때 시스템이 제공하고 있는 모든 채널(창구, 서비스 센터 또는 인터넷)을 통해 현재 진행중인 이벤트는 무엇이고 또한 완료되지 않는 이벤트는 무엇인지 지속적으로 추적(Follow-Up)은 물론 예정시간까지 조회가 가능하여야 한다. 또한 담당자에게 현재 유보되어 있는 프로세스는 무엇인지 지속적으로 보여주며 관리하여야 한다. 경우에 따라 관리자에 의하여 일정기간동안 유보되어 있는 프로세스와 이벤트리스트를 파악하여 원인을 분석하고 필요한 조치를 취하고 프로세스와 이벤트리스트를 종료시키는 작업도 수행하여야 한다.

이때 이벤트를 발생시킨 주체와 이벤트와 관련된 담당 직원은 자신이 갖고 있는 시스템의 접근 권한에 의하여 클러스터와 객체 그리고 디스플레이 모듈에 대한 접근 권한에 따라 모든 정보는 보호받게 되며, 이벤트와 관련된 객체(담당직원, 고객)들만이 이벤트에 의하여 유발된 프로세스와 관련된 정보를 입력, 조회, 수정, 삭제할 수 있으며, 또한 이벤트의 속성과 담당자의 권한에 따라 공개가 가능한 정보를 열람할 수 있게 된다.

프로세스의 추적관리 기능은 시나리오 작성과 보안 단계에서 핵심사항으로 추적 관리란 사전에 정해진 시나리오에 대비하여 진행중인 이벤트는 무엇이고 아직 진행되지 않은 이벤트는 무엇인지 보여주어야 한다. 이 때 고려하여야 할 사항은 시스템이나 담당자 또는 고객이 요구한 사항에 대하여 추적할 수 있는 유일한 구분자를 갖고 있어야 한다는 점이다. 추적관리란 주로 기업의 내부 프로세스와 관련이 되어 이벤트에 의하여 유발된 프로세스나 이벤트리스트에 대하여 시작에서 완료까지 처리의 일관성을 갖고 있어야 한다. 즉, 업무관행 또는 작업의 효율을 위하여 같은 작업이 일정량 쌓인 후 묶어 하나의 작업 단위로 처리하든가 또는 관리의 편한 단위로 담당자가 임의적으로 분리하여 작업 처리하는 방법은 이벤트 모델에서는 원칙적으로 배제되고, 필수 불가결하게 처리하여야 하는 사항은 별도 배치넘버 (Batch Number)와 같은 형태로 묶어 작업이 처리가 되며 개별 이벤트는 보관하여 추적이 가능하도록 한다.

보통 영업과 마케팅 시스템에서는 인-바운드 이벤트에 관해서는 고객의 주민등록 번호, 사업자 등록번호, 건별은 청구번호나 발주번호로 구분할 수 있으며, 아웃-바운드 이벤트의 경우에는 캠페인 번호 등으로 구분할 수 있는데, 업종의 성격에 따라 또는 시나리오의 성격에 따라 구분하는 것이 좋다.

모델을 구축하는 방법에 있어 각 단계별 반복 작업을 하여야 하는데, 이는각 단계가 독립적으로 수행하는 것보다 상호 보완적인 성격에 의하여 연결이 되어 있기 때문이다. 예를 들어 이벤트 정의에서 분리한 이벤트가 속성상으로 이중의 속성을 갖고 있다면, 다시 이벤트 정의 작업에서 단일 속성으로 이벤트를 세분화하여야 한다.

이벤트는 실제 이루어지는 현상을 기준으로 하지만 가상적 또한 개념적으로 이루어지는 현상까지 포함할 수 있어 실존적인 것이 아니라 개념적인 객체들의 집합으로 이해하는 것이 올바를 것이다. 그리고 이벤트에 의하여 발생된 클러스터는 모두 전산적으로 이루어지는 작업을 근거로 하지 아니하며, 정보시스템이 배제 될 수 있는 비즈니스 업무까지 포함되어 있다. 이는 업무흐름과 현상들은 시간의 흐름에 대해 연속적인 속성을 갖고 있어 중단되거나 단절되지 않기 때문이다.

지금까지 관계관리와 이벤트라는 개념에서 기업의 비즈니스를 해석할 수 있는 모델에 관하여 설명하였으며, 이러한 모델을 지원하는 시스템의 구성과 작동 방법에 관하여 설명하도록 하겠다. 본 발명에서는 기업이 추구하는 산업 여건과 전략에 따라 같은 이벤트라 하더라도 각각 목적이 다르고 구성하는 객체가 다르기 때문에 언급하고 있는 시스템은 모델이 제공하는 것 가운데 일부 관계관리와 관련하여 핵심 작동방법에 대해서만 언급한다.

본 발명의 시스템 구성은 프로세스와 이벤트 그리고 객체로 분리하기 때문에OMG(Object Management Group)에서 발간한 분산환경(Distributed System)하에서 객체-지향 어플리케이션을 사용하는 표준 규격인 코바(CORBA)를 근간으로 구축하였으며, 시스템의 플랫폼(Platform)에 따라 JAVA를 기본 언어를 근간으로 하는 JAVA RMI을 사용할 수 있으며, 또한 윈도우(Window) 환경에서는 DCOM의 규격을 따를 수 있다.

본 발명에서 언급하는 모듈을 개발하는데 있어서 반듯이 객체지향방식의 언어를 사용하고 자료 보관도 객체지향 방식으로 처리하는 것을 의미하지 않는다. 이는 모델에서 언급하는 객체는 개념적인 것이고 따라서 개발언어와 방식에 독립적인 것을 의미한다.

이벤트 모델을 기초로 한 관계관리시스템은 도면을 참조로 설명한다.

고객이나 직원들이 시스템을 이용하는 방법에는 두 가지가 있는데, 가장 일반적인 방법으로 기업의 기능별 담당자나 고객이 갖고 있는 단말기(6100)(PDA, 핸드폰, 무선 인터넷, PC)를 이용하여 기업이 제공하는 서버(6200)에 접속하여 고객을 위한 서비스(인터넷 홈페이지, 전자상거래)나 직원들에게 제공하는 서비스(기능 프로그램)를 제공받게 된다. 이를 위한 필요한 화면 또는 영상 그리고 기기 제어는 디스플레이 서버(6200)에서 담당하게 되지만 고객과 담당자는 어떠한 기종을 사용하더라도 공통된 사항은 시스템이 작업하기 위한 필요한 정보를 입력하고 원하는작업을 선택하게 된다는 점이다.

또 다른 방법은 과거 클라이언트와 서버 방식으로 담당자의 단말기나 PC(6500)에 디스플레이와 관련된 프로그램을 보관하고 직접 이벤트 서버(6300)에 접속하는 방법으로 별도 화면과 기기를 제어하고 디스플레이 서버 없이 담당자의 선택으로 연결하여 사용할 수 있다.

따라서 이벤트는 고객이나 직원들과 접속하고 커뮤니케이션하기 위한 디스플레이 서버(6200)와 같은 장비나 매체에 무관할 뿐만 아니라, 단말기의 종류와 목적에 따라 또는 국가에서 사용하는 언어와 화폐 단위 등의 차이 그리고 별도의 인터넷망을 이용하는 개발언어나 그래픽 개발 툴 및 과거의 클라이언트(6500)와 서버 방식의 개발 언어와 독립적으로 운영하게 되어 어떠한 커뮤니케이션 관련 모듈들에 종속되지 않는 특징이 있다.

본 발명에서는 사용자 인터페이스 모듈을 분리하여 처리하며, 이는 어떠한 로직이나 데이터 가공과 관련이 없는 모듈로 단순히 기기의 제어와 화면(GUI, 텍스트)의 처리 또는 프로세스와 연관된 활동으로 인식할 수 있으며, 실질적인 작업은 이벤트라 부르는 모듈들의 집합에서 이행하도록 되어 있다.

필요한 작업은 이벤트 서버(6300)를 통하여 작업을 요청하게 되는데, 하나하나 작업 요청 사항은 디스플레이 서버(6200)에 있는 ORB(Object Request Broker)와 네트워크(GIOP/IIOP) 그리고 이벤트 서버내의 ORB를 거쳐 이벤트 서버로 전달된다. 이때 이벤트 서버는 크게 다음과 같은 기능을 갖고 있다.

☞ 작업 수행을 위한 이벤트의 정보(파라미터, 이벤트의 마스터 모듈 위치)

☞ 각각 이벤트와 연결되어 동시적으로 수행하여야 하는 이벤트들의 정보, 순차적으로 작업하여야 할 이벤트들의 순서를 기록하고 있는 이벤트리스트에 관한 정보 관리

☞ 이벤트, 이벤트리스트 및 프로젝트 그리고 프로세스의 상태 관리

☞ 이벤트 요청 내역과 작업 결과에 대한 기록 관리

☞ 에러 발생에 따른 복구 방법과 이벤트리스트와 이벤트 사용 정지 작업

☞ 디스플레이 모듈과 이벤트를 엮는 작업

그에 따라 어플리케이션 서버(6400)에 있는 각각의 이벤트를 호출하고 디스플레이 서버(6200)와 클라이언트/서버의 사용자 단말기(6500)에서 받은 아규먼트 (Argument)를 이벤트에 제공하는 기능과 어플리케이션 서버의 이벤트로 받은 결과 값을 디스플레이 서버(6200)와 사용자 단말기(6500)에 전달하는 기능을 갖는다.

어플리케이션 서버(6400)는 다른 시스템과 같이 개별 기능을 갖고 있는 모듈을 호출하여 처리하는 것이 아니라 개발 담당자 또는 일반인들도 이해하기가 쉽도록 이벤트 단위로 작업을 요청하게 되며, 실질적인 작업과 관련된 모듈들은 이벤트를 대표하는 마스터 모듈(Master Module)에서 작업에 필요한 모듈들을 라이브러리에서 호출하여 수행하게 된다. 이때 상호 자료 교환이 없는 모듈들에 대하여 동시 작업을 수행하게 된다.

이벤트에 의하여 처리하는 작업은 이벤트내의 모듈들이 수행하게 되는데 앞에서 이야기한 이벤트의 특성에 의하여 객체지향 방식에 따라 각각의 이벤트 단위로 설계와 모듈들을 제작하게 되고 그리고 필요에 따라 기능을 지원하는 객체들의 라이브러리(Library)들을 만들게 된다. 따라서 기업의 전체 시스템을 제작하는 것이 아니라 이벤트 단위로 독립적으로 작동할 수 있는 객체지향방식으로 작업함은 물론이고 이벤트 단위별로 제작이 가능하여 생산성을 증가시킬 수 있다는 장점이 있다. 이벤트가 갖고 있는 라이브러리에 있는 모듈들은 이벤트와 동일한 속성을 띄고 있지만, 모듈은 이벤트와 독립적으로 구성되고 운영하므로 이벤트에서 공동으로 사용하는 객체의 모듈들은 필요한 이벤트에 따라 공동으로 호출하여 작업을 수행하게 된다.

앞에서 이벤트 객체간의 커뮤니케이션 및 모듈화 작업에서 언급한 것처럼 경우에 따라 일부 디스플레이 서버(6200)의 모듈이 이벤트 서버(6300)를 거치지 아니하고 직접 관련 모듈(6400)과 데이터(6600)를 직접 억세스(Access) 할 수 있다. 이는 시스템의 논리차원에서 모듈이 기술하는 기능이 일부 업무에만 귀착되는 경우, 초기 시스템 가동을 위하여 기초자료를 입력하는 경우와 시스템 에러로 말미암아정상적인 작업을 수행할 수 없는 경우 그리고 단말기의 기기를 제어하는 기능을 공유하는 경우에 이용하게 된다.

이벤트 서버(6300)가 어플리케이션 서버(6400)에 산재되어 있는 이벤트의 마스터모듈을 호출하는 과정에서 CORBA의 기능을 이용하게 되며, 또한 어플리케이션 서버(6400)의 마스터 모듈에서 또 다른 어플리케이션의 서버에 있는 객체의 메소드(Method)를 호출하기 위하여 CORBA의 기능을 이용할 수 있으며, 또한 이 과정에서 CORBA가 지원하는 이 기종간에 다양한 모듈들을 호환하는 기능을 제공받게 된다.

이벤트 서버 내 존재하는 이벤트 리스트는 보통 3 가지 방식으로 처리하게 된다.

첫 번째 이벤트들을 데이터 방식으로 바이너리 트리(Binary Tree)이나 힙(heap) 또는 여러 가지 데이터 스트럭쳐(Data Structure)로 표현할 수 있으며, 즉 이벤트들간의 연결관계를 도식화하는 방법으로 간단한 업무 성격으로 개별 이벤트들간의 연관관계가 적어 파라미터 전송이 필요 없는 경우 또는 이벤트들간의 파라미터 전송보다 배치(Batch) 작업의 성격으로 처리하여야 하는 이벤트들인 경우에 처리하는 방식.

두 번째는 각각의 이벤트리스트와의 관련된 객체나 모듈을 사용하여 처리하는 방식으로 이벤트와 이벤트간의 작업처리가 주로 파라미터 많은 경우에 적용하는 방식.

세 번째는 보다 복잡한 이벤트리스트를 표현하기 위하여 데이터베이스 내 테이블의 데이터, 트리거(Trigger)와 프로시저(Procedure)로 표현하는 방법으로 시나리오를 프로세스와 프로젝트 방식으로 관리하여야 하는 복잡한 업무에 적용되는 방식.

따라서 시스템의 규모와 난이도에 따라 각각 다르게 적용할 수 있다.

이벤트 서버는 이벤트의 발생으로 생성된 프로세스 또는 이벤트리스트의 상태를 측정하게 되는데 이는 이벤트의 상태 측정은 물론 이벤트의 시작부터 완료까지 상태를 별도의 파일로 관리하게 되고 예정된 스케줄에 따라서 작업이 정상적으로 진행되고 있는지 또는 문제가 있어 유보되어 있는지 관리하며 작업이 완료된 경우에는 로그 파일에 기록 보관하게 된다.

그리고 시스템은 관리자에게 이벤트별로 에러의 유형에 따라 호출한 프로그램을 일시적으로 작업할 수 없도록 정지시키는 작업이나 이벤트가 속한 이벤트리스트의 모든 이벤트를 일시적으로 정지시킬 수 있다. 이는 문제를 해결하기 전까지 지속적으로 문제를 야기할 수 있는 소지가 있으며 또한 에러가 발생한 이벤트리스트의 작업은 새로운 문제를 야기시키고 다른 시스템의 퍼포먼스에 영향을 주기 때문이다.

본 발명에서는 도7과 같이 이벤트와 이벤트리스트 그리고 프로세스에 의하여 개별 상태를 지속적으로 측정하게 되는데 측정방법은 다음과 같다.

이벤트의 상태는 활동(Active)(710), 비 활동(Passive)(720), 유보(Suspended)(730), 완료(Terminated)(740) 4 단계로 분류하는데, 활동이란 이벤트가 작업중인 상태를 의미하며, 비 활동이란 이벤트가 특정 시간에 예약이 되어 있는 상태 또는 작업을 대기하고 있는 상태를 의미하며, 또한 유보는 에러 발생 또는 담당자가 이벤트 작업을 유보시킨 경우의 상태를 의미한다. 그리고 완료란 작업이 최종적으로 완료된 상태를 의미한다.

여기서 이벤트리스트 그리고 프로세스는 이벤트의 상태 변화에 따라 활동, 비 활동, 유보, 완료 상태가 되고, 이벤트리스트와 프로세스가 유보되는 경우에는 이벤트리스트와 프로세스에 속한 개별 이벤트 모두가 유보되게 되어 있다. 그리고 활동과 비활동 그리고 완료는 정상적인 상태를 의미하지만, 유보는 에러 발생이나 프로세스 변화에 따른 작업 정지를 의미하므로 적절한 조치가 필요한 상태이다.

여기서 고려하여야 할 사항은 에러처리에 대한 방법은 아래와 같은 단계로처리가 되는데,

이벤트리스트의 첫 번째 이벤트의 에러는 에러처리 후에 다시 화면으로 같은 자료를 입력하여 처리하거나, 기존에 입력된 자료를 근거로 이벤트리스트를 재 가동하는 방법으로 처리하게 된다. 이때 기존에 입력된 자료란 디스플레이 모듈에서 이벤트를 호출하기 위하여 이벤트 서버에 제공한 파라미터 자료를 의미하는데 이벤트 서버는 이벤트리스트가 완료되기 전까지 기록을 보관하게 된다.

이벤트리스트의 첫 번째 이벤트이후의 이벤트의 에러는 후단에 있는 이벤트의 작업을 중지시키게 하지만, 이미 작업이 완료된 이벤트 작업은 이벤트마다 독립적인 성격이 있어 에러 발생된 이벤트와 원칙적으로 무관하게 정상적으로 작업 처리된 것을 의미한다. 따라서 이벤트 모델에서 선행 이벤트 완료 작업 이후의 에러 처리는 프로세스의 성격으로 말미암아 에러 발생 유형에 따라 필요한 조치를 취하고 에러 발생으로 유보되어 있는 이벤트리스트를 다시 액티브(Active) 상태로 재 가동하는 포워드(Forward) 방식에 의하여 작업 처리하게 된다. 그러나 유보되어 있는 이벤트리스트가 없는 경우에는 개별적으로 하나 하나 필요한 이벤트의 파라미터를 입력하고 이벤트 작업을 시행하거나 데이터베이스의 데이터를 직접 억세스 (Access)하여야 하는 문제가 있다.

본 발명에서는 이벤트 서버의 기능과 작동방법에 관하여 크게 두 가지를 있다.

하나는 2001년 6월 26일에 출원되어 계류중인 출원번호 제10-2001-0036594의 "이벤트 개념을 이용한 모듈 컨트롤 시스템"에 기술한 기능으로 출원된 발명은 이벤트 모델을 지원하기 위한 시스템으로 세부적인 설명은 아래와 같다.

이벤트 서버 내에 있는 이벤트 리스트를 호출하고 관리하는 역할을아젠다(Agenda)가 수행하게 되며, 이벤트 작업 의뢰와 이벤트의 상태를 기록 보관하는 역할 이외에 이벤트의 에러 발생에 따라 에러 처리 이벤트 또는 에러 처리 루틴을 수행하는 역할 또는 에러 발생된 내용을 아젠다에게 메시지를 통보하는 역할 등을 수행하는스케줄러(Scheduler)가 있다. 아젠다는 스케줄러와 지속적으로 커뮤니케이션을 하며, 유보된 이벤트와 프로세스를 추적하고 해결하는 역할 그리고 이벤트들의 작업이 정상적으로 작업되었는지 확인하고 다음 이벤트를 스케줄러에 전송하는 작업과 이벤트들이 작업 수행에 필요한 파라미터를 적절하게 만드는 작업을 한다. 또한 실시간으로 작업할 필요가 없는 배치 형태의 이벤트는 타이머가 필요한 시간에 작업 할 수 있도록 예약하는 것 이외에 스케줄러에게 받은 작업 결과 또는 에러 발생된 내용 그리고 이벤트의 사전 처리 작업 시 에러 발생 내용을 정보 사용자에게 메시지를 통보하는 역할 등을 수행하게 된다.

수행되어야 할 이벤트의 예정 시간은타이머(Timer)가 관리하는데 요청한 이벤트와 시스템 관리 목적으로 수행하여야 할 이벤트중에 실시간으로 작업할 필요가 없는 이벤트는 수행되어야 할 시간을 갖고 있어 예정된 시간에 스케줄러가 작업할 수 있도록 관리하는 기능을 수행한다. 그리고 작업이 되었을 때 완료 결과를 메시지 형태로 담당자에게 송부하게 된다.

그리고 또 다른 하나는 이벤트 모델을 지원하는 별도의 툴 없이 미들웨어와 데이터베이스 형태로 구축하는 방법이 있다. 이 경우 일반 미들웨어에서 제공하는 CORBA의 규정에 따르는 모듈 또는 데이터베이스를 이용하여 이벤트리스트의 정보, 프로세스와 이벤트리스트의 상태 관리, 이벤트 요청 내역과 작업 결과에 대한 기록 관리, 에러 발생에 따른 복구 방법과 이벤트리스트의 이벤트 사용 정지 작업, 디스플레이 모듈과 이벤트를 엮는 작업의 기능을 제공하게 된다.

도면 6 에서는 이벤트 서버, 디스플레이 서버, 어플리케이션서버가 별도 시스템으로 그려져 있으나 이는 개념적인 것이고 실질적으로는 하나의 서버에 구축이 가능하거나 또는 개별적으로 여러 개의 서버로 구축이 가능하다.

이벤트 서버는 이벤트 모델에서 제공하는 모듈 관리에 따라 기존 시스템보다 좋은 퍼포먼스를 발생시킬 수 있어 업무의 분석과 설계에 따라 큰 차이를 보이게 된다. 이는 코바(CORBA)에서 제공하는 Send와 Oneway와 같은 기능을 이용하여 두 개 이상의 이벤트를 동시에 가동하기 때문이며, 또한 이벤트의 속성에 따른 시간을조절할 수 있으며, 시스템을 분산처리하기 때문이다.

예를 들어 은행의 업무처럼 계좌의 입출력이 빈번하고 데이터의 량이 엄청난 시스템의 경우 대용량의 시스템과 엄청난 규모의 데이터베이스가 유지되어야 하며 또한 근무시간에는 자료의 계좌의 입/출력이 위주인 오퍼레이션 작업에만 치우칠 수밖에 없는 실정이고 정보의 분석을 위한 작업은 별도의 데이터웨어하우스로 자료를 넘겨 분석 작업을 시행하여야 하는 실정이다. 그러나 도 9와 같이 고객이 갖고 있는 전체 계좌를 조회 할 경우 계좌 정보 요청(9010)은 시스템 내부적으로 A계좌(9020), B계좌(9030), C 계좌(9040)의 동시 요청으로 분할되며, 최종적으로 계좌 요청(9010)에서 집계된다. 따라서 데이터베이스를 중앙에 집중방식으로 처리하는 것보다 시스템의 퍼포먼스를 증가시킬 수 있으며, 데이터베이스를 관리하는 시스템 구조가 간단할 수 있다는 장점이 있다.

또한 본 발명에서는 기존 시스템이 데이터웨어하우스처럼 중앙에 고객관계관리의 목적으로 고객정보시스템을 구성하여 회계, 영업, ERP, ABC는 물론 인터넷 시스템과 같이 기업에 산재되어 있는 시스템 사용자의 고객정보를 취합하여 시스템의 목적에 맞게 가공하여 유지하며 분석 등에 목적에 따라 자료를 제공하는 것이 아니라 오퍼레이션 작업을 수행하면서 실시간의 정보 예로, 현재 고객 구좌의 잔고 또는 구좌 보유 현황 그리고 년 간 매출 금액 및 현재 추진중인 업무 등을 이벤트의 구성하는 고객이라는 객체의 기능으로 처리하게 되며, 따라서 항상 최적의 상태에서 시스템을 유지할 수 있으며, 관리 목적에 따라 시스템을 분리할 수 있으며, 또는 객체를 구성하는 데이터의 량 또는 객체의 퍼포먼스에 따라 각각 다른 시스템으로 분리시킬 수 있다.

기업에 따라 시스템에서 소요되는 기능과 작업 처리가 방대하거나 축적되는 자료 량이 많을 경우 시스템을 중앙에 집중시키는 방식이 아니라 이벤트와 이벤트 연결 정보 그리고 이벤트와 관련된 정보로 대표되는 이벤트 서버를 중앙에 놓거나, 지역별 특징에 따라 이벤트 서버를 분산시켜 필요한 정보를 공유하는 방식을 채택하고 있어 작업의 요구가 많은 이벤트와 관련된 시스템은 복수 형태로 유지하여 지역에 분산하여 처리할 수 있다. 그러나 시스템을 어떻게 구성하더라도 공통된 환경은 작업을 이행하는 모듈들은 시스템에 분산하여 처리한다는 점이다.

본 발명의 시스템에서 제공하는 인-바운드 이벤트인 고객 접촉 또는 고객 만남(Contact Management)이라는 이벤트는 기업의 리소스와 연관하여 견적, 발주, 계약, 배송, 수금 등과 같은 핵심이벤트들로 세분화 할 수 있으며, 또한 기업의 조직의 기능에 따라 일반적인 영업 수행 과정으로 영업(Presales) 및 거래 후 지속적인 유지 보수(Postsales)등의 내역관리로 나눌 수 있다. 이에 대한 금융기관의 예로 시스템의 적용방법에 관하여 설명하기로 한다.

은행의 경우는 지역에 따라 지점을 유지하고 있을 뿐만 아니라, 고객과 전화를 통하여 접촉할 수 있는 콜 센터 또는 인터넷을 이용한 홈뱅킹 서비스 및 그 외 여러 가지 접촉과 관련된 기능을 제공하고 있다. 고객들이 참조하고 원하는 기능은 매체가 다르거나 장소가 분리되어 있더라도 일관된 정보 제공을 요구하게 된다.

본 발명에서는 여러 채널을 통해서 접촉하더라도 고객 만남(여기서는 견적, 발주 등 이벤트의 총괄적인 표현으로 언급한다.)이라는 이벤트를 호출하게 되는데 고객 만남이라는 이벤트는 고객이라는 객체 또는 고객 프로파일에 의하여 아래와 같은 정보를 관리하게 된다.

☞ Who : 고객 기초정보(나이, 사진, 성별, 연령, 수입, 취미, 전화번호, FAX,...), 고객 생활정보(집, 주소, 자녀, 차 소유 현황)

☞ Which : 거래 내역(주로 구입한 상품이나 서비스 그리고 거래단가), 매출과 이익 기준으로 고객 구분

☞ How Many : 접촉한 횟수(년, 분기, 월, 주, 일), 설문조사의 응답 횟수,...

☞ How : 접촉하는 채널(인터넷, 직원, 잡지...), 대금지불방법(수표, 어음, 현금),

☞ When : 접촉이 이루어진 시점과 구매시점(계절, 시간, 행사)

☞ 기타 : 고객의 요구 사항, 특징

또한 고객과 관련된 연역(History), 관련 협력업체, 협력업체 직원 인적 사항, 현재 진행중인 업무 내용, 년 간 매출 실적 및 고객 담당직원의 인적사항, 선호하는 상품/서비스, 등등의 고객과 관련된 정보와 유사 고객의 최근 동향 등 많은 정보가 필요하며, 그에 따라 각각의 객체의 모듈과 메소드를 호출하여 정보를 얻게 된다.

그리고 현장에서 기업의 직원과 고객이 만남을 통하여 다음 만날 시간을 예약하거나, 인터넷의 게시판, 또는 이-메일을 통해 필요한 요구에 관한 사항을 접수하게 되는데 이에 대해 담당 직원의 스케줄에 따라 처리하게 되므로 스케줄 관리는 필수적인 사항이 된다. 물론 직원이라는 객체도 인사정보, 근무성적 등 모든 사항을 관리하고 있다.

고객과 접촉하는 시스템(6100)의 특성에 따라 그리고 담당자가 수행하는 업무에 따라 고객 만남이라는 이벤트를 구성하는 객체에 대해 각각 다른 정보와 기능을 요구하며, 이벤트를 호출할 때 원하는 정보와 수행하고자하는 기능을 이벤트의 파라미터(Parameter)형태로 전달하게 되고 이벤트 서버(6300)는 이벤트와 관련된 이벤트리스트를 호출하게 되고 이벤트리스트의 순서에 따라 이벤트를 호출하고 이벤트가 갖고 있는 정보를 제공하거나 작업을 시행하게 된다. 그리고 영업을 수행한 일지 형태로 기록되는 고객 만남이라는 이벤트는 추가적으로 고객만남 : 고객 : 접촉관리라는 메소드(Method)에 의하여 모든 고객과 관련된 연역을 기록 보관하게 된다.

즉, 영업과 관련된 화면은 고객과 관계가 되는 핵심 이벤트별로 구성하게 되는데 이는 고객과 기업이 상호 교류를 기준으로 기업 입장에서 구성되기 때문이며, 각 이벤트 내 기능은 담당자의 요구에 따라 구성된다. 따라서 주요 영업 이벤트는 접촉 관리, 견적, 발주, 수금 등으로 나누어지고, 또 세부적으로 이벤트의 한 예인 접촉관리 이벤트는 내부적으로 고객 객체의 고객인적사항, 상품 객체의 상품 카탈로그, 직원 객체의 스케줄 관리(Schedule)등의 영업수행에 필요한 기능 위주로 화면을 구성하게 된다. 그리고 담당자의 기초 자료 입력과 선택에 따라 디스플레이 서버의 모듈이 작동하고 이때 필요한 이벤트를 요구하고 이벤트 서버는 요구한 이벤트에 대해 이벤트리스트와 이벤트(마스터 모듈)를 동시에 호출하게 되는데, 이벤트를 대표하는 마스터 모듈은 시스템에 따라 어플리케이션 서버(6400) 또는 이벤트 서버(300)에 존재하게 된다.

마스터모듈은 디스플레이 모듈에서 전송한 파라미터를 해석하여 어플리케이션 서버에 있는 라이브러리(Library)에서 해당 객체의 기능을 제공할 수 있는 메소드(Method)를 호출하게 작업을 수행하는 동시에 이벤트리스트는 조건에 따라 서브 이벤트를 호출하게 된다. 즉, 고객 객체의 고객인적사항의 입력은 캠페인 작업과 관련된 이벤트를 호출하게 되고, 상품 카탈로그의 정보 조회는 고객별 관심 상품의 정보이므로 상품관련 메소드를 호출하여 고객이 선호하는 상품, 상품의 디자인, 색상 등을 기록하게 된다. 이러한 서브 이벤트는 실시간으로 처리하는 정보가 아니므로 적절한 시간 내 처리할 수 있도록 시스템이 관리하게 된다.

고객이 직접 지점에 방문하여 담당자와 상담을 하든 또는 인터넷을 통해 그리고 전화 연락을 통해 정보수집을 하는 이벤트의 경우, 고객만 정보를 수집하는 것이 아니라 역으로 기업에서도 고객이 필요로 하는 상품과 서비스를 파악할 수 있는 자료로 활용할 수 있다. 그 결과로 고객 만남이라는 이벤트는 시나리오에 따라 캠페인의 리드 고객등 인지 파악하는 조건 이벤트를 호출하게 되고 조건이 맞는 경우 또 다른 이벤트와 이벤트리스트를 발생시키게 된다. 또한 고객이 조사하는 정보는 상품 개발에 보다 적극적으로 활용할 수 있게 된다.

은행 신용 대출과 같은 이벤트는 대출에 필요한 모든 고객정보를 원하므로 기업 정보시스템 내에 산재되어 있는 고객정보를 모아 실시간으로 고객 프로파일을 제공할 수 있음은 물론이고 동시에 기업 외부 시스템과 연결하여 고객의 신용상태에 관해 조사하여 그 결과를 화면에 보여주게 된다. 그리고 대출금액, 그 시점에 적용하는 이자 및 대출일자 그리고 상환일자를 출력하여 계약서에 고객 서명작업과 동시에 시스템에 확정 입력으로 대출의 절차를 마무리할 수 있게 된다. 시스템의 확정 입력은 대출에 관한 모든 입력을 포함하여 고객 대출 : 고객 : 접촉관리이라는 메소드(Method)에 의하여 모든 고객과 관련된 연역을 기록 보관하게 된다. 이 때 다른 고객 만남이라는 이벤트에서 사용하는 고객 만남 : 고객 : 접촉관리의 메소드와 같은 메소드이므로 두 개의 이벤트는 접촉관리에 같은 정보를 기록하게 되어 있다. 그리고 신용대출이라는 이벤트는 이벤트의 시작과 동시에 완료라는 속성을 갖고 있는 이벤트이다.

본 발명에서는 이벤트의 모듈 호출은 CORBA에서 표시하는 것과 같이 고객 만남 : 고객 : 정보조회와 같은 방법으로 표시하였지만, 시스템을 구축하는 개발자가 상호 작용하는 방법을 사전에 정하여 쓸 수 있으며, 별도의 원칙이나 법칙이 없음을 알리고자 한다.

이상으로 이벤트와 클러스터의 정의와 같이 이벤트 자체만으로도 하나의 현상과 세계를 구성할 수 있을 뿐만 아니라 이벤트와 이벤트를 연결하여 보다 차원 높은 시스템이 될 수 있게 된다.

그리고 본 발명에서 사용한 용어들은 본 발명의 기능을 고려하여 정의된 것으로, 업계의 관습 또는 담당자의 의도에 따라 변경될 수 있으므로, 그 정의는 본 명세서에 제시된 내용을 토대로 하여 해석되어야 한다.

본 발명에서 제시하는 이벤트 모델은 비즈니스 분야에 귀착하여 설명하였지만, 기본 정의와 이론은 특정 분야에 귀착되지 않으며 자연 과학 분야는 물론 사회 과학 분야에 적용 가능함을 알려드리며, 첨부된 특허청구범위의 사상을 이탈하지 않는 범위의 모든 예를 포함하는 것을 의미한다.

본 발명의 모델 제공하는 효과는 프로세스 모델과 객체지향 모델이 제공하고 서술하였던 비즈니스를 이벤트 모델에서 동시에 제공할 수 있으며, 또한 이제까지 비즈니스에서 표시할 수 없었던 시간 개념과 관계 그리고 현상을 설명하는 이론들을 도입하여 수학적으로 비즈니스를 서술하고 설명하며 또한 실질적인 수행을 통해 기업 경영활동에 응용하는데 그 목적이 있다.

이벤트 모델에서는 클러스터는 물질이라면 객체는 분자이고 메소드와 모듈은 전자, 핵 그리고 원자라고 표현할 수 있다. 따라서 이벤트 모델로 파악하는 것은 전체 시스템을 객체단위로 파악하는 것보다 복잡한 업무를 표현하고 처리하는데 여러 가지 면에서 유리하다.

a) 업무의 분석이 이벤트 단위로 이루어지므로 이해하기가 쉽다.

b) 이벤트 모델의 시나리오에 따라 프로세스 모델에서 적용하였던 프로세스에 대한 비용대 효과 분석(Cost-Benefit) 및 프로세스 처리 속도 그리고 비 부가 가치적인 이벤트 제거 등의 분석이 가능하다.

c) 모듈의 수정보다 이벤트별 기능 추가와 모듈 호출의 파라미터 변경 형태로 업-그래드(Upgrade)가 될 수 있다. 하드디스크 용량의 증가에 따라 큰 문제가 되지 않으며, 기존 모듈의 수정보다 추가가 개발하기 쉽다.

d) 이벤트를 통해 이루어진 객체(고객, 직원, 리소스 등)중심으로 업무처리가 이루어지므로, 이벤트 단위별로 균형성과관리(Balanced Score Card)의 적용이 가능하여 필요한 성과측정의 지표와 재무적 시각, 고객 시각, 학습과 성장 시각으로 처리는 물론 이벤트간의 연결로 프로세스 시각에서 접근이 가능하다 할 수 있다.

e) 이벤트 모델은 만들어진 모듈들에 따라 다양한 형태의 논리적 대응전략이 나올 수 있다.

f) 이벤트 내 객체들의 행위는 각각의 목적을 달성하기 위한 활동을 의미하므로 활동기준관리(Activity Based Management)나 활동기준예산(Activity Based Budget)을 적용하는 단위가 될 수 있으며, 이벤트의 시나리오를 사용하는 방법은 활동을 직접 관리하는 것보다 간단하고 과학적인 지식을 활용할 수 있어 실현하기가 쉽다.

g) 화면 관리 모듈 및 이벤트 그리고 객체의 3 단계로 시스템이 구성되어 각기 독립성을 유지하고 있어 버전-업 또는 시스템 수정이 단계별로 따로 할 수 있어작은 변화에 대해 높은 유동성(Flexibility)을 보유하고 있다.

Claims

모델을 구축하는 방법에 있어서,

목적에 있어 다른 객체들과 구분되어 질 수 있고 안정화되어 있는 동시적인 상태의 객체들의 집합인 클러스터와 클러스터의 특성과 속성을 이용한 클러스터들의 네트워크라는 수단을 사용하는 모델 구축 방법.
제 1항에 있어서, 상기 클러스터는

이벤트(Event)에 의하여 이루어진 구체적인 목적을 갖고 있는 동시적인 상태의 객체들 그리고 객체들간의 관계(Relation)와 행위(Action)로 이루어진 집합 또는 목적을 갖고 있는 객체들간의 커뮤니케이션과 행위를 기준으로 관련된 동일 성격과 속성의 객체들의 집합인 것을 특징으로 하는 모델 구축 방법.
제 1항에 있어서, 모델에 적용되는 시간은

클러스터 내에서는 동시적으로 (Synchronous) 진행되는 것이 아니라 비 동시적으로(Asynchronous) 진행하여 하나의 안정된 클러스터의 상태에서 다음 안정된 클러스터의 상태로 이동시간의 차이가 없는 것이 특징인 모델 구축 방법.
제 2항 또는 제 3항의 방법을 이용하여 비즈니스 모델 구축 방법에 있어서,

상기 클러스터들의 연관관계와 네트워크를 표현하는 방법으로 수학의 집합(Set) 이론과 대수학(Algebra)의 함수 이론을 포함하고, 고객의 행동과 조직 내부와의 관계를 해석하는 고객의 행동관점과 기업/기업/고객간의 상호 연관 관계의 의존을 해석하는 네트워크 관점의 관계 마케팅 이론(Relationship Marketing Theory)을 포함하며, 비즈니스를 수행하면서 축적한 지식, 비즈니스 관행과 기업의 일반적인 프로세스를 포함하며, 그리고 퍼트(PERT)와 칸트 차트(Gantt Chart)를 이용하는 전략 시나리오가 추가적으로 포함한 것을 특징으로 하는 비즈니스 모델 구축 방법.
제 4항에 있어서,

상기 비즈니스 모델을 구축하는 단계별 방법으로,

이벤트에 의하여 발생된 클러스터(Cluster)를 식별하고 정의하는 정의 단계(31);

클러스터의 정의를 근거로 클러스터에 속성을 부여하고 클러스터를 분류하는 속성과 분류 단계(32);

클러스터의 속성에 따라 비즈니스 시나리오를 작성하여 클러스터들을 연결시키는 시나리오 단계(34);

시나리오를 근거로 객체간의 커뮤니케이션과 객체의 모듈화를 위한 최적화와 기능적인 설계를 하는 모듈 단계(36);

클러스터와 모듈을 근거로 보안을 적용하는 보안 단계(38)를 구비한 것을 특징으로 하는 비즈니스 모델 구축 방법.
제 5항에 있어서,

상기 비즈니스(Business) 모델을 구축하는 방법에 있어 정의 단계, 속성과 분류 단계, 시나리오 단계, 모듈 단계, 보안 단계를 일부분 적용하거나 또는 단계를 반복적으로 적용하는 비즈니스 모델 구축 방법.
제 5항에 있어서, 상기 정의 단계는

클러스터를 구성하는 주요 객체 관점에 따라 클러스터를 식별하고 정의하는 방법으로 고객과 기업의 거래 형태와 유형을 사회 통계 또는 고객 세그먼트와 고객의 라이프사이클을 기준으로 하는 고객 관점, 기업 내부 프로세스와 연관되는 리소스 관점, 시스템과 개발에 필요한 기술 관점 그리고 마케팅과 캠페인 활동을 주도하는 기업 관점이 포함된 비즈니스 모델 구축 방법.
제 5항에 있어서,상기 속성과 분류 단계는

클러스터의 속성에 따른 분류 방법으로 비용을 유발하는 장치와 장비 그리고 인력에 따라 클러스터를 분류하는 방법과,

작업의 진행 과정에 따라 시작, 완료, 중간 과정에 따른 클러스터를 분류하는 방법과,

시간의 변수에 따라 시작과 완료를 예측할 수 있어 예정 완료 작업 시간을 줄 수 있는 클러스터와 시간의 변수를 적용할 수 없는 클러스터로 나누는 방법과,

이벤트 작업의 주체에 따라 사람 수행하는 클러스터, 기계가 수행하는 클러스터 그리고 정보 시스템이 수행하는 클러스터로 분류하는 방법과,

이벤트를 발생된 문제를 해결하는 주체에 따라 엔티티의 요구를 대처하여야하는 수동적인 클러스터, 엔티티에 영향을 주고자 전략 수행하는 능동적인 클러스터, 새로운 전략 수립과 결과 분석 등의 내부 관리의 목적에 내부 관리 클러스터 그리고 시스템의 판별과 제어의 목적인 조건 클러스터로 분류하는 방법이 포함된 비즈니스 모델 구축 방법.
제 5항에 있어서, 상기 시나리오 단계는

시나리오를 작성하는 방법으로 칸트 차트(Gantt Chart)와 퍼트(PERT)처럼 외부 또는 내부에서 발생한 하나의 이벤트에 대하여 동시 다발적으로 여러 조직에서 같은 목적을 위해 움직일 수 있도록 관련된 모든 이벤트와 클러스터 그리고 클러스터내 객체들의 행위를 관리하는 방식과 일반적인 프로세스처럼 시간에 대하여 관리 없이 이벤트들을 엮어 시나리오로 만드는 방식이 포함된 비즈니스 모델 구축 방법.
제 5항에 있어서, 상기 모듈 단계는

클러스터를 구성하는 객체들을 별도 모아 최적화하게 되고 필요한 분석과 설계 작업을 포함하고,

이벤트에 의하여 유발된 클러스터를 기준으로 분석과 설계 작업을 포함하며,

이벤트리스트와 관련되어 이벤트에 대해 필요한 파라미터 제공과 관련된 분석과 설계 작업을 포함하는 비즈니스 모델 구축 방법.
제 5항 또는 제 10항에 있어서, 상기 모듈 단계는

시스템을 구성하는 3가지 계층 구조에 따른 모듈의 분리와 설계 작업에 있어,

각각 이벤트 내 객체간의 커뮤니케이션과 접촉하는 수단에 있어 인터넷의 웹 브라우저(Web-Browser), 전화, 금융기관의 ATM 단말기, CTI와 같은 자동응답 시스템, PDA, 무선 인터넷, 무선 전화기와 같은 기기의 특성과 제어하는 제어 모듈과 화면을 구성하는 디스플레이 모듈로 각각 세부 분리와 설계 작업을 포함하고,

클러스터를 대표하는 마스터 모듈과 이벤트리스트에서 클러스터간의 연관 관계를 표시하는 모듈 또는 데이터베이스 내 프로시저(Procedure)와 트리거 (Trigger)로 세부 분리와 설계 작업을 포함하며,

클러스터 내 객체의 행위를 나타내는 모듈이나 메소드(Method)들로 이루어진 라이브러리로 분류하는 모듈의 세부 분리와 설계 작업을 포함하는 비즈니스 모델의 구축 방법.
제 5항에 있어서, 상기 보안 단계는

클러스터와 객체 그리고 디스플레이 모듈에 대한 권한을 갖은 담당자에 의하여 조회, 입력, 수정, 삭제의 기능을 제공하는 수단과,

이벤트, 이벤트리스트, 프로젝트와 프로세스의 시작에서부터 완료까지 추적하고 관리하는 기능과 그에 따른 권한을 부여하는 수단을 포함하고,

작업 진행이 유보되어 있는 개별 이벤트, 이벤트리스트, 프로젝트와 프로세스에 대한 처리 수단을 별도로 구비한 비즈니스 모델의 구축 방법.
상기 비즈니스 모델 구축 방법을 적용한 관계관리 시스템은,

사용자의 단말기 또는 다른 시스템에서 요청 작업에 대하여 클러스터와 연결하여 동시적으로 수행하여야 하는 클러스터들과 순차적으로 작업하여야 할 클러스터들에 따라 클러스터와 연결되어 있는 모듈들 또는 라이브러리에서 하나 이상의 실행 모듈을 호출하고 실행을 감독하는 수단이 포함된 것을 특징으로 하는 관계관리 시스템.
상기 비즈니스 모델 구축 방법을 적용한 관계관리 시스템은,

상기 사용자의 단말기 또는 상기 다른 시스템에서 요청 작업 내용을 기록하는 수단을 포함하여, 에러 처리에 있어 상기 기록된 자료를 이용하여 클러스터 단위별로 백워드(Backward)와 포워드(Forward)의 자료 복구 수단이 포함된 것을 특징으로 하는 관계관리 시스템.
제 13항에 있어서, 상기 클러스터들간의 정보 교류하는 수단으로,

이벤트에 의한 파라미터 방식으로 클러스터 내 객체들간의 직접 작업을 의뢰하는 수단과, 인터페이스 파일을 사용하여 배치(Batch) 형태로 클러스터 간의 자료와 정보를 제공하는 수단과, 클러스터 내 소속된 개별 객체의 정보와 지식 축적과 공유를 통한 간접 정보 교류하는 수단이 포함된 관계관리 시스템.
제 13항 또는 제 14항에 있어서,

이벤트 요청 내역과 클러스터, 이벤트리스트, 프로젝트 그리고 프로세스의 작업 결과와 에러 내용을 기록하는 수단과,

클러스터 단위별로 에러 발생에 따른 복구 그리고 이벤트리스트 및 클러스터의 사용 정지 및 해지의 수단이 추가적으로 포함하고,

사전에 정한 프로세스와 프로젝트의 시나리오를 기준하여 클러스터와 클러스터를 연결하고 관리하는 수단과,

각각의 클러스터의 작업 수행 일정에 따라 개별 담당자에게 일정과 작업과 관련된 정보를 제공하는 수단을 추가 포함하고,

담당자와 조직의 퍼포먼스 평가 수단이 추가 포함된 것을 특징으로 하는 관계관리 시스템.
제 13항에 있어서,

상기 사용자의 단말기 또는 상기 다른 시스템에서 요청 작업 가운데 직접 실행 모듈을 호출하는 수단과,

별도 상기 사용자의 단말기 또는 상기 다른 시스템의 요청 없이 사전에 정해진 클러스터의 기능에 따라 주기적으로 필요한 모듈들을 호출하여 작업을 수행하는 수단을 포함하고,

상기 사용자의 단말기 또는 상기 다른 시스템의 요청으로 클러스터에서 별도 모듈의 호출없이 자체 클러스터와 프로세스의 관리 기능만으로 필요한 정보와 기능을 요청한 시스템에 결과를 전송하는 수단을 추가로 포함하고 있는 관계관리 시스템.
상기 비즈니스 모델 구축 방법을 적용한 관계관리 시스템은,

사용자의 단말기에 직접 접속하여 단말기를 제어하고 사용자와 커뮤니케이션에 필요한 화면을 전송하는 기능을 수행하는 디스플레이 모듈(510)들을 포함하고,

상기 디스플레이 모듈(510)과 연결하여 디스플레이 모듈들이 요청하는 개별 클러스터의 작업 또는 요청 작업에 대하여 조건에 따라 클러스터와 연결된 실행 모듈을 호출하고 작업 환경을 제공하며 또한 감독 수행하는 각각의 클러스터를 대표하는 마스터 모듈(530)들을 포함하고,

상기 마스터 모듈(530) 및 상기 디스플레이 모듈(510)과 연결하여 작업을 수행하는 실행 모듈은 일반 프로그램 개발 언어로 작성된 어플리케이션 모듈(540)이 포함된 것을 특징으로 하는 관계관리 시스템.
제 18항에 있어서, 상기 어플리케이션 모듈(540)을 구성하는데 있어,

객체지향의 클래스 및 메소드 또는 장치나 시스템에서 사용하는 시스템 모듈그리고 데이터베이스의 프로시저(Procedure) 및 트리거(Trigger)가 추가로 포함하는 관계관리 시스템.
제 18항에 있어서,

상기 디스플레이 모듈(510)과 연결하여 작업 수행을 위한 마스터 모듈의 정보(파라미터, 모듈 위치) 관리 기능, 각각 클러스터와 연결되어 동시적으로 수행하여야 하는 클러스터들의 정보, 순차적으로 작업하여야 할 클러스터들의 순서를 기록하고 있는 이벤트리스트에 관한 정보 관리 기능, 이벤트 요청 내역과 작업 결과에 대한 기록 관리 기능, 에러 발생에 따른 복구 기능, 이벤트리스트 및 클러스터의 사용 정지 및 해지 기능, 디스플레이 모듈과 마스터 모듈을 엮는 작업 기능 그리고 디스플레이 모듈이 요청하는 작업에 대하여 관련된 클러스터의 마스터 모듈을 연결시켜주는 기능이 별도 구비되어 있는 모듈(이하 "이벤트 모듈"이라 한다.)들을 추가로 포함하는 관계관리 시스템.
제 18항 또는 제 20항에 있어서,

상기 디스플레이 모듈, 상기 이벤트 모듈 및 상기 마스터 모듈 그리고 상기어플리케이션 모듈들이 제공하는 기능들에 대해 모듈들간의 구분 없이 혼재되어 있는 관계관리 시스템.
사용자의 단말기(6100)(6500)를 포함하여,

상기 사용자의 단말기 요청에 따라 단말기 기능 제어와 디스플레이 기능을 지원하는 디스플레이 서버(6200)를 포함하고,

상기 디스플레이 서버(6200)와 상기 사용자 단말기(6500)와 연결하여 클러스터(Cluster)와 클러스터의 네트워크에 관한 정보를 관리하고 디스플레이 모듈이 요청하는 클러스터를 연결시켜주는 이벤트 서버(6300)와,

상기 이벤트 서버(6300)와 상기 디스플레이 서버(6200)와 연결하여 클러스터 내 객체의 로컬 데이터 및 모듈을 보관하고 관리하며 직접 모듈의 실행을 담당하는 어플리케이션 서버(6400)로 구성하여 이벤트 모델과 관계 이론이 요구하는 기능적인 요건을 충족시키는 관계관리 시스템.
제 22항에 있어서,

상기 어플리케이션 서버(6400) 또는 상기 이벤트 서버(6300)와 연결하여 개별적인 데이터를 보관하고 관리하는 데이터베이스 서버(6600)가 추가로 포함하는 관계관리 시스템.
제 22항에 있어서,

상기 어플리케이션 서버(6400) 또는 상기 이벤트 서버(6300)와 연결하여 모듈 또는 메소드의 보관과 관리를 위해 별도 서버가 추가 포함된 관계관리 시스템.
제 18항 또는 제 22항에 있어서, 상기 사용자의 단말기는

PDA, 핸드폰, PCS, 유/무선 인터넷에 접속하여 사용하는 장비, ATM 단말기(Automatic Teller Machines), 음성응답시스템, 카드 리더기 그리고 기업의 정보와 서비스를 제공받을 수 있는 기기를 포함하는 관계관리 시스템.