Cómo integrar la tecnología en la estrategia de tu empresa

La mayoría de los proyectos de tecnología que salen mal no fallan por la tecnología. Fallan porque nadie decidió, antes de empezar, qué problema del negocio se estaba resolviendo y cómo se iba a saber si se resolvió.

Se nota en cómo llega el encargo. Casi nadie llega diciendo cuál es el problema: llegan diciendo «necesito un sistema», «queremos desarrollar una app», «hay que migrar a algo más moderno». Todas esas son soluciones. Y a veces la solución que traen no es la que resuelve lo que les duele.

Esta guía es sobre el paso anterior.

Empieza por el proceso, no por el sistema

Un sistema es una forma de ejecutar un proceso. Si el proceso no está entendido, el software lo va a congelar tal como está, con sus vueltas y sus excepciones incluidas.

Las preguntas que ordenan esa conversación son incómodas y baratas:

• ¿Qué tarea consume hoy más horas de las que debería, y quién las pone?
• ¿Dónde se cae la información entre un área y otra?
• ¿Qué dato necesita la dirección todos los meses y hoy se arma a mano?
• ¿Qué error se repite y cuánto cuesta cada vez que ocurre?

Las respuestas suelen apuntar a un lugar distinto del que traía el encargo original. Ese desplazamiento es el trabajo.

El marco de las tres capas

Cuando aparecen varios candidatos, ordenarlos por tamaño o por entusiasmo no funciona. Este corte sí:

Lo obligatorio va primero siempre, y no porque sea lo más valioso: porque su fecha no la pones tú. En República Dominicana, el calendario de facturación electrónica de la Ley 32-23 es el ejemplo vivo —lo tratamos en detalle en la guía sobre historia clínica electrónica, pero aplica a cualquier sector con RNC.

Lo operativo va segundo porque financia lo demás y porque construye credibilidad interna. Una empresa que nunca ha terminado un proyecto de tecnología no debería empezar por el más ambicioso.

Lo estratégico va tercero, y necesita que las dos capas anteriores estén estables. Un producto nuevo montado sobre una operación que no cuadra sus números hereda el problema.

Comprar, construir o automatizar

Tres caminos para el mismo problema, con costos muy distintos:

Comprar un producto existente es lo correcto cuando tu proceso no tiene nada particular. Pagar por desarrollar lo que ya existe y funciona es la forma más cara de llegar tarde. Si el problema se resuelve con algo que ya está en el mercado, eso es lo que hay que decir, aunque no lo venda quien te asesora.

Automatizar encaja cuando los sistemas ya existen y el trabajo manual está en el medio, copiando datos de uno a otro. Es el camino más barato y el más rápido de los tres, y por eso conviene descartarlo explícitamente antes de pasar a construir. Lo desarrollamos en qué automatizar y qué no.

Construir a medida se justifica cuando el proceso es el que te diferencia, o cuando ningún producto del mercado lo cubre. Es la opción más costosa y la que más control te da: el sistema se adapta al negocio en vez de al revés.

El orden en que conviene evaluarlos es ese: comprar, automatizar, construir. Casi siempre se hace al revés.

Y no es una decisión que se tome leyendo un folleto ni pidiendo tres cotizaciones. Cuál de los tres corresponde sale de la evaluación del proceso, que es el paso que casi todo el mundo se salta. Sin haber entendido cómo se trabaja hoy, la elección entre comprar, automatizar y construir se hace por presupuesto o por entusiasmo, y las dos formas fallan igual.

Esa evaluación es también la que puede terminar en «no hay que construir nada». Es un resultado legítimo del diagnóstico y conviene que tu proveedor pueda llegar a él: si el problema se resuelve con algo que ya existe, aunque no lo venda quien te está asesorando, eso es lo que hay que decir.

Cómo se ve una decisión bien tomada

Tiene cuatro elementos, y se escriben antes de contratar a nadie:

1. El problema en lenguaje de negocio. No «implementar un CRM», sino «los leads de las campañas se pierden entre que entran y que alguien los llama».
2. Cómo se va a medir. Una cifra que hoy puedas tomar, para poder compararla después. Si no se puede medir hoy, medirla es el primer proyecto.
3. Quién es el dueño. Una persona con nombre, del lado del negocio, que decide y responde. Un proyecto sin dueño se convierte en el proyecto de nadie.
4. Qué pasa si no se hace. Si la respuesta es «nada», tienes tu respuesta.

Los errores caros

Empezar por el proyecto más grande. Es el que más tarda en dar señales y el que más gente desanima cuando se atrasa.

Comprar tecnología para un problema de proceso. Si el problema es que nadie aprueba a tiempo, un sistema nuevo solo hace más visible la demora.

Tratar la migración de datos como un detalle. Es un proyecto propio, con su esfuerzo, y depende del estado en que estén los datos actuales. Meterla dentro del presupuesto de desarrollo es la forma más común de que un proyecto se pase de plazo.

No presupuestar lo que viene después. Un sistema en producción tiene costo de operación, de soporte y de cambios. Un proyecto que solo presupuesta la construcción está incompleto por diseño.

Dejarlo sin dueño. Es el más frecuente y el más silencioso: todo el mundo está de acuerdo en que hay que hacerlo y nadie tiene el tiempo asignado para empujarlo.

Por dónde se empieza

Por una conversación sobre el proceso, no sobre el sistema. Del proceso sale qué hay que construir, con qué método y cuánto toma —y a veces sale que no hay que construir nada.

Cuando ya está claro qué se va a hacer, quedan dos decisiones más: cómo se va a trabajar y quién lo va a ejecutar.

Datos clave de este análisis

1. La mayoría de los encargos de tecnología llegan formulados como solución —«necesito un sistema», «queremos una app»— y no como problema de negocio.
2. Los proyectos candidatos se ordenan en tres capas: obligatorio por normativa, operativo por ahorro de costo y error, y estratégico por nueva oportunidad de venta.
3. Lo obligatorio se atiende primero porque su fecha la impone un tercero, como el calendario de facturación electrónica de la Ley 32-23 en República Dominicana.
4. Ante un mismo problema conviene evaluar en este orden: comprar un producto existente, automatizar entre sistemas actuales, y solo entonces construir a medida.
5. Una decisión bien tomada define el problema en lenguaje de negocio, cómo se medirá, quién es el dueño del proyecto y qué ocurre si no se hace.
6. La migración de datos es un proyecto propio y su esfuerzo depende del estado de los datos existentes.
7. Un sistema en producción tiene costo de operación, soporte y cambios que debe estar presupuestado desde el inicio.