모바일 점검 앱과 MES 연동 방법: 현장 점검·이상 보고·작업 지시 종결

모바일 점검과 종이 점검표의 차이

“점검은 하고 있다”고 말하는 공장의 상당수는 벽에 점검표를 걸고 담당자가 교대마다 체크한 뒤 월말에 걷어 모읍니다.

이 방식의 부담은 평소에는 드러나지 않습니다. 드러나는 순간은 세 가지입니다. 고객 공장 감사에서 기록을 요구받을 때, 설비 고장 시 당시 상태를 되짚어야 할 때, 감독기관이 특정 점검이 실제로 수행되었음을 입증하라고 요구할 때입니다. 세 경우의 공통점은 시간이 촉박하다는 것이고, 1년치 종이를 넘겨볼 사람은 없습니다.

모바일 점검 앱의 차이는 세 가지입니다.

• 작업 배정이 시스템에서 이루어지고 반장의 구두 지시가 아님: 누가, 언제, 어느 설비의, 어느 항목을 점검하는지가 근무 시작 전에 기록으로 남습니다
• 점검 항목이 구조화된 필드이고 체크 표시가 아님: 수치 항목은 측정값을 그대로 입력하고, 범위를 벗어나면 즉시 경고가 뜨며 사진과 타임스탬프가 함께 저장됩니다
• 이상은 흐름의 시작이며 끝이 아님: 이상을 발견한 시점에 작업 지시나 알림이 생성되고 월말 집계를 기다리지 않습니다

실용적인 판단 기준은 이렇습니다. 임의의 점검자를 한 명 정해 지난달의 점검 시각과 측정값 전부를 시스템에서 보여줄 수 있다면 그 모바일 점검은 자리 잡은 것입니다.

모바일 점검 앱이 일반적으로 담당하는 기능

모바일 단말은 웹 페이지를 작게 줄인 것이 아닙니다. 현장 담당자가 수행하는 작업 동작 전체를 담당합니다.

기능은 크게 다음 네 가지로 나뉘며, 프로젝트 착수 시에는 현장 실정에 맞춰 선택합니다.

네 가지를 한 번에 도입할 필요는 없습니다. 다만 점검과 이상 대응은 같은 시기에 가동하는 것을 권합니다. 점검만 하고 대응이 없으면 데이터는 시스템에 남은 채 아무도 추적하지 않습니다.

동기화 구조와 오프라인 대응: 신호가 약한 현장에서 끊기지 않게

실제 공장에서는 구석 구역, 지하, 전기실처럼 신호가 약한 곳이 많습니다. 실시간 연결을 전제로 한 앱은 그곳에서 점검을 할 수 없습니다.

일반적인 방식은 “온라인 우선, 오프라인 보완”입니다.

• 점검 작업과 설비 정보는 출발 전에 단말로 미리 받아 두어 통신 없이도 열 수 있게 합니다
• 입력 데이터는 먼저 단말 데이터베이스에 기록하고, 미동기 건수를 화면에 명확히 표시합니다
• 연결이 복구되면 자동 전송하며, 전송 기록에는 업로드 시각이 아니라 원래 타임스탬프를 넣습니다
• 전송 실패에는 재시도와 수동 실행 경로를 두어 특정 담당자의 기억에 의존하지 않습니다

타임스탬프는 놓치기 쉬운 지점입니다. 전송 시각을 기록하면 오프라인 기간의 데이터가 시간축에서 한곳에 몰려 이후 추세 비교나 사건 재구성에서 순서를 잘못 읽게 됩니다.

MES와의 세 가지 연동 방식 선택

모바일 점검 앱과 MES의 연결은 실무에서 세 방향으로 나뉩니다.

• 작업 하달 방향: MES가 점검 계획으로 점검 작업을 생성해 모바일 단말로 보냅니다. 점검을 통제 아래에 두는 핵심 단계입니다
• 데이터 회신 방향: 점검 기록, 이상 작업 지시, 처리 결과를 MES에 기록해 설비와 사람의 이력을 완성합니다
• 기준 정보 방향: 설비 대장, 점검 포인트 목록, 담당자와 권한 계정을 MES와 동일한 원천으로 유지해 설비 번호가 두 체계로 갈라지는 것을 막습니다

어떤 기술 경로를 택할지는 양측의 인터페이스 조건에 달려 있습니다. 대표적인 선택은 REST 인터페이스 직접 연결, 중간 데이터베이스를 통한 교환, 게이트웨이와 메시지 경로를 통한 비동기 전송입니다. 일률적인 우열은 없습니다. 실시간성이 중요한 데이터 회신은 직접 연결이 맞고, 네트워크나 보안 영역을 넘는 상황은 메시지 경로가 맞습니다. 기준 정보 동기화는 보통 일 단위나 근무 단위 배치로 충분합니다.

단말 선택: 안드로이드 스마트폰, PDA, 태블릿

모바일 소프트웨어가 현장에 정착하는지는 절반이 단말 선택으로 결정됩니다.

세 가지 형태의 장단점은 다음과 같습니다.

선택 순서는 먼저 작업 동작(스캔이 많은지 입력이 많은지)을 정하고, 다음에 단말 형태, 마지막에 브랜드와 모델입니다. 반대로 장비를 먼저 사고 상황을 나중에 찾는 것이 이 분야 프로젝트에서 가장 흔한 낭비입니다.

계정·권한·감사 이력 설계

모바일 단말은 시스템을 공장 현장으로 가져옵니다. 권한 설계를 사무실 관행 그대로 가져올 수는 없습니다.

보통 네 가지를 정합니다.

• 계정과 담당자 연결: 인턴, 임시 작업자, 외주 인력의 계정을 어떻게 발급하고 회수할지
• 역할 계층화: 점검자는 입력만, 반장은 확인까지, 설비 책임자만 이상을 종결할 수 있음
• 변경 이력: 입력 후 수정 가능 여부, 수정 시 이력이 남는지, 수정 권한이 누구에게 있는지
• 시각과 위치 정보: 작업 시각과 위치를 기록할지, 기록 범위를 프로젝트 초기에 작업자에게 알릴지

뒤의 두 가지는 제약이나 식품처럼 규제 대응이 무거운 업종에서 특히 중요합니다. 가동 후에 추가하는 대신 방안 검토 단계에서 품질 부서와 확인하는 것을 권합니다.

가동과 검수: 이 앱이 실제로 쓸 수 있는지 판단하는 방법

점검 계열 프로젝트의 논쟁은 기능 유무보다 “가동 후 현장이 계속 쓰는지”에 집중됩니다.

검수는 다음 순서로 진행하는 것을 권합니다.

• 작업 하달 실측: MES에서 점검 작업 하나를 생성해 모바일 단말에 수초 내 표시되는지 확인합니다
• 오프라인 상황 실측: 신호가 없는 구역에서 점검을 한 바퀴 수행하고 복귀 후 전송 기록과 원래 타임스탬프를 대조합니다
• 이상 종결 실측: 현장에서 이상을 한 건 보고하고 배정, 처리, 확인 전 과정을 거쳐 MES 측 기록이 온전한지 확인합니다
• 스캔 정확도 실측: 실제 조도와 유분 조건에서 바코드 판독을 표본 검사해 여러 번 겨냥하지 않고 읽히는지 확인합니다
• 권한 실측: 서로 다른 역할의 계정으로 조작 범위를 확인하고 권한 밖 동작이 차단되는지 확인합니다
• 정착 의향 확인: 실제 근무 한 번을 시범 운영하고 점검자 의견을 모은 뒤 최종 점검 항목을 확정합니다

마지막 항목은 자주 생략되지만 대가가 가장 큽니다. 점검 항목이 너무 세밀하면 현장은 건너뛸 방법을 찾고, 너무 거칠면 감사에서 증거를 내놓지 못합니다. 시범 운영을 한 바퀴 돌린 뒤 확정하는 편이 회의실에서 논쟁하는 것보다 훨씬 효과적입니다.

구축 경계: 시범 범위를 정하고 확산하는 방법

점검 앱의 정착 위험은 두 곳에 집중됩니다. 단말과 통신의 현장 조건, 그리고 다른 시스템과의 인터페이스 소유권입니다. 경계를 문서로 명확히 해 두면 이후 설명이 크게 줄어듭니다.

안정적인 방식은 먼저 하나의 작업장이나 한 개 라인에서 시범 적용해 작업 하달, 오프라인 후속 전송, 이상 종결의 세 경로를 확실히 한 뒤 다른 구역으로 확산하는 것입니다. 확산 단계의 비용은 주로 단말 배포와 계정 개설에 있고, 소프트웨어 측은 점검 항목과 포인트 설정 조정으로 충분한 경우가 많습니다.

구축 상태는 보통 세 단계로 표시합니다. 구축 완료(현장 가동 중), 구축 가능(방안과 실적이 성숙해 현장 조건에 따라 즉시 착수 가능), 맞춤 시범(현장 조건에 맞춰 검증). 기존 MES, ERP, 창고 시스템과의 인터페이스가 관련되면 필드 정의와 책임 범위를 같은 범위 확정 회차에 포함하는 것을 권합니다. 인터페이스 필드는 한 번 확정되면 이후 변경 비용이 사전에 한 차례 더 협의하는 것보다 훨씬 큽니다.