생산관리 시스템 유지보수 계약 갱신 시점이 오면 대개 금액과 기간만 다시 적어 연장합니다. 판단에 필요한 자료는 따로 있습니다. 지난 1년 동안 무엇을 몇 번 요청했고, 언제 조치됐고, 그 결과로 시스템이 어떻게 바뀌었는지입니다. 이 세 가지가 정리되면 갱신·조건 변경·종료 가운데 어느 쪽인지가 거의 자동으로 나옵니다. 아래에 지난 1년 기록을 읽는 방법과 판단 기준을 표로 정리했습니다.
갱신 판단은 만족도가 아니라 지난 1년 기록으로 합니다
갱신 시점의 대화는 대체로 "별 문제 없었으니 그대로 가자" 또는 "쓴 것도 없는데 아깝다" 둘 중 하나로 흐릅니다. 두 말은 서로 반대인데 근거는 같습니다. 체감입니다.
체감이 어긋나는 이유는 유지보수가 두 가지를 섞어 담고 있기 때문입니다. 하나는 실제로 사람이 움직인 작업이고, 다른 하나는 요청이 생겼을 때 들어갈 자리가 미리 정해져 있다는 상태 자체입니다. 조용한 1년을 보내면 앞쪽은 적고 뒤쪽은 그대로 있었는데, 청구서에는 둘이 한 줄로 적혀 있습니다.
그래서 먼저 할 일은 금액을 보는 것이 아니라 지난 1년 요청 기록을 꺼내는 것입니다. 메일함과 메신저, 전화 메모를 모아 날짜·요청 내용·조치 결과 세 칸으로 옮기면 대부분 한 시간 안에 끝납니다. 이 표가 없으면 갱신 협의는 양쪽의 기억 대결이 됩니다.
지난 1년 기록에서 읽는 여섯 줄
정리한 기록을 아래 여섯 줄로 나눠 보면 됩니다. 각 줄이 갱신 쪽인지 조건 변경 쪽인지를 가리킵니다.
| 보는 항목 | 어디서 확인하나 | 갱신 쪽으로 읽히는 모습 | 조건을 바꿔야 하는 모습 |
|---|---|---|---|
| 요청 건수 | 날짜별 요청 목록 | 매달 꾸준히 몇 건씩 들어갔다 | 1년 내내 거의 없었거나, 특정 달에 몰렸다 |
| 요청 성격 | 요청 내용 칸 | 장애·오류 대응이 중심이다 | 신규 화면·보고서 추가 요청이 대부분이다 |
| 대응 시간 | 요청일과 조치 완료일 차이 | 급한 건과 일반 건이 구분돼 처리됐다 | 급한 건도 일반 건과 같은 속도로 밀렸다 |
| 반복 여부 | 같은 증상의 재발 횟수 | 같은 문제가 다시 나오지 않았다 | 같은 증상을 매번 임시로 넘겼다 |
| 누적 변경 | 조치 결과 칸 | 무엇을 바꿨는지 문서로 남아 있다 | 고친 내용이 기록 없이 쌓여 있다 |
| 담당 연속성 | 요청을 받은 사람 | 같은 담당자가 우리 설정을 알고 있다 | 매번 처음부터 설명하고 시작했다 |
여섯 줄 가운데 오른쪽에 걸린 줄이 그대로 다음 계약서에서 고칠 항목입니다. 왼쪽이 대부분이면 조건을 크게 바꿀 이유가 없고, 오른쪽이 절반을 넘으면 같은 조건으로 연장하는 것이 가장 나쁜 선택입니다.
범위를 다시 적는 쪽이 금액을 깎는 쪽보다 낫습니다
갱신 협의에서 가장 흔한 요구는 금액 인하입니다. 그런데 금액만 내리면 범위는 그대로 남고, 실제로 줄어드는 것은 대응 순위입니다. 다음 장애에서 그 차이가 나타납니다.
범위를 다시 적는 편이 양쪽 모두 설명이 됩니다. 신규 개발 요청이 대부분이었다면 그쪽을 유지보수에서 떼어 건별로 돌리고, 유지보수는 장애 대응과 환경 변화 대응만 남깁니다. 반대로 1년 내내 요청이 없었다면 정기 점검과 백업 확인 같은 쓰지 않아도 값이 남는 항목이 계약서에 적혀 있는지를 봅니다. 적혀 있지 않다면 그게 체감이 없던 이유입니다.
함께 적을 것이 대응 시간 기준입니다. 급한 건을 몇 시간 안에 접수하고 언제까지 1차 조치하는지, 그 판단을 누가 하는지를 문장으로 넣습니다. 구두로 들은 양해는 담당자가 바뀌면 함께 사라집니다.
종료를 선택하려면 먼저 확인할 것이 있습니다
유지보수를 끊는 선택도 가능합니다. 다만 끊은 다음에 확인하면 늦는 항목이 있습니다. 시스템이 멀쩡한 동안 아래를 확보해 두는 순서입니다.
| 종료 전에 확보할 것 | 왜 먼저 보나 | 어디서 확인하나 |
|---|---|---|
| 사용 권한 조항 | 지원 종료가 사용 중단과 묶여 있는지가 계약마다 다르다 | 구축 계약서의 사용 권한·유지보수 조항 분리 여부 |
| 소스·설계 자료 제공 조건 | 다른 곳에 맡길 수 있는지가 여기서 갈린다 | 계약서 산출물 목록과 제공 범위 |
| 서버·DB 접근 계정 | 우리 쪽이 들고 있지 않으면 아무것도 열어 볼 수 없다 | 계정 목록과 보관 책임자 |
| 변경 이력 | 원인 구간을 좁히는 시간이 요청마다 다시 든다 | 가동 이후 조치 기록 문서 |
| 연동 예외 규칙 | 신호가 끊긴 시간대 처리 방식을 아는 사람이 필요하다 | 연동 규격서와 예외 처리 문서 |
| 복원 확인 | 백업이 돈다는 말과 복원이 되는 것은 다르다 | 복원 시험 일자와 돌아간 시점 |
여섯 줄이 채워져 있으면 종료는 설명이 되는 선택입니다. 절반이 비어 있으면 그건 선택이 아니라 미확인 상태에서 지원만 끊는 것입니다. 갱신을 한 분기 짧게 연장하면서 이 자료를 받는 쪽이 순서에 맞습니다.
다음 단계
갱신일 한 달 전에 지난 1년 요청 기록을 세 칸 표로 정리하고, 위 여섯 줄에 걸어 보십니다. 그 결과를 들고 협의에 들어가면 금액 이야기보다 범위 이야기가 먼저 나옵니다. 현재 계약 조항과 요청 기록을 함께 보면서 어느 항목을 고쳐야 하는지는 현장 진단 단계에서 정리해 드립니다.
FAQ
자주 묻는 질문
- 1년 동안 유지보수 요청을 거의 안 했는데 그래도 갱신해야 합니까?
- 요청이 없었다는 사실만으로는 판단이 어렵고, 계약서에 쓰지 않아도 값이 남는 항목이 적혀 있는지를 먼저 보셔야 합니다. 정기 점검, 백업 상태 확인, 운영 환경 변화 대응, 접수 창구 유지 같은 항목이 범위에 들어 있다면 요청이 없던 1년에도 받은 것이 있습니다. 반대로 범위가 요청 처리로만 적혀 있다면 체감이 없던 것이 맞고, 그 상태로 같은 조건을 연장하는 것은 설명이 어렵습니다. 그다음으로 보실 것은 앞으로 1년입니다. 서버 운영체제나 데이터베이스 교체, 사업장 증설, 거래처 전송 규격 변경처럼 예정된 변화가 있으면 조용했던 지난 1년은 참고치가 되지 못합니다. 변화가 없고 범위도 요청 처리뿐이라면 금액을 깎는 대신 범위를 장애 대응과 환경 변화 대응으로 좁혀 다시 적는 편이 양쪽 모두 납득이 됩니다.
- 갱신할 때 금액을 깎는 게 좋습니까, 범위를 줄이는 게 좋습니까?
- 범위를 다시 적는 쪽을 권해 드립니다. 금액만 내리고 범위를 그대로 두면 계약서는 종전과 같은데 실제로 줄어드는 것은 대응 순위입니다. 그 차이는 평소에 보이지 않고 급한 일이 생긴 날에 나타나는데, 그때는 조건을 다시 협의할 상황이 아닙니다. 범위를 조정할 때 가장 자주 떼어 내는 것은 신규 개발입니다. 지난 1년 요청이 신규 화면이나 보고서 추가로 채워져 있었다면 그쪽은 건별 과제로 돌리고 유지보수는 장애 대응과 환경 변화 대응만 남기는 식입니다. 이러면 월 고정 범위는 얇아지고 필요할 때 쓰는 비용은 건별로 드러나므로 다음 갱신 때 판단할 근거도 같이 생깁니다. 어떤 형태든 대응 시간 기준은 문장으로 남겨 두시는 편이 안전합니다.
- 유지보수 업체를 갱신 시점에 바꾸는 것은 어떻습니까?
- 가능한지 여부는 받는 쪽의 역량보다 우리 쪽 자료 상태에서 갈립니다. 데이터베이스 구조와 소스에 접근할 수 있고 가동 이후 변경이 어느 정도 기록돼 있으면 다른 곳에서도 인수할 수 있습니다. 반대로 소스 제공 범위가 계약으로 제한돼 있거나 변경이 기록 없이 쌓여 있으면 구조를 읽는 작업이 먼저 들어가고 그 시간도 산정에 포함됩니다. 그래서 업체를 찾기 전에 소스·설계 자료의 보유와 제공 조건을 확인하시는 편이 순서가 맞습니다. 시점도 함께 보십니다. 결산기나 심사 일정이 걸린 달에 인수를 겹치면 문제가 생겼을 때 돌아갈 곳이 없습니다. 바꾸기로 정하셨다면 기존 업체와의 계약을 한두 달 겹쳐 두고 그 기간에 자료 인계와 책임 경계를 문서로 정리하는 방식이 실무에서 안전한 편입니다.
- 대응 시간 기준을 계약서에 어떻게 적어 두면 됩니까?
- 구체적인 시간 수치는 시스템 구성과 생산 일정에 따라 달라지므로 일률적으로 말씀드리기 어렵고, 적어 둘 항목은 대체로 정해져 있습니다. 첫째 접수 창구와 연락 가능 시간, 둘째 급한 건과 일반 건을 나누는 기준, 셋째 각 등급의 접수 응답 시간과 1차 조치 목표, 넷째 목표를 넘길 때 알려 주는 방식입니다. 특히 둘째가 빠지면 나머지가 작동하지 않습니다. 등급을 나누는 판단을 누가 하는지도 함께 적어 두십니다. 우리 쪽이 급하다고 본 건과 업체가 급하다고 본 건이 다를 때 분쟁이 생기는 자리입니다. 생산 중단 여부, 출하 지연 여부처럼 공장에서 바로 확인되는 조건으로 적어 두면 해석 다툼이 줄어듭니다. 야간·휴일 대응이 필요한지도 같은 자리에서 정하시는 편이 좋습니다.
- 갱신 협의 전에 우리 쪽에서 먼저 준비할 자료는 무엇입니까?
- 지난 1년 요청 기록을 세 칸 표로 정리한 것 하나면 협의의 성격이 달라집니다. 날짜, 요청 내용, 조치 결과입니다. 메일함과 메신저, 전화 메모를 모아 옮기면 대부분 한 시간 안에 끝나고, 이 표가 없으면 협의는 양쪽 기억을 맞춰 보는 자리가 됩니다. 여기에 두 가지를 더하시면 충분합니다. 하나는 현재 계약서에서 범위와 대응 시간, 사용 권한 조항을 발췌한 한 장이고, 다른 하나는 앞으로 1년 안에 예정된 변화 목록입니다. 설비 증설, 서버 교체, 거래처 전송 규격 변경, 심사 일정 같은 것들입니다. 지난 1년 기록은 무엇을 고칠지 알려 주고, 예정된 변화 목록은 범위를 어디까지 남길지 알려 줍니다. 두 장을 들고 들어가면 금액 이야기보다 범위 이야기가 먼저 나옵니다.
근거·참고
제도와 기준의 원본
- 식품의약품안전처
식품위생법과 고시의 발령 기관. 제도가 바뀌면 여기가 먼저 바뀝니다.
- 스마트공장 사업관리시스템
정부 스마트공장 보급사업의 공고·신청·공급기업 목록이 있는 곳. 지원금 조건을 여기서 확인합니다.
- 한국생산기술연구원
제조 공정 기술을 연구하는 정부출연 기관. 금형·가공·자동화 분야의 기술 자료가 공개돼 있습니다.
현장에 맞는 답이 필요하시면
이 글은 일반적인 기준을 정리한 것입니다. 공정과 설비를 직접 보고 해당 현장의 조건에 맞춰 범위를 잡아 드립니다.
MORE
함께 보면 좋은 글
- 조선기자재 생산관리시스템 구축 비용, 호선·블록 범위가 기준입니다
조선기자재 생산관리시스템 구축 비용은 사용자 수보다 호선·블록·품목의 연결 깊이와 자재·외주·검사 기록의 연동 범위에서 달라집니다. 거제·통영 생산관리 진단 경험을 바탕으로 견적 전에 정할 관리 단위와 구축 기준을 정리했습니다.
- MES 도입 전에 먼저 정리해야 할 현장 데이터는 설비 목록과 코드 체계입니다
MES 도입 전에 정리할 현장 데이터는 설비 목록, 공정 단위, 코드 체계, 작업지시와 실적 양식입니다. 무엇을 어느 수준까지 정리해야 하는지와 정리 없이 시작했을 때 생기는 일을 함께 정리했습니다.
- 부산 MES 유지보수 업체를 고를 때 출동 거리보다 먼저 확인할 것
부산 MES 유지보수 업체를 비교할 때는 사무소 주소보다 공장이 있는 권역의 생산 방식과 대응 방식 구분이 먼저 갈립니다. 입지·업종별로 요청이 몰리는 지점과 대응 방식별 확인 문장을 표로 정리했습니다.