Как перевести заказы с факса на веб: параллельная работа и поэтапный переход

В предыдущей статье «Что такое EDI? Как он упрощает обмен заказами между компаниями» мы разобрали механизм, который заменяет ручной повторный ввод заказов, пришедших по факсу или почте, обменом данными между системами.

Эта статья — продолжение. Тема делает шаг от понимания механизма к тому, как именно переходить.

Запрос «хотим перевести приём заказов с факса на веб» почти всегда продолжается так:

«Но часть контрагентов умеет заказывать только по факсу»

«Систему учёта продаж хотим оставить как есть»

«На время переключения приём заказов останавливать нельзя»

То есть практическая задача — не построить систему веб-заказов. Нужно спроектировать период, в котором факс ещё остаётся, а приём постепенно уходит на веб.

Ниже перевод заказов с факса на веб разбирается вокруг четырёх вопросов: как спроектировать период параллельной работы, импорт CSV как промежуточный этап, подготовка справочников товаров и контрагентов и как подключать контрагентов.

Статья рассчитана на сотрудников, которые принимают заказы, и на специалистов ИТ-службы в компаниях, где заказы с факса и почты люди вручную заносят в систему учёта продаж. После чтения вы получите не рецепт самой веб-системы заказов, а способ собрать план перехода: с каких контрагентов начинать, в каком порядке и что измерять по ходу. Если нужна общая картина механизма, сначала прочитайте предыдущую статью про EDI.

1. Сначала — вывод

При планировании перевода заказов с факса на веб важны такие пункты.

• Цель ставить не как «отказаться от факса», а как «сократить число заказов, которые люди вводят вручную»
• Исходить из того, что период параллельной работы факса и веба возникнет обязательно, и заранее задать его длительность и способ измерения
• Каналов приёма может быть несколько, но внутреннюю обработку заказов сводят к одному потоку
• Не требовать сразу ввода через веб-форму — предусмотреть импорт CSV как промежуточный этап
• На экране веб-заказа справочники товаров и контрагентов видны партнёру как есть, поэтому сначала готовят эти справочники
• Не переключать всех контрагентов разом — разделить их по объёму заказов и готовности сотрудничать и переводить по очереди

JIPDEC (Japan Institute for Promotion of Digital Economy and Community; японская организация, известная системой PrivacyMark и ведением стандартных кодов предприятий) на странице стандартных кодов предприятий «Преимущества EDI и необходимость стандартов» пишет: «если остаются ручная обработка и работа с факсом и телефоном, под них по-прежнему нужно держать персонал, стопроцентная автоматизация и механизация невозможны, и эффект от повышения эффективности не проявляется в полной мере». Именно поэтому период параллельной работы нельзя оставлять как «само собой получилось»: предметом проектирования должен стать сам план, как этот период сокращать.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 23, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Почему одномоментный полный переход на веб часто срывается

У перевода заказов с факса на веб есть свойство, которое нельзя решить из удобства внутренней системы. Заказ отправляет контрагент.

Схема «всем контрагентам объявляем: со следующего месяца заказывайте через веб» легко приводит к таким сбоям.

• Контрагенты, которые умеют заказывать только по факсу, перестают быть «исключением» и становятся «помехой плану»
• У каждого контрагента своя ситуация, а срок всем ставят один
• Заказы тех, кто не перешёл, продолжают приходить по факсу, и параллельная работа становится бессрочной
• Проект оценивают как «на веб перешли, а людей не стало меньше», и он останавливается

Причина в том, что цель поставили как «убрать факс».

Если цель заменить на «сократить число заказов, которые люди вводят вручную», план становится реалистичным. Например, если на веб или CSV перейдут только крупные контрагенты, на которых приходится 70% заказов, объём ручного ввода заметно упадёт, даже если оставшиеся 30% останутся на факсе.

Не переводить всё сразу, а идти по очереди, начиная с мест, где эффект наибольший. Это и есть основа поэтапного перехода.

3. Какой вид должен получиться: несколько входов, одна внутренняя обработка

Прежде чем проектировать поэтапный переход, сначала рисуют целевую картину.

Главное — развести канал приёма и обработку заказа.

flowchart LR
    ORDER["Общие данные заказа<br/>(единый формат)"]
    BACK["Внутренняя обработка<br/>резервирование запасов, отгрузка, счета"]
    subgraph CH["Каналы приёма"]
        FAX["Факс"]
        MAIL["Вложение в письме"]
        CSV["Импорт CSV"]
        WEB["Экран веб-заказа"]
    end
    FAX -->|"вводит сотрудник"| ORDER
    MAIL -->|"вводит сотрудник"| ORDER
    CSV -->|"автоимпорт"| ORDER
    WEB -->|"авторегистрация"| ORDER
    ORDER --> BACK

Сколько бы каналов приёма ни было, если дальше формат данных заказа и обработка сведены к одному потоку, последующие процессы — запасы, отгрузка, счета — продолжают работать по общей схеме.

Наоборот, если под каждый канал заводить свою обработку или свой журнал, с каждым новым каналом работа усложняется, а нагрузка от параллельной работы только растёт.

Заказ, пришедший по факсу, после ввода сотрудником должен становиться теми же данными заказа, что и в остальных каналах. Переход в этой схеме — это работа по сокращению потока в строках «вводит сотрудник» и наращиванию потока в строках «автоимпорт» и «авторегистрация».

Полностью менять существующую систему учёта продаж не обязательно. Если удаётся подтвердить, что можно добавить вход для данных заказа (функцию импорта CSV, связку с базой данных, API и т. п.), можно идти дальше, оставив текущую систему. Этот пункт проверки разобран в предыдущей статье про EDI, в разделе «Проверьте подключение к внутренней системе».

4. Импорт CSV как промежуточный этап

Сразу перевести контрагента с факса на ввод в веб-форму для него бывает слишком тяжело.

Со стороны заказчика ввод в веб-форму — это «ещё раз набрать в чужом экране заказ, который уже собран в своей системе заказов или в Excel». Если контрагент и так формирует данные заказа своей системой, принять этот файл как есть и импортировать его значит меньше работы для обеих сторон.

Поэтому как промежуточный этап предусматривают импорт CSV (или Excel).

Этап 1: CSV приходит вложением в письме, сотрудник загружает его через функцию импорта
Этап 2: контрагент загружает CSV с веб-страницы, импорт идёт автоматически
Этап 3: для контрагентов с устоявшимся потоком — экран веб-заказа или EDI

Уже на первом этапе время ввода и число ошибок переноса заметно падают по сравнению с ручным набором по бланку заказа. Со стороны контрагента изменение сводится к «вместо факса отправляем вложение в письме», поэтому согласие получить проще — это тоже плюс.

При проектировании импорта CSV как минимум фиксируют следующее.

Из этих пунктов на практике сильнее всего спорят о системе кодов. От выбора «пусть шлют в своих товарных кодах» или «пусть сначала переведут в наши» зависит, у кого лежит таблица соответствия. От продаж слышно «проще, если контрагент шлёт уже в наших кодах»; от ИТ-службы — «вести таблицу соответствия на каждого контрагента накладно».

Практичный выход такой: таблицу соответствия ведёт та сторона, которая первой узнаёт об изменении номенклатуры. О появлении новой позиции и о снятии с производства первой узнаёт своя компания, поэтому преобразование лучше держать у себя: тогда при каждом изменении номенклатуры не нужно просить всех контрагентов «замените таблицу кодов». Схема «пусть контрагенты запоминают наши коды» на старте кажется лёгкой, но при каждом изменении номенклатуры приходится писать всем, кто в этом участвует. Этот выбор лучше зафиксировать до перехода, чтобы потом не объяснять заново, «почему сделали именно так».

Второй пункт, который сразу сказывается на эксплуатации, — как возвращать ошибки. Импорт по умолчанию лучше останавливать целиком: если хотя бы одна строка некорректна, не импортировать ничего. Это безопаснее, чем потом догонять частично попавшие заказы. Но схема работает только если остановка обязательно доходит до конкретного человека. Минимальный набор такой.

• Письмо внутрь компании — на список рассылки сотрудников, принимающих заказы, автоматически уходит «сбой импорта». В теме — имя файла и имя контрагента, в теле — номера ошибочных строк и причина (например, «кода товара ABC-123 нет в справочнике»).
• История импорта в административном экране — список, где видно успех, сбой и ещё не обработанное. Даже если письмо пропустили, утром достаточно открыть этот экран.
• Сообщение контрагенту — на старте не автоответ, а сотрудник сначала смотрит содержимое и только потом связывается. Когда дойдёте до загрузки с веб-страницы, ошибку показывают сразу на экране загрузки.

Схема «ошибка есть в логе, смотрите сами» в период параллельной работы не подходит. Сотрудники и так заняты обработкой факса.

CSV выглядит просто, но в нём много ловушек с кодировкой, переводами строк, запятыми и кавычками. Технические нюансы реализации импорта собраны в статье «Практическое руководство по обработке файлов CSV».

Импорт CSV — не конечный вариант, а промежуточный этап. Состав полей и система кодов, которые здесь зафиксировали, затем становятся основой и для веб-заказов, и для EDI.

5. Сначала готовят справочники товаров и контрагентов

При приёме заказов по факсу пробелы в справочниках закрывает сотрудник.

Например, даже если в бланке стоит старое название товара, сотрудник понимает «это вот эта текущая позиция» и вводит уже её. Даже если единица указана как «короб», он помнит, сколько штук в коробе, и пересчитывает.

При переходе на импорт CSV или веб-заказы эту подстановку делает машина. Плюс на экране веб-заказа справочник товаров видит сам контрагент.

Поэтому до перехода нужна как минимум такая подготовка:

• Навести порядок в кодах товаров (убрать снятые с производства, объединить дубли, таблица соответствия старых и новых кодов)
• Унифицировать написание названий (можно ли показывать это имя контрагенту)
• Единицы и количество в упаковке (связь штуки / короба / паллеты, минимальное количество заказа)
• Коды контрагентов и коды грузополучателей (как вести несколько адресов доставки у одного контрагента)
• Где хранить цены и договорные условия, которые действуют для конкретного контрагента

Важно не ждать, пока все справочники станут идеальными. Если ждать этого, переход так и не начнётся.

Реалистичный путь — сначала закрыть только товары и грузополучателей первого контрагента (пилота), а диапазон расширять с каждым следующим. Саму подготовку справочников встраивают в фазы поэтапного перехода.

6. Как спроектировать период параллельной работы

Параллельная работа факса и веба (CSV) на время перехода возникнет обязательно. Если это не спроектировать, она станет нормой, и получится «работы прибавилось ровно на столько каналов, сколько добавили».

Спроектировать период параллельной работы — значит конкретно решить следующее.

6.1. Задать срок и целевой показатель

Числом фиксируют, «к какой дате какую долю заказов нужно перевести на автоимпорт». Например: «за шесть месяцев снизить долю заказов по факсу с 70% до 30%».

Параллельная работа без срока так и закрепляется. Даже если цель не достигнута, наличие срока ведёт к действию: у каждого контрагента спрашивают, почему переход не идёт.

6.2. Каждый месяц считать заказы по каналам

Ход перехода смотрят по числам, а не «на глаз».

• Число заказов по каналам (факс, вложение в письме, CSV, веб)
• Число заказов, введённых вручную, и затраченное время
• Число ошибок импорта и их причины
• Число исправлений ввода и двойных регистраций

Это тот же подход, что и показатели, которые стоит измерять после внедрения, из предыдущей статьи. Разложение по каналам показывает, «к какому контрагенту обратиться, чтобы эффект был наибольшим».

Вопрос в том, как эти числа собирать. Если механизма нет, решение «давайте считать каждый месяц» ломается уже в первый месяц. Надёжный способ — добавить в сами данные заказа одно поле для измерения.

Если в существующую систему учёта продаж колонку добавить нельзя, логи импорта и экрана ввода оставляют в отдельной таблице и считают там. В любом случае способ измерения фиксируют до старта перехода. Критерий перехода между фазами в главе 8 — доля заказов по каналам; без этой доли нельзя решить, идти в следующую фазу или остановиться.

6.3. Выровнять правила работы между каналами

Путаница в период параллельной работы чаще всего возникает, когда бизнес-правила различаются по каналам.

• Одинаково ли время отсечки приёма заказов для факса и веба
• В каком канале принимают изменения и отмены (если заказ, принятый через веб, меняют по факсу, нужна сверка)
• Не расходится ли по каналам способ сообщить об отсутствии товара
• Уникален ли номер заказа сквозь каналы (это нужно, чтобы ловить двойную регистрацию)

Особенно паттерн «заказали через веб и сразу изменили по телефону или факсу» возникнет обязательно. Заранее решают, в каком канале принимают изменение и кто правит какие данные.

6.4. Улучшать и сам приём факса

В период параллельной работы факс остаётся. Раз он остаётся, обработка на стороне факса тоже объект улучшения.

• Принимать факс на МФУ и сразу класть в PDF, отказаться от учёта на бумаге
• Собирать полученные PDF в папку заказов и вести статус (не обработан / введён / отложен)
• После ввода связывать оригинал факса (PDF) с данными заказа по номеру заказа, чтобы потом можно было сверить

Мысль «факс всё равно когда-нибудь исчезнет, трогать не будем» нагрузку в период параллельной работы не снижает. До завершения перехода обработку факса ведут как ещё один канал, который тоже попадает в те же данные заказа.

7. Как подключать контрагентов

Успех поэтапного перехода определяется не столько внутренней работой, сколько тем, как вы работаете с контрагентами.

7.1. Классифицировать контрагентов

Не обращаться со всеми одинаково — сначала классифицировать.

Эффект определяют группы A и B. Силой двигать контрагентов группы C — почти одни затраты, поэтому им можно прямо сказать: «мы продолжим принимать и по факсу».

7.2. Выбрать одного пилотного контрагента

Не запускать переход сразу с нескольких компаний параллельно — сначала отработать процесс на одной. Критерии выбора те же, что в предыдущей статье.

• Много заказов, эффект легко измерить
• Много типовых, повторяющихся заказов
• Сотрудникам с обеих сторон легко связаться, есть понимание системной интеграции

На пилоте собирают «схему» — формат CSV, как сообщать об ошибках, таблицу соответствия справочников, текст рассылки — и эту схему повторно используют со второго контрагента.

7.3. Объяснять переход выгодой контрагента

Для контрагента смена способа заказа — просьба в ваших интересах. Поэтому в рассылке говорят не о своей эффективности, а о выгоде партнёра.

• Подтверждение приёма приходит сразу, не нужны звонки «дошло или нет»
• Меньше ошибочных отгрузок и расхождений в количестве из-за неверного прочтения
• Историю заказов можно смотреть самому, повторные заказы проще (в случае веб-заказов)
• Исчезает отправка по факсу и повторная отправка при сбое

Практическая забота тоже работает.

• Свести процедуру к инструкции на одну страницу (объём, который объясняется несколькими экранами)
• Явно назвать дату старта и период совместной работы («с месяца X принимаем и через веб; факс пока можно использовать параллельно»)
• Первые несколько раз принимать заказ и с факса, и с веба и сразу отвечать на вопросы

При этом сразу рассылать «факс отключаем с месяца X» не стоит. Тему срока лучше поднимать, когда переход уже продвинулся и оставшихся контрагентов мало — так меньше риск испортить отношения.

По теме цифровизации обмена заказами у малого и среднего бизнеса Агентство МСП Японии (中小企業庁) рассказывает о стандартизации, включая общий EDI, и о её эффекте. Если отраслевое объединение или ключевые контрагенты уже работают по таким стандартам, стоит рассмотреть и переход на стандарт вместо собственного формата.

8. Типовой сценарий поэтапного перехода

Сведём сказанное в хронологическую модель. Сроки — только пример и меняются в зависимости от числа контрагентов и внутренней организации.

«Текущее состояние» фазы 0 можно собрать тем же перечнем способов обмена заказами, что в предыдущей статье.

Если отдельно неясно, стоит ли переносить само управление заказами в веб-систему или оставить его настольным приложением, рамка решения разобрана в «Стоит ли переносить Windows-приложение в веб». Перевод канала приёма на веб и перевод внутренней системы на веб можно решать независимо.

9. Где обычно спотыкаются и что делать

В конце — сбои, которые часто возникают при реальном переходе.

Итоги

Перевод заказов с факса на веб — это не столько создание системы, сколько проектирование периода перехода.

• Цель — не «отказаться от факса», а «сократить число заказов, которые люди вводят вручную»
• Каналов приёма может быть несколько, но внутренние данные заказа и обработку сводят к одному потоку
• Не требовать сразу ввода через веб-форму — вставить импорт CSV как промежуточный этап
• Справочники готовят поэтапно, начиная с диапазона первого контрагента
• Для периода параллельной работы задают срок и целевой показатель и смотрят ход по числу заказов в каналах
• Контрагентов делят по объёму и готовности сотрудничать, схему отрабатывают на одном пилоте и затем расширяют

Как уже было в предыдущей статье, эффект EDI или веб-заказов определяется тем, насколько далеко полученные данные доходят по внутренней работе. Спроектировать переход — значит спланировать, как в посильном порядке наращивать долю заказов, которые попадают в этот поток.

Если вы рассматриваете перевод обмена заказами на веб

Если пересмотр приёма заказов с факса уже обсуждается, но неясно, с чего начать — согласование с контрагентами, связка с существующей системой учёта продаж, формат CSV и подготовка справочников, — начинать нужно с того, чтобы сначала свести текущее число заказов по каналам.

В KomuraSoft LLC (合同会社小村ソフト) можно обсудить проектирование и реализацию импорта CSV и связки с веб-заказами на базе существующих Windows-приложений и баз данных, а также саму проработку плана перехода.

Полная замена системы не обязательна: можно рассмотреть и схему, в которой текущий учёт продаж остаётся, а каналы приёма добавляют поэтапно.

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.