Enterprise Application

9/20/2007

Enterprise Application Integration

406.306 Management Information Systems

Jonghun Park jonghun@snu.ac.kr

Dept. of Industrial Engineering

Seoul National University

Requirements of e-Business

 Crucial business objective in today’s event-driven Digital Economy

 Demand for products/services translates into satisfied demand in almost real-time

 Supplying systems are instantly aware of demand and are able to react

 Demanding systems are instantly aware of supply capability and are able to react

 For this to occur …

 All participating systems are able to communicate in any direction, with any system.

 All relevant information in any participating system is accessible by any other participating system.

 Sharing of data and business processes among connected applications and data sources, both within & between companies

application integration imperatives

 mergers

 acquisitions

 decentralization

 outsourcing

 reorganization of internal structure

 adopting new technologies

What is Interoperability?

 Interoperability means the ability of two or more applications to pass data and services to each other

 Interoperability is a serious impediment to developing cross enterprise (e-Business) applications

 Interoperability needs increase the complexity of building and maintaining application programming interfaces (APIs) & shared services between enterprise applications that cross enterprise

boundaries increase substantially.

The Application Integration Imperative

Business reality today: Corporate Islands of automation

Data flow to user

Purchasing system

Sales tracking system

Financial systems

Inventory &

manufacturing systems

Human Resources systems Purchasing Sales Financial Manufacturing Human Resources

Data flow to user Data flow to user Data flow to user Data flow to user

islands of data / islands of automation

 islands of data

 each island of data has its own meaning of biz objects, such as customers, invoices, shipments, and sales

 there is data replication between the islands, creating data consistency and integrity problem

 none of the islands contain complete information about business objects, making it necessary to integrate data from multiple islands to create a unified enterprisse-wide view of biz objects

 islands of automation

 each island automates only a limited and selected set of activities

 there is duplication between process contained in different islands of automation, which require synchronization and coordination between

Interoperability Problems

 e-Business implementations automate only a small portion of the business transaction process. For example:

 Ordering & distribution of goods can be fast but the supporting

accounting & inventory info., payment & funds transfer lag as there is no communication between business processes and legacy data.

 This decoupling of accounting & payment info. from the ordering &

delivery of goods & service, increases transaction credit risks &

introduces discrepancies between the various information sources, requiring expensive & time consuming reconciliation.

 Electronic business must be based on a common set of protocols that ensure interoperability

 OAGi (Open Application Group): an ERP vendor based organization for interoperability standards at business process level

target applications

 need to integrate not only internal applications and processes but also to extend this integration to the suppliers, partners, and customerrs

 why integration is complex

 lack of common business and technical architectures

 lack of common definition of the business concepts that underlies the different sources to be integrated

What is EAI?

 a key enabling technology that has emerged to help organisations achieve intra-enterprise integration

 seeks to eliminate islands of data and automation caused by disparate software development activities and to integrate custom and package apps

 a strategy that does not specify products, tools or technology for its inception. It is an on-going process, utilising new technologies

within the IT infrastructure to allow applications to mirror the ideal workflow of the business

 the goal of EAI is to encapsulate the enterprise in a single virtual

application of heterogeneous and autonomous parts working together in a cohesive system

characteristics of EAI

 EAI provides the infrastructure to reuse, rapidly connect, interface &

unify information and BPs between an organisation's internal applications into a cohesive corporate framework within the enterprise

 EAI represents both the products as well as the process of integrating new & legacy applications (including packaged applications) with data files & databases

 EAI is primarily about integrating custom & package applications and map data between apps to drive operational efficiency within the corporation

 EAI seeks to enable enterprises to react with consistency and speed through access to biz inf. in real-time

REQUIREMENTS

Internet /

Virtual Private Network

•Configurable across applications

•Loosely coupled

•Supports an incremental approach

•Standards based integration

•Business process oriented

•Scaleable, available, secure, manageable Trading Partners

Suppliers Distributors Business Partners

Heterogeneous Platforms ERP Systems

In-house Proprietary Apps Legacy Applications

e-Bizi (external) vs. EAI (internal)

Typical Product Suites in EAI

 A message (integration) broker (i.e., a set of services for transformation and routing).

 Various development tools for specifying the transformation and routing rules.

 Tools for building adapters into applications

 Off-the-shelf adapters

 Monitoring, administration, and security facilities, and

 Message-oriented middleware, business process management facilities and portal services.

topologies for EAI

 point-to-point

 pub-sub (shared bus)

 hub and spoke

E-Commerce

Web Server Accounting

Order Management

CRM ERP

Logistics

Sales Automation

Point-to-point

 Applications are linked through hand-coded,

custom-built connectivity systems & data

interchanged directly between any two systems

 The approach is to "build an interface" for each

connection.

 The point-to-point

approach is not scalable:

n*(n-1)

 Hard to manage

Publish/Subscribe

 no centralized message server to coordinate the distribution of messages

 Publish/subscribe technologies use subject or topic names as the loosely coupled link between publishers and subscriber

systems

 Publishers produce messages on a particular subject or topic

name and subscribers receive those messages by registering interest in the subject name.

 Modern publish-subscribe EAI messaging tools are based on the multicast model where

messages are published by being sent once & are received

simultaneously by all subscribers

 growth rate of 2n

E-Commerce Web Server

CRM ERP Logistics

Sales Automation Order

Management Accounting

Network/Shared Bus

Adapter

Adapter Adapter

Adapter Adapter Adapter

Adapter

receive( ) receive( )

send( )

E-Commerce Web Server

CRM ERP Logistics

Sales Automation Order

Management Accounting

Message Oriented Middleware

&

Integration Broker Adapter

Adapter Adapter

Adapter Adapter Adapter

Adapter

receive( ) receive( )

send( )

Hub & Spoke

 A central node manages all interactions between applications. Each application does not have to integrate multiple times with several other applications, it simply carries out one integration process on the central node.

passive vs. active app integration

 passive application integration

 existing applications and systems are integrated and communicate with each other without end-user interaction

 supported by traditional MOM and message-oriented products such as integration brokers

 rely on an async. application architecture

 any external application that need to be integrated has to be event- enabled

 active application integration

 end-users interact with BPM workflow to drive the execution pf BPs and transactions

 BPs are composed of a frequently changing combination of human and automated tasks using an end-to-end BP model

 offers a combination of sync and async delivery

EAI Integration Layers

Data Integration Layer API

Integration Layer Business

Process

Integration Layer

transportation layer

 handles connectivity to an application and transports data to it from other applications

 provides message encryption and network connectivity

 typically includes TCP/IP

 when communicating across enterprises the common means of

transport occurs through the use of HTTP that operates over TCP/IP connections

Data Integration Layer

 refers to the ability to exchange relevant business data from the applications available and integrate it with other such related data items despite differences in data formats, structures and intended meaning of business terms under possibly diverse company

standards.

 deals with moving data between multiple databases and solves the problem of sharing data across multiple applications created by implementing numerous proprietary back-end systems.

 used when the applications do not provide any APIs or client

interfaces, and developers understand how business operations affect an application’s data schema

 It is not simply the differences in data formats or interfaces that

mechanisms for data level integration

 staged integration

 source data is exported into an intermediate format for eventual transformation and importing into the new target application’s data structures

 limitations: data latency, inconsistency, and cost overhead

 data replication

 a synchronous process whereby triggering mechanisms are employed to automatically transform and copy data from the source application to the target application on the basis of business rules

 data federation

 create a virtual integration model so that applications can access

schemas and data from different data sources using the same interface

 provides a single integration portal accessing all enterprise data

 data integration servers (data portal)

 provide data access, transformation, and movement



Application#1 Application#2 Application#N

Common API

API Integration Layer

 concentrates on the sharing of business logic between applications

 It differs from the data integration level as the interface is created with the application rather than its underlying database

 APIs: hooks that can be used to connect to an app to invoke its biz logic and retrieve its underlying data

characteristics of API integration

 API level integration is synchronous in nature, and inherently point- to-point integration

 examples of APIs

 component interfaces such as CORBA, DCOM, or JavaBeans

 TP interfaces such as IBM’s CICS or BEA’s Tuxedo

 Packaged app interfaces such as SAP’s Business API (BAPI)

 disadvantages

 tight application coupling in front-end components (applications)

Data-driven Vs. Process Driven Integration

 Data view (tactical point2point application integration)

 Traditional approach is to integrate disparate applications & business processes by mapping data to a “standard” format & then routing it from one application to another

 Failure to provide a unified view of data

 Inability to handle conceptual mismatches

 Difficulties to scaling to the enterprise level

 Process integration is treated as a feature of data management

 Process view (strategic functional level integration)

 Clarifies which data & services are needed from pre-existing data &

their underlying applications

 It creates a new supervisory application that drives the entire process

BP integration layer

 to automate business processes which need to access data and business logic across disparate back end applications

 the ability to define a commonly acceptable business process model that specifies the sequence, hierarchy, events, execution logic & information movement between systems residing in the same enterprise (viz. EAI) & in multiple interconnected enterprises (eBI)

 an integration solution that provides enterprises with end-to-end visibility and control over the contributing parts of a multi-step information request or

transaction, which include people, customers, partners, applications, and DBs

 builds builds on middleware providing:

 EAI to ensure business processes are executed in the defined order using the required data

 process execution engine

 visual process definition tools

 process monitoring tools

Receive order

Allocate inventory

Ship products

Bill customer

Business Process flow-level

Information flow-level

Graphical

specification-level

Business analyst – Process designer

Sales order entry

Web server

Order mgt

Billing

Inventory mgt

Shippin g

CUSTOMER ENTERPRISE

DISTRIBUTION PARTNER

confirm shipment check inventory

confirm inventory

Business Process Integration Scenario

requirements for BPI

 dividing applications into distinct parts for front and back-office tasks

 defining BPs that implement the overall enterprise functionality

 ultimately leads to a loosely coupled architecture whereby back-

office apps do not communicate directly with fron-office apps, they rather communcate with each other through processes and they do not need to have specific knowledge of one another

Modelling

Integration

Analysis &

Monitoring Business

Process Management

Business Process Management

 extension of BPI with management aspects

 a commitment to expressing, understanding, representing, and managing a business in terms of a collection of BPs that are responsive to a business environment of

internal or external events

 BPM solution: a graphical productivity tool for modeling, integrating, monitoring, and optimizing process flows of all sizes, crossing any applications, company

boundary, or human interactions

 active vendors: IBM (WebSphere), HP (HP Process Manager), BEA (WebLogic), MS (BizTalk), Vitria (BusinessWare)

workflow, EAI, and BPM: a comparison

 workflow

 models and automates “long-running” processes lasting days or even months

 tends to relegate integration functions such as synchronizing data between disparate packaged and legacy apps, to custom code within its activities

 tightly coupled with enterprise apps, not good at connecting cross-enterprise systems together

 EAI

 has not tried to automate long-running end-to-end processes involving many steps, nor include interactive activities in which a person does some work and make a decision

 BPM

 provides an infrastructure that may cross enterprise boundaries

 manages and automates processes that have both human and system related tasks

 places considerable emphasis on management and business functions (compared to workflow)

 can be considered as the convergence of workflow, EAI, and unstructured adhoc processes

EAI and WfMS

 EAI tackles the composition problem from the side of heterogeneity to make all components look alike and therefore easier to integrate

 Workflow technology focuses on the workflow language and on the management of the workflows that perform the integration

 Conceptually all workflow steps can be assigned to the same “resource” – the WfMS/EAI adapter

message broker

SmartQuotation

adapter database ^{adaptere-mail} adapter SmartForecasting

adapter XYZ

adapter WfMS adapter

WfMS

Web server based approach for B2Bi

serverweb

internal infrastructure

supplier customer

serverweb

internal infrastructure internal

infrastructure internal procurement

requests B2B interactions

occur by

accessing Web pages, filling Web forms, or via email.

Limitations of conventional middleware for “global workflow”

 No obvious place where to put the

middleware

 Lack of trust

 Autonomy

 Confidentiality

internal infrastructure

supplier customer

warehouse

internal internal procurement

requests

message broker

WfMS adapter

WfMS a “global” workflow is executed here

the combination of message broker and adapters enables interoperability

third party

customer’

adapterss

warehouse’s adapters

supplier’

adapterss

An alternative approach: P2P

internal infrastructure

supplier

warehouse

middleware for supplier-customer

interaction middleware for supplier-warehouse

interaction middleware for

supplier-XYZ interaction

middleware for integrating the middleware

customer

another party (XYZ)

yet another party (ABC)

middleware for supplier-ABC

interaction supplier’s

adapters supplier’s

adapters supplier’s adapters

SOA for the previous example

internal infrastructure

supplier customer

internal infrastructure internal

infrastructure internal procurement

requests

internal functionality made available as a service

serviceWeb serviceWeb

serviceWeb

interactions based on

protocols redesigned for peer to peer and B2B settings

languages and protocols

standardized, eliminating need for many different middleware infrastructures (need only the Web services middleware)

Web services and EAI

 Web services as wrappers

 Entry points to the local information system

 provide homogeneity of components

 Currently most widely deployed application of Web services

 In the future, software applications might come out of the box with a Web service interface -> No need for adapters!

Web services and EAI

DBMS applications

Web service-enabled broker

sendmail application

SmartQuotation SmartForecasting XYZ

integrating application (contains the composition logic)

Company A (or a LAN within Company A)

synchronous vs. asynchronous communication

 timing is an important element of the app integration infrastructure

 infrastructure services related timing

 scheduling

 events

 interaction model

 models for interaction between the apps

 request and reply

 conversational (n-step, synchronous)

 publish and subscribe

 asynchronous

implementing business process level EAI

 two types middleware products commonly used for implementing BPI

 integration brokers

 applicarion servers

integration broker based process-level integration

 an integration broker, built primarily on MOM, provides an end-to- end integration platform to completely automate business processes across the extended enterprise. It provides:

 wide-ranging, pre-built application adapters, and bi-directional connectivity to multiple applications

 data translation and transformation mechanisms

 asynchronous processing behaviour

 support of send & receive messages & status info

 message transformation through self describing (meta) data

 simultaneous bridging of multiple middleware products

 use of a uniform interface to provide seamless access to each

application based on its own syntactical & semantic requirements

 ability to allow transaction recovery in a consistent format

 intelligent routing: routes messages based on message content

Legacy Systems

 Computing systems that are obsolete in some manner and typically not easy to modify or modernize

 A pejorative term for computing systems that

 run on obsolete hardware and nonstandard communication networks

 run poorly documented, unmaintainable software

 consist of poorly modeled databases on hierarchical or network DBMSs

 support rigid user interfaces

 Legacy systems are important for us precisely because they are not cooperative!

How Legacy Systems Arise

 Proprietary software

 not documented

 not supporting industry standards (vendors who hope to lock in the market through incompatibility)

 Semantics embedded procedurally in the code

 Ad hoc changes to software in response to

 changing requirements, because of changes in laws, regulations, competition, or other business needs

 bugs

Legacy Systems

 Negative

 Difficulties in reuse and sharing of data and programs cause redundancy, wasted effort, and integrity violations

 Closed: typically, use a vendor’s proprietary software, and cannot cooperate with other systems

 Positive

 Fulfill crucial business functions

 Work, albeit suboptimally

 Run the world’s airline reservation systems

 Run most air traffic control programs

 Have dedicated users

 Represent huge investments in time and money

system

Adapter

 An adapter is a component that resides between the message broker and the source/target systems

 Simplify complexity of end system interface through an abstraction layer

 Thin adapters - simple wrappers

 Thick adapters

 Programmable

 Abstract representation of services and meta-data

 Centralized adapters co-located with broker

 Distributed adapters execute in own process and may be located with source/target systems/target

Adapters for application data access

 Adaptor (aka connector, bridge)

 a set of software services for connecting and accessing application data

 integrates with the application through the DB access, designated APIs or other points of interfaces

 Progression of adapters

 Simple APIs

 Design-time connectivity services

 Open standard (J2EE-CA)

 improves interoperability

 Agent adapters

Adapter patterns (cont.)

 Database access pattern

 when applications store data in a RDB

 polling or event-based stored procedures

 most common, but at the risk of contaminating data

 Interface file exchange pattern

 when end application provides import/export tables

 protects integrity, but low latency

 Remote method call pattern

 when end application provides a RMI type interface for data access

 a callback can be registered

 e.g. SAP’s Remote Function Call (RFC), Business API (BAPI)

Adapter patterns (cont.)

 User interface protocol pattern

 obtains access to the application data through the user interface (screen scraping, screen stuffing)

 mainly for access to legacy applications

 the adapter generates components that emulate the specific user interactions

Java Classes

for 3270 Screen

TN3270 Session Recorder

User Session 1. Record

user session 2. Generate

classes

3. Load 4. Execute classes and drive

Adapter patterns (cont.)

 Socket-queue pattern

 when applications provide a socket or message queue as a point of asynchronous interface with external systems

 useful for applications that use MOM as a messaging backbone

 the adapter essentially provides a listener interface

 may use a polling or publish-subscribe mechanism

Adapter patterns (cont.)

 Transactional proxy pattern

 when applications are hosted in a TPM (e.g. CICS on mainframe or Tuxedo on UNIX)

 interacts with the application through a TPM proxy

CICS Adapter

Stub

CICS Adapter

CICS Proxy

Target CICS program

Source CICS TS

Queue CICS region

NT/UNIX OS/390

TCP/IP Control Block

J2EE connector architecture (J2EE-CA)

 A common mechanism for J2EE Apps to manage application connectivity in a consistent, scalable, and secure fashion

 To provide

 a common way of accessing various enterprise applications  i.e., a connector for a given EIS will work with any number of J2EE-compliant applications

 rich services to support enterprise application connectivity

 a basis for interoperable connectors running within a J2EE platform

EJB Component

Resource

Adapter EIS

EJB contract

System contract

CCI (Common Client Interface)

Sales adapter

Inventory mgt adapter Product

data adapter

OrderMgt adapter

Billing adapter

integrating application

(contains busines composition logic)

Application integration Business Processes Business Rules

Meta-data

Data Transformation Message Routing

Integration Broker

integration broker for BPI

advantages and disadvantages of IB based BPI

 advantages

 reduction of app integration effort by providing pre-built functionality common to many integration scenarios

 reuse in terms of middleware infra and the app integration logic

 disadvantages

 inability to automatically define implementation level data flows

between distributed application instances: manually configured typically using JMS, MQSeries

 inability to easily define ad-hoc workflows and distributed apps (i.e., component composition) across multiple component models and

platforms deployed within an organization

 inability to easily configure different adapters and apps participating in an integration

 end-to-end transactions are not supported due to the asynchronous messaging nature -> use of compensating transactions

An example of application integration with IB

 The problem of EAI appears when all the different steps of business procedures are to be combined into a coherent and seamless process

 e.g., quotation, order processing, and order fulfillment

 Responding to an RFQ may involve checking the availability of the product, their production schedule, and even with suppliers for delivery dates and prices

 Each of the steps is likely to be implemented and supported using a different information system

 Different OS, different interfaces, different data format, different security requirements, different protocols and interaction models

 The systems to be integrated are typically owned and operated by different departments within a company

EAI with IB

 Two fundamental components

 Adapters

 map heterogeneous data formats, interfaces, and protocols into a common model and format

 hide heterogeneity and present a uniform view of the underlying heterogeneous world

 Different adapter is needed for each type of application

 Message broker

 facilitates the interaction among adapters

DBMS

message broker

SmartQuotation

adapter e-mail

adapter database

adapter SmartForecasting

adapter XYZ

adapter

integrating application (contains the composition

logic)

IB-based application integration

 Developing an application (often in Java or C) that implements the integration logic

 The application interacts with the message broker

 Configuring the adapters so that they subscribe to the appropriate messages and perform the appropriate action on the back-end system

 At systems startup time

 A: subscription to message quote

 B: subscription to message quoteRequest

 C: subscription to message newQuote

 At runtime

 1: publication of a quoteRequest message

 2: delivery of message quoteRequest

 3: synchronous invocation of the getQuote function

 4: publication of a quote message

message broker

SmartQuotation

adapter SmartForecasting adapter

RFQ processing 1

A 6

B 2 4 C 7

3

5

8

typical IB products

 IBM MQSeries Integrator

 Extricity

 BEA eLink

 WebMethods B2B Enterprise

 Mercator Enterprise Broker, WebBroker, CommerceBroker

 NEON eBusiness Integration Servers

 SeeBeyond eBusiness Integration Suite

 Tibco ActiveEnterprise

 ActivePortal and ActiveExchange

 Vitria BusinessWare

 CrossWorlds Software

 MS BizTalk

Application Server Process-level Integration

 ASs

 a collection of services that support the development, run-time execution, and management business logic for web-enabled applications

 enable the separation of business logic from interface processing, and also coordinate many resource connections

 offer critical features such as secure transactional execution env, load

balancing, app-level clustering across multiple servers, failover management, ...

 provide Web connectivity for extending existing solutions and bring transaction processing mechanisms to the Web

 provides programming language support & an integrated development

environment. Doesn’t deal with heterogeneity. Info. sources can be switched without affecting the application too much and clients can be changed at will (promotes loose coupling).

 ideal for portal-based EAI development

Component Wrapper

Component Wrapper Component

Wrapper

Application server

Application development tools

ERP application Adapter

Distributor data

Adapter Adapter

CRM application Web server Front-end of many EAI initiatives,

(i.e. composites)

Application connectivity Business Processes Business Rules Security

Transaction Mgt Message Routing

Java/EJB-based client

Web-based client

CORBA/COM -based client

responsibility fo ASs

 message routing

 data transformation: wrapped EIS components appear as objects within the AS

 meta-data support

 business process and business rules support

 transaction support: employs 2PC protocol

 component support

 WAS already provide DB connectivity, transaction management,

EAI-style connectors, message queueing, and are gradually evolving into business process execution engines

advantages and disadvantages of AS based BPI

 advantages

 facilitates reliability, scalability, and availability, while at the same time automating application development tasks

 relieves application developers from the need to develop complex low- level middleware services and lets them concentrate more on coding business rules, creating and reusing BPs

 end-to-end transactions can be implemented

 disadvantages

 not strong in providing back-end integration or app-to-app integration

 no support for data transformation between different data structures and semantics, rules-based and syntax validation and intelligent routing of data

 do no provide functionality such as long-lived transaction support, time- based exception handling, real-time monitoring and analysis of running processes, and dynamic management and change of the processes

 all processing occurs synchronously (if async comm is not supported) -

> long-lived processes can starve AS resources

typical AS vendors

 BEA

 HP

 IBM

 Oracle

 Sun

 Borland

Object Request Broker Integration broker Application

server

Business process API

Web presence EAI-type Transport Transaction Translation Timing Integration rules

asynch No Passive No Yes Yes Yes Yes Yes Yes synch/

asynch Yes Active Yes Yes Yes Yes Yes Yes Yes

synch No

Coupling

Loose Loose

Tight

Passive No Yes Yes Yes No Yes Yes Communication mode

comparison of AS, IB, and ORB

 ASs are the most flexible infrastructure that can be considered as the infrastructure that targets e-Biz app integration

case study: BPMS

BPMS (business process management system)

 BPM

 a field of knowledge at the intersection between management and IT, encompassing methods, techniques and tools to design, enact, control, and analyze operational business processes involving humans,

organizations, applications, documents and other sources of information

 BPMS

 executes process models, automatically delivering work to a relevant participant

 includes process modeling tools, external integration facilities, sophisticated user interfaces, and powerful analytics

 objectives

 continuous improvement of BPs: automation and optimization

process digitization

reasons for adopting BPMS (source: Delphi Group, 2003)

dimensions of business processes

 process logic: describes what in terms of which activities are to be performed and in which sequence they need to be performed

 organization: describes the organizational structure of the company in terms of departments, roles, and people; define who

should perform each activity

 IT: describes which IT resources, such as programs that perform a particular activity

People

Process

Technology

W³

integration as a key to business agility

 Business Users

 Business Processes

 Business Applications

 Data Access

 Data Transformation

 Data Synchronization

 Data Quality

EAI

BPM

major IT hype cycle (Gartner, 2005)

BPMS genealogy

BPMS = EAI + Workflow + a

Groupware: H2H EAI: A2A

BPMS: {H,A}2{H,A}

Applications Database Applications

Rules Services

Flows

Services Flows

Data Rules

Database Applications

Rules Flows

evolution of BPM Suites (Gartner, 2004)

Database Applications

Rules Database

Applications

Data Application Presentation

Data Application Business Process

Presentation

BPMS

Engine Web Service

WAS Transaction

EAI / Adapters

Enterprise Portal

Customer Partner Manager Employee

Admin

DBData

ERP Data

Message

(HTTP/SMTP/FTP) MES

Workflow Mgmt.

DB data

role of BPMS

웹 서 비 스 기 반 의 통 합

프로세스 개선 프로세스 정의

프로세스 분석

기간 시스템

서식

Enterprise App 문서 프로세스 실행

결재 지식 조회

재무정보 작업 리스트 시스템 통합

Long-running H2H biz flows Short-Running S2S Technical Flows

ERP KMS

전자 결재 포털

2 3

4 1

5

process management using BPMS

CPI & major components of BPMS

프로세스 실행

프로세스 분석 최적화 프로세스

정의

프로세스 모니터링

측정

자원할당

Metrics (e.g.,KPI) 수정된

프로세스

Directory Services

Rules Engine Execution

Engine Development

Env.

Process Designer Portal

Monitoring

& Analysis External

Interfaces

Integration Platform Repository

주 요 기 능

제 공

프로세스 정의 / 표준화

프로세스 매핑

• 프로세스도출/정형화/구 조화

• 그래픽 기반의 도식화

• 상호 관계 분석/정합성 검 증

프로세스 성과지표 모델 링

KPI 모델링

KPI / 프로세스 Aligning

프로세스 공유

업무 매뉴얼

프로세스 검색

BPM Process Modeler

• Swimlane Diagram

• 프로세스 Matrix

• Hierarchical/ Vertical Map

프로세스 실행

프로세스 자동화

유연한 통합을 통한 자동화 시스템 구축

프로세스 외부 실행

업무, 알람 자동 공지

동적 라우팅, 위임

다양한 이벤트 처리

진행 상황 모니터링 및 예외처리 지원

eForms 및 다양한 클라이언트 지원

Workflow

Workflow 모델러

Form designer

실행 엔진

프로세스 성과 모니터링/측정/분석

프로세스 성과 모니터링

• 프로세스 실행 추적

• KPI 성과 지표, 프로세스 성과 지표 모니터링

프로세스 측정/분석

• 시간, 비용, 자원 분석

• Raw data를 KPI로 변환

• KPI를 프로세스 성과 지 표로 변환

• 측정 결과 통계 처리

프로세스 통제

• 전략 경영 실현

• 성과 지표 변경 반영

KPI Monitor

(Data Collector, Converter)

프로세스 성과 Monitor

프로세스 관리 / 개선

개선 프로세스 도출

• 개선 프로세스 도출

• 작업량 조정

• 개선 point DSS

개선안 검증

• Simulation

• 프로세스 변화 및 KPI σ레벨 변화에 따른 Co. KPI 영향 분석

프로세스 변경

• 조직, 자원, 규칙 변 경에 따른 프로세스 관리

프로세스-KPI Analyzer

CPM/ PERT

4 main functionalities of BPMS

specifications for BP modeling

NIST: PSL, PIF

WfMC: XPDL, Wf-XML, SWAP

OMG: Workflow Facility, UML 2.0

CommerceNet

RosettaNet: PIP

ebXML: BPSS, CPP/CPA

BPMI.org: BPMN, BPML, BPQL

OASIS: BPEL (from XLANG and WSFL)

increasingly XML based

BPMS application examples

기존 IT 인프라를 활용한 프로젝트

전사적 프로세스 관리

부서 내 프로세스 관리

Application 개발 프로젝트

BPMS를 기반으로 한 application 개발

Web, mobile access, Forms 지원

기업간 프로세스 관리

B2Bi, B2B collaboration 관리

기업 내 문서관리

전자문서 관리, 전자결재 application 개발

산업분야 적용 프로세스 금융

/보험

Claim 관리, 정책관리, 예외관리, 예측, 여신/채무, 투자/보상, 신규고객처리, 대출/투자심사, 위험평가관리, BASLE II

제조

ISO 9000, 6 Sigma, 생산관리, 품질관리, 구매관리, 자재관리, 판매관리, 출하관리, Claim 처리, 물류관리, 안전관리

통신 고객관리, 영업관리, 서비스관리, 콜센터, 서비스망 관리, 대리점망 관리

유통

판매관리, 지점관리, 협력사관리,

물류관리, 구매관리, 인력관리, 고객관리, 주문/배송처리, 인사/재무

정부 /공공

민원관리, 자격증관리, 부처간 프로세스 통합, 인력관리, 구매/조달관리,

정책관리, 예산관리, 보건관리, Payroll

적용 형태

Healthcare Payer Organization Case Study

Steps In Records Update Process

case 1: 20%+ ROI

Contact insurance

company

Receive change

packet

Complete change

forms

Send to insurer

Wait for change processing Wait for

change packet delivery

Receive change request

Send change packet

Receive completed

change information

Copy info. To member form

Verify information (if necessary)

Enter info.

into central database

Prepare & mail confirmation

letter

Send info. To imaging center

Image center scans &

indexes documents

Receive confirmation

letter

Scope

case 2

 LG electronics

Processing by Rule and System

Visibility Productivityand

•11 Mega process under 5 value chain

R&D SCM

SRMCRM MGT

•Maximum TDR effect

•Top-Down approach

BPM Project

CSF

Continuous Monitoring

Well-Organized Project team Strong Sponsorship

• TDR operations in ordinary

• Adapting improved process to system

• Cooperation with SI and Vendor

• Continuous education Constant PI

• Introducing BPM in enterprise level

• Recognizing BPM as tool for biz mgmt

Gartner’s magic quadrants

SES ECM

BPM

BPMS vendor characteristics

 integration-driven vendors

 Miracom, SDS, WebMethods, Tibco

 strong at enterprise-wide process & app. integration

 workflow-driven vendors

 Real Web, HandySoft, Staffware, Ultimus

 strong at vertical industry requirements

 content Management-driven vendors

 Filenet, OpenText, Documentum

 strong at collaboration

 application platform vendors

 IBM, Microsoft, BEA

 strong at simplifying IT Infrastructure

 e.g., Microsoft workflow foundation in Vista

 enterprise application vendors