Lo que hace realmente un catálogo punchout
Una sesión punchout se desarrolla en cuatro pasos. Cada uno cruza la frontera entre los sistemas de dos empresas.
- El comprador inicia el punchout: su sistema de compras envía una solicitud que identifica al comprador y a su organización, de modo que el sitio del proveedor se abre sabiendo quién está comprando
- Los precios se ajustan por cuenta: la tienda muestra los precios contratados y la disponibilidad actual de ese comprador, no un catálogo público
- El carrito se devuelve como una solicitud de pedido: el comprador transfiere el carrito de vuelta a su sistema de compras en lugar de finalizar la compra en el sitio del proveedor
- La aprobación y el pedido se realizan del lado del comprador: la solicitud sigue la cadena de aprobación interna del comprador y luego llega como una orden de compra
El pedido nunca se realiza en la tienda del proveedor. Esa es la parte que a los proveedores les resulta contraintuitiva, y es exactamente la razón por la que el equipo de compras del comprador insiste en ello.
¿Por qué los compradores corporativos insisten en el punchout?
El software de compras existe para hacer cumplir las políticas. El gasto se clasifica según los presupuestos, las aprobaciones se dirigen según el valor y cada compromiso queda registrado en un lugar auditable. Un comprador que abandona ese sistema para realizar un pedido en el sitio de un proveedor se salta todas estas normas.
Las grandes organizaciones responden exigiendo que las compras se realicen dentro del sistema de compras. Comprar en cualquier otro lugar se convierte en gasto no autorizado (maverick spend), algo que los equipos de compras tienen el objetivo de reducir. En ese punto, la tienda web del proveedor no compite con otras tiendas web. Compite con la propia política del comprador, y pierde.
El punchout resuelve el conflicto en lugar de luchar contra él. El proveedor mantiene el catálogo, la lógica de precios y la experiencia de producto. El comprador mantiene la cadena de aprobación y la pista de auditoría. Ninguna de las partes renuncia a lo que no puede permitirse perder.
¿Qué pierden los proveedores sin un catálogo punchout?
Un proveedor sin punchout no solo obtiene un canal más lento. Queda excluido de cuentas que, de otro modo, comprarían. La pérdida se manifiesta de forma clara:
- Exclusión de la lista de proveedores aprobados: los equipos de compras seleccionan a los proveedores a los que su sistema puede acceder, y un proveedor al que no se puede acceder mediante punchout es descartado antes de cualquier conversación comercial
- Pedidos que se convierten en carga administrativa: sin punchout, las grandes cuentas envían órdenes de compra por correo electrónico o EDI, y alguien debe volver a introducirlas manualmente en el ERP
- Disputas de precios en la facturación: cuando el comprador realiza un pedido a partir de una hoja de cálculo o un catálogo en PDF, el precio esperado y el facturado no coinciden, y el departamento financiero debe absorber la diferencia
- Sin visibilidad de la cuenta: los pedidos llegan sin el historial de navegación, las cotizaciones previas o el interés por productos que capturaría una tienda conectada
Lo que el punchout exige de sus sistemas
El punchout parece una función de comercio electrónico, pero se comporta como un requisito de integración. Cuatro condiciones deben cumplirse en el momento en que el comprador está navegando.
- Precios específicos por cuenta bajo demanda: el precio contratado para ese comprador, resuelto en tiempo real desde el ERP en lugar de servirse desde una tabla sincronizada que queda obsoleta
- Disponibilidad real: stock que tiene en cuenta las asignaciones y las recepciones entrantes, ya que un carrito de punchout que falla en la entrega daña la relación con la cuenta mucho más que un sitio lento
- Gestión correcta de la identidad: la solicitud de punchout incluye credenciales que deben asignarse a la cuenta y al contrato correctos en sus sistemas, en cada ocasión
- Los formatos de documento adecuados: la mayoría de las plataformas de compras utilizan cXML, algunas usan OCI, y tanto la solicitud como el pedido deben ser legibles para ambas partes
Solo el cuarto se refiere realmente al punchout como estándar, y se sitúa junto a la integración EDI que la mayoría de los proveedores ya utilizan para sus cuentas más grandes. Los tres primeros son problemas de integración comunes que el punchout hace visibles. Un comprador que utiliza su propio sistema de compras no tiene paciencia para una página que tarda seis segundos en mostrar los precios.
Cómo una plataforma de integración gestiona un catálogo punchout
Los proveedores acceden al punchout de tres formas. Una red de compras o un portal de proveedores puede alojar el catálogo por usted, lo cual funciona y cobra por transacción, aunque mantiene la relación con el comprador a un paso de distancia. Algunas plataformas de comercio electrónico ofrecen módulos de punchout que gestionan el protocolo, pero aún requieren conexión con el ERP que contiene los precios de contrato. Desarrollarlo directamente para el sistema de compras de cada comprador es posible, pero se multiplica con cada nueva cuenta importante.
Una plataforma de integración como servicio (iPaaS) conecta la tienda con los sistemas que contienen la información. En la iPaaS de Alumio, ese trabajo adopta cuatro formas:
- Precios calculados mientras el comprador espera: un proxy en tiempo real verifica los precios de contrato y el stock en el ERP mientras el comprador navega, de modo que la cifra en pantalla es la misma que figura en el ERP
- Formatos traducidos en ambos sentidos: un transformador de datos convierte los documentos cXML u OCI al formato que espera el ERP y viceversa, para que los estándares de compras no condicionen el diseño de su gestión interna
- Retenidos cuando un sistema es lento: un almacenamiento integrado mantiene los datos de referencia listos y pone en cola los pedidos devueltos, para que un ERP con mucha carga no interrumpa la sesión activa del comprador
- Trazables por sesión: registros detallados que anotan qué comprador vio qué precio y cuándo, lo cual permite resolver una disputa de facturación sin necesidad de investigación
Esos flujos se configuran en lugar de crearse manualmente para cada comprador, con el transformador de código disponible cuando la configuración no puede expresar una regla y se prefiere escribir código. Leeuwerik Plaat, un proveedor holandés B2B de materiales en láminas, vende con precios de contrato específicos para cada cliente. Alumio transfiere sus productos, stock y precios por cliente en tiempo real entre el ERP Kerridge y Adobe Commerce. Los compradores realizan pedidos las 24 horas del día según el precio estipulado en su contrato.
El valor de un catálogo punchout para un proveedor
El punchout rara vez se financia por sus propios méritos. Se financia cuando una cuenta importante lo solicita, y la respuesta determina si esa cuenta permanece o no.
Los proveedores que lo tratan como una infraestructura en lugar de como una implementación única terminan en una mejor posición. Al utilizar una plataforma de integración, cada nuevo comprador corporativo se conecta a un patrón que ya existe. Los equipos de compras dejan de buscar alternativas y los precios que recibe el comprador son los que el departamento financiero espera facturar.
Lo que la empresa obtiene a cambio es acceso a cuentas que antes eran inalcanzables, pedidos que llegan estructurados en lugar de como archivos adjuntos en correos electrónicos, y un canal que escala junto con el equipo de ventas en lugar de hacerlo con la acumulación de integraciones pendientes.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
