구매 요청부터 지급까지 프로세스의 데이터 템플릿
구매 요청부터 지급까지 프로세스의 데이터 템플릿
- 상세 분석에 권장되는 속성
- 추적해야 할 주요 프로세스 활동
- 실용적인 데이터 추출 안내
구매 요청부터 지급까지 프로세스의 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
구매 요청 ID
PurchaseRequisitionId
|
각 구매 요청을 식별하는 고유 ID로, 프로세스의 기본 케이스 ID로 사용됩니다. | ||
|
설명
구매 요청 ID는 하나의 상품 또는 서비스 요청과 관련된 모든 활동을 연결하는 기준 키입니다. 요청이 생성될 때 고유 ID가 부여되며 수명 주기 내내 유지됩니다. 이 ID를 사용하면 요청 생성과 제출부터 승인 또는 거부 단계, 최종 소싱과 종료까지 전체 과정을 추적할 수 있습니다. process mining에서는 모든 이벤트 로그 항목이 이 ID와 연결되므로 각 케이스의 전체 진행 과정을 재구성할 수 있습니다.
중요한 이유
모든 프로세스 단계를 연결하는 기본 케이스 ID로, 구매 요청의 시작부터 종료까지 전체 수명 주기를 분석할 수 있습니다.
확보 방법
Coupa의 Requisitions 모듈과 관련 데이터 내보내기에 포함된 기본 키 필드입니다.
예시
PR-102934PR-102935PR-102936
|
|||
|
이벤트 시간
EventTime
|
활동이 발생한 정확한 날짜와 시간입니다. | ||
|
설명
이벤트 시간 또는 타임스탬프는 구매 요청 활동이 기록된 정확한 시점을 나타냅니다. 이벤트를 시간순으로 정렬해 프로세스 흐름을 구성하는 데 필요한 데이터입니다. 처리 시간 계산, 활동 간 소요 시간 측정을 통한 병목 파악, 기간별 프로세스 성과 분석 등 시간 기반 분석의 기준이 됩니다. 의미 있는 프로세스 분석을 위해서는 정확하고 세밀한 타임스탬프가 필요합니다.
중요한 이유
이 타임스탬프는 이벤트를 올바른 순서로 정렬하고 처리 시간이나 병목과 같은 시간 기반 지표를 계산하는 데 필요합니다.
확보 방법
Coupa에서 각 구매 요청의 감사 추적 또는 이력 레코드에 기록됩니다. 각 작업의 'created_at' 또는 'updated_at' 필드에 저장되는 경우가 많습니다.
예시
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
|
|||
|
활동명
ActivityName
|
특정 시점에 구매 요청과 관련해 발생한 업무 활동 또는 이벤트의 이름입니다. | ||
|
설명
이 속성은 구매 요청 수명 주기의 개별 단계를 기록합니다. 예를 들면 '구매 요청 생성', '승인 단계 승인', '구매 요청 소싱 진행' 등이 있습니다. 각 활동은 구매 요청에 대해 수행된 특정 작업이나 주요 단계를 나타냅니다. 활동의 순서와 빈도를 분석하면 프로세스 맵을 시각화하고, 일반적인 경로를 파악하며, 표준 절차에서 벗어난 사례를 찾을 수 있어 process mining의 기반이 됩니다.
중요한 이유
프로세스 맵의 단계를 정의하므로 구매 요청의 흐름을 시각화하고 분석할 수 있습니다.
확보 방법
일반적으로 Coupa 시스템의 이벤트 로그, 상태 변경 기록 또는 감사 추적에서 가져옵니다. 상태 필드나 작업 코드의 매핑이 필요할 수 있습니다.
예시
요청서 생성요청서 제출승인 단계 승인구매 요청 거부구매 주문 생성
|
|||
|
원천 시스템
SourceSystem
|
데이터를 추출한 원천 시스템을 식별합니다. | ||
|
설명
이 속성은 프로세스 데이터가 생성된 기록 시스템을 나타냅니다. 이 분석에서는 값이 항상 'Coupa'입니다. 여러 시스템의 데이터를 병합할 수 있는 환경에서는 이 필드를 포함하는 것이 바람직합니다. 데이터 계보를 파악하고 데이터 거버넌스 및 품질 규칙을 관리하는 데 필요한 맥락을 제공합니다.
중요한 이유
데이터 계보를 명확히 파악할 수 있어 데이터 거버넌스와 여러 기업 시스템의 데이터를 결합할 때 유용합니다.
확보 방법
일반적으로 데이터 추출 및 변환 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다.
예시
Coupa
|
|||
|
최종 데이터 업데이트
LastDataUpdate
|
원천 시스템에서 데이터를 마지막으로 새로 고친 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 Coupa에서 데이터를 가장 최근에 추출한 날짜와 시간을 기록합니다. 분석 중인 데이터의 최신성을 확인할 수 있습니다. 인사이트가 현재 운영 상태를 반영하는지, 아니면 이전 시점의 상태를 반영하는지 사용자가 판단하려면 데이터의 최신 시점을 알아야 합니다. 진행 중인 운영을 모니터링하는 대시보드에서는 특히 중요합니다.
중요한 이유
데이터의 최신 시점을 알려 분석 기간을 파악하고 최신 정보를 바탕으로 의사결정할 수 있도록 합니다.
확보 방법
데이터 파이프라인 또는 ETL 도구가 데이터 추출을 성공적으로 마친 후 이 타임스탬프를 생성해 추가합니다.
예시
2024-05-21T02:00:00Z
|
|||
|
구매 요청 상태
RequisitionStatus
|
구매 요청의 현재 상태 또는 최종 상태입니다. | ||
|
설명
이 속성은 데이터 추출 시점의 구매 요청 상태 또는 최종 결과를 나타냅니다. 일반적인 상태로는 '승인 대기', '승인', '거부', '철회', '종료'가 있습니다. 필터링과 분석에 사용하는 주요 기준입니다. 승인율과 거부율을 계산하고, 미종결 구매 요청의 현재 업무량을 모니터링하며, 요청의 최종 처리 결과를 파악하는 데 사용됩니다.
중요한 이유
구매 요청의 처리 결과를 파악하고 승인율과 거부율을 계산하며, 진행 중인 요청의 현재 상태를 모니터링하는 데 필요합니다.
확보 방법
Coupa의 Purchase Requisition 객체에 있는 표준 필드로, 보통 'status' 또는 'state'라는 이름을 사용합니다.
예시
승인 대기승인거부철회종료
|
|||
|
부서
Department
|
구매 요청 비용이 청구되는 사업 부서 또는 비용 센터입니다. | ||
|
설명
부서 속성은 각 구매 요청을 특정 조직 단위 또는 비용 센터와 연결합니다. 부서별 비교 분석에 필요한 기준입니다. 대시보드와 KPI를 부서별로 필터링하고 구분해 승인 처리 시간, 거부율, 규정 준수를 조직 내 여러 부문 간에 비교할 수 있습니다. 이를 통해 부서별 문제나 모범 사례를 파악할 수 있습니다.
중요한 이유
사업 부문별로 처리 시간이나 거부율 같은 프로세스 KPI를 비교해 개선이 필요한 영역을 찾을 수 있습니다.
확보 방법
Coupa의 Requisition 객체에 있는 표준 필드입니다. 요청자의 사용자 프로필과 연결되거나 구매 요청 품목에 지정되는 경우가 많습니다.
예시
마케팅IT 운영시설 관리연구 개발
|
|||
|
승인자
Approver
|
승인 활동을 담당하는 사용자 또는 그룹입니다. | ||
|
설명
이 속성은 승인 단계에 지정된 개인 또는 승인 그룹을 식별합니다. '승인 단계 시작', '승인 단계 승인', '승인 단계 거부'와 같은 활동에 값이 기록됩니다. 승인자별 데이터를 분석하면 '승인자 성과 및 업무량' 대시보드를 구성할 수 있습니다. 개인별 승인 처리 시간을 측정하고, 특정 승인자로 인한 병목을 파악하며, 업무량 분배를 평가하는 데 도움이 됩니다.
중요한 이유
승인자별 성과와 업무량을 분석하고 특정 개인이나 승인 그룹과 관련된 병목을 파악하는 데 필요합니다.
확보 방법
Coupa에서 각 구매 요청에 연결된 승인 체인 세부 정보에 있습니다. User 데이터를 결합해야 할 수 있습니다.
예시
David Miller재무 승인자 L2Susan Chen
|
|||
|
요청자
Requester
|
구매 요청을 생성하고 제출한 직원입니다. | ||
|
설명
이 속성은 요청을 시작한 사용자를 식별합니다. 요청자별 데이터를 분석하면 수정이 잦거나 거부가 빈번한 사용자와 같은 패턴을 파악할 수 있으며, 추가 교육이 필요한지 판단하는 데 도움이 됩니다. 사용자 또는 사용자 그룹별 구매 요청 건수와 프로세스 이용 방식도 분석할 수 있습니다.
중요한 이유
사용자별 프로세스 이용 방식을 분석해 교육 필요성을 파악하고, 사용자마다 프로세스를 어떻게 이용하는지 이해할 수 있습니다.
확보 방법
Coupa의 Requisition 객체에 있는 표준 필드로, User 객체와 연결되며 보통 'requester' 또는 'created_by'라는 이름을 사용합니다.
예시
Alice JohnsonBob SmithCharlie Brown
|
|||
|
총액
TotalAmount
|
구매 요청의 총 금액입니다. | ||
|
설명
이 속성은 구매 요청에 포함된 상품과 서비스의 총비용을 나타냅니다. 금액은 승인 워크플로의 복잡성에 영향을 주는 경우가 많아 프로세스 분석에서 중요한 요소입니다. 금액이 큰 요청일수록 승인 단계가 더 많을 수 있습니다. 금액 구간(예: <$1,000, $1,000-$10,000)별로 프로세스 지표를 분석하면 재정 규모가 다른 요청을 프로세스에서 어떻게 처리하는지 파악할 수 있습니다.
중요한 이유
금액이 큰 요청은 더 복잡한 승인 워크플로를 거치는 경우가 많으므로, 요청 금액에 따라 프로세스가 어떻게 달라지는지 분석할 수 있습니다.
확보 방법
Coupa의 Requisition 객체 헤더에 있는 표준 필드로, 일반적으로 'total' 또는 'total_amount'라는 이름을 사용합니다.
예시
500.0012550.7599.99
|
|||
|
거부 사유
RejectionReason
|
승인자가 구매 요청 또는 승인 단계를 거부할 때 입력한 사유입니다. | ||
|
설명
승인자가 구매 요청을 거부할 때는 결정 사유를 입력하는 경우가 많습니다. 이 속성은 해당 설명을 텍스트로 기록합니다. 거부 사유를 분석하면 요청이 거부된 이유를 직접 파악할 수 있습니다. 잘못된 코드 입력, 예산 부족, 근거 미흡과 같은 반복 문제를 찾아 교육이나 프로세스 개선으로 해결하는 근본 원인 분석에 유용합니다.
중요한 이유
프로세스 실패의 근본 원인을 파악해 사용자 교육이나 프로세스 안내를 보완할 영역을 찾을 수 있습니다.
확보 방법
일반적으로 구매 요청 승인 이력에서 상태가 '거부'로 변경될 때 연결된 댓글 또는 메모 필드에 기록됩니다.
예시
비용 센터 오류이번 분기 예산 초과중복 요청요청 근거 부족
|
|||
|
공급업체명
SupplierName
|
구매 요청에 지정된 공급업체의 이름입니다. | ||
|
설명
이 속성은 요청한 상품 또는 서비스의 공급업체를 식별합니다. 요청자가 공급업체를 지정하거나 이후 소싱 과정에서 추가할 수 있습니다. 공급업체별 프로세스 지표를 분석하면 공급업체 성과를 평가하고 특정 공급업체와의 거래가 처리 시간을 늘리거나 비효율을 일으키는지 파악할 수 있습니다. 조달 전략과 공급업체 관계 관리에도 필요한 정보입니다.
중요한 이유
선택한 공급업체에 따른 프로세스 성과를 분석해 소싱 전략과 공급업체 관리에 활용할 수 있습니다.
확보 방법
Coupa의 Requisition Line 객체에서 확인할 수 있으며, 보통 'supplier' 또는 'vendor' 필드에 저장됩니다.
예시
StaplesDell TechnologiesAccentureCDW
|
|||
|
구매 요청 유형
RequisitionType
|
구매 요청의 분류 또는 유형으로, '자본 지출', '운영 비용', '소프트웨어' 등이 있습니다. | ||
|
설명
구매 요청 유형은 업무 목적이나 구매 성격에 따라 요청을 분류하는 속성입니다. 규정 준수 분석과 요청 유형별 프로세스 흐름을 파악하는 데 유용합니다. 예를 들어 자본 지출 요청은 일반 운영 비용 요청보다 더 엄격하고 긴 승인 절차를 거칠 수 있습니다. 구매 요청 유형별로 프로세스를 분석하면 개선에 필요한 정보를 얻을 수 있습니다.
중요한 이유
요청의 업무 목적별로 분석을 구분할 수 있습니다. 유형에 따라 프로세스 흐름과 정책이 다를 수 있습니다.
확보 방법
Coupa의 Requisition 객체에 있는 표준 분류 필드이거나 사용자 정의 필드일 수 있습니다.
예시
자본 지출운영 비용IT 하드웨어전문 서비스
|
|||
|
구매 주문 ID
PurchaseOrderId
|
승인된 구매 요청에서 생성된 구매 주문의 식별자입니다. | ||
|
설명
구매 요청의 승인이 완료되고 소싱이 진행되면 일반적으로 구매 주문이 생성됩니다. 이 속성에는 생성된 PO의 ID가 저장됩니다. 이를 통해 앞 단계인 구매 요청 프로세스와 다음 단계인 구매 주문 프로세스를 연결할 수 있습니다. '구매 요청 승인부터 PO 생성까지 걸린 시간' KPI를 계산하고 전체 구매-지급 주기를 처음부터 끝까지 분석할 수 있습니다.
중요한 이유
구매 요청과 후속 구매 주문을 연결해 단계 간 인계 시간을 분석하고 구매-지급 프로세스 전체를 파악할 수 있습니다.
확보 방법
Coupa의 Requisition 객체에 있는 표준 필드로, PO 생성 후 값이 입력됩니다.
예시
PO-45000123PO-45000124PO-45000125
|
|||
|
긴급도
UrgencyLevel
|
구매 요청의 긴급도를 나타내는 분류로, '높음', '보통', '낮음' 등이 있습니다. | ||
|
설명
긴급도는 우선순위 필드에 매핑되는 경우가 많으며, 신속한 처리가 필요한 요청을 요청자가 표시할 수 있습니다. '긴급 구매 요청 처리 시간' 대시보드에 필요한 속성입니다. 긴급도가 높은 요청과 일반 요청의 처리 시간을 비교하면 우선순위 정책이 효과적인지, 긴급한 업무상 요구가 제때 충족되는지 평가할 수 있습니다.
중요한 이유
긴급 요청이 일반 요청보다 빠르게 처리되는지 분석해 우선순위 정책의 효과를 확인할 수 있습니다.
확보 방법
Coupa의 Requisition 객체에 있는 표준 필드이거나 사용자 정의 필드일 수 있습니다. Coupa 문서 또는 시스템 설정을 확인하세요.
예시
높음보통낮음
|
|||
|
수정 여부
IsAmended
|
최초 제출 후 구매 요청이 한 번 이상 수정된 경우 참으로 설정되는 불리언 플래그입니다. | ||
|
설명
이 계산 속성은 해당 케이스에서 '구매 요청 수정' 활동이 발생했는지를 참 또는 거짓으로 표시합니다. 수정이 필요한 구매 요청만 쉽게 필터링할 수 있어 분석이 간편해집니다. 구매 요청 수정률 KPI를 계산하고 '구매 요청 수정 건수' 대시보드를 구성하는 데 사용되며, 재작업의 원인을 파악하고 최초 제출 품질을 높이는 데 도움이 됩니다.
중요한 이유
수정률 KPI를 간편하게 계산하고 재작업이 필요한 케이스와 그렇지 않은 케이스를 쉽게 구분할 수 있습니다.
확보 방법
process mining 도구에서 각 케이스의 이벤트 로그에 '구매 요청 수정' 활동이 있는지 확인해 계산합니다.
예시
truefalse
|
|||
|
승인 단계 소요 시간
ApprovalStepDuration
|
구매 요청이 단일 승인 단계에서 대기한 시간입니다. | ||
|
설명
이 계산 지표는 '승인 단계 시작' 활동부터 이에 대응하는 '승인 단계 승인' 또는 '승인 단계 거부' 활동까지 걸린 시간을 측정합니다. 승인 체인의 각 단계에서 대기한 시간을 따로 확인할 수 있습니다. '주요 승인 단계 병목' 대시보드에서 지연을 가장 많이 일으키는 승인자나 단계를 정확히 파악하는 데 필요합니다.
중요한 이유
전체 처리 시간만 보는 대신 각 단계의 대기 시간을 측정해 승인 워크플로의 병목을 구체적으로 찾아냅니다.
확보 방법
process mining 도구에서 '승인 단계 시작'과 그다음에 발생하는 최종 승인 이벤트(승인됨/거부됨) 사이의 시간 차이를 계산합니다.
예시
1.2일4시간3.8일
|
|||
|
승인 단계 수
ApprovalStepCount
|
구매 요청이 거친 승인 단계의 총수입니다. | ||
|
설명
이 계산 속성은 각 구매 요청에서 '승인 단계 승인됨' 활동이 발생한 횟수를 셉니다. 이를 통해 각 케이스의 승인 워크플로 복잡도를 파악할 수 있습니다. 이 값은 '평균 승인 단계 수' KPI를 계산하는 데 사용되며, 승인 경로가 비정상적으로 길거나 복잡해 워크플로를 간소화할 필요가 있는 구매 요청을 찾는 데 유용합니다.
중요한 이유
구매 요청별 승인 워크플로의 복잡도를 수치화해 간소화가 필요한 경로를 찾는 데 도움을 줍니다.
확보 방법
process mining 도구에서 각 Case ID별로 '승인 단계 승인됨'이 발생한 횟수를 세어 계산합니다.
예시
253
|
|||
|
승인 워크플로 경로
ApprovalWorkflowPath
|
구매 요청에 적용된 승인 체인 또는 워크플로 템플릿을 식별하는 값입니다. | ||
|
설명
이 속성은 구매 요청이 따라야 하는 사전 정의된 승인자 순서를 나타냅니다. 금액, 부서, 구매 요청 유형 등의 기준에 따라 업무 규칙으로 결정됩니다. '구매 요청 정책 준수' 대시보드의 분석에 중요한 속성입니다. 실제 승인자 순서를 지정된 워크플로 경로와 비교하면 편차를 감지하고 준수율을 측정하며 관리되지 않는 예외를 파악할 수 있습니다.
중요한 이유
예상 승인 단계와 실제 승인 단계를 비교해 프로세스 편차를 파악하고 규정 준수를 분석할 수 있습니다.
확보 방법
Coupa 문서를 확인하세요. 구매 요청에 적용된 승인 체인 또는 워크플로 규칙의 이름에서 가져올 수 있습니다.
예시
표준 승인 <$5kIT 하드웨어 승인 >$10k자본 지출 CFO 검토
|
|||
|
통화
Currency
|
구매 요청 총액의 통화 코드입니다. | ||
|
설명
이 속성은 구매 요청의 총액에 적용되는 통화(예: USD, EUR, GBP)를 나타냅니다. 여러 통화를 사용하는 다국적 조직의 재무 분석에 필요한 정보입니다. 금액을 올바르게 해석하고 재무 보고서와 대시보드에서 정확하게 환산하고 집계할 수 있습니다.
중요한 이유
'총액' 속성의 통화 정보를 제공해 여러 통화를 사용하는 환경에서도 정확한 재무 분석을 지원합니다.
확보 방법
Coupa의 Requisition 객체에 있는 표준 필드로, 보통 'currency_code' 또는 유사한 이름을 사용합니다.
예시
USDEURGBP
|
|||
|
품목 분류
Commodity
|
요청한 상품 또는 서비스의 상위 분류입니다. | ||
|
설명
품목 분류 속성은 구매 요청의 품목을 '사무용품', '컴퓨터 하드웨어', '마케팅 서비스'와 같이 표준화된 기준으로 분류합니다. 이를 통해 구매 항목에 따른 구매 패턴과 프로세스 차이를 분석할 수 있습니다. 품목에 따라 별도의 승인 요건이나 소싱 전략이 적용될 수 있으므로, 품목별 프로세스 분석은 지출 범주에 맞는 조달 방식을 개선하는 데 도움이 됩니다.
중요한 이유
지출 범주를 분석하고 구매하는 상품이나 서비스 유형에 따라 승인 시간 등의 프로세스가 달라지는지 파악할 수 있습니다.
확보 방법
Coupa의 표준 필드로, 일반적으로 구매 요청 품목 수준에서 제공됩니다. 헤더 수준으로 집계해야 할 수 있습니다.
예시
사무용품컴퓨터 하드웨어마케팅 서비스출장
|
|||
구매 요청부터 지급까지 프로세스의 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
구매 요청 거부
|
승인 과정에서 구매 요청이 최종 거부되어 구매 주문으로 전환되지 않습니다. 구매 요청 헤더의 전체 상태가 'rejected'로 변경된 것을 기준으로 추론합니다. | ||
|
중요한 이유
이 활동은 프로세스의 최종 실패를 나타냅니다. 이벤트를 분석하면 '구매 요청 거부율'을 낮추고 정책 위반이나 예산 문제와 같은 근본 원인을 찾는 데 도움이 됩니다.
확보 방법
'requisition_headers' 테이블의 'status' 필드가 'rejected'로 변경된 것을 기준으로 추론합니다. 타임스탬프는 관련 감사 추적에 기록됩니다.
기록
구매 요청의 전체 상태가 'rejected'로 변경된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
구매 요청 승인
|
구매 요청이 승인 워크플로의 필수 단계를 모두 통과했습니다. 구매 요청 헤더의 전체 상태가 'approved'로 변경된 것을 기준으로 추론합니다. | ||
|
중요한 이유
승인 주기의 종료를 나타내는 주요 성공 단계입니다. 이 활동까지 걸린 시간은 주요 KPI이며, 이후 조달 작업을 시작하는 기준이 됩니다.
확보 방법
'requisition_headers' 테이블의 'status' 필드가 'approved'로 변경된 것을 기준으로 추론합니다. 타임스탬프는 관련 감사 추적에 기록됩니다.
기록
구매 요청의 전체 상태가 'approved'로 변경된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
구매 요청 종료
|
구매 요청이 공식적으로 종료되어 더 이상 처리되지 않습니다. PO 생성 및 이행 후 종료될 수도 있고, 승인 후 주문 전에 취소되어 종료될 수도 있습니다. | ||
|
중요한 이유
이 활동은 구매 요청 수명 주기의 명확한 종료 지점입니다. 사례가 확실히 마무리되므로 프로세스 분석에서 무기한 '진행 중'으로 표시되는 일을 방지합니다.
확보 방법
'requisition_headers' 테이블의 'status' 필드가 'closed'로 변경된 것을 기준으로 추론합니다. 타임스탬프는 관련 감사 추적에 기록됩니다.
기록
구매 요청의 전체 상태가 'closed'로 변경된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
구매 주문 생성
|
승인된 구매 요청의 정보를 바탕으로 구매 주문(PO)이 생성됩니다. 원본 구매 요청 ID를 참조하는 PO 레코드가 생성된 경우를 기준으로 추론합니다. | ||
|
중요한 이유
구매 요청 프로세스의 주요 성공 결과이며, 다음 구매-지급 단계로 넘어가는 시점입니다. '구매 요청 승인'부터 이 이벤트까지 걸린 시간을 분석하면 실행 지연을 파악할 수 있습니다.
확보 방법
원본 'requisition_headers' 또는 'requisition_lines' ID를 참조하는 레코드가 'purchase_orders' 테이블에 생성된 것을 기준으로 추론합니다.
기록
구매 요청 ID와 연결된 PO 레코드의 'created-at' 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
요청서 생성
|
사용자가 새 구매 요청서를 작성해 초안으로 저장합니다. 각 요청서 케이스는 이 시점에서 시작하며, 일반적으로 요청서 레코드의 생성 시각을 기준으로 파악합니다. | ||
|
중요한 이유
이 활동은 요청서 처리 주기의 시작을 나타냅니다. 생성부터 제출까지 걸린 시간을 분석하면 사용자의 불확실성이나 시스템 복잡성으로 인한 지연을 파악할 수 있습니다.
확보 방법
해당 구매 요청서 ID의 'requisition_headers' 테이블에서 'created-at' 타임스탬프를 확인해 이 이벤트를 기록합니다.
기록
요청서 헤더 레코드의 생성 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
요청서 제출
|
요청자가 작성한 요청서를 승인 워크플로에 정식으로 제출합니다. 시스템 감사 로그나 이력 테이블에서 요청서 상태가 'draft'에서 'pending_approval'로 바뀐 시점을 확인해 이 이벤트를 파악합니다. | ||
|
중요한 이유
제출과 함께 승인 절차가 시작되므로 '평균 요청서 승인 주기' KPI를 측정하는 중요한 기준점입니다. 이 시점 전의 지연은 사용자와 관련이 있고, 이후의 지연은 프로세스와 관련이 있습니다.
확보 방법
'requisition_headers' 테이블의 상태 변경을 확인해 파악합니다. 구체적으로 'status' 필드가 'pending_approval'로 바뀐 시각을 연결된 감사 이력에서 확인합니다.
기록
요청서 상태가 처음으로 'pending_approval'로 바뀐 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
구매 요청 소싱 진행
|
승인된 구매 요청이 즉시 구매 주문으로 전환되는 대신 RFQ나 경매와 같은 소싱 이벤트로 전달됩니다. 구매 요청이 소싱 이벤트 객체와 연결된 경우를 기준으로 추론합니다. | ||
|
중요한 이유
이 활동은 조달 프로세스의 중요한 대안 경로를 보여줍니다. 일반 구매와 복잡한 전략적 소싱을 구분해 처리 시간을 더 세밀하게 분석할 수 있습니다.
확보 방법
상태가 'sourcing'으로 변경되었거나 'requisition_lines' 테이블과 소싱 이벤트 테이블 간에 연결이 생성된 경우를 확인해 추론합니다.
기록
상태가 'sourcing'으로 변경되었는지 또는 소싱 이벤트 ID와 연결이 생성되었는지 확인합니다.
이벤트 유형
inferred
|
|||
|
구매 요청 철회
|
최종 승인이 나기 전에 최초 요청자가 구매 요청을 취소합니다. 사용자가 직접 수행하는 명시적 작업으로, 해당 요청의 프로세스가 종료됩니다. | ||
|
중요한 이유
요청 철회는 업무상 필요의 변경, 중복 요청 또는 사용자의 프로세스 우회 등을 나타낼 수 있습니다. 이를 추적하면 수요 변동과 프로세스 준수 문제를 파악하는 데 도움이 됩니다.
확보 방법
감사 추적에 기록된 명시적 사용자 작업을 바탕으로 'requisition_headers' 테이블의 상태가 'withdrawn' 또는 이에 준하는 값으로 변경된 경우를 확인합니다.
기록
구매 요청 상태가 'withdrawn'으로 변경된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
승인 단계 승인
|
워크플로에서 개별 승인자가 구매 요청을 승인합니다. 시스템에 기록되는 명시적 작업으로, 정확한 타임스탬프와 사용자 정보가 남습니다. | ||
|
중요한 이유
이 활동을 통해 승인 프로세스의 흐름을 세부적으로 파악할 수 있습니다. 각 단계를 집계하면 '승인 단계별 평균 대기 시간'을 계산하고 승인자별 처리 성과를 분석할 수 있습니다.
확보 방법
'approvals' 테이블 또는 감사 추적에 기록된 명시적인 'approve' 작업을 기준으로 수집하며, 해당 구매 요청 및 승인자와 연결됩니다.
기록
구매 요청의 승인 이력에서 'approve' 이벤트를 필터링합니다.
이벤트 유형
explicit
|
|||
|
승인 단계 시작
|
승인 작업이 특정 승인자나 승인 그룹에 할당되어 요청서가 승인을 기다리는 상태가 됩니다. 요청서와 연결된 승인 레코드가 'pending' 상태로 생성된 시점을 기준으로 파악합니다. | ||
|
중요한 이유
이 시점부터 해당 승인에 대한 대기 시간이 시작됩니다. 이 시점과 해당하는 '승인 단계 승인/반려' 사이의 시간을 측정하면 승인 절차의 구체적인 병목을 찾을 수 있습니다.
확보 방법
요청서와 연결된 'approvals' 테이블에서 승인자의 작업 상태가 'pending' 또는 이에 해당하는 값인 레코드의 생성 타임스탬프를 기준으로 파악합니다.
기록
승인 절차에서 특정 승인자의 대기 중인 승인 레코드가 생성된 시각을 사용합니다.
이벤트 유형
inferred
|
|||
|
승인 단계에서 거부됨
|
워크플로의 해당 단계에서 승인자가 구매 요청을 거부합니다. 일반적으로 수정할 수 있도록 요청자에게 돌려보냅니다. Coupa에 기록되는 명시적 작업입니다. | ||
|
중요한 이유
어느 단계에서든 거부가 발생하면 재작업이 생기고 처리 시간이 늘어납니다. 거부가 발생한 단계와 원인을 분석하면 프로세스 개선과 사용자 교육에 도움이 됩니다.
확보 방법
'approvals' 테이블 또는 감사 추적에 기록된 명시적인 'reject' 작업을 기준으로 수집하며, 해당 구매 요청 및 승인자와 연결됩니다.
기록
구매 요청의 승인 이력에서 'reject' 이벤트를 필터링합니다.
이벤트 유형
explicit
|
|||
|
요청서 수정
|
요청서를 제출한 뒤 요청자나 권한이 있는 다른 사용자가 내용을 수정합니다. Coupa는 이를 새 버전이나 감사 기록으로 명시적으로 기록하며, 승인 워크플로의 일부 또는 전체가 다시 시작되는 경우가 많습니다. | ||
|
중요한 이유
수정 내역을 추적하면 프로세스의 재작업과 비효율을 파악할 수 있습니다. 수정이 잦다면 최초 요건이 명확하지 않거나 구매 정책이 복잡할 수 있으며, 이는 '요청서 수정률' KPI에 영향을 줍니다.
확보 방법
'requisition_headers' 테이블과 연결된 감사 이력 테이블에서 버전 변경이나 특정 'edit' 작업을 확인해 기록합니다.
기록
제출 후 요청서 이력 로그에서 명시적인 'edit' 또는 'update' 이벤트를 찾습니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 지금 Coupa 구매 요청부터 지급까지의 프로세스를 최적화해 보세요. 조달 과정의 유용한 인사이트를 확인하고 효율을 높일 수 있습니다.
Coupa 구매 요청 프로세스를 최적화하고 처리 시간을 단축하세요
비효율을 찾아 구매 요청 처리 시간을 30% 단축하세요.
신용카드가 필요하지 않습니다. 몇 분 만에 최적화를 시작할 수 있습니다.