[EWM BASIC] WPT Performance Issue

성능 및 모니터링 (Performance and Monitoring)

창고 프로세스 유형(Warehouse Process Types)에 대해 이야기할 때, 우리는 주로 그것들이 어떻게 결정되고, 어떻게 창고 프로세스를 다양한 방식으로 운영할 수 있는 가능성을 제공하는지에 대해 많이 논의합니다.

그러나 특정 제품 유형이나 문서 유형에 대해 다른 요구사항이 없더라도,

여전히 다양한 창고 프로세스 유형을 커스터마이징하는 것이 의미가 있을 수 있습니다.

그 이유 중 하나는 성능 측면입니다.

 

다음 예시를 살펴보시기 바랍니다.

약 12,000개의 창고 작업을 표시하는 것이 얼마나 빠르게 이루어졌는지 보셨나요?

이는 창고 작업을 위한 데이터베이스가 창고 프로세스 유형을 통해 선택하는 것이 최적화되어 있기 때문입니다.

이렇게 높은 속도로 결과를 얻는 것은 작업을 훨씬 더 효율적이고 즐겁게 만듭니다.

예를 들어, 재고 제거 프로세스(Stock Removal Process)를 위해 하나의 창고 프로세스 유형만으로 창고를 운영해야 한다면, 추가적인 선택 필드나 필터 등을 사용해야 할 것이며, 이는 작업 속도를 더 빠르게 하지는 못할 것입니다.

 

---

생각 없이 커스터마이징하거나 코딩하지 마세요 (Think Twice Before You Customize or Code)

이 말은 당연하고 쉽게 이해할 수 있는 것처럼 들리지만, 실제로는 그렇지 않을 때가 많습니다.

예를 들어, 제가 외부 컨설턴트로 지원해야 했던 EWM 시스템을 운영하는 한 창고의 사례를 소개하겠습니다.

이 시스템은 회사 웹사이트와 외부 파트너로부터의 전자상거래 주문을 처리하도록 운영되었습니다.

그러나 제가 이 EWM 구현을 "EWM 창고를 잘못 운영하는 방법"이라고 부르는 이유를 설명해드리겠습니다.

 

앞서 언급했듯이, 이 시스템은 여러 다른 파티의 주문을 처리하도록 설정되었습니다.

하지만 이러한 주문의 구분은 예상할 수 있는 문서 유형(Document Type)으로 이루어진 것이 아니라,

문서 헤더 수준에서 고객 확장 필드(C Header Extension)로만 정보를 보유하고 있었습니다.

(고객별로 다른 문서 유형이 아니라 같은 Doc type, 고객 구분은 Customer Header Extension으로만 구분

- 스탠다드는 다른 파티를 구분할 방법이 없음 - )

문제는 여기서 끝나지 않았습니다. SAP 스탠다드 상으로는 모든 Order가 같은 Party에서 온 것처럼보이며, 

오직 z필드인 헤더 수준의 C 필드만이 차이를 나타냅니다

이것이 첫 번째 실수였습니다.

첫번째 실수

교훈 1 : 파티 별 DOC TYPE을 나누자

보통의 EWM 구현에서는 각 주문 유형에 대해 별도의 창고 프로세스 유형(Warehouse Process Type)을 제공하여

창고 작업(Warehouse Task)과 창고 주문(Warehouse Orders)을 분리합니다.

(즉 창고 작업을 위한 WPT와, 창고 주문을 위한 WPT가 있음)

하지만 이 창고처럼 창고 작업 수준에서도 분리가 이루어지지 않으면,

창고 모니터링 및 적절한 KPI(핵심 성과 지표) 프레젠테이션을 제공하기가 매우 어려워집니다.

예를 들어, 각 관련된 파티에 대해 몇 개의 피킹 작업이 있는지,

그리고 그중 몇 개가 오늘 처리되어야 하는지를 파악해야 한다고 상상해 보십시오.

이것을 Order 헤더 수준의 C 확장 필드만으로 수행하는 것은 매우 어렵습니다.

이것이 두 번째 실수였습니다.

두번째 실수 - 이렇게 안한거

교훈 2 : 스탠다드 상으로 구분을 못하면, WT, WO 선택에도 영향을 미치게 된다.

 

보통은 창고 모니터로 이동하여,

예를 들어 창고 프로세스 유형 4711을 사용하여 파티 A 또는 파티 B의 작업 부하를 표시할 수 있습니다.

그러나 이 시스템에서는 C 헤더 확장 필드로만 구분이 이루어졌기 때문에,

작업 부하를 표시하려면 모든 열린 창고 작업을 선택하고,

해당하는 delivery header를 선택한 후, 각 파티별로 합계를 필터링해야 합니다.

이는 가장 빠른 방법이 아닙니다. 솔직히 말해서, 아무리 뛰어난 ABAP 프로그래머라 하더라도 이러한 방식이 빠를 수는 없습니다.

 

이 예시에서 전달하고자 하는 메시지는, 구현하기 전에 신중히 생각하라는 것입니다.

위에서 언급한 모든 문제는 단순히 별도의 문서 유형과 별도의 창고 프로세스 유형을 커스터마이징함으로써 쉽게 피할 수 있었습니다.

이렇게 하면 창고를 운영하고 모니터링하는 더 나은 방법을 확보할 수 있었을 것입니다.