공공기관 업무 시스템, 제안요청서 전에 정리할 여섯 가지

‘현장에서는 모바일로 입력하고, 사무실에서는 웹으로 확인한다.’ 업무 시스템의 출발점은 이 정도 문장일 수 있습니다. 다만 개발 범위로 옮기려면 입력한 내용을 누가 수정할 수 있는지, 기존 기록은 어디서 가져오는지, 통신이 끊겼을 때는 어떻게 처리할지까지 정해야 합니다.

기능 목록을 늘리기보다 부서마다 다르게 이해하고 있는 조건을 먼저 맞추세요. 아래 여섯 가지를 정리하면 제안요청서와 검수 기준을 구체화하는 데 도움이 됩니다. 기관별 계약·보안 심의 요건은 해당 담당 부서의 기준을 별도로 확인해야 합니다.

1. 사용자 구분은 직급보다 실제 업무로 합니다

현장 담당자, 사업소 관리자, 본부 담당자가 같은 자재 정보를 보더라도 할 수 있는 일은 다릅니다. 조회만 하는 사람, 사용량을 입력하는 사람, 잘못 입력된 기록을 바로잡는 사람을 나눠보세요. 다른 사업소의 자료도 볼 수 있는지까지 정하면 권한의 경계가 드러납니다.

조직도를 그대로 화면 권한으로 옮기기보다는 ‘누가 어떤 기록에 어떤 조치를 할 수 있는가’를 기준으로 정리하는 편이 실무 검토에 적합합니다.

2. 현장 조건을 별도 메모로 남겨두지 않습니다

지하 시설, 이동 차량, 실외 작업처럼 통신 상태가 달라지는 장소에서는 입력 방식도 달라집니다. 사진 첨부, 바코드 촬영, 위치 확인이 필요하다면 사용할 단말과 현장 환경에서 확인해야 합니다.

예를 들어 현장 기록을 기기에 저장한 뒤 나중에 전송하도록 설계할 수 있습니다. 하지만 승인이나 재고 확정까지 통신 없이 처리해도 되는지는 별개의 판단입니다. 기능별로 가능한 범위를 나누고, 사용자가 현재 상태를 알 수 있도록 해야 합니다.

3. 연동 목록에는 시스템 이름과 담당자를 함께 기재합니다

‘기관 시스템 연동’이라는 항목만으로는 착수 일정을 잡기 어렵습니다. 계정 인증, 자재 코드, 조직 정보 중 무엇을 제공받는지와 연동 담당 부서를 확인해야 합니다. API 문서가 있어도 검수 환경의 계정이나 망 연결이 준비되지 않으면 실제 시험을 시작할 수 없습니다.

이 표는 발주 문서 전체를 대신하는 양식은 아닙니다. 빠진 조건을 관련 담당자에게 확인하기 위한 출발점으로 활용하면 됩니다.

4. 이관은 ‘몇 건’뿐 아니라 ‘어떤 의미’가 옮겨지는지 봅니다

과거 자료의 등록일과 수정일, 처리 완료 상태, 첨부파일 연결이 새 시스템에서도 같은 뜻으로 사용되는지 확인해야 합니다. 코드명이 바뀌거나 필수 항목이 추가되면 단순 복사로 끝나지 않습니다.

먼저 대표 자료를 시험 이관하고, 누락·중복·형식 오류를 어떤 기준으로 처리할지 결정하세요. 원본에서 잘못된 것으로 보이는 기록도 담당 부서의 확인 없이 삭제 대상으로 삼아서는 안 됩니다.

5. 관리자가 직접 처리할 범위를 남깁니다

사용자 권한 변경, 기준 코드 추가, 공지 수정, 잘못된 입력의 정정처럼 운영 중 반복되는 일을 정리해 보세요. 이런 일이 모두 개발 요청으로 남으면 작은 변경에도 대기 시간이 생깁니다. 반대로 모든 관리자에게 수정 권한을 주면 기록의 신뢰성을 관리하기 어렵습니다. 처리 권한과 변경 이력을 함께 설계해야 합니다.

케이엠웍스는 한국수자원공사 예비자재시스템에서 자재 정보와 입출고 이력, 사업소별 권한을 반영한 모바일·웹 업무 시스템을 구축했습니다. 이 사례에서 참고할 부분은 현장과 관리 부서의 화면을 같은 업무 데이터에 연결한 범위입니다.

6. 검수는 실제 업무의 끝까지 진행합니다

로그인이나 입력 화면이 열린다는 것만으로 검수를 마치지 않습니다. 현장에서 등록한 자료가 관리 화면에 표시되고, 필요한 검토를 거쳐 다음 담당자에게 전달되는지 확인해야 합니다. 권한이 없는 계정의 접근, 첨부 전송 실패, 중복 제출도 함께 시험합니다.

현재 사용하는 양식과 실제 업무 한 건의 처리 순서부터 준비해 보세요. 공공 분야 개발 사례를 확인한 뒤, 사용자·연동 대상·희망 개통 시점을 제작 문의에 남겨주시면 사전 확인이 필요한 범위를 함께 검토하겠습니다.