구매 요청 데이터 템플릿

구매 요청 ID는 구매 요청 문서를 생성할 때 부여하는 고유 키입니다. 요청의 시작부터 완료까지 단일 요청과 관련된 모든 활동, 변경 사항, 승인을 연결하는 기준으로 사용됩니다.

process mining에서 이 ID는 케이스를 연결하는 데 필수적입니다. 시스템은 이 ID를 기준으로 각 구매 요청의 전체 흐름을 재구성하고, '구매 요청 생성', '승인 단계 승인', '구매 주문서 생성'처럼 서로 다른 이벤트를 하나의 일관된 프로세스 흐름으로 연결합니다. 일관되고 고유한 케이스 식별자가 없으면 프로세스 변형, 처리 주기, 결과를 분석할 수 없습니다.

구매 요청의 전체 수명 주기를 추적하는 기준 키입니다. 관련 이벤트를 하나의 프로세스 인스턴스로 연결할 수 있습니다.

일반적으로 구매 요청 트랜잭션의 헤더 데이터나 문서 테이블에서 확인할 수 있습니다.

이벤트 시간은 타임스탬프라고도 하며, 활동이 발생한 정확한 시점을 기록합니다. 이벤트 순서를 올바르게 정하고 처리 주기 계산, 병목 파악, 성과 모니터링 등 시간 기반 프로세스 분석을 수행하는 데 필요한 데이터입니다.

process mining에서는 타임스탬프를 사용해 각 케이스의 활동 순서를 정하고 단계 간 소요 시간을 측정합니다. 소요 시간을 분석하면 지연을 찾아내고 처리 주기가 길어지는 원인을 파악하며 서비스 수준 계약의 준수 여부를 평가할 수 있습니다. 의미 있는 성과 분석을 하려면 타임스탬프 데이터가 정확하고 빠짐없이 기록되어야 합니다.

이 타임스탬프는 이벤트 순서 지정, 처리 주기 계산, 프로세스 성과와 병목 분석에 필요합니다.

일반적으로 시스템 감사 추적이나 이벤트 로그에 기록되며, 트랜잭션 레코드의 생성일 또는 변경일로 저장되기도 합니다.

활동명은 구매 요청 수명 주기에서 발생한 개별 단계나 상태 변경을 나타냅니다. '구매 요청 제출', '승인 단계 시작', '구매 요청 거부'와 같은 이벤트를 사람이 이해하기 쉬운 이름으로 표시하며, 프로세스 맵을 구성하는 기본 요소가 됩니다.

이 속성은 프로세스 탐색과 분석의 기반입니다. 활동을 순서대로 배열하면 process mining 도구로 실제 프로세스 흐름을 시각화하고, 표준 절차에서 벗어난 부분을 찾으며, 병목이나 재작업 반복을 파악할 수 있습니다. 이해하기 쉽고 실행 가능한 프로세스 모델을 만들려면 활동명을 일관되고 명확하게 정해야 합니다.

프로세스의 개별 단계를 정의하며, 프로세스 맵을 시각화하고 흐름을 분석하는 데 필요합니다.

구매 요청 문서와 관련된 이벤트 로그, 상태 변경 테이블 또는 트랜잭션 코드에서 가져오는 경우가 많습니다.

소스 시스템 속성은 프로세스 데이터의 출처를 나타냅니다. 중앙 ERP와 전자 조달 전용 도구처럼 여러 시스템을 사용하는 조직에서는 이 필드로 데이터 출처를 구분할 수 있습니다.

이 정보는 데이터 검증과 문제 해결, 시스템에 따라 달라지는 프로세스 차이를 파악하는 데 유용합니다. 예를 들어 한 시스템에서 시작된 구매 요청은 다른 시스템의 요청과 승인 경로가 다르거나 처리 주기가 더 짧을 수 있습니다. 소스 시스템별로 데이터를 분석하면 시스템 통합 문제나 시스템 통합 기회를 찾을 수 있습니다.

데이터 출처를 파악할 수 있어 데이터 검증과 여러 시스템 간 프로세스 차이 분석에 도움이 됩니다.

데이터 추출 과정에서 추가되는 고정값인 경우가 많으며, 기술 메타데이터 필드에서 확인할 수도 있습니다.

최종 데이터 업데이트 타임스탬프는 분석 중인 데이터의 최신성을 나타냅니다. 레코드를 소스 시스템에서 마지막으로 추출해 process mining 환경에 적재한 시점을 보여줍니다.

이 속성은 운영 모니터링과 최신 정보를 바탕으로 한 분석에 필요합니다. 실제 이벤트가 발생한 시점과 프로세스 모델에 반영되는 시점 사이에 지연이 있을 수 있음을 사용자가 파악하도록 돕습니다. 진행 중인 운영을 추적하는 대시보드와 KPI는 이 정보를 바탕으로 시의적절하고 관련성 높은 인사이트를 제공합니다.

데이터가 얼마나 최신인지 알려주므로 분석 결과의 적시성과 관련성을 확인하는 데 중요합니다.

일반적으로 데이터 적재 과정에서 데이터 통합 도구나 ETL(추출, 변환, 적재) 도구가 추가합니다.

구매 요청 금액은 요청에 포함된 모든 품목과 서비스의 총 금액입니다. 조달 프로세스 전반에서 사용하는 주요 재무 지표입니다.

프로세스 분석에서는 금액을 기준으로 데이터를 필터링하고 분석할 수 있습니다. 금액이 큰 요청과 작은 요청을 구분할 수 있으며, 두 유형은 승인 워크플로와 위험 수준이 다를 수 있습니다. 구매 요청 금액에 따른 처리 주기나 거부율을 분석하면 고액 요청의 승인에 시간이 더 걸리거나 거부되는 경우가 많은지 확인할 수 있습니다. 이를 바탕으로 프로세스 개선을 시작할 수 있습니다.

금액에 따른 분석이 가능해 고액 구매 요청의 우선순위를 정하고 금액이 프로세스에 미치는 영향을 파악할 수 있습니다.

일반적으로 구매 요청 트랜잭션의 헤더 데이터나 문서 테이블에서 확인할 수 있습니다.

구매 요청 상태는 특정 시점의 진행 상태나 최종 결과를 나타냅니다. 일반적인 상태로는 '진행 중', '승인 대기', '승인됨', '거부됨', '종료됨'이 있습니다.

이 속성은 결과 분석과 운영 모니터링에 필요합니다. 최종 상태별로 구매 요청을 필터링해 거부율이나 구매 주문서 전환율 같은 지표를 계산할 수 있습니다. 운영 측면에서는 승인 대기 중인 구매 요청 수처럼 현재 업무량을 파악해 팀이 업무 우선순위를 정하고 리소스를 효율적으로 관리하도록 돕습니다.

구매 요청 결과를 명확히 파악해 거부율과 같은 주요 지표를 계산하고 운영 업무량을 관리할 수 있습니다.

일반적으로 구매 요청 문서의 헤더 상태 필드에서 확인할 수 있습니다.

구매 요청 유형은 요청의 성격이나 목적에 따라 구매 요청을 분류합니다. 일반 자재, 서비스, 자본 지출 또는 특정 카탈로그 품목에 대한 요청 등이 있습니다. 이 분류에 따라 승인 워크플로와 회계 처리가 달라지는 경우가 많습니다.

유형별로 프로세스를 분석하면 요청 유형에 따라 경로와 처리 효율이 달라지는지 파악할 수 있습니다. 예를 들어 자본 지출 구매 요청은 승인 단계가 추가되어 처리 주기가 길 수 있지만, 표준 카탈로그 품목 요청은 자동화 수준이 높을 수 있습니다. 분석 결과를 활용해 유형별 프로세스 흐름을 설계하고 최적화할 수 있습니다.

구매 요청 유형에 따라 필요한 승인 워크플로와 복잡성이 달라지는 경우가 많아 프로세스 경로를 유형별로 분석할 수 있습니다.

일반적으로 구매 요청 헤더 데이터에 문서 유형 또는 범주 코드로 저장됩니다.

구매 주문서 ID는 승인된 구매 요청에서 생성된 구매 주문서의 고유 번호입니다. 이 필드로 구매 요청 프로세스를 후속 조달 및 결제 프로세스와 연결할 수 있습니다.

이 속성은 구매 요청에서 구매 주문서로 전환되는 효율을 분석하는 데 중요합니다. 구매 요청이 실제 구매 주문서로 이어졌는지 확인하고 전환에 걸린 시간을 측정할 수 있습니다. 구매 요청과 연결된 구매 주문서가 있는지 분석하면 조달 전 단계의 효과를 평가하고 승인 후에도 이행되지 않은 요청을 찾을 수 있습니다.

구매 요청을 후속 조달 프로세스와 연결해 구매 요청에서 구매 주문서로의 전환율과 소요 시간을 분석할 수 있습니다.

구매 주문서 생성 후 구매 요청 문서 데이터에서 확인할 수 있으며, 관련 문서 또는 문서 흐름 테이블에 저장되기도 합니다.

부서 속성은 구매를 담당하는 조직 단위를 나타냅니다. 예를 들어 '마케팅', 'IT', '재무' 등이 있습니다. 예산 편성과 비용 배분에 사용하는 주요 재무 및 조직 데이터입니다.

process mining에서는 부서별 분석을 자주 활용합니다. 사업 부서 간 성과를 비교해 효율이 높은 부서와 지원이 필요한 부서를 파악할 수 있습니다. 처리 주기, 승인율 또는 규정 준수의 차이를 분석하면 부서별 구매 방식이나 내부 절차에서 비롯된 차이를 찾을 수 있습니다.

사업 부서별 성과를 비교하고 비용을 분석해 부서마다 다른 프로세스 특성을 파악할 수 있습니다.

일반적으로 구매 요청의 헤더 또는 품목 데이터에서 확인할 수 있으며, 회사의 조직 구조와 연결됩니다.

요청자 이름은 구매 요청을 시작한 사람을 식별합니다. 일반적으로 필요한 물품이나 서비스를 요청하는 업무 담당자입니다.

요청자별로 프로세스를 분석하면 개인이나 그룹에 따른 패턴을 찾을 수 있습니다. 예를 들어 특정 요청자가 불완전하거나 규정을 준수하지 않는 구매 요청을 자주 제출해 재작업이 발생하는지 확인할 수 있습니다. 이 정보를 활용해 필요한 사용자 그룹에 맞춤형 교육을 제공하거나 구매 요청 절차를 간소화하면 효율성과 규정 준수를 높일 수 있습니다.

사용자별 업무 방식을 파악해 개인이나 팀에 맞는 교육과 프로세스 개선을 진행할 수 있습니다.

구매 요청의 헤더 데이터에서 확인할 수 있으며, 직원 마스터 데이터와 연결되어 있는 경우가 많습니다.

통화 속성은 구매 요청 금액의 화폐 단위를 나타냅니다. 다국적 조직에서는 요청자나 공급업체의 위치에 따라 구매 요청이 여러 통화로 작성될 수 있습니다.

정확한 재무 보고와 분석을 위해 필요한 필드입니다. 금액을 올바르게 해석하고 여러 지역의 데이터를 합산할 때 적절히 환산할 수 있습니다. 구매 요청 금액을 분석할 때는 서로 다른 통화 단위를 그대로 비교하지 않도록 통화를 고려해야 합니다.

재무 데이터를 정확히 해석하고 여러 지역의 구매 요청 금액을 합산하는 데 필요한 정보를 제공합니다.

일반적으로 구매 요청 트랜잭션의 헤더 데이터에서 금액 필드와 함께 확인할 수 있습니다.

거부 사유는 구매 요청이 승인되지 않은 이유를 설명하는 텍스트 또는 코드입니다. 승인자는 요청자에게 피드백을 제공하기 위해 이 정보를 입력하며, 요청자는 이를 바탕으로 내용을 수정해 다시 제출할 수 있습니다.

이 속성은 프로세스 실패의 근본 원인을 분석하는 데 유용합니다. 거부 사유를 분류하고 분석하면 '잘못된 GL 코드', '예산 초과', '규정을 준수하지 않는 공급업체'와 같은 반복 문제를 찾을 수 있습니다. 이를 바탕으로 요청자 교육, 정책 안내, 시스템 개선 등을 진행해 자주 발생하는 오류를 예방할 수 있습니다.

구매 요청이 거부된 이유를 직접 파악해 근본 원인을 분석하고 재작업을 줄이며 최초 승인율을 높일 수 있습니다.

일반적으로 '거부됨' 활동 또는 상태 변경과 연결된 의견이나 메모 필드에 기록됩니다.

긴급도는 우선순위라고도 하며, 요청자가 물품이나 서비스가 얼마나 빨리 필요한지 표시하는 필드입니다. 이 분류에 따라 조달팀과 승인자가 구매 요청을 전달받고 우선순위를 정하는 방식이 달라질 수 있습니다.

긴급도별로 프로세스 성과를 분석하면 업무 요구에 맞게 요청을 처리하는지 확인할 수 있습니다. 예를 들어 긴급도가 '높음'인 요청이 '낮음'인 요청보다 실제로 더 빨리 처리되는지 확인할 수 있습니다. 그렇지 않다면 병목이 있거나 우선순위 지정 방식이 제대로 작동하지 않을 수 있습니다.

긴급 요청의 우선순위가 적절히 반영되는지, 표시된 긴급도와 실제 처리 속도가 일치하는지 평가할 수 있습니다.

일반적으로 구매 요청 작성 양식의 선택 또는 필수 입력란이며, 구매 요청 헤더에 저장됩니다.

사용자 이름은 프로세스 로그의 각 활동을 수행한 사람을 나타냅니다. 요청자, 편집자, 승인자 또는 구매 요청과 관련된 다른 사용자를 기록할 수 있는 일반 속성입니다.

이 속성은 리소스 및 자동화 분석에 중요합니다. 서로 다른 사용자가 업무를 주고받는 '4-eyes 원칙'을 파악하고, 시스템 또는 배치 사용자가 수행한 활동을 식별해 자동화율을 계산하는 데 활용할 수 있습니다. 사용자별 활동을 분석하면 각 역할이 프로세스에 어떻게 관여하는지 파악할 수 있습니다.

사용자 간 업무 인계와 자동화를 분석하고, 각 프로세스 단계를 적절한 담당자와 연결하는 데 필요한 속성입니다.

각 거래의 감사 추적 또는 이벤트 로그 데이터에서 확인할 수 있으며, 보통 사용자 ID로 저장됩니다.

승인자 이름은 워크플로에서 승인 또는 거부 단계를 수행한 개인, 역할 또는 그룹을 식별합니다. 요청자나 다른 활동을 수행하는 일반 사용자와는 구분됩니다.

이 속성은 승인 프로세스 자체를 분석하는 데 중요합니다. 승인자가 결정을 내리는 데 걸리는 평균 시간 등 승인자별 성과를 측정할 수 있습니다. 또한 특정 승인자에게 업무가 집중되어 프로세스의 병목이 되는지 확인할 수 있습니다. 분석 결과를 활용해 승인 절차의 리소스 배분과 성과 관리를 개선할 수 있습니다.

승인자별 업무량과 성과를 분석하고 승인 워크플로의 병목을 파악할 수 있습니다.

승인 관련 활동의 이벤트 로그 또는 감사 로그에 기록됩니다. 직원 마스터 데이터와 연결해야 할 수도 있습니다.

필요일은 요청자가 구매 요청을 이행해야 하는 기한으로 지정합니다. 구매 요청 승인부터 최종 배송까지 조달 프로세스 전반의 목표 날짜로 사용됩니다.

이 속성은 프로세스가 적시에 진행되는지, 비즈니스 요구에 부합하는지 분석하는 데 중요합니다. 필요일을 실제 구매 주문 생성일 또는 배송일과 비교하면 내부 서비스 수준 협약을 얼마나 잘 준수하는지 측정할 수 있습니다. 조달 프로세스가 비즈니스 기한을 맞출 만큼 빠른지와 같은 질문에 답하는 데 도움이 됩니다.

비즈니스 기한을 기준으로 프로세스 성과를 측정하고, 정시 이행 역량을 평가하는 기준이 됩니다.

일반적으로 구매 요청을 생성할 때 사용자가 입력하며, 요청 헤더 또는 품목 상세 정보에 저장됩니다.