ERP 구축시 To-Be 설계 절차와 방법

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

24. 다음에 계속…?