주문-수금 판매 주문 처리 데이터 템플릿
주문-수금 판매 주문 처리 데이터 템플릿
주문부터 현금화까지, 판매 주문 처리에 사용할 일반적인 process mining 데이터 템플릿입니다. 더 구체적인 안내가 필요하면 시스템별 템플릿을 사용하세요.
특정 시스템 선택- 완전한 이벤트 로그를 구성하는 데 필요한 주요 데이터 속성을 안내합니다.
- 프로세스의 주요 활동과 마일스톤을 정리합니다.
- 어떤 시스템에도 맞게 조정할 수 있는 process mining의 범용 시작점입니다.
주문-수금 판매 주문 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 이벤트 시각 EventTime | 특정 활동이나 이벤트가 발생한 정확한 날짜와 시각입니다. | ||
| 설명 이벤트 시각은 활동이 발생한 정확한 순간을 기록하는 타임스탬프입니다. 판매 주문과 관련된 모든 이벤트를 시간순으로 정렬할 수 있도록 프로세스의 시간 정보를 제공합니다. 시간 기반 분석에는 이 속성이 필수입니다. 두 활동 사이의 처리 시간을 계산하고, 특정 단계에 걸린 시간을 파악하며, 지연이나 병목이 발생한 지점을 찾는 데 사용합니다. 예를 들어 ‘주문 이행 주기 시간’ KPI는 최종 배송 활동과 최초 주문 생성 활동의 이벤트 시각 차이로 계산합니다. ‘판매 주문 처리 시간 개요’ 대시보드도 이 속성을 기반으로 작동합니다. 중요한 이유 처리 시간과 소요 시간 등 성과 지표를 계산하는 데 필요한 타임스탬프로, 병목을 파악하는 데 중요합니다. 확보 방법 일반적으로 각 거래 또는 상태 변경 기록에 포함되며, 생성일, 변경일 또는 전기일로 표시됩니다. 예시 2023-03-15T09:30:00Z2023-04-01T14:05:10Z2023-04-10T11:00:00Z | |||
| 판매 주문 ID SalesOrderId | 판매 주문을 고유하게 식별하는 값으로, 주문부터 현금 회수까지 프로세스의 기본 케이스 식별자로 사용됩니다. | ||
| 설명 판매 주문 ID는 주문부터 종료까지 각 프로세스 인스턴스를 고유하게 식별하므로 주문부터 현금 회수까지 프로세스 마이닝의 기준이 됩니다. 관련된 모든 활동, 이벤트, 데이터 항목을 연결하는 기본 키로, 개별 주문의 전체 처리 과정을 구성합니다. 분석에서는 이 속성을 사용해 각 판매 주문의 생애주기를 재구성합니다. 이벤트 순서를 추적하고 활동 간 소요 시간을 측정하며 주문 단위로 지표를 집계할 수 있습니다. 예를 들어 ‘주문 이행 주기 시간’ KPI를 계산하려면 판매 주문 ID별로 활동을 묶고 첫 이벤트와 마지막 이벤트의 시간 차이를 구해야 합니다. 중요한 이유 개별 주문을 프로세스 전반에서 추적하는 데 필요한 ID입니다. 이를 통해 케이스별 처리 시간, 병목, 편차를 분석할 수 있습니다. 확보 방법 일반적으로 원본 ERP 또는 CRM 시스템의 판매 주문 문서 헤더 테이블에서 찾을 수 있습니다. 예시 SO-001234598004567ORD-2023-54321 | |||
| 활동 이름 ActivityName | 판매 주문 프로세스에서 특정 시점에 발생한 업무 이벤트 또는 작업의 이름입니다. | ||
| 설명 활동 이름은 ‘판매 주문 생성’, ‘신용 확인 수행’, ‘상품 배송’과 같이 판매 주문 생애주기의 단계나 주요 시점을 나타냅니다. 각 활동은 판매 주문에 수행된 개별 작업이며, 프로세스 맵을 구성하는 기본 요소입니다. 프로세스 흐름을 시각화하고 일반적인 경로를 파악하며 표준 절차에서 벗어난 사례를 찾으려면 이 속성을 분석해야 합니다. 활동 순서를 분석하면 병목, 재작업 반복(예: ‘판매 주문 변경’ 활동의 반복), 규정을 준수하지 않는 프로세스 변형을 찾아낼 수 있습니다. ‘프로세스 준수 및 편차’ 대시보드와 ‘판매 주문 재작업률’ KPI에도 이 속성이 필요합니다. 중요한 이유 프로세스의 단계를 정의하므로 프로세스 맵을 시각화하고 흐름을 분석하며 재작업이나 편차를 파악할 수 있습니다. 확보 방법 원본 시스템의 판매, 배송, 청구 모듈에서 문서 상태 변경, 이벤트 로그 또는 거래 코드로부터 가져오는 경우가 많습니다. 예시 판매 주문 생성상품 출고결제 수령판매 주문 취소 | |||
| 원본 시스템 SourceSystem | ERP, CRM 또는 레거시 플랫폼 등 데이터가 생성된 정보 시스템을 식별합니다. | ||
| 설명 원본 시스템 속성은 이벤트 데이터가 생성된 기록 시스템을 나타냅니다. 현대 기업의 주문부터 현금 회수까지 이어지는 프로세스는 여러 애플리케이션에 걸쳐 진행되는 경우가 많습니다. 예를 들어 주문 생성에는 CRM을, 이행과 송장 발행에는 ERP를 사용할 수 있습니다. 분석 시 이 속성을 활용하면 프로세스에 사용되는 시스템 환경을 파악할 수 있습니다. 시스템 간 연동 지점과 데이터 일관성 문제의 가능성을 확인하는 데 도움이 됩니다. 원본 시스템별로 활동을 분석하면 시스템에 따라 특정 단계의 처리 방식이 다르거나 지연이 더 자주 발생하는지 알 수 있습니다. 중요한 이유 데이터 출처를 파악할 수 있어 여러 시스템을 사용하는 환경에서 데이터 계보를 추적하고 시스템별 프로세스 차이를 찾는 데 유용합니다. 확보 방법 데이터 추출(ETL) 과정에서 추가하거나 데이터 웨어하우스의 표준 필드로 제공하는 경우가 많습니다. 예시 SAP S/4HANASalesforce Sales CloudOracle NetSuite | |||
| 최종 데이터 업데이트 LastDataUpdate | 원본 시스템에서 데이터를 마지막으로 새로 고치거나 추출한 시각입니다. | ||
| 설명 이 속성은 데이터가 프로세스 마이닝 환경에 마지막으로 적재된 시각을 나타냅니다. 분석에 사용되는 데이터의 최신성을 보여주며, 실제 업무 활동이 발생한 시각을 기록하는 이벤트 시각과는 다릅니다. 프로세스 흐름을 직접 분석할 때는 일반적으로 사용하지 않지만, 데이터 거버넌스와 분석 결과의 신뢰성을 확보하는 데 중요합니다. 분석가와 업무 사용자는 이를 통해 인사이트가 얼마나 최신인지 확인할 수 있습니다. 예를 들어 최종 데이터 업데이트가 일주일 전이라면 현재 성과에 대한 결론을 내릴 때 이 점을 고려해야 합니다. 중요한 이유 데이터의 최신성을 나타내므로 최신 정보를 바탕으로 분석하고 관련성 있는 결론을 내릴 수 있습니다. 확보 방법 일반적으로 데이터 수집 과정에서 데이터 추출(ETL) 도구나 프로세스 마이닝 플랫폼이 생성하고 저장합니다. 예시 2023-10-27T02:00:00Z2023-10-26T02:00:00Z2023-10-25T02:00:00Z | |||
| 고객 식별자 CustomerIdentifier | 판매 주문을 한 고객의 고유 식별자 또는 이름입니다. | ||
| 설명 이 속성은 판매 주문을 처리하는 대상인 외부 당사자를 식별합니다. 고유 고객 번호, 회사명 또는 고객을 구분하는 다른 키를 사용할 수 있습니다. process mining에서는 고객 식별자를 기준으로 데이터를 분류할 수 있습니다. 분석가는 프로세스 맵을 필터링해 특정 고객의 프로세스 흐름을 살펴보거나 주요 거래처와 일반 구매 고객 등 고객 그룹별 흐름을 비교할 수 있습니다. 이를 통해 맞춤형 프로세스를 파악하거나 프로세스 편차와 지연을 자주 일으키는 고객을 찾아 고객 관계 관리에 활용할 수 있습니다. 중요한 이유 고객이나 고객 그룹별로 프로세스를 필터링하고 비교하여 맞춤형 프로세스나 문제가 있는 거래처를 파악할 수 있습니다. 확보 방법 원본 ERP 또는 CRM 시스템의 판매 주문 헤더 데이터에서 찾을 수 있으며, 고객 마스터 데이터와 연결됩니다. 예시 CUST-10023Global Corp Inc.758991 | |||
| 사용자 이름 UserName | 활동을 수행한 사용자, 직원 또는 시스템 에이전트의 이름이나 ID입니다. | ||
| 설명 사용자 이름 속성은 특정 활동을 수행한 사람이나 자동화 에이전트를 식별합니다. 주문을 생성한 영업 담당자, 주문을 승인한 신용 관리자, 결제를 자동으로 전기한 시스템 사용자 등이 해당합니다. 이 속성을 활용하면 사람을 중심으로 프로세스를 분석할 수 있습니다. 업무량 분포를 살펴보고 팀이나 개인의 성과를 비교하며 교육이 필요한 부분을 찾을 수 있습니다. 규정 준수와 감사 추적에도 중요합니다. 사용자별 활동을 분석하면 재작업 반복이나 규정 미준수 행위에 관여한 주체를 파악할 수 있으며, ‘수동 개입률’ KPI를 계산하는 데도 필요합니다. 중요한 이유 활동을 수행한 사람이나 시스템을 식별하여 업무량, 팀 성과, 자동화 수준, 규정 준수를 분석할 수 있습니다. 확보 방법 일반적으로 거래 로그나 문서 변경 이력에서 찾을 수 있으며, ‘생성자’ 또는 ‘변경자’로 표시됩니다. 예시 John.SmithBATCH_USERAlice.JonesUSER_API | |||
| 제품 식별자 ProductIdentifier | 판매 주문의 주요 제품이나 서비스를 나타내는 고유 코드 또는 이름입니다. | ||
| 설명 자재 번호나 SKU와 같은 제품 식별자는 판매 대상 제품을 나타냅니다. 판매 주문에 여러 제품이 포함될 수 있지만, 이 속성은 주력 제품을 나타내거나 상위 수준 분석을 위해 제품 범주로 집계할 수 있습니다. 이 속성을 사용하면 주문부터 현금 회수까지의 프로세스를 제품 중심으로 살펴볼 수 있습니다. 특정 제품의 이행 시간이 더 길거나 배송 문제가 자주 발생하거나 취소율이 높은지 분석할 수 있습니다. 이러한 인사이트는 공급망 계획, 재고 관리, 제품 포트폴리오 전략에 유용합니다. 예를 들어 특정 제품군이 ‘창고 출고 승인’ 단계에서 계속 지연된다면 재고 수준이나 창고 내 배치를 조사할 수 있습니다. 중요한 이유 제품이나 제품 그룹별 프로세스 성과를 분석하여 제품별 병목이나 문제를 파악할 수 있습니다. 확보 방법 판매 주문의 품목 수준에서 찾을 수 있습니다. 케이스 단위 분석에서는 가장 중요한 품목이나 파생된 제품 범주로 나타낼 수 있습니다. 예시 PROD-5540-XLMAT-009871SVC-CONSULT-HR | |||
| 주문 금액 OrderValue | 일반적으로 문서 통화로 표시되는 판매 주문의 총 금액입니다. | ||
| 설명 주문 금액은 판매 주문의 총 재무 가치를 나타내며, 각 케이스의 규모를 수치로 보여주는 주요 재무 지표입니다. 가치 기준으로 프로세스를 분석할 때 유용합니다. 금액이 큰 주문에 집중해 문제의 우선순위를 정할 수 있습니다. 예를 들어 고액 주문이 저액 주문보다 처리 시간이 길거나 재작업이 많은지 조사할 수 있습니다. 특정 병목으로 지연된 주문의 총액처럼 프로세스 비효율의 재무적 영향을 계산하는 데도 사용합니다. 이를 통해 프로세스 개선의 필요성을 구체적으로 제시할 수 있습니다. 중요한 이유 가치 기준 분석을 통해 고액 주문에 우선순위를 두고 지연의 재무적 영향을 수치화하여 프로세스 개선의 우선순위를 정할 수 있습니다. 확보 방법 판매 주문 헤더 데이터에서 확인할 수 있으며, 일반적으로 모든 품목의 순액을 합산해 계산합니다. 예시 15200.50500.00125000.75 | |||
| 판매 채널 SalesChannel | 웹, 직접 판매, 파트너 등 판매 주문이 접수된 채널입니다. | ||
| 설명 판매 채널은 주문이 접수된 경로나 방식을 나타냅니다. 온라인 포털, 직접 판매팀, 파트너와의 EDI 연결 또는 소매점 등이 해당합니다. 판매 채널별로 프로세스를 분석하면 효율성과 규정 준수의 차이를 파악할 수 있습니다. 예를 들어 웹 채널 주문은 자동화 수준이 높고 빠르게 처리되는 반면, 직접 판매 주문은 수작업 변경이 많고 승인에 더 오래 걸릴 수 있습니다. 채널별 흐름을 최적화하고 리소스를 효율적으로 배분하는 데 도움이 됩니다. ‘주문 이행 병목’ 대시보드에서도 주요 분석 기준으로 활용할 수 있습니다. 중요한 이유 채널별 프로세스 성과를 비교해 효율성, 자동화 수준, 규정 준수의 차이를 파악할 수 있습니다. 확보 방법 일반적으로 판매 주문 헤더 데이터에 저장되며, 주문 입력 시 필수 항목인 경우가 많습니다. 예시 웹 포털직접 판매EDI파트너 네트워크 | |||
| 거부 사유 RejectionReason | 판매 주문 또는 품목이 취소되거나 거부된 이유를 설명하는 코드 또는 설명입니다. | ||
| 설명 판매 주문이 취소되거나 품목이 거부되면 거부 사유를 통해 이러한 결과가 발생한 업무상 배경을 파악할 수 있습니다. 사유에는 '고객 요청에 따른 취소', '가격 오류', '재고 부족' 등이 있습니다. 이 속성은 프로세스 실패의 근본 원인을 분석하는 데 필수적입니다. 거부 사유별 발생 빈도를 분석하면 조직 차원의 문제를 찾을 수 있습니다. 예를 들어 '가격 오류'로 취소된 주문이 많다면 견적 작성이나 기준 데이터 관리 프로세스에 문제가 있을 수 있습니다. 이러한 분석은 '최초 처리 성공률'을 높이고 프로세스 낭비를 줄이는 데 직접 도움이 됩니다. 중요한 이유 주문이 실패한 이유를 파악해 가격 책정, 재고 또는 고객 커뮤니케이션의 근본 문제를 분석하고 해결할 수 있습니다. 확보 방법 일반적으로 판매 주문 품목 수준에서 확인할 수 있으며, 품목 취소 시 사전 정의된 코드 목록에서 선택합니다. 예시 고객 요청제품 단종가격 오류신용 한도 초과 | |||
| 결제 기한 PaymentDueDate | 고객이 송장 대금을 결제해야 하는 날짜입니다. | ||
| 설명 결제 기한은 송장 날짜와 고객이 합의한 결제 조건을 기준으로 계산합니다. 제때 결제해야 하는 기한을 정하며 매출채권 프로세스의 주요 요소입니다. 주문부터 현금 회수까지 이어지는 주기의 재무 부분을 분석하는 데 필요한 속성입니다. ‘정시 결제율’ KPI에서 결제가 기한 내에 이루어졌는지 판단하는 기준으로 사용합니다. ‘송장 발행부터 결제까지의 주기’ 대시보드는 이 날짜를 바탕으로 결제 양상을 분석하고 운전자본을 관리합니다. 송장 생성부터 결제까지의 지연을 기한과 비교하면 결제가 늦은 고객을 파악할 수 있습니다. 중요한 이유 재무 분석에 중요하며, 정시 결제율을 계산하고 매출채권을 관리하는 기준이 됩니다. 확보 방법 일반적으로 고객 송장 문서에서 찾을 수 있으며, 송장 날짜와 고객 마스터 데이터 또는 판매 주문에 지정된 결제 조건을 기준으로 계산합니다. 예시 2023-12-152024-01-302024-02-28 | |||
| 실제 배송일 ActualDeliveryDate | 상품이 실제로 고객에게 배송된 날짜로, 프로세스의 이행 단계가 완료된 시점을 나타냅니다. | ||
| 설명 실제 배송일은 상품이 고객에게 성공적으로 배송된 시각을 기록합니다. 운송업체의 배송 증명을 기준으로 하는 경우가 많습니다. 이 속성은 이행 성공 여부를 판단하는 최종 기준입니다. 요청 배송일 및 확정 배송일과 비교해 ‘정시 배송률’을 계산하는 데 사용합니다. ‘상품 배송’ 활동부터 실제 배송일까지 걸린 시간을 분석하면 물류 파트너와 배송 방식의 성과도 파악할 수 있습니다. 중요한 이유 이행이 완료되었음을 보여주는 최종 증빙으로, 정시 배송률과 총 주문 이행 주기 시간을 정확히 계산하는 데 필요합니다. 확보 방법 외부 물류 또는 배송 시스템에서 가져와 ERP에 연동하는 경우가 많습니다. ‘상품 배송 완료’ 활동의 시각에서 가져올 수도 있습니다. 예시 2023-11-172023-12-022024-01-14 | |||
| 요청 배송일 RequestedDeliveryDate | 고객이 요청한 주문 배송일입니다. | ||
| 설명 이 날짜는 고객이 원하는 배송 일정을 나타냅니다. 프로세스 초기에 기록되는 중요한 정보이며, 배송 적시성에 대한 고객 만족도를 평가하는 기준이 됩니다. 프로세스 분석에서는 요청 배송일을 확정 배송일, 실제 배송일 등 주요 날짜와 비교해 서비스 수준을 측정합니다. ‘정시 배송 성과’ 대시보드의 주요 입력값이며, 고객 관점에서 배송이 제때 이루어졌는지 계산하는 데 사용합니다. 요청일과 확정일의 차이를 분석하면 계획 및 일정 수립 문제도 파악할 수 있습니다. 중요한 이유 고객의 배송 기대일을 나타내며, 정시 배송 성과와 고객 만족도를 측정하는 기준이 됩니다. 확보 방법 일반적으로 판매 주문 헤더나 품목 상세 정보에 있으며, 주문 생성 시 입력합니다. 예시 2023-11-152023-12-012024-01-10 | |||
| 자동화 여부 IsAutomated | 활동을 시스템이 자동으로 수행했는지 사용자가 수동으로 수행했는지 나타내는 플래그입니다. | ||
| 설명 이 불리언 속성은 사용자가 수행한 작업과 백그라운드 작업, API 또는 RPA 봇 등 시스템 자동화로 처리된 작업을 구분합니다. 예를 들어 신용 조회는 자동화 단계일 수 있지만, 신용 보류를 해제하는 작업은 일반적으로 수동으로 처리합니다. 자동화 관점에서 프로세스를 분석하는 일은 디지털 전환 과제에서 중요합니다. 이 플래그는 '수동 개입률' KPI를 계산하는 주요 데이터입니다. 이를 통해 프로세스에서 자동화 수준이 높은 부분과 여전히 수작업에 의존하는 부분을 파악할 수 있습니다. 분석 결과를 바탕으로 추가 자동화 기회를 찾아 비용과 오류를 줄이고 처리 시간을 단축할 수 있습니다. 중요한 이유 수동 작업과 자동화된 작업을 구분합니다. 자동화 수준을 측정하고 프로세스 개선 기회를 찾는 데 필요한 정보입니다. 확보 방법 '사용자 이름' 속성에서 확인할 수 있습니다. 예를 들어 'BATCH_USER'와 같은 시스템 사용자를 식별하거나, 이벤트 로그에서 실행 맥락을 기록하는 특정 필드를 활용할 수 있습니다. 예시 truefalse | |||
| 주문 상태 OrderStatus | 이벤트 발생 시점의 판매 주문 상태입니다. 예를 들어 ‘진행 전’, ‘처리 중’, ‘완료’ 등이 있습니다. | ||
| 설명 주문 상태는 특정 시점에 판매 주문이 생애주기의 어느 단계에 있는지 보여줍니다. 주문의 현재 상태를 요약하는 범주형 값입니다. 활동 순서가 상세한 프로세스 맵을 제공한다면, 주문 상태 속성은 프로세스를 간략하게 파악하는 데 유용합니다. 예를 들어 ‘신용 보류’ 상태인 모든 주문을 필터링할 수 있습니다. 상태별 체류 시간을 분석하면 ‘승인 대기’ 상태에 주문이 지나치게 오래 머무는 경우처럼 병목도 찾을 수 있습니다. 중요한 이유 주문 상태를 간략하게 보여주므로 필터링과 상태 분석에 활용하고 특정 단계에 머물러 있는 주문을 찾을 수 있습니다. 확보 방법 ERP 및 CRM 시스템의 대부분 판매 주문 문서 헤더에 있는 표준 필드입니다. 예시 진행 전진행 중신용 보류완료취소 | |||
| 확정 배송일 ConfirmedDeliveryDate | 회사가 고객에게 확정하고 약속한 배송일입니다. | ||
| 설명 재고와 생산 일정을 확인한 후 회사가 확정 배송일을 안내합니다. 이는 고객에 대한 회사의 약속이며, 이행 성과를 측정하는 내부 기준입니다. 내부 운영 효율을 평가하는 데 중요한 속성입니다. ‘정시 배송률’ KPI에서 실제 배송일과 비교해 회사가 약속을 지켰는지 판단합니다. 여러 주문에서 요청 배송일과 확정 배송일의 차이가 크게 나타나면 ATP 계산이나 생산 능력 계획에 구조적인 문제가 있을 수 있습니다. 중요한 이유 고객에 대한 회사의 약속을 나타내며, 정시 배송과 이행 신뢰도를 측정하는 내부 기준이 됩니다. 확보 방법 판매 주문의 일정 라인 데이터에서 찾을 수 있으며, 가용성 확인이나 생산 계획 실행 후 업데이트되는 경우가 많습니다. 예시 2023-11-182023-12-012024-01-15 | |||
주문-수금 판매 주문 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 결제 수령 | 고객의 송장 대금이 수령되어 처리되고 해당 송장에 반영된 활동입니다. 일반적으로 매출채권 모듈에서 발생하며 미결 재무 항목을 정산합니다. | ||
| 중요한 이유 가치를 실현하는 마지막 단계입니다. 송장 발행부터 결제까지 걸리는 시간은 매출채권 회전일수와 현금 전환 주기 효율을 분석하는 데 중요합니다. 확보 방법 매출채권 문서의 반제일이나 결제 적용 기록의 생성 시각에서 가져오는 명시적 재무 전기 이벤트입니다. 기록 미결 송장 금액을 정산하는 재무 문서의 전기일 또는 반제일을 사용합니다. 이벤트 유형 explicit | |||
| 상품 출고 | 이 중요한 이벤트는 포장된 주문 상품이 창고에서 출고되어 실제로 창고를 떠난 시점을 나타냅니다. 물류와 재무 측면에서 중요한 단계이며, 이 시점에 송장 발행이 시작되는 경우가 많습니다. | ||
| 중요한 이유 정시 배송 성과와 주문 이행 주기를 측정하는 주요 단계입니다. 주문 생성부터 출고까지 걸리는 시간은 주요 성과 지표입니다. 확보 방법 일반적으로 배송 또는 물류 모듈에 명시적 이벤트로 기록되며, 'Post Goods Issue' 또는 'Ship Confirmation'이라고 표시되는 경우가 많습니다. 기록 일반적으로 배송 또는 이행 문서에 저장되는 출고 확인이나 상품 출고 거래의 타임스탬프를 사용합니다. 이벤트 유형 explicit | |||
| 송장 생성 | 이 활동은 배송된 상품이나 서비스에 대한 고객 송장을 생성하는 단계입니다. 고객의 채무를 공식적으로 기록하고 결제 절차를 시작하는 주요 재무 거래입니다. | ||
| 중요한 이유 배송부터 송장 발행까지 걸리는 시간은 ‘청구 후 현금 회수’ 지연으로, 현금 흐름에 직접 영향을 줍니다. 이를 분석하면 청구 절차의 지연을 파악할 수 있습니다. 확보 방법 재무 모듈에서 송장 또는 청구 문서가 생성된 시각을 기록한 명시적 이벤트입니다. 기록 매출채권 또는 청구 테이블에 기록된 송장 문서의 생성 날짜와 시각을 사용합니다. 이벤트 유형 explicit | |||
| 판매 주문 생성 | 이 작업은 시스템에서 판매 주문을 처음 생성하는 단계입니다. 고객이 상품이나 서비스를 요청한 내용을 공식적으로 등록하며 Order to Cash 프로세스의 시작점이 됩니다. | ||
| 중요한 이유 이 이벤트는 일반적으로 프로세스의 시작을 나타냅니다. 이 시점부터 걸리는 시간을 분석하면 전체 주문 이행 주기와 초기 데이터 입력의 효율성을 측정할 수 있습니다. 확보 방법 일반적으로 판매 주문 헤더 레코드의 생성 타임스탬프나 관련 거래 로그에서 이 이벤트를 확인할 수 있습니다. 기록 시스템의 주문 헤더 테이블이나 문서에서 새 판매 주문 ID가 생성된 시점의 첫 타임스탬프를 확인합니다. 이벤트 유형 explicit | |||
| 판매 주문 승인 | 이 단계는 판매 주문이 신용 및 구성 검토 등 필요한 내부 확인을 모두 통과해 이행이 공식적으로 확정되었음을 나타냅니다. 명시적인 승인 작업이나 상태 변경으로 기록되는 경우가 많습니다. | ||
| 중요한 이유 이 단계는 주문 이행을 시작하기 위한 주요 통제 지점입니다. 승인까지 걸리는 시간을 분석하면 주문 검증 및 검토 과정의 지연을 찾을 수 있습니다. 확보 방법 판매 주문 상태 필드나 워크플로 기록에 'Approved', 'Confirmed', 'Booked'와 같은 상태로 기록되는 경우가 많습니다. 기록 판매 주문 상태가 'Approved' 또는 'Booked'처럼 이행 준비가 완료되었음을 나타내는 상태로 변경된 시점의 타임스탬프를 확인합니다. 이벤트 유형 inferred | |||
| 판매 주문 종료 | 성공적으로 처리된 주문의 마지막 활동으로, 주문의 배송, 송장 발행, 결제가 모두 완료되었음을 나타냅니다. 이 상태가 되면 해당 판매 주문에 추가 거래가 발생하지 않습니다. | ||
| 중요한 이유 이 활동은 프로세스가 성공적으로 완료되었음을 나타냅니다. 주문 생성부터 종료까지의 총 시간은 완벽한 주문의 전체 처리 시간을 의미합니다. 확보 방법 일반적으로 모든 하위 거래가 완료된 후 판매 주문 헤더의 최종 상태가 ‘종료’ 또는 ‘완료’로 변경된 것을 기준으로 판단합니다. 기록 판매 주문 헤더의 전체 상태가 최종 완료 상태로 변경된 시각을 확인합니다. 이벤트 유형 inferred | |||
| 판매 주문 취소 | 판매 주문이 배송 및 송장 발행을 모두 마치기 전에 취소된 이벤트입니다. 프로세스의 여러 단계에서 발생할 수 있는 실패 종료를 나타냅니다. | ||
| 중요한 이유 중요한 실패 결과입니다. 주문이 취소된 시점과 사유를 분석하면 고객 만족도, 재고 가용성 또는 데이터 입력 오류와 관련된 문제를 찾을 수 있습니다. 확보 방법 일반적으로 판매 주문 헤더나 품목에 적용된 ‘취소’ 또는 ‘거부’ 상태로 기록됩니다. 기록 취소 사유가 입력되거나 최종 ‘취소’ 상태가 판매 주문 문서에 적용된 시각을 수집합니다. 이벤트 유형 inferred | |||
| 고객에게 송장 발송 | 생성된 송장을 고객에게 결제 요청 목적으로 전송하는 시점을 나타냅니다. 이메일, 전자 데이터 교환 또는 우편 등 다양한 채널을 통해 발송할 수 있습니다. | ||
| 중요한 이유 이 시점부터 고객의 결제 기한이 시작됩니다. 송장 생성 후 발송까지 지연되면 현금 전환 주기에 부정적인 영향을 줄 수 있습니다. 확보 방법 출력 관리 로그, 커뮤니케이션 기록 또는 송장 문서의 특정 상태 변경에서 가져옵니다. 기록 송장 문서가 성공적으로 전송되었음을 나타내는 시스템 출력 로그의 시각을 수집합니다. 이벤트 유형 inferred | |||
| 대변 메모 생성 | 상품 반품, 가격 분쟁 또는 기타 조정으로 고객에게 대변 메모를 발행할 때 발생하는 활동입니다. 이전에 청구한 금액을 취소하거나 줄이는 것을 나타냅니다. | ||
| 중요한 이유 대변 메모의 발생 빈도와 사유를 분석하면 제품 품질, 배송 정확도 또는 가격 오류와 관련된 구조적 문제를 파악할 수 있습니다. 프로세스 실패를 보여주는 주요 지표입니다. 확보 방법 청구 또는 매출채권 모듈에서 대변 메모 문서가 생성된 시각을 기록한 명시적 재무 이벤트입니다. 기록 대변 메모 문서의 생성 날짜와 시각을 사용합니다. 일반적으로 원래 판매 주문이나 송장과 연결되어 있습니다. 이벤트 유형 explicit | |||
| 상품 배송 완료 | 이 작업은 상품이 고객이 지정한 주소로 정상 배송되었음을 나타냅니다. 외부 물류 업체에서 받은 데이터로 업데이트하거나 담당자가 직접 배송을 확인해 기록하는 경우가 많습니다. | ||
| 중요한 이유 배송을 추적하면 고객 경험을 전체적으로 파악하고 주문 이행에 걸리는 총 시간을 정확히 측정할 수 있습니다. 확보 방법 일반적으로 외부 운송업체 데이터를 핵심 시스템에 연동하거나, 배송 증명 확인 기록에서 가져옵니다. 기록 운송업체가 제공한 배송 확인 시각이나 수기로 입력한 배송 증명 기록의 시각을 수집합니다. 이벤트 유형 explicit | |||
| 상품 포장 | 이 작업은 피킹한 상품을 모아 포장하고 배송 준비를 마치는 단계입니다. 포장 명세서를 생성하고 최종 배송 정보를 확정하는 과정이 포함될 수 있습니다. | ||
| 중요한 이유 피킹부터 포장까지 걸리는 시간을 분석하면 작업 공간 배치와 포장 절차를 개선할 수 있습니다. 배송 전에 주문 내용이 정확한지 확인하는 중요한 단계입니다. 확보 방법 WMS의 별도 상태로 기록하거나 포장 명세서 문서의 생성 시간으로 확인할 수 있습니다. 기록 이행 문서의 상태가 'Packed'로 변경된 시점의 타임스탬프를 확인하거나 포장 명세서의 생성 타임스탬프를 사용합니다. 이벤트 유형 inferred | |||
| 상품 피킹 | 이 작업은 창고 보관 위치에서 주문에 필요한 모든 상품을 실제로 피킹하는 단계가 완료되었음을 나타냅니다. 창고 작업자가 피킹 완료를 확인할 때 기록되는 경우가 많습니다. | ||
| 중요한 이유 피킹 소요 시간을 측정하면 창고 효율성을 분석하고 실제 주문 이행 과정의 병목을 찾을 수 있습니다. 확보 방법 일반적으로 창고 관리 시스템(WMS)에 기록되거나 배송 또는 이행 문서의 상태 업데이트를 통해 확인합니다. 기록 관련 피킹 목록이나 이행 문서의 상태가 'Picked' 또는 'Completed'로 업데이트된 시점의 타임스탬프를 기록합니다. 이벤트 유형 inferred | |||
| 신용 조회 수행 | 이 작업은 주문과 연결된 고객의 신용도를 확인했음을 나타냅니다. 시스템에서 자동으로 확인하거나 담당자가 직접 검토할 수 있으며, 대개 주문의 신용 상태가 업데이트됩니다. | ||
| 중요한 이유 이 단계는 흔히 병목이 발생하는 지점입니다. 소요 시간과 결과를 측정하면 신용 관리의 효율성과 전체 주문 처리 주기에 미치는 영향을 분석할 수 있습니다. 확보 방법 판매 주문 상태 변경, 신용 보류 해제 또는 특정 신용 관리 로그의 기록을 통해 확인하는 경우가 많습니다. 기록 주문의 신용 상태 필드가 'Approved' 또는 'Checked'로 업데이트되거나 신용 관련 보류가 해제된 시점의 타임스탬프를 기록합니다. 이벤트 유형 inferred | |||
| 재고 예약 | 이 작업은 판매 주문 품목에 필요한 재고를 할당하거나 예약하는 시점을 나타냅니다. 해당 품목을 특정 주문에 확보해 다른 주문에 판매되지 않도록 합니다. | ||
| 중요한 이유 재고 예약을 추적하면 자재 가용성과 재고 부족으로 인한 잠재적 지연을 분석할 수 있습니다. 주문 승인부터 재고 예약까지 걸리는 시간을 보면 조달 문제를 파악할 수 있습니다. 확보 방법 재고 거래 테이블에 기록되는 자동 시스템 이벤트인 경우가 많으며, 판매 주문 품목의 상태 변경으로 확인할 수도 있습니다. 기록 특정 판매 주문 품목에 재고가 할당된 시점에 해당하는 재고 거래 로그의 타임스탬프를 기록합니다. 이벤트 유형 explicit | |||
| 창고로 전달 | 이 작업은 판매 주문을 창고에 공식적으로 전달해 실제 처리를 시작하는 단계입니다. 창고 팀이 피킹과 포장을 시작하는 계기가 됩니다. | ||
| 중요한 이유 이 단계는 부서 간 인수인계가 이루어지는 중요한 지점입니다. 처리 시간을 분석하면 영업과 물류 간 소통의 병목을 찾을 수 있습니다. 확보 방법 피킹 목록이 생성되거나 주문 상태가 'Ready to Pick' 또는 'Released'로 변경될 때 기록되는 경우가 많습니다. 기록 판매 주문 품목의 상태가 창고 처리 준비가 완료되었음을 나타내는 상태로 변경된 시점의 타임스탬프를 확인합니다. 이벤트 유형 inferred | |||
| 판매 주문 변경 | 이 작업은 판매 주문을 처음 생성한 뒤 수량, 품목, 가격, 요청일 등을 변경하는 모든 주요 수정 사항을 나타냅니다. 일반적으로 시스템 감사 추적이나 변경 로그의 업데이트 내역을 추적해 확인합니다. | ||
| 중요한 이유 주문 변경을 추적하면 프로세스 재작업을 파악하고 비효율의 원인을 이해하며 첫 처리 정확도를 측정할 수 있습니다. 변경이 잦다면 최초 주문 정보의 정확성에 문제가 있을 수 있습니다. 확보 방법 시스템 변경 로그 테이블이나 감사 추적에서 가져오거나 판매 주문 문서의 여러 버전을 비교해 확인합니다. 기록 시스템 변경 로그에서 판매 주문 헤더나 품목의 주요 필드가 업데이트된 내역을 필터링하고, 변경 타임스탬프를 이벤트 시간으로 사용합니다. 이벤트 유형 explicit | |||
데이터 추출 가이드
추출 방법은 시스템마다 다릅니다. 자세한 안내는
ETL 가이드 를 확인하거나 특정 프로세스와 시스템을 선택하세요.
시작할 준비가 되셨나요?
시스템별 가이드를 따르거나 이 범용 템플릿을 환경에 맞게 조정해 주문-수금 판매 주문 처리를 최적화할 수 있습니다.
지금 판매 주문 처리를 최적화하세요
즉시 인사이트를 얻고 지연을 줄여 현금 흐름을 개선하세요.
신용카드 없이 몇 분 만에 설정할 수 있습니다.