Mapping 절차

1. Mapping 절차와 방법
2012. 6.
이성복

2. Mapping이라고?
Mapping은 패키지 기반의 솔루션으로 IT시스템을 구축하는 프로젝트에서만 사용되는
용어로써, 이미 구축된 어플리케이션 위에 해당 프로세스를 구축하는데 필요한(또는 해
당되는) 프로세스/기능을 찍어서 표시하는 것
1
Map = 지도
 Mapping은 지도위에 해당 지점을 표시하는 것
 ERP 프로젝트에서 Map = ERP
 Mapping = ERP Standard에 요구사항을 꿰어 맞추는 것

3. Mapping을 위해 필요한 조건
명확하고 바람직한 Mapping이 되기 위해서는 컨설턴트 내/외적인 역량과 환경 조건
이 준비되어 있어야 한다.
Consultant 역량 대외 환경
 ERP Standard에 대한 지식
 개인의 학습, 경험 등을 통한 ERP
Standard에 대한 정확하고 폭넓은
지식
 지식의 원천에 대한 지식
 다양한 구축 경험
 업종별, 규모별, 기간별로 다양한 프
로젝트 구축 경험
 업무 지식과 경험
 해당 업무에 대한 깊이 있는 지식
 직,간접적인 경험을 통한 노하우
 명확한 고객의 요구사항
 고객과 Baseline에 대한 명확한 합
의/서명
 고객의 변화관리
 Mapping 전 ERP에 대한 꾸준하고
충분한 교육 또는 정보 전달
 Mapping 결과를 이해하고 논의할
수 있는 수준
 ERP에 대한 이해와 긍정적인 태도
2

4. Mapping 절차
Mapping은 구축의 방향과 내용을 결정하는 중요한 작업이므로 To-Be와 ERP
Standard에 대한 정확한 이해가 필요하다.
 Standard가 전체적인 관점에서 해당 to-be
프로세스를 지원하는가
 또는 관련된 프로세스가 Standard에 있는가
1. 해당 프로세스를 지원하는가?
2. Activity 또는 기능을 지원하는가?
3. 해당 데이터를 지원하는가?
 해당 Activity나 기능을 1:1로 지원하는가
 대체할 만한 Workaround가 있는가
 결정적인 것인가 사소한 것인가
 데이터의 성격에 맞게 생성, 유통, 저장되는
가
 To-be에서 요청하는 바로 그 데이터인가
Mapping 원칙
고객의 승인 하에 Baseline 확정
1. To-Be 확정
3. 프로세별/기능별 Mapping
4. GAP 도출
업무의 특성에 맞춰 프로세스 단위 또는 기능단
위까지 Mapping 작업 수행
ERP Standard에서 수용할 수 없는 내용 도출
Mapping 절차
2. Function 도출
Mapping을 위해 sub-process의 기능요구사항
을 도출
5. 해결방안(Solution) 수립
GAP으로 도출된 내용들은 각각의 유형에 따라
별도의 해결방안을 수립하고 추진
3

5. Mapping 이후
Mapping된 프로세스/기능에 대해서는 결과를 확정하는 Standard 테스트 작업이 필요
하며, GAP으로 도출된 내용들은 각각의 유형별로 적절한 해결책을 수립한다.
4
Mapping
1. 프로세스 테스트 후 매핑 결과 확정
2. 도출된 GAP을 분석하여 솔루션 협의/확정
 Mapping 결과를 가지고 핵심 프로세스에 대해 Configuration
 테스트하여 정상 작동여부, 요구사항 만족 여부 확인(고객과 함께)
 매핑 결과 확정
※ Mapping에서 GAP으로 도출된 기능/Activity는 생략하고 테스트를 위한 임시 처리
 GAP 유형을 분석/분류하고 솔루션을 확정함
 CBO  프로그램 개발
 R&R  이해관계자 분석하여 관련 내용 협의
 고객 설득사항  대안을 수립하여 관련자 설득(PI  현업 순)

6. [참고] Mapping 상세 절차

7. Mapping 방법 - 예시
 E = ERP 기능 매핑  매핑 근거와 해당 t-code 기술
 M = 수작업
 I = 대외 시스템 또는 내부 Legacy 와의 Interface
 L = Legacy에서 처리하는 Activity 또는 Function
 N = Mapping되는 기능 없음  GAP으로 도출되며, Solution 정의
6

8. Mapping 시 고려할 사항
 Mapping의 주체는 Consultant
 To-Be를 설계하면서 이미 ERP Standard의 관련 프로세스와 기능/화면을 떠올려야
함
 To-Be의 프로세스나 기능과 ERP의 프로세스나 기능을 1:1로 Mapping 한다는 생각
을 버려라.
 중요한 것은 프로세스의 목적과 데이터의 흐름
 다른 방식으로라도 해당 프로세스나 기능을 지원할 수 있는 방법이 있다면 그것
으로 Mapping
 Mapping에 CBO 솔루션(타사 산출물)을 공식적으로 고려하지 않는다.(별도로 구매한
3rd Party 솔루션은 제외)
 나중을 대비해 협상카드로 가지고 있어라
 Mapping 작업을 통해 전체 구축 규모를 가늠할 수 있어야 함  Mapping 이후 재
산정된 업무 분량에 따라 전체적인 Task와 Task별 일정을 조정(WBS 업데이트)
 핵심 프로세스나 기능에 대해서는 반드시 데모 시스템에서 확인을 거친 후 확정한다.
 이 과정에서 새로운 GAP이 나오게 되거나, GAP으로 도출했던 것이 GAP 아닌 것
으로 결정될 수 있다
7

9. GAP 도출과 Solution 수립 시 고려사항
 To-Be와 ERP를 1:1로 매핑하려고 하지 말고 ERP에서 수용할 수 있는 다양한 방법을
찾은 후 GAP을 도출한다.
 GAP은 반드시 GAP_ID를 부여한다.
 GAP_ID는 이후 CBO나 이슈, Solution Paper에 붙어서 따라 다녀야 하며 추적이 가
능해야 한다.
 GAP으로 도출된 것은 다시 한 번 Simulation 또는 데모 시스템에서의 테스트를 통해
확인한다.
 GAP은 반드시 적절한 유형별로 분류하고, 각 분류된 유형별로 해결방안을 수립한다.
 편리한 기능을 위해 GAP을 도출하지 않는다.
 CBO 중심의 해결방안은 지양한다.
 GAP으로 도출된 해당 기능이나 프로세스에 국한하지 말고 한 단계 더 넓은 차원에
서 문제를 보고 해결방안을 수립한다.
 사소하거나 시스템으로 구축시 한계가 있는 기능/절차들은 수작업 또는 업무 개선을
유도한다.
8

10. Mapping 이후의 위험 징후
 향후 자신이 구축해야 할 분량이 어느 정도인지 확실하게 모르겠다.
 그래서 WBS를 업데이트할 수도, 적절한 업무 배분을 할 수도 없다.
 Mapping율이 현저히 낮다  컨설턴트로써 FD 작성하는 거 말고 내가 할 일이 별로
없다.
 특히 트랜잭션 관련 기능의 매핑율이 너무 낮다.
즉, CBO로 구현해야 하는 트랜잭션 기능이 상대적으로 많다.
 고객과의 합의 없이 또는 고객의 불만이나 반대에도 불구하고 일방적으로 Mapping
했다.
 1차 Mapping 이후 최소한 핵심 프로세스에 대한 기본적인 검증 절차(Demo Conifg
& test)를 거치지 않고 확정했다.
9

11. 헉, 헉, 힘들다…