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 reto práctico real 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.

Este artículo está dirigido al personal de gestión de pedidos y a los responsables de sistemas de información de empresas donde los pedidos que llegan por fax o correo electrónico son introducidos manualmente en el sistema de gestión de ventas. Al terminar de leerlo, no se llevará el modo de construir un sistema de pedidos web en sí, sino cómo estructurar un plan de migración: “desde qué cliente, en qué orden y qué medir mientras se migra”. Si desea conocer primero el panorama general del mecanismo, lea antes el artículo anterior sobre el EDI.

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 (Jipdekku, la Fundación de Promoción de la Sociedad de la Información y la Economía de Japón —一般財団法人日本情報経済社会推進協会—, conocida por gestionar el sistema de la Marca de Privacidad y el código empresarial estándar) señala también, en la página del proyecto de código empresarial estándar “Beneficios del EDI y la necesidad de la estandarización”, que “si persisten el procesamiento manual y la atención por fax o teléfono, será necesario dedicar personal a ellos, lo que impide una automatización y mecanización del 100% y no permite obtener plenamente los beneficios de la eficiencia”. Precisamente por eso, el periodo de doble operación no debe dejarse como “algo que ocurre inevitablemente”; 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, y la doble operación se vuelve indefinida
• El proyecto se detiene bajo la valoración de que “se digitalizó la web, pero el personal no se ha reducido”

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

Si se sustituye 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 disminuye considerablemente aunque el 30% restante siga usando el fax.

En lugar de mover todo a la vez, se avanza primero por donde el efecto es mayor. Esta es la base de la migración por etapas.

3. El resultado tras la migración — entradas múltiples, procesamiento interno único

Antes de diseñar la migración por etapas, conviene describir primero la forma a la que se aspira.

El punto clave es separar conceptualmente el canal de recepción del procesamiento de pedidos.

flowchart LR
    accTitle: Migración de los pedidos por fax a la web: canales de entrada y procesamiento interno
    accDescr: Diagrama que muestra cómo los pedidos que llegan por fax, correo electrónico, importación de CSV o la pantalla de pedidos web convergen en un mismo dato de pedido con formato unificado, que alimenta después el procesamiento interno de reserva de stock, envío y facturación
    ORDER["Datos de pedido comunes<br/>(formato unificado)"]
    BACK["Procesamiento interno<br/>reserva de stock, envío, facturación"]
    subgraph CH["Canales de recepción"]
        FAX["Fax"]
        MAIL["Adjunto de correo"]
        CSV["Importación de CSV"]
        WEB["Pantalla de pedidos web"]
    end
    FAX -->|"El responsable lo introduce"| ORDER
    MAIL -->|"El responsable lo introduce"| ORDER
    CSV -->|"Importación automática"| ORDER
    WEB -->|"Registro automático"| ORDER
    ORDER --> BACK

Sin importar cuántos canales de recepción existan, si el formato y el procesamiento de los datos de pedido posteriores se mantienen unificados en uno solo, los procesos siguientes —inventario, envío, facturación— siguen funcionando de forma común.

Por el contrario, si se crean procesos o libros distintos para cada canal, la operación se vuelve más compleja con cada canal añadido, y la carga de la doble operación no deja de crecer.

Incluso los pedidos que llegan por fax deben convertirse, en el momento en que el responsable los introduce, en el mismo dato de pedido que el de los demás canales. Se puede decir que la migración consiste en reducir el volumen que fluye por la fila de “el responsable lo introduce” de este diagrama, e ir aumentando el que fluye por las filas de “importación automática” y “registro automático”.

No es necesariamente imprescindible renovar el sistema de gestión de ventas existente. Basta con comprobar si es posible añadir una entrada de datos de pedido (función de importación de CSV, integración con base de datos, API, etc.) para poder avanzar manteniendo el esquema actual. Este punto de verificación es el mismo que se organizó en “Comprobar la conexión con el sistema interno” del artículo anterior sobre el EDI.

4. La importación de CSV como forma intermedia

Pasar directamente del fax a la entrada por pantalla web puede suponer una carga considerable para el cliente.

Desde el punto de vista de quien hace el pedido, la entrada por pantalla web significa “volver a escribir en la pantalla del proveedor un pedido que ya se generó en el propio sistema de pedidos o en Excel”. Si el cliente ya genera los datos del pedido con su propio sistema, recibir e importar ese archivo tal cual supone menos trabajo para ambas partes.

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

Etapa 1: recibir el CSV como adjunto de correo y que el responsable lo cargue con 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 pedidos web o al EDI

Incluso en la etapa 1, el tiempo de entrada y los errores de transcripción se reducen considerablemente en comparación con la entrada manual mirando el pedido en papel. Otra ventaja es que resulta más fácil obtener la colaboración del cliente, porque el cambio que se le pide es solo “sustituir el envío por fax por un adjunto de correo”.

Al diseñar la importación de CSV, conviene decidir como mínimo los siguientes puntos.

De estos seis puntos, el que en la práctica genera más discusión es el sistema de códigos. Si se pide al cliente que envíe con su propio código de producto o que lo convierta antes al código propio, determina quién mantiene la tabla de conversión. Desde ventas suele oírse que “es más cómodo que el cliente envíe con su propio código”, mientras que desde sistemas se oye que “mantener una tabla de conversión por cada cliente es una carga”.

El punto de equilibrio es que la tabla de conversión la mantenga quien se entera primero de los cambios en los productos. Como la propia empresa es quien primero sabe de las altas y bajas de productos, si la conversión se hace en el lado propio, no hace falta pedir a todos los clientes que “sustituyan la tabla de códigos” cada vez que se da de alta o de baja un producto. El esquema en el que el cliente memoriza el código propio de la empresa es cómodo al principio, pero genera un aviso a tantos clientes como haga falta cada vez que hay una alta o baja. Resolver este ida y vuelta antes de la migración evita tener que volver a explicar más adelante “por qué se diseñó así”.

Otro aspecto que afecta directamente a la operación diaria es cómo devolver los errores. En principio, es más seguro que la importación “se detenga ante cualquier error” (si una sola fila es incorrecta, no se importa nada) que perseguir después un pedido que se cargó parcialmente. Pero esto solo funciona si existe la garantía de que alguien se entera siempre de que el proceso se detuvo. Una configuración mínima sería la siguiente:

• Notificación por correo al equipo interno ── enviar automáticamente un “fallo de importación” a la lista de distribución del equipo de pedidos. En el asunto, el nombre del archivo y del cliente; en el cuerpo, el número de línea del error y la causa (por ejemplo, “el código de producto ABC-123 no existe en el maestro”).
• Historial de importación en el panel de administración ── disponer una pantalla donde se vean de un vistazo los casos correctos, fallidos y pendientes. Aunque se pase por alto el correo, basta con revisar esta pantalla a primera hora de la mañana para darse cuenta.
• Contacto con el cliente ── al principio, no automatizar la respuesta; que el responsable interno revise el contenido antes de contactar. Una vez avanzada la fase de carga por web, se pasa a mostrar el error directamente en la pantalla de carga.

Un diseño del tipo “los errores quedan en el registro, así que revísenlo” no es adecuado para el periodo de doble operación, porque el personal ya está saturado con el procesamiento del fax.

El CSV parece simple, pero es un formato con muchas trampas relacionadas con la codificación de caracteres, los saltos de línea y el tratamiento de comas y comillas. Las consideraciones técnicas al implementar el procesamiento de importación están reunidas en la “Guía práctica de procesamiento 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 códigos que se decidan aquí seguirán siendo la base tanto en los pedidos web posteriores como en el EDI.

5. Preparar antes los maestros de productos y clientes

En los pedidos por fax, las deficiencias del maestro las absorbe el responsable.

Por ejemplo, aunque en el pedido en papel figure un nombre de producto antiguo, el responsable lo interpreta como “esto se refiere a este producto actual” y lo introduce así. Aunque la unidad esté escrita como “caja”, el responsable recuerda cuántas unidades trae cada caja y hace la conversión mentalmente.

Al pasar a la importación de CSV o a los pedidos web, esta interpretación pasa a hacerla la máquina. Además, en la pantalla de pedidos web, el maestro de productos queda expuesto directamente a la vista del cliente.

Por eso, antes de la migración es necesario, como mínimo, preparar lo siguiente:

• Organización de los códigos de producto (limpieza de bajas, unificación de duplicados, tabla de correspondencia entre códigos antiguos y nuevos)
• Unificación de la denominación de los productos (que el nombre sea presentable ante el cliente)
• Unidades y cantidades por embalaje (relación entre unidad suelta, caja y palé, cantidad mínima de pedido)
• Código de cliente y código de lugar de entrega (tratamiento de un cliente con varios lugares de entrega)
• Dónde gestionar el precio aplicado y las condiciones contractuales por cliente

Aquí es importante no intentar perfeccionar todo el maestro antes de empezar. Esperar a eso hace que la migración nunca comience.

Lo realista es preparar primero solo el alcance de productos y lugares de entrega que maneja el primer cliente que migra (el piloto), y ampliar ese alcance cada vez que se suma un nuevo cliente a la migración. El propio trabajo de preparación del maestro se incorpora como una fase más de la migración por etapas.

6. Diseño del periodo de doble operación

La doble operación de fax y web (CSV) se produce inevitablemente durante el periodo de migración. Si se deja sin diseñar, la doble operación se vuelve permanente, y se llega a la situación de “el trabajo aumentó exactamente en la medida en que aumentaron los canales”.

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

6.1. Definir el periodo y los valores objetivo

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

Una doble operación sin plazo tiende a fijarse tal cual, de forma permanente. Aunque no se alcance el objetivo, si existe un plazo, esto lleva a la acción de revisar, cliente por cliente, “por qué no avanza la migración”.

6.2. Medir mensualmente el volumen por canal

El avance de la migración se sigue con cifras, no con impresiones.

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

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

El problema es cómo recopilar esto. Si se decide “contemos cada mes” sin disponer de un mecanismo, el seguimiento se detiene en el primer mes. Lo seguro es añadir un solo campo de medición a los propios datos de pedido.

Si no es posible añadir una columna al sistema de gestión de ventas existente, se deja el registro del proceso de importación y de la pantalla de entrada en una tabla independiente, y se agrega desde ahí. En cualquier caso, la forma de medir se decide antes de iniciar la migración. Dado que el criterio de la decisión de fase (capítulo 8) que se ve más adelante es la proporción por canal, si no se puede obtener esa proporción, no es posible decidir si avanzar a la siguiente fase o detenerse.

6.3. Unificar las reglas operativas entre canales

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

• ¿La hora de cierre de pedidos es la misma para el fax y la web?
• ¿Por qué canal se reciben los cambios o cancelaciones de pedidos? (si se recibe por fax el cambio de un pedido que llegó por web, hace falta un cotejo)
• ¿El método de aviso ante falta de existencias cambia según el canal?
• ¿El número de pedido es único a través de todos los canales? (necesario para detectar registros duplicados)

En particular, el patrón “pedir por web y, justo después, cambiarlo por teléfono o fax” se da inevitablemente. Conviene decidir de antemano por qué canal se reciben los cambios y quién corrige qué datos.

6.4. Incluir también la recepción de fax como objeto de mejora

Durante el periodo de doble operación, el fax sigue existiendo. Si se parte de que va a seguir existiendo, el procesamiento del lado del fax también es objeto de mejora.

• Recibir el fax mediante una multifuncional y convertirlo a PDF, dejando de gestionar papel
• Concentrar los PDF recibidos en una carpeta de pedidos y gestionar su estado (pendiente, introducido, en espera)
• Vincular por número de pedido el original del fax (PDF) ya introducido con los datos de pedido, de modo que se pueda cotejar posteriormente

Pensar que “el fax acabará por desaparecer, así que no hace falta tocarlo” no reduce la carga durante el periodo de doble operación. Hasta que se complete la migración, el procesamiento del fax se trata también como un canal más que converge en los mismos datos de pedido.

7. Cómo involucrar a los clientes

El éxito o el fracaso de la migración por etapas depende más de cómo se aborda a los clientes que de lo que ocurre internamente.

7.1. Clasificar a los clientes

En lugar de tratar a todos los clientes por igual, se los clasifica primero.

Quienes determinan el efecto son A y B. Intentar mover a la fuerza a los clientes de C solo genera costes, por lo que se les puede decir claramente que “también se seguirán aceptando pedidos por fax”.

7.2. Elegir una empresa piloto

En lugar de migrar varias empresas en paralelo desde el principio, primero se establece la operación con una sola. Los criterios de selección son los mismos que en el artículo anterior.

• Volumen de pedidos alto, de modo que el efecto sea fácil de medir
• Predominio de pedidos estandarizados
• Comunicación fluida entre responsables y comprensión de la integración de sistemas

Con el piloto se crea el “molde”: formato de CSV, método de contacto ante errores, tabla de correspondencia del maestro, documentos de aviso, etc. A partir de la segunda empresa, ese molde se reutiliza.

7.3. Explicar la propuesta destacando los beneficios para el cliente

Desde el punto de vista del cliente, cambiar el modo de pedir es una petición motivada por conveniencia propia del proveedor. El aviso debe explicarse no en términos de la propia eficiencia, sino de los beneficios para el cliente.

• La confirmación del pedido llega de inmediato, por lo que ya no hace falta la llamada de “¿les llegó o no?”
• Se reducen los envíos erróneos y las discrepancias de cantidad por errores de lectura
• El cliente puede consultar su propio historial de pedidos, lo que facilita los pedidos repetidos (en el caso del pedido web)
• Desaparecen el trabajo de envío por fax y los reenvíos por errores de transmisión

Junto a esto, también resultan eficaces algunas consideraciones prácticas.

• Reunir el procedimiento de uso en un único manual (que baste con unas pocas pantallas de explicación)
• Indicar con claridad la fecha de inicio y el periodo de uso simultáneo (“a partir de tal mes también se aceptará por web; el fax seguirá disponible por ahora”)
• En las primeras veces, aceptar el pedido tanto si llega por fax como por web, y responder de inmediato a las consultas

Cabe señalar que no se recomienda anunciar desde el principio “el fax se eliminará en tal mes”. Es preferible hablar de un plazo solo cuando la migración ya ha avanzado y quedan pocos clientes pendientes, para no dañar la relación.

Sobre la digitalización de pedidos en pymes, la Agencia de Pymes de Japón presenta iniciativas de estandarización, incluido el EDI común, y sus efectos. Si el gremio del sector o los principales clientes ya se han adaptado a estos estándares, conviene también valorar la opción de ajustarse al estándar en lugar de a un formato propio.

8. Caso modelo de migración por etapas

A continuación se organiza todo lo anterior en un modelo cronológico. Los periodos son solo orientativos y varían según el número de clientes y la estructura interna.

La fase 0, “diagnóstico de la situación actual”, puede resolverse directamente con la tabla de métodos de pedido presentada 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 de Windows a la web?” se organiza un marco de decisión. La digitalización del canal de recepción y la digitalización del sistema interno pueden decidirse por separado.

9. Problemas frecuentes y cómo abordarlos

Por último, se resumen los problemas que suelen surgir en migraciones reales.

Resumen

Digitalizar los pedidos por fax hacia la web no es tanto un trabajo de construir un sistema como un trabajo de diseñar el periodo de migración.

• Fijar el objetivo no en “eliminar el fax”, sino en “reducir el número de pedidos que requieren entrada manual”
• Puede haber varios canales de recepción, pero los datos y el procesamiento internos de pedidos deben unificarse en uno solo
• No exigir de inmediato la entrada por pantalla web; intercalar la importación de CSV como forma intermedia
• Avanzar en la preparación del maestro de forma progresiva, empezando por el alcance del primer cliente que migra
• Establecer un plazo y valores objetivo para el periodo de doble operación, y medir el avance por el volumen de pedidos por canal
• Clasificar a los clientes por volumen y disposición a colaborar, crear el molde con una empresa piloto y ampliar después

Como se organizó en el artículo anterior, el efecto del EDI o del pedido web depende de hasta dónde se puedan hacer llegar los datos recibidos dentro de la operación interna. Diseñar la migración es planificar, en un orden razonable, el aumento de la proporción de pedidos que se incorpora a ese flujo.

Para quienes estén considerando digitalizar sus pedidos

Si está considerando revisar sus pedidos por fax, pero duda por dónde empezar —la coordinación con los clientes, la conexión con el sistema de gestión de ventas existente, cómo avanzar en el formato CSV y la preparación del maestro—, el primer paso necesario es organizar la situación actual del volumen de pedidos por canal.

En KomuraSoft LLC puede consultarnos sobre el diseño e implementación de la integración de importación de CSV y pedidos web aprovechando su aplicación de negocio y su base de datos Windows existentes, así como sobre la organización del propio plan de migración.

Sin dar por hecho una renovación total, también es posible estudiar una configuración que mantenga el esquema actual de gestión de ventas y añada de forma progresiva únicamente los canales de recepción.

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.