MES 커스터마이징 비용을 줄이는 출발점은 견적서를 다시 받는 일이 아니라 변경을 누가 손댈 수 있는지를 옮기는 일입니다. 같은 성격의 수정이 해마다 발주로 나가는 곳은 작업이 어려워서가 아니라, 바꿀 권한과 판단 근거가 모두 밖에 있어서 그렇게 되는 경우가 적지 않습니다. 아래에 변경이 생기는 지점별로 내부에서 처리할 수 있게 만드는 방법과, 계약·유지보수 문서에서 확인할 항목을 표로 정리했습니다.
개발비가 매번 나가는 곳에는 같은 패턴이 있습니다
지출이 반복되는 현장을 들여다보면 작업 목록보다 경로가 먼저 눈에 들어옵니다.
첫째는 권한입니다. 제품에 설정 화면이 있는데 그 메뉴를 열 수 있는 계정이 구축 업체에만 있으면, 사용자 한 명을 추가하는 일조차 요청서로 나갑니다. 기능이 없어서 생긴 비용이 아니라 접근 경로 때문에 생긴 비용입니다.
둘째는 기준정보입니다. 품목·거래처·공정 코드가 부서마다 다른 규칙으로 쌓여 있으면 화면 하나를 바꿀 때마다 예외 처리를 따로 만들게 되고, 그 예외가 다음 변경의 범위를 다시 넓힙니다. 자료가 정리되지 않은 상태에서 화면만 손대면 손댈 곳이 매번 늘어납니다.
셋째는 기록입니다. 지난 수정이 어떤 범위였는지 남아 있지 않으면 새 요청마다 현황 조사부터 다시 시작합니다. 실제 작업보다 조사에 들어가는 몫이 커지고, 담당자가 바뀌면 그 조사를 또 한 번 하게 됩니다.
그래서 금액을 놓고 하는 협의는 한 건에만 효과가 있습니다. 구조를 그대로 두면 다음 요청이 같은 경로로 또 나갑니다. 줄여야 하는 것은 한 번의 견적이 아니라 외부로 나가는 요청의 건수입니다.
변경이 생기는 지점을 나눠서 봅니다
| 변경이 생기는 지점 | 지금 누가 바꾸고 있는가 | 내부에서 바꿀 수 있게 만드는 방법 |
|---|---|---|
| 사용자 추가·권한 변경 | 업체 계정으로만 열리는 메뉴가 있다 | 관리자 권한을 사내 담당자 계정으로 분리해 받는다 |
| 품목·거래처·공정 코드 등록 | 요청서로 넘겨 처리한다 | 등록 규칙을 정해 사내에서 처리하고 중복 정리 주기를 둔다 |
| 조회 화면의 항목·검색 조건 | 화면별로 개발로 처리해 왔다 | 사용자별 조회 설정 기능이 있는지 확인하고 사용법을 인수받는다 |
| 출력 양식(전표·라벨·보고서) | 서식이 바뀔 때마다 발주한다 | 양식 편집 도구 보유 여부를 확인하고 편집 권한을 받는다 |
| 집계·지표 계산 규칙 | 전부 개발 범위로 들어간다 | 자주 바뀌는 기준은 설정값으로 빼 달라고 설계 단계에서 요청한다 |
| 설비 신호 수집 항목 | 설비마다 개별 작업으로 처리한다 | 통신 방식과 항목 정의를 문서로 받아 다음 설비에 같은 틀을 쓴다 |
| 거래처 전송 서식 | 거래처가 늘 때마다 추가 작업이 생긴다 | 서식을 틀과 값으로 분리해 두고 신규 거래처는 값만 등록한다 |
| 알림·결재 조건 | 조건이 바뀔 때마다 요청한다 | 조건을 규칙 표로 관리할 수 있는 구조인지 확인한다 |
| 신규 보고서 | 모두 발주로 처리한다 | 자료 내보내기와 집계 도구로 대체 가능한지 먼저 본다 |
표를 채워 보면 대개 두세 줄은 "이미 제품에 기능이 있는데 권한이 없었다"로 정리됩니다. 되돌릴 수 있는 작업부터 사내로 가져오는 것이 먼저이고, 집계 규칙이나 데이터 구조처럼 지난 자료까지 영향을 받는 구간은 책임 경계를 문서로 정한 뒤에 옮기는 편이 안전합니다.
반복 지출은 문서에서 먼저 줄어듭니다
| 계약·유지보수 문서에서 확인할 항목 | 적혀 있어야 하는 내용 | 비어 있을 때 따라오는 결과 |
|---|---|---|
| 설정 권한의 범위 | 사내 담당자가 직접 다룰 수 있는 메뉴 목록 | 설정으로 끝나는 일도 요청·대기·비용을 거칩니다 |
| 확장 지점 | 표준을 고치지 않고 얹을 수 있는 자리와 방식 | 표준 화면을 직접 수정해 버전 변경 때 재작업 범위가 생깁니다 |
| 유지보수 포함 범위 | 포함되는 변경과 별도 산정되는 변경의 구분 기준 | 같은 성격의 작업인데 매번 산정 방식이 달라집니다 |
| 산출물 인수 목록 | 화면 정의·데이터 항목 정의·인터페이스 정의의 제공 범위 | 담당자가 바뀌면 현황 조사부터 다시 비용이 듭니다 |
| 데이터 접근 수단 | 자료 조회와 내보내기 권한, 허용 방법 | 단순 자료 추출까지 요청으로 나갑니다 |
| 변경 이력 기록 | 누가 언제 무엇을 바꿨는지 남는 자리 | 원인 추적이 어려워 조사부터 다시 맡기게 됩니다 |
| 버전 변경 시 책임 | 추가 작업을 새 버전에 다시 맞추는 주체와 부담 | 올릴 때마다 범위 협의를 처음부터 다시 합니다 |
| 교육·인수 인계 | 설정 작업 교육 대상과 횟수, 자료 제공 여부 | 권한만 받고 쓰지 못해 다시 요청으로 돌아갑니다 |
이 항목들은 구축이 끝난 뒤에 추가하기가 어렵습니다. 아직 발주 전이라면 제안 요청서에 그대로 넣고, 이미 운영 중이라면 다음 유지보수 갱신 시점이 손댈 수 있는 자리입니다.
어디부터 손대면 되는가
순서는 조사 → 권한 → 자료 → 문서입니다.
먼저 최근 1년간 업체에 보낸 요청과 발주 내역을 한 장에 모아 성격별로 묶습니다. 같은 지점이 세 번 이상 반복되면 그곳이 구조를 바꿀 대상입니다. 다음으로 되돌릴 수 있는 설정 권한을 담당자 한 명에게 받고, 작업 순서를 몇 줄짜리 절차서로 남깁니다. 권한만 받고 절차가 없으면 결국 쓰지 않게 됩니다. 그 뒤에 코드와 기준정보의 등록 규칙을 정하고 중복을 정리합니다. 마지막으로 확장 지점과 유지보수 포함 범위를 문서에 반영합니다.
줄어드는 폭은 제품 구조와 현재 권한 상태, 기준정보 정비 수준에 따라 달라지므로 일반적인 수치로 말하기는 어렵습니다. 현장 진단 단계에서 요청 내역을 함께 분류하면 어느 지점이 반복 지출을 만들고 있는지, 그중 권한 이관과 설정으로 닫을 수 있는 범위가 어디까지인지 산출해 드립니다.
FAQ
자주 묻는 질문
- 커스터마이징을 아예 하지 않고 표준 기능만 쓰는 편이 비용 면에서 낫습니까?
- 전부 표준으로 맞추는 것이 늘 유리하다고 말하기는 어렵습니다. 기준은 그 업무가 우리 제품이나 고객 요구 때문에 생긴 고유한 절차인지, 아니면 그동안 손으로 해 와서 굳어진 순서인지입니다. 거래처가 요구하는 서식이나 인증 기록처럼 바꿀 수 없는 조건에서 나온 업무는 맞추는 작업이 필요합니다. 반대로 담당자가 익숙해서 유지해 온 입력 순서나 화면 배치는 표준에 맞추는 편이 유지 비용 면에서 가벼운 경우가 많습니다. 실무적으로는 처음 구축에서 표준 기능으로 운영을 시작하고, 몇 달 쓰면서 실제로 걸리는 지점만 모아 손대는 방식이 범위가 덜 번집니다. 쓰기 전에 상상으로 적은 요구사항은 쓰기 시작하면 상당수가 바뀝니다.
- 소스코드를 받아 두면 다음 변경 비용이 줄어듭니까?
- 소스를 보유하는 것과 변경 비용이 줄어드는 것은 바로 이어지지 않습니다. 코드를 받아도 그것을 읽고 고칠 사람과 시험할 환경이 없으면 쓰이지 않고, 다른 업체에 맡기더라도 구조를 파악하는 시간이 처음부터 다시 듭니다. 실제로 다음 변경을 가볍게 만드는 것은 소스보다 설계 자료입니다. 화면과 데이터 항목 정의, 인터페이스 규격, 집계 규칙 문서가 있으면 누가 맡아도 조사 구간이 짧아집니다. 소스 보유가 의미 있는 경우는 사내에 개발 인력이 있거나, 업체가 바뀔 가능성을 전제로 이관 절차까지 계약에 적어 둔 경우입니다. 보유 여부를 정할 때는 함께 받을 자료와 빌드·배포 방법이 포함되는지 확인하시는 것이 좋습니다.
- 유지보수 계약에 포함되는 변경과 별도 비용이 나가는 변경은 어떻게 나뉩니까?
- 계약서 문구에 따라 다르므로 일반적인 선을 말하기는 어렵고, 문서에서 구분 기준을 확인하는 것이 확실합니다. 대개 장애 복구, 오류 수정, 환경 변경에 따른 대응은 포함 범위로 적히고, 새 화면·새 집계·새 인터페이스는 별도 산정으로 적힙니다. 문제가 생기는 지점은 그 사이입니다. 기존 화면에 항목 하나를 더하는 일이나 양식 수정이 어느 쪽인지 적혀 있지 않으면 같은 성격의 작업에도 매번 다른 답이 돌아옵니다. 그래서 갱신 시점에 확인하실 것은 두 가지입니다. 포함과 별도를 가르는 기준이 예시와 함께 적혀 있는지, 그리고 월 또는 연간으로 포함되는 작업량의 단위가 정해져 있는지입니다. 기준을 문서로 고정하면 건마다 협의하는 시간이 줄어듭니다.
- 기준정보를 정리하면 커스터마이징이 줄어든다는 말은 무슨 뜻입니까?
- 품목·거래처·공정·불량 사유 같은 코드가 규칙 없이 쌓여 있으면, 화면을 바꾸는 작업마다 예외 처리가 따라붙습니다. 같은 품목이 두 가지 코드로 등록되어 있거나 공정 이름이 부서마다 다르면 집계 화면 하나를 만들 때도 그 둘을 묶는 처리를 따로 만들어야 하고, 그 처리가 다음 변경에서 또 손댈 자리가 됩니다. 반대로 등록 규칙과 중복 정리가 되어 있으면 같은 요청이 표준 기능의 설정 범위에서 끝나는 경우가 생깁니다. 정리 작업은 한 번에 전부 할 필요가 없습니다. 최근 요청에서 가장 많이 등장한 코드 영역부터 등록 규칙을 정하고, 중복을 묶고, 앞으로 누가 등록할지 담당을 정하는 순서로 하시면 됩니다.
- 화면을 직접 만들 수 있다고 안내하는 제품은 비용 절감에 도움이 됩니까?
- 도움이 되는 범위가 제품마다 다르므로 기능 설명만으로 판단하기는 어렵습니다. 확인하실 것은 세 가지입니다. 첫째, 직접 만들 수 있다는 범위가 어디까지인지입니다. 조회 화면과 보고서까지인 경우와, 입력·검증·집계까지 다룰 수 있는 경우는 차이가 큽니다. 둘째, 그 작업을 할 사람이 사내에 있는지입니다. 도구가 있어도 담당자가 정해져 있지 않으면 결국 외부 요청으로 돌아갑니다. 셋째, 그렇게 만든 화면이 제품 버전을 올릴 때 어떻게 되는지입니다. 시연을 보실 때는 미리 준비된 예제 대신 우리 업무에서 실제로 자주 나오는 변경 한 건을 그 자리에서 만들어 보여 달라고 요청하시면 범위가 분명해집니다.
근거·참고
제도와 기준의 원본
- 스마트공장 사업관리시스템
정부 스마트공장 보급사업의 공고·신청·공급기업 목록이 있는 곳. 지원금 조건을 여기서 확인합니다.
- 중소기업 기술개발사업 종합관리시스템
기술개발 과제 공고와 신청 창구. 설비·시스템 도입을 과제로 묶을 때 확인합니다.
현장에 맞는 답이 필요하시면
이 글은 일반적인 기준을 정리한 것입니다. 공정과 설비를 직접 보고 해당 현장의 조건에 맞춰 범위를 잡아 드립니다.
MORE
함께 보면 좋은 글
- 조선기자재 생산관리시스템 구축 비용, 호선·블록 범위가 기준입니다
조선기자재 생산관리시스템 구축 비용은 사용자 수보다 호선·블록·품목의 연결 깊이와 자재·외주·검사 기록의 연동 범위에서 달라집니다. 거제·통영 생산관리 진단 경험을 바탕으로 견적 전에 정할 관리 단위와 구축 기준을 정리했습니다.
- 스마트공장 지원사업에 선정되고도 구축업체를 못 구하면 어떻게 하나
스마트공장 지원사업에 선정되고도 구축업체를 못 구하면 선정 여부보다 협약서의 남은 기간부터 셉니다. 업체가 견적을 미루는 이유와 바꿀 수 있는 조건, 요구사항을 한 장으로 적는 방법, 남은 기간을 역산하는 순서를 정리했습니다.
- MES 추가개발 비용 부담은 쌓인 변경 요청을 분류하는 데서 갈립니다
쓰면서 바꾸고 싶은 요청이 쌓였다면 견적을 깎기 전에 설정·운영·추가개발·보류로 나눠야 합니다. 요청을 나누는 기준과 요청서에 적어야 할 항목, 묶어서 발주할 때 확인할 것을 표로 정리했습니다.