MES 유지보수 계약 없이 운영하는 상태는 평소에 아무 차이도 만들지 않습니다. 차이가 드러나는 시점은 설비가 멈추거나 집계가 어긋난 날이고, 그때 걸리는 것은 수리 작업 자체보다 누가 언제까지 봐 주기로 했는지, 서버와 설정 기록에 누가 접근할 수 있는지가 정해져 있지 않다는 점입니다. 아래에 미체결 상태에서 실제로 막히는 지점과, 계약을 바로 맺기 어려울 때 먼저 확보해 둘 자료를 표로 정리했습니다.
계약이 없는 상태는 멈추기 전까지 티가 나지 않습니다
가동 중인 MES는 대체로 조용합니다. 입력이 들어가고 실적이 집계되는 동안에는 유지보수 범위가 비어 있어도 체감되지 않습니다. 그래서 계약을 미뤄 둔 판단이 한동안은 맞아 보입니다.
달라지는 지점은 요청이 생길 때입니다. 계약이 있으면 요청은 접수 창구로 가고, 없으면 요청은 사람 찾기부터 시작합니다. 구축한 곳이 아직 같은 담당자를 두고 있는지, 그 담당자가 우리 쪽 설정을 기억하는지, 지금 일정이 비는지를 확인하는 데 시간이 먼저 들어갑니다. 급한 일일수록 이 확인 구간이 길게 느껴집니다.
또 하나는 값의 문제가 아니라 순서의 문제입니다. 계약이 없으면 모든 요청이 건당 협의로 시작하므로, 무엇을 고칠지 판단하기 전에 견적과 발주 절차를 먼저 돌려야 합니다. 설비가 서 있는 상태에서는 이 순서가 그대로 생산 지연으로 이어집니다.
멈춘 뒤에 확인하게 되는 여섯 가지
장애가 난 공장에서 실제로 시간을 잡아먹는 항목은 대체로 정해져 있습니다. 평소에는 전부 문제없어 보이는 줄들입니다.
| 구분 | 평소에 보이는 모습 | 멈춘 날 실제로 막히는 일 | 지금 확인할 수 있는 것 |
|---|---|---|---|
| 대응 창구 | 문제가 없어 연락할 일이 없다 | 누구에게 연락할지부터 찾는다. 담당자가 바뀌었는지도 모른다 | 구축사의 현재 담당 창구와 연락 가능 시간 |
| 대응 시간 약속 | 급하면 봐 주겠다는 구두 양해가 있다 | 언제까지 조치되는지 기준이 없어 생산 일정을 다시 잡지 못한다 | 구두로 들은 내용이 문서에 적혀 있는지 |
| 접근 권한 | 화면이 잘 돌아간다 | 서버·데이터베이스·소스에 들어갈 계정을 우리 쪽이 들고 있지 않다 | 계정 보유 현황과 보관 장소 |
| 변경 이력 | 그동안 몇 번 고쳐서 쓰고 있다 | 무엇을 왜 바꿨는지 몰라 원인 구간을 좁히지 못한다 | 가동 이후 변경 기록이 문서로 남아 있는지 |
| 백업·복구 | 백업은 돌고 있다고 들었다 | 복원해 본 적이 없어 어느 시점까지 돌아가는지 모른다 | 백업 주기·보관 위치와 복원 시험 기록 |
| 자동 수집 구간 | 실적이 알아서 올라온다 | 신호가 끊긴 시간대를 어떻게 처리하기로 했는지 아는 사람이 없다 | 연동 규격서와 예외 처리 규칙 문서 |
표의 마지막 칸이 오늘 확인할 수 있는 항목입니다. 여섯 줄 가운데 답이 나오지 않는 줄이 있으면, 그 줄이 장애가 났을 때 가장 오래 걸릴 구간입니다.
기록과 사람이 함께 빠지면 복구가 어려워집니다
점검이나 심사에서 확인받는 것은 화면이 아니라 기록입니다. 일반적으로 어느 값이 언제 어떻게 저장됐는지, 수정 이력이 남는지, 정해진 기간만큼 보관되는지를 묻게 됩니다. 유지보수 범위가 비어 있으면 이 질문이 들어올 때 저장된 자료를 직접 꺼내 설명할 사람이 없는 상태가 됩니다. 저장 자체는 되고 있어도 꺼내서 설명할 수 없으면 확인 과정이 길어집니다. 설비 신호로 자동 수집하는 구간은 끊긴 시간대 처리 규칙을 어디에 적어 두었는지까지 함께 묻는 경우가 많습니다.
여기에 담당자 퇴사가 겹치면 남는 것은 화면뿐입니다. 한 사람이 오래 맡아 온 시스템은 설정 근거가 문서가 아니라 사람에게 들어 있는 경우가 흔합니다. 어떤 값을 왜 그렇게 잡았는지, 어떤 예외를 어디서 손으로 메우고 있었는지가 함께 나가면, 다음 사람은 멀쩡히 돌아가는 시스템을 두고도 손댈 수 없는 상태를 물려받습니다. 계약이 있으면 최소한 상대 쪽에 조치 기록이 남지만, 없으면 양쪽 모두 기록이 없습니다.
계약을 바로 맺기 어렵다면 자료부터 확보합니다
예산 시점이나 업체 상황 때문에 계약이 당장 어려울 수 있습니다. 그렇다면 계약을 기다리는 동안에도 할 수 있는 일이 있습니다. 지금 시스템이 멀쩡히 돌아가는 상태에서 자료를 받아 두는 것이 가장 수월하고, 멈춘 뒤에 같은 자료를 모으는 일이 제일 오래 걸립니다.
| 먼저 확보할 자료 | 없을 때 생기는 일 | 어디서 확보하나 | 어떤 형태로 남기나 |
|---|---|---|---|
| 소스·설계 자료 제공 조건 | 다른 곳에 맡길 수 있는지조차 판단이 안 된다 | 구축 당시 계약서와 산출물 목록 | 제공 범위와 조건만 발췌해 한 장으로 |
| 서버·DB 접근 계정 | 급할 때 우리 쪽에서 아무것도 열어 볼 수 없다 | 현재 운영 담당자와 구축사 확인 | 계정 목록과 보관 책임자를 함께 지정 |
| 조치 이력 | 원인 구간을 좁히는 시간이 요청마다 다시 든다 | 지난 요청 메일·메신저 기록 정리 | 날짜·요청 내용·조치 결과 세 칸 표 |
| 설정 근거 | 담당자가 바뀌면 왜 그 값인지 설명하지 못한다 | 지금 담당자와 화면을 함께 보며 정리 | 화면별 설정값과 그렇게 잡은 이유 |
| 수기 보완 구간 | 시스템 밖에서 사람이 메우던 일이 통째로 사라진다 | 현장 입력 담당자 확인 | 누가 언제 어떤 자료를 손으로 처리하는지 |
| 복원 확인 | 백업이 있다는 말만 남는다 | 운영 담당자와 함께 한 번 시험 | 복원 시도 일자와 어디까지 돌아왔는지 |
이 여섯 줄이 모이면 계약 협의 자체도 수월해집니다. 상대가 우리 환경을 파악하는 데 드는 시간이 줄어들기 때문에, 범위와 대응 시간을 구체적으로 적어 달라고 요구하기도 쉬워집니다. 반대로 자료가 없는 상태에서 받는 조건은 대체로 넓게 적히고, 정작 급한 구간이 빠져 있을 수 있습니다.
다음 단계는 간단합니다. 위 표 두 개를 그대로 출력해 빈 칸을 채워 보시고, 답이 나오지 않는 줄에 표시를 해 두시면 됩니다. 그 줄이 지금 우리 공장에서 가장 약한 구간입니다. 어느 줄부터 메워야 하는지와 우리 환경에서 필요한 유지보수 범위는 현장 구성을 확인한 뒤 정리해 드립니다.
FAQ
자주 묻는 질문
- 지금 아무 문제 없이 잘 돌아가는데 유지보수 계약이 꼭 필요합니까?
- 지금 조용한 것과 문제가 생겼을 때 대응이 되는 것은 다른 이야기입니다. 계약의 실질은 매달 뭔가를 고쳐 주는 것보다, 요청이 생겼을 때 어디로 연락해 언제까지 조치받는지가 미리 정해져 있는 상태를 사는 것에 가깝습니다. 그래서 가동이 안정적일수록 계약 없이 지내도 체감이 없고, 한 번 멈춘 날에 그 차이가 한꺼번에 나타납니다. 판단이 어려우시면 계약 여부를 먼저 정하기보다 본문 첫 번째 표의 여섯 줄을 채워 보시는 편이 빠릅니다. 창구·대응 시간·접근 권한·변경 이력·복원 확인·연동 예외 처리 가운데 답이 안 나오는 줄이 몇 개인지가 지금 위험 수준을 그대로 보여 줍니다. 전부 채워진 공장이라면 계약 없이 버티는 선택도 설명이 되지만, 절반이 비어 있다면 그건 선택이 아니라 미확인 상태입니다.
- 유지보수 계약을 안 하면 시스템 사용이 중단되거나 잠기는 겁니까?
- 계약 형태에 따라 다르고, 계약서에 어떻게 적혀 있는지를 확인하셔야 합니다. 구축해서 우리 서버에 설치한 형태라면 유지보수를 끊어도 설치된 시스템은 보통 그대로 돌아가고, 멈추는 것은 지원이지 사용이 아닌 경우가 많습니다. 반면 사용 기간이나 사용자 수에 맞춰 이용 권한이 갱신되는 형태라면 지원과 사용 권한이 한 묶음으로 묶여 있을 수 있습니다. 그래서 먼저 보실 것은 계약서의 사용 권한 조항과 유지보수 조항이 분리돼 있는지입니다. 실무에서 더 자주 문제가 되는 쪽은 사용 중단이 아니라 운영 환경 변화입니다. 서버 운영체제나 데이터베이스, 브라우저, 연동하는 상대 쪽 규격이 바뀔 때 손봐 줄 사람이 정해져 있지 않으면 어느 날 특정 기능만 동작하지 않는 상태로 들어갑니다.
- 구축한 업체와 연락이 거의 끊겼는데 다른 곳에 유지보수를 맡길 수 있습니까?
- 가능한 경우와 어려운 경우가 갈리고, 기준은 받는 쪽의 역량보다 자료 상태입니다. 데이터베이스 구조와 소스에 접근할 수 있고 그동안의 변경이 어느 정도 기록돼 있으면 다른 곳에서도 인수할 수 있습니다. 반대로 소스 제공 범위가 계약으로 제한돼 있거나 가동 이후 변경이 기록 없이 쌓여 있으면, 구조를 읽는 작업이 먼저 들어가고 그 시간도 산정에 포함됩니다. 그래서 업체를 찾기 전에 소스·설계 자료의 보유와 제공 조건을 먼저 확인하시는 편이 순서가 맞습니다. 함께 정하실 것은 책임 경계입니다. 한 시스템을 여러 곳이 손대기 시작하면 문제가 생겼을 때 원인 구분이 어려워지므로, 어느 구간을 누가 맡고 변경 기록을 어디에 남길지를 인수 시점에 적어 두시는 편이 낫습니다.
- 심사나 점검에서 시스템 기록을 요구하면 계약 없이도 대응할 수 있습니까?
- 요구되는 자료가 시스템 안에 저장돼 있기만 하면 되는 것이 아니라, 꺼내서 설명할 수 있어야 한다는 점이 어려운 부분입니다. 일반적으로 어느 값이 언제 어떻게 저장됐는지, 수정하면 이력이 남는지, 정해진 기간만큼 보관되는지를 확인받게 됩니다. 사내에 데이터베이스를 직접 열어 볼 수 있는 사람이 있고 저장 구조를 설명할 자료가 있으면 계약 없이도 대응이 됩니다. 그 둘이 없으면 요구를 받은 다음부터 사람을 찾기 시작하는데, 점검 일정은 기다려 주지 않는 편입니다. 설비 신호로 자동 수집하는 구간은 신호가 끊긴 시간대를 어떻게 처리하기로 했는지까지 함께 묻는 경우가 많으므로, 그 규칙이 문서에 적혀 있는지 미리 확인해 두시는 편이 안전합니다. 우리 환경에서 어떤 기록이 어디에 남는지는 현재 구성을 확인한 뒤 정리해 드립니다.
- 담당 직원이 그만두기 전에 무엇을 받아 둬야 합니까?
- 퇴사 통보를 받은 뒤에 인수인계서를 쓰게 하면 대개 화면 사용법이 나옵니다. 사용법은 다음 사람이 며칠 쓰면 익히므로 실제로 필요한 것은 그게 아니라 판단의 근거입니다. 네 가지를 권해 드립니다. 첫째 화면별 주요 설정값과 왜 그 값으로 잡았는지, 둘째 시스템 밖에서 사람이 손으로 메우고 있던 작업이 무엇인지, 셋째 그동안 업체에 보낸 요청과 조치 결과, 넷째 서버·데이터베이스 계정이 어디에 보관돼 있고 누가 알고 있는지입니다. 특히 두 번째가 빠지면 다음 사람은 시스템이 전부 자동으로 돌아간다고 믿은 채 인수하고, 월말 집계에서 처음 어긋난 숫자를 보게 됩니다. 문서 분량보다 실제로 손으로 하던 일이 적혀 있는지가 중요하고, 함께 화면을 보면서 받아 적는 방식이 가장 확실합니다.
근거·참고
제도와 기준의 원본
- 스마트공장 사업관리시스템
정부 스마트공장 보급사업의 공고·신청·공급기업 목록이 있는 곳. 지원금 조건을 여기서 확인합니다.
현장에 맞는 답이 필요하시면
이 글은 일반적인 기준을 정리한 것입니다. 공정과 설비를 직접 보고 해당 현장의 조건에 맞춰 범위를 잡아 드립니다.
MORE
함께 보면 좋은 글
- 조선기자재 생산관리시스템 구축 비용, 호선·블록 범위가 기준입니다
조선기자재 생산관리시스템 구축 비용은 사용자 수보다 호선·블록·품목의 연결 깊이와 자재·외주·검사 기록의 연동 범위에서 달라집니다. 거제·통영 생산관리 진단 경험을 바탕으로 견적 전에 정할 관리 단위와 구축 기준을 정리했습니다.
- MES 도입 전에 먼저 정리해야 할 현장 데이터는 설비 목록과 코드 체계입니다
MES 도입 전에 정리할 현장 데이터는 설비 목록, 공정 단위, 코드 체계, 작업지시와 실적 양식입니다. 무엇을 어느 수준까지 정리해야 하는지와 정리 없이 시작했을 때 생기는 일을 함께 정리했습니다.
- 생산관리 시스템 유지보수 계약 갱신 기준, 지난 1년 요청 기록으로 판단합니다
유지보수 계약 갱신 여부는 느낌이 아니라 지난 1년 기록으로 판단합니다. 요청 건수·대응 시간·누적 변경을 어떻게 읽는지와 갱신·조건변경·종료를 가르는 기준을 표로 정리했습니다.