ݺߣ

ݺߣShare a Scribd company logo

Mapping 절차와 방법.pptx

•Download as PPTX, PDF•
•
Seong-Bok Lee
Seong-Bok Lee

Mapping 절차

1 of 11
Download to read offline
Mapping 절차와 방법 2012. 6. 이성복
Mapping이라고? Mapping은 패키지 기반의 솔루션으로 IT시스템을 구축하는 프로젝트에서만 사용되는 용어로써, 이미 구축된 어플리케이션 위에 해당 프로세스를 구축하는데 필요한(또는 해 당되는) 프로세스/기능을 찍어서 표시하는 것 1 Map = 지도  Mapping은 지도위에 해당 지점을 표시하는 것  ERP 프로젝트에서 Map = ERP  Mapping = ERP Standard에 요구사항을 꿰어 맞추는 것
Mapping을 위해 필요한 조건 명확하고 바람직한 Mapping이 되기 위해서는 컨설턴트 내/외적인 역량과 환경 조건 이 준비되어 있어야 한다. Consultant 역량 대외 환경  ERP Standard에 대한 지식  개인의 학습, 경험 등을 통한 ERP Standard에 대한 정확하고 폭넓은 지식  지식의 원천에 대한 지식  다양한 구축 경험  업종별, 규모별, 기간별로 다양한 프 로젝트 구축 경험  업무 지식과 경험  해당 업무에 대한 깊이 있는 지식  직,간접적인 경험을 통한 노하우  명확한 고객의 요구사항  고객과 Baseline에 대한 명확한 합 의/서명  고객의 변화관리  Mapping 전 ERP에 대한 꾸준하고 충분한 교육 또는 정보 전달  Mapping 결과를 이해하고 논의할 수 있는 수준  ERP에 대한 이해와 긍정적인 태도 2
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
Mapping 이후 Mapping된 프로세스/기능에 대해서는 결과를 확정하는 Standard 테스트 작업이 필요 하며, GAP으로 도출된 내용들은 각각의 유형별로 적절한 해결책을 수립한다. 4 Mapping 1. 프로세스 테스트 후 매핑 결과 확정 2. 도출된 GAP을 분석하여 솔루션 협의/확정  Mapping 결과를 가지고 핵심 프로세스에 대해 Configuration  테스트하여 정상 작동여부, 요구사항 만족 여부 확인(고객과 함께)  매핑 결과 확정 ※ Mapping에서 GAP으로 도출된 기능/Activity는 생략하고 테스트를 위한 임시 처리  GAP 유형을 분석/분류하고 솔루션을 확정함  CBO  프로그램 개발  R&R  이해관계자 분석하여 관련 내용 협의  고객 설득사항  대안을 수립하여 관련자 설득(PI  현업 순)
[참고] Mapping 상세 절차
Mapping 방법 - 예시  E = ERP 기능 매핑  매핑 근거와 해당 t-code 기술  M = 수작업  I = 대외 시스템 또는 내부 Legacy 와의 Interface  L = Legacy에서 처리하는 Activity 또는 Function  N = Mapping되는 기능 없음  GAP으로 도출되며, Solution 정의 6
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
GAP 도출과 Solution 수립 시 고려사항  To-Be와 ERP를 1:1로 매핑하려고 하지 말고 ERP에서 수용할 수 있는 다양한 방법을 찾은 후 GAP을 도출한다.  GAP은 반드시 GAP_ID를 부여한다.  GAP_ID는 이후 CBO나 이슈, Solution Paper에 붙어서 따라 다녀야 하며 추적이 가 능해야 한다.  GAP으로 도출된 것은 다시 한 번 Simulation 또는 데모 시스템에서의 테스트를 통해 확인한다.  GAP은 반드시 적절한 유형별로 분류하고, 각 분류된 유형별로 해결방안을 수립한다.  편리한 기능을 위해 GAP을 도출하지 않는다.  CBO 중심의 해결방안은 지양한다.  GAP으로 도출된 해당 기능이나 프로세스에 국한하지 말고 한 단계 더 넓은 차원에 서 문제를 보고 해결방안을 수립한다.  사소하거나 시스템으로 구축시 한계가 있는 기능/절차들은 수작업 또는 업무 개선을 유도한다. 8
Mapping 이후의 위험 징후  향후 자신이 구축해야 할 분량이 어느 정도인지 확실하게 모르겠다.  그래서 WBS를 업데이트할 수도, 적절한 업무 배분을 할 수도 없다.  Mapping율이 현저히 낮다  컨설턴트로써 FD 작성하는 거 말고 내가 할 일이 별로 없다.  특히 트랜잭션 관련 기능의 매핑율이 너무 낮다. 즉, CBO로 구현해야 하는 트랜잭션 기능이 상대적으로 많다.  고객과의 합의 없이 또는 고객의 불만이나 반대에도 불구하고 일방적으로 Mapping 했다.  1차 Mapping 이후 최소한 핵심 프로세스에 대한 기본적인 검증 절차(Demo Conifg & test)를 거치지 않고 확정했다. 9
헉, 헉, 힘들다…

More Related Content

Mapping 절차와 방법.pptx

  • 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  현업 순)
  • 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