Hay un momento bastante reconocible en muchos negocios digitales.
La operación empieza a tensionarse. Aumentan los pedidos, aparecen más incidencias, atención al cliente necesita más tiempo para resolverlas, las tiendas empiezan a asumir tareas que inicialmente no estaban previstas y determinadas gestiones terminan resolviéndose por correo, teléfono o Excel.
Es entonces cuando lo más fácil es pensar que la tecnología se nos ha quedado pequeña. Que necesitamos cambiar de plataforma, o que necesitamos un OMS, o que el ERP ya no soporta el negocio. También es usual que pensemos que hay que automatizar cosas, incluso que necesitamos más personas.
Y, en ocasiones, todo eso es cierto. El problema es saber cuánto hay de verdad y cuánto de intuición, o de «yo creo que…».
Pensemos en un retailer especializado en videojuegos con más de 200 tiendas y un ecommerce que factura más de 70 millones de €. Sobre el papel, el modelo puede parecer relativamente sencillo: compras un producto y eliges recibirlo en casa o recogerlo en una tienda.
Sin embargo, detrás de todo eso puede haber bastantes más complicaciones.
Hay producto disponible directamente en tienda y producto que tiene que viajar desde un almacén. Hay reservas, preventas y lanzamientos con picos de demanda muy concentrados. Imaginemos la preventa de la futura Playstation 6. El producto nuevo puede convivir con el producto usado. Hay recogidas, devoluciones, cambios, incidencias, promociones, fidelización y atención al cliente. Y cada una de esas casuísticas puede cruzarse además con distintos stocks, ubicaciones y sistemas.
La complejidad se va acumulando.
Primero incorporas una nueva opción de entrega. Después una excepción para determinados productos. Más tarde una casuística especial para tiendas. Luego una solución temporal para resolver algo que el sistema todavía no contempla.
Y aquello que nació como una excepción termina convirtiéndose en una parte habitual de la operación.
Un lanzamiento importante permite verlo bastante bien.
Semanas antes de que el producto esté disponible, empiezas a aceptar preventas. El cliente puede querer recibirlo en casa o recogerlo en una tienda concreta. Comercialmente, la experiencia parece habitual: eliges, reservas y esperas al día de lanzamiento.
Pero la realidad operativa es un enjambre de flujos.
Estás vendiendo un producto que todavía no tienes disponible para entregar y sobre el que probablemente trabajas con una previsión de unidades. Tienes que decidir cuánto stock comprometes, cómo lo distribuyes entre ecommerce y tiendas, qué ocurre si la demanda de una ubicación supera la asignación prevista y qué prioridad tienen las unidades cuando se acerca la fecha de lanzamiento.
Imaginemos que una tienda tiene cincuenta reservas y recibe cuarenta y siete unidades. El problema ya no es simplemente de stock. Hay tres clientes a los que alguien tendrá que dar una respuesta. Quizá puedan recibir producto desde otra tienda. Quizá exista stock en el almacén central. Quizá haya que reasignar unidades inicialmente destinadas a otro canal. Quizá el sistema permita hacerlo automáticamente. Quizá no.
Y alrededor de esas tres unidades empiezan a aparecer personas. Alguien comprueba la disponibilidad. Otro equipo revisa las asignaciones. La tienda necesita saber qué decir al cliente. Atención al cliente puede recibir una consulta. Logística tiene que valorar si existe margen para mover el producto antes de la fecha comprometida. Si hay un cambio, alguien tendrá además que asegurarse de que la reserva, el stock y la información que ve el cliente siguen diciendo lo mismo.
Ahora multipliquemos esa situación por decenas de tiendas y por un lanzamiento con miles de reservas concentradas en pocos días.
Eso es lo que me interesa analizar. No si el sistema es capaz de registrar una preventa. Cualquier plataforma de ecommerce de mercado común puede hacer esto de caja. Lo que me interesa saber es qué ocurre cuando la preventa no sigue exactamente el recorrido que habíamos previsto. El happy path que dicen los informáticos.
Cuando todo sale bien, muchas operaciones digitales son razonablemente eficientes. El pedido entra, el stock se asigna, se prepara, se entrega y se factura. El verdadero coste aparece cuando algo se desvía.
No hay stock donde esperábamos. La asignación prevista no coincide con la demanda real. El cliente quiere cambiar la tienda de recogida. Una reserva no se recoge y esa unidad podría estar siendo demandada por otro cliente. Un producto llega tarde. Una unidad está dañada.
O simplemente necesitamos tomar una decisión que el flujo estándar nunca contempló. Entonces aparece la intervención humana.
Alguien consulta un sistema. Después otro. Envía un correo. Llama a una tienda. Modifica manualmente un dato. Customer service vuelve a contactar con el cliente. Finanzas puede tener que conciliar posteriormente alguna parte de la operación.
Una excepción aislada no es especialmente preocupante. Miles sí.
La eficiencia de una operación digital no se entiende estudiando únicamente cómo procesa los pedidos que salen bien. Hay que estudiar cuánto cuesta gestionar los que se salen del flujo previsto.
Ese coste no suele estar identificado en un dashboard. Está repartido entre departamentos. Visto de forma separada, cada equipo puede estar haciendo perfectamente su trabajo. El problema aparece cuando reconstruyes la operación completa.
Es frecuente descubrir entonces que una incidencia aparentemente tecnológica tiene detrás otra cosa.
A veces es un proceso que nunca se rediseñó cuando cambió el modelo de negocio.
A veces hemos ido añadiendo excepciones durante años hasta construir una operativa que nadie diseñó realmente de principio a fin.
A veces dos áreas están haciendo la misma tarea.
A veces una tienda dedica tiempo a una gestión administrativa que podría resolverse aguas arriba.
A veces customer service está absorbiendo un problema que se genera mucho antes de que el cliente contacte.
Y otras veces, por supuesto, el límite sí está en la tecnología.
Ahí está precisamente la dificultad.
No se trata de defender la tecnología existente ni de evitar una inversión. Se trata de saber qué estamos intentando arreglar antes de decidir cuánto invertir en arreglarlo.
Ese tipo de decisiones es precisamente donde el problema deja de pertenecer únicamente a tecnología, operaciones o ecommerce y pasa a necesitar una lectura más amplia del negocio. Es uno de los ámbitos en los que suelo trabajar desde Executive Advisory: ayudar a ordenar el problema antes de comprometer una solución.
Hay además una dimensión económica que me parece especialmente relevante. Cuando una compañía dice que su operación digital no escala, trato de entender qué está ocurriendo con el coste por pedido a medida que crece el volumen.
Si los pedidos aumentan un 30 % y para sostenerlos necesitamos prácticamente un 30 % más de recursos, no estamos escalando. Estamos aumentando volumen.
Cuánto cuesta procesar un pedido normal y cuánto cuesta procesar una excepción.
Porque una preventa que entra, se asigna y se entrega correctamente puede requerir muy poca intervención. Pero esa misma venta, cuando necesita una reasignación de stock, dos consultas internas, una llamada a tienda y una conversación con el cliente, tiene una economía completamente distinta.
Y normalmente contabilizamos las dos como una venta.
La diferencia puede ser muy significativa. Y, sobre todo, puede cambiar completamente el diagnóstico. Quizás no necesitamos sustituir toda la plataforma para mejorar la operación. Quizás necesitamos eliminar determinados pasos, redefinir responsabilidades, automatizar algunas tareas sobre la arquitectura existente y reservar la inversión tecnológica para aquellos puntos donde realmente existe una limitación estructural.
O quizás, después de hacer ese análisis, descubramos exactamente lo contrario: que hemos llegado al límite de la arquitectura actual y que seguir construyendo excepciones encima de ella empieza a ser más caro que sustituirla.
Las dos conclusiones son válidas.
Lo importante es llegar a ellas en ese orden.
Primero entender cómo funciona realmente la operación.
Después entender dónde se genera su coste.
Y sólo entonces decidir qué parte del problema queremos resolver con tecnología.
En determinadas organizaciones, mantener esa visión completa de negocio, operaciones, tecnología y economía digital requiere que exista una responsabilidad claramente definida sobre el conjunto, no sólo sobre cada una de sus partes. Es precisamente uno de los ámbitos en los que una dirección digital puede aportar valor cuando la complejidad del negocio empieza a superar los límites funcionales de cada área.
Cuando una operación empieza a acumular excepciones, ¿en qué momento consideráis que el problema ha dejado de ser operativo y empieza a justificar un cambio de tecnología?
