MES를 이미 쓰고 있는데 바꾸고 싶은 것이 쌓였을 때 추가개발 비용 부담을 줄이는 출발점은 견적을 깎는 협의가 아니라 올라온 요청을 설정·운영방식·추가개발·보류로 나누는 일입니다. 목록을 한 덩어리로 넘기면 받는 쪽은 전부 개발 범위로 계산하지만, 나눠 보면 설정 화면에서 끝나는 요청과 쓰는 방식만 바꾸면 해소되는 요청이 섞여 있는 경우가 적지 않습니다. 아래에 올라온 요청을 나누는 기준과, 요청서에 적어야 할 항목을 표로 정리했습니다.
쌓이는 동안 불어나는 것은 금액이 아니라 범위입니다
쓰다 보면 "이 화면에 거래처별 합계가 같이 나오면 좋겠다", "출하 전표 양식을 바꿔 달라", "불량 사유를 더 세분해서 고르고 싶다" 같은 말이 현장에서 하나씩 올라옵니다. 그때마다 업체에 묻기가 번거로워 메모로 모아 두고, 몇 달 뒤 한꺼번에 전달하는 흐름이 흔합니다. 문제는 이 목록이 요청자의 말 그대로 넘어간다는 점입니다. 받는 쪽에서는 한 문장이 설정 변경인지 화면 추가인지 데이터 구조 변경인지 알 수 없으므로, 대부분 가장 넓은 범위를 가정해 회신합니다. 금액이 커지는 첫 번째 이유는 작업의 난도가 아니라 범위가 말로만 적혀 있다는 것입니다.
두 번째 이유는 요청끼리 겹친 부분이 정리되지 않은 채 넘어가는 것입니다. 집계 기준을 바꾸는 요청과 출력 양식을 바꾸는 요청이 같은 화면을 건드리는데도 따로 적혀 있으면 같은 작업이 두 건으로 계산될 수 있습니다. 반대로 서로 충돌하는 요청이 함께 들어가 있으면 개발 중에 판단을 묻는 일이 반복되고 기간이 늘어납니다. 요청을 화면·전표·집계 단위로 묶고 충돌을 걸러내는 작업은 업체가 아니라 쓰는 쪽에서만 할 수 있는 일입니다.
올라온 요청을 네 갈래로 나눕니다
| 현장에서 올라온 요청 | 먼저 확인할 것 | 처리 갈래 |
|---|---|---|
| 조회 조건에 항목을 더 넣고 싶다 | 숨은 항목이나 사용자별 조회 설정에 이미 있는지 확인한다 | 대부분 설정 |
| 출력 양식에 항목을 추가하고 싶다 | 양식 편집 기능이 있는지, 그 권한이 누구에게 있는지 본다 | 기능이 있으면 설정(권한 조정) |
| 불량 사유를 더 세분하고 싶다 | 코드 등록으로 끝나는지, 집계 규칙까지 바뀌는지 구분한다 | 코드는 설정 · 집계 변경은 추가개발 |
| 입력 단계를 줄이고 싶다 | 지금 순서가 규정 때문인지 습관 때문인지 확인한다 | 습관이면 운영방식 변경 |
| 따로 쓰는 엑셀 표를 시스템에 넣고 싶다 | 그 표를 쓰는 사람 수와 사용 횟수를 센다 | 빈도가 높으면 묶어서 추가개발 |
| 설비 수치를 자동으로 받고 싶다 | 설비에 신호를 꺼낼 출력 단자·통신 방식이 있는지 먼저 본다 | 확인 후 추가개발 |
| 거래처가 요구하는 서식으로 보내고 싶다 | 서식이 고정인지, 요구하는 거래처가 늘어날지 본다 | 늘어날 전망이면 양식 틀로 설계 |
| 화면 배치를 바꾸고 싶다 | 불편의 원인이 배치인지 권한·속도인지 나눠 본다 | 원인이 배치가 아니면 보류 |
| 지난 자료를 다른 기준으로 다시 집계하고 싶다 | 과거 자료에 그 기준에 필요한 항목이 남아 있는지 확인한다 | 항목이 없으면 수집부터 · 집계는 보류 |
나누는 작업의 효과는 금액보다 협의의 성격이 바뀌는 것에서 먼저 나타납니다. "스물세 건을 개발해 달라"가 아니라 "여덟 건은 우리가 설정으로 처리하고, 네 건은 운영 방식을 바꿔 닫고, 여섯 건을 같은 화면 묶음으로 발주한다"가 되면 업체도 무엇을 만들면 끝인지 알고 답할 수 있습니다. 남은 요청만 다루므로 검토에 걸리는 시간도 줄어듭니다.
요청서에 적는 항목이 견적의 폭을 좁힙니다
| 요청서 항목 | 적는 방법 | 빠지면 생기는 일 |
|---|---|---|
| 누가 언제 쓰는 화면인지 | 사용 역할과 하루 사용 횟수를 적는다 | 급한 요청과 아쉬운 요청이 같은 순서로 처리됩니다 |
| 지금은 어떻게 처리하는지 | 현재 손으로 하는 절차를 단계로 적는다 | 개발 뒤에도 기존 수작업이 그대로 남습니다 |
| 바뀐 뒤 화면에 무엇이 보이면 되는지 | 항목 이름과 예시 값을 함께 적는다 | 완성 기준이 없어 인수 단계에서 요청이 다시 생깁니다 |
| 함께 바뀌는 곳 | 같이 영향받는 화면·전표·집계를 적는다 | 누락된 화면이 2차 요청으로 돌아옵니다 |
| 과거 자료 적용 범위 | 바뀐 기준을 지난 자료에 적용할지 정해 적는다 | 범위를 뒤늦게 정해 재작업이 생깁니다 |
| 외부 제출 여부 | 거래처·기관으로 나가는 문서인지 표시한다 | 서식 요건을 모른 채 만들어 다시 고칩니다 |
| 필수와 선택 구분 | 꼭 필요한 것과 있으면 좋은 것을 나눠 적는다 | 전부 필수로 간주되어 범위가 넓어집니다 |
| 확인 방법 | 어떤 자료로 맞는지 검증할지 미리 적는다 | 검수 없이 넘겨받아 운영 중에 문제를 발견합니다 |
여기서 가장 자주 빠지는 것이 필수와 선택의 구분과 확인 방법입니다. 둘이 없으면 업체는 적힌 모든 문장을 만들어야 하는 것으로 보고, 완성 여부도 판단할 수 없어 여유를 넉넉히 둔 범위로 회신하게 됩니다. 효과를 숫자로 적기는 어렵지만, 같은 요청을 이 여덟 항목으로 다시 쓰면 돌아오는 회신의 범위가 좁아지는 쪽으로 움직입니다. 우리 현장에서 어느 정도로 좁아지는지는 현장 진단 단계에서 요청 목록을 함께 보며 산출해 드립니다.
묶어서 발주하기 전에 확인할 것
나눈 결과를 가지고 발주할 때는 세 가지를 문서에 남기시는 편이 안전합니다. 첫째, 표준 기능과 우리 쪽 변경의 경계입니다. 제품의 표준 화면을 직접 고치는 방식인지, 별도 화면·추가 항목으로 얹는 방식인지에 따라 나중에 제품 버전을 올릴 때 다시 손봐야 하는 범위가 달라집니다. 이 구조는 제품과 계약마다 다르므로 일반적인 설명으로 단정하지 말고 우리 계약과 구축 문서에서 직접 확인하셔야 합니다.
둘째, 인수 기준과 검증 자료입니다. 무엇을 보고 완료로 볼지, 어떤 기간의 실제 자료로 맞춰 볼지를 발주 시점에 함께 적으면 인수 단계에서 요청이 한 번 더 늘어나는 일을 줄일 수 있습니다. 셋째, 완료 뒤 유지보수 범위에 들어가는지입니다. 추가개발한 화면이 기존 유지보수 계약에 포함되는지, 별도 항목으로 분리되는지를 적어 두지 않으면 다음 갱신에서 같은 논의를 처음부터 다시 하게 됩니다.
다음 단계는 간단합니다. 지금 메모와 머릿속에 흩어져 있는 요청을 한 장에 모아 위 표의 갈래로 표시해 보십시오. 설정과 운영방식으로 표시된 줄이 생각보다 많다면, 그만큼은 발주 범위에서 빠지는 부분입니다. 남은 줄만 요청서 여덟 항목으로 다시 쓰면 업체와 같은 그림을 보고 이야기할 수 있습니다.
FAQ
자주 묻는 질문
- MES 추가개발 견적이 생각보다 크게 나왔습니다. 어디부터 확인해야 합니까?
- 금액을 깎는 이야기보다 범위를 다시 보는 쪽이 먼저입니다. 확인하실 것은 세 가지입니다. 첫째, 전달한 요청 중 설정 화면이나 권한 조정으로 끝나는 항목이 섞여 있지 않은지입니다. 조회 조건 추가나 양식 항목 변경은 제품에 편집 기능이 있는 경우가 있어 개발 범위에서 빠질 수 있습니다. 둘째, 같은 화면을 건드리는 요청이 여러 건으로 나뉘어 있지 않은지입니다. 묶으면 한 작업으로 계산되는 경우가 있습니다. 셋째, 요청서에 필수와 선택이 구분되어 있는지입니다. 구분이 없으면 받는 쪽은 적힌 모든 문장을 만들어야 하는 것으로 보고 가장 넓은 범위로 회신합니다. 이 세 가지를 정리해 다시 요청하면 같은 목록이라도 범위가 달라집니다.
- 설정으로 되는 일인지 개발이 필요한 일인지 어떻게 구분합니까?
- 기준은 그 작업이 화면에서 값을 고르는 일로 끝나는지입니다. 사용자 추가와 권한 변경, 기준정보·코드 등록, 조회 조건과 출력 항목의 선택은 대부분 설정 범위에 들어갑니다. 반면 집계 규칙, 데이터 구조, 설비 통신 구간, 외부로 나가는 전송 형식은 설정으로 바꾸기 어려운 구간입니다. 구분이 애매할 때 쓸 수 있는 방법은 두 가지입니다. 하나는 관리자 화면의 설정 메뉴를 항목별로 열어 보고 이름이 비슷한 항목이 있는지 찾아보는 것이고, 다른 하나는 업체에 요청을 보낼 때 "이것이 설정으로 가능한 범위인지 먼저 알려 달라"를 한 줄 넣는 것입니다. 개발 전에 이 답을 받아 두면 다음 요청부터는 사내에서 판단할 수 있습니다.
- 요청을 모아서 한 번에 맡기는 편이 유리합니까, 생길 때마다 처리하는 편이 낫습니까?
- 같은 화면이나 같은 집계를 건드리는 요청은 모아서 한 번에 처리하는 편이 일반적으로 낫습니다. 같은 구간을 두 번 열어 손대는 작업과 시험이 한 번으로 줄기 때문입니다. 다만 모으는 기간이 길어지면 다른 문제가 생깁니다. 요청한 사람이 왜 그것이 필요했는지 잊고, 그동안 수작업이 굳어 버려 개발이 끝난 뒤에도 예전 방식이 남습니다. 그래서 현실적인 방법은 두 갈래를 두는 것입니다. 설정과 운영방식으로 닫을 수 있는 요청은 올라온 주에 처리하고, 개발이 필요한 요청만 화면 묶음별로 모았다가 일정 주기로 발주하는 식입니다. 모으는 동안에도 요청서 항목을 그때그때 채워 두면 발주 시점에 다시 조사할 일이 없습니다.
- 표준 기능을 고치면 나중에 버전 업그레이드가 안 된다고 들었습니다. 사실입니까?
- 제품과 구축 방식에 따라 다르므로 일반적인 설명으로 단정하기는 어렵습니다. 다만 구조상 차이가 있는 것은 사실입니다. 제품의 표준 화면과 내부 처리 로직을 직접 수정한 경우에는 새 버전에 그 수정이 포함되지 않아 올릴 때 다시 적용해야 하는 범위가 생길 수 있습니다. 반대로 별도 화면이나 추가 항목, 제공되는 확장 지점을 통해 얹은 경우에는 영향이 작은 편입니다. 발주 전에 서면으로 확인하실 항목은 세 가지입니다. 이번 작업이 표준을 직접 고치는 방식인지, 버전을 올릴 때 이 작업을 누가 다시 맞추는지, 그 비용 부담 주체가 계약서에 적혀 있는지입니다. 이 셋이 문서에 없으면 작업 범위보다 먼저 정리하시는 편이 안전합니다.
- 사내에서 처리할 수 있는 범위를 넓히려면 무엇이 필요합니까?
- 권한과 절차서, 그리고 바꾼 기록을 남길 자리 세 가지입니다. 설정으로 되는 작업이라도 권한이 업체 계정에만 있으면 결국 요청으로 나갑니다. 사용자 추가, 코드 등록, 조회·출력 항목 변경처럼 되돌릴 수 있는 작업부터 담당자 한 명에게 권한을 주고, 작업 순서를 짧은 절차서로 적어 두시면 됩니다. 반대로 집계 규칙과 데이터 구조, 설비 통신 설정은 잘못 손대면 지난 자료까지 영향을 받으므로 사내 범위에 넣기 전에 책임 경계를 문서로 정해 두어야 합니다. 함께 권하는 것은 누가 언제 무엇을 바꿨는지 한 줄로 남기는 기록입니다. 기록이 없으면 몇 달 뒤 집계가 달라 보일 때 원인을 찾는 데 시간이 걸리고, 그 자체가 다시 요청으로 올라갑니다.
근거·참고
제도와 기준의 원본
- 스마트공장 사업관리시스템
정부 스마트공장 보급사업의 공고·신청·공급기업 목록이 있는 곳. 지원금 조건을 여기서 확인합니다.
- 중소기업 기술개발사업 종합관리시스템
기술개발 과제 공고와 신청 창구. 설비·시스템 도입을 과제로 묶을 때 확인합니다.
현장에 맞는 답이 필요하시면
이 글은 일반적인 기준을 정리한 것입니다. 공정과 설비를 직접 보고 해당 현장의 조건에 맞춰 범위를 잡아 드립니다.
MORE
함께 보면 좋은 글
- 조선기자재 생산관리시스템 구축 비용, 호선·블록 범위가 기준입니다
조선기자재 생산관리시스템 구축 비용은 사용자 수보다 호선·블록·품목의 연결 깊이와 자재·외주·검사 기록의 연동 범위에서 달라집니다. 거제·통영 생산관리 진단 경험을 바탕으로 견적 전에 정할 관리 단위와 구축 기준을 정리했습니다.
- 스마트공장 지원사업에 선정되고도 구축업체를 못 구하면 어떻게 하나
스마트공장 지원사업에 선정되고도 구축업체를 못 구하면 선정 여부보다 협약서의 남은 기간부터 셉니다. 업체가 견적을 미루는 이유와 바꿀 수 있는 조건, 요구사항을 한 장으로 적는 방법, 남은 기간을 역산하는 순서를 정리했습니다.
- 스마트공장 유지보수비 부담 해결은 지원 종료 전 항목 나누기에서 갈립니다
지원사업이 끝나 유지보수비가 자부담으로 넘어왔다면 총액을 깎기 전에 항목을 계속·축소·내부전환·중단으로 나눠야 합니다. 나누는 기준과 종료 시점에서 역산한 준비 순서를 표로 정리했습니다.