유휴·가동 손실 원가 점검 — 제조원가, 작업장이 서 있던 시간을 원가로 바꿔 허용 기준과 견주는 월마감 화면

개발 배경 — 이 앱을 사용해야 하는 이유

제조 원가를 월마감에서 점검하는 사람은 매달 같은 질문을 받습니다. 설비가 서 있던 시간이 얼마나 되나, 그 시간이 원가로는 얼마인가, 허용할 만한 수준을 넘었나. 지금은 이 세 답이 작업장 마스터 · 오더 확정 실적 · 코스트센터 보고서 · 현장의 정지 기록으로 나뉘어 있어, 숫자가 어긋나면 어디서 갈렸는지부터 찾아야 합니다.

이 화면은 작업장의 가용시간을 가동시간과 손실시간으로 나누고, 손실시간에 활동단가를 곱해 유휴 손실원가를 만든 뒤 작업장별 허용 손실률과 견줍니다. 손실시간은 다시 준비·교체, 설비 고장, 자재·인력 대기, 원인 미분류로 나눠, 손실이 어디에 몰렸는지까지 한 화면에서 봅니다. 월마감 전에 점검하는 자리이며, 관련 기준서가 따로 정해진 영역이 아니므로 대상 영역은 제조원가(유휴·가동 손실 원가)로 적습니다.

서 있던 시간은 원가로 바꿔야 크기가 보인다

정지 시간은 시간 단위로 보면 작아 보여도 활동단가가 곱해지면 얘기가 달라집니다. 이 자료의 6개월 합계는 손실시간 743시간(가용시간 11,712시간의 6.34%)이고, 이를 활동단가로 바꾼 유휴 손실원가는 4,147만 원입니다. 같은 시간이라도 단가가 높은 프레스 라인이나 도장 설비의 정지가 CNC 선반의 정지보다 훨씬 비쌉니다. 시간만 보는 가동률 보고서로는 이 차이가 보이지 않습니다.

허용 기준은 작업장마다 다르다

준비·교체가 많은 설비와 연속으로 도는 설비를 같은 기준으로 재면 안 됩니다. 이 화면은 작업장별 허용 손실률(이 자료에서는 5~9%)을 기준 값으로 두고, 손실률이 허용 기준보다 3%p 넘게 크면 점검 필요(L1)로 올립니다. 6개월 합계의 허용 손실원가는 4,623만 원이어서 허용 초과 원가는 -476만 원, 곧 전체로는 허용 범위 안입니다. 그런데도 작업장·월 단위로 내려가면 9건이 기준에 걸립니다. 합계로는 보이지 않던 것이 행 단위에서 드러나는 것이 이 화면의 쓸모입니다.

활동단가가 비어 있으면 손실이 0원으로 보인다

손실시간이 있는데 활동단가가 0이면 유휴 손실원가도 0으로 집계됩니다. 정지가 없었던 것처럼 보이지만 실제로는 단가 설정이 빠진 것입니다. 이 화면은 손실시간이 있는데 활동단가가 없는 작업장(L2)을 따로 올립니다. 이 자료에서는 3월 조립 라인이 여기에 걸립니다.

고장과 미분류가 몰리면 원인 분석부터 막힌다

설비 고장이 손실시간의 절반을 넘는 작업장(L3)은 정비 계획을, 원인 미분류가 30%를 넘는 작업장(L4)은 정지 사유 입력 상태를 먼저 봐야 합니다. 월 단위로도 원인 미분류 원가 비중 12% 초과(C1), 설비 고장 원가 비중 40% 초과(C2)를 올립니다. 어느 쪽이든 원인을 단정하지 않고 확인할 일만 적어 줍니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도는 필수이고, 전기 월 범위 · 작업장 · 손실 원인 · 점검 결과는 선택입니다. ‘전체’를 고르면 그 조건은 걸리지 않습니다.
2. 조회 버튼(조회조건 오른쪽 끝) 또는 회계연도 입력 칸에서 Enter 키를 누릅니다. 처음 열면 자동으로 한 번 조회합니다.
3. 요약 지표에서 유휴 손실원가 · 허용 손실원가 · 허용 초과 원가 · 손실률과 점검 필요 작업장 · 원인 건수, 대사 차이 건수를 먼저 봅니다.
4. 탭을 작업장별 점검 → 손실 이벤트 → 원인별 집계 → 월별 추이 → 대사 결과 순서로 옮겨 가며 확인합니다.
5. 행을 누르면 상세 창이 열려 시간 구성 · 원가 · 점검 내용 · 정지 이벤트 명세가 나옵니다.
6. CSV 내려받기 버튼으로 현재 탭의 조회 결과를 UTF-8 CSV로 받아 엑셀로 이어 갑니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 그래서 화면을 만들기 전에 대사식 아홉 개를 먼저 세우고 자료 전수에 돌렸습니다.

아홉 대사식 모두 차이 건수 0건입니다(검사 229건). 이와 별도로 판정 기준에 걸리는 건을 일부러 넣었습니다. 점검 필요 작업장 9건(손실률 초과 3건 · 활동단가 없음 1건 · 설비 고장 편중 3건 · 원인 미분류 편중 2건)과 점검 필요 원인 2건(미분류 비중 · 고장 비중)이며, 이 건들은 대사 차이가 아니라 점검 대상이라 차이 건수에 넣지 않았습니다.

무엇으로 만들었나

실행 화면

아래 화면은 가상의 작업장 6곳(CNC 선반 2 · 머시닝센터 · 프레스 · 조립 · 도장)과 가상의 단가로 만든 검증용 샘플 데이터(2026년 1~6월)를 실제로 조회한 모습입니다. 작업장·월 36행, 정지 이벤트 282건이며, 실제 고객사 값이 아닙니다.

처음 열었을 때

열면 자동으로 한 번 조회해, 조회조건 아래에 요약 지표 일곱 개와 작업장별 점검 표가 한꺼번에 나옵니다.

맨 위 조회조건은 회계연도 · 전기 월 시작/종료 · 작업장 · 손실 원인 · 점검 결과 여섯 칸이고 기본값은 2026년 전체입니다. 요약 지표는 유휴 손실원가 합계 41.5 · 허용 손실원가 46.2 · 허용 초과 원가 -4.8(이상 백만 원) · 손실률 6.34% · 점검 필요 작업장 9 · 점검 필요 원인 2 · 정합성 대사 차이 건수 0 순서입니다. 허용 초과 원가가 음수라는 것은 6개월 합계로는 허용 범위 안이라는 뜻입니다. 표는 작업장 · 월마다 가용시간 · 가동시간 · 준비·교체 · 설비 고장 · 자재·인력 대기 · 원인 미분류 · 손실시간 · 손실률 · 허용 손실률을 한 줄에 보여 줍니다. 탭 이름 위의 숫자는 조회된 건수입니다.

손실 이벤트

두 번째 탭은 작업장이 선 기록을 한 건씩 보여 줍니다. 손실시간이 어떤 정지들로 이뤄졌는지 확인하는 자리입니다.

이벤트는 6개월 동안 282건입니다. 건마다 정지 날짜 · 작업장 · 원인 · 정지 시간 · 손실원가가 있고, 손실원가는 정지 시간에 그 작업장의 활동단가를 곱한 값입니다. 작업장별 점검 표의 손실시간은 이 이벤트 시간의 합과 같아야 하며, 이는 대사식 R05로 검산됩니다. 손실 원인과 작업장 조건을 걸면 “3월 프레스 라인의 고장 정지만”처럼 좁혀 볼 수 있습니다.

원인별 집계

세 번째 탭은 월마다 손실을 원인별로 나눕니다. 어느 달에 어떤 원인이 몰렸는지 한눈에 보입니다.

원인은 준비·교체 · 설비 고장 · 자재·인력 대기 · 원인 미분류 네 가지이고, 월 4행씩 24행입니다. 6개월 합계로는 설비 고장이 249시간, 준비·교체가 248시간, 자재·인력 대기가 175시간, 원인 미분류가 71시간이어서 합계 743시간입니다. 이 가운데 3월의 원인 미분류 원가 비중은 14.49%로 12%를 넘어 C1 점검 필요이고, 5월의 설비 고장 원가 비중은 42.62%로 40%를 넘어 C2 점검 필요입니다. 비중 합계는 매월 100%여야 하며 R08로 검산됩니다.

월별 추이

네 번째 탭은 6개월을 한 줄씩 놓고 손실이 어느 달에 커졌는지 봅니다.

월 손실률은 1월 7.03%, 2월 5.82%, 3월 6.05%, 4월 6.51%, 5월 5.89%, 6월 6.70%입니다. 6개월 중 허용 초과 원가가 양수인 달은 4월 하나이고(+10.4만 원), 나머지 달은 허용 기준보다 손실원가가 작아 음수입니다. 달이 정상이어도 안에는 점검 필요 작업장이 있을 수 있어, 월 행의 점검 필요 건수를 함께 봅니다. 월 행을 누르면 그 달의 이벤트 명세가 열립니다.

대사 결과

마지막 탭은 숫자를 믿어도 되는지 확인하는 자리입니다.

아홉 대사식마다 검사 건수 · 좌변 · 우변 · 차이 건수 · 최대 차이가 나옵니다. 검사는 모두 229건이고 차이는 0건입니다. 차이 건수 칸은 0이면 정상색, 0이 아니면 경고색으로 바뀌어 그 숫자는 원천을 확인하라는 신호가 됩니다.

행 클릭 상세

표의 행을 누르면 그 작업장·월의 시간 구성과 원가, 점검 내용, 정지 이벤트 명세가 한 창에 열립니다.

상세 창은 위에서부터 가용시간 → 가동시간 → 손실시간(원인별), 활동단가, 유휴 손실원가와 허용 손실원가, 손실률과 허용 손실률, 점검 내용, 그리고 그 달의 정지 이벤트 명세 순서입니다. 점검 필요 행은 어떤 조건(L1~L4)에 걸렸는지와 확인할 일이 함께 적힙니다. 원인 행이나 이벤트 행을 눌러도 같은 모양의 창이 열립니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 필터로 바꿔 서비스에 요청하고, 받은 결과를 탭마다 다른 표에 바인딩합니다. 작업장 탭 · 이벤트 탭 · 원인 탭 · 월 탭 · 대사 탭이 각자 자기 데이터 묶음을 읽고, 행을 누르면 상세 창이 그 작업장·월의 이벤트 묶음을 따로 불러옵니다. 계산은 모두 서비스가 하고 화면은 값을 읽어 보여 주기만 합니다.

화면의 요약 지표 손실률은 가용시간 가중(손실시간 합계 ÷ 가용시간 합계)이고, 월별 손실률의 단순 평균은 별도 조회용 함수가 돌려줍니다. 두 값은 용도가 다르므로 화면에서는 가중 값만 지표로 씁니다.

SAP 표준 기능 확장 포인트

원가를 집계하고 전기하는 일은 SAP 표준 T-code가 담당하고, 이 화면은 그 결과를 조회 · 검증하는 관점을 더해 확장합니다. 표준 화면을 없애는 것이 아니라, 표준 화면 사이를 오가며 하던 대조를 한 화면으로 모읍니다.

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

T-code 별 연계 지점

S/4HANA 분석 스택과의 자리

S/4HANA에서는 CDS 뷰 위에 분석 쿼리를 만들고, Fiori 분석 앱이나 Analysis for Office로 읽는 구성이 일반적입니다. 이 앱은 그 구성과 경쟁하지 않고 같은 CDS 뷰를 OData 서비스로 노출하는 자리에 놓입니다. 분석 쿼리는 임의로 축을 바꿔 보는 데 좋고, 이 화면은 정해진 판정 기준으로 이상한 작업장 · 원인만 골라 보여 주는 데 맞춰 둔 것입니다. 같은 시간 · 원가 뷰를 공유하므로 두 화면의 숫자는 갈라지지 않습니다.

확장 포인트 — 운영에서 실제로 손대는 자리

분석 지표 정의표

이 화면은 회계 기준서의 요구사항을 점검하는 도구가 아니라 제조원가 지표를 점검하는 도구이므로, 요구사항 매핑표 대신 지표 정의표를 둡니다.

CDS 구성

아래는 이 화면이 읽는 값을 S/4HANA의 CDS 뷰로 세울 때의 구성 예시입니다. 객체 이름과 필드는 이 글에서 새로 지은 것이고, 표준 테이블(CRHD · CRCO · AFRU)과 표준 필드 이름만 실재하는 것을 썼습니다. 정지 기록의 원천은 회사마다 달라 확인 필요입니다.

뷰 레이어 구성

① 활동단가 기준 테이블 — 작업장별 활동단가와 허용 손실률

활동단가와 허용 손실률은 작업장마다, 기간마다 다르므로 코드가 아니라 기준 테이블에 둡니다. 이 테이블이 비어 있으면 손실원가가 0 으로 집계되므로 점검 코드 L2 가 가장 먼저 걸리는 자리입니다.

" ───────────────────────────────────────────────
" 활동단가 기준 — 작업장 · 유효시작일 단위
" 단가를 코드에 두지 않고 기간별로 관리하기 위해 나눈다
" ───────────────────────────────────────────────
@EndUserText.label : '유휴 손실 활동단가 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zidle_rate {
  key client     : abap.clnt not null;
  key werks      : werks_d not null;
  key arbpl      : arbpl not null;
  key valid_from : datum not null;
  act_rate       : abap.curr(11,0);
  waers          : waers;
  allow_pct      : abap.dec(5,2);   " 허용 손실률(%)
}

② 차원 뷰 — 작업장

작업장 이름과 코스트센터 연결은 작업장 마스터에서 읽습니다. 집계 뷰가 마스터를 직접 조인하지 않도록 차원 뷰로 분리하면 작업장 이름이나 코스트센터가 바뀌어도 한 곳만 고치면 됩니다.

" ───────────────────────────────────────────────
" ZI_IdleWorkCenter — 작업장 차원
" 작업장 마스터(CRHD)와 코스트센터 할당(CRCO)을 한 번만 조인한다
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '유휴 손실 — 작업장 차원'
@ObjectModel.representativeKey : 'WorkCenter'
define view entity ZI_IdleWorkCenter
  as select from crhd as wc
  inner join crco as co on co.objty = wc.objty and co.objid = wc.objid
{
  key wc.werks as Plant,
  key wc.arbpl as WorkCenter,
      wc.verwe as Category,
      co.kostl as CostCenter,
      co.lstar as ActivityType
}

③ 정지 이벤트 뷰 — 정지 기록을 한 줄 단위로

정지 시간과 사유는 표준 테이블 하나로 모이지 않습니다. 설비 가동 시스템이나 정비 통보에서 오는 정지 기록을 이 뷰 한 곳에서 받도록 하고, 원천 이름은 회사가 정합니다(확인 필요). 이후 뷰는 이 뷰의 칸 이름만 바라봅니다.

" ───────────────────────────────────────────────
" ZI_IdleStopEvent — 정지 이벤트
" 원천: 회사의 정지 기록(원천 테이블 이름 확인 필요)
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '유휴 손실 — 정지 이벤트'
define view entity ZI_IdleStopEvent
  as select from zidle_stoplog          " 회사 정지 기록 (확인 필요)
{
  key event_no                          as EventNo,
      werks                             as Plant,
      arbpl                             as WorkCenter,
      event_date                        as EventDate,
      reason_code                       as ReasonCode,      " R1 준비·교체 / R2 고장 / R3 대기 / R4 미분류
      aufnr                             as OrderNo,
      @Semantics.quantity.unitOfMeasure : 'HourUnit'
      stop_hours                        as StopHours,
      cast('H' as meins)                as HourUnit
}

④ 큐브 뷰 — 작업장 · 월 단위 시간 구성과 원가

시간 구성과 원가는 이 큐브에서 한 번 계산합니다. 손실원가는 손실시간에 활동단가를 곱하고, 활동 원가풀은 가용시간에 단가를 곱해 제품 배부 원가와 손실원가의 합과 맞춥니다. 대사식 R03·R04 가 이 큐브의 식을 그대로 검사합니다.

" ───────────────────────────────────────────────
" ZI_IdleLossCube — 작업장 · 월 큐브
" 이 뷰에서만 시간 → 원가 계산을 한다 (식을 한 곳에 모으기 위해)
" ───────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '유휴 손실 큐브'
define view entity ZI_IdleLossCube
  as select from ZI_IdleStopEvent as ev
  association [1] to ZI_IdleWorkCenter as _WorkCenter
    on _WorkCenter.Plant = ev.Plant and _WorkCenter.WorkCenter = ev.WorkCenter
  association [0..1] to zidle_rate as _Rate
    on _Rate.werks = ev.Plant and _Rate.arbpl = ev.WorkCenter
{
  key ev.Plant, key ev.WorkCenter,
  key substring(ev.EventDate, 1, 6)                                       as PostingMonth,
      @Aggregation.default : #SUM
      sum(ev.StopHours)                                                   as LossHours,
      @Aggregation.default : #SUM
      sum(case when ev.ReasonCode = 'R2' then ev.StopHours else 0 end)    as BreakHours,
      @Semantics.amount.currencyCode : 'Currency'
      cast(sum(ev.StopHours * _Rate.act_rate) as abap.curr(15,0))         as LossCost,
      _Rate.waers                                                         as Currency,
      _WorkCenter
} group by ev.Plant, ev.WorkCenter, substring(ev.EventDate, 1, 6), _Rate.waers

⑤ 쿼리 뷰 — 화면이 바라보는 점검 쿼리

화면의 조회조건과 점검 판정은 이 쿼리에서 정합니다. 손실률이 허용 기준을 넘는지의 판정을 여기서 계산해 두면 서비스와 화면이 같은 기준을 읽습니다.

" ───────────────────────────────────────────────
" ZC_IdleLossQuery — 점검 쿼리
" ───────────────────────────────────────────────
@Analytics.query : true
@EndUserText.label : '유휴·가동 손실 원가 점검'
@UI.headerInfo : { typeName : '작업장', typeNamePlural : '작업장' }
define view entity ZC_IdleLossQuery
  as select from ZI_IdleLossCube
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key Plant,
  @UI.lineItem : [{ position : 10 }]
  key WorkCenter,
  @Consumption.filter : { selectionType : #INTERVAL }
  key PostingMonth,
  @UI.lineItem : [{ position : 20, criticality : 'CheckCrit' }]
  LossHours,
  @UI.lineItem : [{ position : 30 }]
  LossCost,
  @AnalyticsDetails.query.axis : #COLUMNS
  BreakHours
}

⑥ 권한 — 플랜트 단위 접근 제어

손실원가는 설비 가동 현황과 원가 단가가 함께 드러나므로 플랜트 단위로 접근을 나눕니다. 권한 오브젝트와 값은 회사의 권한 설계에 맞춰 정합니다.

" ───────────────────────────────────────────────
" 플랜트 단위 접근 제어
" ───────────────────────────────────────────────
@EndUserText.label : '유휴 손실 — 플랜트 권한'
@MappingRole : true
define role ZC_IDLELOSSQUERY {
  grant select on ZC_IdleLossQuery
    where ( Plant ) = aspect pfcg_auth( C_ANLA_WRK, WERKS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

화면은 서비스 정의에 올린 쿼리만 바라봅니다. 운영에서는 이 서비스를 게시하고 manifest 의 서비스 주소만 교체합니다. 서비스 활성화는 서비스 바인딩에서 게시합니다.

" ───────────────────────────────────────────────
" 서비스 정의 — 점검 쿼리와 정지 이벤트 노출
" ───────────────────────────────────────────────
@EndUserText.label : '유휴·가동 손실 원가 점검 서비스'
define service ZUI_IdleLoss {
  expose ZC_IdleLossQuery as LossSet;
  expose ZI_IdleStopEvent as EventSet;
  expose ZI_IdleWorkCenter as WorkCenterSet;
}

운영 시점에 해야 할 일

아래 아홉 가지는 코딩이 아니라 합의입니다. 합의가 끝나기 전에는 화면이 올라가도 숫자가 믿을 만해지지 않습니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

점검 기능

도입과 운영