SlideShare a Scribd company logo
To-Be 설계 절차와 방법
2012. 6.
이성복
Ⅰ. TO-BE 설계란 무엇인가?
Ⅱ. TO-BE에는 무엇이 있는가?
Ⅲ. 어떻게 TO-BE를 설계할 것인가?
[첨부] TO-BE 설계 TIP : FLOWCHART
To-Be?
To-Be는 어디로 가야 하는지, 어떻게 가야 하는지, 거기에 무엇이 있는지를 찾는 목적
이자 목표
2
왜 To-Be가 필요한가?
프로세스의 파편화, 불명확성 등으로 인해 통합경영과 예측경영이 어려움  프로세스를 가시
화, 명확하한 통합된 시스템을 구축함으로써 가능하게 함
무엇이 문제인가? 왜 개선이 필요한가? 어떠한 미래상인가?
 숨겨진 프로세스를 찾아라!
 비정형, 개인화된 프로세스
 업무의 지연
 관리 불가, 인수인계 불가
 불명확한 프로세스 = 조직간의 불명확
한 R&R
 생산성 저하
 가시화되고 명확한 프로세스
 공유할 수 있고, 개선할 수 있는 프로
세스
 너무 산만한 시스템
: 업무 필요에 따라 그때 그때 시스템
구축  통일성 결여, 시스템 아무도
모름
 통합관리 불가
 I/F를 위한 복잡한 장치와 부정확성
 시스템간 R&R 부재  결국은 사람의
손으로
 ERP를 근간으로 한 통합된(잘
Interface된) IT Architecture
 어느 게 진짜 Data?
: 데이터의 중복관리, 부분관리, 또는
관리 부재
 정확성과 신뢰성 없는 데이터
 정확한 데이터를 적시에 확보할 수 없
음
 데이터의 소재 파악 어려움
 결국은 사람이 직접 찾아다님
 기준정보의 통합관리(ERP)
 데이터의 정확성, 적시성
 유형별 정확한 정보의 관리 :
transaction, 기준정보, 참고성..
 BW/EIS 구현 가능
3
[참고] To-Be Business Process를 통해 얻는 것
1. 소프트웨어와는 독립적으로 미래의 경영모델과 비즈니스 프로세스를 정의
: 기존의 좁은 시야/관행에서 벗어나 경영개선 결과를 측정 가능하게 하는 도구로
써의 IT를 활용하여 커다란 기회를 찾게 함
2. 현재와 미래의 프로세스간의 Job, 책임과 역할 등의 차이를 명확히 함
 기업의 변화관리 관점에서 매우 중요
3. 경영개선과 회계책임을 위한 KPI 정의에 도움
 새로운 프로세스가 새로운 책임과 기회를 가져옴
4. Customization, 통합, 보고서 수요의 우선순위 결정 가능
: 경영상의 관점에서 기업이 어디로 가야 하는지에 대한 이해가 없으면 어느 정도
의 customization이나 추가 개발이 적절한지 판단할 수 없음
4
To-Be 설계의 의의
 전체적인 미래상을 가지는 기회
: 프로세스를 지원하는 IT, IT에 의한 프로세스의 관리
 프로젝트를 어떻게 구현하는가에 대한 가장 초보적 단계이자 타 모듈에 대한 입장을 청취할
수 있는 기회
 고객 스스로 문제점을 찾아내고 분석/평가하고, 개선책을 내놓는 과정
 데이터(정보) 중심의 설계(=End-to-End Process)
: 데이터가 어떻게 내 모듈로 들어와서 어디로 가고 나중에 어떻게 되는지를 알 수 있게 함
 고객 스스로 작업 또는 적극적인 협업을 통해 자연스러운 BPR 과정을 만들어 냄
5
Ⅰ. TO-BE 설계란 무엇인가?
Ⅱ. TO-BE에는 무엇이 있는가?
Ⅲ. 어떻게 TO-BE를 설계할 것인가?
[첨부] TO-BE 설계 TIP : FLOWCHART
ERP프로젝트에서 To-Be란 무엇인가?
TO-BE란 미래의 이상적 지향점, 즉 ERP를 도입함으로써 변하게 될 프로세스, 시스템, 보고서, 데이터의
미래상
PROCESS
Report
SYSTEM
DATA
To-Be
Image
 BPM에 기반한 프로세스
 ERP 기반의 Best Practice를
통해 개선된 프로세스
 핵심 프로세스 중심
 ERP 시스템
 ERP를 근간으로 한
Legacy 배치  통합 환
경
 One Data, One Storage
 정합성, 정확성, 적시성
 프로세스의 흐름에 따른
명확한 I/O
 OLAP tool로 통폐합
 프로세스 중심
 최소화, 화면으로 대체..
7
Ⅰ. TO-BE 설계란 무엇인가?
Ⅱ. TO-BE에는 무엇이 있는가?
Ⅲ. 어떻게 TO-BE를 설계할 것인가?
[첨부] TO-BE 설계 TIP : FLOWCHART
To-Be는 어디에서 오는가?
 TO-BE는 다양한 원천으로부터 입력을 받아 미래상을 그리는 종합예술
 To-Be에 필요한 원천은 회사 전반에 걸쳐 다양하게 존재하고 있으며, 이를 확보하기 위해서는 담당자
/PI를 기반으로 다방면에 걸쳐 확보하여야 한다
As-Is Process
요구사항
(Requirements)
ERP Standard
규정/정책/법
To-Be
Image
Pain Point
회사의 전략/Vision
Business Process
개선된 Process
9
 As-Is 분석을 통해 도출
To-Be 설계 절차
To-Be는 End-to-End Business Process로부터 개별 프로세스 정의서까지 차례대로 도출될 수
있도록 한다.
ERP에서 업무를 레벨별로 구분하여 세부업
무에 대한 레벨은 하위 레벨로 정하여 최하
위 레벨과 SAP의 T-CODE)를 매칭하는 작업
1. to-be 프로세스 목록 작성
2. to-be 프로세스 체계도 작성
3. to-be 프로세스 정의서 작성
SAP 기준으로 업무가 어떤 체계의 구조를
가지고 있는지에 대하여 계층구조 형태로
업무를 분류하는 작업
SAP 기준으로 업무의 흐름에 대하여 Flow
Chart 형태로 업무를 정의하는 작업
기존의 to-be 분석 절차
각 영역별 업무를 도출하고 업무간의 관계도와 계
층도 작성
1. 영역별 업무 구분 & 관계도 작성
3. to-be 프로세스 목록 & 체계도 작성
4. Process Flowchart 작성
Level 3(Sub-process)까지 업무를 도출하고 계층구
조 형태로 업무를 분류
Flowchart 형태로 업무를 정의하여 고객과 협의
BPM 관점의 to-be 분석 절차
2. 업무별 프로세스 정의
각 업무영역별 End-to-End Process 작성
5. to-be 프로세스 정의서 작성
프로세스별 상세 내역(Activity, Data, 기능 등) 정의
10
To-Be 설계 절차와 각 요소의 관계
To-Be 설계는 ERP를 기반으로 한 하나의 완결된 업무 프로세스를 구성하도록 프로세스를 중심
으로 Report, Data, System 정보를 통합하는 것
to-be 분석 절차
Process
Organiza
tion
Report
Data
System
업무영역 도
출
Process
Flow 작성
Process
확정
업무별 End-
to-End
Process
Report 수요
파악
대상 Report
확정
Layout,
Data 정의
핵심 Data
확정
조직구조 정
의
Configuration
GAP
ERP 데이터
확인
Data
Mapping
I/F 대상 확
인
I/F CBO 개
발
Business
Process
Mapping
Data
Dictionary
정의
To-Be
System
Image
Test
11
To-Be 설계의 원칙
 To-Be는 기업의 경영전략과 일치시켜야 함
 큰 그림  작은 그림
 Data의 정확한 흐름 중심
 핵심 프로세스  비핵심 프로세스의 순서대로 작업
 철저한 고객과의 Communication : Flowchart 활용
 To-be는 명확해야 함 : 빠짐없는 Process와 activity, 정확한 data
 To-be는 단순한 이상향을 그리는 게 아님  ERP 기반의 개선된 모습
(ERP Standard = 기업 비즈니스 프로세스와 IT의 이상향)
 각각의 프로세스의 가치 : 왜 이 프로세스가 필요? 어떤 역할, 어떤 결과물? 등에 대한 이해
 가중치 부여/분석  핵심/비핵심 프로세스 구분
 고객에게 또는 스스로에게 질문
- “이 기업이 5년 후에 어떤 모습이길 원하는가?
- “기업의 전략을 가능하게 하기 위해 필요한 경영 전략은 무엇인가?”
 각 모듈별로 TO-BE 프로세스를 작성을 하였으면 다 모여서 통합 프로세스를 설계
12
To-Be 프로세스 설계
13
 경영전략, End-to-End Business Process의 반영
 ‘ERP = To-Be’라는 정신
 고객과의 끊임없는 커뮤니케이션을 통해 확정 (by Flowchart)
 ‘To-Be = ERP’가 될 수 있도록 사전 정지작업 필수 : 교육, 타사사례 제공, 벤치마킹, 각종 관
련 정보의 제공 등 적극적 변화관리 활동
 최소한 핵심 프로세스에 대해서라도 ERP Standard 관철
 화면을 자주 접할 수 있도록 다양한 방법 강구
: News letter, 교육, Visioning 등
 입출력되는 데이터(정보)의 종류와 성격 등을 명확히 정의
 핵심 프로세스의 선정
- 프로세스 주기, 빈도, 관련자, 출력물의 활용도, 업무의 비중, 입출력 데이터의 양 등
- 많은 경우 As-Is와 비슷한 구조로 감
To-Be 보고서 설계
 보고서 설계의 원칙 정의
예) 시뮬레이션 또는 수시보고용 개별보고서는 OLAP 툴로 흡수(전략적 판단)
공식보고서 외에는 조회화면 등으로 대체 등등
 보고서에 필요한 핵심 데이터의 추출, 정의
: 비핵심 데이터, 손이 많이 가는 데이터의 처리 방법 또는 우회로
 필요한 데이트의 확보  대응책 수립
: Standard, CBO, Legacy?
14
To-Be 시스템 설계
 근간이 되는 시스템은 ERP
 ERP를 중심에 두고 Legacy 배치
핵심정보, 기준정보, 결과정보 등은 ERP 관리, Transaction 정보, 참고성 정보 등은
Legacy에서 관리
 ERP, PI(XI)를 통한 통합 Architecture 환경 구성
 Data의 중복, 누락 여부 확인 : Report, Data의 정보 확인
15
To-Be 조직 설계
 프로세스 설계에 따른 기본 조직구조 정의
 중복 또는 누락 조직 점검
 HR조직과 분리해서 생각 : 주로 결재, 보고선 지정
 Organization 설계는 ERP Configuration에 직접적인 영향 – 모듈과 충분히 협의
16
To-Be 설계의 Check-point
17
 End-to-End Process를 도출했는가?
 핵심 프로세스를 발라 냈나?
 Flowchart를 Activity나 Event가 빠지지 않게 명확하게 그릴 수 있는가?
 업무 Flow상, Interface상 입출력 Data에 대해 명확히 알고 있는가?
 고객과 충분히 합의된 flow인가?
 Flow에는 Data의 흐름이 분명히 표현되어 있는가?
 프로세스를 Level별로 체계화/계층화 할 수 있는가?
 Interface 부분은 타 시스템, 타 모듈과 충분히 협의되었는가?
 To-be Data(특히 핵심 Data)를 파악하고 있는가?
 작업 분량(Configuration, CBO, 자료이관 등)에 대해 ‘감’이 오는가?
 ERP Standard를 충분히 반영한 프로세스인가?
 To-Be의 원천 요소들이 제대로 반영되어 있는가?
 To-Be를 그리기 전 또는 그리면서 PI들에게 ERP 교육을 충분히 시켰는가?
Ⅰ. TO-BE 설계란 무엇인가?
Ⅱ. TO-BE에는 무엇이 있는가?
Ⅲ. 어떻게 TO-BE를 설계할 것인가?
[첨부] TO-BE 설계 TIP : FLOWCHART
Process를 위한 고객과의 Communication
서로 다른 배경지식과 경험을 가진 사람들이 단기간에 업무 협의를 하는 과정에서 ‘수많은 오해
와 오해 발생  잘못된 설계와 잘못된 구축으로 인한 재작업  그리고 이에 따른 일정의 지연
과 고객과의 갈등’이라는 악순환을 피하는 커뮤니케이션이 중요
19
말(언어)
텍스트형 문서
간략한 메모,
회의록
Legacy 화면
정책, 규정, 보
고서 등
 단편적, 단절적
 전체 그림을 볼 수 없음
 프로세스의 흐름을 볼 수 없
음
 같은 내용에 대한 서로 다른
이해(=오해)
 보이지 않거나 보여도 의미
파악이 어려움
 체계화되지 않음
Flowchart!!
고객과 컨설턴트간에 오
해를 최소화하면서 효과
적인 커뮤니케이션을 위
한 수단/방법이 없을까?
왜 Process Flowchart인가?
프로세스 Flowchart를 활용하게 되면 타 의사소통 수단에 비해 오류가 적고, 적극적이면서도 명확한
커뮤니케이션이 가능하다
20
1. 눈에 보인다  구체적이고 실질적인 협의 가능
: To-Be를 설계하려면 자신들의 현재의 지식/경험 범위 바깥에서 프로세스가 어떻게
작동하는지 객관적으로 알 필요
 Flowchart는 짧은 시간에 이것들을 총체적이고 일목요연하게 볼 수 있게 해줌
2. 기업이 더 효율적으로 변화할 수 있도록 해 줌
: 업무를 처리하는 데 쓸데없는 비용을 발생시키는 중복과 비효율성을 구분할 필요
 구태에서 벗어나 더 효율적인 조직으로 발돋움
Flowchart 예시 - 휴가관리
21
Process Flowchart 그리기 tip
 Sample Flowchart 확보  계속 수정/보완하면서 완성
 큰 프로세스에서 작은 프로세스로, Activity로 breakdown : Big Picture
 선후행 프로세스 명시 : 단순한 연결(linkage)인지 의존관계(dependency)인지 파악
 프로세스의 Input과 Output 명시 : I/O 없는 프로세스는 없다!
 Data(혹은) 정보의 흐름에 주의 : 프로세스 = Data(정보)의 흐름
 고객과의 커뮤니케이션을 위한 수단  고객의 눈높이에 맞춰 쉽고 상세하게
 핵심 프로세스 선정  핵심 프로세스는 상세하게, 비핵심 프로세스는 대충
 Flowchart를 보면서 고객들이 스스로 자신들의 현행 프로세스의 문제점을 인식/가시화하고,
그 프로세스를 재평가하여 스스로 불필요한 단계를 제거하거나 개선하는 기회
22
다음에 계속…?

More Related Content

Similar to To-Be 설계 절차와 방법.pptx

Process Oriented Architecture
Process Oriented ArchitectureProcess Oriented Architecture
Process Oriented Architecture
uEngine Solutions
 
전사 데이터 관리 반드시 피해야 할 7가지 실수
전사 데이터 관리 반드시 피해야 할 7가지 실수전사 데이터 관리 반드시 피해야 할 7가지 실수
전사 데이터 관리 반드시 피해야 할 7가지 실수
Devgear
 
유엔진 프로세스 모니터링 툴킷 P M T Process Monitoring Toolkit
유엔진 프로세스 모니터링 툴킷  P M T  Process  Monitoring  Toolkit유엔진 프로세스 모니터링 툴킷  P M T  Process  Monitoring  Toolkit
유엔진 프로세스 모니터링 툴킷 P M T Process Monitoring Toolkit
uEngine Solutions
 
3 7 건설정보화전략과pmis(이민남)
3 7 건설정보화전략과pmis(이민남)3 7 건설정보화전략과pmis(이민남)
3 7 건설정보화전략과pmis(이민남)
JiWoon Yi
 
스마트워크플레이스 플랫폼 프로세스 코디
스마트워크플레이스 플랫폼 프로세스 코디 스마트워크플레이스 플랫폼 프로세스 코디
스마트워크플레이스 플랫폼 프로세스 코디
uEngine Solutions
 
[8]viii.process as a service platform process codi
[8]viii.process as a service platform   process codi[8]viii.process as a service platform   process codi
[8]viii.process as a service platform process codi
uEngine Solutions
 
비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램
비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램
비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램
Stefano_Shin
 
Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트
Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트
Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트
koscom
 
정보화 계획 수립 개념
정보화 계획 수립 개념정보화 계획 수립 개념
정보화 계획 수립 개념
InGuen Hwang
 
투이컨설팅 제23회 Y세미나 : 설문결과
투이컨설팅 제23회 Y세미나 : 설문결과투이컨설팅 제23회 Y세미나 : 설문결과
투이컨설팅 제23회 Y세미나 : 설문결과
2econsulting
 
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업
Steve Kim
 
Process As A Service Platform Process Codi For Sharing
Process  As  A  Service  Platform    Process  Codi For SharingProcess  As  A  Service  Platform    Process  Codi For Sharing
Process As A Service Platform Process Codi For Sharing
uEngine Solutions
 
서비스 기획자의 데이터 분석
서비스 기획자의 데이터 분석서비스 기획자의 데이터 분석
서비스 기획자의 데이터 분석
YOO SE KYUN
 
Fif기고문 050311 05
Fif기고문 050311 05Fif기고문 050311 05
Fif기고문 050311 05
Eugene Chung
 
Game Development Process Management
Game Development Process ManagementGame Development Process Management
Game Development Process Management
changehee lee
 
LOgistics KPI
LOgistics KPI LOgistics KPI
LOgistics KPI
seouk joo Seouk Joo Lee
 
Rpa approach
Rpa approach Rpa approach
Rpa approach
ssuser9a50211
 
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업
Steve Kim
 
프로젝트관리­ 2회(블로그용)
프로젝트관리­ 2회(블로그용)프로젝트관리­ 2회(블로그용)
프로젝트관리­ 2회(블로그용)
yonsei87
 
Business process approach and the future of bpm - Social BPM and PaaS for Bus...
Business process approach and the future of bpm - Social BPM and PaaS for Bus...Business process approach and the future of bpm - Social BPM and PaaS for Bus...
Business process approach and the future of bpm - Social BPM and PaaS for Bus...
uEngine Solutions
 

Similar to To-Be 설계 절차와 방법.pptx (20)

Process Oriented Architecture
Process Oriented ArchitectureProcess Oriented Architecture
Process Oriented Architecture
 
전사 데이터 관리 반드시 피해야 할 7가지 실수
전사 데이터 관리 반드시 피해야 할 7가지 실수전사 데이터 관리 반드시 피해야 할 7가지 실수
전사 데이터 관리 반드시 피해야 할 7가지 실수
 
유엔진 프로세스 모니터링 툴킷 P M T Process Monitoring Toolkit
유엔진 프로세스 모니터링 툴킷  P M T  Process  Monitoring  Toolkit유엔진 프로세스 모니터링 툴킷  P M T  Process  Monitoring  Toolkit
유엔진 프로세스 모니터링 툴킷 P M T Process Monitoring Toolkit
 
3 7 건설정보화전략과pmis(이민남)
3 7 건설정보화전략과pmis(이민남)3 7 건설정보화전략과pmis(이민남)
3 7 건설정보화전략과pmis(이민남)
 
스마트워크플레이스 플랫폼 프로세스 코디
스마트워크플레이스 플랫폼 프로세스 코디 스마트워크플레이스 플랫폼 프로세스 코디
스마트워크플레이스 플랫폼 프로세스 코디
 
[8]viii.process as a service platform process codi
[8]viii.process as a service platform   process codi[8]viii.process as a service platform   process codi
[8]viii.process as a service platform process codi
 
비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램
비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램
비즈니스 인텔리전스 솔루션 사이센스 퀵스타트 프로그램
 
Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트
Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트
Koscom report - 초(超)자동화를 선도할 프로세스 사이언티스트
 
정보화 계획 수립 개념
정보화 계획 수립 개념정보화 계획 수립 개념
정보화 계획 수립 개념
 
투이컨설팅 제23회 Y세미나 : 설문결과
투이컨설팅 제23회 Y세미나 : 설문결과투이컨설팅 제23회 Y세미나 : 설문결과
투이컨설팅 제23회 Y세미나 : 설문결과
 
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 비영리법인 및 공공산업
 
Process As A Service Platform Process Codi For Sharing
Process  As  A  Service  Platform    Process  Codi For SharingProcess  As  A  Service  Platform    Process  Codi For Sharing
Process As A Service Platform Process Codi For Sharing
 
서비스 기획자의 데이터 분석
서비스 기획자의 데이터 분석서비스 기획자의 데이터 분석
서비스 기획자의 데이터 분석
 
Fif기고문 050311 05
Fif기고문 050311 05Fif기고문 050311 05
Fif기고문 050311 05
 
Game Development Process Management
Game Development Process ManagementGame Development Process Management
Game Development Process Management
 
LOgistics KPI
LOgistics KPI LOgistics KPI
LOgistics KPI
 
Rpa approach
Rpa approach Rpa approach
Rpa approach
 
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업
마이크로소프트 클라우드 Erp 서비스 nav 2013 소개 공단 등 부동산관리산업
 
프로젝트관리­ 2회(블로그용)
프로젝트관리­ 2회(블로그용)프로젝트관리­ 2회(블로그용)
프로젝트관리­ 2회(블로그용)
 
Business process approach and the future of bpm - Social BPM and PaaS for Bus...
Business process approach and the future of bpm - Social BPM and PaaS for Bus...Business process approach and the future of bpm - Social BPM and PaaS for Bus...
Business process approach and the future of bpm - Social BPM and PaaS for Bus...
 

More from Seong-Bok Lee

소화설비_수원과 소화약제량.pdf
소화설비_수원과 소화약제량.pdf소화설비_수원과 소화약제량.pdf
소화설비_수원과 소화약제량.pdf
Seong-Bok Lee
 
소화설비_작동순서.pdf
소화설비_작동순서.pdf소화설비_작동순서.pdf
소화설비_작동순서.pdf
Seong-Bok Lee
 
소화설비_계통도.pdf
소화설비_계통도.pdf소화설비_계통도.pdf
소화설비_계통도.pdf
Seong-Bok Lee
 
정보공학(IE) 방법론.pptx
정보공학(IE) 방법론.pptx정보공학(IE) 방법론.pptx
정보공학(IE) 방법론.pptx
Seong-Bok Lee
 
CBD 개발방법론.pptx
CBD 개발방법론.pptxCBD 개발방법론.pptx
CBD 개발방법론.pptx
Seong-Bok Lee
 
Mapping 절차와 방법.pptx
Mapping 절차와 방법.pptxMapping 절차와 방법.pptx
Mapping 절차와 방법.pptx
Seong-Bok Lee
 
ERP프로젝트 중요산출물 ERD.pptx
ERP프로젝트 중요산출물 ERD.pptxERP프로젝트 중요산출물 ERD.pptx
ERP프로젝트 중요산출물 ERD.pptx
Seong-Bok Lee
 
금융It시스템의 이해 2편
금융It시스템의 이해 2편금융It시스템의 이해 2편
금융It시스템의 이해 2편
Seong-Bok Lee
 
금융It시스템의 이해 1편 202201
금융It시스템의 이해 1편 202201금융It시스템의 이해 1편 202201
금융It시스템의 이해 1편 202201
Seong-Bok Lee
 
비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술
Seong-Bok Lee
 
블록체인적용사례-해운물류
블록체인적용사례-해운물류블록체인적용사례-해운물류
블록체인적용사례-해운물류
Seong-Bok Lee
 
HR Analytics - 퇴직가능성예측모델
HR Analytics - 퇴직가능성예측모델HR Analytics - 퇴직가능성예측모델
HR Analytics - 퇴직가능성예측모델
Seong-Bok Lee
 
비트코인 채굴과정
비트코인 채굴과정비트코인 채굴과정
비트코인 채굴과정
Seong-Bok Lee
 
통계 기초 용어1
통계 기초 용어1통계 기초 용어1
통계 기초 용어1
Seong-Bok Lee
 
Intro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_sIntro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_s
Seong-Bok Lee
 
Cloud migration pattern[한글]
Cloud migration pattern[한글]Cloud migration pattern[한글]
Cloud migration pattern[한글]
Seong-Bok Lee
 
Cloud migration pattern using microservices
Cloud migration pattern using microservicesCloud migration pattern using microservices
Cloud migration pattern using microservices
Seong-Bok Lee
 

More from Seong-Bok Lee (17)

소화설비_수원과 소화약제량.pdf
소화설비_수원과 소화약제량.pdf소화설비_수원과 소화약제량.pdf
소화설비_수원과 소화약제량.pdf
 
소화설비_작동순서.pdf
소화설비_작동순서.pdf소화설비_작동순서.pdf
소화설비_작동순서.pdf
 
소화설비_계통도.pdf
소화설비_계통도.pdf소화설비_계통도.pdf
소화설비_계통도.pdf
 
정보공학(IE) 방법론.pptx
정보공학(IE) 방법론.pptx정보공학(IE) 방법론.pptx
정보공학(IE) 방법론.pptx
 
CBD 개발방법론.pptx
CBD 개발방법론.pptxCBD 개발방법론.pptx
CBD 개발방법론.pptx
 
Mapping 절차와 방법.pptx
Mapping 절차와 방법.pptxMapping 절차와 방법.pptx
Mapping 절차와 방법.pptx
 
ERP프로젝트 중요산출물 ERD.pptx
ERP프로젝트 중요산출물 ERD.pptxERP프로젝트 중요산출물 ERD.pptx
ERP프로젝트 중요산출물 ERD.pptx
 
금융It시스템의 이해 2편
금융It시스템의 이해 2편금융It시스템의 이해 2편
금융It시스템의 이해 2편
 
금융It시스템의 이해 1편 202201
금융It시스템의 이해 1편 202201금융It시스템의 이해 1편 202201
금융It시스템의 이해 1편 202201
 
비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술
 
블록체인적용사례-해운물류
블록체인적용사례-해운물류블록체인적용사례-해운물류
블록체인적용사례-해운물류
 
HR Analytics - 퇴직가능성예측모델
HR Analytics - 퇴직가능성예측모델HR Analytics - 퇴직가능성예측모델
HR Analytics - 퇴직가능성예측모델
 
비트코인 채굴과정
비트코인 채굴과정비트코인 채굴과정
비트코인 채굴과정
 
통계 기초 용어1
통계 기초 용어1통계 기초 용어1
통계 기초 용어1
 
Intro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_sIntro to hpe helion stackato_paa_s
Intro to hpe helion stackato_paa_s
 
Cloud migration pattern[한글]
Cloud migration pattern[한글]Cloud migration pattern[한글]
Cloud migration pattern[한글]
 
Cloud migration pattern using microservices
Cloud migration pattern using microservicesCloud migration pattern using microservices
Cloud migration pattern using microservices
 

To-Be 설계 절차와 방법.pptx

  • 1. To-Be 설계 절차와 방법 2012. 6. 이성복
  • 2. Ⅰ. TO-BE 설계란 무엇인가? Ⅱ. TO-BE에는 무엇이 있는가? Ⅲ. 어떻게 TO-BE를 설계할 것인가? [첨부] TO-BE 설계 TIP : FLOWCHART
  • 3. To-Be? To-Be는 어디로 가야 하는지, 어떻게 가야 하는지, 거기에 무엇이 있는지를 찾는 목적 이자 목표 2
  • 4. 왜 To-Be가 필요한가? 프로세스의 파편화, 불명확성 등으로 인해 통합경영과 예측경영이 어려움  프로세스를 가시 화, 명확하한 통합된 시스템을 구축함으로써 가능하게 함 무엇이 문제인가? 왜 개선이 필요한가? 어떠한 미래상인가?  숨겨진 프로세스를 찾아라!  비정형, 개인화된 프로세스  업무의 지연  관리 불가, 인수인계 불가  불명확한 프로세스 = 조직간의 불명확 한 R&R  생산성 저하  가시화되고 명확한 프로세스  공유할 수 있고, 개선할 수 있는 프로 세스  너무 산만한 시스템 : 업무 필요에 따라 그때 그때 시스템 구축  통일성 결여, 시스템 아무도 모름  통합관리 불가  I/F를 위한 복잡한 장치와 부정확성  시스템간 R&R 부재  결국은 사람의 손으로  ERP를 근간으로 한 통합된(잘 Interface된) IT Architecture  어느 게 진짜 Data? : 데이터의 중복관리, 부분관리, 또는 관리 부재  정확성과 신뢰성 없는 데이터  정확한 데이터를 적시에 확보할 수 없 음  데이터의 소재 파악 어려움  결국은 사람이 직접 찾아다님  기준정보의 통합관리(ERP)  데이터의 정확성, 적시성  유형별 정확한 정보의 관리 : transaction, 기준정보, 참고성..  BW/EIS 구현 가능 3
  • 5. [참고] To-Be Business Process를 통해 얻는 것 1. 소프트웨어와는 독립적으로 미래의 경영모델과 비즈니스 프로세스를 정의 : 기존의 좁은 시야/관행에서 벗어나 경영개선 결과를 측정 가능하게 하는 도구로 써의 IT를 활용하여 커다란 기회를 찾게 함 2. 현재와 미래의 프로세스간의 Job, 책임과 역할 등의 차이를 명확히 함  기업의 변화관리 관점에서 매우 중요 3. 경영개선과 회계책임을 위한 KPI 정의에 도움  새로운 프로세스가 새로운 책임과 기회를 가져옴 4. Customization, 통합, 보고서 수요의 우선순위 결정 가능 : 경영상의 관점에서 기업이 어디로 가야 하는지에 대한 이해가 없으면 어느 정도 의 customization이나 추가 개발이 적절한지 판단할 수 없음 4
  • 6. To-Be 설계의 의의  전체적인 미래상을 가지는 기회 : 프로세스를 지원하는 IT, IT에 의한 프로세스의 관리  프로젝트를 어떻게 구현하는가에 대한 가장 초보적 단계이자 타 모듈에 대한 입장을 청취할 수 있는 기회  고객 스스로 문제점을 찾아내고 분석/평가하고, 개선책을 내놓는 과정  데이터(정보) 중심의 설계(=End-to-End Process) : 데이터가 어떻게 내 모듈로 들어와서 어디로 가고 나중에 어떻게 되는지를 알 수 있게 함  고객 스스로 작업 또는 적극적인 협업을 통해 자연스러운 BPR 과정을 만들어 냄 5
  • 7. Ⅰ. TO-BE 설계란 무엇인가? Ⅱ. TO-BE에는 무엇이 있는가? Ⅲ. 어떻게 TO-BE를 설계할 것인가? [첨부] TO-BE 설계 TIP : FLOWCHART
  • 8. ERP프로젝트에서 To-Be란 무엇인가? TO-BE란 미래의 이상적 지향점, 즉 ERP를 도입함으로써 변하게 될 프로세스, 시스템, 보고서, 데이터의 미래상 PROCESS Report SYSTEM DATA To-Be Image  BPM에 기반한 프로세스  ERP 기반의 Best Practice를 통해 개선된 프로세스  핵심 프로세스 중심  ERP 시스템  ERP를 근간으로 한 Legacy 배치  통합 환 경  One Data, One Storage  정합성, 정확성, 적시성  프로세스의 흐름에 따른 명확한 I/O  OLAP tool로 통폐합  프로세스 중심  최소화, 화면으로 대체.. 7
  • 9. Ⅰ. TO-BE 설계란 무엇인가? Ⅱ. TO-BE에는 무엇이 있는가? Ⅲ. 어떻게 TO-BE를 설계할 것인가? [첨부] TO-BE 설계 TIP : FLOWCHART
  • 10. To-Be는 어디에서 오는가?  TO-BE는 다양한 원천으로부터 입력을 받아 미래상을 그리는 종합예술  To-Be에 필요한 원천은 회사 전반에 걸쳐 다양하게 존재하고 있으며, 이를 확보하기 위해서는 담당자 /PI를 기반으로 다방면에 걸쳐 확보하여야 한다 As-Is Process 요구사항 (Requirements) ERP Standard 규정/정책/법 To-Be Image Pain Point 회사의 전략/Vision Business Process 개선된 Process 9  As-Is 분석을 통해 도출
  • 11. To-Be 설계 절차 To-Be는 End-to-End Business Process로부터 개별 프로세스 정의서까지 차례대로 도출될 수 있도록 한다. ERP에서 업무를 레벨별로 구분하여 세부업 무에 대한 레벨은 하위 레벨로 정하여 최하 위 레벨과 SAP의 T-CODE)를 매칭하는 작업 1. to-be 프로세스 목록 작성 2. to-be 프로세스 체계도 작성 3. to-be 프로세스 정의서 작성 SAP 기준으로 업무가 어떤 체계의 구조를 가지고 있는지에 대하여 계층구조 형태로 업무를 분류하는 작업 SAP 기준으로 업무의 흐름에 대하여 Flow Chart 형태로 업무를 정의하는 작업 기존의 to-be 분석 절차 각 영역별 업무를 도출하고 업무간의 관계도와 계 층도 작성 1. 영역별 업무 구분 & 관계도 작성 3. to-be 프로세스 목록 & 체계도 작성 4. Process Flowchart 작성 Level 3(Sub-process)까지 업무를 도출하고 계층구 조 형태로 업무를 분류 Flowchart 형태로 업무를 정의하여 고객과 협의 BPM 관점의 to-be 분석 절차 2. 업무별 프로세스 정의 각 업무영역별 End-to-End Process 작성 5. to-be 프로세스 정의서 작성 프로세스별 상세 내역(Activity, Data, 기능 등) 정의 10
  • 12. To-Be 설계 절차와 각 요소의 관계 To-Be 설계는 ERP를 기반으로 한 하나의 완결된 업무 프로세스를 구성하도록 프로세스를 중심 으로 Report, Data, System 정보를 통합하는 것 to-be 분석 절차 Process Organiza tion Report Data System 업무영역 도 출 Process Flow 작성 Process 확정 업무별 End- to-End Process Report 수요 파악 대상 Report 확정 Layout, Data 정의 핵심 Data 확정 조직구조 정 의 Configuration GAP ERP 데이터 확인 Data Mapping I/F 대상 확 인 I/F CBO 개 발 Business Process Mapping Data Dictionary 정의 To-Be System Image Test 11
  • 13. To-Be 설계의 원칙  To-Be는 기업의 경영전략과 일치시켜야 함  큰 그림  작은 그림  Data의 정확한 흐름 중심  핵심 프로세스  비핵심 프로세스의 순서대로 작업  철저한 고객과의 Communication : Flowchart 활용  To-be는 명확해야 함 : 빠짐없는 Process와 activity, 정확한 data  To-be는 단순한 이상향을 그리는 게 아님  ERP 기반의 개선된 모습 (ERP Standard = 기업 비즈니스 프로세스와 IT의 이상향)  각각의 프로세스의 가치 : 왜 이 프로세스가 필요? 어떤 역할, 어떤 결과물? 등에 대한 이해  가중치 부여/분석  핵심/비핵심 프로세스 구분  고객에게 또는 스스로에게 질문 - “이 기업이 5년 후에 어떤 모습이길 원하는가? - “기업의 전략을 가능하게 하기 위해 필요한 경영 전략은 무엇인가?”  각 모듈별로 TO-BE 프로세스를 작성을 하였으면 다 모여서 통합 프로세스를 설계 12
  • 14. To-Be 프로세스 설계 13  경영전략, End-to-End Business Process의 반영  ‘ERP = To-Be’라는 정신  고객과의 끊임없는 커뮤니케이션을 통해 확정 (by Flowchart)  ‘To-Be = ERP’가 될 수 있도록 사전 정지작업 필수 : 교육, 타사사례 제공, 벤치마킹, 각종 관 련 정보의 제공 등 적극적 변화관리 활동  최소한 핵심 프로세스에 대해서라도 ERP Standard 관철  화면을 자주 접할 수 있도록 다양한 방법 강구 : News letter, 교육, Visioning 등  입출력되는 데이터(정보)의 종류와 성격 등을 명확히 정의  핵심 프로세스의 선정 - 프로세스 주기, 빈도, 관련자, 출력물의 활용도, 업무의 비중, 입출력 데이터의 양 등 - 많은 경우 As-Is와 비슷한 구조로 감
  • 15. To-Be 보고서 설계  보고서 설계의 원칙 정의 예) 시뮬레이션 또는 수시보고용 개별보고서는 OLAP 툴로 흡수(전략적 판단) 공식보고서 외에는 조회화면 등으로 대체 등등  보고서에 필요한 핵심 데이터의 추출, 정의 : 비핵심 데이터, 손이 많이 가는 데이터의 처리 방법 또는 우회로  필요한 데이트의 확보  대응책 수립 : Standard, CBO, Legacy? 14
  • 16. To-Be 시스템 설계  근간이 되는 시스템은 ERP  ERP를 중심에 두고 Legacy 배치 핵심정보, 기준정보, 결과정보 등은 ERP 관리, Transaction 정보, 참고성 정보 등은 Legacy에서 관리  ERP, PI(XI)를 통한 통합 Architecture 환경 구성  Data의 중복, 누락 여부 확인 : Report, Data의 정보 확인 15
  • 17. To-Be 조직 설계  프로세스 설계에 따른 기본 조직구조 정의  중복 또는 누락 조직 점검  HR조직과 분리해서 생각 : 주로 결재, 보고선 지정  Organization 설계는 ERP Configuration에 직접적인 영향 – 모듈과 충분히 협의 16
  • 18. To-Be 설계의 Check-point 17  End-to-End Process를 도출했는가?  핵심 프로세스를 발라 냈나?  Flowchart를 Activity나 Event가 빠지지 않게 명확하게 그릴 수 있는가?  업무 Flow상, Interface상 입출력 Data에 대해 명확히 알고 있는가?  고객과 충분히 합의된 flow인가?  Flow에는 Data의 흐름이 분명히 표현되어 있는가?  프로세스를 Level별로 체계화/계층화 할 수 있는가?  Interface 부분은 타 시스템, 타 모듈과 충분히 협의되었는가?  To-be Data(특히 핵심 Data)를 파악하고 있는가?  작업 분량(Configuration, CBO, 자료이관 등)에 대해 ‘감’이 오는가?  ERP Standard를 충분히 반영한 프로세스인가?  To-Be의 원천 요소들이 제대로 반영되어 있는가?  To-Be를 그리기 전 또는 그리면서 PI들에게 ERP 교육을 충분히 시켰는가?
  • 19. Ⅰ. TO-BE 설계란 무엇인가? Ⅱ. TO-BE에는 무엇이 있는가? Ⅲ. 어떻게 TO-BE를 설계할 것인가? [첨부] TO-BE 설계 TIP : FLOWCHART
  • 20. Process를 위한 고객과의 Communication 서로 다른 배경지식과 경험을 가진 사람들이 단기간에 업무 협의를 하는 과정에서 ‘수많은 오해 와 오해 발생  잘못된 설계와 잘못된 구축으로 인한 재작업  그리고 이에 따른 일정의 지연 과 고객과의 갈등’이라는 악순환을 피하는 커뮤니케이션이 중요 19 말(언어) 텍스트형 문서 간략한 메모, 회의록 Legacy 화면 정책, 규정, 보 고서 등  단편적, 단절적  전체 그림을 볼 수 없음  프로세스의 흐름을 볼 수 없 음  같은 내용에 대한 서로 다른 이해(=오해)  보이지 않거나 보여도 의미 파악이 어려움  체계화되지 않음 Flowchart!! 고객과 컨설턴트간에 오 해를 최소화하면서 효과 적인 커뮤니케이션을 위 한 수단/방법이 없을까?
  • 21. 왜 Process Flowchart인가? 프로세스 Flowchart를 활용하게 되면 타 의사소통 수단에 비해 오류가 적고, 적극적이면서도 명확한 커뮤니케이션이 가능하다 20 1. 눈에 보인다  구체적이고 실질적인 협의 가능 : To-Be를 설계하려면 자신들의 현재의 지식/경험 범위 바깥에서 프로세스가 어떻게 작동하는지 객관적으로 알 필요  Flowchart는 짧은 시간에 이것들을 총체적이고 일목요연하게 볼 수 있게 해줌 2. 기업이 더 효율적으로 변화할 수 있도록 해 줌 : 업무를 처리하는 데 쓸데없는 비용을 발생시키는 중복과 비효율성을 구분할 필요  구태에서 벗어나 더 효율적인 조직으로 발돋움
  • 22. Flowchart 예시 - 휴가관리 21
  • 23. Process Flowchart 그리기 tip  Sample Flowchart 확보  계속 수정/보완하면서 완성  큰 프로세스에서 작은 프로세스로, Activity로 breakdown : Big Picture  선후행 프로세스 명시 : 단순한 연결(linkage)인지 의존관계(dependency)인지 파악  프로세스의 Input과 Output 명시 : I/O 없는 프로세스는 없다!  Data(혹은) 정보의 흐름에 주의 : 프로세스 = Data(정보)의 흐름  고객과의 커뮤니케이션을 위한 수단  고객의 눈높이에 맞춰 쉽고 상세하게  핵심 프로세스 선정  핵심 프로세스는 상세하게, 비핵심 프로세스는 대충  Flowchart를 보면서 고객들이 스스로 자신들의 현행 프로세스의 문제점을 인식/가시화하고, 그 프로세스를 재평가하여 스스로 불필요한 단계를 제거하거나 개선하는 기회 22