SAP 재작업 원가 점검 — 재작업률 · 표준 대비 차이 · 복귀율을 오더 한 줄에서 확인하는 제조원가 점검 화면

도입 포인트 — 이 앱을 사용해야 하는 이유

재작업은 원가 회의에서 가장 설명하기 어려운 비용입니다. 얼마나 났는가, 표준보다 많은가, 무엇이 키웠는가. 이 세 답은 오더 조회 · 차이 분석 · 개별 항목에 흩어져 있고, 재작업만 따로 모은 숫자는 대개 엑셀 안에만 있습니다. 이 앱은 세 답을 오더 한 줄에 붙이고, 그 합계가 어디서 왔는지 같은 화면에서 내려가 확인하게 합니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 합계는 괜찮은데 오더는 그렇지 않았다

이 사례에서 재작업 원가는 47,696,087원으로 표준 재작업 원가 50,054,100원보다 2,358,013원 적었습니다. 합계만 보면 문제가 없습니다. 그런데 오더로 내려가면 이야기가 달라집니다. 판정 기준에 걸린 오더가 15건 나옵니다 — 재작업 수량이 있는데 원가가 집계되지 않은 오더 3건, 재작업률이 한도를 넘은 오더 5건, 표준에서 25% 넘게 벗어난 오더 4건, 복귀율이 모자란 오더 3건입니다. 합계에서는 표준을 밑도는 오더와 넘는 오더가 서로 상쇄되어 보이지 않았을 뿐입니다.

월별로도 비슷합니다. 1~3월은 점검 필요 오더가 두 건씩이었는데 4월부터 세 건씩으로 늘었고, 5월 재작업률은 4.14% 로 가장 높았습니다. 원인별로는 치수 불량이 전체 재작업 원가의 23.5% 로 가장 크고 조립 불량이 19.6% 로 뒤를 잇습니다. 총액이 아니라 어디를 먼저 볼지가 정해집니다.

도입하면 달라지는 것

• 원가 점검 준비 — 재작업 원가를 개별 항목에서 건건이 모아 엑셀에 붙이는 일이 줄어듭니다.
• 회의의 주제 — “재작업이 늘었다”에서 “어느 원인의 어느 오더가 키웠나”로 넘어갑니다.
• 빠진 원가의 발견 — 수량은 있는데 원가가 0 인 오더를 정산 전에 잡습니다.
• 기준의 공유 — 판정 기준과 순서가 화면에 적혀 있어 담당자가 바뀌어도 같은 기준으로 봅니다.

이런 회사에 맞습니다

생산오더 기반으로 제조원가를 관리하면서 재작업 · 폐기 비용을 엑셀로 따로 모으고 있는 회사, 표준 원가 차이는 보지만 재작업 몫을 떼어 설명하기 어려운 원가팀, 그리고 원가 점검 기준을 사람 머릿속이 아니라 화면에 적어 두고 싶은 관리회계 조직에 맞습니다. 법정 보고나 공시 숫자를 만드는 화면은 아닙니다.

숫자를 믿을 수 있는가 — 검증 결과

점검 도구가 틀린 숫자를 내놓으면 쓸 수 없습니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸습니다. 아래는 이 사례 데이터의 결과입니다.

열 가지 대사식이 모두 차이 0 입니다. 점검 화면이므로 판정 기준에 걸리는 건은 일부러 넣었고 이것은 대사 차이와 별도입니다. 화면 쪽은 브라우저 자동화로 따로 돌려 요약의 재작업 원가와 재작업률이 검증 스크립트 결과와 같은지 확인했습니다.

도입 후 쓰는 순서

1. 회계연도를 확인하고 조회를 누릅니다. 필요하면 전기 월 범위 · 제품 · 원인 · 점검 결과로 좁힙니다.
2. 요약에서 재작업 원가 · 표준 대비 차이 · 재작업률과 점검 필요 건수를 봅니다.
3. 점검 결과를 점검 필요로 바꿔 판정에 걸린 오더만 남깁니다.
4. 오더 행을 눌러 재작업 원가가 어떻게 모였는지, 어느 공정이 키웠는지 봅니다.
5. 원인별 · 월별 탭에서 쏠림과 추이를 확인합니다.
6. 대사 결과가 모두 0 인지 확인한 뒤, 의심되는 오더는 표준 T-code 로 가서 확인합니다.

실행 화면

실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 자료는 가상의 검증용 데이터입니다.

화면을 열면 한 번 자동으로 조회됩니다. 재작업률은 오더별 비율을 평균내지 않고 재작업 수량 합계를 투입 수량 합계로 나누어 다시 계산합니다. 수량이 큰 오더가 비율을 더 크게 끄는 것이 현장의 감각과 맞기 때문입니다.

판정은 위에서 아래 순서로 먼저 걸리는 한 가지로 정해집니다. 결과 글자는 원인을 단정하지 않고 점검 필요 · 확인 필요로만 적습니다. 판단은 사람이 합니다.

합계가 맞는지 의심될 때 표를 닫지 않고 그 자리에서 확인하라고 만든 창입니다. 위쪽 세 값을 더하면 재작업 원가가 되고, 아래쪽 공정 원가를 더해도 같은 값이 나와야 합니다.

재작업은 공정을 한 번 더 도는 일이라 원가의 실체가 공정 단위에 있습니다. 오더 한 줄이 너무 크게 보일 때 어느 공정이 키웠는지를 여기서 찾습니다.

재작업을 줄이는 일은 결국 원인을 줄이는 일입니다. 월 총액만 보면 늘었다는 사실밖에 모르지만, 원인별로 나누면 어느 불량이 키웠는지가 보입니다.

이 사례에서는 1~3월이 재작업률 3% 초반이다가 4월부터 점검 필요 오더가 세 건씩 나오고, 5월에는 4.14% 로 가장 높았습니다. 흐름을 보는 자리입니다.

점검 도구가 틀린 숫자를 내놓으면 쓸 수 없습니다. 그래서 대사 결과를 화면 안에 두었고, 차이 건수가 0 이 아니면 요약에 먼저 올라옵니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 화면을 없애야 하느냐”는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다. 대사와 감사 대응은 표준 거래가 맡는 편이 안전합니다.

분석 지표 정의

관련 기준서는 없고 대상 영역은 제조원가입니다. 아래 한도는 화면의 기본값이며 회사 정책에 맞게 조정해 쓰는 것을 전제로 합니다.

화면이 부르는 OData 구성

화면은 OData V2 서비스만 바라봅니다. 엔티티셋은 OrderSet(오더) · OpSet(재작업 공정) · CauseSet(원인별) · MonthSet(월별) · ReconSet(대사) 다섯 개이고, 펑션 GetReworkRate 가 월별 재작업률을 돌려줍니다. 서비스 주소는 manifest 의 상대 경로로 선언되어 실제 서비스로 바꾸면 화면은 그대로 동작합니다.

CDS 구성

이 사례의 화면은 오더 84건을 서비스가 한 번에 내려줍니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일이 집계를 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 원가요소 그룹 매핑 테이블

재작업 원가를 재료 · 노무 · 기계 및 간접비로 가르는 기준이 이 표에서 정해집니다. 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 원가요소 체계가 바뀌어도 지난 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZRWK_COSTELEM — 원가요소 → 재작업 원가 그룹 (투명 테이블)
"  그룹 : M 재료 · L 노무 · H 기계 및 간접비
"  코드에 박지 않는 이유 : 원가요소는 늘어나고, 늘 때마다
"  개발자를 부르게 하면 점검 화면이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '재작업 원가요소 그룹'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zrwk_costelem {
  key mandt    : mandt not null;
  key ktopl    : ktopl not null;         " 계정과목표
  key kstar    : kstar not null;         " 원가요소
  cost_grp     : abap.char(1);           " M · L · H
  valid_from   : abap.dats;
  valid_to     : abap.dats;
}

② 표준 재작업 단가와 기준값 테이블

표준 단가를 어디서 가져올지는 회사마다 다릅니다. 이 스케치는 별도 테이블에 두었지만, 표준 원가 추정이나 작업 계획에서 읽는 구성도 가능합니다. 기준값을 한 곳에 둔 이유는 한도를 바꿀 때 화면을 고치지 않기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZRWK_STDRATE — 제품별 표준 재작업 단가 / 판정 기준값
"  표준 단가의 원천(표준 원가 추정 · 작업 계획 · 별도 관리)은
"  고객사마다 달라 구현 전에 확인해야 한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '표준 재작업 단가'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zrwk_stdrate {
  key mandt    : mandt not null;
  key werks    : werks_d not null;        " 플랜트
  key matnr    : matnr not null;          " 제품
  std_rate     : abap.curr(15,2);         " 재작업 1개당 표준 원가
  waers        : waers;
  lim_rate     : abap.dec(5,2);           " 재작업률 한도(%)   기본 6.00
  lim_var      : abap.dec(5,2);           " 차이율 한도(%)     기본 25.00
  lim_rec      : abap.dec(5,2);           " 복귀율 하한(%)     기본 80.00
  valid_from   : abap.dats;
  valid_to     : abap.dats;
}

③ 확인 실적 집계 뷰

수량과 시간의 원천입니다. 재작업 · 폐기 수량이 어느 필드에 담기는지는 대상 시스템에서 확인이 필요합니다. 아래는 원천 테이블 기준 스케치이며, 표준 CDS 뷰 이름은 확인하지 못해 쓰지 않았습니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '재작업 확인 실적 집계'
define view entity ZI_RwkConfirm
  as select from afru as conf
    inner join   afko as hdr on hdr.aufnr = conf.aufnr
{
  key conf.aufnr                         as Aufnr,
  key conf.vornr                         as Vornr,
      hdr.gamng                          as PlanQty,
      sum( conf.lmnga )                  as YieldQty,     " 양품 — 확인 필요
      sum( conf.rmnga )                  as ReworkQty,    " 재작업 — 확인 필요
      sum( conf.xmnga )                  as ScrapQty,     " 폐기
      sum( conf.ismnw )                  as ActHours      " 실적 시간 — 필드 확인 필요
}
where conf.stokz = ''                    " 취소 확인 제외
  and conf.vernr = ''
group by conf.aufnr, conf.vornr, hdr.gamng

④ 재작업 원가 집계 뷰

원가 금액은 개별 항목에서 읽어 원가요소 그룹으로 가릅니다. 오더 단위로 먼저 합산해 두면 화면의 합계가 서로 어긋나지 않습니다. 그룹 매핑이 없는 원가요소는 기타로 따로 세워 숫자가 조용히 사라지지 않게 합니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '재작업 원가 집계'
define view entity ZI_RwkCost
  as select from coep as e
    left outer join zrwk_costelem as g
      on  g.kstar = e.kstar
  association [1..1] to aufk as _ord on _ord.objnr = e.objnr
{
  key _ord.aufnr                                  as Aufnr,
      sum( case g.cost_grp when 'M' then e.wkgbtr else 0 end ) as ReworkMat,
      sum( case g.cost_grp when 'L' then e.wkgbtr else 0 end ) as ReworkLabor,
      sum( case g.cost_grp when 'H' then e.wkgbtr else 0 end ) as ReworkMach,
      sum( case when g.cost_grp is null
                then e.wkgbtr else 0 end )        as Unmapped   " 매핑 없는 금액
}
where e.wrttp = '04'                              " 실제 — 값 유형은 확인 필요
group by _ord.aufnr

⑤ 오더 판정 뷰

화면의 OrderSet 에 해당하는 뷰입니다. 판정 순서는 원가 미집계 → 재작업률 → 표준 대비 차이 → 복귀율이고, 먼저 걸리는 하나로 정합니다. 결과 글자는 원인을 단정하지 않고 점검 필요 · 확인 필요로만 둡니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '재작업 오더 점검'
define view entity ZI_RwkOrder
  as select from ZI_RwkConfirm as c
    inner join   ZI_RwkCost    as k on k.Aufnr = c.Aufnr
{
  key c.Aufnr,
      c.ReworkQty,
      ( k.ReworkMat + k.ReworkLabor + k.ReworkMach )           as ReworkCost,
      case when c.ReworkQty > 0
            and ( k.ReworkMat + k.ReworkLabor + k.ReworkMach ) = 0 then 'R20'
           when cast( c.ReworkQty as abap.dec(15,4) )
                / ( c.YieldQty + c.ReworkQty + c.ScrapQty ) > 0.06   then 'R10'
           else 'I00'
      end                                                      as CheckCode
      " R30(차이율) · R40(복귀율) 은 표준 단가를 join 한 뒤 같은 방식으로 이어 붙인다
}

⑥ 원인별 · 월별 집계 뷰

비율은 오더 비율을 평균내지 않고 합계에서 다시 계산합니다. 그래야 월 합계가 오더 합계와 어긋나지 않습니다. 원인 코드 체계는 회사마다 달라 확인이 필요합니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '재작업 월별 집계'
define view entity ZI_RwkMonth
  as select from ZI_RwkOrder as o
{
  key o.Gjahr,
  key o.Period,
      count( * )                                         as OrderCnt,
      sum( o.InputQty )                                  as InputQty,
      sum( o.ReworkQty )                                 as ReworkQty,
      sum( o.ReworkCost )                                as ReworkCost,
      " 비율은 합계에서 다시 계산한다 — 오더 비율의 평균이 아니다
      division( sum( o.ReworkQty ) * 100, sum( o.InputQty ), 2 ) as ReworkRate,
      sum( case when o.CheckStatus = 'CHECK' then 1 else 0 end ) as NeedCnt
}
group by o.Gjahr, o.Period

⑦ 권한 객체 (DCL)

권한은 집계를 읽는 자리에 겁니다. 상세에만 걸면 합계와 상세의 차이로 남의 숫자를 뺄셈으로 알아낼 수 있습니다. 어떤 권한 객체와 필드를 쓸지는 보안 담당과 먼저 합의합니다.

@EndUserText.label : '재작업 점검 접근 제어'
@MappingRole : true
define role ZI_RWKORDER {
  grant select on ZI_RwkOrder
    where ( Werks ) = aspect pfcg_auth( I_PLANT, WERKS, ACTVT = '03' );
}
" 같은 방식으로 ZI_RwkMonth · ZI_RwkCause 에도 건다.
" 권한 객체 이름과 필드는 대상 시스템의 설계에 맞춰 확인한다.

운영 전환에서 정해야 할 항목

개발보다 합의가 많습니다. 아래 여섯 가지는 코딩이 아니라 결정입니다.

1. 원가요소 그룹 합의 — 어느 원가요소까지 재작업 원가로 볼지 회계팀이 정합니다.
2. 표준 단가의 원천 — 표준 원가 추정에서 읽을지 별도 관리할지 기획팀이 정합니다.
3. 재작업 원인 코드 — 확인 실적의 사유 코드를 쓸지 별도 코드를 둘지 현업과 정합니다.
4. 값 유형 · 버전 — COEP 에서 어떤 값 유형의 금액을 읽을지 CO 담당이 확인합니다.
5. 권한 기준 — 회사코드 · 플랜트 · 오더 유형 중 무엇으로 막을지 보안 담당이 정합니다.
6. 서비스 연결 — manifest 의 서비스 주소를 실제 OData 서비스로 바꾸고 $metadata 를 확인합니다.

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문을 네 묶음으로 나눠 적었습니다.

숫자와 산식

판정 기준

SAP 연계와 데이터

운영과 도입