El valor de la analítica en una pyme empieza en la decisión, no en la herramienta

Una pyme puede disponer de datos, cuadros de mando, hojas de cálculo cuidadas o una nueva plataforma analítica sin que cambie una decisión relevante. La tecnología puede funcionar correctamente y, aun así, no demostrar valor para el negocio.

El problema suele aparecer antes de construir. Se empieza por la solución: un dashboard, un modelo de forecasting, una automatización o una aplicación de inteligencia artificial. Después se buscan datos y se delimita el trabajo técnico. Pero queda sin responder una pregunta más importante: ¿qué decisión se tomará de otra manera cuando exista esa solución?

Para una empresa con recursos limitados, esa pregunta debería ordenar la inversión. El objetivo no es acumular herramientas, sino mejorar decisiones, procesos y resultados concretos.

Los datos no eliminan las restricciones de una pyme

No todas las pymes parten del mismo punto. Algunas trabajan principalmente con un ERP, Excel y conocimiento operativo acumulado. Otras ya utilizan CRM, herramientas de business intelligence, sistemas de planificación o repositorios de datos. Tener más información puede ayudar, pero no resuelve por sí solo los problemas de adopción, capacidades o prioridad.

Los informes de la OCDE sobre analítica y digitalización en pymes identifican barreras estructurales relacionadas con recursos, competencias y capacidades organizativas. OCDE, 2019 y OCDE, 2021 no son una medición actual de cuántas empresas sufren cada dificultad, pero sí ofrecen una base útil para entender por qué adoptar y aprovechar tecnologías basadas en datos no depende únicamente de comprar software.

En la práctica, una iniciativa analítica también consume tiempo de operaciones, finanzas, comercial o planificación. Requiere revisar definiciones, validar datos, cambiar rutinas y asignar responsabilidad. Por eso, antes de preguntar qué herramienta conviene implantar, es más útil identificar una decisión que hoy se toma con lentitud, incertidumbre, exceso de trabajo manual o criterios poco consistentes.

La decisión concreta da sentido al proyecto

Un proyecto de forecasting puede parecer justificado porque existen históricos de ventas. Sin embargo, su valor depende de lo que ocurra después de generar una previsión. ¿Cambiarán las compras? ¿La asignación de inventario? ¿La planificación de producción? ¿La capacidad de servicio o las prioridades comerciales?

Si una previsión más precisa no modifica ninguna de esas decisiones, puede seguir siendo informativa, pero su impacto esperado será limitado. En cambio, si permite revisar semanalmente qué referencias requieren ajustar pedidos de compra, la iniciativa ya tiene un uso operativo identificable.

Con los dashboards ocurre algo parecido. Un cuadro de mando puede reducir el tiempo empleado en preparar informes y ordenar información dispersa. Eso ya puede ser un beneficio válido. Pero, si muestra desviaciones de margen, roturas de stock o retrasos de servicio, conviene concretar quién revisará esas señales, qué acción puede tomar y dentro de qué plazo.

Este es el criterio de SC-Analytics: un proyecto debería comenzar por la decisión que se quiere mejorar, no por el modelo, el dashboard o la plataforma que se quiere construir.

No significa que toda decisión deba automatizarse ni que toda iniciativa requiera modelos complejos. A veces basta con ordenar indicadores, definir una regla operativa o establecer una rutina de revisión. En otros casos, tiene sentido aplicar forecasting, optimización matemática, machine learning o automatización. La complejidad debe ser proporcional al problema, los datos disponibles, el riesgo de equivocarse y la capacidad real de mantener la solución.

Un marco para comparar iniciativas antes de invertir

El resumen público de un capítulo de Springer sobre creación de valor en proyectos analíticos propone evaluar las iniciativas considerando capacidades habilitadoras, riesgos, funciones beneficiadas e impacto empresarial. También plantea el uso de pilotos acotados y un sistema de puntuación para priorizar proyectos antes de comprometer recursos significativos. Referencia del capítulo.

Esta propuesta no debe interpretarse como un consenso general de toda la literatura ni como evidencia reciente sin verificar la fecha de publicación. Sí sirve para una idea práctica: implantar una tecnología no es, por sí mismo, una medida suficiente de creación de valor.

Cuando una empresa tiene varias opciones —automatizar reporting, mejorar la previsión de demanda, revisar inventario, detectar anomalías financieras o aplicar IA a tareas administrativas— conviene compararlas con criterios explícitos:

• Impacto esperado: qué coste, margen, nivel de servicio, tiempo de ciclo, riesgo o capacidad podría afectar la decisión.
• Viabilidad: si los datos, conocimientos y sistemas disponibles permiten abordar el problema con un alcance razonable.
• Riesgo: qué consecuencias tendría una recomendación incorrecta o una decisión basada en información deficiente.
• Esfuerzo total: no solo desarrollo técnico, sino integración, mantenimiento, validación y dedicación de las personas implicadas.
• Dependencia del cambio operativo: cuánto debe cambiar el proceso y si existe capacidad real para adoptar ese cambio.
• Facilidad de medición: si será posible observar un uso y un resultado coherentes con la hipótesis inicial.

No se trata de convertir la priorización en una fórmula automática. El juicio directivo sigue siendo necesario. Pero una comparación estructurada reduce el riesgo de elegir por novedad, por presión comercial o porque una herramienta está disponible.

La ficha previa a cualquier iniciativa analítica

SC-Analytics propone reunir estas preguntas en una única ficha de evaluación antes de aprobar un proyecto. Es un criterio editorial propio, no una conclusión atribuida literalmente a las fuentes.

1. ¿Qué decisión debe mejorar?

La respuesta debe describir una acción concreta. “Mejorar la visibilidad” puede ser un objetivo útil, pero todavía no define una decisión. “Determinar qué pedidos priorizar cuando la capacidad es limitada” o “revisar qué referencias requieren modificar la compra” sí permite diseñar y evaluar una iniciativa.

2. ¿Quién actuará y en qué proceso?

Hay que identificar al responsable que recibirá la información o recomendación, la autoridad que tiene y el momento del proceso en que podrá actuar. Sin ese vínculo, el resultado puede terminar como información adicional sin uso claro.

3. ¿Qué indicador se espera afectar?

El indicador puede ser económico u operativo: inventario, nivel de servicio, margen, carga administrativa, tiempo de ciclo, utilización de capacidad o cualquier medida pertinente para la decisión. No siempre será posible atribuir el resultado con precisión absoluta, pero debe existir una conexión razonable entre la intervención y el negocio.

4. ¿Qué datos, capacidades y restricciones existen?

No basta con confirmar que hay datos. Es necesario revisar acceso, consistencia y utilidad para el problema. También importan las restricciones: plazos, políticas comerciales, capacidad disponible, reglas de servicio, dependencias entre sistemas y esfuerzo de mantenimiento.

5. ¿Qué cambio debe producirse en el trabajo diario?

Una previsión genera una señal; un dashboard muestra una excepción; una automatización prepara información. El valor esperado depende de la acción posterior. La ficha debe describir qué rutina, regla o decisión cambiará realmente.

6. ¿Cómo se decidirá si se continúa, ajusta o detiene?

Antes del piloto deben quedar definidos el responsable de la evaluación, el periodo de prueba, el indicador observado y una condición verificable para decidir el siguiente paso. Puede ser calidad suficiente de datos, uso efectivo por el equipo, viabilidad operativa o evolución del indicador acordado. No hace falta inventar umbrales universales: deben ser coherentes con cada caso.

El piloto debe probar una hipótesis de negocio

Un piloto acotado no debería limitarse a demostrar que una herramienta funciona. Una demostración técnica puede ser convincente y, sin embargo, no encajar en las condiciones reales de la empresa.

La hipótesis debe formularse en términos de negocio. Por ejemplo: si el equipo de compras recibe una señal semanal sobre referencias con riesgo de rotura y puede revisar esas propuestas dentro de su proceso habitual, debería mejorar la capacidad de anticipar incidencias frente al procedimiento actual. El piloto deberá comprobar tanto si la señal es útil como si el equipo la utiliza y puede actuar sobre ella.

Conviene limitar el alcance a una familia de productos, una planta, un tipo de pedido, un proceso administrativo o un grupo de usuarios. Así se aprende sin comprometer una inversión desproporcionada.

El flujo puede representarse así:

Problema y decisión de negocio → responsable y proceso → indicador y valor esperado → datos, capacidades y riesgos → piloto acotado → continuar, ajustar o detener.

La última decisión es tan importante como la primera. Escalar tiene sentido cuando existe evidencia suficiente de uso, viabilidad e impacto esperado. Ajustar puede ser adecuado si el problema es válido, pero los datos o el proceso requieren cambios. Detener también puede ser una buena decisión si la iniciativa no justifica más tiempo, coste o complejidad.

Elegir tecnología después de entender el trabajo

Poner la decisión antes que la herramienta no implica rechazar la tecnología. Implica elegirla cuando ya se entiende el problema que debe resolver.

Una vez definidos la decisión, el responsable, el proceso, el indicador y las restricciones, es más fácil valorar si basta con un reporting mejor diseñado, si conviene automatizar una tarea, si hace falta forecasting o si el problema requiere un modelo de optimización. También es más fácil reconocer cuándo no conviene construir nada todavía.

Para una pyme, priorizar bien no consiste en esperar condiciones perfectas. Consiste en empezar por problemas concretos, hacer explícitas las condiciones de éxito, limitar el riesgo mediante pilotos y escalar solo cuando la solución ayuda de forma demostrable a tomar una decisión mejor.