FAX 수주를 Web으로 옮기려면 ── 이중 운용 기간의 설계와 단계 이행의 실무

이전 기사 「EDI란? 기업 간 수발주를 어떻게 수월하게 만드는가」에서는 FAX나 메일로 받은 주문을 사람이 다시 입력하는 업무를 시스템 간 데이터 교환으로 바꾸는 구조를 정리했습니다.

이 기사는 그 속편입니다. 주제는 「구조의 이해」에서 한 걸음 나아가, 어떻게 이행할 것인가입니다.

「FAX 수주를 Web화하고 싶다」는 상담은 대부분 이렇게 이어집니다.

「다만 거래처 중에는 FAX만 쓸 수 있는 곳도 있다」

「판매 관리 시스템은 지금 그대로 쓰고 싶다」

「전환하는 동안 수주가 멈추면 곤란하다」

즉 실무상의 과제는 Web 수주 시스템을 만드는 일이 아닙니다. FAX가 남은 채로 Web으로 단계적으로 옮겨 가는 기간을 어떻게 설계할 것인가입니다.

이 기사에서는 FAX 수주의 Web화를, 이중 운용 기간의 설계, CSV 가져오기라는 중간 형태, 상품·거래처 마스터 정비, 거래처를 끌어들이는 방법의 네 가지를 중심으로 정리합니다.

이 기사의 대상은 FAX나 메일로 도착하는 주문을 사람이 판매 관리 시스템에 입력하고 있는 회사의 수주 업무 담당자와 정보 시스템 담당자입니다. 읽고 나면 Web 수주 시스템 자체의 만드는 법이 아니라, 「어느 거래처부터, 어떤 순서로, 무엇을 측정하면서 옮길 것인가」라는 이행 계획의 짜는 법을 가져갈 수 있습니다. 구조의 전체 그림부터 알고 싶다면 먼저 이전 EDI 기사를 읽어 주세요.

1．먼저 결론

FAX 수주의 Web화를 계획할 때의 요점은 다음과 같습니다.

• 목표를 「FAX 폐지」가 아니라 「사람이 입력하는 주문 건수를 줄이는 것」에 둔다
• FAX와 Web의 이중 운용 기간은 반드시 생긴다는 전제로, 기간과 측정 방법을 먼저 설계한다
• 접수 방법(채널)은 여러 개여도 사내의 수주 처리는 한 갈래로 모은다
• 처음부터 Web 화면 입력을 요구하지 않고 CSV 가져오기라는 중간 형태를 마련한다
• Web 수주 화면에는 상품·거래처 마스터가 그대로 드러나므로 마스터 정비를 먼저 한다
• 거래처는 한꺼번에 전환하지 않고 건수와 협조도로 분류해 순서대로 이행한다

JIPDEC(지프데크, 일반재단법인 일본정보경제사회추진협회. 프라이버시마크 제도와 표준 기업 코드 운용으로 알려진 단체입니다)도 표준 기업 코드 사업 해설 페이지 「EDI의 이점과 표준의 필요성」에서 「인력 처리, FAX·전화 대응이 남으면 그 때문에 인원을 확보해야 해서 100%의 자동화·기계화를 할 수 없고, 효율화 효과를 충분히 얻지 못한다」고 말하고 있습니다. 그렇기 때문에 이중 운용 기간을 「어쩔 수 없이 생기는 것」으로 방치하지 않고, 짧게 만들어 가는 계획 자체를 설계 대상으로 삼습니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 23건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2．한꺼번에 전면 Web화하기가 실패하기 쉬운 이유

FAX 수주의 Web화에는 사내 시스템의 사정만으로는 정할 수 없는 특징이 있습니다. 주문을 보내는 쪽은 거래처이기 때문입니다.

전 거래처에 「다음 달부터 Web으로 주문해 주세요」라고 안내하는 방식은 다음과 같은 실패로 이어지기 쉽습니다.

• FAX로만 주문할 수 있는 거래처가 「예외」가 아니라 「계획의 장애」가 된다
• 거래처마다 사정이 다른데 같은 마감을 부과한다
• 이행하지 않는 거래처의 주문이 결국 FAX로 계속 도착해 이중 운용이 기한 없이 고착된다
• 「Web화했는데 인원이 줄지 않는다」는 평가가 되어 프로젝트가 멈춘다

원인은 목표를 「FAX를 없애는 것」에 두고 있기 때문입니다.

목표를 「사람이 입력하는 주문 건수를 줄이는 것」으로 바꾸면 계획은 현실적이 됩니다. 예를 들어 주문의 70%를 차지하는 상위 거래처만 Web이나 CSV로 이행하면, 나머지 30%가 FAX로 남아도 입력 작업은 크게 줄어듭니다.

전체를 한 번에 움직이는 것이 아니라, 효과가 큰 곳부터 순서대로 움직인다. 이것이 단계 이행의 기본입니다.

3．이행 후의 모습 ── 입구는 여러 개, 사내 처리는 한 갈래

단계 이행을 설계하기 전에, 목표로 하는 모습을 먼저 그려 둡니다.

포인트는 접수 채널과 수주 처리를 나눠서 생각하는 것입니다.

flowchart LR
    ORDER["공통 수주 데이터<br/>(형식을 통일)"]
    BACK["사내 처리<br/>재고 할당·출하·청구"]
    subgraph CH["접수 채널"]
        FAX["FAX"]
        MAIL["메일 첨부"]
        CSV["CSV 가져오기"]
        WEB["Web 수주 화면"]
    end
    FAX -->|"담당자가 입력"| ORDER
    MAIL -->|"담당자가 입력"| ORDER
    CSV -->|"자동 가져오기"| ORDER
    WEB -->|"자동 등록"| ORDER
    ORDER --> BACK

접수 채널이 몇 종류여도, 그 앞의 수주 데이터 형식과 처리를 한 갈래로 모아 두면 재고, 출하, 청구 등 후공정은 공통인 채로 돌아갑니다.

반대로 채널마다 다른 처리나 다른 대장을 만들어 버리면, 채널이 늘 때마다 업무가 복잡해지고 이중 운용의 부담이 계속 늘어납니다.

FAX로 도착한 주문도 담당자가 입력한 시점에 다른 채널과 같은 수주 데이터가 되도록 합니다. 이행이란 이 그림 안에서 「담당자가 입력」 행으로 흐르는 건수를 줄이고, 「자동 가져오기」「자동 등록」 행으로 흐르는 건수를 늘려 가는 작업이라고 할 수 있습니다.

기존 판매 관리 시스템을 반드시 새로 만들 필요는 없습니다. 수주 데이터의 입구를 추가할 수 있는지(CSV 가져오기 기능, 데이터베이스 연계, API 등)가 확인되면 지금 구조를 남긴 채로 진행할 수 있습니다. 이 확인 포인트는 이전 EDI 기사의 「사내 시스템으로의 접속을 확인한다」에서 정리한 바와 같습니다.

4．CSV 가져오기라는 중간 형태

FAX에서 곧바로 Web 화면 입력으로 옮겨 달라고 하면, 거래처에게 부담이 큰 경우가 있습니다.

발주하는 쪽에서 보면 Web 화면 입력은 「자사의 발주 시스템이나 Excel로 만든 주문을, 한 번 더 상대 화면에 입력하는 일」이기 때문입니다. 거래처가 자사 구조로 주문 데이터를 만들고 있다면, 그 데이터를 파일 그대로 받아 가져오는 편이 양쪽 작업이 적게 끝납니다.

그래서 중간 형태로 CSV(또는 Excel) 가져오기를 마련합니다.

제1단계: CSV를 메일에 첨부해 받고, 담당자가 가져오기 기능으로 읽는다
제2단계: 거래처가 Web 페이지에서 CSV를 업로드하고, 자동으로 가져온다
제3단계: 정형화된 거래처는 Web 수주 화면 또는 EDI로

제1단계에서도 주문서를 보면서 수기 입력하는 것에 비하면 입력 시간과 전사 실수는 크게 줄어듭니다. 거래처 쪽 변화는 「FAX로 보내던 것을 메일 첨부로 바꾸는」 정도라서 협조를 얻기 쉬운 것도 이점입니다.

CSV 가져오기를 설계할 때는 최소한 다음 항목을 정합니다.

이 6항목 가운데 실제로 가장 다툼이 많은 것은 코드 체계입니다. 「거래처의 상품 코드로 보내 달라」인지 「자사 상품 코드로 고친 뒤에 보내 달라」인지에 따라 변환표를 누가 가질지가 정해집니다. 영업에서는 「거래처에 자사 코드로 보내 달라고 하는 편이 편하다」는 목소리가 나오고, 정보시스템에서는 「거래처별 변환표를 가지는 것은 부담」이라는 목소리가 나옵니다.

판단의 타협점은 변환표는 「상품 변경을 맨 먼저 아는 쪽」이 가진다입니다. 신설·폐번을 맨 먼저 아는 것은 자사이므로, 자사 쪽에서 변환하는 형태로 두면 상품을 신설·폐번할 때마다 전 거래처에 「코드표를 바꿔 주세요」라고 요청할 필요가 없어집니다. 거래처에 자사 코드를 외우게 하는 방식은 시작할 때는 편해도, 신설·폐번할 때마다 인원 수만큼 연락이 발생합니다. 이 한 차례 조율을 이행 전에 끝내 두면 나중에 「왜 이 설계인가」를 다시 설명하지 않아도 됩니다.

또 하나 운용에 직결되는 것이 오류 통지 방법입니다. 가져오기는 원칙적으로 「한 행이라도 오류면 전체를 중단한다」(한 행이라도 부정이면 아무것도 가져오지 않는다) 편이, 부분적으로 들어간 주문을 나중에 쫓는 것보다 안전합니다. 다만 그것은 멈춘 사실이 반드시 누군가에게 도착한다는 전제에서 성립합니다. 최소 구성은 다음과 같습니다.

• 사내로의 메일 알림 ── 수주 담당 메일링 리스트 앞으로 「가져오기 실패」를 자동 송신합니다. 제목에 파일명과 거래처명, 본문에 오류 행 번호와 원인(「상품 코드 ABC-123이 마스터에 없습니다」 등)을 나열합니다.

• 관리 화면의 가져오기 이력 ── 성공·실패·미처리가 목록으로 보이는 화면을 마련합니다. 메일을 놓쳐도 아침 제일 먼저 여기를 보면 알아챌 수 있습니다.

• 거래처로의 연락 ── 처음에는 자동 회신하지 않고, 사내 담당자가 내용을 확인한 뒤에 연락합니다. Web 업로드 방식으로 나아간 단계에서 업로드 화면에 그 자리에서 오류를 표시하는 형태로 옮깁니다.

「오류는 로그에 나와 있으니 확인해 주세요」라는 설계는 이중 운용 기간에는 맞지 않습니다. 담당자는 FAX 처리로 이미 바쁘기 때문입니다.

CSV는 단순해 보여도 문자 코드, 줄바꿈, 쉼표나 인용 부호 처리 등에서 함정이 많은 형식입니다. 가져오기 처리를 구현할 때의 기술적 주의점은 「CSV 파일 처리의 실무 가이드」에 정리해 두었습니다.

덧붙여 CSV 가져오기는 최종 형태가 아니라 중간 형태입니다. 여기서 정한 항목 정의와 코드 체계는 그 후의 Web 수주나 EDI에서도 그대로 토대가 됩니다.

5．상품·거래처 마스터 정비를 먼저 한다

FAX 수주에서는 마스터의 미비를 담당자가 흡수하고 있습니다.

예를 들어 주문서에 오래된 상품명이 적혀 있어도 담당자가 「이것은 현행의 이 상품이다」라고 바꿔 읽어 입력합니다. 단위가 「케이스」로 적혀 있어도 1케이스가 몇 개인지를 기억하고 환산합니다.

CSV 가져오기나 Web 수주로 옮기면 이 바꿔 읽기를 기계가 하게 됩니다. 나아가 Web 수주 화면에서는 상품 마스터가 그대로 거래처의 눈에 닿습니다.

그래서 이행 전에 적어도 다음 정비가 필요합니다.

• 상품 코드 정리(폐번 정리, 중복 통합, 신구 코드 대응표)
• 상품명 표기 통일(거래처에 보여줄 수 있는 명칭인가)
• 단위와 입수량(낱개·케이스·팔레트의 관계, 최소 주문 수량)
• 거래처 코드와 납품처 코드(1 거래처에 여러 납품처가 있는 경우의 처리)
• 거래처별 적용 단가나 계약 조건을 어디에서 관리할지

여기서 중요한 것은 전 마스터를 완벽하게 만든 뒤에 시작하려고 하지 않는 것입니다. 그것을 기다리면 이행이 시작되지 않습니다.

현실적인 방법은 먼저 이행하는 거래처(파일럿)가 다루는 상품과 납품처 범위만 먼저 정비하고, 이행하는 거래처를 늘릴 때마다 범위를 넓히는 방법입니다. 마스터 정비 작업 자체를 단계 이행의 페이즈에 넣습니다.

6．이중 운용 기간의 설계

FAX와 Web(CSV)의 이중 운용은 이행 기간 중에는 반드시 발생합니다. 설계하지 않고 방치하면 이중 운용이 상시화되어, 「채널이 늘어난 만큼 일이 늘어난」 상태가 됩니다.

이중 운용 기간의 설계란, 구체적으로는 다음을 정하는 일입니다.

6.1．기간과 목표값을 정한다

「언제까지, 주문 건수의 몇 %를 자동 가져오기로 할지」를 수치로 정합니다. 예를 들어 「6개월 만에 FAX 수주 비율을 70%에서 30%로」와 같은 형태입니다.

기한이 없는 이중 운용은 그대로 고정됩니다. 도달하지 못한 경우에도 기한이 있으면 「왜 이행이 나아가지 않는가」를 거래처마다 확인하는 행동으로 이어집니다.

6.2．채널별 건수를 매월 측정한다

이행의 진척은 감각이 아니라 건수로 추적합니다.

• 채널별 수주 건수(FAX, 메일 첨부, CSV, Web)
• 수기 입력한 주문 건수와 소요 시간
• 가져오기 오류 건수와 원인
• 입력 정정·이중 등록 건수

이전 기사에서 든 도입 후에 측정하고 싶은 지표와 같은 생각입니다. 채널별로 나눠 측정하면 「어느 거래처에 손을 쓰면 효과가 큰가」가 보입니다.

문제는 이것을 어떻게 모을까입니다. 구조가 없는 채로 「매월 세어 봅시다」고 정해도 첫 달에 멈춥니다. 확실한 방법은 수주 데이터 자체에 측정용 항목을 하나 더하는 것입니다.

기존 판매 관리 시스템에 열을 더할 수 없는 경우에는 가져오기 처리와 입력 화면의 로그를 별도 테이블에 남겨 그쪽에서 집계합니다. 어느 쪽이든 측정 방법을 정하는 것은 이행을 시작하기 전입니다. 뒤에서 말하는 페이즈 판정(8장)의 기준이 채널 비율인 이상, 비율을 구할 수 없으면 다음 페이즈로 갈지 멈출지의 판단을 할 수 없습니다.

6.3．운용 규칙을 채널 간에 맞춘다

이중 운용 기간 중에 혼란이 일어나기 쉬운 것은 채널마다 업무 규칙이 다른 경우입니다.

• 수주 마감 시각은 FAX와 Web에서 같은가
• 주문 변경·취소는 어느 채널로 받는가(Web으로 받은 주문의 변경을 FAX로 받으면 대조가 필요해진다)
• 결품 시 연락 방법은 채널에 따라 바뀌지 않는가
• 주문 번호는 채널을 가로질러 유일한가(이중 등록 검출에 필요)

특히 「Web으로 주문하고, 직후에 전화나 FAX로 변경하는」 패턴은 반드시 발생합니다. 변경을 어느 채널로 받고, 누가 어느 데이터를 고칠지를 먼저 정해 둡니다.

6.4．FAX의 받는 방식도 개선 대상으로 삼는다

이중 운용 기간 중 FAX는 남습니다. 남는다는 전제라면 FAX 쪽 처리도 개선 대상입니다.

• FAX를 복합기로 받아 PDF화하고, 종이 관리를 그만둔다
• 수신한 PDF를 수주 폴더에 모으고, 처리 상황(미처리·입력 완료·보류)을 관리한다
• 입력 후의 FAX 원본(PDF)과 수주 데이터를 주문 번호로 연결해, 나중에 대조할 수 있게 한다

「FAX는 어차피 없어질 테니 손대지 않는다」고 생각하면 이중 운용 기간 중의 부담이 내려가지 않습니다. 이행이 끝날 때까지 FAX 처리도 같은 수주 데이터로 합류하는 하나의 채널로 다룹니다.

7．거래처를 끌어들이는 방법

단계 이행의 성패는 사내보다 거래처를 움직이는 쪽에서 정해집니다.

7.1．거래처를 분류한다

전 거래처를 똑같이 다루지 않고, 먼저 분류합니다.

효과를 정하는 것은 A와 B입니다. C 거래처를 무리하게 움직이려 하면 비용만 들기 때문에, 「FAX도 계속 받습니다」라고 분명히 말해도 되는 상대입니다.

7.2．파일럿을 1곳 고른다

처음부터 여러 곳을 병행해 이행하지 않고, 먼저 1곳에서 운용을 확립합니다. 고르는 기준은 이전 기사와 같습니다.

• 거래 건수가 많아, 효과를 측정하기 쉽다
• 정형적인 주문이 많다
• 담당자끼리 연락이 잘 되고, 시스템 연계에 대한 이해가 있다

파일럿에서 CSV 형식, 오류 시 연락 방법, 마스터 대응표, 안내 문서 등의 「틀」을 만들고, 두 번째 이후에는 그 틀을 재사용합니다.

7.3．상대의 이점으로 안내한다

거래처에서 보면 주문 방법의 변경은 자사 사정에 따른 요청입니다. 안내는 자사의 효율화가 아니라 상대의 이점으로 설명합니다.

• 수주 확인이 바로 돌아오므로 「도착했는지」를 묻는 확인 전화가 필요 없어진다
• 읽기 실수로 인한 오출하·수량 차이가 줄어든다
• 주문 이력을 스스로 조회할 수 있어 반복 주문이 편해진다(Web 수주의 경우)
• FAX 송신 작업과 송신 오류의 재송신이 없어진다

아울러 실무적인 배려도 효과가 있습니다.

• 조작 절차는 1장의 매뉴얼로 정리한다(화면 몇 장의 조작 설명으로 충분한 규모로 만든다)
• 시작일과 병용 기간을 명시한다(「◯월부터 Web으로도 받습니다. FAX도 당분간 병용할 수 있습니다」)
• 처음 몇 번은 FAX와 Web 어느 쪽으로 보내도 받고, 문의에 즉시 대응한다

덧붙여 「FAX를 ◯월에 폐지합니다」라는 안내를 처음에 내는 것은 권하지 않습니다. 이행이 진행되어 남는 거래처가 소수인 단계에서 비로소 기한 이야기를 하는 편이 관계를 해치지 않고 끝납니다.

중소기업의 수발주 디지털화에 대해서는 중소기업청이 공통 EDI를 포함한 표준화 활동과 효과를 소개하고 있습니다. 업계 단체나 주요 거래처가 이런 표준에 대응하고 있는 경우에는 독자 형식이 아니라 표준에 맞추는 선택지도 검토합니다.

8．단계 이행의 모델 케이스

여기까지의 내용을 시계열 모델로 정리합니다. 기간은 어디까지나 일례이며, 거래처 수와 사내 체제에 따라 달라집니다.

페이즈 0의 「현황 정리」는 이전 기사에서 소개한 수발주 방법의 목록화를 그대로 쓸 수 있습니다.

또한 수주 관리 자체를 Web 시스템으로 옮겨야 할지, 데스크톱 앱으로 남겨야 할지 고민하는 경우에는 「Windows 앱을 Web으로 옮겨야 하는가」에서 판단의 틀을 정리하고 있습니다. 접수 채널의 Web화와 사내 시스템의 Web화는 분리해서 판단할 수 있습니다.

9．자주 있는 막힘과 대책

마지막으로 실제 이행에서 일어나기 쉬운 막힘을 정리합니다.

정리

FAX 수주의 Web화는 시스템을 만드는 작업이라기보다, 이행 기간을 설계하는 작업입니다.

• 목표는 「FAX 폐지」가 아니라 「사람이 입력하는 주문 건수의 삭감」에 둔다
• 접수 채널은 여러 개여도 되지만, 사내의 수주 데이터와 처리는 한 갈래로 모은다
• 처음부터 Web 화면 입력을 요구하지 않고, CSV 가져오기라는 중간 형태를 끼운다
• 마스터 정비는 먼저 이행하는 거래처의 범위부터 단계적으로 진행한다
• 이중 운용 기간에는 기한과 목표값을 두고, 채널별 건수로 진척을 측정한다
• 거래처는 건수와 협조도로 분류하고, 파일럿 1곳에서 틀을 만든 뒤에 넓힌다

이전 기사에서 정리한 대로, EDI나 Web 수주의 효과는 받은 데이터를 사내 업무의 어디까지 흘릴 수 있는지로 정해집니다. 이행의 설계란, 그 흐름에 합류하는 주문의 비율을 무리 없는 순서로 늘려 가는 계획입니다.

수발주의 Web화를 검토 중이신 분께

FAX 수주의 재검토를 검토하고 있으나, 거래처와의 조정, 기존 판매 관리 시스템과의 접속, CSV 형식이나 마스터 정비의 진행 방법 등 어디서부터 손대야 할지 고민되는 경우에는, 먼저 현황의 채널별 수주 건수 정리부터 시작할 필요가 있습니다.

合同会社小村ソフト에서는 기존 Windows 업무 앱이나 데이터베이스를 살린 CSV 가져오기·Web 수주 연계의 설계·구현, 그리고 이행 계획 자체의 정리를 상담받으실 수 있습니다.

전면 쇄신을 전제로 하지 않고, 현재의 판매 관리 구조를 남긴 채로 접수 채널만 단계적으로 추가해 가는 구성도 검토할 수 있습니다.

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.