경경경경경경경

경경경경경경경

BPR 관점에서의 BPM－ Make Processes Manageable －

2

Use the power of modern information technology to radically redesign our business processes to achieve dramatic improvements in their performance

Michael HammerHarvard Business Review, July/August 1990

ⅠⅠ. . BPRBPR 과 과 BPMBPM 의 관계에 대한 고찰의 관계에 대한 고찰

Ⅱ. 프로세스 정립 및 모델링

Ⅲ. BPR 관점에서의 BPMS 도입 방법론

목차

4

BPR 에 대한 평가

BPR 의 실패와 성공과 관련된 여러가지 질문들…

BPR

Process중심의혁신

PI

BPR

Process중심의혁신

PI

1. 성공 / 실패 ?

2. 성공 / 실패의 기준 ?

3. 성공 / 실패 확인 방법 ?

4. Design 의 문제 , 실행 ( 추진력 ) 의 문제 ?

5

BPR 의 일반적인 실패 요인

새로운 IT 기술의 적용 , 분석 및 관리 능력의 향상 , 실행의 강제화가 BPR 성공의 요건이 아닐까

• 잘못된 Scope 정의( 중점프로세스의 부재 )

• 잘못된 현상 분석( 짧은 기간 /소수 인원 /Data 부재 )

• 강력한 지도자 부재

• 현업의 핵심 인력 지원 거부

• BPR 결과를 강제화 할 시스템 부재

• 변화 관리 실패( 변화를 적용하고 관리하는 Tool 또는 System 부재 )

• 지속적이지 못함 ( 일회성 )

: .

주요 실패요인

실행

분석

관리

“ 분석 ,

실행 강제화 ,

관리”

를 위한

도구 미흡

6

BPR 성공을 위한 필요 조건

“Process 관리 , 탄력적 운영 , 상시 분석 및 관리와 분석의 Feedback 구조” 를 구현할 수 있는 시스템이 필요함

분석

실행

관리

항목 기존 시스템 Needs

분석 대상 Transaction Data Process( 예 : Lead Time 분석에 의한 Neck Define, Process 준수 여부 등 )

분석 주기 단속적 (discrete) 지속적 (continuous)

탄력성 비탄력적 ( 프로세스 변화를 위해서는 기간 시스템 변화가 필요함 )

탄력적 ( 쉽고 , 빠르고 , 기간 시스템의 변화 없이 )

시스템 구조 단위 프로세스 Enterprise Process View

변화관리 프로세스 최종 결과인 지표만을 관리

프로세스 자체를 관리( 예 : Rule 준수여부 , 리드타임 ,책임소재 )

실행 형태 Pull ( 개인이 알아서 챙김 ) Push ( 시스템이 실행을 강제화 )

BPM 의 영역

7

BPM: BPR 의 주요 성공 동인

BPM 은 BPR 의 기본 사상인 “ Process 통합 , Enterprise 통합 , 탄력적인 프로세스 운영” 을 달성 , 유지할 수 있는 강력한 지원 도구임

분석

실행

관리

항목 기존 시스템 Needs

분석 대상 Transaction Data Process( 예 : Lead Time 분석에 의한 Neck Define, Process 준수 여부 등 )

분석 주기 단속적 (discrete) 지속적 (continuous)

탄력성 비탄력적 ( 프로세스 변화를 위해서는 기간 시스템 변화가 필요함 )

탄력적 ( 쉽고 , 빠르고 , 기간 시스템의 변화 없이 )

시스템 구조 단위 프로세스 Enterprise Process View

변화관리 프로세스 최종 결과인 지표만을 관리

프로세스 자체를 관리( 예 : Rule 준수여부 , 리드타임 ,책임소재 )

실행 형태 Pull ( 개인이 알아서 챙김 ) Push ( 시스템이 실행을 강제화 )

ProcessView 에서의Data 통합

제한된 탄력성

ProcessView 에서의Data 통합

제한된 탄력성

EnterpriseView 에서의

Process 통합

탄력적인 프로세스

EnterpriseView 에서의

Process 통합

탄력적인 프로세스

8

BPM 역할 요약

BPM 은 시스템에 의한 To-Be Process 의 강제화 , Process 변화에 대한 지속적 관리에 핵심적 역할을 하며 , 설계 - 실행 - 모니터링 - 분석 - 재설계의 Feedback 체계를 가능하게 해주는 좋은 도구임

BPR 수행 체계

문제점도출

ProcessRedesign

실행

Monitoring

분석

분석

BPM 의 역할

Process

Design

: Process Modeling Tool 및

Modeling 된 Process 를 보관할 수

있는 Repository 제공

실행 : System 을 통하지 않으면 업무를 수행할

수 없도록 To-Be Process 를 강제함

Monitorin

g 및 분석

: 과거 － Monitoring 및 분석을 위하여

많은

노력이 필요함

BPM － Process 상의 문제점이 바로

지표로

보이므로 별도의 노력 없이 분석이

가능함

ⅠⅠ. . BPRBPR 과 과 BPMBPM 의 관계에 대한 고찰의 관계에 대한 고찰

Ⅱ. 프로세스 정립 및 모델링

Ⅲ. BPR 관점에서의 BPMS 도입 방법론

목차

10

BPR Modeling vs. BPM Modeling

BPM 은 BPR 과 다른 모델링 방법을 가지고 있는가 ?

• Process 설계 시 BPM

Solution 이 미리 전제되어야 함

오해를 유도하는 명제들

• 프로세스 상세 설계 (Detail Design) 단계에 해당됨

• 그러나 BPM Solution 에 의하여 To-Be

Process 가 바뀌는 것은 아님

올바른 인식

11

BPR Modeling vs. BPM Modeling

BPM 이 BPR 을 대체할 수 있는가 ?

• BPM 이 BPR 을 대체할 수 있음(To-Be 설계 없이 As-Is

프로세스에 BPM 을 적용하여 문제점을 도출해 낼 수 있으므로 BPR 이 필요 없어짐 )

오해를 유도하는 명제들

• 어느 프로세스에 어떻게 BPM 솔루션을 적용할 것인가

• BPR 없이 수행된 ERP 의 실패의 교훈

올바른 인식

ⅠⅠ. . BPRBPR 과 과 BPMBPM 의 관계에 대한 고찰의 관계에 대한 고찰

Ⅱ. 프로세스 정립 및 모델링

Ⅲ. BPR 관점에서의 BPMS 도입 방법론

목차

13

도입 방법론 개요

Ⅴ. StabilizationⅣ. ImplementationⅢ. ConstructionⅡ. DesignI. Analysis

구축 이후의 문제점 해결

향후 안정화를 위한 지속적인 운영 원칙 수립

Test 를 위한 Legacy 개발 사항 적용

Test 수행

권한 설정 및 사용자 교육

BPMS 도입 범위 확정

BPR 의 To-Be 와 BPMS 간의 Gap

분석 및 해결 방안 도출

Process 상세 설계

BPMS

Prototyping

개선 기회 Grouping 을 통해High-Level To-Be

Direction 설계

To-Be Process

설계

As-Is Business

환경 및 전략 ,

Process, 조직 ,

시스템 분석을 통한 이슈 도출

이슈에 대한 근본 원인 분석 및 Best

Practice 와의 비교 분석

근본 원인에 대한 개선 기회 도출

BPMS 도입 방법론은 Analysis, Design, Construction, Implementation, Stabilization 5 단계로 나누어 설명할 수 있음

14

Stage Overview

상세 단계 － I. Analysis

목적 정확한 개선기회 포착을 통해 To-Be 설계를 위한 방향 수립

Input

전략 보고서As-Is Process, 조직 , 시스템 현황Interview 결과서Best Practice

추진 Framework

경영진 /담당자 Interview

이슈 도출 및이슈에 대한

Root Cause분석 개선 기회

도출

As-Is Process/ 조직 /시스템 분석

Best Practice 분석

비즈니스 환경 및 전략 검토

현재의 상황을 정확히 이해하고 근본원인을 도출하여 개선할 수 있는 기회를 찾아냄

Output

이슈 리스트이슈별 개선기회 정의서

Check Point

이슈가 적합하게 도출되었으며 , 이슈별 근본원인은 논리적으로 무결한가 ?개선 기회가 적합하게 도출되었는가 ?

15

Stage Overview

상세 단계 － II. Design

목적 To-Be Process 도출

Input

이슈별 개선기회 정의서

추진 Framework

개선 기회를 통해 Ideal 한 To-Be Process 를 설계

Output

High-Level To-Be DirectionTo-Be Process 정의서※이 단계에서 BPMS 의 한계를 미리 반영할 필요는 없음

Check Point

To-Be Direction 이 회사의 발전방향 전략과 합치되는가 ?To-Be Process 가 High-Level To-Be Direction 에 위배되지 않는가 ?

High-LevelTo-Be Direction

정의개선기회 Grouping

To-Be Process정의

16

Stage Overview

상세 단계 － III. Construction

목적 BPMS 도입 프로세스 영역 확정 및 BPMS 적용이 가능하도록 Process 상세 설계

Input

To-Be Process 정의서BPMS 기능 정의서

추진 Framework

설계된 To-Be 에 대하여 , BPMS 도입 범위를 확정하고 , BPMS 구축이 가능한 수준으로 Process 를 세분화 하여 상세 설계함

Output

BPMS 에 적합한 Detailed To-Be Process 정의서

GAP 항목 및 해결방안 정의서Prototyping 기술서

Check Point

선택된 BPMS 도입 영역이 시스템 측면에서 타당하게 정의되었는가 ?상세화 된 To-Be Process 가 근본적인 개선 방향에 위배되지 않는가 ?

BPMSPrototyping

GAP 분석 및해결방안 수립

GAP 항목 해결을 위한개발 사항 정의 /적용

To-Be Process 와 BPMS 의적합성 판단

To-Be Process 에 따른 마스터 데이터 요건 정의

To-Be Process영역 중BPMS

도입 범위 확정

DetailedTo-Be Process

설계

BPMS 의 시스템 요건 정의 및 Set-Up

17

Stage Overview

상세 단계 － IV. Implementation

목적 Test 를 통해 Go-Live 를 위한 최종 점검 수행

Input

Test Scenario권한 정의서교육 매뉴얼 및 일정 계획서

추진 Framework

Test 를 수행하고 , Go-Live 하기 위한 Cut-Off Plan 을 수립함

Output

Cut-Off

Check Point

Scenario 가 모든 비즈니스 상황을 고려하여 수립되었는가 ?Go-Live 를 위한 모든 준비가 완료되었는가 ?

권한 정의 및 User 매뉴얼 작성

Test

Cut-Off

교육계획 수립 및 교육

Integration 을 위한Legacy 개발 사항 정의

Cut-OffPlan 수립

18

Stage Overview

상세 단계 － V. Stabilization

목적 Go-Live 이후 발생하는 문제점을 점검하고 , 안정화를 위한 향후 운영 원칙 수립

Input

Post Implementation Issues List

추진 Framework

Go-Live 이후 , 운영 차원에서 문제점을 점검하고 안정화를 위한 지속적인 운영 원칙을 수립함

Output

안정화를 위한 향후 운영 원칙

Check Point

시스템 운영 차원에서의 문제점을 모두 해결하였는가 ?초기에 의도했던 Process Management 가 수행되고 있는가 ?

향후 운영 원칙 수립문제점 점검 및 해결방안 수립

19

Q & A