현재 중국에서는 소프트웨어 상담을 하는 사람들이 이미 거리에서 썩었다.
많은 사람들이 기술 전환을 하고 있고, SAP 기능은 모두 익숙하다.
어떤 사람들은 기업에서 컨설팅 회사로 옮겨갔는데, 원래 업무는 매우 정통했다.
어떤 사람들은 졸업하자마자 컨설팅 회사에 들어갈 수 있고, 프로젝트마다 하나씩 들어갈 수 있다.
이 모든 사람들, 이 서클에 섞인 사람들은 대부분 프로젝트가 어떻게 하는지, 1, 2, 3 이라고 말할 수 있다.
어떤 청사진, 건설, 테스트, 구현 과정의 이러한 단계들은 누구나 다 알고 있다고 말할 수 있다.
그런데 프로젝트가 어떻게 하는지 정말 아시나요?
배포에 필요한 작업을 정확히 알고 계십니까?
당신은 정말 프로그램에 배포 사이의 연결을 이해 합니까?
너는 네가 왜 이렇게 하는지 정말 알고 있니?
먼저, 가장 세부적인 것부터 시작해보죠.
내가 이 프로젝트를 처음 시작했을 때, 나는 말레이시아 사람인 외국 회사에 의해 해고되었다.
당시 각 팀은 PPT 가 만든 상태 보고서를 작성해야 했고, 전문적인 템플릿이 있었다.
일주일에 한 번 회의를 하고, 모두 함께 팀 리뷰를 진행한다.
회의 기간 동안 프로젝트 관리자는 보고서 형식에 초점을 맞출 것입니다.
Ctrl C+Ctrl V 를 사용하여 페이지를 추가할 수 없습니다. 가장 완벽하게 템플릿을 복사하려면 PPT 에 페이지를 삽입해야 합니다.
각 페이지에 있는 각 텍스트 상자의 글꼴 크기는 템플릿과 일치해야 합니다.
분기, 단락, 페이지 수 및 날짜 형식은 템플릿과 일치해야 합니다.
보고 내용에는 반드시 정확한 숫자가 있어야 한다. 이번 주에 얼마나 완성할 계획이고, 실제로 얼마나 완성할 계획입니까? 너는 절대로 백분율로 네가 과거에 해야 했던 임무를 희롱해서는 안 된다. PIC (책임자) 와 목표 날짜가 있어야 합니다.
사물을 묘사할 때 "우리", "그들" 과 같은 단어를 사용할 수 없다. "우리" 는 누구입니까? 그들은 누구인가?
마지막으로, 우리는 개정 역사를 써야 한다.
당시 우리, 특히 국내 동료들은 모두 매우 번거로웠다. 왜 이렇게 많은 시간을 들여 이 세부 사항들을 보아야 합니까?
글씨가 달라도 괜찮아요. 각 작업의 완성은 정확한 숫자까지 시간이 많이 걸린다.
그러나 시간이 지남에 따라 나는 익숙해질 것이다.
몇 년 후, 제가 다른 공기업 프로젝트의 상태 보고서를 보았을 때,
그 공기업 프로젝트의 상태 보고서에도 템플릿이 있지만 간단하다.
구체적인 보고 내용은 내가 위에서 언급한 요구 사항이 전혀 없다.
결국 나는 전혀 이해하지 못했다.
또한 다른 그룹의 보고서를 함께 요약해야합니다. 글씨체가 다르면 페이지를 바꿀 때 차이가 뚜렷이 드러난다.
상태 보고서는 사소한 일일 뿐이다. 그러나 세부 사항에 주의를 기울이는 것은 매우 중요하다.
누가 무슨 일을 하는지, 누가 심사할 것인지, 어떻게 할 것인지, 언제 완성할 것인지. 。 。
네가 분명히 말하지 않으면, 다른 사람도 모를 것이다. 결과는 반드시 일을 잘 하지 못하거나 미루는 것이다.
따라서 프로젝트를 잘 하려면 먼저 세부 사항을 진지하게 다루십시오.
둘째, 물류
이곳의 물류는 물류를 가리키며, 프로젝트의 모든 사람에게 제공되는 생활과 업무 서비스이다.
왜 이것을 말해야 합니까?
배포로서 우선 PM 이 물류 문제를 해결해야 하기 때문이다.
지금 프로젝트를 하고 있는데, 대부분의 멤버들은 다른 곳에서 왔다. 그럼 숙박은 어떻게 배정해야 하나요?
일반적으로 PM 은 현지 호텔 몇 곳과 가격을 이야기하며, 때때로 고객이 합의된 가격을 받을 수 있다.
당신은 고객으로부터 너무 멀리 살 수 없습니다. 출퇴근은 시간이 많이 걸리고 택시비도 비쌉니다.
거주지는 시내에서 너무 멀리 떨어져 있지 말고 상담사가 출장을 갈 때 세상과 단절하지 말고 생활의 편리성을 고려해야 한다.
당신이 사는 곳의 방 유형은 무엇입니까? 1 사람 세트인가요, 아니면 2 인 세트인가요?
만약 두 사람이 있다면, 인원은 어떻게 안배합니까? 너는 두 사람을 함께 둘 수 없다.
이 두 사람이 함께 지낼 수 있을지 생각해야 한다.
공항과 고객을 오가는 데 어떤 교통수단을 사용하시겠습니까?
정규택시 기사를 찾나요, 아니면 길에서 직접 택시를 타나요?
알다시피, 안전 제일!
먹는다면 대원들은 어떤 금기와 외국 습관이 있습니까?
고객처에서 사무실은 어디에 있습니까?
한 프로젝트에 약 20 명, 주요 사용자까지 포함해서 어떻게 앉을까요?
일반적으로 한 팀이 함께 한다면 팀 간의 소통은 어떨까요?
FI 와 CO 는 더 가까워야 하고, PP 는 mm 에 더 가까워야 한다.
상담사와 주요 사용자는 옆에 앉는 것이 가장 좋다. 상담사가 쓸데없는 일에 참견할 필요가 없어 의사소통이 편리하다.
사무실, 출입증, 전화, 팩스, 프린터, 복사기, 정수기, 인터넷, 에어컨, 프로젝터, 회의실.
잠깐, 이 자원들은 정리해야 한다.
다른 사람이 찾을 수 있도록 팀 구성원의 이름을 좌석에 붙이다.
주소록을 하나 만들어서 인쇄하여 모두에게 보내는 것이 가장 좋다.
.....
사실 물류에는 알아야 할 것이 너무 많다.
하지만 알다시피, 이것은 PM 이 책임지는 일이다.
이 시점에서 프로젝트가 아직 시작되지 않았기 때문에 인원도 오지 않았다.
그리고 많은 비용 관련, PM 은 비용을 통제해야합니다.
물론, 때로는 프로젝트가 시작되면 PM 도 다른 사람이 관리할 수 있도록 도움을 받을 때가 있다.
그러나 이 작업은 항상 배포로서 수행해야 하는 작업입니다.
아마도 많은 PM 이 마음대로 이것을 할 수 있고, 심지어 돈을 아까워할 수도 있다.
하지만 제가 말씀드리고 싶은 것은 일이 잘 진행되고 있는지, 세부 사항을 보아야 한다는 것입니다.
배정된 자원이 다른 사람의 감정과 생각을 고려하는지 여부.
우리는 어떻게 하면 나쁜 환경에 대해 불평하지 않고 즐겁게 일할 수 있는지 고려해야 한다.
셋째, 글로벌 틀
글로벌 계획을 예로 들어 보겠습니다.
템플릿이란 무엇입니까?
일반적으로 다국적 기업은 SAP 를 구현할 때 서로 다른 국가와 다른 공장에 직면해야 합니다.
지점마다 업무가 다르고, 생산형 공장도 있고, 무역회사도 있습니다.
그렇다면 다국적 기업으로서, 일반적으로 하나의 시스템에서 업무 통합이 필요하다.
SAP 에는 1 개의 클라이언트가 있으며 여러 회사 코드로 나뉩니다.
회사 코드는 별도의 분기입니다.
따라서 실제로 SAP 를 구현하기 전에 전체 엔터프라이즈 (클라이언트) 아키텍처를 고려해야 합니다.
통합 비즈니스 프로세스, 통합 솔루션 및 통합 데이터 형식을 포함합니다.
이렇게 통일된 것을 템플릿이라고 합니다.
우리 자신의 말로 글로벌 템플릿이라고도 합니다.
이것들을 설계한 후에, 우리는 한 공장에 가서 실현한다.
공장이 실현되는 과정에서, 너는 분명히 템플릿과는 다른 수요를 만날 것이다. 이때 템플릿을 수정할 수도 있습니다.
템플릿에는 무엇이 포함되어 있습니까?
첫 번째는 조직 구조입니다
이러한 템플릿을 제어하려면 관리 전담 팀, GT 팀 (Global 템플릿 팀) 이 필요합니다.
이 팀의 모든 사람은 fi, mm 과 같은 분야의 전문가입니다. 이 팀원들은 CFO 와 같은 기업 차원의 BPO (비즈니스 프로세스 책임자) 를 대상으로 합니다.
각 배포 구현 과정에서 배포 팀에서 발생하는 템플릿 변경 요구 사항은 GT 팀에 에스컬레이션되어야 하며, GT 팀은 이러한 수정이 가능한지 확인하기 위해 다른 배포를 조율해야 합니다.
예를 들어 배포에서는 필드를 사용하여 품목 마스터에 일부 참조 정보를 배치하려고 합니다.
괜찮으세요? 이것은 SAP 의 표준 기능에서 이 필드의 목적이 무엇인지 고려해야 합니다.
품목 마스터는 모든 공장에서 공통입니다. 다른 배치를 구현할 때 이 필드를 사용합니까?
이 필드는 시스템 보고서에 사용됩니까?
.....
템플릿은 청사진 디자인에 중점을 둡니다.
품목 마스터에 대한 명명 규칙은 무엇입니까?
어떤 종류의 재료가 어떤 재료에 사용됩니까?
팀의 주체는 어떻게 정의합니까?
비용 부서, 이익 센터, 제품 계층
품목 원장을 사용하시겠습니까?
분할로 평가하시겠습니까?
문서 유형의 용도는 무엇입니까? 숫자 범위는 얼마입니까?
.....
통합 프로세스
예를 들어, 구매 요청이 제출되면 승인됩니다.
예를 들어 생산 주문이 릴리즈되었는지, 주문 릴리즈인지, 백플러쉬인지, 둘 다 있는지 등을 예로 들 수 있습니다.
.....
통합 권한 제어
공통 역할을 설정하고, 배포하고, 복제하면 됩니다.
.....
템플릿에는 프로그램 개발도 포함되어 있습니다.
일부 보고서는 기업 전체에서 사용되기 때문에 템플릿에서 잘 한다.
배포 기간에는 사용하시면 됩니다.
.....
및 문서 템플릿
모든 파일 형식, 상태 보고서, 데이터 변환 템플릿, 보류 중,
물론 제가 처음에 말씀드린 서체 크기, 행 분할 등은 모두 템플릿에 정의되어 있습니다.
템플릿을 만드는 방법
아쉽게도 나는 템플릿을 만들어 본 적이 없어서 이 부분을 자세히 말하지 않았다.
제작 템플릿도 별도의 프로젝트입니다.
일반적으로 프로그램이 시작된 후, 배치가 시작되기 전에.
기업들은 컨설턴트와 사용자를 포함하여 여러 공장에서 나올 수 있는 많은 사람들을 모을 것이다.
프로세스는 또한 비즈니스 조사, 청사진 설계, 제도 구축, 문서 준비 등과 같은 프로젝트를 수행하는 것과 같습니다.
왜 템플릿을 만들어야 합니까?
템플릿이 없다면 어떻게 기업을 위한 통합 SAP 시스템을 구현할 수 있을지 상상하기 어렵다.
템플릿이 좋은지 아닌지는 세부 사항을 보아야 한다.
Template 로 만든 문서를 처음 봤을 때, 프로젝트에 사용할 모든 문서가 이렇게 상세하다는 사실에 놀랐습니다.
많은 경우, 우리는 그것을 베껴 써서 몇 글자만 바꾸면 된다.
템플릿을 보면 쉽게 공장에 가서 실현할 수 있다.
따라서, 좋고 상세한 템플릿은 전체 방안이 성공하기 위한 전제 조건이다.
넷째, 로컬 입력 가져오기
템플릿이 있으면 다음 단계는 지사/공장에 가서 배포하는 것이다.
앞서 말씀드렸듯이 공장마다 업무가 다르기 때문에 템플릿이 완전히 적용되는 것은 아닙니다.
따라서 배포 초기에 첫 번째 단계는 현지 입력을 캡처하는 것이고, 중국어로는 현지 수요를 수집하는 것이다.
그렇다면 어떻게 수요를 수집할 수 있을까요?
우선 소개 자료를 준비해 주세요. SAP 시스템 및 템플릿 설계를 소개합니다.
소개자료는 일반적으로 PPT 로 제작되며, Workshop 에서 사용자에게 설명하기 위해 사용됩니다.
요점은 사용자가 이해하는 방식으로 소개하는 것이다.
나는 훈련 자료를 포함한 몇몇 사람들이 쓴 자료를 본 적이 있는데, 완전히 기술적인 것이다.
어떤 함수를 사용했는지, T 코드가 어떤지, 시스템에 어떤 문서가 생성되었는지 알려주면 끝납니다.
그러나, 또한, 당신은 몇 가지를 쓸 수 있습니다:
1 .. 명사 설명
2. 기업이 템플릿 설계를 결정하는 정책은 무엇입니까?
3. 원래의 업무 프로세스는 무엇이고, 템플릿은 무엇을 바꿀 것이며, 어떤 이점이 있습니까?
4. 권한에 어떤 영향을 미치는가, 업무에서 어떤 직위가 어떤 부문에 해당하는가?
우리는 템플릿을 기반으로 한 것임을 기억하십시오. 즉, 공장에 가서 현지 입력을 캡처하기 전에 숙제를 해야 합니다.
자료를 소개한 후에는 문제 목록이 있어야 한다.
어떤 재질 유형이 사용됩니까?
완제품이 있는지, 원료가 있는지 직접 물어볼 수는 없습니다.
실례합니다, 판지, 나무 트레이 및 목재 컨테이너와 같은 포장재가 있습니까?
연료, 산업 화학 물질, 윤활제와 같은 석유 화학 제품이 있습니까?
.....
어떤 결제 방법을 사용하시겠습니까?
예를 들어 30 일 동안 표를 보고 60 일 동안 표를 본다.
.....
템플릿에 기초하여 매우 기초적인 질문을 하지 마라. 실제 업무와 관련이 있어야 하며 후기의 시스템 설계 문제를 직접 도울 수 있어야 한다.
로컬 입력 캡처 단계에서는 일반적으로 여러 부서의 사용자가 호출되어 Workshop 을 시작합니다.
소집된 사용자의 수와 범위를 자세히 연구해야 한다.
사용자는 MM 과 FI 의 두 세션에 동시에 참여할 수 없습니다. 그래서 필요하다면 시간을 엇갈리게 해야 한다.
일부 워크샵에는 BPO 가 필요합니다. 미리 인사를 하고 초대장을 보내야 합니다.
일부 워크숍은 통합 회의라고 하는 다양한 기능 팀과 논의해야 합니다.
워크숍이 끝나면 로컬 입력을 기록하고 로컬 입력 목록이 되어야 합니다.
이 목록에는 당연히 그것을 포함해야 한다.
1. 간단한 문장으로 이러한 입력을 설명합니다.
상세히 소개하다
3. 누가 제기했습니까?
4. 제출 일자
5. 해당 BPO 는 누구입니까?
6. 각 품목에 대해 다른 분류를 정의할 수 있는 분류.
7. 수요 유형. 사양구성 관련 수요입니까, 아니면 데이터 변환과 관련된 수요입니까?
8. 글로벌 템플리트에 영향을 미칩니까?
9. 우선 순위, 이 우선 순위는 특별한 정의가 있습니다. 사용자가 높거나 높다고 말하는 것이 아닙니다.
10. 누가 이 수요를 추적할 책임이 있습니까?
1 1. 가능한 솔루션
12. 상태, 켜기 또는 끄기
여기서 언급해야 할 것은 필요한 레코드 수가 중요하지 않다는 것이다. 추적이 잘 되고, 후기에 사용자와 확인하면 상태가 꺼짐이면 된다.
나는 두 명의 사용자가 대천에서 말하는 것이 너무 적을까 봐 두렵다.
이 단계에서 프로젝트 경험은 여전히 중요합니다. 많은 요구는 작업장에서 취소할 수 있다.
또한 보고 수요도 이 단계에서 수집해야 합니다.
요점은 이 단계에서 합리화와 합리화를 해야 한다는 것이다.
발전의 수요일수록 더 짜증나고, 자르고, 자르고, 잘라야 한다는 것을 알아야 한다. (존 F. 케네디, 노력명언)
마지막으로, PM 은 매일 회의를 하고 상태를 검토해야 한다.
오늘 수집한 현지 입력은 얼마나 되고, 얼마나 높습니까?
상태를 추적하다.
마지막으로 다음 단계의 청사진 설계의 기초로 BPO 와 로컬 입력 목록을 확인해야 합니다.
다섯째, 청사진 디자인
청사진 설계 단계에서 주요 시간은 현지 입력 솔루션을 논의하는 것입니다.
즉, 우리는 수요를 수집하는 이 단계에서 해결책을 찾아야 한다.
그중 세 개의 문서가 가장 중요하다.
그것들은 청사진이고, 과정과 데이터 변환의 방법이다.
청사진이란 무엇입니까?
시스템 설계 및 솔루션과 같은 몇 가지 개념적 소개가 있습니다. ....
사실 이것은 일련의 Word 문서입니다.
각 문서에는 각 기능 설계에 대해 자세히 설명하는 모듈이 있습니다.
이 문서에는 이 기능에 대한 요구 사항 소개, 상세한 요구 사항 분석 및 솔루션, 이 구축에 대한 특별한 결론이 포함되어야 합니다.
예를 들어 실제 재고 재고입니다.
1. 사용자의 요구 사항은 무엇입니까? 재고 정확성 보장? 재정적 균형에 부합하는가?
2. 자세한 요구 사항은 무엇입니까? 재고의 정확성은 공장 수준이나 저장 위치 수준에 따라 결정됩니까? 주기 실사를 사용하시겠습니까?
3. 해결 방법은요? A, b, c 에 대한 분류를 어떻게 정의합니까? 재고 조정의 사유 코드는 무엇입니까?
이 배포와 템플릿의 차이점은 무엇입니까?
곧 일어날 많은 일들을 보셨을 겁니다.
그러나 여기서는 문서의 사양을 강조해야 합니다.
사용된 기호, 표시 방법, 머리글 및 바닥글은 모두 템플릿에 따라 해야 합니다.
그렇지 않으면 이해하기 어렵다.
DCT (데이터 변환 방법) 는 데이터 변환을 위한 지침 파일입니다.
여기에는 이 배치에서 사용할 수 있는 변환 항목이 포함됩니다.
원시 데이터는 어디에 있습니까? 얼마나 많은 데이터가 있습니까? 누가 제공했어요? 누가 조정합니까? 누가 확인했어요?
기존 SAP 데이터 업로드 템플릿을 사용할 수 있습니까?
원시 데이터를 SAP 데이터 템플릿으로 변환하려면 어떻게 해야 합니까? 필드는 어떻게 일치합니까? 예를 들어 이전 시스템에서는 필드의 문자 길이가 SAP 의 필드 길이보다 큽니다. 어떻게 해결합니까?
.....
이 세 가지 문서는 청사진 설계 단계의 핵심입니다.
이 세 개의 서류를 정리한 후에 너는 BPO 와 함께 심사하고 서명해야 한다.
시스템 구축의 다음 단계의 기초로 삼다.
또한 개발할 물건의 목록도 이 단계에서 확정해야 한다.
프로젝트가 일환일환을 실시하다.
당신이 수집하는 수요가 불완전하거나 정확하지 않다면, 당신의 청사진 디자인은 분명 불완전할 것입니다.
청사진 단계에서는 아직 해결책이 없는 요구 사항이 있습니다. 만약 네가 이렇게 시스템 구축을 시작한다면, 앞으로 반드시 문제가 있을 것이다.
각 단계마다 완료된 플래그는 BPO 확인입니다. 앞으로는 마음대로 서명을 바꿀 수 없다.
물론 새로운 수요가 있을 수 없다는 뜻은 아니며, 일부 고객은 서명을 중시하지 않는다.
그러나 프로젝트 관리자로서 이러한 접근 방식을 고수하고 guide 사용자에게 이러한 접근 방식에 따라 협력하도록 요청해야 합니다.
이런 방법을 개발하는 것은 프로젝트 관리에서 가장 중요한 일이다.
여섯째, 구축 및 테스트
기술 문제를 연구하는 것은 중국인의 강점이다.
많은 강자들은 SAP 구성에 익숙하고 SAP 에서 어떤 기능을 실현할 수 있는지 알고 있습니다.
그러나 기술만 알고 컨설턴트가 되는 것만으로는 충분하지 않다.
먼저 시스템 환경을 소개하겠습니다.
SAP 에서 클라이언트마다 환경이 다릅니다.
지나가다
일반적으로 한 클라이언트는 구성에 사용되고, 한 클라이언트는 개발에 사용되고, 한 클라이언트는 샌드박스 (변경하고 사용하기만 하면 됨) 와 다른 클라이언트에 사용됩니다.
SIT 고객, UAT 고객, 교육 고객, 시뮬레이션 고객
고객 전환, 공식 생산 고객 및 사용자 지원 고객.
구성된 클라이언트는 어떤 트랜잭션도 할 수 없으며 구성 후 개발 클라이언트로 자동 전송할 수 있습니다.
개발 클라이언트에서 구성 요소 테스트 수행
개발 고객도 개발의 고객이다.
Config 의 클라이언트에서 어떤 거래라도 하면 일부 구성이 변경되지 않을 수 있기 때문이다.
예를 들어, 번호 범위, 거래, 번호 점프를 할 수 있습니다.
개발에는 테스트 절차가 필요하므로 개발 고객은 테스트 데이터가 필요합니다.
구성을 할 때는 먼저 구성 목록이 있어야 한다.
이 파일은 모든 SAP IMG 의 모든 구성 항목을 포함하는 Excel 파일입니다.
단일 열을 사용하여 이 배포에 필요한 구성, 클라이언트 간 구성 및 내부 거래 코드를 식별합니다. 또한 운송 요청 번호를 기록하십시오.
게다가, 물론 Config Notes 도 있습니다. 여러분도 많이 보셨을 겁니다.
운송은 기초에 의해 통제되며, 이 방면은 기초와 조화를 이루어야 한다.
누가 요청했는지, 누가 승인했는지, 언제?
일반적으로 대규모 프로젝트에서는 구성을 변경하지 않으려는 경우가 많습니다.
GT 팀의 승인을 받았습니다.
테스트는 구성 요소 테스트, SIT 및 UAT 로 나뉩니다.
구성 요소 테스트는 구성을 완료했음을 의미하며 구성을 사용할 수 있는지 확인하기 위해 환경을 테스트해야 합니다. 이 섹션에서는 청사진 설계 단계에 따라 SIT 및 UAT 에 사용자가 참여할 필요가 없습니다.
테스트 스크립트는 보류 중인 프로세스에서 가져온 것입니다.
사용자가 확인한 프로세스는 무엇입니까? 물론, 우리는 시스템에서 그것들을 시도해야 한다.
예를 들어 품목 마스터를 생성하고 판매 주문을 생성합니다. 。 。 。
SIT 및 UAT 의 테스트 스크립트는 BPO 와 확인해야 합니다.
SIT 및 UAT 의 테스트 스크립트 결과는 사용자 승인이 필요합니다.
SIT 와 UAT 의 차이점은
UAT 의 범위는 SIT 보다 크거나 같고, 일부 미처리 프로세스는 비교적 간단하고 거의 사용되지 않으므로 BPO 에 문의하십시오. 좌석이 다 차면 UAT 는 더 이상 재지 않아도 된다.
SIT 와 UAT 의 사용자 범위는 다릅니다. SIT 참여 사용자는 핵심 사용자이고 UAT 참여 사용자는 선별된 최종 사용자입니다.
통합 테스트도 있습니다. 즉, 일부 프로세스에는 3 개 이상의 모듈이 포함됩니다.
예컨대 재고생산, 주문생산
통합 테스트는 SIT 및 UAT 단계에 존재합니다.
테스트 스크립트: 테스트 데이터는 미리 준비해야 합니다.
테스트를 예약할 때, 우리는 사용자의 시간이 충돌하지 않도록 주의해야 한다. 일부 사용자는 모듈의 통합 테스트 및 테스트에 참여하므로 시간을 분리해야 합니다.
일곱째, 데이터 변환
데이터 변환은 온라인 이전에 데이터를 가져오는 것이 아니라 전체 프로젝트 구현 프로세스를 거칩니다.
이 부분을 주시하는 전담 지도자가 있어야 한다.
로컬 입력을 캡처할 때 데이터 수집 범위를 결정해야 합니다.
각 모듈에는 어떤 변환 항목이 있으며 데이터 소스는 어디에 있습니까? 데이터를 제공 하는 사람, 데이터를 수집 하는 사람, 데이터를 승인 하는 사람, 예상 데이터 양은 무엇입니까?
청사진 설계 단계에서는 세 가지 문서를 완성해야 합니다.
DCA (데이터 변환 방법), DMM (데이터 매핑 매트릭스) 및 DCT (데이터 변환 템플릿) 가 있습니다.
DCA 는 각 변환 항목을 SAP 시스템으로 가져오는 방법에 대해 자세히 설명해야 합니다
어떻게 상세한가요?
예를 들어, 사용자의 현재 데이터를 정리하려면 어떻게 정리해야 합니까?
구매 주문서 못 받으면 어떡하죠? 끝났어? 절반? 먼저 인보이스를 받습니까? 인보이스 반씩 받았나요?
사용자 시스템에서 데이터를 내보내는 방법은 무엇입니까? 수동 또는 도구? 누가 공구를 준비합니까? 누가 테스트합니까?
DMM 은 SAP 를 매핑하는 데 사용되는 사용자 시스템 및 필드입니다.
시스템마다 같은 필드라도 문자 길이가 다를 수 있습니다. 재료 매개변수는 말할 것도 없습니다.
DCT 는 SAP 에 업로드하기 전에 사용된 템플릿입니다. 기본적으로 DCT 의 필드는 SAP 의 필드와 정확히 일치합니다.
구축 및 테스트 단계에서는 변환 도구 구축&; 실험
이것은 이해하기 쉽다. 바로 이전의 DCA 에 따라 일을 시작하는 것이다.
이 단계에서 시뮬레이션 변환이 동시에 시작됩니다.
일반적으로 1, 시뮬레이션 2 및 FDR 의 세 가지 시뮬레이션 변환이 있습니다.
왜 이렇게 여러 번 했어?
아날로그
1 의 목표는 비교적 간단하다. 고라이브 데이터의 30~50% 만 준비할 수 있고, 생산업체는 완전한 BOM 을 준비할 수 있다. 이렇게 우습다
변환은 SIT 를 위한 기본 데이터를 준비하고, 데이터 업로드 시간을 예상하고, 업로드 도구를 테스트하여 사용자가 데이터 변환의 전 과정을 이해할 수 있도록 합니다.
Mock 2 는 더 높은 요구 사항을 가지고 있으며, 데이터 양은 Go Live 의 약 75% 가 필요합니다.
UAT 를 준비하기 위해 시뮬레이션 2 의 데이터는 재무 및 물류 균형을 확인하는 데 한 달이 걸립니다.
FDR 은 온라인 상황을 완전히 시뮬레이션하는 전체 리허설입니다.
업로드 데이터의 수와 일정은 분리 요구 사항을 참조해야 합니다.
그리고 FDR 프로세스의 데이터는 서명이 필요하며 간단히 온라인 시뮬레이션이 필요합니다.
동시에, 이 단계에서 준비한 많은 자료는 자재 마스터와 같은 분리에도 사용할 수 있으며, 더 이상 준비할 필요가 없다.
데이터 변환은 사용자의 시스템에 익숙해질 수 있는 매우 중요한 작업입니다.
좋은 아날로그 전환이 없는데, 어떻게 온라인이 순조롭게 진행될 수 있는지 보장할 수 있습니까?
마지막으로, 시스템이 온라인 상태가 되기 전에 그것이 마지막 데이터 변환이다. 전환 계획을 짜다.
각 변환 항목에 대해 언제 업로드합니까? 순서는 무엇입니까? 의존성이 있습니까?
업로드 소요 시간, 데이터 양? 누가 업로드를 담당합니까? 모든 관련 문제에 대해 후속 조치를 취합니다.
여덟, 라이센스
프로젝트 구현 시 누가 권한을 집행합니까?
기초가 아니라 기능 팀입니다.
Basis 는 시스템에서 역할과 전송을 만들어야 합니다.
그러나 어떤 역할이 필요한지, 그리고 그들이 어떤 권한을 가지고 있는지 결정하는 것은 직능 팀의 일이다. 기능 팀은 비즈니스를 이해하고 역할을 설정하는 방법을 알고 있기 때문입니다.
권위의 시행도 쉽지 않다.
첫째, 글로벌 템플릿으로 이미 공통된 역할 집합이 있습니다. 배포 시 이러한 공통 역할을 로컬 역할로 복사하고 일부 변경 작업을 변형 역할로 수행해야 합니다.
1 청사진 디자인 시 법인을 역할에 매핑해야 합니다.
이 배포에 사용되는 회사 코드, 공장 공장 및 사용할 일반 역할은 몇 개입니까? 그것들을 나열해 주세요.
2. SAP Tcode 와 역할 간 매핑을 확인합니다
마찬가지로 청사진 설계가 완료되면 사용할 T 코드를 알아야 합니다. 모든 T 코드가 Commone 캐릭터에 포함되어 있는지, 그리고 새로운 T 코드를 추가할 수 있는 지역 개발이 있는지 확인해야 합니다.
모든 변경 사항은 다른 역할을 만들어야 합니다.
3 사용자 ID 에 대한 역할 매핑 확인
이것은
이것은 Excel 파일입니다. 먼저 이름, ID, 부서, 이메일 등 모든 사용자 정보를 표로 나열해야 합니다. 및 역할
설명, 이 파일은 사용자에게 보여지며, 물론 각 역할이 무엇을 하는지 사용자에게 알려주는 것이지, 기술 묘사가 아니다. 잔디도 있습니다.
통제, 사반스 오크슬리 법에 따라 제정된 감사 원칙에 따라 사용자가 어떤 역할이 어떤 역할과 충돌하는지 알기를 바란다. 다음은 점, 사용자 ID 입니다.
캐릭터에 매핑하면 이것은 말할 필요도 없다.
이 파일은 주요 사용자에게 넘겨 완성해야 하며, 결국 BPO 가 승인해야 한다.
팀마다 팀 간 권한 요구 사항 (예: MM 사용자가 재무를 원하는 권한) 을 사용할 수 있습니다.
이를 위해서는 조정을 위해 권한 있는 지도자가 필요하다.
다음 단계는 Basis Team 에게 캐릭터를 만들어 기술적인 측면을 한쪽으로 치우는 것이다.
5 권위 테스트
두 가지 테스트가 있습니다. 하나는 별도의 역할 테스트이고 다른 하나는 사용자 ID 기반 테스트입니다.
각 역할에 대해 하나의 역할만 있는 ID 를 만듭니다. 로그인 후 역할의 권한을 테스트합니다.
각 사용자에 대한 ID 를 만들고 테스트 시스템에서 함수 작업에 따라 사용자의 권한을 테스트합니다.
6 마지막으로, 온라인권입니다.
역할을 프로덕션 시스템에 전달하고, 프로덕션 시스템에 ID 를 만들고, 유효기간을 설정하는 등
여기서 언급해야 할 것은 권한 변경이 정상적인 업무 프로세스이며 운송 등 T 코드 변경만이 문제라는 점이다.
이 온라인 후에는 특별히 구분해야 한다.