Post on 02-Jan-2016
description
경경경경경경경
경경경경경경경
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