Как перевести приём заказов по факсу в веб ── проектирование периода двойной эксплуатации и практика поэтапного перехода

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

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

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

«Но у некоторых контрагентов есть только факс»

«Систему управления продажами хотим оставить как есть»

«Мы не можем допустить остановки приёма заказов на время перехода»

Иными словами, реальная задача — не построить систему веб-заказов. Это проектирование периода, в течение которого приём постепенно переходит в веб, пока факс ещё используется.

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

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

Ключевые моменты при планировании перевода заказов по факсу в веб:

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

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

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

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

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

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

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

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

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

3. Как выглядит результат перехода ── несколько точек входа, единая внутренняя обработка

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

Ключевая мысль — рассматривать канал приёма и обработку заказов раздельно.

[Каналы приёма]                  [Единые данные заказа]        [Внутренняя обработка]

Факс ──── вводит сотрудник ──┐
Вложение в письме ── вводит сотрудник ─┤
Импорт CSV ─── автоматический импорт ────┼──→ Данные заказа ──→ Резервирование склада, отгрузка, выставление счёта
Экран веб-заказа ── автоматическая регистрация ───┘  (единый формат)

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

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

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

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

4. Импорт CSV как промежуточная форма

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому перед переходом необходимо провести как минимум следующую подготовку:

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

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

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

6. Проектирование периода двойной эксплуатации

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

Проектирование периода двойной эксплуатации конкретно означает решение следующих вопросов.

6.1. Установите срок и целевое значение

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

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

6.2. Ежемесячно измеряйте объёмы по каналам

Прогресс перехода нужно отслеживать по числам, а не на глаз.

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

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

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 и подготовкой справочников, — начать нужно с того, чтобы сначала упорядочить текущее количество заказов по каналам.

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

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

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

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

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

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

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

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

Об авторе

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

Го Комура

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

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