BPR 관점에서의 BPM

1. 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 Hammer Harvard Business Review, July/August 1990

3. 목차 Ⅰ. BPR과 BPM의 관계에 대한 고찰 Ⅱ. 프로세스 정립 및 모델링 Ⅲ. BPR 관점에서의 BPMS 도입 방법론

4. BPR에 대한 평가 BPR의 실패와 성공과 관련된 여러가지 질문들… BPR Process 중심의 혁신 PI 1. 성공 / 실패 ? 2. 성공 / 실패의 기준 ? 3. 성공 / 실패 확인 방법 ? 4. Design의 문제, 실행(추진력)의 문제?

5. 주요 실패요인 BPR의 일반적인 실패 요인 새로운 IT 기술의 적용, 분석 및 관리 능력의 향상, 실행의 강제화가 BPR 성공의 요건이 아닐까 • 잘못된 Scope 정의(중점프로세스의 부재) • 잘못된 현상 분석(짧은 기간/소수 인원/Data 부재) • 강력한 지도자 부재 • 현업의 핵심 인력 지원 거부 • BPR 결과를 강제화 할 시스템 부재 • 변화 관리 실패(변화를 적용하고 관리하는 Tool 또는 System 부재) • 지속적이지 못함 (일회성) • : • . “분석, 실행 강제화, 관리” 를 위한 도구 미흡 분석 실행 관리

6. 항목 기존 시스템 Needs BPR 성공을 위한 필요 조건 “Process 관리, 탄력적 운영, 상시 분석 및 관리와 분석의 Feedback 구조”를 구현할 수 있는 시스템이 필요함 분석 분석 대상 Transaction Data Process(예 : Lead Time 분석에 의한 Neck Define, Process 준수 여부 등) 분석 주기 단속적 (discrete) 지속적 (continuous) 실행 탄력성 비탄력적 (프로세스 변화를 위해서는 기간 시스템 변화가 필요함) 탄력적 (쉽고, 빠르고, 기간 시스템의 변화 없이) 시스템 구조 단위 프로세스 Enterprise Process View 실행 형태 Pull (개인이 알아서 챙김) Push (시스템이 실행을 강제화) 관리 변화관리 프로세스 최종 결과인 지표만을 관리 프로세스 자체를 관리 (예 : Rule 준수여부, 리드타임,책임소재) BPM의 영역

7. 항목 기존 시스템 Needs BPM: BPR의 주요 성공 동인 BPM은 BPR의 기본 사상인 “Process 통합, Enterprise 통합, 탄력적인 프로세스 운영”을 달성, 유지할 수 있는 강력한 지원 도구임 분석 분석 대상 Transaction Data Process(예 : Lead Time 분석에 의한 Neck Define, Process 준수 여부 등) Process View에서의 Data 통합 제한된 탄력성 Enterprise View에서의 Process 통합 탄력적인 프로세스 분석 주기 단속적 (discrete) 지속적 (continuous) 실행 탄력성 비탄력적 (프로세스 변화를 위해서는 기간 시스템 변화가 필요함) 탄력적 (쉽고, 빠르고, 기간 시스템의 변화 없이) 시스템 구조 단위 프로세스 Enterprise Process View 실행 형태 Pull (개인이 알아서 챙김) Push (시스템이 실행을 강제화) 관리 변화관리 프로세스 최종 결과인 지표만을 관리 프로세스 자체를 관리 (예 : Rule 준수여부, 리드타임,책임소재)

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

9. 목차 Ⅰ. BPR과 BPM의 관계에 대한 고찰 Ⅱ. 프로세스 정립 및 모델링 Ⅲ. 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의 실패의 교훈

12. 목차 Ⅰ. BPR과 BPM의 관계에 대한 고찰 Ⅱ. 프로세스 정립 및 모델링 Ⅲ. BPR 관점에서의 BPMS 도입 방법론

13. 도입 방법론 개요 BPMS 도입 방법론은 Analysis, Design, Construction, Implementation, Stabilization 5단계로 나누어 설명할 수 있음 I. Analysis Ⅱ. Design Ⅲ. Construction Ⅳ. Implementation Ⅴ. Stabilization • As-Is Business 환경 및 전략, Process, 조직, 시스템 분석을 통한 이슈 도출 • 이슈에 대한 근본 원인 분석 및 Best Practice와의 비교 분석 • 근본 원인에 대한 개선 기회 도출 • 개선 기회 Grouping을 통해High-Level To-Be Direction 설계 • To-Be Process 설계 • BPMS 도입 범위 확정 • BPR의 To-Be와 BPMS 간의 Gap 분석 및 해결 방안 도출 • Process 상세 설계 • BPMS Prototyping • Test를 위한 Legacy 개발 사항 적용 • Test 수행 • 권한 설정 및 사용자 교육 • 구축 이후의 문제점 해결 • 향후 안정화를 위한 지속적인 운영 원칙 수립

14. 상세 단계 － I. Analysis 현재의 상황을 정확히 이해하고 근본원인을 도출하여 개선할 수 있는 기회를 찾아냄 Stage Overview 목적 • 정확한 개선기회 포착을 통해 To-Be 설계를 위한 방향 수립 Input • 전략 보고서 • As-Is Process,조직,시스템 현황 • Interview 결과서 • Best Practice Output • 이슈 리스트 • 이슈별 개선기회 정의서 Check Point • 이슈가 적합하게 도출되었으며, 이슈별 근본원인은 논리적으로 무결한가? • 개선 기회가 적합하게 도출되었는가? 추진 Framework As-Is Process/조직/시스템 분석 이슈 도출 및 이슈에 대한 Root Cause 분석 개선 기회 도출 경영진/담당자 Interview Best Practice 분석 비즈니스 환경 및 전략 검토

15. 상세 단계 － II. Design 개선 기회를 통해 Ideal한 To-Be Process를 설계 Stage Overview 목적 • To-Be Process 도출 Input • 이슈별 개선기회 정의서 Output • High-Level To-Be Direction • To-Be Process 정의서 ※이 단계에서 BPMS의 한계를 미리 반영할 필요는 없음 Check Point • To-Be Direction이 회사의 발전방향 전략과 합치되는가? • To-Be Process가 High-Level To-Be Direction에 위배되지 않는가? 추진 Framework 개선기회 Grouping High-Level To-Be Direction 정의 To-Be Process 정의

16. 상세 단계 － III. Construction 설계된 To-Be에 대하여, BPMS 도입 범위를 확정하고, BPMS 구축이 가능한 수준으로 Process를 세분화 하여 상세 설계함 Stage Overview 목적 • BPMS 도입 프로세스 영역 확정 및 BPMS 적용이 가능하도록 Process 상세 설계 Input • To-Be Process 정의서 • BPMS 기능 정의서 Output • BPMS에 적합한 DetailedTo-Be Process 정의서 • GAP 항목 및 해결방안 정의서 • Prototyping 기술서 Check Point • 선택된 BPMS 도입 영역이 시스템 측면에서 타당하게 정의되었는가? • 상세화 된 To-Be Process가 근본적인 개선 방향에 위배되지 않는가? 추진 Framework To-Be Process 영역 중 BPMS 도입 범위 확정 To-Be Process와 BPMS의 적합성 판단 Detailed To-Be Process 설계 BPMS Prototyping GAP 분석 및 해결방안 수립 GAP 항목 해결을 위한 개발 사항 정의/적용 To-Be Process에 따른 마스터 데이터 요건 정의 BPMS의 시스템 요건 정의 및 Set-Up

17. Integration을 위한 Legacy 개발 사항 정의 Test Cut-Off Cut-Off Plan 수립 권한 정의및 User 매뉴얼 작성 교육계획 수립 및 교육 상세 단계 － IV. Implementation Test를 수행하고, Go-Live 하기 위한 Cut-Off Plan을 수립함 Stage Overview 목적 • Test를 통해 Go-Live를 위한 최종 점검 수행 Input • Test Scenario • 권한 정의서 • 교육 매뉴얼 및 일정 계획서 Output • Cut-Off Check Point • Scenario가 모든 비즈니스 상황을 고려하여 수립되었는가? • Go-Live를 위한 모든 준비가 완료되었는가? 추진 Framework

18. 상세 단계 － V. Stabilization Go-Live 이후, 운영 차원에서 문제점을 점검하고 안정화를 위한 지속적인 운영 원칙을 수립함 Stage Overview 목적 • Go-Live 이후 발생하는 문제점을 점검하고, 안정화를 위한 향후 운영 원칙 수립 Input • Post Implementation Issues List Output • 안정화를 위한 향후 운영 원칙 Check Point • 시스템 운영 차원에서의 문제점을 모두 해결하였는가? • 초기에 의도했던 Process Management가 수행되고 있는가? 추진 Framework 문제점 점검 및 해결방안 수립 향후 운영 원칙 수립

19. Q & A