생산 계획·능력 통합 관리 — 수요에서 계획오더·생산오더까지, 능력 부하와 실적 차이를 한 앱에서
기준정보 · 문서 처리와 2단계 승인 · 시뮬레이션을 거친 일괄 실행 · 대사와 예외 조치 · 능력 부하 분석과 요인분해 · AI 해설과 에이전트 · 영역 간 연계와 감사 — 소개 영상과 실제 화면 29종, 그리고 CDS 코드까지
소개 영상블로그 목차 순서대로 · 자막 포함
도입 포인트 — 이 앱을 사용해야 하는 이유
생산 계획 회의의 질문은 늘 같습니다. 이번 달 수요를 받을 능력이 있는가, 누가 승인했고 무엇이 아직 막혀 있는가, 계획과 실적은 왜 벌어졌는가. 지금 이 세 답은 소요량 계획(MD01·MD04) 결과, 생산오더 조회(COOIS), 능력 평가(CM01·CM21), 그리고 밤새 맞춘 엑셀과 메일 승인으로 흩어져 있습니다. 이 앱은 세 답을 한 화면에 붙여, 계획 담당자가 표준 거래 사이를 오가며 숫자를 옮기는 일을 줄입니다.
표준 거래는 한 건을 정확히 처리하는 데 강하고, 이 앱은 그 사이를 잇는 쪽에 섭니다. 계획오더 문서를 만들고 검토 요청·승인·확정까지 상태를 서버가 지키며, 수요를 일괄로 계획오더로 바꾸기 전에 시뮬레이션으로 부하와 가공비를 먼저 보고, 확정한 숫자는 대사식으로 검산합니다. 그 위에 작업장 × 기간 부하를 축을 바꿔 가며 보고, 가공비 차이를 요인으로 가르는 분석을 얹었습니다.
핵심 포인트 여덟 가지
| 핵심 포인트 | 고객이 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 계획·승인·확정이 한 앱에서 끝난다 | 계획오더·생산오더·조정 문서를 만들고 검토 요청 → 승인 → 확정까지 한 화면에서 처리합니다. 상태 전이는 서버가 판정해 화면이 바뀌어도 규칙이 같습니다. | 표준 거래를 오가며 입력하고, 승인은 메일과 구두로 받아 누가 언제 승인했는지 찾기 어렵습니다. |
| ② 직무 분리와 금액별 2단계 승인 | 작성자가 자기 문서를 승인하면 서버가 거절하고, 1,500만 원 이상은 서로 다른 승인자 두 명이 필요합니다. 1단계가 끝나면 상태 칸에 "1 / 2 단계"가 보입니다. | 승인 규칙이 담당자의 기억과 메일에 있어, 사람이 바뀌면 규칙도 흔들립니다. |
| ③ 시뮬레이션을 거쳐야 실행되는 일괄 실행 | 수요를 계획오더로 바꾸기 전에 항목 수·총 시간·가공비·능력 초과 작업장을 미리 봅니다. 시뮬레이션 없이 실행하거나 조건이 바뀌면 서버가 거절합니다. | 일괄 실행을 돌린 뒤에야 능력 초과를 알고, 되돌리는 데 하루가 걸립니다. |
| ④ 대사와 예외 조치를 앱 안에서 | 규칙 네 개(머리·항목 시간, 계획·실적, 부하·능력, 수요·계획오더)를 돌려 예외를 만들고, 조정 문서·사유·보류로 조치한 뒤 재대사합니다. | 엑셀로 두 표를 맞추고 차이를 메일로 물으며, 조치 이력은 담당자의 파일에만 남습니다. |
| ⑤ 능력 부하를 축을 바꿔 가며 본다 | 작업장 × 기간 피벗을 작업장 유형·자재 그룹 등으로 바꿔 보고, 칸을 누르면 그 값을 만든 문서 라인이 열립니다. 모든 축이 같은 큐브에서 나와 합계가 갈라지지 않습니다. | 축마다 리포트를 따로 만들고, 숫자가 의심스러우면 다른 거래로 옮겨 조건을 다시 넣습니다. |
| ⑥ 가공비 차이를 네 요인으로 | 계획 대비 가공비 차이를 물량·수율·능률·요율로 가르고, 네 요인의 합이 총차이와 같은지 매번 검산합니다. | "왜 더 들었나"를 엑셀로 분해하고, 산식이 사람마다 달라 회의에서 다시 따집니다. |
| ⑦ 수주에서 구매요청까지 이어지는 연계와 감사 로그 | 수주 → 계획오더 → 구매요청의 앞뒤 문서를 한 줄로 따라가고, 모든 쓰기는 누가·언제·무엇을 바꿨는지 감사 로그에 남습니다. | 문서마다 다른 거래를 열어 번호를 이어 보고, 변경 이력은 필요할 때 찾아야 합니다. |
| ⑧ 숫자는 서비스가, 말은 규칙이 | AI 해설의 금액·비율은 서비스가 계산하고, 감시 규칙 다섯 개가 걸리면 받을 역할의 대기함에 보고가 올라갑니다. 보고는 하루 한 번만 만들어집니다. | 숫자가 나빠진 날에도 아무도 화면을 열지 않으면 그대로 지나갑니다. |
사례로 보는 효과 — 가공비 차이 3,485만 원의 진짜 이유
2026년 1~10월 계획 가공비는 800,494,307원, 실적은 835,342,365원이었습니다. 차이 +34,848,058원(4.4%)까지는 표준 리포트도 말해 줍니다. 이 앱은 그 다음을 답합니다. 네 요인으로 가르자 몫이 가장 큰 것은 능률 +39,276,968원이었습니다 — 같은 물량을 만드는 데 계획보다 시간이 더 든 몫입니다. 물량 +2,858,012원과 수율 +2,570,390원이 더해졌고, 요율은 −9,857,312원으로 총차이를 일부 줄여 주었습니다.
양품 수량 Q · 불량 수량 S · 투입 I = Q + S · 수율 y = Q ÷ I · 투입 단위당 시간 h · 시간당 가공비 r (a = 실적, p = 계획)
물량 = (Qa − Qp) ÷ yp × hp × rp · 수율 = Qa (1 ÷ ya − 1 ÷ yp) × hp × rp
능률 = Ia (ha − hp) × rp · 요율 = Ha (ra − rp) (Ha = 실적 시간)
네 항을 더하면 전개 과정에서 중간 항이 서로 지워져 실적 가공비 − 계획 가공비와 정확히 같아집니다.
분해에는 조건을 걸었습니다. 네 요인의 합이 총차이와 1원도 어긋나면 안 됩니다. 화면이 매번 그 등식을 검산해 보여 줍니다. 2,858,012 + 2,570,390 + 39,276,968 − 9,857,312 = 34,848,058. 이 한 줄이 맞아야 "능률이 문제"라는 말이 회의에서 통합니다. 대사식 검사 건수와 차이 0건은 검증 결과 절에 따로 적었습니다.
도입하면 달라지는 것
- 계획 회의 준비 — 부하율·승인 대기·예외가 개요 한 화면에 모이므로 엑셀 취합과 메일 확인 시간이 줄어듭니다.
- 승인의 기록 — 누가 언제 어떤 사유로 승인·반려했는지가 상태 이력과 감사 로그에 남아 사람이 바뀌어도 규칙이 이어집니다.
- 일괄 실행의 안전 — 시뮬레이션 합계와 실행 결과가 같고, 같은 조건의 두 번째 실행은 막혀 중복 오더가 생기지 않습니다.
- 회의의 주제 — "어느 숫자가 맞나"가 아니라 "능률이 왜 벌어졌나"를 이야기합니다.
- 놓치는 날이 없는 점검 — 아무도 화면을 열지 않은 날에도 규칙에 걸린 항목은 받을 역할의 대기함에 올라갑니다.
이런 회사에 맞습니다
작업장 여러 곳을 공유하는 제조 법인으로, 수요가 월 단위로 들어오고 계획오더를 일괄로 만들며 승인 단계가 둘 이상인 회사에 맞습니다. S/4HANA의 생산 계획·오더 관리를 쓰면서 능력 평가와 계획 대비 실적을 엑셀로 맞추고 있는 생산관리팀, 그리고 숫자의 출처를 통제하면서 AI 해설을 쓰고 싶은 경영지원 조직이 대상입니다. 반대로 한 작업장에서 한 가지 제품만 만들거나 승인 단계가 없는 곳이라면 표준 거래만으로 충분할 수 있습니다.
실행 화면
실제로 돌아가는 화면 29종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 읽을 수 있습니다.
사용 방법
- 조회조건을 입력합니다. 화면 맨 위 한 줄에 사업장·기간(시작)·기간(종료)이 있고 모두 선택 입력입니다. 기간은
2026-01형식이며 시작이 종료보다 늦으면 안내가 뜹니다. - 조회를 누르거나 입력 칸에서 Enter 키를 누릅니다. 개요·문서 처리·기준정보 화면은 열 때 현재 조건으로 자동 조회되고, 분석 화면은 조회를 눌러야 큐브를 읽습니다.
- 개요의 요약 타일(부하율·승인 대기·반려·미해결 예외·확정·열린 할 일)을 먼저 봅니다. 아래 "내 할 일"에서 줄을 누르면 해당 문서나 예외로 바로 이동합니다.
- 왼쪽 메뉴를 위에서 아래로 따라갑니다 — 개요 · 기준정보 관리(작업장·자재·공정 순서 탭) → 문서 처리 → 일괄 실행 → 대사·점검 → 분석 → 영역 간 연계 → 이력·감사·권한.
- 행이나 칸을 눌러 상세를 엽니다. 문서 처리에서는 오른쪽에 항목·상태 이력·연계 문서·감사 로그가 열리고, 분석에서는 피벗 칸을 누르면 그 값을 만든 문서 라인이 열립니다.
- 처리자가 문서를 만들어 검토 요청하면 승인자가 승인(또는 사유를 적어 반려)하고 처리자가 전기합니다. 일괄 실행은 시뮬레이션 → 결과 검토 → 실행, 대사는 대사 실행 → 예외 목록 → 조치 → 재대사 순서입니다.
- 내보내기 — 기준정보·문서·드릴스루·연계 내역·피벗의 CSV는 UTF-8(BOM)이라 엑셀에서 한글이 깨지지 않습니다. 문서는 xlsx 내보내기와, 미리 검사한 뒤 반영하는 xlsx 업로드도 있습니다.
무엇으로 만들었나
화면은 OpenUI5 표준 컨트롤로 짰고, 판정과 집계는 서비스가 맡습니다. 어디에 무엇을 두었는지와 그렇게 한 까닭을 표로 적었습니다.
| 자리 | 무엇 | 왜 그렇게 두었나 |
|---|---|---|
| 화면 컨트롤 | OpenUI5 표준 컨트롤(sap.m · sap.f · sap.tnt · sap.ui.table · sap.uxap)과 직접 그린 SVG 차트, 테마 sap_horizon | 외부 차트 라이브러리를 들이지 않아 반입 심사가 필요 없고, 표와 차트의 숫자가 다른 경로로 만들어질 일이 없습니다. |
| 집계 · 판정 로직 | 큐브 재집계와 요인분해, 상태 전이·채번·승인·대사·시뮬레이션은 모두 서비스 쪽 로직이 판정 | 화면은 요청을 보내고 서버 응답을 그대로 보여 주므로, 같은 규칙을 다른 화면에서 다시 구현하지 않습니다. |
| OData 서비스 구성 | OData V2 서비스 1개 — 엔티티셋 34개(기준정보·문서·집계·대사·감사), 펑션 12개(검토 요청·승인·전기·역처리·일괄 실행·대사·요인분해·에이전트 등). 화면은 기본 모델 1개로 모든 셋을 읽습니다. | 조회·단건·생성·수정·삭제와 펑션만 쓰는 표준 형태라, 운영 서비스로 바꿀 때 서비스 주소 한 곳만 교체합니다. |
| 보조 모델 | 문구(i18n) · 공통 조회조건과 사용자 모델 · 화면별 입력 상태 모델 | 조회조건을 화면마다 따로 두지 않고 하나를 공유해 개요에서 정한 사업장이 분석까지 따라옵니다. |
| 테마와 접근성 | sap_horizon, 좁은 화면에서는 메뉴가 아이콘으로 접히고 조회조건이 한 줄씩 쌓임 | 현장 태블릿과 휴대폰에서도 같은 화면을 열 수 있게 했습니다. |
앱 정보
| 항목 | 내용 |
|---|---|
| 영역 | 생산 (PP) · 통합 관리 |
| 업무 흐름 범위 | 수요 → 계획오더 → 승인·확정 → 생산오더 → 능력 부하·실적 차이 분석 |
| 모듈 구성 | 개요·할 일 / 기준정보 / 문서 처리 / 일괄 실행 / 대사·점검 / 분석 / 영역 간 연계 / 이력·감사·권한 |
| SAP 표준 T-code | CO01 · CO02 · CO03 · COOIS · MD01 · MD04 · CM01 · CM21 · CR03 · CA03 |
| 데이터 연동 | OData V2 서비스 1개 (조회·단건·생성·수정·삭제·펑션) |
| 테마 | sap_horizon |
처음 열었을 때 — 부하율과 할 일이 앞에 선다
처음 여는 화면은 숫자 몇 개와 할 일입니다. 조회조건 아래에 타일 여섯 개가 서고, 그 아래 "내 할 일"이 역할에 맞게 줄을 세웁니다.
가장 먼저 보이는 것은 이번 기간의 작업장 부하율(2,563 / 4,122 h, 62.2%)과 승인 대기 34건 · 반려 22건 · 미해결 대사 예외 15건 · 확정 202건 · 열린 할 일 145건입니다. 타일 색은 부하율이 85% 이하면 녹색, 85%를 넘으면 주황, 95%를 넘으면 빨강으로 바뀝니다. 오른쪽 위 사용자 전환으로 역할을 바꾸면 같은 화면이 그 역할의 눈높이로 다시 그려집니다.
할 일은 서버가 문서 상태에 맞춰 만들고 닫습니다. 승인 대기 · 반려 · 대사 예외 · 시작일 임박이 한 목록에 모이고, 한 줄을 누르면 해당 문서 상세로 바로 넘어갑니다. 상태 오른쪽의 색 글씨는 기한이 지났거나 임박했는지를 뜻합니다.
기준정보 관리 — 작업장 · 자재 · 공정 순서
기준정보는 계획 숫자의 바닥입니다. 작업장의 가용 능력·효율·시간당 가공비가 여기서 정해지고, 부하율과 가공비가 모두 이 값에서 나옵니다.
일 가용 능력(h) · 효율(%) · 교대 · 시간당 가공비가 한눈에 보이고, 위쪽 검색어는 코드와 이름에 모두 걸립니다. 생성 · 수정 · 사용 중지 버튼은 관리자에게만 켜지며, 행의 라디오를 먼저 골라야 수정과 사용 중지가 열립니다. 목록은 CSV로 내려받을 수 있습니다.
표준 로트는 일괄 실행이 계획오더 수량을 자를 때 쓰는 값이라 이 탭에서 고치면 다음 실행부터 반영됩니다. 사용 중지한 자재는 목록에 남되 새 문서에서는 고를 수 없습니다.
저장을 누르면 화면이 아니라 서비스가 필수값과 중복을 확인합니다. 이미 있는 작업장 코드를 다시 넣으면 "이미 있는 작업장입니다"라는 메시지가 그대로 돌아옵니다. 입력을 바꾼 뒤 닫으려 하면 저장하지 않은 변경이 있다고 한 번 더 묻습니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
문서 처리와 승인 — 상태와 권한을 서버가 지킨다
문서가 한 번 만들어지면 상태는 서버가 지킵니다. 목록·상세·생성·업로드가 한 화면 안에서 이어지고, 버튼은 현재 상태와 내 역할에 맞는 것만 켜집니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
일괄 실행 — 시뮬레이션을 거쳐야 실행된다
수요를 계획오더로 바꾸는 일괄 실행은 되돌리기 어렵습니다. 그래서 시뮬레이션을 거쳐야만 실행되도록 순서를 고정했습니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
대사와 예외 조치 — 15건은 의도적으로 남겨 두었다
대사는 "숫자가 맞는가"를 사람 대신 돌려 보는 일입니다. 규칙 네 개가 예외를 만들고, 예외에는 조치와 이력이 붙습니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
분석 — 능력 부하를 축을 바꿔 가며 본다
분석은 이 앱의 중심입니다. 작업장 × 기간 부하를 같은 큐브 위에서 축을 바꿔 가며 보고, 차이는 요인으로 가르고, 칸은 원천 라인까지 내려갑니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
레이아웃 저장 · AI 분석 · 에이전트
자주 쓰는 배치는 이름을 붙여 저장하고, 숫자 해설은 AI가 말로 쓰되 숫자는 서비스가 계산하며, 에이전트는 사람이 열지 않아도 감시 규칙을 돌립니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
영역 간 연계 — 수주에서 구매요청까지
문서는 혼자 있지 않습니다. 수요가 계획오더가 되고 구매요청으로 이어지는 앞뒤를 한 줄로 따라갑니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
이력 · 감사 · 역할
모든 쓰기는 기록이 남고, 역할마다 할 수 있는 일이 다릅니다. 같은 문서를 다른 사람이 열면 버튼이 달라지는 모습입니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
좁은 화면에서는
휴대폰 폭에서는 조회조건과 보드가 한 줄씩 쌓이고, 메뉴는 아이콘으로 접힙니다. 숨기는 기능은 없습니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
화면 뒤에서 일어나는 일
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
판정 규칙 — 조건에서 결과까지
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
문서 상태 전이
| 현재 상태 | 동작 | 다음 상태 | 필요 역할 | 서버 검사 | 사용자 조치 |
|---|---|---|---|---|---|
| 임시저장(10) | 검토 요청 | 검토요청(20) | 처리자 | 항목 합계 · 필수값 · 기간 열림 | 검토 요청을 누릅니다. 항목이 없거나 기간이 마감이면 서버가 사유를 돌려줍니다. |
| 반려(90) | 검토 요청 | 검토요청(20) | 처리자 | 반려 사유를 보완했는지는 사람이 확인 | 보완한 뒤 다시 검토 요청합니다. |
| 검토요청(20) | 승인 | 승인(30) | 승인자 | 작성자 ≠ 승인자 · 금액 1,500만 원 이상이면 2단계(서로 다른 승인자) | 1단계 승인 뒤 상태 칸에 "1 / 2 단계"가 보이면 다른 승인자가 이어서 승인합니다. |
| 검토요청(20) | 반려 | 반려(90) | 승인자 | 반려 사유 필수 | 사유를 적어 돌려보냅니다. |
| 승인(30) | 전기 | 확정(40) | 처리자 | 기간 열림(마감 월은 거절) · 최종 승인 완료 | 전기하면 문서가 확정되어 수정할 수 없습니다. |
| 확정(40) | 역처리 | 취소(99) | 승인자 | 사유 필수 · 마감 월 거절 · 한 번만 | 사유를 적으면 원문서와 연결된 반대 문서(금액 −1배)가 만들어집니다. |
부하율 판정
| 판정 조건 | 결과 상태 | 사용자 조치 |
|---|---|---|
| 부하율 ≤ 85% | 여유(녹색) | 추가 수요를 받을 수 있습니다. |
| 85% < 부하율 ≤ 95% | 주의(주황) | 일정 조정이나 교대 운영을 검토합니다. |
| 부하율 > 95% | 능력 초과 위험(빨강) | 시뮬레이션의 능력 초과 작업장 열에서 어느 작업장인지 확인하고 오더 시작일을 옮기거나 다른 작업장으로 돌립니다. |
일괄 실행 판정
| 판정 조건 | 결과 | 사용자 조치 |
|---|---|---|
| 시뮬레이션 없이 실행 | SIM_REQUIRED 로 거절 | 먼저 시뮬레이션을 돌립니다. |
| 시뮬레이션 뒤 조건이 바뀜 | SIM_STALE 로 거절 | 같은 조건으로 시뮬레이션을 다시 돌립니다. |
| 같은 조건으로 이미 실행됨 | 중복 거절 | 처리할 수요가 없다는 메시지를 확인합니다. 새 수요가 들어온 뒤 다시 시뮬레이션합니다. |
| 마감된 기간 | PERIOD_CLOSED 로 거절 | 열린 기간(2026-09 이후)으로 조건을 바꿉니다. |
대사 규칙
| 규칙 | 판정 조건 | 결과 상태 | 사용자 조치 |
|---|---|---|---|
| R01 | 문서 머리 총시간 ≠ 항목 시간 합계(허용 0.01 h) | 예외 생성 | 항목을 다시 계산하거나 조정 문서로 정리합니다. |
| R02 | 계획 시간과 실적 시간 차이가 8%(또는 0.5 h) 초과 | 예외 생성 | 실적 입력과 계획 값을 확인하고 사유를 남깁니다. |
| R03 | 작업장 월 부하 > 가용 능력 + 0.5 h | 예외 생성 — 능력 초과 | 일정 이동 · 외주 · 교대 증설을 검토합니다. |
| R04 | 당월 수요 수량 ≠ 계획오더 수량 합계 | 예외 생성 | 미충족 수요를 일괄 실행하거나 보류 사유를 적습니다. |
기준 대비 차이 색칠
| 판정 조건 | 결과 상태 | 사용자 조치 |
|---|---|---|
| 차이가 금액 임계와 비율 임계를 모두 넘음 | 영향 방향에 따라 빨강(나쁨) · 녹색(좋음) | 차이 요인분해로 원인을 가릅니다. |
| 둘 중 하나만 넘음 | 색을 입히지 않음 | 작은 차이는 눈에 띄게 하지 않습니다. |
업무 흐름과 대사식
수요에서 능력 부하·차이까지의 흐름을 단계별 상태와 SAP 데이터 지점, 이 앱의 모듈로 정리했습니다.
| 단계 | 상태 | 하는 일 | SAP 데이터 지점 | 이 앱의 모듈 |
|---|---|---|---|---|
| ① 수요 | 영업 수주 · 미충족 수요 | 수요 접수 | VBAK · VBAP · VBEP | M7 영역 간 연계 · M4 일괄 실행 |
| ② 계획오더 | 임시저장 → 검토요청 → 승인 → 확정 | 일괄 실행이 만들거나 사람이 생성 | PLAF | M3 문서 처리 |
| ③ 승인 · 전기 | 승인(1~2단계) → 확정 | 직무 분리 · 기간 열림 확인 | PLAF · 오더 상태 | M3 · M8 |
| ④ 생산오더 | 확정 → 생산오더 문서 | 공정 항목(작업장 · 시간 · 준비) | AFKO · AFPO · AFVC · AFVV | M3 문서 처리 |
| ⑤ 확인 · 실적 | 양품 · 불량 · 실적 시간 | 실적 입력 | AFRU | M6 분석 큐브 |
| ⑥ 능력 부하 · 차이 | 부하율 · 계획 대비 차이 · 요인분해 | 집계 · 대사 | KAKO · CRHD · 위 테이블 집계 | M5 대사 · M6 분석 |
| 대사식 | 검사 종류 | 검사 대상 |
|---|---|---|
| ① 문서 머리 시간 = 항목 시간 합계 | R01 | 문서 352건 |
| ② 계획 시간 = 실적 시간(확정 생산오더, 허용 오차 8%) | R02 | 150건 |
| ③ 작업장 월 부하 ≤ 가용 능력 | R03 | 130건(작업장 × 월) |
| ④ 당월 수요 = 계획오더 수량 | R04 | 23건 |
| ⑤ 집계 큐브 합계 = 원천 라인 합계(6개 측정값) | 큐브 검산 | 키 묶음 2,808개 |
| ⑥ 피벗 총합 = 큐브 총합(축 배치 6가지) | 화면 검산 | 6가지 |
| ⑦ 칸 금액 = 드릴스루 라인 합계 | 화면 검산 | 12칸 |
| ⑧ 계획 + 요인 합 = 실적(요인 합 = 총차이) | 요인분해 검산 | 매 조회 |
| ⑨ 시뮬레이션 합계 = 실행 결과 합계 | 서버 검산 | 실행 시 |
| ⑩ 역처리 금액 = 원문서 금액 × (−1) | 서버 검산 | 역처리 시 |
조회조건
화면마다 쓰는 조건과 서비스 조건($filter)의 대응입니다. 모든 조건은 한 번 정하면 메뉴를 옮겨도 따라옵니다.
| 화면 | 조건 | 필수 | 기본값 | 서버 조건 대응 |
|---|---|---|---|---|
| 공통 | 사업장 | 선택 | 전체 | Plant eq 'P100' |
| 공통 | 기간(시작) | 선택 | 2026-01 | Period ge '2026-01' |
| 공통 | 기간(종료) | 선택 | 2026-10 | Period le '2026-10' (시작과 하나의 and 묶음) |
| 문서 처리 | 문서번호 · 자재 | 선택 | — | substringof('값',DocNo) eq true or … |
| 문서 처리 | 구분 · 상태 | 선택 | 전체 | DocType eq 'PLO' · Status eq '20' |
| 기준정보 | 검색어(코드 · 이름) · 상태 | 선택 | 전체 | substringof('M10',WorkCenter) eq true or … · Active eq true |
| 일괄 실행 | 사업장 · 수요 기간 | 필수 | P100 · 2026-10 | 시뮬레이션 펑션의 파라미터 |
| 영역 간 연계 | 문서번호 | 선택 | — | FromDoc eq 'PL26000001' or ToDoc eq 'PL26000001' |
| 이력 · 감사 | 검색어 | 선택 | — | substringof('PL26',ObjKey) eq true or … |
| 분석 | 기간 · 사업장 · 측정값 · 표시 행 수 · 비교 기준 · 차원 필터 | 기간 선택 | 2026-01 ~ 2026-09 · 부하 시간 | (Period ge … and Period le …) and … |
결과 컬럼
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
좁은 화면에서 달라지는 것
| 자리 | 달라지는 것 |
|---|---|
| 조회조건 · 보드 | 가로로 놓이던 입력 칸과 레이아웃 보드가 한 줄에 하나씩 쌓입니다. |
| 왼쪽 메뉴 | 폭이 900px 아래로 내려가면 아이콘으로 접히고, 넓어지면 다시 펼쳐집니다. |
| 요약 타일 | 한 줄에 하나씩 놓이고 아래에 내 할 일 목록이 이어집니다. |
| 표 | 가로로 넘치는 표는 스크롤합니다. 기능을 줄이지 않고 같은 표를 그대로 둡니다. |
파일 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
SAP 표준 기능 확장 포인트
이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.
표준으로 되는 것과 안 되는 것
| 하고 싶은 일 | SAP 표준 | 표준에서 걸리는 자리 | 이 앱이 하는 일 |
|---|---|---|---|
| 소요량 계획과 계획오더 | MD01 · MD04 · MD11 · MD13 | 실행 결과를 확인하기 전에는 부하와 가공비를 합쳐 볼 수 없습니다 | 일괄 실행 전에 시뮬레이션으로 항목·시간·가공비·능력 초과를 미리 봅니다 |
| 생산오더 처리 | CO01 · CO02 · CO03 · COOIS | 오더 한 건씩 처리하고, 목록은 조회 중심입니다 | 한 화면에서 검토 요청·승인·전기·역처리를 상태 규칙대로 처리합니다 |
| 능력 평가 | CM01 · CM21 | 작업장별 평가이며 축을 바꾸거나 칸에서 원천으로 내려가기 어렵습니다 | 작업장 × 기간 피벗을 축을 바꿔 보고 칸에서 문서 라인까지 내려갑니다 |
| 작업장·라우팅·자재 | CR01~CR03 · CA03 · MM03 | 조회·변경이 거래별로 나뉘어 있습니다 | 세 탭으로 묶어 보고 변경 이력을 함께 보여 줍니다 |
| 계획 대비 실적 차이의 원인 | 없음 | 표준에 없습니다. 보통 엑셀로 분해합니다 | 물량·수율·능률·요율 네 요인으로 가르고 합계를 검산합니다 |
| 승인 기록과 직무 분리 | 문서별 상태 · 변경 문서 | 승인 규칙이 문서 유형마다 다르고 금액별 2단계는 별도 설계가 필요합니다 | 금액 구간별 1~2단계와 작성자≠승인자를 서버가 판정합니다 |
| 이상 징후 알림 | SM36 배치 + 메일 | 잡은 돌지만 누가 봐야 하는지는 사람이 정합니다 | 규칙마다 받을 역할이 붙고 대기함에 보고가 올라갑니다 |
T-code 별 연계 지점
이 앱이 표준 거래의 어느 자리를 이어받는지 적었습니다. 운영에 올릴 때 꼭 나오는 질문이 "기존 거래를 없애야 하는가"인데, 대부분은 없애지 않고 둡니다 — 법정·감사 대응과 세무 신고에 쓰는 숫자는 표준 거래가 만든 값이어야 하기 때문입니다.
| T-code | 이름 | 연계 |
|---|---|---|
VA03 | 판매오더 표시 | 수요의 원천입니다. 영역 간 연계 화면에서 수주 번호를 눌러 확인하는 자리와 같은 데이터(판매오더 일정 라인)를 읽습니다. |
MD01 · MD04 | 소요량 계획 실행 · 재고/소요 목록 | 일괄 실행이 수요를 계획오더로 바꾸는 자리입니다. 표준 소요량 계획을 돌린 결과와 이 앱의 시뮬레이션 합계를 맞춰 보는 것이 첫 대사입니다. |
MD11 · MD12 · MD13 | 계획오더 생성 · 변경 · 표시 | 이 앱의 계획오더 문서가 닿는 자리입니다. 확정한 문서 번호로 표준 화면에서 같은 오더를 찾아 수량·시작일을 대조합니다. |
CO01 · CO02 · CO03 | 생산오더 생성 · 변경 · 표시 | 생산오더 문서의 공정 항목(작업장·시간·준비 시간)이 표준 오더의 공정 구조를 따릅니다. 생산오더 정산과 확인 입력은 표준에 남깁니다. |
COOIS | 오더 정보 시스템 | 문서 목록과 드릴스루가 같은 오더를 읽습니다. 표준 목록의 오더 수와 이 앱의 확정 문서 수를 대조하는 것이 운영 대사의 기본입니다. |
CM01 · CM21 | 능력 평가 · 능력 계획(작업장) | 분석의 부하율이 닿는 자리입니다. 같은 작업장·월의 표준 능력 평가 값과 이 앱의 부하 시간을 나란히 보고 차이를 점검합니다. |
CR01 · CR02 · CR03 | 작업장 생성 · 변경 · 표시 | 기준정보의 작업장 탭이 같은 작업장(코드·이름·가용 능력·효율)을 읽습니다. 마스터 변경은 표준 거래에서 하고 이 앱은 조회·점검을 맡는 구성도 가능합니다. |
CA03 | 라우팅 표시 | 공정 순서 탭이 닿는 자리입니다. 단위당 시간과 준비 시간이 여기서 오며, 바뀌면 부하 시간이 함께 바뀝니다. |
MM03 | 자재 표시 | 자재 탭의 그룹·단위·표준 로트가 같은 자재 마스터 값입니다. |
CO11N | 공정 확인 입력 | 실적 시간·양품·불량이 입력되는 자리입니다. 이 앱은 확인된 실적을 읽어 분석에 쓰며 확인 입력 자체는 표준에 남깁니다. |
CO88 | 생산오더 정산 | 원가 정산은 표준에 남깁니다. 이 앱의 가공비는 계획 대비 차이를 보는 분석용 값이며 정산 값이 아닙니다. |
ME53N | 구매요청 표시 | 영역 간 연계의 마지막 칸입니다. 계획오더 소요 자재가 만든 구매요청 번호를 눌러 확인하는 자리입니다. |
SM36 · SM37 | 배치 잡 등록 · 조회 | 에이전트를 사람 없이 돌리는 자리입니다. 잡이 에이전트 실행 펑션을 두드리면 화면에서 누른 것과 똑같이 감시 규칙을 점검합니다. |
지표 정의 — 숫자가 어디서 오는가
화면의 숫자가 표준 데이터의 어느 값에서 어떤 산식으로 만들어지는지 적었습니다. 표준 화면의 값과 맞춰 볼 때 이 표를 씁니다.
| 지표 | 산식 · 판정 기준 | 대응 기능 | 원천 데이터 | 비고 |
|---|---|---|---|---|
| 부하 시간 | Σ 공정 표준 시간 × 오더 수량 ÷ 기준 수량 + 준비 시간 | M1 타일 · M6 피벗 | AFVV 표준값 · AFKO 수량 | 시간 단위는 시간(h)으로 환산 |
| 가용 능력 | 일 가용 능력(h) × 월 일수 | M2 · M6 · R03 | KAKO · CRHD | 교대 · 효율은 기준정보에서 관리 |
| 부하율 | 부하 시간 ÷ 가용 능력 × 100 | M1 · M4 · M6 | 위 두 지표 | 85% 초과 주황 · 95% 초과 빨강 |
| 실적 시간 | Σ 확인된 실적 시간 | M5 R02 · M6 | AFRU | — |
| 양품 · 불량 수량 | Σ 확인 수량 · Σ 불량 수량 | M6 · 에이전트 AR03 | AFRU | 수율 = 양품 ÷ (양품 + 불량) |
| 가공비 | 실적 시간 × 작업장 시간당 가공비 | M6 · 기준 대비 차이 | AFRU · 작업장 요율 | 요율은 기준정보의 시간당 가공비 |
| 계획 대비 차이 | 실적 가공비 − 계획 가공비 | M6 기준 대비 차이 | 계획 데이터(계획오더 기준) | 계획 데이터 원천은 도입 때 확정 |
| 요인분해 | 물량 · 수율 · 능률 · 요율 네 요인으로 총차이를 가름 | M6 요인분해 · 워터폴 | 위 지표 | 요인 합 = 총차이로 매번 검산 |
원천 테이블 — 이 앱이 읽는 표준 데이터
| 테이블 | 이름 | 이 앱이 읽는 것 | 사용 모듈 |
|---|---|---|---|
| AFKO | 생산오더 헤더 | 오더 수량 · 기본 시작일 · 종료일 | M3 · M6 |
| AFPO | 생산오더 품목 | 자재 · 계획 수량 · 입고 수량 | M3 · M6 |
| AFVC | 오더 공정 | 공정 번호 · 작업장 연결 · 공정 텍스트 | M3 · M6 |
| AFVV | 공정 수량 · 값 | 표준 시간(준비 · 가공) · 기준 수량 · 확인 수량 | M3 · M6 |
| AFRU | 오더 확인 | 실적 시간 · 양품 · 불량 · 확인 일자 | M6 · R02 |
| PLAF | 계획오더 | 계획 수량 · 시작일 · 종료일 | M3 · M4 |
| RESB | 예약 · 소요 자재 | 소요 자재 수량(구매 연계) | M7 |
| EBAN | 구매요청 | 계획오더 소요 자재가 만든 구매요청 | M7 |
| VBAK · VBAP · VBEP | 판매오더 헤더 · 품목 · 납품 일정 | 수요 수량 · 납기 | M4 · M7 |
| CRHD · CRTX | 작업장 헤더 · 텍스트 | 작업장 코드 · 사업장 · 이름 · 유형 | M2 · M6 |
| KAKO | 능력 헤더 | 가용 능력 · 효율 · 작업 시간 | M2 · M6 |
| CRCO | 작업장-원가센터 지정 | 원가센터 | M2 |
| MARA · MAKT · MARC | 자재 마스터 · 텍스트 · 플랜트 데이터 | 그룹 · 단위 · 이름 · 표준 로트 | M2 |
| MAPL · PLAS · PLPO | 라우팅 지정 · 공정 지정 · 공정 | 공정 순서 · 작업장 · 표준 시간 | M2 · M3 |
S/4HANA 분석 스택과의 자리
표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office와 이 앱이 어떻게 겹치고 나뉘는지 층으로 적었습니다.
| 층 | 무엇 | 이 앱과의 관계 |
|---|---|---|
| 원천 | 생산오더(AFKO·AFPO·AFVC·AFVV)·확인(AFRU)·계획오더(PLAF)·작업장(CRHD·KAKO) | 이 앱의 큐브가 읽는 표준 테이블입니다. 앱 전용 기록(상태 이력·감사 로그·대사 결과·에이전트 대기함)만 따로 저장합니다. |
| CDS 분석 뷰 | 차원 → 큐브 → 분석 쿼리(Consumption) | 표준 Fiori 분석 앱과 Analysis for Office가 같은 쿼리를 읽을 수 있습니다. CDS 구성 절에 이 앱의 뷰 설계를 코드로 실었습니다. |
| 표준 앱 · 거래 | 능력 평가·오더 정보 시스템 등 표준 거래 | 그대로 둡니다. 특정 Fiori 분석 앱의 이름은 환경마다 다르므로 도입 시점에 확인합니다(확인 필요). |
| 이 앱 | OpenUI5 통합 관리 화면 | 승인·일괄 실행·대사·조치처럼 쓰기가 있는 흐름과, 축을 바꿔 보는 분석을 한 화면에 묶습니다. |
확장 포인트 — 운영에서 실제로 손대는 자리
| 확장 포인트 | 무엇을 손대나 | 손대는 방법 |
|---|---|---|
| 작업장 유형 매핑 | 표준 작업장 카테고리를 분석 차원(조립·가공·검사·포장·도장)으로 묶는 기준 | 매핑 테이블 한 장에 행을 더하면 됩니다. 새 카테고리가 생길 때 현업이 직접 적습니다. |
| 시간당 가공비 원천 | 작업장 요율을 활동 유형 단가에서 가져올지 별도 기준으로 둘지 | 원가 담당과 정합니다. 기준정보의 시간당 가공비를 읽는 한 곳만 바꿉니다(확인 필요). |
| 계획 데이터 원천 | 기준 대비 차이의 "계획"이 무엇인지(계획오더 × 라우팅 표준값 등) | 계획 뷰를 한 장 교체합니다. 같은 키 모양만 지키면 화면은 바뀌지 않습니다. |
| 확장 필드 | 자재·작업장에 고객사 고유 속성을 더할 때 | 표준 확장 필드(Custom Fields)로 추가한 뒤 차원 뷰에 노출하면 필터·축으로 쓸 수 있습니다. |
| BAdI · 승인 규칙 | 금액 구간·승인 단계를 회사 규칙에 맞출 때 | 현재 규칙(1,500만 원 이상 2단계)을 상태 규칙 표에서 바꾸거나 운영에서는 표준 승인 기능에 연결합니다. |
| 권한 | 사업장별로 볼 수 있는 숫자를 가를 때 | 권한 객체와 DCL로 집계 단계에서 자릅니다. 드릴스루에만 걸면 합계의 뺄셈으로 새어 나갑니다. |
CDS 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
자주 묻는 질문
도입을 검토하는 분들이 먼저 묻는 것을 네 묶음으로 모았습니다. 답은 이 글의 사례 데이터에서 확인한 범위로만 적었습니다.
숫자와 산식
부하율은 어떻게 계산됩니까?
부하율 = 부하 시간 ÷ 가용 능력 × 100 입니다. 부하 시간은 공정 표준 시간에 오더 수량을 곱해 기준 수량으로 나눈 값에 준비 시간을 더해 모으고, 가용 능력은 일 가용 능력(h)에 월 일수를 곱합니다. 효율과 교대는 작업장 기준정보에서 관리합니다.
이 사례의 개요에서는 2,563시간 ÷ 4,122시간으로 62.2%입니다. 85%를 넘으면 주황, 95%를 넘으면 빨강입니다.
요인분해의 합이 정말 총차이와 같습니까?
같습니다. 우연이 아니라 그렇게 되는 산식을 골랐습니다. 물량·수율·능률·요율 네 항을 전개하면 중간 항이 서로 지워져 실적 가공비에서 계획 가공비를 뺀 값과 정확히 같아집니다.
이 사례는 2,858,012 + 2,570,390 + 39,276,968 − 9,857,312 = 34,848,058원입니다. 화면은 이 등식을 매번 검산해 보여 주며, 맞지 않으면 그 자체가 오류 신호입니다.
능률이 왜 가장 큰 요인으로 나왔습니까?
능률은 "투입 단위당 시간이 계획보다 얼마나 더 들었나"를 계획 요율로 환산한 값입니다. 이 사례에서는 투입 단위당 시간이 계획보다 길었던 몫이 +39,276,968원으로 나왔습니다. 다만 검증용 샘플 데이터의 값이므로 실제 회사의 결과는 아닙니다. 어느 작업장·자재에서 났는지는 분석 화면에서 차원을 바꿔 가며 확인합니다.
칸 금액과 드릴스루 합계가 같습니까?
같습니다. 큐브가 원천 라인을 더해 만든 값이기 때문입니다. 이 사례에서 눌러 본 칸의 598.2시간은 32개 라인의 합과 같았고, 12개 칸을 골라 대조했을 때 차이는 모두 0이었습니다. 칸 금액과 합계가 다르면 그 즉시 점검 대상으로 봅니다.
대사 예외 15건은 오류 아닙니까?
아닙니다. 점검 화면이 실제로 어떻게 보이는지 보이려고 샘플 데이터에 일부러 넣은 예외입니다. 규칙 R01 1건 · R02 5건 · R03 3건 · R04 6건이며, 대사 차이 건수와 같은 건입니다. 예외를 뺀 나머지는 차이가 모두 0입니다.
계획 데이터는 어디서 옵니까?
이 사례에서는 계획오더의 수량에 라우팅 표준값을 곱해 계획 시간과 계획 가공비를 만듭니다. 운영에서는 계획 원천(계획오더 기준인지, 별도 계획 버전인지)과 시간당 가공비 원천을 도입 단계에서 확정해야 하며, 확인하지 못한 부분은 화면과 코드에 "확인 필요"로 남겨 두었습니다.
화면과 조작
시뮬레이션 없이 일괄 실행을 누르면 어떻게 됩니까?
서버가 거절하고 먼저 시뮬레이션을 돌리라고 안내합니다. 시뮬레이션 뒤 조건(사업장·기간)이 바뀌어도 거절하며, 같은 조건으로 시뮬레이션을 다시 돌려야 합니다. 일괄 실행은 되돌리기 어려운 일이라 순서를 고정했습니다.
같은 조건으로 두 번 실행하면 문서가 두 배로 생깁니까?
생기지 않습니다. 같은 조건으로 이미 실행했다면 처리할 수요가 없다는 메시지로 막습니다. 이 사례에서는 수요 8건이 638.06시간의 문서 8건으로 한 번만 만들어졌고, 새 수요가 들어온 뒤에 다시 시뮬레이션하면 다음 실행이 열립니다.
작성자가 자기 문서를 승인할 수 있습니까?
없습니다. 서버가 작성자와 승인자가 같으면 거절합니다. 금액이 1,500만 원 이상이면 서로 다른 승인자 두 명이 필요하고, 1단계 승인 뒤에는 상태 칸에 "1 / 2 단계"가 보입니다. 조회자는 버튼이 흐려지고 서버도 같은 기준으로 거절합니다.
마감된 기간의 문서는 어떻게 됩니까?
이 사례에서는 2026-01~08 기간이 닫혀 있고 09·10월이 열려 있습니다. 닫힌 기간에는 전기와 역처리가 서버에서 거절됩니다. 확정한 문서를 되돌릴 때는 승인자가 사유를 적어 역처리하며, 원문서와 연결된 반대 문서(금액 −1배)가 만들어지고 한 번만 가능합니다.
엑셀 업로드는 어떻게 검사합니까?
반영하기 전에 행마다 검사 결과를 미리 보여 줍니다. 이 사례의 업로드 창은 "검사 통과 3건 · 확인 필요 1건"처럼 요약하고, 통과한 행만 반영합니다. 검사에 걸린 행은 확인 필요로 표시되고, 고친 뒤 다시 올리면 됩니다.
휴대폰에서도 같은 화면이 보입니까?
보입니다. 폭이 좁아지면 왼쪽 메뉴가 아이콘으로 접히고 조회조건과 보드가 한 줄씩 쌓입니다. 숨기는 기능은 없고 가로로 넘치는 표는 스크롤합니다. 현장 태블릿으로 승인만 하는 경우를 염두에 두었습니다.
분석 기능과 AI
축을 바꿀 때마다 서버를 다시 부릅니까?
부르지 않습니다. 큐브는 이미 브라우저에 있고 축을 바꾸는 일은 그 큐브를 다시 묶는 일입니다. 서버를 다시 부르는 때는 조회를 눌렀을 때뿐입니다. 큐브가 수만 행을 넘으면 묶기를 서비스로 옮기는 것이 CDS 구성 절의 첫 번째 권고입니다.
저장한 레이아웃은 어디에 남습니까?
현재 축·조회조건·측정값·표시 행 수·접힘 상태를 이름으로 저장합니다. 기본 레이아웃과 "열 때 자동 조회"는 하나만 켤 수 있고, 이름 바꾸기와 삭제는 관리 창에서 합니다. 운영에서는 표준 변형 관리 서비스에 두는 방법도 있습니다.
AI 가 금액을 잘못 말하면 어떻게 됩니까?
그럴 자리를 두지 않았습니다. 금액과 비율은 서비스가 큐브에서 계산해 근거 표로 넘기고, 모델은 그 숫자를 읽어 설명만 합니다. 근거 표는 화면에서 펼쳐 볼 수 있어 해설의 숫자와 바로 대조되며, 모델을 붙이지 않아도 같은 근거로 규칙 기반 해설이 나옵니다.
에이전트는 무엇을 감시합니까?
감시 규칙 다섯 개입니다 — 작업장 월 부하율 상한, 양품 수량 계획 미달, 불량률 상승, 시간당 가공비 상승, 승인 대기 장기 문서. 규칙마다 기준값과 받을 역할(생산 책임자·COO·원가 책임자·자재 책임자)이 붙어 있고, 걸리면 그 역할의 대기함에 근거를 단 보고가 올라갑니다.
에이전트 보고는 자동으로 발송됩니까?
발송하지 않습니다. 보고는 앱의 대기함에 쌓이고 사람이 읽고 판단합니다. 같은 날 두 번째 실행은 "하루 한 번 제한"으로 막히고 활동 기록만 남습니다. 조회자는 에이전트를 실행할 수 없으며, 사람이 누르든 타이머나 배치가 부르든 같은 규칙을 탑니다.
도입과 운영
도입하면 어떤 효과가 있고 누가 씁니까?
생산 계획 담당자(문서·일괄 실행), 승인자(검토·승인), 생산 책임자·원가 담당(분석·대사), 관리자(기준정보·권한)가 씁니다. 효과는 이 사례에서 확인한 범위로만 말합니다 — 상태·승인 규칙을 서버가 지키고, 일괄 실행이 시뮬레이션을 거치며, 대사식이 매번 숫자를 검산한다는 점입니다. 시간 절감률 같은 수치는 실제 도입 후 측정해야 합니다.
언제부터 어디까지 적용할 수 있습니까?
확인된 것은 검증용 샘플 데이터 위에서 화면·서비스 로직·대사가 일관되게 동작한다는 사실까지입니다. 운영 시스템의 원천 연결, 권한 설계, 계획 원천 확정은 도입 단계에서 정해야 하며 시기와 소요는 환경마다 다르므로 확인이 필요합니다.
기존 표준 거래는 없애야 합니까?
대부분 없애지 않고 둡니다. 오더 생성·정산·확인 입력은 표준에 남기고, 이 앱은 그 사이의 승인·일괄 실행·대사·분석을 맡습니다. 법정·감사 대응 숫자는 표준 거래가 만든 값이어야 하므로, 이 앱의 숫자와 표준 거래의 숫자를 맞춰 보는 대사를 운영 절차로 둡니다.
표준 T-code 와는 어떻게 오갑니까?
이 앱 → 표준: 확정 문서 번호로 CO03(생산오더)·MD13(계획오더)에서 같은 오더를 열어 수량과 시작일을 대조하고, 부하는 CM01·CM21의 같은 작업장·월 값과 맞춰 봅니다. 표준 → 이 앱: 오더 번호를 문서 처리의 검색에 넣으면 상태 이력과 감사 로그를 볼 수 있습니다. 두 쪽의 건수가 다르면 R01~R04 규칙으로 먼저 좁힙니다.
데이터 원천과 정합성은 어떻게 확인합니까?
원천은 생산오더(AFKO·AFPO·AFVC·AFVV)·확인(AFRU)·계획오더(PLAF)·작업장(CRHD·KAKO)입니다. 정합성은 대사식 열 가지로 확인했습니다 — 머리·항목 시간, 계획·실적, 부하·능력, 수요·계획오더, 큐브·원천 합계, 피벗·큐브 총합, 칸·드릴스루, 요인 합·총차이, 시뮬레이션·실행 결과, 역처리 금액입니다.
외화나 환율은 어떻게 처리합니까?
이 앱의 금액은 가공비(원화)이며 환율 변환이 없습니다. 수입 자재 같은 외화 항목이 계획 원가에 필요하면 환율 유형과 환산 일자를 도입 단계에서 정해 계획 뷰에서 환산한 뒤 같은 키로 맞춥니다. 환율 변동을 평가하는 기능은 이 앱의 범위가 아닙니다.
권한과 보안은 어떻게 됩니까?
데모의 사용자 전환은 시연용입니다. 운영에서는 SAP 권한 객체와 PFCG 역할로 바꾸고 사업장 권한을 CDS 의 DCL 로 집계 단계에 겁니다. 서버가 요청의 사용자로 역할을 판정하는 구조라 대체 지점이 한 곳이며, 화면의 외부 라이브러리는 표준 컨트롤뿐이라 반입 심사 부담이 적습니다.
운영 연결 절차와 소요는 어떻게 됩니까?
순서는 이렇습니다. ① 계획 원천·요율 원천·작업장 유형 매핑을 정합니다. ② CDS 뷰(테이블·차원·큐브·쿼리·DCL·서비스)를 만들어 이송합니다. ③ 서비스를 게시하고 앱의 서비스 주소를 바꿉니다. ④ 처리 펑션을 표준에 연결하고 권한을 PFCG 로 옮깁니다. ⑤ 대사로 표준 거래와 건수를 맞춥니다. 소요는 환경과 합의 속도에 달려 있어 단정하지 않습니다.
대용량이면 느려지지 않습니까?
느려질 수 있는 곳을 미리 정했습니다. 큐브는 차원 조합 수를 따라 늘어 문서 건수와 무관하고, 먼저 막히는 곳은 원천 라인 조회입니다. 조회 조건을 필수로 하고 건수를 먼저 세며 상위 N건만 받습니다. 큐브가 수만 행을 넘으면 묶기를 서비스로 옮깁니다.
작업장 유형이나 계정 같은 매핑이 바뀌면 어떻게 합니까?
작업장 유형 매핑 테이블에 행을 더하거나 바꿉니다. 코드에 박혀 있지 않아 개발 없이 현업이 유지합니다. 새 작업장 카테고리가 생기면 어느 분석 유형으로 묶을지만 적어 주면 되고, 정기적으로 손이 가는 곳은 사실상 이 매핑 하나입니다.
이 도구의 판단을 최종 결과로 써도 됩니까?
이 앱은 업무 처리와 분류·집계·대사를 돕는 점검 도구이며, 최종 판단은 회사와 감사인이 합니다(세무 신고는 회사와 세무 대리인·관세사). 법정·공시·감사 대응에 쓰는 숫자는 SAP 표준 거래가 만든 값을 쓰고, 이 앱의 숫자는 그것을 점검하고 설명하는 데 씁니다.