구매요청부터 지급까지 프로세스 데이터 템플릿
구매요청부터 지급까지 프로세스 데이터 템플릿
- 상세 분석을 위해 수집할 속성
- 프로세스 탐색을 위해 추적할 주요 활동
- SAP S/4HANA 데이터 추출 안내
구매요청부터 지급까지 프로세스의 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 구매요청 ID PurchaseRequisitionId | 구매요청 문서를 고유하게 식별하는 ID입니다. | ||
| 설명 구매요청 ID는 SAP S/4HANA에서 각 재화 또는 서비스 요청을 고유하게 식별하는 기본 키입니다. 요청 생성부터 승인, 반려 또는 구매오더 전환과 같은 최종 상태까지 관련된 모든 활동과 변경 사항을 연결하는 케이스 식별자로 사용됩니다. process mining에서는 이 속성을 기준으로 각 구매요청의 전체 수명 주기를 재구성합니다. 관련 이벤트를 하나의 구매요청 ID로 묶으면 분석 담당자가 처리 시간을 정확히 측정하고 상태 변경을 추적하며 승인 과정에서 구매요청이 거치는 경로를 분석할 수 있습니다. 중요한 이유 관련된 모든 프로세스 단계를 연결하는 필수 케이스 식별자로, 구매요청 수명 주기를 빠짐없이 일관되게 파악할 수 있습니다. 확보 방법 EBAN 테이블의 BANFN 필드에 저장되는 구매요청 번호입니다. 예시 100178901001789110017892 | |||
| 이벤트 시각 EventTime | 특정 활동이 발생한 정확한 날짜와 시각입니다. | ||
| 설명 이벤트 시각은 활동이 발생한 시점을 기록하는 타임스탬프입니다. 케이스 내 이벤트를 시간순으로 정렬하는 데 필요하며, process mining에서 모든 기간과 성과를 계산하는 기준이 됩니다. 예를 들어 '구매요청 제출'과 '구매요청 승인' 이벤트 사이의 시간으로 승인 처리 시간을 계산합니다. 프로세스 성과를 분석하고 지연을 찾아 서비스 수준 협약 준수 여부를 모니터링하려면 정확한 타임스탬프가 필요합니다. 이 속성을 사용하면 처리 시간을 시각화하고 지연된 구매요청을 추적하며 기간별 성과를 비교하는 대시보드를 구성할 수 있습니다. 중요한 이유 이 타임스탬프는 이벤트 순서를 정하고 처리 시간을 계산하며 프로세스 성과와 병목을 분석하는 데 필요합니다. 확보 방법 일반적으로 변경 문서 헤더(CDHDR-UDATE, CDHDR-UTIME) 또는 워크플로 이벤트 로그에서 타임스탬프를 가져옵니다. 예시 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| 활동명 ActivityName | 구매요청 프로세스의 특정 시점에 발생한 업무 활동의 이름입니다. | ||
| 설명 활동명은 구매요청 수명 주기에서 발생한 특정 이벤트나 작업을 나타냅니다. 변경 문서와 워크플로 이력 등의 시스템 로그에서 활동을 도출하며, '구매요청 생성', '승인 단계 시작', '구매오더 생성'과 같은 주요 프로세스 기준점을 보여줍니다. 활동을 분석하면 프로세스 흐름을 시각화하고 병목을 찾아 각 단계에 걸린 시간을 측정할 수 있습니다. '구매요청 수정'이나 '구매요청 반려'와 같은 활동의 순서와 빈도를 파악하면 프로세스 비효율과 개선 영역을 찾는 데 도움이 됩니다. 중요한 이유 프로세스의 단계를 정의해 프로세스 맵의 뼈대를 구성하고, 프로세스 흐름과 변형, 병목을 분석할 수 있게 합니다. 확보 방법 일반적으로 변경 문서 테이블(CDHDR, CDPOS)과 워크플로 로그(예: SWWLOGHIST)의 데이터를 해석해 생성하는 파생 속성입니다. 예시 구매요청 생성승인 단계 완료구매요청 승인구매오더 생성 | |||
| 구매요청 금액 RequisitionAmount | 구매요청의 총 금액입니다. | ||
| 설명 구매요청 금액은 요청한 재화 또는 서비스의 총 예상 비용입니다. 이 금액은 승인 워크플로의 복잡성과 소요 시간에 영향을 주는 경우가 많으며, 금액이 큰 구매요청은 일반적으로 더 많은 승인 단계를 거칩니다. 이 속성을 기준으로 금액별 프로세스를 분석할 수 있습니다. 예를 들어 고액 구매요청의 승인에 더 오래 걸리는지, 자주 반려되는 구매요청의 금액은 얼마인지 확인할 수 있습니다. 프로세스 비효율이 재무에 미치는 영향을 파악하는 데 필요한 분석 기준입니다. 중요한 이유 재무적 영향에 따라 프로세스를 구분할 수 있으며, 승인 복잡성과 처리 시간의 연관성을 파악하는 데 도움이 됩니다. 금액 기준 프로세스 분석에 필요한 속성입니다. 확보 방법 총액은 EBAN 테이블의 GFWERT 필드에서 확인할 수 있습니다. 품목별 금액은 EBAN-PREIS에 저장됩니다. 예시 1500.0075000.50250.75 | |||
| 구매요청 상태 RequisitionStatus | 구매요청의 현재 처리 또는 승인 상태입니다. | ||
| 설명 구매요청 상태는 수명 주기에서 구매요청이 현재 어떤 단계에 있는지 나타냅니다. SAP에서는 릴리스 표시자로 표시되는 경우가 많으며, 구매요청이 차단되었는지, 승인 진행 중인지, 일부 승인되었는지, 전체 승인되었는지 보여줍니다. 구매요청이 워크플로를 진행하면서 상태가 바뀝니다. 시간에 따른 상태를 추적하면 프로세스 흐름을 파악할 수 있습니다. 구매요청이 어느 단계에서 얼마나 오래 지연되는지 확인하고, 상태 간 전환을 분석해 승인 프로세스와 다양한 처리 경로를 자세히 살펴볼 수 있습니다. 중요한 이유 구매요청의 현재 상태를 나타냅니다. 진행 상황을 추적하고 병목을 찾아 프로세스 흐름을 분석하는 데 필요합니다. 확보 방법 릴리스 상태는 일반적으로 EBAN 테이블의 FRGZU 필드에 있는 릴리스 표시자를 기준으로 확인합니다. 예시 B1S | |||
| 구매요청 유형 RequisitionType | 구매요청을 분류하는 코드입니다. 예를 들어 일반 품목, 서비스 또는 자본 지출을 구분합니다. | ||
| 설명 SAP에서 문서 유형이라고도 하는 구매요청 유형은 구매요청을 분류하는 주요 설정 필드입니다. 유형에 따라 승인 워크플로와 필드 설정이 달라질 수 있으며, 일반 재고 품목, 외부 서비스, 자산 구매 등 서로 다른 업무 목적에 사용됩니다. 구매요청 유형별로 프로세스를 분석하면 요청 유형에 따라 처리 방식이 어떻게 다른지 파악할 수 있습니다. 범주별 성과와 처리 시간, 승인 경로를 비교해 특정 유형의 효율이 낮은지 확인하고, 그에 맞는 프로세스 개선 방안을 마련할 수 있습니다. 중요한 이유 구매요청을 유형별로 분류해 비교 분석할 수 있습니다. 요청 유형에 따라 프로세스 흐름과 병목, 처리 시간이 달라지는지 파악하는 데 도움이 됩니다. 확보 방법 EBAN 테이블의 BSART 필드에 저장되는 문서 유형입니다. 예시 NBFORV | |||
| 부서 Department | 구매요청 비용이 청구되는 부서 또는 코스트 센터입니다. | ||
| 설명 부서 속성은 SAP의 코스트 센터로 표시되는 경우가 많으며, 요청한 구매를 담당하는 사업 부문을 나타냅니다. 구매요청의 품목 수준에 지정되는 재무 및 조직 정보입니다. process mining에서 이 속성은 부서별 성과 분석에 필요합니다. 부서별 처리 시간, 수정률, 반려율 등의 지표를 비교하는 대시보드를 구성할 수 있습니다. 이를 통해 다른 부서에서 참고할 만한 우수 사례를 찾고, 추가 교육이나 프로세스 지원이 필요한 부서를 파악할 수 있습니다. 중요한 이유 사업 부문별 성과를 비교해 처리 시간이나 반려율의 차이를 확인하고, 우수 사례와 개선 영역을 찾을 수 있습니다. 확보 방법 일반적으로 계정 지정 테이블 EBKN의 KOSTL 필드에 저장되는 코스트 센터입니다. 예시 FIN-1001IT-2005MKT-3010 | |||
| 사용자 ID UserId | 구매요청을 생성했거나 특정 활동을 수행한 사용자의 식별자입니다. | ||
| 설명 사용자 ID는 구매요청 수명 주기에서 특정 이벤트를 담당한 직원 또는 시스템 사용자를 식별합니다. 구매요청을 생성한 사람, 승인한 관리자, 수정한 담당자 등이 해당합니다. 자동화된 단계에서는 시스템 또는 배치 사용자 ID가 기록될 수 있습니다. 사용자 ID별로 분석하면 사용자별 작업 방식과 업무량 분포, 성과를 파악할 수 있습니다. 교육이 필요한 영역을 찾고 성과가 높은 직원을 확인하며 프로세스의 책임 소재를 명확히 하는 데 도움이 됩니다. 사용자 마스터 데이터를 결합하면 부서별 성과 분석에도 활용할 수 있습니다. 중요한 이유 사용자별 성과와 업무량 분포, 프로세스 준수 여부를 분석할 수 있습니다. 교육이 필요한 영역과 리소스 병목을 찾는 데도 도움이 됩니다. 확보 방법 생성자는 EBAN-ERNAM에서 확인할 수 있습니다. 이후 변경은 CDHDR-USERNAME에, 승인은 워크플로 로그에 기록됩니다. 예시 JSMITHRROEWF-BATCH | |||
| 승인자 ID ApproverId | 승인 또는 반려 단계를 수행한 사용자의 식별자입니다. | ||
| 설명 승인자 ID는 승인 또는 반려 활동을 완료한 사용자를 식별합니다. 일반 사용자 ID와 달리 승인 워크플로에서 의사결정을 내린 사용자에 초점을 둡니다. 승인 프로세스를 자세히 분석하려면 이 정보를 기록해야 합니다. 이 속성을 활용하면 승인 처리 시간이 긴 관리자나 구매요청을 자주 반려하는 승인자를 파악하는 등 승인 행태를 분석할 수 있습니다. 승인 단계별 처리 시간과 워크플로 병목을 보여주는 대시보드에 필요한 정보로, 지연을 유발하는 개인이나 역할을 찾는 데 도움이 됩니다. 중요한 이유 승인 단계의 의사결정자를 식별해 개인 또는 역할별 승인 처리 시간과 병목을 자세히 분석할 수 있습니다. 확보 방법 일반적으로 SAP Business Workflow 테이블인 SWW_WI2OBJ와 SWWLOGHIST에서 정보를 추출합니다. 이 테이블은 작업 항목과 작업을 완료한 사용자를 연결합니다. 예시 MJOHNSONCWILLIAMSLBLACK | |||
| 구매오더 번호 PurchaseOrderNumber | 구매요청에서 생성된 구매오더의 번호입니다. | ||
| 설명 구매오더 번호는 승인된 구매요청에서 생성된 공식 구매 문서의 식별자입니다. 구매오더가 생성되면 요청이 공급업체에 전달할 정식 발주로 전환되므로, 구매요청 프로세스가 성공적으로 완료되었음을 나타내는 경우가 많습니다. 이 속성은 구매요청에서 구매오더까지의 리드타임 KPI와 전체 전환율을 측정하는 데 필요합니다. 구매요청 프로세스와 후속 구매 프로세스를 연결해 구매부터 지급까지의 전체 과정을 파악할 수 있습니다. 중요한 이유 구매요청과 후속 구매 문서를 연결해 구매요청의 구매오더 전환율과 리드타임을 측정할 수 있습니다. 확보 방법 구매요청 항목에서 구매오더가 생성되면 EBAN 테이블의 EBELN 필드에서 확인할 수 있습니다. 예시 450001789045000178914500017892 | |||
| 긴급도 UrgencyLevel | 구매요청의 긴급도를 분류하는 값으로, 처리 우선순위에 영향을 줄 수 있습니다. | ||
| 설명 긴급도는 구매요청의 우선순위를 나타냅니다. 표준 전용 필드는 없지만, 일부 조직에서는 Requirement Tracking Number와 같은 필드에 이 정보를 기록합니다. 요청자는 이를 통해 신속한 처리가 필요한 긴급 요청을 표시할 수 있습니다. 긴급도가 프로세스에 미치는 영향을 분석하면 중요 요청의 우선순위가 적절히 반영되는지 평가할 수 있습니다. 긴급도 영향 분석 대시보드는 이 속성을 사용해 긴급 구매요청과 일반 구매요청의 처리 시간 및 승인율을 비교하고, 우선 처리 방식이 의도대로 작동하는지 확인합니다. 중요한 이유 우선순위가 높은 요청의 프로세스 성과를 분석해 긴급 항목이 실제로 신속하게 처리되는지 확인할 수 있습니다. 확보 방법 표준 긴급도 필드는 없습니다. 일부 기업은 Requirement Tracking Number(EBAN-BEDAR)를 이 용도로 사용합니다. 사용자 정의 필드일 수도 있습니다. 예시 높음보통낮음 | |||
| 반려 사유 RejectionReason | 구매요청이 반려된 사유입니다. | ||
| 설명 반려 사유는 승인자가 구매요청을 반려한 이유를 설명합니다. 예산 초과, 정보 오류, 정책 미준수, 다른 요청과의 중복 등이 사유가 될 수 있습니다. 이 정보는 프로세스 실패의 배경을 파악하는 데 필요합니다. 반려 사유를 분석하면 비효율과 재작업의 근본 원인을 찾을 수 있습니다. 예를 들어 '코스트 센터 오류'가 자주 발생한다면 사용자 교육을 강화하거나 시스템 검증을 개선해야 할 수 있습니다. 이 속성은 구매요청 반려 분석 대시보드의 기준이며, 개선 대상을 구체적으로 정하는 데 도움이 됩니다. 중요한 이유 프로세스 실패의 근본 원인을 파악해 재작업을 줄이고 구매요청의 최초 정확 처리율을 높이는 개선 방안을 마련할 수 있습니다. 확보 방법 일반 필드가 아닌 경우가 많습니다. 워크플로 컨테이너 요소, 구매요청에 연결된 장문 텍스트 또는 사용자 정의 필드에 기록될 수 있습니다. 예시 예산 초과공급업체 오류중복 요청 | |||
| 소스 시스템 SourceSystem | 데이터를 추출한 SAP S/4HANA 인스턴스를 식별합니다. | ||
| 설명 소스 시스템 속성은 프로세스 데이터가 생성된 시스템을 나타냅니다. 개발, 품질 보증, 운영용 시스템이나 지역별 시스템 등 여러 SAP 인스턴스를 사용하는 조직에서는 데이터 거버넌스와 분석 맥락을 파악하는 데 이 필드가 필요합니다. 이 속성을 사용하면 서로 다른 소스의 데이터를 구분해 잘못된 집계를 방지하고 시스템별 분석을 수행할 수 있습니다. 데이터 계보를 관리하고 프로세스 데이터의 추적 가능성을 보장하기 위해 반드시 필요한 속성입니다. 중요한 이유 데이터 출처와 거버넌스에 필요한 맥락을 제공하며, 특히 여러 시스템을 사용하는 환경에서 데이터 추적성을 보장합니다. 확보 방법 일반적으로 SAP 시스템 ID(SID)를 사용하며, 시스템 변수나 설정 테이블에서 가져올 수 있습니다. 예시 S4PECCS4H_PROD_01 | |||
| 승인 단계 이름 ApprovalStepName | 워크플로에서 특정 승인 단계의 이름 또는 설명입니다. | ||
| 설명 승인 단계 이름은 승인 워크플로의 특정 단계를 사람이 이해하기 쉬운 설명으로 나타냅니다. 예를 들면 '관리자 승인' 또는 '재무 담당 부사장 승인'이 있습니다. 일반적인 '승인 단계 완료' 활동보다 구체적인 정보를 제공합니다. 이 속성은 승인 단계 처리 시간 및 워크플로 병목 분석 대시보드에 중요합니다. 승인 프로세스를 세부적으로 살펴보고 지연이 가장 큰 단계와 업무가 쌓이는 지점을 정확히 파악할 수 있습니다. 승인 절차를 개선하려면 이 수준의 세부 정보가 필요합니다. 중요한 이유 승인 단계를 세부적으로 보여 주어 여러 단계로 구성된 승인 워크플로에서 병목을 정확히 찾을 수 있습니다. 확보 방법 이 정보는 워크플로 작업 설명에서 가져옵니다. 워크플로 로그를 T528T와 같은 작업 정의 테이블에 연결해 확인할 수 있습니다. 예시 관리자 승인이사 승인재무 담당 부사장 승인 | |||
| 요청 납기일 RequiredByDate | 요청자가 재화 또는 서비스를 필요로 하는 날짜입니다. | ||
| 설명 SAP에서 납품일이라고도 하는 요청 납기일은 구매요청 품목의 재화 또는 서비스가 필요한 날짜입니다. 요청자가 지정하며 전체 구매 프로세스의 목표일로 사용됩니다. 이 속성은 '구매요청 정시 완료율' KPI를 계산하는 데 필요합니다. 요청 납기일과 최종 승인일 또는 구매오더 생성일을 비교하면 조직이 내부 서비스 수준과 업무상 요구를 충족하는지 측정할 수 있습니다. 이 날짜를 넘긴 구매요청을 분석하면 구매 프로세스의 반복적인 지연을 파악할 수 있습니다. 중요한 이유 요청의 목표 완료일을 지정해 정시 처리 여부와 내부 서비스 수준 준수 여부를 측정할 수 있습니다. 확보 방법 EBAN 테이블의 품목 수준 LFDAT 필드에 저장되는 납품일입니다. 예시 2023-11-152023-12-012024-01-20 | |||
| 자동화 여부 IsAutomated | 활동을 사람이 아닌 시스템 사용자가 수행했는지 나타내는 표시자입니다. | ||
| 설명 Is Automated 속성은 활동을 시스템 사용자나 배치 사용자가 실행했으면 true로 설정되는 불리언 플래그입니다. 예를 들어 워크플로 작업은 'WF-BATCH'가 실행할 수 있습니다. 이 속성을 사용하면 프로세스의 수동 단계와 자동화된 단계를 구분할 수 있습니다. 이 속성은 구매요청 프로세스의 자동화 수준을 측정하고 '자동 승인율' KPI를 계산하는 데 필요합니다. 자동화된 단계와 수동 단계를 각각 필터링해 효율성을 비교하고, 처리 시간과 수작업을 줄일 수 있는 추가 자동화 기회를 찾을 수 있습니다. 중요한 이유 사람이 수행한 활동과 시스템이 처리한 활동을 구분합니다. 자동화율을 측정하고 수동 작업의 자동화 기회를 찾는 데 중요합니다. 확보 방법 파생 속성으로, 일반적으로 이벤트의 User ID가 알려진 시스템 사용자 또는 배치 사용자 목록에 포함되는지 확인하는 규칙을 바탕으로 설정합니다. 예시 truefalse | |||
| 재작업 여부 IsRework | 제출 후 수정과 같이 활동이 재작업에 해당하는지 나타내는 플래그입니다. | ||
| 설명 Is Rework는 부가가치를 만들지 않거나 반복되는 작업을 식별하는 계산된 불리언 플래그입니다. 이 프로세스에서는 승인 요청을 제출한 뒤 '구매요청 수정' 활동이 발생해 승인 절차를 다시 시작하는 경우가 대표적입니다. 이 속성을 사용하면 재작업 규모와 전체 처리 시간에 미치는 영향을 측정할 수 있습니다. 구매요청 수정 및 재작업률 대시보드는 이 플래그를 바탕으로 프로세스의 비효율을 보여 줍니다. 재작업을 줄이면 시간과 노력을 직접 절감할 수 있으므로 프로세스 개선의 주요 목표가 되는 경우가 많습니다. 중요한 이유 낭비되거나 반복되는 작업을 표시해 재작업 규모와 프로세스 효율성에 미치는 영향을 직접 측정할 수 있습니다. 확보 방법 계산된 속성입니다. 일반적으로 첫 번째 '승인 요청을 위해 구매요청 제출' 활동 이후에 발생한 '구매요청 수정' 활동을 재작업으로 표시합니다. 예시 truefalse | |||
| 종료 시간 EndTime | 특정 활동이 완료된 정확한 날짜와 시간입니다. | ||
| 설명 EndTime은 활동이 끝난 시점을 기록하는 타임스탬프입니다. 시스템에서 생성되는 이벤트는 대부분 즉시 처리되므로 StartTime과 EndTime이 같지만, 승인과 같은 사람의 작업은 시작 시점과 종료 시점이 다를 수 있습니다. EndTime은 해당 작업이 완료된 시점을 나타냅니다. EndTime을 별도로 기록하면 실제 처리 시간과 대기 시간을 더 정확하게 구분할 수 있습니다. StartTime과 함께 사용해 ProcessingTime 지표를 계산합니다. 이 세부 정보는 수동 작업의 리소스 사용과 효율성을 분석하는 데 도움이 됩니다. 중요한 이유 활동이 완료된 시점을 표시해 실제 처리 시간을 계산하고 작업 소요 시간을 더 자세히 분석할 수 있습니다. 확보 방법 작업 항목의 생성 시점(StartTime)과 완료 시점(EndTime)을 모두 기록할 수 있는 워크플로 로그에서 가져옵니다. 예시 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| 최근 데이터 업데이트 LastDataUpdate | 소스 시스템에서 이 레코드의 데이터를 마지막으로 새로 고친 시각입니다. | ||
| 설명 이 속성은 소스 시스템에서 데이터를 가장 최근에 추출하거나 업데이트한 날짜와 시각을 기록합니다. 분석에 사용하는 데이터의 최신성을 파악하는 데 필요한 메타데이터입니다. 분석 담당자와 업무 사용자는 이 타임스탬프를 통해 프로세스 데이터가 현재 운영 상태를 얼마나 반영하는지 확인할 수 있습니다. 정확한 분석과 의사결정을 위해서는 데이터가 최신 상태인지 알아야 합니다. 이 속성을 통해 사용자의 기대 수준을 관리하고, 분석 목적에 필요한 최신 데이터에 근거해 결론을 내릴 수 있습니다. 중요한 이유 데이터의 최신성을 나타내므로 분석 결과의 신뢰도를 판단하고 시의적절한 업무 결정을 내리는 데 필요합니다. 확보 방법 데이터 추출, 변환, 적재(ETL) 과정에서 생성해 추가하는 타임스탬프입니다. 예시 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 통화 Currency | 구매요청 금액의 통화 코드입니다. | ||
| 설명 이 속성은 구매요청 금액의 통화를 지정합니다. 예를 들어 USD, EUR, JPY 등이 있습니다. 여러 통화를 사용하는 다국적 조직에서 구매요청 금액을 해석하는 데 필요한 정보입니다. 정확한 재무 분석과 보고를 위해 통화를 고려해야 합니다. 구매요청 금액을 합산하거나 비교할 때는 의미 있는 결과를 얻을 수 있도록 모든 금액을 공통 통화로 환산해야 합니다. 이 속성은 환산에 필요한 기준입니다. 중요한 이유 구매요청 금액의 통화 정보를 제공해 여러 통화를 사용하는 환경에서도 정확한 재무 분석과 비교를 할 수 있습니다. 확보 방법 EBAN 테이블의 WAERS 필드에서 확인할 수 있습니다. 예시 USDEURGBP | |||
구매요청부터 지급까지 프로세스의 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 구매오더 생성 | 구매요청 항목을 참조하는 구매오더가 생성되었음을 나타냅니다. 구매요청과 후속 구매 문서를 연결하는 시스템 이벤트로 명시적으로 기록됩니다. | ||
| 중요한 이유 구매요청 프로세스의 주요 기준점이자 성공적인 결과입니다. 구매요청 승인부터 구매오더 생성까지의 시간은 구매 효율을 측정하는 중요한 KPI입니다. 확보 방법 구매오더 항목이 생성될 때 명시적으로 기록됩니다. 구매오더 항목 테이블인 EKPO에 구매요청 번호(BANFN)와 항목 번호(BNFPO)가 저장되어 두 문서를 연결합니다. 기록 구매요청 번호와 항목 번호를 기준으로 EKPO 테이블을 EBAN 테이블에 조인합니다. 구매오더 항목의 생성일이 이벤트 시점입니다. 이벤트 유형 explicit | |||
| 구매요청 반려 | 승인자가 구매요청을 최종 반려해 프로세스가 중단되는 것을 나타냅니다. 반려를 표시하는 특정 상태 변경으로 기록됩니다. | ||
| 중요한 이유 프로세스가 실패로 끝나는 중요한 지점입니다. 반려 빈도와 사유, 반려가 발생한 단계를 분석하면 정책 준수, 예산 또는 요청 품질과 관련된 문제를 파악할 수 있습니다. 확보 방법 EBAN 테이블의 상태 변경을 바탕으로 추정합니다. 처리 상태(PROCSTAT) 또는 릴리스 표시자가 '반려'를 명시하는 값으로 설정됩니다. 기록 변경 문서를 통해 EBAN의 전체 상태가 '반려'로 바뀐 시각을 확인합니다. 이벤트 유형 inferred | |||
| 구매요청 생성 | 시스템에서 구매요청 문서가 처음 생성된 시점을 나타냅니다. 사용자가 새 구매요청을 처음 저장할 때 이 이벤트가 명시적으로 기록되며, 생성 시각도 함께 저장됩니다. | ||
| 중요한 이유 이 활동은 구매요청 수명 주기 분석의 시작점입니다. 최초 필요 확인부터 최종 승인 또는 구매오더 전환까지의 전체 처리 시간을 측정하는 데 필요합니다. 확보 방법 EBAN 테이블에서 해당 구매요청 번호(BANFN)의 생성일(ERDAT)과 생성 시간(ERZEIT) 필드를 사용해 명시적으로 기록되는 이벤트입니다. 기록 각 구매요청(BANFN)의 EBAN 테이블에서 생성 시각 필드(ERDAT, ERZEIT)를 사용합니다. 이벤트 유형 explicit | |||
| 구매요청 승인 | 구매요청의 최종 승인이 완료되어 구매오더로 전환할 수 있는 상태를 나타냅니다. 전체 릴리스 상태가 최종 승인 상태에 도달하면 이 시점을 기준으로 추정합니다. | ||
| 중요한 이유 성공 여부를 판단하는 중요한 기준점이자 처리 시간 분석의 일반적인 종료점입니다. 구매요청이 모든 검토를 통과해 구매 부서에서 후속 처리를 할 수 있음을 의미합니다. 확보 방법 EBAN 테이블의 상태 변경을 바탕으로 추정합니다. 전체 릴리스 표시자(FRGZU) 또는 처리 상태(PROCSTAT)가 최종 '승인' 값으로 바뀌는 시점을 확인합니다. 기록 최종 릴리스 코드가 적용되거나 구매요청의 전체 상태가 '승인'으로 바뀐 시각을 확인합니다. 이벤트 유형 inferred | |||
| 구매요청 종료 | 구매요청 항목의 처리가 완료되어 해당 항목에서 더 이상 구매오더를 생성할 수 없는 상태를 나타냅니다. 일반적으로 전체 수량이 발주되면 이 상태가 자동으로 설정됩니다. | ||
| 중요한 이유 구매요청 항목의 수명 주기가 성공적으로 완료되는 마지막 단계입니다. 업무상 필요가 구매오더로 모두 전환되었음을 확인합니다. 확보 방법 EBAN 테이블을 바탕으로 추정합니다. '종료' 표시자(EBAKZ)가 설정될 때 발생하며, 일반적으로 구매오더 수량이 구매요청 수량과 같아지면 설정됩니다. 기록 변경 문서를 통해 EBAN 테이블에서 '종료' 표시자(EBAKZ)가 설정된 이벤트를 찾습니다. 이벤트 유형 inferred | |||
| 승인 단계 완료 | 승인자가 구매요청을 승인해 다단계 승인 워크플로의 한 단계를 완료할 때 발생합니다. 구매요청의 릴리스 상태 변경을 바탕으로 추정합니다. | ||
| 중요한 이유 이 활동을 통해 승인 워크플로를 세부적으로 분석하고 각 단계에 걸린 시간을 측정할 수 있습니다. 처리 효율이 높은 승인자와 병목이 발생하는 지점을 파악하는 데 도움이 됩니다. 확보 방법 EBAN 테이블의 변경 문서(CDHDR/CDPOS)를 바탕으로 추정합니다. 특정 릴리스 코드의 상태(예: FRGZU 필드)가 미승인에서 승인으로 바뀌면 이 이벤트로 판단합니다. 기록 전략에 정의된 각 릴리스 코드에 대해 EBAN의 릴리스 상태 필드 변경을 추적합니다. 이벤트 유형 inferred | |||
| 공급처 지정 | 구매 담당자가 승인된 구매요청 항목에 특정 공급업체, 계약 또는 구매 정보 레코드를 지정하는 작업입니다. 구매요청을 구매오더로 전환하기 위한 주요 단계입니다. | ||
| 중요한 이유 이 활동은 승인과 발주를 연결합니다. 공급처 지정까지 걸린 시간을 측정하면 구매 담당자의 업무량과 공급처 선정 효율에 따른 지연을 파악할 수 있습니다. 확보 방법 EBAN 테이블의 공급처 관련 필드에 값이 입력된 시점을 바탕으로 추정합니다. 해당 필드에는 고정 공급업체(LIFNR), 구매 정보 레코드(INFNR), 계약(KONNR) 등이 있습니다. 기록 변경 문서를 통해 EBAN 테이블의 LIFNR, INFNR, KONNR 등의 필드에 값이 입력되는 시점을 추적합니다. 이벤트 유형 inferred | |||
| 구매요청 수정 | 사용자가 구매요청을 처음 생성한 뒤 수량, 가격, 자재 등 주요 필드를 변경할 때 발생합니다. 이 작업은 SAP 변경 문서 시스템에 명시적으로 기록됩니다. | ||
| 중요한 이유 수정 내역을 추적하면 재작업이 반복되는 구간과 처리 시간에 미치는 영향을 파악할 수 있습니다. 수정이 잦다면 데이터 품질이나 요구사항 변경에 문제가 있을 수 있으며, 이는 프로세스 개선이 필요한 영역입니다. 확보 방법 EBAN 테이블의 변경 사항은 SAP 변경 문서 테이블(CDHDR 및 CDPOS)에 명시적으로 기록됩니다. 추적 대상 필드가 변경될 때마다 항목이 생성됩니다. 기록 구매요청의 오브젝트 클래스가 BANF인 CDHDR/CDPOS 변경 이벤트를 추출합니다. 이벤트 유형 explicit | |||
| 구매요청 승인 제출 | 요청자가 구매요청을 공식적으로 제출해 승인 워크플로를 시작하는 시점입니다. 일반적으로 구매요청의 릴리스 전략이 결정되고 상태가 '승인 진행 중'으로 바뀌는 시점을 기준으로 추정합니다. | ||
| 중요한 이유 승인 처리 시간 KPI를 측정하기 시작하는 중요한 기준점입니다. 생성부터 제출까지 걸린 시간을 분석하면 구매요청 준비 단계의 지연을 파악할 수 있습니다. 확보 방법 EBAN 테이블의 변경 문서(CDHDR/CDPOS)를 바탕으로 추정합니다. 릴리스 전략 필드(예: FRGST)가 입력되거나 전체 상태(PROCSTAT)가 승인 진행 상태로 바뀌는 시점을 확인합니다. 기록 승인 워크플로가 시작되었거나 상태가 '승인 진행 중'으로 바뀌었음을 나타내는 최초 변경 문서 항목을 찾습니다. 이벤트 유형 inferred | |||
| 구매요청 철회 | 요청자가 구매요청의 처리가 완료되기 전에 취소하거나 삭제할 때 발생합니다. 일반적으로 구매요청 항목에 삭제 표시자를 설정하는 명시적 작업입니다. | ||
| 중요한 이유 철회 내역을 추적하면 수요 변동과 취소 사유를 파악할 수 있습니다. 철회는 구매요청의 종료 상태로, 이후 처리가 진행되지 않습니다. 확보 방법 EBAN 테이블에서 구매요청 항목의 삭제 표시자(LOEKZ)가 설정되면 명시적으로 기록됩니다. 변경 사항은 CDHDR/CDPOS에 저장됩니다. 기록 EBAN 테이블에서 삭제 표시자(LOEKZ)가 'L'로 설정된 이벤트를 찾습니다. 이벤트 유형 explicit | |||
| 승인 단계 시작 | 특정 승인자 또는 승인 그룹의 처리를 기다리는 구매요청을 나타냅니다. 구매요청 상태에 특정 릴리스 코드의 처리가 대기 중이라고 표시될 때를 기준으로 추정합니다. | ||
| 중요한 이유 승인 단계에서 병목이 발생하는 지점을 파악하는 데 필요한 활동입니다. 이 상태가 지속된 시간을 분석하면 처리가 지연된 구매요청과 업무가 과중한 승인자를 찾을 수 있습니다. 확보 방법 EBAN 테이블의 릴리스 상태 필드(예: FRGZU)와 릴리스 전략 설정을 바탕으로 추정합니다. 특정 릴리스 코드가 다음 처리 대상으로 지정되면 이벤트가 시작됩니다. 기록 워크플로 로그 또는 상태 필드를 바탕으로 특정 릴리스 코드의 승인을 기다리는 상태에 구매요청이 진입한 시점을 확인합니다. 이벤트 유형 inferred | |||
| 승인 초기화 | 구매요청이 크게 수정되는 등의 이유로 승인 워크플로 전체가 초기화되는 이벤트입니다. 초기화되면 첫 번째 단계부터 승인을 다시 진행해야 합니다. | ||
| 중요한 이유 이 활동은 처리 시간에 큰 영향을 주는 재작업을 보여줍니다. 승인 초기화의 원인을 파악하면 프로세스를 간소화하고 지연을 줄이는 데 도움이 됩니다. 확보 방법 EBAN 테이블의 변경 문서(CDHDR/CDPOS)를 바탕으로 추정합니다. 일부 또는 전체 릴리스 상태가 설정된 뒤 릴리스 상태 필드(FRGKZ 또는 FRGZU 등)가 지워지면 이 이벤트로 판단합니다. 기록 변경 로그에서 릴리스 상태가 승인된 상태에서 미승인 상태로 되돌아간 기록을 찾습니다. 이벤트 유형 inferred | |||
데이터 추출 가이드
단계
- 사전 준비: 필요한 CDS 뷰에 접근할 수 있는 SAP S/4HANA 사용자 권한을 확인합니다. 일반적으로 S_TABU_NAM과 같은 권한 객체 및 데이터 조회 도구에 대한 접근 권한이 필요합니다.
- 시스템 접속 방법 확인: SQL 쿼리를 실행할 SAP S/4HANA 데이터베이스 접속 방법을 정합니다. SAP HANA Studio, ADT(ABAP Development Tools)가 포함된 Eclipse IDE, SAP HANA 데이터베이스 클라이언트를 통해 연결하는 DBeaver 같은 타사 SQL 클라이언트를 사용할 수 있습니다.
- SQL 쿼리 검토: 제공된 SQL 스크립트를 확인합니다. 이 스크립트는 공통 테이블 식(CTE)으로 활동별 데이터를 가져온 뒤, 이를 통합해 하나의 이벤트 로그를 만듭니다.
- 자리표시자 수정: 쿼리에서 자리표시자를 찾아 실제 값으로 바꿉니다. 추출 기간의 날짜 범위는
[YYYY-MM-DD]형식으로 설정하고, 조직에 해당하는 회사 코드([Your Company Code])를 지정합니다. - 쿼리 실행: 수정한 SQL 쿼리 전체를 SAP S/4HANA 데이터베이스에서 실행합니다. 데이터 양과 날짜 범위에 따라 실행에 시간이 걸릴 수 있습니다.
- 초기 데이터 검토: 쿼리 실행이 끝나면 결과의 처음 몇 행을 검토합니다. PurchaseRequisitionId, ActivityName, EventTime 등의 열이 예상대로 채워졌는지, 데이터 형식이 올바른지 확인합니다.
- 데이터 변환 확인: 제공된 쿼리는 process mining에 바로 사용할 수 있는 형식으로 데이터를 출력하도록 작성되었습니다. 데이터 유형을 일관되게 유지하기 위해
CAST와CONCAT함수를 사용하므로, 실행 후 별도의 주요 변환 작업은 필요하지 않습니다. - 이벤트 로그 내보내기: SQL 클라이언트에서 전체 결과를 CSV 파일로 내보냅니다. 문자 깨짐을 방지하려면 파일 인코딩을 UTF-8로 설정합니다.
- 업로드 준비: process mining 도구에 업로드하기 전에 CSV 파일의 헤더(
PurchaseRequisitionId,ActivityName,EventTime등)가 올바른지 확인합니다. EventTime의 날짜 및 시간 형식이 일관되고 대상 플랫폼에서 지원되는지도 확인합니다. - ProcessMind에 업로드: 최종 CSV 파일을 ProcessMind 프로젝트에 업로드합니다.
PurchaseRequisitionId를 케이스 ID로,ActivityName을 활동으로,EventTime을 타임스탬프로 매핑합니다.
구성
- 주요 CDS View: 추출에는 구매요청 기본 데이터용
I_PurchaseRequisitionAPI01, 변경 사항과 상태 업데이트 추적용I_ChangeDocument및I_ChangeDocumentItem, 구매오더 연결용I_PurchaseOrderItemAPI01이 주로 사용됩니다. - 권한: 쿼리를 실행하는 사용자에게는 위 CDS View에 대한 읽기 권한이 필요합니다. 필요한 역할과 권한은 SAP 보안 담당자에게 문의하세요.
- 날짜 범위 필터링: 데이터 양을 제한하려면 구매요청 생성일(
CreationDate)에 날짜 범위 필터를 적용해야 합니다. 초기 분석에는 3~6개월 분량의 데이터를 권장합니다. - 조직 필터링: 올바른 법인 또는 사업체의 프로세스를 분석하도록
CompanyCode로 데이터를 필터링합니다. 표준 상품과 서비스처럼 특정 조달 프로세스에 집중하려면PurchaseRequisitionType으로 추가 필터링할 수 있습니다. - 변경 문서 설정: '구매요청 수정' 및 여러 승인 단계와 같은 활동을 수집하려면 SAP 시스템에서 관련 필드의 변경 문서 기록이 활성화되어 있어야 합니다. 이벤트가 누락되면 테이블 EBAN의 시스템 설정을 확인하세요.
- 성능: 구매요청이 수백만 건인 대규모 시스템에서 장기간의 데이터를 조회하면 시스템 성능에 영향을 줄 수 있습니다. 사용량이 적은 시간대에 실행하거나 최근 데이터로 갱신한 비운영 환경에서 실행하세요.
샘플 쿼리 sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' 단계
- EBAN과 EBKN이 포함된 SAP HANA 스키마에 직접 읽기 권한이 있는지 확인합니다. 또한 시스템에서 구매요청 수정, 릴리스 처리, 소스 지정, 구매오더 참조 및 종료에 사용하는 변경 문서와 구매 문서 객체를 확인합니다. 객체와 필드는 릴리스 및 설정에 따라 다를 수 있으므로, 쿼리의 대괄호로 표시된 자리표시자를 시스템에 해당하는 객체나 필드로 바꿉니다.
- SAP GUI에서 SE16H 트랜잭션이나 승인된 데이터베이스 관리 도구를 사용해 EBAN과 EBKN을 조회합니다. 구매요청 키 필드를 확인하고 날짜, 시간, 사용자, 상태, 삭제, 릴리스, 계정 지정 및 구매 문서 참조 필드가 있는지 점검합니다. SE11 또는 SAP 데이터 사전에서 필드 정의를 확인합니다. 테스트 중에는 운영 데이터를 노출하지 마세요.
- 구매요청 수정 및 승인 변경에 사용하도록 설정된 변경 문서 소스를 확인합니다. 쿼리는 [Your requisition change document source]라는 정규화된 변경 소스를 전제로 하며, 구매요청 번호, 품목 번호, 변경 필드, 이전 값, 새 값, 변경 날짜, 변경 시간 및 사용자 필드가 필요합니다. 실행 전에 이 소스를 시스템의 관련 SAP 변경 문서 테이블이나 CDS View에 연결합니다.
- 제출, 승인 초기화, 승인 단계 시작, 승인 단계 완료, 최종 승인 및 거부에 사용하는 워크플로 또는 릴리스 소스를 확인합니다. 쿼리는 상태 또는 릴리스 전환당 한 행이 있는 [Your requisition approval event source]를 전제로 합니다. 여기에는 구매요청 번호, 품목 번호, 이벤트 유형, 릴리스 코드 또는 승인 그룹, 승인자, 이벤트 날짜, 이벤트 시간 및 상태 필드가 필요합니다. S/4HANA 설정에서 사용하는 릴리스 또는 워크플로 저장소에 연결합니다.
- 소스 지정, 구매오더 참조 및 종료에 사용할 소스를 확인합니다. 쿼리의 [Your requisition source assignment source], [Your requisition purchase order reference source], [Your requisition closure source] 자리표시자를 시스템에서 승인된 테이블이나 뷰에 연결합니다. 구매오더 품목에서 구매요청 품목으로 이어지는 명시적 참조를 통해 구매오더 생성을 기록해야 합니다. 관련 없는 구매 활동을 근거로 추정하지 마세요.
- [Start date]와 [End date]로 추출 기간을 설정합니다. 초기 실행에는 3~6개월을 권장합니다. 데이터베이스 성능과 이벤트 양을 확인한 뒤에만 기간을 늘리세요. 쿼리는 생성일과 이벤트 날짜를 필터링하며, 구매요청 ID는 사례 식별자로 유지합니다.
- SAP HANA에 연결된 승인된 SQL 클라이언트에서 쿼리를 실행합니다. 연결 정보, 날짜 매개변수, 회사별 필터, 문서화된 소스 및 필드 자리표시자만 바꾸세요. 출력 열 이름은 PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus로 정확히 유지합니다.
- 중복 이벤트, 타임스탬프 정밀도, 시간대 처리, 품목 수준과 문서 수준의 데이터 단위를 검토합니다. 쿼리는 문서 수준의 사례 ID를 출력하고 내부적으로 품목 정보를 포함합니다. 여러 품목에서 활동과 타임스탬프가 같더라도 ProcessMind 설계상 중복 제거가 명시적으로 필요한 경우가 아니라면 행을 각각 유지합니다.
- 필요한 모든 활동이 ActivityName 값으로 나타나는지, EventTime이 입력되어 있고 시간 순서가 타당한지, 필수 사례 ID가 null이 아닌지 확인합니다. 같은 날짜 범위의 SAP 보고서나 승인된 운영 데이터 추출 결과와 건수를 대조합니다.
- 결과를 UTF-8 CSV 또는 ProcessMind에서 지원하는 다른 표 형식으로 내보냅니다. 헤더 행을 포함하고 ISO 호환 타임스탬프를 유지하며, null은 빈 값으로 둡니다. 파일을 업로드할 때 PurchaseRequisitionId는 사례 식별자, ActivityName은 활동 열, EventTime은 타임스탬프 열로 지정합니다.
구성
- 사례 식별자: EBAN의 구매요청 문서 번호를 사용하고 PurchaseRequisitionId로 표시합니다. 프로세스를 품목 수준으로 설정한 경우에는 구매요청 번호와 품목 번호를 결합한 문서화된 복합 키를 사용하고 모든 이벤트에 동일한 키를 적용합니다.
- 주요 데이터 소스: EBAN은 구매요청 품목 데이터에 사용합니다. EBKN은 계정 지정과 부서 또는 원가 중심점 정보를 보완하는 데 사용합니다. 실행 전에 SAP 데이터 사전에서 정확한 필드 이름과 데이터 형식을 확인합니다.
- 이벤트 소스: 변경, 승인, 소스 지정, 구매오더 참조 및 종료 소스는 S/4HANA 릴리스, 워크플로 설계, 릴리스 절차, 활성화된 비즈니스 기능 및 고객 확장에 따라 달라집니다. 따라서 쿼리에는 해당 소스를 지정할 자리표시자가 포함되어 있습니다.
- 날짜 범위: 처음에는 3~6개월을 대상으로 합니다. 가능한 경우 인덱스가 있거나 파티션 제거가 가능한 날짜 필드에 범위를 지정합니다. 증분 적재에서는 늦게 도착하는 변경 사항을 포함할 수 있도록 추출 기간을 충분히 겹치고, 사례, 활동, 타임스탬프, 품목 및 소스 이벤트 키를 기준으로 중복을 제거합니다.
- 업무 필터: 해당 필드를 사용할 수 있고 업무상 의미가 확인된 경우에만 [Company code filter], [Document type filter], [Purchasing group filter], [Plant filter]를 설정합니다. 전체 생애주기를 수집하려는 경우 상태 필터는 피하세요.
- 상태 매핑: 대상 시스템의 릴리스 전략 또는 워크플로 설정에 따라 승인 중, 최종 승인, 거부, 초기화, 릴리스 코드 대기 및 종료 상태의 값을 설정합니다. SAP 클라이언트마다 상태 코드가 동일하다고 가정하지 마세요.
- 수정 매핑: 수량, 가격, 자재, 납품일, 계정 지정 및 프로세스에서 주요 필드로 정의한 기타 항목의 변경을 포함합니다. 쿼리에는 나열된 주요 필드에 대한 조건이 명시되어 있으며, 소스에서 변경된 필드 이름을 제공해야 합니다.
- 타임스탬프 처리: 데이터베이스 시간대를 기준으로 이벤트 날짜와 시간을 결합한 뒤 UTC로 변환하는 경우 그 방법을 문서화합니다. 소스에 날짜만 저장되어 있고 더 정확한 타임스탬프가 없을 때만 자정을 사용하고, 해당 한계를 기록합니다.
- 성능: 초기 추출은 날짜와 업무 범위를 제한하고 필요한 열만 선택합니다. 대량의 변경 이력이나 워크플로 이력과 무제한으로 조인하지 말고 HANA 실행 계획을 검토합니다. 반복 추출이 필요하면 정규화된 이벤트 소스를 구체화하거나 스테이징합니다.
- 권한 및 사전 준비: EBAN, EBKN, 설정된 변경 및 워크플로 소스, 소스 지정 데이터, 구매오더 참조 데이터 및 종료 데이터에 대한 읽기 권한을 확보합니다. 데이터베이스 직접 접속이 승인되었는지, 관련 구매 및 워크플로 기능이 활성화되어 있는지, 필요한 SAP HANA 데이터베이스 라이선스나 관리 도구를 사용할 수 있는지 확인합니다.
- 보안: 최소 권한 원칙을 적용하고 사용자 및 승인자 식별 정보를 보호하며, 구매 및 재무 정보 추출에 관한 조직의 규정을 따릅니다.
샘플 쿼리 sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; 시작할 준비가 되셨나요?
이 템플릿을 활용해 데이터를 준비하고 구매요청부터 지급까지의 프로세스에 프로세스 마이닝을 적용해 보세요. 지금 프로세스 효율화를 시작하세요.
구매요청 처리 지연을 줄이세요. 지금 워크플로를 개선하세요!
프로세스를 간소화하고 처리 기간을 단축해 전체 처리 시간을 30% 줄이세요.
신용카드 없이 5분 만에 설정할 수 있습니다.