Tecnología como negocio (de verdad), no como juguete caro: deja de quemar lana

Llegas a la junta con el founder y suelta: “Necesitamos IA… pero para ayer”. Ventas pide un CRM “que haga todo”, finanzas quiere recortar 30% y tu equipo trae un backlog que ya parece lista del súper en quincena. Y tú con la laptop ya medio guerrera, viendo cómo sostener el changarro sin aventar el próximo gasto que luego nadie pela.

En ese punto es bien fácil caer en la trampa: comprar la herramienta shiny, contratar una consultoría carísima, o “migrar a microservicios” porque lo viste en un talk. Se siente como avanzar… hasta que llega el deadline, falla production y nadie sabe ni quién es el owner.

La neta: no es que seas malo en tech. Es que el juego no es “tener mejor tecnología”. Es operar tecnología como negocio, con decisiones defendibles y números claros. No con juguetes caros.

Qué vas a aprender

• Cómo traducir “queremos modernizarnos” a objetivos de negocio medibles.
• Un marco simple para decidir qué construir, qué comprar, qué integrar y qué matar.
• Cómo armar un roadmap que sobreviva cambios de prioridades sin volverse PowerPoint muerto.
• Cómo evitar compras que se vuelven suscripciones eternas y deuda técnica que se vuelve “normal”.
• Un checklist operativo para que tus decisiones aguanten preguntas del CEO/CFO… y el golpe de realidad en producción.

Contexto práctico: el “juguete caro” casi siempre se ve así

Tres escenas que pasan diario en México/LatAm:

1. La suite “todo en uno”

   • La compran porque “sale más barato que desarrollar”.
   • A los 3 meses: nadie la usa bien, necesitas un consultor para cambios básicos y terminas con un Excel paralelo.

2. La migración épica

   • “Vámonos a Kubernetes/microservicios/event-driven” sin un dolor real que lo justifique.
   • Resultado: más complejidad, on-call infernal, y el negocio sigue sin métricas claras.

3. La herramienta de moda

   • Observabilidad, AI assistants, data lake, MDM, lo que sea.
   • Se compra sin dueño, sin proceso, sin definición de éxito.

Tecnología sí puede ser ventaja competitiva. Pero solo cuando está amarrada a resultados y no a ego, presión o FOMO.

Guía principal: de “queremos tecnología” a “esto genera valor”

1) Empieza por el outcome, no por la herramienta

Antes de “comprar X”, escribe el outcome con esta plantilla:

Outcome = (métrica) + (cambio) + (plazo) + (impacto)

Ejemplos reales:

• “Reducir el tiempo de alta de cliente de 48h a 4h en 60 días para aumentar conversión en +8%.”
• “Bajar el costo por ticket de soporte de $45 a $30 en Q3 sin bajar CSAT.”
• “Mejorar el fill rate del inventario de 92% a 97% para reducir cancelaciones.”

Decisión práctica: si no puedes escribir el outcome sin mencionar la herramienta (“con Salesforce”, “con IA”), todavía no está claro qué problema estás resolviendo.

2) Define un KPI principal y 2 guardrails

Muchos proyectos truenan porque “mejoran todo” y al final nadie sabe si funcionó.

• KPI principal (uno): el que define éxito.
• Guardrail 1: calidad/experiencia (ej. CSAT, NPS, tasa de error).
• Guardrail 2: costo/operación (ej. costo por transacción, horas on-call).

Ejemplo para un checkout:

• KPI: conversión.
• Guardrails: latencia P95 < 800ms; incidentes sev1 = 0.

Decisión práctica: si tu KPI puede “mejorar” rompiendo operación, vas a ganar la demo y perder production.

3) Haz el mapa de flujo (sí, aunque suene básico)

Agarra el proceso de punta a punta: lead → venta → cobro → entrega → soporte. Lo dibujas en Miro o en una hoja (la clásica: cafetería, WiFi medio chafa, el jefe pidiéndote “un cambio rápido” en pleno cierre de mes).

Marca:

• Handoffs (donde pasa de persona a sistema o de área a área).
• Re-trabajo (capturas repetidas, “mándamelo por Whats”).
• Cuellos (aprobaciones, conciliación, facturación, “se atoró en contabilidad”).

Decisión práctica: el 80% del ROI sale de quitar fricción del flujo, no de meter features.

4) Aplica la matriz Build / Buy / Integrate / Kill

Para cada “solución” candidata, contesta rápido (y por escrito):

• Build (construir): cuando es core del negocio o te da ventaja diferencial.
• Buy (comprar SaaS): cuando es commodity y te importa más el time-to-value.
• Integrate (integrar): cuando ya tienes piezas y el valor está en conectarlas.
• Kill (matar): cuando el sistema existe por inercia y cuesta más de lo que vale.

Regla de guerra:

• Si tu equipo no puede mantenerlo a las 2am con un incidente real, no lo construyas.

Mini-scorecard (0–2 puntos cada uno):

• Diferenciación
• Urgencia
• Complejidad operativa
• Costo total (TCO)
• Riesgo (seguridad/compliance)
• Dependencia del vendor

Decisión práctica: “Buy” no significa “ya quedó”. Significa que tu chamba cambia: ahora tienes que gobernar la relación con el vendor, tu data y tu workflow.

5) Calcula el TCO como adulto: licencia + operación + cambio

El juguete caro se justifica con el precio de lista. El negocio se decide con TCO (Total Cost of Ownership).

Incluye:

• Licencias y tiers (usuarios, storage, requests, add-ons)
• Implementación/consultoría
• Integraciones (APIs, iPaaS, webhooks)
• Soporte interno (horas del equipo, on-call)
• Capacitación y rotación (onboarding de gente nueva)
• Riesgo: incidentes y downtime (costo de oportunidad)

Ejemplo rapidísimo (ilustrativo):

• CRM: $20 USD/usuario/mes * 50 usuarios = $1,000/mes
• Add-ons + soporte premium: $600/mes
• Consultoría inicial: $8,000
• Integraciones: 2 sprints del equipo
• Operación: 10h/mes del sysadmin + 6h/mes del analista

De pronto no cuesta $1,000/mes. Cuesta “una lana” sostenida y, si no hay dueño, se pudre.

Decisión práctica: si el CFO solo está viendo licencias, tú llega con TCO y supuestos. Te va a tomar más en serio cuando caiga el primer renewal.

6) Roadmap de negocio (no roadmap de features)

Estructura útil:

• Now (0–4 semanas): quick wins que mueven KPI sin re-arquitectura.
• Next (1–3 meses): proyectos con dependencias claras.
• Later (3–6 meses): apuestas grandes (migraciones, data platform, re-platform).

Cada item debe tener:

• Outcome + KPI
• Dueño (persona, no “TI”)
• Riesgos y mitigación
• Métrica de adopción (si nadie lo usa, no existe)

Decisión práctica: si tu roadmap no cabe en una sola pantalla (sin scrolleo infinito), ya es wishlist.

7) Gobernanza ligera: quién decide qué (y con qué información)

La mayoría de las broncas no son técnicas, son de decisión.

Define 3 niveles:

• Táctico (semanal): priorización de backlog, bugs, soporte.
• Producto/Negocio (quincenal o mensual): outcomes, tradeoffs, cambios de alcance.
• Arquitectura/Seguridad (mensual): estándares mínimos, riesgos, excepciones.

Tip de vida real: si la decisión no tiene foro, se decide en Slack a las 11pm, y al día siguiente alguien te pide un rollback “en corto”.

Screenshots sugeridos

• Un ejemplo de roadmap Now/Next/Later en Notion/Jira (vista simple).
• Un tablero con KPI principal + guardrails (Looker/Data Studio/Metabase).
• Diagrama del flujo de proceso (Miro/Lucidchart) con cuellos marcados.
• Tabla de TCO (Google Sheets) con supuestos y escenarios (base/optimista/pesimista).

Errores comunes (y cómo salir sin incendiar todo)

Error 1: Comprar la herramienta antes de entender el proceso

Síntoma: “Ya pagamos la licencia, ahora hay que ver cómo encaja”.

Solución: pausa y mapea el flujo. Implementa primero lo mínimo que mueve KPI. Si el vendor se pone pesado porque “no usas todo”, mejor enterarte temprano.

Error 2: Confundir adopción con implementación

Síntoma: “Ya lo deployamos” pero el equipo sigue con Excel/WhatsApp.

Solución: define métricas de adopción:

• % de operaciones hechas en el sistema
• usuarios activos semanales
• tiempo promedio del flujo

Y pon un dueño de adopción (muchas veces es operaciones, no TI).

Error 3: No asignar owner y presupuesto de operación

Síntoma: nadie atiende configs, permisos, integraciones, incidentes.

Solución: por cada sistema: owner + backup + runbook + ventana de mantenimiento. Si no hay owner, el sistema es huérfano y va a fallar en el peor momento (tipo fin de mes y SAT).

Error 4: Migrar arquitectura por moda

Síntoma: “Microservicios” para una app que ni tráfico tiene, pero ya te cuesta 3 veces operarla.

Solución: complejidad proporcional:

• monolito bien hecho + buenas pruebas + CI/CD
• observabilidad básica
• escalamiento donde duele

Error 5: Medir éxito con vanity metrics

Síntoma: “Subimos 20% el número de tickets resueltos” pero cayó la satisfacción.

Solución: KPI + guardrails. Sin guardrails, sin querer incentivas trampas.

Checklist final (para decidir sin humo)

• Puedo escribir el outcome sin mencionar una herramienta.
• Tengo 1 KPI principal y 2 guardrails.
• El flujo actual está mapeado con cuellos y re-trabajo.
• Elegí Build/Buy/Integrate/Kill con scorecard y tradeoffs.
• Calculé TCO (licencia + implementación + integración + operación + adopción).
• Hay owner, backup y runbook.
• El roadmap está en Now/Next/Later con métricas de adopción.
• Sé cómo haré rollback o plan B si falla.

FAQ

1) ¿Cómo le explico a mi CEO que “no” a una herramienta de moda sin verme negativo?

Dile que sí al outcome y no al juguete: “Si queremos X resultado, estas son 2–3 opciones con costo, tiempo y riesgo”. Lleva escenarios y pide decidir con KPI.

2) ¿Buy siempre es mejor que Build para ir rápido?

No. Buy acelera el arranque, pero puede frenarte después por customizaciones, límites del vendor y costo creciente. Build es más lento al inicio, pero te da control si es core.

3) ¿Qué hago si ya compramos la herramienta y está subutilizada?

Arma un “rescate” de 30 días: 3 flujos críticos, entrenamiento, métricas de adopción y un owner. Si no sube adopción, recorta alcance o planea salida antes del renewal.

4) ¿Cómo estimo ROI si no tengo datos limpios?

Empieza con supuestos explícitos y márgenes:

• baseline (medición manual de una semana)
• rango (optimista/pesimista)
  Mejor una estimación honesta con error conocido que un “ROI infinito” sin sustento.

5) ¿Cuál es la señal más clara de que estoy comprando un juguete caro?

Cuando el argumento principal es “porque todos lo usan” o “se ve pro”, y no puedes ligar la compra a un KPI con plazo, owner y TCO.

Lo que sigue

Ya amarramos tecnología a resultados. Lo que sigue es lo que normalmente rompe equipos: cómo armar un roadmap que sobreviva cambios, recortes y urgencias sin volverse caos.

Spoiler: no se arregla con más Jira. Se arregla con mejores decisiones, límites claros y un workflow que no se desmorone en la primera emergencia.