구매 주문 데이터 입력 문제
— 그리고 이를 유지하는 요인

아무도 말하지 않는 217달러짜리 문제

조달 관리자에게 구매 주문서 처리 비용이 얼마인지 물어보면 대개 멍한 표정을 짓습니다. 비용에 신경 쓰지 않아서가 아닙니다. 신경 쓰긴 합니다. 하지만 수동 PO 데이터 입력 비용이 일상 업무 전반에 고르게 분산되어 배경 속으로 사라져 버리기 때문입니다. 누구의 예산에도 항목으로 잡히지 않습니다. 그냥 "우리가 하는 일"일 뿐입니다.

첨단 조달 전략 센터(CAPS Research)는 수년간 PO 처리 비용을 측정해 왔습니다. 업계를 망라한 데이터에 따르면 PO당 평균 비용은 업종에 따라 약 50달러에서 1,000달러 이상이며, 평균은 약 217달러입니다. 여러 출처의 제조업 특화 추정치는 PO당 95~145달러에 수렴합니다. 이 비용에는 데이터를 입력하는 가시적인 노동뿐만 아니라 이메일 후속 조치, 상태 확인, 오류 수정, 중복 주문 해결, 그리고 PO에 명시된 내용과 공급업체가 실제로 선적한 내용 간의 불일치를 조정하는 데 소요되는 시간이 포함됩니다.

월 200건의 PO를 각각 120달러에 처리하는 회사는 단순히 주문 데이터를 한 문서에서 다른 문서로 옮기는 행정 비용으로 연간 288,000달러를 지출하고 있습니다. 그리고 이것은 중간값의 경우입니다. 복잡한 제조 PO(50개 라인 항목 테이블과 다단계 승인 포함)의 상위권에서는 PO당 비용이 500달러를 초과할 수 있습니다.

숫자 자체가 중요한 것은 아닙니다. 중요한 것은 이러한 비용이 10년 넘게 독립적인 연구 기관에 의해 측정, 발표, 벤치마킹되어 왔다는 점입니다. 모든 조달 리더는 이 데이터에 접근할 수 있습니다. 이러한 비용을 줄일 수 있는 자동화 도구도 존재합니다. 그럼에도 불구하고 "숫자를 아는 것"과 "숫자를 바꾸는 것" 사이의 격차는 중견 제조 및 유통 기업 대다수에서 지속되고 있습니다. 물어볼 가치가 있는 질문은 "비용이 얼마인가"가 아니라 해결책이 미스터리가 아닌데도 왜 해마다 그 비용이 계속 들고 있는가입니다.

문제는 하나가 아닙니다. 세 가지가 쌓여 있습니다.

소프트웨어 업체에 수동 구매 주문 처리의 문제점을 묻는다면, "데이터 입력이 느리고 오류가 많다"는 한 문장으로 답할 것입니다. 기술적으로는 맞는 말입니다. 하지만 진단으로는 전혀 쓸모가 없습니다. 진짜 문제는 조달팀이 클릭할 수 있는데도 타이핑을 한다는 것이 아닙니다. 진짜 문제는 현재 업계 조건에서 타이핑이 사실상 불가피하도록 만드는 세 가지 계층 구조입니다.

첫 번째 계층: 형식의 파편화. 모든 고객의 구매 주문서는 서로 다른 형식으로 되어 있습니다. 어떤 곳은 PO 번호를 오른쪽 상단에, 다른 곳은 왼쪽 헤더 블록에, 또 다른 곳은 2페이지 바코드에 넣습니다. 5줄, 50줄, 또는 300줄이 될 수 있는 라인 아이템 표는 6개 열일 수도 있고 14개 열일 수도 있습니다. 품목 코드는 1열 또는 4열에 있을 수 있습니다. 납품일은 각 라인 항목별로 표시되거나 헤더의 단일 필드로 표시될 수 있습니다. r/manufacturing의 한 Reddit 사용자가 말했듯이: "우리의 가장 큰 문제는 고객 구매 주문서 형식이 통일되지 않았다는 점입니다. 모든 회사가 필드 이름까지도 다른 PO 형식을 사용합니다."

새로운 관찰은 아닙니다. 모든 조달 전문가가 알고 있습니다. 덜 이해되는 점은 형식 파편화는 버그가 아니라 시스템의 균형 상태라는 것입니다. 각 회사의 PO 형식은 자체 ERP에 의해 생성되며, 이 ERP는 수년간의 비즈니스별 결정을 통해 진화한 내부 데이터 구조에 맞게 구성되었습니다. 80명의 고객에게 PO 형식을 표준화하라고 요청하는 것은 조달 요청이 아닙니다. 80개 회사에 ERP 출력을 재구성하라고 요청하는 것과 같으며, 그들의 관점에서는 ROI가 전혀 없는 작업입니다.

두 번째 계층: 공급업체 인센티브 불일치. 고객으로부터 PO를 받는 제조업체라면 데이터 입력을 자동화할 강력한 인센티브가 있습니다. 타이핑 시간을 1분이라도 절약하면 생산 계획, 재고 관리 또는 공급업체 협상에 돌려쓸 수 있습니다. 그러나 PO를 보내는 고객 입장에서는 공급업체의 업무를 편하게 하기 위해 형식을 바꿀 인센티브가 전혀 없습니다. PO는 항상 그랬듯이 ERP에서 생성되어 이메일에 PDF로 첨부되어 발송되며, 공급업체의 데이터 입력 부담은 보이지 않습니다. 이러한 비대칭성은 근본적입니다. 형식을 통제하는 쪽은 표준화할 인센티브가 없고, 표준화가 필요한 쪽은 이를 요구할 레버리지가 없습니다.

세 번째 계층: 도구 불일치. 지난 20년간 문서 데이터 추출의 지배적인 접근 방식은 템플릿 기반이었습니다. 샘플 문서의 필드 주위에 상자를 그리고 레이블을 지정하면, 동일한 레이아웃과 일치하는 이후 문서에서 데이터를 추출합니다. 이는 단일 공급업체의 송장에는 효과적입니다. 그러나 40개 다른 고객의 PO에는 적용되지 않습니다. 각 고객마다 별도의 템플릿이 필요합니다. 각 템플릿을 만드는 데 시간이 걸립니다. 그리고 고객이 ERP를 업그레이드하거나 PO 레이아웃을 변경(시스템 마이그레이션, 인수, 리브랜딩 시 발생)하면 템플릿은 조용히 깨져서 왜곡된 데이터를 생성하거나 아무것도 생성하지 않습니다. 없애려고 했던 작업(수동 데이터 입력)이 다른 종류의 수동 작업(템플릿 유지보수)으로 대체되었습니다.

EDI는 세계 최대 기업들을 위해 이 문제를 해결했습니다. 나머지 기업들에게는 한계를 만들었습니다.

몇 년 이상 조달 분야에 종사해왔다면 EDI에 대한 이야기를 들어봤을 것입니다. EDI 850 — 전자 구매 주문서를 위한 ANSI X12 표준 — 은 기계 간 PO 교환을 위한 구조화된 형식을 정의합니다. 양측이 EDI를 사용할 때, 구매 주문서는 구매자의 ERP에서 공급업체의 주문 관리 시스템으로 사람의 개입 없이 직접 전송됩니다. PDF도, 타이핑도, 형식 변형도 없습니다. 양측이 동일한 트랜잭션 세트를 따르기 때문입니다.

구현된 관계에서는 아름답게 작동합니다. 대형 자동차 제조업체, 대형 소매업체, 항공우주 기업들은 수십 년 동안 1차 공급업체와 EDI를 사용해 왔습니다. 월마트의 공급망은 EDI 없이는 붕괴될 것입니다.

문제는 EDI의 채택 곡선에 단단한 한계가 있다는 것입니다. EDI를 구현하려면 양측 모두에 기술 인프라가 필요합니다. EDI 변환 소프트웨어, 통신 프로토콜(AS2, VAN), 그리고 EDI 850 세그먼트(BEG, N1, PO1, PID, CTT)와 각 당사자의 내부 데이터 구조 간 매핑 로직이 필요합니다. 설정 비용은 거래 파트너당 수천 달러에 달합니다. 대량 거래 관계(주간 수백만 달러 규모의 주문을 하는 제조업체)의 경우 ROI는 즉시 실현됩니다. 분기별 또는 산발적으로 주문하는 소규모 고객(대부분의 중견 B2B 관계를 설명함)의 경우 ROI는 결코 실현되지 않습니다.

그 결과는 이중 계층 조달 현실입니다. 상위 10~20%의 거래 관계는 EDI로 운영됩니다. 나머지 80%는 이메일과 PDF로 운영됩니다. 두 번째 그룹이 수동 데이터 입력이 존재하는 곳이며, 자동화 옵션이 이러한 관계가 경제적으로 지원할 수 없는 형식 표준화를 요구하는 한 계속 존재할 곳입니다.

CAPS Research에 따르면 공급망 리더의 31%는 구식 조달 소프트웨어가 실행을 차단한다고 말하고, 37%는 데이터 접근 문제를 최우선 장벽으로 꼽습니다. 이 수치는 자동화를 모르는 회사를 설명하는 것이 아닙니다. 자동화를 평가했지만 공급업체 포트폴리오의 대부분에 대해 경제성이 맞지 않는다는 것을 발견한 회사를 설명합니다.

템플릿 함정: 새로운 수작업을 만드는 자동화

이론적으로 템플릿 기반 추출은 합리적인 접근 방식입니다. 도구에 샘플 문서를 보여주고 각 필드의 위치를 표시하면 도구가 이후 문서에서 해당 추출 패턴을 복제합니다. 초기 OCR 시절부터 엔터프라이즈 IDP 플랫폼부터 가벼운 SaaS 제품까지 대부분의 문서 자동화 도구가 작동해 온 방식입니다.

실제로 템플릿 기반 추출에는 치명적인 확장 속성이 있습니다. 필요한 템플릿 수는 수신하는 고유 문서 형식의 수에 비례하여 증가합니다. 40명의 고객이 각각 다른 PO 레이아웃을 사용한다면 40개의 템플릿이 필요합니다. 새 고객이 추가될 때마다 일반적으로 10~15분이 소요되는 필드 식별, 영역 지정, 추출 정확도 확인 과정의 새 템플릿 설정 세션이 필요합니다. 41번째 고객이 온보딩되면 누군가는 하던 일을 멈추고 템플릿 #41을 만들어야 합니다.

이로 인해 자동화의 약속이 역전됩니다. 도구는 반복적인 수작업을 없애기 위한 것이었습니다. 대신 덜 눈에 띄지만 동일한 시간이 소요되는 새로운 유형의 반복적인 수작업, 즉 템플릿 유지보수가 생겼습니다. 그리고 데이터 입력과 달리 템플릿 오류는 조용히 발생합니다. 고객이 PO 형식을 변경하면(새 ERP, 새 브랜딩, 합병으로 인한 형식 통합) 템플릿은 오류를 발생시키지 않습니다. 잘못된 데이터나 누락된 데이터를 추출하며, 이는 주문이 잘못되었거나, 배송이 잘못 라우팅되었거나, 송장이 일치하지 않는 등 다운스트림에서 발견됩니다.

비용 구조는 교활합니다. 수동 데이터 입력 오류(잘못 입력된 수량이나 전치된 부품 번호)는 일반적으로 동일한 워크플로 내에서, 동일한 사람이나 다운스트림 검증에 의해 발견됩니다. 템플릿 오류는 체계적인 오류를 생성합니다. 고객 X의 모든 PO에서 배송 날짜 필드가 누락되었고, 창고에서 어디로 배송할지 물을 때까지 아무도 모릅니다. 사고당 오류 비용은 더 높고, 탐지 지연 시간은 더 깁니다.

SAP, NetSuite, Microsoft Dynamics, Epicor, Sage, Infor 등 여러 ERP 생태계에 걸쳐 20~80명의 다양한 고객으로부터 PO를 처리하는 중견 제조업체의 경우 템플릿 접근 방식은 작업을 줄이지 않습니다. 데이터 입력 데스크에서 템플릿 구성 화면으로 작업을 옮길 뿐입니다. 그리고 전담 자동화 엔지니어가 없는 조달 팀의 경우 이러한 이동은 문제를 개선하기보다 악화시킵니다.

조달팀이 실제로 매일 하는 일

원가 벤치마크와 구조 분석 이면에는 제조업 조달 부서에서 하루에도 수천 번씩 발생하는 실제 업무 흐름이 있습니다. Reddit과 업계 포럼에서 조달 전문가들이 묘사하는 내용을 종합해, 꾸민 장면이 아닌 있는 그대로 설명할 가치가 있습니다.

받은 편지함에 고객으로부터 새 메시지가 도착했습니다. 각 메시지는 구매 주문서 첨부 파일로, 보통 PDF 형식입니다. 일부는 고객 포털을 통해 들어오지만, 대부분은 이메일로 옵니다. 조달 코디네이터가 첫 번째 파일을 엽니다. NetSuite를 사용하는 고객이 보낸 것으로, PO 번호는 헤더에, 공급업체 코드는 참조 필드에, 라인 항목은 9열 테이블에 있습니다. 코디네이터는 스프레드시트나 ERP를 열고 입력을 시작합니다: PO 번호, 날짜, 고객명, 배송지 주소. 그다음 라인 항목을 한 행씩 입력합니다: 품목 코드, 설명, 수량, 단위, 단가, 합계 금액. PO에 15개 라인 항목이 있다면, 숫자 하나 잘못 옮기거나 행을 건너뛰지 않고 수동으로 90개의 개별 데이터를 전송해야 합니다.

두 번째 PO는 SAP를 사용하는 고객이 보냈습니다. 레이아웃이 완전히 다릅니다. PO 번호는 오른쪽 상단에 있습니다. 고객명은 다른 위치에 있습니다. 라인 항목 테이블은 9열이 아닌 12열이며, 창고 위치와 라인별 배송일 필드가 추가되었습니다. 필드명도 다릅니다. SAP에서는 NetSuite의 "품목 코드"를 "자재"라고 부릅니다.

세 번째 PO는 ERP가 전혀 없는 고객이 보낸 것입니다. Word 문서를 PDF로 변환한 파일로, 라인 항목이 테이블이 아닌 글머리 기호 목록으로 되어 있습니다. 템플릿 기반 추출 도구는 이 파일을 즉시 처리하지 못할 것입니다. 사람은 읽을 수 있지만, 시간당 여러 번 완전히 다른 세 가지 문서 구조를 전환해야 하는 인지적 마찰이 진정한 생산성 저하의 원인입니다. 타이핑 속도가 문제가 아닙니다.

Reddit의 r/procurement에서 한 사용자가 말했듯이: "우리는 말 그대로 공급업체에서 PDF를 받아 스프레드시트에 값을 복사하고, 모든 라인을 PO와 대조하고, 불일치 사항에 대해 공급업체에 이메일을 보내고, 이 모든 시스템이 서로 통신하지 않기 때문에 모든 것을 ERP에 붙여넣고 있었습니다. 업무의 절반은 공급업체 관리로 위장된 행정 작업입니다."

이 설명에서 놀라운 점은 비효율성이 아니라 정확성입니다. 시스템은 정말로 서로 통신하지 않습니다. PDF는 막다른 형식입니다. 시각적 레이아웃은 보존하지만 데이터 구조는 파괴합니다. 수신 측 ERP는 구조화되고 필드 매핑된 입력을 기대합니다. 이 두 형식 사이에는 PO가 고객 시스템을 떠날 때 손실된 데이터 구조를 수동으로 재구성하는 인간이 있습니다. 그 인간은 가치를 더하는 것이 아닙니다. 형식 변환을 수행하고 있는 것입니다. 소프트웨어가 처리해야 하지만 형식이 계속 변경되기 때문에 처리할 수 없는 작업입니다.

수동 입력을 정당화하는 조직 관성

수동 PO 데이터 입력 비용이 측정 가능하고 이를 줄일 도구가 존재하는데도, 시장이 이 문제를 해결하지 못한 이유는 무엇일까? 그 답은 기술을 넘어 조직 행동과 공급업체 인센티브에 있습니다.

의사 결정권자에게 비용이 보이지 않습니다. 수동 PO 데이터 입력은 별도 비용으로 나타나지 않습니다. 구매 담당자와 코디네이터의 시간이 주중에 분산되어 '데이터 입력 노동'이 아닌 '운영 간접비'로 분류됩니다. '수동 PO 처리 — 288,000달러'라는 항목을 승인하는 CFO는 없습니다. 비용은 실재하지만, 어차피 지급될 급여에 흡수됩니다. 이러한 회계적 투명성 부재로 인해 문제 해결을 위한 자연스러운 예산 주체가 없습니다. IT는 조달 효율성을 담당하지 않고, 조달 부서는 소프트웨어 평가를 담당하지 않으며, 재무 부서는 해당 항목을 인식하지 못합니다. 문제는 부서 간 간극에 빠집니다.

자동화 실패는 수동 작업보다 더 가시적입니다. 수동 데이터 입력에서 오류가 발생하면 해결 방법은 간단합니다. 실수를 찾아 수정하고 업데이트된 주문을 보내면 됩니다. 짜증나지만 일상적인 일입니다. 반면 자동화 도구에서 오류가 발생하면 실패 규모가 더 크고 가시적이며 진단이 어렵습니다. 잘못된 필드 매핑으로 50개의 PO를 자동 처리하면 50개의 잘못된 주문이 생성되어 관리자 책상 위에 올라가는 위기가 발생합니다. 자동화를 도입한 조달 전문가가 비난을 받습니다. 대부분의 조직이 한 번의 나쁜 자동화 경험에서 얻는 교훈은 '우리 문서가 도구로 처리하기엔 너무 복잡하다'이지, '형식 다양성에 비해 잘못된 도구 유형을 사용했다'가 아닙니다. 이러한 위험 비대칭(자동화 실패는 수동 실패보다 더 높은 조직 비용을 초래함)은 현상 유지에 대한 강력한 편향을 만듭니다.

ERP 공급업체는 잘못된 인센티브를 가지고 있습니다. PO 데이터 입력을 해결하기에 가장 적합한 기업(SAP, Oracle, Microsoft, NetSuite, Epicor)은 이를 해결할 인센티브가 가장 적은 기업입니다. 이들의 조달 모듈은 구조화된 입력을 가정합니다. 이들의 영업 방식은 포인트 솔루션 추출이 아닌 전체 제품군 채택을 중심으로 구축됩니다. 고객이 '내 고객의 PO 데이터를 시스템에 어떻게 입력하나요?'라고 묻으면 일반적인 답변은 '고객이 당사 포털을 사용하게 하세요', 'EDI를 설정하세요', 또는 '수동으로 입력하세요'입니다. 세 가지 답변 모두 형식 문제를 솔루션 외부의 문제로 간주합니다. ERP 공급업체의 비즈니스 모델은 고객이 종단 간 플랫폼을 채택하는 데 의존하며, 시스템과 고객 시스템 간 경계에 있는 추출 단계를 해결하는 데 의존하지 않습니다.

이 문제는 여러 세대의 조달 전문가들 사이에서 정상화되었습니다. 15년 동안 조달 분야에 종사해 온 사람들은 PO 데이터 입력이 수동이 아니었던 때를 기억하지 못합니다. 그들은 이에 맞춰 워크플로를 구축했습니다. Excel 단축키, 매크로, 수동 입력을 견딜 수 있게 해주는 정신적 모델을 가지고 있습니다. 자동화를 제안하는 것은 효율성 개선처럼 들리지 않고, 모든 결함에도 불구하고 수년간 안정적으로 주문을 처리해 온 시스템을 위협하는 것처럼 들립니다. 변화의 운영 비용(새 도구 학습, 출력 신뢰, 실패 시 예외 처리)은 수학적으로 그 반대임에도 불구하고 현상 유지의 운영 비용보다 더 크게 느껴집니다.

실제로 판도를 바꿀 요소

근본 문제가 형식의 파편화(동일한 논리 정보(PO 번호, 라인 항목, 수량, 가격)를 무제한의 물리적 레이아웃으로 배열한 문서)라면, 해결책은 각 레이아웃을 개별적으로 처리해야 하는 도구가 될 수 없습니다. 레이아웃이 무엇인지 신경 쓰지 않는 도구여야 합니다.

이것이 템플릿 기반 추출과 의미 기반 추출의 차이입니다. 템플릿은 묻습니다: 필드가 어디에 있습니까? 3열, 7행, 왼쪽 여백에서 150픽셀. 의미 기반 접근 방식은 묻습니다: 필드가 무엇입니까? "PO 번호"의 의미적 역할과 일치하는 텍스트(문서 상단 근처의 고유 식별자, 일반적으로 영숫자이며 "PO #" 또는 "주문 번호" 또는 "구매 주문 번호" 등의 변형으로 레이블 지정됨)를 찾아 페이지 내 위치에 관계없이 값을 추출합니다.

이것이 바로 열 이름 추출이 하는 일입니다: 원하는 열("PO 번호", "공급업체 이름", "품목 코드", "수량", "단가", "라인 합계")을 정의하면 AI가 각 값의 위치가 아닌 의미를 이해하여 찾습니다. 입력한 열 이름이 출력 테이블의 헤더가 됩니다. 추출 논리가 위치 기반이 아닌 의미 기반이기 때문에 하나의 열 정의가 모든 고객의 PO 형식에서 작동합니다.

구조적 영향은 상당합니다:

• 제로 템플릿 운영. 고객별 설정이 필요 없습니다. 유지 관리할 템플릿 라이브러리가 없습니다. 고객이 PO 레이아웃을 변경할 때 조용히 실패하지 않습니다. 추출이 각 문서의 구조에 자동으로 적응합니다.
• 라인 항목 처리. 구매 주문서의 주요 페이로드는 라인 항목 테이블로, 다양한 열 구성을 가진 수십 개의 행에 걸쳐 있을 수 있습니다. 열 이름 추출은 각 행을 완전한 레코드로 읽어 올바른 수량, 설명 및 가격을 각 라인에 매핑합니다(여러 페이지에 걸쳐 분할된 테이블 포함).
• 다중 형식 입력. 동일한 열 정의가 PDF, 스캔 문서, 심지어 이메일 스크린샷에서도 작동합니다. 추출 논리는 SAP에서 생성된 PO와 Word 문서에 입력된 PO를 구분하지 않습니다. 형식이 아닌 내용을 읽습니다.

이것이 실제로 어떻게 작동하는지, PO 추출에 대한 필드별 가이드를 포함한 자세한 설명은 템플릿 없이 Excel로 구매 주문서에서 특정 필드 추출하기에 관한 기사를 참조하세요. 일괄 처리(단일 작업으로 수십 개의 다른 고객으로부터 온 PO에 동일한 열 정의 실행)에 대해서는 모든 공급업체 형식의 구매 주문서를 하나의 스프레드시트로 일괄 처리하기 가이드를 참조하세요. 그리고 종단 간 자동화 워크플로(추출 출력을 기존 주문 관리 시스템에 연결하는 방법 포함)는 ERP 없이 구매 주문 데이터 입력 자동화하기에 관한 기사를 참조하세요.

자주 묻는 질문

모든 고객이 당사 PO 형식을 사용하도록 강제할 수 없는 이유는 무엇인가요?

시도해 볼 수는 있습니다. 구매력이 큰 대기업은 주요 공급업체와의 협상에서 성공하는 경우도 있습니다. 그러나 대부분의 중견기업은 협상력이 반대 방향으로 흐릅니다. 고객의 PO 출력을 표준화해야 할 필요성보다 고객의 비즈니스를 유지하는 것이 더 중요합니다. 설사 고객이 동의하더라도, 변경을 실행하려면 고객의 IT팀이 ERP 출력을 재구성하고 테스트한 후 배포해야 합니다. 이는 실질적인 비용이 들지만 고객에게 직접적인 이점은 전혀 없는 프로젝트입니다. 대부분의 조달팀은 형식 표준화를 강제하는 데 드는 노력이 다양한 형식을 처리하는 노력보다 더 크다는 것을 알게 됩니다.

ERP에서 이미 PO 데이터 입력을 처리하지 않나요?

대부분의 ERP 조달 모듈은 PO 생성 — 공급업체에 발주서를 작성하는 것 — 을 처리하지만, PO 접수 — 고객으로부터 구매 주문서를 받아들이는 것 — 에는 훨씬 취약합니다. ERP는 구조화된 입력(EDI, CSV 가져오기 또는 직접 데이터 입력)을 기대하며, 비정형 PDF에서 구조화된 데이터를 추출하는 내장 메커니즘은 제공하지 않습니다. 고객이 PO를 PDF 첨부 파일로 보내는 경우, ERP는 이를 첨부 파일로 저장할 수 있지만 추가 추출 도구나 수동 입력 없이는 읽을 수 없습니다.

복잡한 라인 항목 테이블이 있는 구매 주문서에 대한 AI 기반 추출의 정확도는 어느 정도인가요?

인쇄된 테이블 데이터는 시각적 AI 모델을 사용하여 최대 99%의 정확도로 인식할 수 있습니다. 가장 까다로운 경우는 긴 테이블이 아닙니다. AI는 반복적인 구조를 잘 처리합니다. 문제는 라인 항목이 행이 아닌 서술형 텍스트로 구성된 문서(서비스 기반 PO에서 흔함)나 인쇄된 테이블에 수기 주석이 추가된 경우입니다. 이러한 예외적인 경우에는 추출을 완전히 제거하기보다는 수동 작업을 80~90% 줄이는 1차 처리로 간주해야 합니다. 결과는 ERP 또는 주문 관리 시스템에 반영되기 전에 항상 검토되어야 합니다.

고객이 수기 변경 사항이나 주석이 있는 PO를 보내면 어떻게 하나요?

열 이름 추출은 인쇄된 문서의 주석을 포함한 필기를 처리할 수 있습니다. AI는 필기 텍스트를 문서 내용의 일부로 읽고 의미에 따라 적절한 필드에 매핑합니다. 필기의 정확도는 인쇄된 텍스트보다 낮습니다. 특히 필기체나 연필로 가볍게 쓴 주석의 경우 더욱 그렇습니다. 따라서 수기 PO는 깨끗하게 인쇄된 PO보다 더 주의 깊게 검토해야 합니다.

이미 비용을 지불하고 있는 ERP 위에 또 다른 소프트웨어 구독을 추가하는 것일 뿐인가요?

이는 대부분의 ERP가 다루지 않는 특정 격차를 해결합니다. PDF PO를 받은 후 작업할 구조화된 데이터를 확보하기까지의 추출 단계입니다. 현재 구매 담당자와 코디네이터의 시간으로 이 단계에 비용을 지불하고 있다면 — 비용 벤치마크에 따르면 대부분의 중간 규모 제조업체가 PO당 $95~$145를 지출하고 있습니다 — 비교 대상은 "소프트웨어 대 소프트웨어 없음"이 아닙니다. "소프트웨어 대 인건비"입니다. 월 200건의 PO를 처리하는 제조업체의 경우, 보수적으로 추정해도 연간 수동 처리 비용이 $200,000를 넘습니다. 중요한 질문은 추출 도구가 비용보다 더 많은 금액을 절감하는지 여부입니다. 이 계산은 PO의 양과 복잡성에 따라 달라지며, 도구가 기존 ERP 예산 범주에 속하는지 여부와는 무관합니다.

문제의 실제 근원

구매 주문 데이터 입력 문제가 수십 년간의 자동화 기술에도 불구하고 사라지지 않은 데는 이유가 있습니다. 조달 팀이 기술 공포증이 있거나 정보가 부족해서가 아닙니다. 문제의 구조 자체 — 무한한 형식 변형, 구매자와 공급업체 간의 잘못된 인센티브, 다양한 형식을 확장할 수 없는 템플릿 기반 접근 방식이 지배하는 도구 환경 — 때문에 명백한 해결책(자동화 소프트웨어 구매)이 대부분의 조달 관계에서 효과적이지 않습니다.

EDI 850은 설정 비용을 감당할 수 있는 대량 파트너십을 위해 이 문제를 해결했습니다. 템플릿 기반 추출은 형식 안정성이 보장된 경우에 해결책이 되었습니다. 그러나 이 두 솔루션 사이에는 실제 조달의 대부분을 차지하는 격차가 있습니다: 수십 명의 고객, 각자 고유한 PO 형식을 가지고 있으며, 그 누구도 당신을 위해 표준화하지 않을 것입니다. 이 격차가 바로 수동 데이터 입력이 존재하는 곳이며, 조달 팀이 형식 표준화 없이도 작동하는 도구를 채택하기 전까지는 계속 존재할 것입니다.

템플릿 기반 추출에서 의미 기반 추출로의 전환 — "필드가 어디에 있나"에서 "필드가 무엇인가"로 질문을 바꾸는 것 — 은 문제의 경제학을 구조적 근본에서 변화시킵니다. 추출 정확도가 위치 매핑이 아닌 의미 이해에 의존할 때, 형식 다양성은 더 이상 장벽이 아니라 무의미해집니다. 자동화 비용은 "공급업체당 하나의 템플릿"에서 "모든 공급업체를 위한 하나의 열 정의"로 떨어집니다. 채택 장벽은 기술적 능력이 아니라, 이전 세대의 자동화 도구가 문서 형식이 안정적인 세상을 위해 설계되었으며 조달 현실은 그 반대라는 점을 인식하는 데 있습니다.