사무실에서는 기존 ERP를 계속 쓰고 있지만 현장에서는 전화나 별도 문서로 일을 전달하는 경우를 생각해보겠습니다. 모바일 업무가 필요하다고 해서 ERP 전체를 교체해야 하는 것은 아닙니다. 필요한 데이터를 제공받고 처리 결과를 되돌려줄 방법이 있다면, 기존 시스템 위에 현장 앱을 연결하는 방식을 검토할 수 있습니다.
가능 여부를 판단하려면 먼저 두 가지를 확인해야 합니다. 어느 시스템의 데이터를 기준으로 삼을 것인지, 기존 시스템이 어떤 연동을 허용하는지입니다.
화면을 만들기 전에 기준 시스템부터 정하세요
앱과 ERP가 각각 같은 재고를 수정하면 어느 값이 맞는지 판단해야 하는 일이 생깁니다. 거래처, 품목, 작업 상태처럼 여러 화면에서 사용하는 정보는 관리 주체를 정해야 합니다.
예를 들어 품목 코드는 ERP에서만 관리하고 앱은 이를 조회하도록 할 수 있습니다. 현장 작업 결과는 앱에서 입력하되 ERP의 확인을 거쳐 확정하도록 나눌 수도 있습니다. 어떤 방식이 맞는지는 업무에 따라 다르지만, ‘양쪽에서 알아서 맞춘다’는 설명만으로 설계를 끝내서는 안 됩니다.
API가 있다는 답변 다음에 물어볼 것
API는 시스템끼리 데이터를 주고받는 통로입니다. 제공된다는 사실만으로 앱 개발에 필요한 범위가 모두 준비된 것은 아닙니다. 다음 항목을 기존 시스템 담당자에게 확인해 보세요.
- 필요한 데이터를 조회할 수 있는가, 변경 결과도 등록할 수 있는가
- 사용자별 권한으로 호출하는가, 별도 연동 계정을 사용하는가
- 시험용 계정과 데이터가 있는가
- 호출 제한, 제공 시간, 변경 통지 방식은 무엇인가
- 연동 항목을 추가해야 할 때 누가 작업하고 비용을 부담하는가
문서가 없는 경우에는 원본 자료를 파일로 받아 처리하는 방식도 검토할 수 있습니다. 다만 실시간 반영이 어려울 수 있고, 누락·중복을 확인하는 절차가 필요합니다. 운영 데이터베이스에 직접 쓰는 방식은 권한과 장애 영향, 기존 업체의 지원 조건을 먼저 검토해야 합니다.
조회부터 시작하면 되는 업무도 있습니다
처음부터 모든 변경 기능을 연결할 필요는 없습니다. 현장에서 작업 목록과 진행 상태를 확인하는 것이 우선이라면 조회 기능부터 적용할 수 있습니다. 다음 단계에서 현장 결과 등록, 관리자 확인, 확정 처리 순으로 범위를 넓히는 안을 검토합니다.
다만 단계적으로 만든다는 이유로 상태 정의를 미뤄두면 안 됩니다. ‘전송 완료’가 ERP 접수인지 최종 업무 확정인지, 반려된 건을 어디에서 다시 처리하는지 정도는 처음부터 맞춰야 합니다.
연동 경험은 같은 제품을 써봤는지만으로 판단하지 않습니다
케이엠웍스의 동국제강 모바일 운송관리는 현장 업무 처리와 운송 상태, 업무용 메시징을 연결한 구축 사례입니다. 삼성서울병원 WearSMC에서는 Galaxy Watch·Samsung Health의 헬스데이터를 주기적 또는 수동으로 서버에 전달하는 흐름을 구축했습니다.
각 사례의 연동 대상은 다르지만, 다른 시스템에서 들어온 데이터를 모바일과 서버의 업무 흐름에 연결했다는 점을 확인할 수 있습니다. 특정 ERP에 바로 연결할 수 있는지는 제품과 버전, 계약된 API 범위를 별도로 살펴봐야 합니다.
세 담당자가 같은 표를 보면 협의가 빨라집니다
현업 담당자는 처리할 업무와 예외를, 기존 시스템 담당자는 제공 가능한 데이터와 제약을, 앱 개발사는 화면과 연동 흐름을 정리합니다. 이 내용을 ‘데이터 항목 / 기준 시스템 / 조회·변경 방향 / 확인 담당자’로 묶으면 서로의 작업 범위를 확인하기 좋습니다.
현재 시스템 이름과 현장에서 불편한 업무 한 가지를 먼저 알려주셔도 됩니다. 플랫폼 개발 범위를 확인한 뒤 연동 개발 문의를 남겨주시면, 유지할 부분과 새로 개발할 부분을 나눠 검토하겠습니다.