Cómo trasladar los pedidos por fax a la web ── diseño del periodo de doble operación y migración por etapas

En el artículo anterior, “¿Qué es el EDI? Cómo facilita el intercambio de pedidos entre empresas”, repasamos el mecanismo que sustituye la reintroducción manual de pedidos recibidos por fax o correo electrónico por un intercambio de datos entre sistemas.

Este artículo es su continuación. El tema avanza un paso más allá de “entender el mecanismo”, hacia cómo migrar realmente.

Las consultas del tipo “queremos trasladar los pedidos por fax a la web” suelen continuar así:

“Pero algunos de nuestros clientes solo pueden usar el fax”

“Queremos seguir usando el sistema de gestión de ventas tal como está”

“No podemos permitirnos que los pedidos se detengan durante el cambio”

Dicho de otro modo, el verdadero reto práctico no es construir un sistema de pedidos web. Es diseñar el periodo durante el cual se migra gradualmente hacia la web mientras el fax sigue en uso.

Este artículo organiza el traslado de los pedidos por fax a la web en torno a cuatro ejes: el diseño del periodo de doble operación, la importación de CSV como forma intermedia, la preparación de los maestros de productos y clientes, y cómo involucrar a los clientes.

1. La conclusión, primero

Los puntos clave al planificar el traslado de los pedidos por fax a la web son los siguientes:

• Fijar el objetivo no en “eliminar el fax”, sino en “reducir el número de pedidos que requieren entrada manual”
• Partir de la base de que se producirá inevitablemente un periodo de doble operación de fax y web, y diseñar de antemano su duración y forma de medición
• Puede haber varios canales de recepción, pero el procesamiento interno de pedidos debe unificarse en un único flujo
• No exigir de inmediato la entrada mediante pantalla web, sino disponer la importación de CSV como forma intermedia
• Como la pantalla de pedidos web expone directamente los maestros de productos y clientes, preparar antes estos maestros
• No cambiar a todos los clientes a la vez, sino clasificarlos según el volumen de pedidos y su disposición a colaborar, y migrarlos en orden

JIPDEC también señala que, mientras persistan procesos manuales como el fax o el teléfono, seguirá siendo necesario el personal para atenderlos, lo que dificulta obtener plenamente los beneficios de la eficiencia. Precisamente por eso, el periodo de doble operación no debe dejarse como “algo que ocurre inevitablemente”, sino que el propio plan para acortarlo debe convertirse en objeto de diseño.

2. Por qué el paso inmediato y total a la web tiende a fracasar

El traslado de los pedidos por fax a la web tiene una particularidad que no puede decidirse solo con criterios internos del sistema: quien envía el pedido es el cliente.

Anunciar a todos los clientes por igual “a partir del próximo mes, pidan por la web” suele conducir a los siguientes fracasos:

• Los clientes que solo pueden pedir por fax dejan de ser una “excepción” y se convierten en un “obstáculo para el plan”
• Cada cliente tiene circunstancias distintas, pero se les impone el mismo plazo a todos
• Los pedidos de los clientes que no migran siguen llegando por fax, con lo que la doble operación se prolonga indefinidamente
• El proyecto se valora como “pasamos a la web, pero el personal no se redujo”, y se estanca

La causa está en haber fijado el objetivo en “eliminar el fax”.

Al sustituir el objetivo por “reducir el número de pedidos que requieren entrada manual”, el plan se vuelve realista. Por ejemplo, si solo los clientes principales, que representan el 70 % de los pedidos, migran a la web o al CSV, el trabajo de entrada se reduce considerablemente aunque el 30 % restante siga en fax.

En lugar de mover todo a la vez, se avanza primero donde el impacto es mayor. Ese es el principio básico de una migración por etapas.

3. Cómo queda tras la migración ── varias entradas, un único procesamiento interno

Antes de diseñar la migración por etapas, conviene primero dibujar la forma objetivo.

El punto clave es pensar por separado el canal de recepción y el procesamiento de pedidos.

[Canales de recepción]             [Datos de pedido comunes]      [Procesamiento interno]

Fax ──── introducido por un empleado ──┐
Adjunto de correo ── introducido por un empleado ─┤
Importación CSV ─── importación automática ────┼──→ Datos de pedido ──→ Asignación de stock, envío, facturación
Pantalla de pedido web ── registro automático ───┘  (formato unificado)

Sea cual sea el número de canales de recepción, mientras el formato y el procesamiento de los datos de pedido aguas abajo estén unificados en un único flujo, los procesos posteriores —stock, envío, facturación— siguen funcionando de forma común.

Por el contrario, si se crea un procesamiento o un registro distinto para cada canal, el trabajo se complica con cada canal añadido, y la carga de la doble operación no deja de crecer.

Incluso un pedido recibido por fax, una vez introducido por un empleado, debe convertirse en los mismos datos de pedido que los de los demás canales. Puede decirse que la migración consiste en reducir, en este esquema, el volumen que fluye hacia la fila “introducido por un empleado”, a la vez que se aumenta el que fluye hacia las filas de “importación automática” y “registro automático”.

No es necesariamente imprescindible renovar por completo el sistema de gestión de ventas existente. Mientras se pueda confirmar si es posible añadir un punto de entrada para los datos de pedido (una función de importación de CSV, integración con base de datos, una API, etc.), se puede avanzar manteniendo el sistema actual. Este punto de verificación es exactamente el que tratamos en “verificar la conexión con el sistema interno” del artículo anterior sobre EDI.

4. La importación de CSV como forma intermedia

Pedir a un cliente que pase directamente del fax a la entrada mediante pantalla web puede suponerle una carga considerable.

Desde el punto de vista de quien realiza el pedido, la entrada mediante pantalla web significa “volver a escribir, en la pantalla de la otra parte, un pedido ya creado en su propio sistema de pedidos o en Excel”. Si el cliente ya genera los datos del pedido a través de su propio sistema, recibir esos datos tal cual en forma de archivo e importarlos supone menos trabajo para ambas partes.

Por eso, como forma intermedia, se dispone la importación de CSV (o Excel).

Etapa 1: recibir el CSV como adjunto de correo, y que un empleado lo cargue mediante la función de importación
Etapa 2: el cliente sube el CSV desde una página web, y se importa automáticamente
Etapa 3: los clientes ya estandarizados pasan a la pantalla de pedido web o al EDI

Ya en la etapa 1, el tiempo de entrada y los errores de transcripción se reducen notablemente en comparación con la entrada manual mirando el formulario de pedido en papel. Otra ventaja es que resulta más fácil obtener la colaboración, ya que el cambio del lado del cliente se limita a “sustituir lo que se enviaba por fax por un adjunto de correo”.

Al diseñar la importación de CSV, hay que decidir como mínimo los siguientes elementos.

El CSV parece sencillo, pero es un formato con bastantes trampas en cuanto a la codificación de caracteres, los saltos de línea y el tratamiento de comas y comillas. Los aspectos técnicos a tener en cuenta al implementar el procesamiento de importación se resumen en nuestra “Guía práctica para el manejo de archivos CSV”.

Cabe señalar que la importación de CSV no es la forma final, sino una forma intermedia. La definición de campos y el sistema de codificación decididos aquí se convertirán directamente en la base de los futuros pedidos web o EDI.

5. Preparar antes los maestros de productos y clientes

En los pedidos por fax, son los empleados quienes absorben las carencias de los maestros.

Por ejemplo, aunque en el formulario de pedido aparezca un nombre de producto antiguo, el empleado interpreta que “se refiere a este producto actual” y lo introduce en consecuencia. Aunque la unidad esté escrita como “caja”, el empleado recuerda cuántas piezas contiene una caja y hace la conversión por su cuenta.

Al pasar a la importación de CSV o al pedido web, esta interpretación debe realizarla una máquina. Además, en la pantalla de pedido web, el maestro de productos queda expuesto directamente ante el cliente.

Por ello, antes de la migración es necesario realizar como mínimo la siguiente preparación:

• Depuración de los códigos de producto (gestión de artículos descatalogados, unificación de duplicados, tabla de correspondencia entre códigos antiguos y nuevos)
• Unificación de la denominación de los productos (¿son nombres presentables ante los clientes?)
• Unidades y cantidades por envase (relación entre unidad suelta, caja y palet, cantidad mínima de pedido)
• Códigos de cliente y códigos de destino de entrega (cómo tratar los casos en que un cliente tiene varios destinos de entrega)
• Dónde se gestionan los precios aplicables y las condiciones contractuales de cada cliente

Lo importante aquí es no intentar perfeccionar todos los maestros antes de empezar. Esperar a eso significa que la migración nunca comenzará.

El enfoque realista es preparar primero solo el ámbito de productos y destinos de entrega del primer cliente que migre (el piloto), y ampliar ese ámbito con cada nuevo cliente que se sume a la migración. Incorpore el propio trabajo de preparación de los maestros a las fases de la migración por etapas.

6. Diseñar el periodo de doble operación

La doble operación de fax y web (CSV) se producirá inevitablemente durante el periodo de migración. Si se deja sin diseñar, la doble operación se normaliza, y se acaba en una situación en la que “el trabajo ha aumentado exactamente en la medida de los canales añadidos”.

Diseñar el periodo de doble operación significa, en concreto, decidir lo siguiente.

6.1 Fijar una duración y un valor objetivo

Decidir numéricamente “para cuándo, qué porcentaje de los pedidos debe pasar a la importación automática”. Por ejemplo, en una forma como “reducir la proporción de pedidos por fax del 70 % al 30 % en seis meses”.

Una doble operación sin plazo se acaba fijando tal cual. Aunque no se alcance el objetivo, tener un plazo impulsa a comprobar, cliente por cliente, “por qué no avanza la migración”.

6.2 Medir mensualmente los volúmenes por canal

El avance de la migración debe seguirse con cifras, no por sensación.

• Número de pedidos por canal (fax, adjunto de correo, CSV, web)
• Número de pedidos introducidos manualmente y tiempo empleado
• Número de errores de importación y sus causas
• Número de correcciones de entrada y registros duplicados

Es el mismo enfoque que los indicadores a medir tras la implantación mencionados en el artículo anterior. Medir por separado según el canal permite ver “en qué cliente conviene incidir para lograr el mayor impacto”.

6.3 Alinear las reglas operativas entre canales

La confusión durante el periodo de doble operación tiende a surgir cuando las reglas de negocio difieren según el canal.

• ¿Es la misma la hora límite de cierre de pedidos para el fax y la web?
• ¿Por qué canal se reciben los cambios y cancelaciones de pedidos? (Si un pedido recibido por web se modifica por fax, será necesaria una conciliación.)
• ¿El método de aviso ante falta de existencias varía según el canal?
• ¿Es único el número de pedido a través de todos los canales? (Necesario para detectar registros duplicados.)

En particular, el patrón “pedir por la web y, justo después, modificarlo por teléfono o fax” se dará inevitablemente. Decida de antemano por qué canal se reciben los cambios y quién es responsable de corregir qué datos.

6.4 Convertir también la forma de recibir el fax en objeto de mejora

Durante el periodo de doble operación, el fax seguirá existiendo. Dado que se parte de la base de que permanecerá, el procesamiento del lado del fax también es objeto de mejora.

• Recibir el fax mediante una multifunción y convertirlo en PDF, dejando de gestionar papel
• Reunir los PDF recibidos en una carpeta de pedidos y gestionar el estado de procesamiento (sin procesar, introducido, pendiente)
• Vincular el original del fax (PDF) tras la entrada con los datos del pedido mediante el número de pedido, para poder cotejarlos más adelante

Pensar que “el fax acabará desapareciendo, así que no vale la pena tocarlo” no reduce la carga durante el periodo de doble operación. Hasta que se complete la migración, trate el procesamiento del fax como un canal más que converge en los mismos datos de pedido.

7. Cómo involucrar a los clientes

El éxito de la migración por etapas depende más de cómo se aborda a los clientes que del trabajo interno.

7.1 Clasificar a los clientes

No tratar a todos los clientes por igual: clasificarlos primero.

El impacto lo determinan A y B. Intentar forzar a los clientes de la categoría C a migrar solo genera costes, así que se les puede decir con claridad: “seguiremos aceptando también el fax”.

7.2 Elegir un único cliente piloto

En lugar de migrar varios clientes en paralelo desde el principio, conviene establecer primero la operativa con un solo cliente. Los criterios de selección son los mismos que en el artículo anterior:

• Alto volumen de operaciones, lo que facilita medir el impacto
• Predominio de pedidos estandarizados
• Comunicación fluida entre los empleados de ambas partes y comprensión de la integración de sistemas

Con el piloto, construya la “plantilla” —formato CSV, forma de comunicar los errores, tabla de correspondencia de maestros, documentos de guía— y reutilice esa plantilla a partir del segundo cliente.

7.3 Plantear la propuesta según el beneficio de la otra parte

Desde el punto de vista del cliente, un cambio en la forma de pedir es una petición motivada por la conveniencia de la propia empresa. Por eso hay que explicarlo en función del beneficio del cliente, no de la propia eficiencia.

• La confirmación del pedido se recibe de inmediato, eliminando la necesidad de llamar para comprobar “si ha llegado”
• Se reducen los envíos erróneos y los errores de cantidad causados por lecturas equivocadas
• Puede consultar su propio historial de pedidos, lo que facilita los pedidos repetidos (en el caso del pedido web)
• Ya no hace falta la tarea de envío por fax ni el reenvío en caso de errores de transmisión

La atención práctica también da resultado.

• Resumir el procedimiento de uso en un manual de una sola página (apuntar a un alcance que se explique con unas pocas pantallas)
• Indicar claramente la fecha de inicio y el periodo de convivencia (“a partir del mes X también aceptaremos pedidos por la web; el fax seguirá siendo utilizable en paralelo por ahora”)
• En las primeras ocasiones, aceptar los pedidos lleguen por fax o por web, y responder de inmediato a las consultas

Además, no se recomienda emitir desde el principio un aviso del tipo “el fax se eliminará en el mes X”. Es mejor plantear la cuestión del plazo solo cuando la migración ya haya avanzado y los clientes restantes se hayan reducido a unos pocos, para no dañar la relación.

En cuanto a la digitalización del intercambio de pedidos en las pequeñas y medianas empresas, la Agencia japonesa de pymes presenta iniciativas de estandarización, incluido un EDI común, y sus beneficios. Si su asociación sectorial o sus principales clientes ya se ajustan a estos estándares, también vale la pena considerar la opción de alinearse con un estándar en lugar de con un formato propio.

8. Un caso modelo de migración por etapas

Organicemos todo lo anterior en un modelo cronológico. Estos plazos son solo un ejemplo y variarán según el número de clientes y la organización interna.

El “diagnóstico de la situación actual” de la fase 0 puede reutilizar directamente el inventario de métodos de pedido presentado en el artículo anterior.

Además, si duda entre trasladar la propia gestión de pedidos a un sistema web o mantenerla como aplicación de escritorio, en “¿Conviene trasladar una aplicación Windows a la web?” se expone un marco de decisión. Trasladar el canal de recepción a la web y trasladar el sistema interno a la web son decisiones que pueden tomarse de forma independiente.

9. Escollos habituales y medidas

Por último, resumimos los escollos que suelen darse en migraciones reales.

Resumen

Trasladar los pedidos por fax a la web es menos un trabajo de construcción de un sistema que un trabajo de diseño del periodo de migración.

• Fijar el objetivo en “reducir el número de pedidos que requieren entrada manual”, no en “eliminar el fax”
• Los canales de recepción pueden ser varios, pero los datos y el procesamiento internos de los pedidos deben unificarse en un único flujo
• No exigir de inmediato la entrada mediante pantalla web, sino insertar la importación de CSV como forma intermedia
• Avanzar en la preparación de los maestros de forma progresiva, empezando por el ámbito del primer cliente que migre
• Establecer un plazo y un valor objetivo para el periodo de doble operación, y medir el avance con los volúmenes por canal
• Clasificar a los clientes según el volumen y la disposición a colaborar, construir la plantilla con un único piloto y luego ampliar

Tal como se expuso en el artículo anterior, el beneficio del EDI o del pedido web se determina por hasta dónde pueden fluir los datos recibidos dentro de los procesos internos. Diseñar la migración es planificar, en un orden razonable, cómo aumentar la proporción de pedidos que se suman a ese flujo.

Para quienes estén considerando trasladar el intercambio de pedidos a la web

Si está considerando replantear los pedidos por fax pero no sabe por dónde empezar —coordinación con clientes, conexión con el sistema de gestión de ventas existente, cómo avanzar en el formato CSV y la preparación de maestros—, es necesario comenzar organizando primero el número actual de pedidos por canal.

KomuraSoft LLC (合同会社小村ソフト) puede asesorarle en el diseño y la implementación de la importación de CSV y la integración con pedidos web aprovechando sus aplicaciones de negocio y bases de datos Windows existentes, además de en la organización del propio plan de migración.

Sin partir necesariamente de una renovación completa, también se puede estudiar una configuración que mantenga el sistema de gestión de ventas actual mientras se añaden canales de recepción de forma progresiva.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.