－ Make Processes Manageable － BPR 관점에서의 BPM － Make Processes Manageable － 경영컨설팅본부 파트너 정희돈

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

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

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

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

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

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

BPM 역할 요약 BPM은 시스템에 의한 To-Be Process의 강제화, Process 변화에 대한 지속적 관리에 핵심적 역할을 하며, 설계-실행-모니터링-분석-재설계의 Feedback 체계를 가능하게 해주는 좋은 도구임 BPR 수행 체계 BPM의 역할 Process Design : Process Modeling Tool 및 Modeling된 Process를 보관할 수 있는 Repository 제공 실행 System을 통하지 않으면 업무를 수행할 수 없도록 To-Be Process를 강제함 Monitoring 및 분석 과거 － Monitoring 및 분석을 위하여 많은 노력이 필요함 BPM － Process 상의 문제점이 바로 지표로 보이므로 별도의 노력 없이 분석이 가능함 문제점 도출 Process Redesign 분석 분석 실행 Monitoring

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

BPR Modeling vs. BPM Modeling BPM은 BPR과 다른 모델링 방법을 가지고 있는가? 오해를 유도하는 명제들 올바른 인식 Process 설계 시 BPM Solution이 미리 전제 되어야 함 프로세스 상세 설계(Detail Design) 단계에 해당됨 그러나 BPM Solution에 의하여 To-Be Process 가 바뀌는 것은 아님

BPR Modeling vs. BPM Modeling BPM이 BPR을 대체할 수 있는가? 오해를 유도하는 명제들 올바른 인식 BPM이 BPR을 대체할 수 있 음 (To-Be 설계 없이 As-Is 프로세스에 BPM을 적용하여 문제점을 도출해 낼 수 있으므 로 BPR이 필요 없어짐) 어느 프로세스에 어떻게 BPM 솔루션을 적용할 것인가 BPR 없이 수행된 ERP의 실패의 교훈

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

도입 방법론 개요 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 수행 권한 설정 및 사용자 교육 구축 이후의 문제점 해결 향후 안정화를 위한 지속적인 운영 원칙 수립

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

상세 단계 － 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 프로젝트 목표에 대한 합의 1. Major 산출물 항목 및 주요 내용에 대한 합의 2. 기본은 삼일 계획에 의거해서… Qwin 정의 및 진도체크  정이사 자료 경영진 인터뷰 개선기회 Grouping High-Level To-Be Direction 정의 To-Be Process 정의

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

상세 단계 － 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 프로젝트 목표에 대한 합의 1. Major 산출물 항목 및 주요 내용에 대한 합의 2. 기본은 삼일 계획에 의거해서… Qwin 정의 및 진도체크  정이사 자료 경영진 인터뷰 권한 정의 및 User 매뉴얼 작성 Test Cut-Off 교육계획 수립 및 교육 Integration을 위한 Legacy 개발 사항 정의 Plan 수립

상세 단계 － V. Stabilization Go-Live 이후, 운영 차원에서 문제점을 점검하고 안정화를 위한 지속적인 운영 원칙을 수립함 Stage Overview 목적 Go-Live 이후 발생하는 문제점을 점검하고, 안정화를 위한 향후 운영 원칙 수립 Input Post Implementation Issues List Output 안정화를 위한 향후 운영 원칙 Check Point 시스템 운영 차원에서의 문제점을 모두 해결하였는가? 초기에 의도했던 Process Management가 수행되고 있는가? 추진 Framework 프로젝트 목표에 대한 합의 1. Major 산출물 항목 및 주요 내용에 대한 합의 2. 기본은 삼일 계획에 의거해서… Qwin 정의 및 진도체크  정이사 자료 경영진 인터뷰 문제점 점검 및 해결방안 수립 향후 운영 원칙 수립

Q & A