ERP와 그룹웨어를 AI에 연결할 때 먼저 정할 데이터와 권한

구매 담당자가 입고 지연을 확인한다고 생각해 보세요. ERP에서 발주와 입고 내역을 찾고, 그룹웨어에서 변경 승인서를 열고, 공유 폴더에서 거래처의 납기 안내를 확인합니다. 필요한 것은 세 시스템의 검색 결과 목록보다 어느 발주가 지연됐고, 변경된 날짜는 승인됐으며, 그 판단의 근거는 어디에 있는지입니다.

ERP AI 연동과 그룹웨어 AI 검색을 함께 설계할 때는 이 업무의 연결 고리부터 정해야 합니다. 시스템 이름만 맞춘 연결로는 발주 상태, 문서 버전, 사용자 권한의 차이를 해결하기 어렵습니다. 처음에는 데이터를 조회하고 근거를 확인하는 범위를 검증한 뒤, 실제 업무에 필요한 부분을 넓히는 편이 좋습니다.

숫자를 조회하는 일과 문서를 읽는 일은 다릅니다

ERP에는 품목, 발주, 입고, 거래처처럼 필드와 상태로 관리하는 데이터가 많습니다. 반면 그룹웨어에는 공지, 결재 본문, 첨부 파일, 변경 사유가 쌓입니다. 둘을 같은 방식으로 문서 조각으로 만들면 ERP 수량을 부정확하게 합산하거나, 결재가 진행 중인 변경안을 확정된 사실로 답할 수 있습니다.

연결 대상	필요한 정보	결과에서 확인할 것
ERP 발주·입고	발주 ID, 품목, 수량, 예정일, 상태	원본 레코드와 조회 기준 시점
그룹웨어 변경 결재	결재 ID, 발주 ID, 승인 상태, 승인일	확정본인지와 적용 범위
납기 안내 첨부	거래처, 발주 ID, 안내 날짜, 본문	원문 위치와 다른 안내의 존재
업무 규정·양식	담당 부서, 시행일, 개정 이력	현재 적용되는 절차와 예외

연동 설계에서는 정형 데이터의 조건 검색·집계와 문서의 내용 검색을 구분합니다. 예를 들어 미입고 수량은 발주 수량에서 유효한 입고 수량을 계산해야 합니다. 단순히 여러 PDF에 등장한 숫자를 요약해서 얻을 값이 아닙니다. 취소·반품·분할 입고를 어떻게 처리하는지 ERP 담당자와 계산 기준을 먼저 맞춥니다.

한 건의 발주로 연결 오류를 찾아보세요

다음은 연결 방법을 설명하기 위한 가상 예시입니다. 발주 PO-101의 원래 입고 예정일은 10월 8일이고, 거래처 안내에는 10월 12일로 연기됐다고 적혀 있습니다. 하지만 그룹웨어의 변경 결재는 아직 진행 중입니다.

이 상태에서 답변이 “승인된 입고일은 10월 12일”이라고 나오면 날짜를 잘 찾았더라도 업무적으로 틀린 결과입니다. 적절한 결과는 ERP에 기록된 예정일, 거래처가 요청한 변경일, 미승인 상태를 구분하고 담당자가 확인할 원본을 보여주는 것입니다. 최종 날짜가 불분명하다는 사실 자체가 유용한 답변입니다.

시스템 사이를 연결할 기준은 파일 이름보다 발주 ID 같은 업무 식별자가 적합합니다. 거래처 이름이 같다는 이유만으로 서로 다른 주문을 묶어서는 안 됩니다. 식별자가 없는 오래된 첨부는 수동 확인 대상으로 남기고, 연결이 안 된 문서 수를 따로 기록하세요. 모든 자료를 억지로 한 결과로 합치는 것보다 연결의 빈칸을 보여주는 편이 현업에게 도움이 됩니다.

동일한 ID라도 법인이나 사업장이 다르면 다른 건일 수 있습니다. 사업장 코드와 회계 기간 등 필요한 구분값을 함께 정하고, 공통 데이터 사전을 짧게 작성합니다. 현업이 말하는 “입고 완료”와 ERP 상태값의 의미가 같은지 확인하는 과정도 여기에서 필요합니다.

읽기 전용 연동부터 범위를 명확히 하세요

첫 단계는 필요한 조회 화면이나 데이터 뷰를 정하고, 읽기 전용 계정과 허용 범위를 구성하는 것입니다. 연결 방법은 시스템의 API, 승인된 데이터 추출, 조회용 데이터베이스 등 환경에 따라 달라집니다. API가 있다는 사실만으로 첨부 파일, 삭제 이력, 사용자 권한까지 제공된다고 가정하지 마세요.

시험 전에 연결 담당자가 확인할 내용은 다음과 같습니다.

• 접근할 테이블·문서 종류와 제외할 필드
• 문서 본문, 첨부, 상태를 얻는 경로와 사용 조건
• 원본 식별자와 원문으로 돌아가는 방법
• 조회 시점, 갱신 주기, 변경·삭제 감지 방법
• 연결 실패를 알리고 복구하는 담당자

대화로 발주를 변경하거나 결재를 올리는 기능은 조회와 별도의 업무입니다. 데이터 쓰기를 계획한다면 실행 권한, 승인, 중복 실행 방지, 취소·복구 절차를 따로 검토해야 합니다. 조회 PoC가 통과했다고 쓰기 작업까지 검증된 것은 아닙니다.

문서를 읽는 계정과 질문하는 사람의 권한을 맞추세요

연동 계정이 모든 결재 문서를 읽을 수 있어도 일반 직원이 같은 내용을 검색해도 된다는 뜻은 아닙니다. ERP의 사업장·부서·금액별 조회 권한과 그룹웨어의 열람·참조 권한을 어떻게 검색에 반영할지 정해야 합니다. 본문은 공개돼도 첨부 파일은 제한되는 경우도 시험에 넣으세요.

Microsoft의 검색 결과에 문서 접근 조건을 적용하는 패턴은 사용자 식별 정보와 문서의 접근 정보를 연결하는 참고 자료입니다. 실제 환경에서는 사용자 인증, 조직 변경, 권한 회수까지 함께 검증해야 합니다.

구매 담당자와 일반 직원이 같은 발주를 찾았을 때 어떤 결과가 보여야 하는지 미리 적습니다. 제한 문서의 링크만 숨기는 것으로 시험을 끝내지 말고, 제목·요약·인용 문장·대화 이력에서 내용이 드러나는지도 확인합니다. 수집 시점의 권한이 이후에도 그대로 남지 않도록 권한 변경을 갱신하는 방법도 정하세요.

통합 결과에는 상태와 시점을 남기세요

사내 데이터 통합 검색은 여러 저장소를 한 화면에 모으는 것만으로 완성되지 않습니다. ERP는 오전에 조회했고 결재 문서는 전날 색인했다면 같은 답변 안에 서로 다른 시점의 정보가 섞일 수 있습니다. 현황을 보여주는 답변에는 데이터 기준 시점과 변경이 아직 반영되지 않을 가능성을 설명할 수 있어야 합니다.

시험 상황	기대하는 확인 방식
발주와 납기 안내의 날짜가 다름	두 날짜와 각 원본을 구분하고 확정 여부 확인
결재가 진행 중에서 승인으로 바뀜	갱신 후 상태와 답변이 함께 바뀌는지 확인
첨부 파일이 삭제됨	이전 인용과 원문 링크의 처리 확인
동일 거래처의 다른 발주가 존재	업무 ID를 기준으로 잘못 합쳐지지 않는지 확인
ERP 연결이 끊김	과거 데이터를 최신 현황으로 표시하지 않는지 확인

평가할 때는 “관련 자료를 찾았다”와 “수량·상태를 정확하게 답했다”를 별도로 기록합니다. 데이터가 없으면 답변을 보류하는지, 누락된 시스템을 알려주는지도 봅니다. 추가로 시스템 담당자는 조회 부하를, 현업은 결과를 다시 확인하는 시간을 측정하면 운영 가능성과 업무 가치를 함께 판단할 수 있습니다.

연결 범위가 분명하면 도입 상담도 구체적입니다

Wissly는 문서·NAS·드라이브 연결과 원문 근거를 확인하는 문서 업무를 지원합니다. ERP, 그룹웨어, 업무용 SaaS는 데이터 구조와 권한 환경에 맞춰 연동 범위를 협의합니다. 모든 제품의 데이터를 즉시 연결하거나 모든 업무를 자동 처리하는 것으로 가정하기보다, 사용할 시스템과 필요한 데이터를 구체적으로 전달하세요.

Enterprise 도입 상담에는 구매 현황 같은 첫 업무, ERP·그룹웨어 제품과 버전, 연결할 데이터 예시, 허용 계정, 필요한 갱신 간격을 준비하면 좋습니다. 문서가 공유 폴더에도 흩어져 있다면 NAS 연결 준비를 함께 확인하세요. 한 업무의 조회와 근거 확인이 검증되면, 그 결과를 바탕으로 연동 범위와 운영 책임을 정할 수 있습니다.