모듈형 생산 계획 소프트웨어: 먼저 추가할 모듈

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

모듈형 생산 계획 소프트웨어를 사용하면 성장하는 공장이 계획 계층을 단계적으로 추가할 수 있습니다. 어떤 모듈이 있는지, 모듈끼리 무엇을 공유하는지, 무엇을 먼저 추가해야 하는지 살펴봅니다.

Automatically translated with AI from the original post. Read the English original

모듈형 생산 계획 소프트웨어는 계획을 마스터 일정, 자재 계획, 유한 능력 일정 계획, 현장 피드백, 보고 등의 모듈로 나눕니다. 따라서 가장 큰 문제를 해결하는 모듈부터 시작하고, 공장이 성장함에 따라 나머지를 추가할 수 있습니다. 다만 모듈이 제 역할을 하려면 같은 데이터를 공유하고 같은 계획에 합의해야 한다는 점이 관건입니다. 이 글은 첫 모듈을 골라야 하면서 짜깁기 구성은 피하고 싶은 제조 공장의 생산 계획 담당자를 위한 글입니다.

핵심 포인트

• 모듈형 생산 계획 소프트웨어는 계획을 마스터 일정, 자재 계획, 유한 능력 일정 계획, 현장 피드백, KPI 등의 계층으로 나눕니다.
• 모듈은 품목, 자재명세서(BOM), 공정 경로, 자원, 달력 데이터를 하나의 세트로 공유할 때만 함께 제대로 작동합니다.
• 부품 부족, 실행할 수 없는 일정, 아무도 따르지 않는 계획, 가시성 부족처럼 가장 큰 손실을 일으키는 증상을 해결하는 모듈을 먼저 추가합니다.
• 모듈형이 공유 데이터를 갖춘 하나의 스위트를 뜻하는지, 인터페이스로 연결된 별개 제품을 뜻하는지 모든 공급업체에 확인하십시오. 답에 따라 통합 작업량이 크게 달라집니다.
• 나머지 모듈을 구매하기 전에, 두 모듈에 걸쳐 제품군 하나를 처음부터 끝까지 시범 적용합니다.

계획 소프트웨어에서 "모듈형"은 무엇을 의미합니까?

공급업체는 이 용어를 두 가지 방식으로 사용하므로, 지금 듣고 있는 것이 어느 쪽인지 확인해야 합니다.

첫째는 하나의 데이터베이스를 공유하는 모듈들로 이루어진 스위트입니다. 위키백과의 제조 자원 계획 설명이 이 개념을 잘 보여줍니다. MRP II는 기준 생산 일정, 품목 마스터와 자재명세서, 생산 자원 데이터, 자재 소요 계획, 현장 관리, 능력 계획 등의 모듈로 구성되며, 이 모듈들은 공통 데이터를 공유해 정보를 자유롭게 교환합니다. 정의상 완전히 통합되어 있거나, 적어도 완전히 인터페이스로 연결되어 있습니다.

둘째는 각자 한 계층에 강점을 가진 별개 제품들을 인터페이스로 연결한 구성입니다. 나중에 한 부분을 교체할 자유가 있지만, 구성 요소 사이의 데이터 매핑과 테스트는 직접 책임져야 합니다.

어느 쪽이 틀린 것은 아닙니다. 차이는 작업이 어디에 쌓이는지에 있습니다. 스위트에서는 작업이 구성(configuration)에 있고, 별개 제품에서는 통합에 있습니다. 가격을 비교하기 전에 어느 쪽을 구매하는지부터 확인하십시오.

어떤 계획 계층이 모듈이 될 수 있습니까?

계획 담당자의 업무는 몇 개의 계층을 거치며, 각 계층이 모듈이 될 수 있습니다. 제품마다 이름은 다르지만 논리는 변하지 않습니다.

• 마스터 일정. 기준 생산 일정은 기간별로 생산할 제품을 정합니다. 위키백과에 따르면 입력값에는 예측 수요, 판매 주문, 재고 수준, 공급, 로트 크기, 리드 타임, 능력이 포함되며, 이를 바탕으로 자재 소요 계획이 작동합니다.
• 자재 계획. 이 계층은 수요를 재고와 미입고 공급량에 대조하고 오더를 제안합니다. Dynamics 365에서는 이를 마스터 계획이라고 부르며, Microsoft 문서에서는 가용 자재와 용량을 필요량과 결합해 소요량을 계산하고, 계획자가 변경할 수 있는 계획 오더를 생성하는 기능으로 설명합니다. 일상적인 보충을 위한 순소요량 계획과 장기 수요를 위한 수요 예측 계획을 구분합니다.
• 유한 일정 계획. 이 계층은 실제 제약 조건을 반영해 자원에 오더를 시간 순서대로 배치합니다. Wikipedia에서는 고급 계획 및 일정 계획(APS)을 자재와 용량을 함께 계획하고 제약 조건을 고려하는 방식으로 설명합니다. 반면 기존 MRP 방식의 시스템은 이 둘을 따로 계획하므로, 실행할 수 없는 계획이 만들어질 수 있습니다.
• 실행 및 피드백. 이 계층은 현장 관리자에게 작업을 전달하고, 실제로 무슨 일이 일어났는지 보고합니다.
• KPI 및 검토. 리드 타임, 가동률, 정시 납품율을 계획과 비교합니다.

두 번째와 세 번째 계층 사이의 차이를 살펴보십시오. 많은 지연 오더가 여기서 비롯되기 때문입니다. Microsoft 문서에 따르면, 계획 생산 오더는 품목 레코드의 정적 리드 타임을 사용하는 반면, 자원 제약을 고려한 라우팅 기반 일정은 오더가 확정될 때 수행됩니다. 따라서 계획과 확정 오더 사이에서 리드 타임이 달라질 수 있습니다. 이는 결함이 아닙니다. 계획 계층마다 서로 다른 정보를 사용할 때 발생하는 현상이며, 유한 일정 계획 모듈을 검토할 만한 이유이기도 합니다.

어떤 모듈을 먼저 도입해야 할까요?

기능 목록이 아니라, 가장 큰 비용을 초래하는 증상에서 출발하십시오.

1. 자재가 부족하거나 과다하게 보유합니다. 자재 계획부터 시작하고, 재고 및 리드 타임 데이터를 정리하십시오.
2. 자재는 있지만 오더가 여전히 늦게 출하됩니다. 계획이 용량을 고려하지 않고 있습니다. 유한 일정 계획을 검토하십시오.
3. 화면상 일정은 괜찮아 보이지만 아무도 따르지 않습니다. 실행 피드백이 필요합니다. 그래야 계획자가 지연을 당일에 파악할 수 있습니다.
4. 모두가 숫자를 두고 논쟁합니다. 새로운 계획 로직을 도입하기 전에, 합의된 정의를 갖춘 KPI 계층을 추가하십시오.
5. 변경이 도움이 될지 판단할 수 없습니다. MRP II 설명에서도 언급되는 시뮬레이션과 같은 가정 분석 기능은 나중에 도입해도 됩니다.

첫 적용 범위는 단일 부서보다 단일 제품군이 더 적절합니다. 그래야 한 개 모듈이 실제 납품 성과에 미치는 효과를 확인할 수 있습니다.

모듈들은 무엇을 공유해야 합니다까?

아키텍처와 관계없이, 모듈들은 다음 소수의 마스터 데이터에 대해 일치해야 합니다.

• 품목 마스터와 자재 명세서(BOM),
• 라우팅과 공정 시간,
• 자원, 작업 센터 및 그 달력,
• 교대 모델과 가용 기술,
• 오더 상태와 그 의미.

두 모듈이 이 중 어느 하나라도 각자의 복사본을 가지고 있다면, 몇 달 안에 서로 어긋나게 됩니다. 각 객체의 마스터 모듈을 정하고, 현장과 기록이 다를 때 누가 이를 수정할지도 함께 정하십시오.

데모에서 이를 직접 검증하십시오. 공급업체에 한 모듈에서 라우팅 시간을 변경해 보여 달라고 요청하고, 그 변경이 다른 모듈의 어디에 반영되는지, 그리고 얼마나 걸리는지 확인하십시오. 답이 "내보내기 후에"라면, 실제 통합 작업량을 알게 된 것입니다.

예시: 하나의 라우팅, 두 개의 답

이 예시는 측정된 결과가 아니라 가상의 사례입니다. 한 공장이 기존 자재 계획 옆에 유한 일정 계획 모듈을 추가합니다. ERP에 등록된 브래킷의 라우팅에는 밀링 공정이 15분으로 되어 있습니다. 그런데 일정 계획 모듈은 스프레드시트를 기준으로 설정되었고, 그 값은 22분입니다. 셋업과 디버링 이후 작업자가 실제로 체감하는 시간이 그만큼이기 때문입니다.

자재 계획은 브래킷을 목요일에 출하할 수 있다고 약속합니다. 일정 계획은 월요일이라고 표시합니다. 두 모듈 모두 자신의 데이터 기준으로는 올바르게 작동하고 있지만, 계획자는 매주 한 시간을 들여 그 이유를 설명합니다. 해결책은 더 나은 알고리즘이 아닙니다. 합의된 하나의 시간값을 정하고, 한 사람이 책임지며, 두 모듈이 모두 읽는 한 곳에 저장하는 것입니다.

모든 것을 다시 하지 않고 어떻게 확장할까요?

성장은 보통 제품 수 증가, 교대 증가, 두 번째 라인 또는 다른 사이트의 추가를 의미합니다. 다음 네 가지 방식으로 이에 대비하십시오.

• 계획 기간을 명확하게 구분하십시오. Microsoft에 따르면 마스터 스케줄링은 일반적으로 1주에서 6개월 범위를 다루며, 대부분의 기업에서는 관련 제품의 가장 긴 누적 리드타임까지 확장됩니다. 어떤 모듈이 어떤 계획 기간을 담당하는지 파악해 두면, 단기 일정을 장기 계획으로 혼동하는 일을 막을 수 있습니다.
• 두 번째 사업장은 먼저 문서로 계획하십시오. Microsoft 문서는 사업장 간 계획을 법인 사이의 수요와 공급을 연결하는 별도의 프로세스로 소개합니다. 두 번째 공장이 생길 것으로 예상된다면, 후보 솔루션이 이를 어떻게 처리하는지 확인하십시오.
• 커스텀 코드보다 설정을 우선하십시오. 모든 사용자 지정 규칙은 업그레이드할 때마다 다시 테스트해야 합니다.
• 데이터가 늘어날 때 실행이 어떻게 달라지는지 확인하십시오. Microsoft에 따르면 Planning Optimization으로 만든 계획은 재생성 방식이어서, 변경된 요구사항만이 아니라 모든 요구사항을 갱신합니다. 공급업체에는 현재 물량의 두 배 규모에서 전체 계획 실행에 얼마나 걸리는지 물어보십시오.

공급업체는 어떻게 선택하고 테스트합니까?

모든 모듈에 적용할 수 있는 질문은 다음과 같습니다.

1. 이 모듈은 어떤 시스템의 어떤 데이터를 읽고 쓰나요?
2. 긴급 주문, 설비 고장, 작업자 결원이 발생하면 계획은 어떻게 바뀌나요? 전문가 없이도 계획 담당자가 재계획할 수 있나요?
3. 계획 담당자가 모듈이 주문을 그 위치에 배치한 이유를 확인할 수 있나요? 블랙박스 방식의 계획은 현장 회의에서 설명하기 어렵습니다.
4. 업그레이드는 어떻게 처리되며, 이후 인터페이스는 누가 테스트합니까?
5. 다음 모듈을 연결하는 데 드는 비용은 라이선스 비용 외에 얼마인가요?
6. 계획과 마스터 데이터를 활용 가능한 형식으로 내보낼 수 있나요?

그다음에는 파일럿을 진행하십시오. 제품군 하나와 2주간의 실제 주문을 선택합니다. 후보 모듈로 계획을 세우고, 현재 방식으로도 계획을 세운 뒤, 두 결과를 실제 결과와 비교하십시오. 수작업 보정 횟수와 준비에 든 시간 같은 작업량도 함께 기록하십시오.

흔한 실수

• 모든 모듈을 한 번에 구매하기. 어떤 모듈이 도움이 되었는지 구분할 수 없고, 데이터 작업이 한꺼번에 몰리게 됩니다.
• 증상과 맞지 않는 모듈부터 시작하기. 잘못된 자재명세서(BOM)를 기반으로 한 유한 능력 스케줄러는 정밀하지만 잘못된 결과를 냅니다.
• 마스터 데이터를 두 벌 유지하기. 모듈 간 데이터가 어긋나고, 결국 어느 쪽도 신뢰받지 못합니다.
• 사람 계층을 무시하기. 계획 담당자는 계획이 왜 그렇게 나왔는지 알아야 합니다. 그렇지 않으면 계획을 임의로 수정하게 됩니다.
• 인터페이스 담당자 부재. 업그레이드로 인터페이스가 깨져도 책임질 사람이 없습니다.
• 현재 물량만 기준으로 계획하기. 계약하기 전에 다음 제품군이나 다음 교대 체계에 대해 물어보십시오.

Polaris의 위치

모듈로 구성된 생산 계획 스택을 찾고 계신다면 iFAKT Polaris를 살펴볼 만합니다. iFAKT는 Polaris를 ERP 데이터와 제조 디지털 트윈을 결합하고 7개 모듈로 구성된 생산 소프트웨어로 소개합니다. Polaris Designer는 제품, 공정, 자원의 지식 그래프를 구축해 공유 기준 정보(source of truth)로 활용합니다. Polaris Optimizer는 자원, 교대, 구역, 자격, 생산 능력 같은 제약 조건 안에서 생산 계획을 생성합니다. 다른 후보 제품과 마찬가지로, 자사 데이터로 제품군 하나에 대해 직접 시험해 보십시오.

함께 살펴볼 관련 주제

• 마스터 데이터 품질. 라우팅과 자재명세서를 누가 관리하며, 오류를 어떻게 바로잡는지 정합니다.
• 유한 능력 계획과 무한 능력 계획. 자재 계획만으로 충분한 경우와 그렇지 않은 경우를 살펴봅니다.
• 계획 기간과 동결 구간. 각 계층이 얼마나 앞서 계획하는지, 그리고 일정이 언제 더 이상 바뀌지 않는지 다룹니다.
• 시나리오 계획. 확정하기 전에 두 계획을 비교하는 방법입니다.
• 다중 사업장 계획. 공장 간에 수요와 공급을 공유할 때 달라지는 점을 다룹니다.

다음 단계

모듈형 생산 계획 소프트웨어는 증상에 맞춰 모듈을 고를 때 효과를 발휘합니다. 공장에서 가장 큰 계획 문제가 무엇인지 적고, 그 문제가 어느 계층에 속하는지 찾은 다음, 두 공급업체에 자사 제품군 하나로 해당 모듈이 어떻게 작동하는지 보여 달라고 요청하십시오.