현장 사진은 메신저에 있고, 점검표는 종이에 있으며, 보고서는 엑셀에서 다시 만드는 조직이 있습니다. 이때 현장 점검 앱 외주 개발 범위를 정하는 기준은 사진을 올릴 수 있느냐가 아닙니다. 이상 항목이 발견된 뒤, 그 문제가 해결됐는지까지 조직이 관리해야 하는지를 먼저 정해야 합니다.
점검 결과를 제출하면 업무가 끝나는 조직도 있습니다. 반대로 보고서는 냈지만 보수 요청이 빠지거나, 다음 점검 때 같은 문제가 반복되는 조직도 있습니다. 두 경우에 필요한 앱은 다릅니다. 처음부터 큰 시스템을 만들기보다, 우리 업무가 어느 쪽에 가까운지 구분하는 편이 낫습니다.
보고서 제출이 업무의 끝이라면 기록과 검토에 집중한다
정기 점검 결과를 공유하거나, 작업 사실을 남기거나, 고객에게 보고서를 제출하는 일이 주된 목적이라면 첫 범위는 비교적 짧게 잡을 수 있습니다. 현장이나 설비를 선택하고, 정해진 점검 항목에 정상·이상·메모를 입력합니다. 필요한 사진을 붙여 제출한 뒤 관리자가 검토하고, 승인된 내용을 보고서로 확정하는 흐름입니다.
이 단계에서 사진은 현장별 앨범처럼 쌓기보다 점검 항목에 연결해야 합니다. 예를 들어 냉난방 설비의 누수 여부를 확인한 항목에 사진을 붙여야, 나중에 보고서를 보는 사람이 무엇을 보여 주는 사진인지 알 수 있습니다. 사진 파일이 많아도 항목과 연결되지 않으면 담당자는 다시 메신저 대화, 촬영 날짜, 파일 이름을 뒤져야 합니다.
이 범위는 종이·메신저·엑셀에 흩어진 기록을 모으는 데 적합합니다. 다만 이상 표시를 남긴 뒤 누가 수리했는지, 수리 결과가 적절했는지까지 앱에서 답할 필요가 없다면 문제 관리 기능을 서둘러 넣을 이유는 없습니다. 보고서 작성의 속도와 누락 없는 제출이 우선인 단계입니다.
미조치 항목이 남는 조직은 ‘이상’을 문제로 분리한다
보고서를 냈는데도 같은 지적이 반복되거나, “이 건은 누가 처리하기로 했지?”라는 대화가 자주 나온다면 이상 항목은 체크값으로 끝나면 안 됩니다. 해결해야 할 문제 한 건으로 이어져야 합니다.
가상의 상황을 생각해 보겠습니다. 점검자가 기계실 배관의 누수 사진과 이상 표시를 남겼습니다. 보고서만 만드는 업무라면 그 기록으로 충분할 수 있습니다. 그러나 내부 시설팀이나 외부 보수 업체가 조치해야 한다면 이야기가 달라집니다. 누가 맡는지, 언제까지 처리하는지, 어떤 작업을 했는지, 수리 후 사진은 무엇인지, 다른 사람이 다시 확인해 통과시켰는지가 이어져야 합니다. 사진 한 장은 조치 완료를 뜻하지 않습니다.
이 단계에서 필요한 것은 복잡한 관리 화면보다 책임이 끊기지 않는 흐름입니다. 업체와 요구사항을 논의할 때는 아래 항목이 한 건의 이상 기록에서 자연스럽게 이어지는지 확인하면 됩니다.
- 이상 항목에서 별도의 문제 번호와 담당자를 만들 수 있는가
- 처리 기한과 우선순위를 정하고, 담당자가 조치 내용을 남길 수 있는가
- 조치 전후 사진과 작업 메모를 구분해 기록할 수 있는가
- 재점검한 사람과 통과·보완 결과가 최초 점검 기록에 이어지는가
- 보고서 확정 뒤 수정하거나 다시 발행한 이력을 확인할 수 있는가
담당자가 한 명이고 조치 속도가 빠른 작은 운영에서는 목록 관리만으로도 충분할 수 있습니다. 그러나 여러 지점, 부서, 협력업체가 함께 움직이고 담당자가 바뀌는 일이 잦다면 이 연결을 초기에 정하는 편이 좋습니다. 보고서가 많아져서가 아니라, 미조치 항목의 책임이 사라지기 쉬워서입니다.
사진의 위치와 현장 통신 상태가 운영 범위를 바꾼다
사진 관리는 저장 용량만의 문제가 아닙니다. 최초 점검의 증빙 사진인지, 조치 후 결과 사진인지, 재점검 통과의 근거인지에 따라 붙는 위치가 달라집니다. 외부 업체가 참여한다면 자기에게 배정된 문제에만 사진을 올릴 수 있는지, 기존 사진을 교체하거나 삭제할 수 있는지도 미리 정해야 합니다.
지하 기계실, 지하 주차장, 외곽 작업장처럼 통신이 불안정한 곳이 있다면 현장 시험이 필요합니다. 인터넷이 끊긴 상태에서 입력한 점검표와 사진이 임시 저장되는지, 연결이 회복된 뒤 서버에 반영됐는지, 업로드 실패를 현장 담당자와 관리자가 알아차릴 수 있는지를 확인해야 합니다. 제출 완료처럼 보이지만 사진이 기기에만 남는 상황은 보고서 업무에서도 치명적입니다.
개발 상담 전에는 현재 쓰는 점검표 한 종, 실제 보고서 한 종, 최근 처리 지연 사례 몇 건을 준비해 보십시오. 그리고 업체에게 이상 항목 하나가 발견된 뒤 재점검 통과와 확정 보고서까지 어떻게 이어지는지 보여 달라고 요청하면 됩니다. 그 흐름을 화면에서 설명하기 어렵다면, 필요한 업무 범위도 아직 충분히 정리되지 않은 상태일 가능성이 큽니다.
