Caso de negocio para automatización: escenarios, sensibilidad y decisión

El caso de negocio es una decisión documentada, no una promesa

Un caso de negocio útil no intenta demostrar que el proyecto «va a rendir». Intenta mostrar bajo qué supuestos conviene hacerlo, qué podría salir mal y qué se aprendería con una prueba antes de comprometer todo el presupuesto. Quien lo presenta con un solo escenario optimista pierde credibilidad cuando aparece el primer sobrecosto.

La estructura que sigue sirve para RFID, ESL o dispositivos móviles. En este texto no hay cifras de retorno, porque cualquier número que no venga de sus propios datos sería inventado. Los valores del ejemplo son ficticios y están marcados como tales.

Línea base: medir antes de proyectar

Todo beneficio es una diferencia contra algo, así que primero hay que medir ese algo. Describa el proceso actual con datos propios: cuánto tiempo toma, cuántos errores ocurren, cuánto cuesta corregirlos, qué se pierde cuando falla. Si no hay datos, el primer entregable del proyecto puede ser medir durante unas semanas.

Tenga cuidado con las métricas de partida. Una exactitud de inventario depende de cómo se cuente; un conteo de lecturas no es un conteo de artículos únicos. Defina con operaciones y finanzas qué mide cada indicador y quién lo registra, para que el «después» use el mismo método que el «antes».

Inversión: la lista completa

La inversión no se reduce al equipo. Incluya etiquetas o consumibles recurrentes, lectores, dispositivos, infraestructura de red, instalación, software y licencias, integración, capacitación, gestión del cambio, soporte y renovación. En ESL, por ejemplo, la documentación de integración de Cisco Meraki con Vusion, una página que promueve su propia alternativa integrada, señala que instalar gateways ESL implica costos adicionales como cableado, puertos de conmutador con alimentación, aprovisionamiento y monitoreo de seguridad de TI y mano de obra de instalación; son rubros que conviene preguntar en una primera cotización de etiquetas. Para los rubros de dispositivos móviles, remítase a la guía de costo total de PDA y lectores.

Distinga inversión inicial de costo recurrente. Y reserve una partida de contingencia con el criterio que su organización aplique a proyectos de tecnología; el porcentaje es una decisión interna y no se sugiere aquí.

Beneficios netos y su nivel de certeza

Clasifique los beneficios en tres grupos. Los medibles y directos se pueden comparar con la línea base (tiempo de una tarea, errores corregidos). Los indirectos dependen de una cadena de supuestos (menos faltantes que generan más ventas). Los estratégicos son difíciles de cuantificar (capacidad de ofrecer un servicio nuevo). En un caso serio, la decisión debe sostenerse con los primeros y tratar los demás como un posible extra.

La alianza RAIN afirma en sus preguntas frecuentes que en comercio minorista, logística, salud y aviación hay aplicaciones con retornos significativos; es una declaración general de una organización que promueve la tecnología, no una medición de su caso. Úsela como contexto, no como argumento financiero.

Considere también los beneficios netos: reste lo que el cambio quita o añade en trabajo. Un sistema que acelera una tarea y agrega otra de mantenimiento debe reflejar ambas.

Escenarios y sensibilidad

Construya al menos tres escenarios: conservador, base y favorable. No se diferencian solo por un porcentaje; cada uno debe tener supuestos explícitos sobre adopción, calidad de datos, necesidades de integración y duración de la fase de ajuste. Luego haga un análisis de sensibilidad: mueva una variable a la vez y observe cuánto cambia el resultado. Las variables que más lo mueven son las que conviene medir en piloto.

Ejemplo hipotético de lectura

Supongamos, solo como ilustración, que un equipo de finanzas descubre que su caso depende casi por completo de dos variables: el tiempo ahorrado por tarea y la proporción de tareas que realmente se harán con el sistema nuevo. El resto de los supuestos mueve poco el resultado. En lugar de discutir todo el modelo, el equipo decide que la prueba de concepto medirá justamente esas dos variables con personal real. El resultado de la prueba reemplaza dos supuestos por datos y el comité decide con menos incertidumbre. Este ejemplo no refleja a ninguna empresa ni cifras reales.

Cómo presentar la decisión

Presente al comité tres cosas: el caso base con sus supuestos, el rango entre conservador y favorable, y las condiciones de parada, por ejemplo qué resultado de la prueba haría detener o replantear el proyecto. Incluya un plan de medición posterior: sin él, nadie sabrá si el beneficio llegó.

Evite el sesgo de justificar una compra ya decidida. Si el caso depende de beneficios estratégicos que nadie puede medir, dígalo con claridad: puede ser una decisión legítima, pero debe presentarse como apuesta y no como retorno calculado.

Siguiente paso

Mida la línea base de un solo proceso durante un periodo corto, liste la inversión completa con apoyo de proveedores y construya los tres escenarios con supuestos escritos. Luego defina qué prueba reduciría la incertidumbre más importante.

Si quiere revisar su caso con ARKCOM, puede escribir desde garkcom.com/contact.