FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간 설계와 단계적 이행 실무

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

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

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

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

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

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

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

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

1. 먼저 결론

FAX 수주의 웹화를 계획할 때 핵심은 다음과 같습니다.

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

JIPDEC도 FAX나 전화 같은 수작업 처리가 남으면 그 대응 인력이 필요해져 효율화 효과를 충분히 얻기 어렵다고 지적합니다. 그렇기 때문에 이중 운영 기간을 「어쩔 수 없이 발생하는 것」으로 방치하지 않고, 단축해 가는 계획 자체를 설계 대상으로 삼아야 합니다.

2. 갑작스러운 전면 웹화가 실패하기 쉬운 이유

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

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

• FAX로만 주문할 수 있는 거래처가 「예외」가 아니라 「계획의 장애물」이 된다
• 거래처마다 사정이 다른데도 같은 마감일을 강요하게 된다
• 이행하지 않는 거래처의 주문이 결국 FAX로 계속 들어와 이중 운영이 무기한화된다
• 「웹화했는데도 인력이 줄지 않는다」는 평가로 이어져 프로젝트가 멈춘다

원인은 목표를 「FAX를 없애는 것」에 둔 데 있습니다.

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

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

3. 이행 후의 모습 ── 입구는 여러 개, 사내 처리는 하나

단계적 이행을 설계하기 전에, 목표로 하는 형태를 먼저 그려 둡니다.

핵심은 접수 채널과 수주 처리를 분리해서 생각하는 것입니다.

[접수 채널]                    [공통 수주 데이터]        [사내 처리]

FAX ──── 담당자가 입력 ──┐
메일 첨부 ── 담당자가 입력 ─┤
CSV 가져오기 ─── 자동 가져오기 ────┼──→ 수주 데이터 ──→ 재고 배정・출하・청구
웹 수주 화면 ── 자동 등록 ───┘      (형식을 통일)

접수 채널이 몇 종류든 그 뒤의 수주 데이터 형식과 처리를 하나로 통합해 두면, 재고, 출하, 청구 등 후속 공정은 공통된 흐름으로 그대로 돌아갑니다.

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

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

기존 판매관리 시스템을 새로 만들 필요는 반드시 있는 것은 아닙니다. 수주 데이터의 입구를 추가할 수 있는지(CSV 가져오기 기능, 데이터베이스 연계, API 등)를 확인할 수 있다면, 지금의 구조를 유지한 채로 진행할 수 있습니다. 이 확인 포인트는 지난 EDI 글의 「사내 시스템과의 연결을 확인한다」에서 정리한 대로입니다.

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

FAX에서 갑자기 웹 화면 입력으로 옮겨가도록 하는 것은 거래처 입장에서 부담이 클 수 있습니다.

발주하는 쪽에서 보면, 웹 화면 입력이란 「자사의 발주 시스템이나 Excel로 만든 주문을 다시 상대방 화면에 입력하는 것」이기 때문입니다. 거래처가 자사 시스템으로 주문 데이터를 만들고 있다면, 그 데이터를 파일 그대로 받아서 가져오는 쪽이 양쪽의 작업이 적게 듭니다.

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

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

1단계라도 주문서를 보면서 수작업으로 입력하는 것에 비하면 입력 시간과 전기(轉記) 오류가 크게 줄어듭니다. 거래처 측의 변화는 「FAX로 보내던 것을 메일 첨부로 바꾸는」 정도로 끝나므로 협조를 얻기 쉬운 것도 장점입니다.

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

CSV는 단순해 보이지만 문자 코드, 줄바꿈, 쉼표와 따옴표 처리 등에서 함정이 많은 형식입니다. 가져오기 처리를 구현할 때의 기술적 주의점은 「CSV 파일 처리 실무 가이드」에 정리했습니다.

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

5. 상품・거래처 마스터 정비를 먼저 진행한다

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

예를 들어 주문서에 예전 상품명이 적혀 있어도 담당자가 「이건 현재 이 상품을 말하는 것」이라고 바꿔 읽어 입력합니다. 단위가 「케이스」로 적혀 있어도 1케이스가 몇 개 들어 있는지 기억해서 환산합니다.

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

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

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

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

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

6. 이중 운영 기간 설계

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

이중 운영 기간 설계란 구체적으로 다음을 정하는 것입니다.

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

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

기한 없는 이중 운영은 그대로 고착화됩니다. 목표에 도달하지 못하더라도 기한이 있으면 「왜 이행이 진행되지 않는가」를 거래처별로 확인하는 행동으로 이어집니다.

6.2. 채널별 건수를 매달 측정한다

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

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

지난 글에서 언급한 도입 후 측정해야 할 지표와 같은 사고방식입니다. 채널별로 나누어 측정함으로써 「어느 거래처에 힘을 쏟으면 효과가 큰지」가 보입니다.

6.3. 운영 규칙을 채널 간에 맞춘다

이중 운영 기간 중 혼란이 생기기 쉬운 경우는 채널에 따라 업무 규칙이 다른 경우입니다.

• 수주 마감 시각은 FAX와 웹이 같은가
• 주문 변경・취소는 어느 채널에서 받는가(웹으로 받은 주문의 변경을 FAX로 받으면 대조 작업이 필요해진다)
• 결품 시 연락 방법은 채널마다 다르지 않은가
• 주문 번호는 채널을 넘나들어 유일한가(중복 등록 검출에 필요)

특히 「웹으로 주문하고 직후에 전화나 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. 상대방의 이점으로 안내한다

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

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

실무적인 배려도 함께하면 효과가 있습니다.

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

또한 「FAX를 ◯월에 폐지합니다」라는 안내를 처음부터 내는 것은 권장하지 않습니다. 이행이 진행되어 남은 거래처가 소수가 된 단계에서 비로소 기한 이야기를 꺼내는 편이 관계를 해치지 않고 넘어갈 수 있습니다.

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

8. 단계적 이행 모델 케이스

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

0단계 「현황 정리」는 지난 글에서 소개한 수발주 방법 목록화를 그대로 활용할 수 있습니다.

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

9. 흔한 걸림돌과 대책

마지막으로 실제 이행에서 발생하기 쉬운 걸림돌을 정리합니다.

정리

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

• 목표는 「FAX 폐지」가 아니라 「사람이 입력하는 주문 건수 감소」에 둔다
• 접수 채널은 여러 개여도 좋지만, 사내 수주 데이터와 처리는 하나로 통합한다
• 갑작스럽게 웹 화면 입력을 요구하지 않고 CSV 가져오기라는 중간 형태를 끼워 넣는다
• 마스터 정비는 처음 이행할 거래처의 범위부터 단계적으로 진행한다
• 이중 운영 기간에는 기한과 목표값을 두고 채널별 건수로 진척을 측정한다
• 거래처는 건수와 협조도로 분류하고 파일럿 1곳으로 틀을 만든 뒤 확대한다

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

수발주의 웹화를 검토하시는 분께

FAX 수주 재검토를 검토하고 있지만 거래처와의 조정, 기존 판매관리 시스템과의 연결, CSV 포맷과 마스터 정비를 어떻게 진행할지 등 어디서부터 손대야 할지 고민되는 경우, 먼저 현재의 채널별 수주 건수 정리부터 시작할 필요가 있습니다.

합동회사 고무라소프트에서는 기존 Windows 업무 앱과 데이터베이스를 활용한 CSV 가져오기・웹 수주 연계의 설계・구현, 그리고 이행 계획 자체를 정리하는 것을 상담해 드립니다.

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

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

저자 프로필

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

Go Komura

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

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