Qué información debería conocer cualquier director antes de comprar tecnología

Introducción

Antes de comprar tecnología, un director no necesita conocer todos los detalles técnicos de cada producto, pero sí debe comprender qué problema se pretende resolver, qué dependencia se crea, cuánto costará mantener la solución y qué ocurrirá si no funciona como se esperaba.

Muchas decisiones tecnológicas se presentan como comparaciones simples: un equipo frente a otro, una licencia básica frente a una profesional, nube frente a servidor propio o una aplicación conocida frente a una alternativa más económica. Sin embargo, el precio y la lista de funciones muestran solo una parte de la decisión.

Una herramienta puede ser barata y exigir cientos de horas de adaptación. Un servicio puede incluir muchas funciones y no integrarse con los sistemas existentes. Una plataforma puede reducir trabajo durante dos años y convertirse después en una dependencia costosa porque los datos no se exportan con facilidad. Un equipo muy potente puede resultar innecesario, mientras una inversión aparentemente secundaria en copias, formación o conectividad puede proteger toda la actividad.

El papel de dirección no consiste en elegir marcas ni sustituir al especialista técnico. Consiste en establecer objetivos, exigir información comparable, identificar riesgos empresariales y decidir qué compromisos son aceptables. Para ello necesita una visión que conecte tecnología, procesos, personas, datos, costes, continuidad y capacidad de cambio.

Este artículo propone la información mínima que debería conocer cualquier director antes de aprobar una compra tecnológica. El enfoque está pensado para pequeñas empresas, microempresas, despachos profesionales y organizaciones de formación online que necesitan tomar decisiones sólidas sin crear procesos de compra corporativos desproporcionados.

Índice

• Cuál es el papel del director en una compra tecnológica
• 1. Qué problema empresarial se quiere resolver
• 2. Cómo se resuelve hoy y cuánto cuesta
• 3. Qué resultado debe producir la compra
• 4. Quién utilizará la tecnología
• 5. Qué requisitos son obligatorios
• 6. Cómo encajará con la infraestructura existente
• 7. Qué datos utilizará y quién los controlará
• 8. Qué riesgos de seguridad introduce
• 9. Qué ocurrirá si falla
• 10. Qué dependencia se crea del proveedor
• 11. Cuál es el coste total durante su ciclo de vida
• 12. Qué exige la implantación
• 13. Cómo se logrará la adopción
• 14. Qué capacidad y escalabilidad necesita
• 15. Cómo se mantendrá y recibirá soporte
• 16. Cómo se retirará o sustituirá
• Cómo comparar alternativas de forma equivalente
• Cuándo conviene realizar una prueba piloto
• Ficha de decisión para dirección
• Semáforo de riesgo de una compra tecnológica
• Preguntas que deben hacerse al proveedor
• Ejemplo aplicado a una pequeña empresa
• Ejemplo aplicado a una empresa de formación online
• Errores frecuentes de dirección
• Proceso de decisión en diez pasos
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Cuál es el papel del director en una compra tecnológica

La dirección debe decidir sobre impacto empresarial, prioridades, riesgo y recursos. El especialista técnico debe analizar arquitectura, configuración, rendimiento y compatibilidad. Ambos papeles se necesitan.

Antes de aprobar una compra, dirección debería poder explicar:

• qué proceso o capacidad se pretende mejorar;
• qué problema existe actualmente;
• qué resultado se espera;
• qué personas y datos estarán afectados;
• qué coste total tendrá;
• qué riesgos son aceptables;
• quién será responsable de la implantación;
• cómo se medirá el éxito;
• qué alternativa existe;
• cómo se abandonará la solución si deja de encajar.

Dirección no debería aprobar una herramienta únicamente porque sea popular, porque un competidor la utilice o porque el proveedor prometa transformar la empresa. La compra debe vincularse a una necesidad concreta.

Una buena decisión tecnológica no empieza preguntando qué producto comprar, sino qué capacidad necesita realmente la empresa y qué compromisos está dispuesta a asumir.

1. Qué problema empresarial se quiere resolver

La definición debe expresarse en términos de negocio, no de producto.

Definición deficiente

“Necesitamos un CRM”, “necesitamos inteligencia artificial” o “necesitamos un servidor nuevo”.

Definición útil

“Perdemos solicitudes porque la información comercial está repartida”, “la elaboración de presupuestos consume veinte horas al mes” o “el servidor no admite el crecimiento previsto y carece de soporte”.

Preguntas

• ¿Qué proceso está afectado?
• ¿Qué personas intervienen?
• ¿Con qué frecuencia ocurre?
• ¿Qué impacto produce?
• ¿Es un problema técnico, organizativo o ambos?
• ¿Podría resolverse sin comprar una nueva herramienta?

Una compra no debería utilizarse para ocultar un proceso mal definido, responsabilidades confusas o datos desordenados.

2. Cómo se resuelve hoy y cuánto cuesta

Sin una línea base no puede demostrarse que la compra aporta valor.

Coste actual

• horas de trabajo;
• errores;
• repeticiones;
• incidencias;
• retrasos;
• licencias existentes;
• pérdidas o riesgos;
• dependencia de personas.

Volumen

Debe conocerse cuántos usuarios, operaciones, documentos, alumnos, clientes o gigabytes están implicados.

Limitación real

La empresa puede creer que necesita más hardware cuando el problema es una consulta, una conexión o un procedimiento. Conviene revisar cómo detectar cuellos de botella tecnológicos antes de que aparezcan.

Coste de no actuar

No comprar también tiene consecuencias. Deben estimarse retrasos, riesgos y oportunidades perdidas.

3. Qué resultado debe producir la compra

El objetivo debe ser observable y medible.

Ejemplos

• reducir de seis a dos horas la elaboración de un informe;
• recuperar un servicio en menos de cuatro horas;
• soportar cincuenta usuarios simultáneos;
• eliminar la introducción doble de datos;
• disminuir incidencias de acceso;
• tener la información comercial en una fuente oficial;
• ampliar capacidad durante tres años;
• retirar un sistema sin soporte.

Criterios de éxito

Deben acordarse antes de seleccionar proveedor. Una vez comprada la herramienta, existe tendencia a redefinir el éxito para justificarla.

Resultado mínimo y deseable

Conviene separar lo imprescindible de lo conveniente. Esto evita pagar por funciones atractivas que no resuelven el objetivo principal.

4. Quién utilizará la tecnología

Tipos de usuario

• usuarios diarios;
• usuarios ocasionales;
• administradores;
• clientes o alumnos;
• proveedores;
• personal temporal;
• dirección.

Conocimientos

Una solución puede ser técnicamente excelente y fracasar si exige habilidades que la plantilla no posee.

Accesibilidad y movilidad

Debe conocerse si se trabajará desde oficina, domicilio, móvil, ubicaciones con mala conectividad o equipos compartidos.

Licencias reales

El modelo por usuario, dispositivo, uso o concurrencia puede cambiar mucho el coste.

Administración

También debe identificarse quién dará altas, resolverá permisos, configurará y atenderá incidencias.

5. Qué requisitos son obligatorios

Los requisitos deben clasificarse:

• obligatorios: sin ellos la solución no sirve;
• importantes: aportan valor significativo;
• deseables: pueden posponerse;
• irrelevantes: no deben influir.

Requisitos funcionales

Qué tareas debe realizar.

Requisitos no funcionales

Disponibilidad, rendimiento, seguridad, soporte, accesibilidad, exportación, capacidad y recuperación.

Restricciones

Presupuesto, plazos, legislación, equipos existentes, conectividad y habilidades internas.

Evitar listas copiadas

Una lista genérica de funciones conduce a comparar productos en lugar de resolver necesidades.

6. Cómo encajará con la infraestructura existente

Toda compra introduce relaciones con sistemas actuales.

Compatibilidad técnica

• sistemas operativos;
• navegadores;
• dispositivos;
• formatos;
• bases de datos;
• red;
• identidad;
• copias;
• API;
• versiones.

Compatibilidad operativa

Debe encajar en el proceso real, no solo instalarse correctamente.

Dependencias nuevas

Puede necesitar más almacenamiento, ancho de banda, cuentas, certificados, soporte o formación.

Arquitectura

Conviene comprender qué componentes forman una infraestructura digital moderna antes de añadir otra pieza.

Pruebas de integración

Las afirmaciones comerciales deben verificarse con los sistemas y versiones concretos.

7. Qué datos utilizará y quién los controlará

Tipos de datos

• clientes;
• empleados;
• alumnos;
• facturación;
• documentos;
• contenidos;
• métricas;
• credenciales;
• propiedad intelectual.

Ubicación

La empresa debe saber dónde se almacenan, replican y procesan.

Titularidad

El contrato debe dejar claro que los datos empresariales siguen bajo control de la empresa.

Exportación

No basta con que exista una opción de exportar. Debe conocerse formato, integridad, coste, tiempo y limitaciones.

Fuente de verdad

La nueva solución no debería crear otra copia maestra sin gobierno.

Borrado y retención

Debe saberse qué ocurre al cancelar, cuánto se conserva y cómo se certifica la eliminación.

8. Qué riesgos de seguridad introduce

Accesos

Debe admitir cuentas individuales, roles y autenticación adecuada.

Administración

Conviene separar uso diario y privilegios.

Actualizaciones

Debe conocerse quién actualiza, con qué frecuencia y durante cuánto tiempo.

Incidentes

El proveedor debe explicar notificación, soporte y responsabilidades.

Integraciones

Tokens, claves API y cuentas técnicas necesitan custodia y revocación.

Riesgo proporcional

No toda compra exige el mismo análisis. El riesgo aumenta con criticidad, datos y exposición.

La dirección debe exigir una seguridad empresarial práctica, no una colección de promesas.

9. Qué ocurrirá si falla

Impacto

¿Qué procesos se detienen, cuántas personas quedan bloqueadas y cuánto tiempo puede tolerarse?

Disponibilidad

Las cifras comerciales deben relacionarse con el impacto real. Un porcentaje anual puede ocultar varias horas de caída.

Copias

Debe diferenciarse redundancia, historial, backup y recuperación.

Restauración

¿Quién restaura, cuánto tarda y qué datos pueden perderse?

Modo alternativo

Puede existir un procedimiento manual, un equipo de reserva o un servicio temporal.

Dependencia común

La copia no debería depender del mismo sistema o cuenta que protege.

10. Qué dependencia se crea del proveedor

Titularidad de cuentas

Dominio, nube, licencias y repositorios deben quedar bajo control empresarial.

Conocimiento

La empresa necesita documentación suficiente para comprender y sustituir el servicio.

Soporte

Debe conocerse horario, canal, tiempos y exclusiones.

Subidas de precio

Conviene analizar escalones, renovaciones y capacidad de negociación.

Continuidad del proveedor

¿Qué ocurriría si cambia de estrategia, es adquirido o abandona el producto?

Salida

La capacidad de cambiar debe existir desde el principio. Puede aplicarse cómo evitar dependencia de proveedores.

11. Cuál es el coste total durante su ciclo de vida

La comparación debe utilizar el mismo periodo y alcance.

Costes iniciales

• compra;
• implantación;
• configuración;
• migración;
• integración;
• formación;
• documentación;
• consultoría.

Costes recurrentes

• licencias;
• suscripciones;
• alojamiento;
• soporte;
• energía;
• copias;
• seguridad;
• administración;
• actualizaciones.

Costes ocultos

Horas internas, interrupciones, aprendizaje, duplicidad, errores y coordinación.

Costes futuros

Ampliación, renovación, subida de precios, migración y retirada.

Riesgo

Puede estimarse como probabilidad por impacto.

La metodología completa se desarrolla en cómo calcular el coste real de una infraestructura tecnológica.

12. Qué exige la implantación

Responsable

Debe existir una persona que coordine proveedor, usuarios y decisiones.

Dependencias

Datos preparados, cuentas, infraestructura, contratos, formación y disponibilidad de usuarios.

Migración

Debe incluir limpieza, validación, pruebas y conservación del sistema anterior durante un periodo definido.

Calendario

Conviene evitar periodos críticos de facturación, campañas o cierres.

Vuelta atrás

La implantación debe poder detenerse o revertirse si no cumple criterios.

Carga interna

Comprar una solución no libera automáticamente tiempo; durante la implantación suele consumirlo.

13. Cómo se logrará la adopción

Una herramienta no genera valor si las personas no la utilizan correctamente.

Participación

Los usuarios clave deben probar procesos reales antes de la compra definitiva.

Formación

Debe orientarse a tareas, no solo a menús y funciones.

Procedimientos

Hay que definir cuándo se utiliza la nueva herramienta y cuándo deja de usarse la anterior.

Soporte inicial

Las primeras semanas concentran dudas y errores.

Métricas de adopción

• usuarios activos;
• procesos realizados;
• datos completos;
• errores;
• uso del sistema anterior;
• tiempo por tarea.

Resistencia razonable

Una objeción puede revelar un requisito omitido. No toda resistencia es falta de actitud.

14. Qué capacidad y escalabilidad necesita

Demanda actual

Usuarios, transacciones, almacenamiento, documentos y concurrencia.

Crecimiento

Debe estimarse a uno, tres y cinco años según la vida esperada.

Picos

Campañas, cierres, matrículas y copias pueden exigir más que la media.

Límites comerciales

Usuarios, API, almacenamiento, exportaciones y funciones pueden cambiar de plan.

Tiempo de ampliación

No basta con poder escalar; debe saberse cuánto tarda y qué interrupción produce.

Evitar exceso

Comprar hoy toda la capacidad futura puede inmovilizar presupuesto y quedar obsoleto.

15. Cómo se mantendrá y recibirá soporte

Responsabilidad interna

Quién administra usuarios, configuración, informes y cambios.

Responsabilidad externa

Qué cubre el proveedor y qué se factura aparte.

Actualizaciones

Quién prueba, aplica y revierte.

Conocimiento

Debe existir documentación y transferencia.

Fin de soporte

La vida comercial puede ser menor que la vida deseada por la empresa.

Coste de atención

Una herramienta barata con soporte deficiente puede aumentar mucho las horas internas.

16. Cómo se retirará o sustituirá

El plan de salida debe definirse antes de entrar.

Datos

Formatos, volumen, metadatos, adjuntos e históricos.

Configuración

Plantillas, reglas, automatizaciones, roles y documentación.

Integraciones

Qué sistemas dependen de la solución.

Coste

Servicios profesionales, exportaciones, coexistencia y formación.

Plazo

Una salida que requiere un año no es equivalente a una herramienta sustituible en semanas.

Cancelación

Renovaciones, retención y borrado deben estar claros.

Cómo comparar alternativas de forma equivalente

La comparación debe utilizar una matriz común.

Descalificación

Una alternativa que incumple un requisito obligatorio no debería compensarlo con muchas funciones secundarias.

Ponderación previa

Los pesos deben definirse antes de puntuar para evitar favorecer la opción preferida.

Evidencia

Cada puntuación debe indicar si procede de contrato, demostración, prueba o declaración comercial.

Cuándo conviene realizar una prueba piloto

Es especialmente útil cuando:

• la integración es compleja;
• la adopción es incierta;
• el volumen es elevado;
• existen datos críticos;
• la migración es costosa;
• el contrato es largo;
• el proveedor es nuevo;
• el rendimiento no está demostrado.

Alcance

Debe probar un proceso real con usuarios y datos representativos.

Criterios

Tiempo, errores, integración, soporte, facilidad y exportación.

No confundir demostración y piloto

La demostración utiliza un entorno preparado por el vendedor. El piloto verifica condiciones propias.

Ficha de decisión para dirección

Una compra importante debería resumirse en una página:

• Necesidad: problema que se resuelve.
• Resultado: mejora medible.
• Alcance: usuarios, procesos y datos.
• Alternativas: incluida no comprar.
• Coste total: periodo y supuestos.
• Riesgos: principales y mitigaciones.
• Dependencias: técnicas y externas.
• Implantación: responsable y calendario.
• Continuidad: recuperación y alternativa.
• Salida: datos, coste y plazo.
• Criterio de éxito: cuándo se considerará lograda.
• Decisión: aprobar, probar, posponer o rechazar.

Semáforo de riesgo de una compra tecnológica

Verde

• problema bien definido;
• requisitos verificados;
• coste total conocido;
• datos exportables;
• responsables claros;
• piloto satisfactorio;
• plan de salida razonable.

Ámbar

• integración pendiente;
• adopción incierta;
• costes futuros poco claros;
• dependencia elevada pero mitigable;
• capacidad no probada.

Rojo

• la compra busca una solución sin problema definido;
• el proveedor controla cuentas críticas;
• no existe exportación útil;
• no se sabe quién mantendrá;
• no hay alternativa ni recuperación;
• el contrato impide una salida asumible;
• los requisitos se basan solo en publicidad.

Preguntas que deben hacerse al proveedor

1. ¿Qué requisitos concretos cumple y cuáles no?
2. ¿Qué costes no están incluidos?
3. ¿Cómo crecerá el precio?
4. ¿Qué versiones y sistemas son compatibles?
5. ¿Cómo se integrará?
6. ¿Dónde se almacenan los datos?
7. ¿Cómo se exportan?
8. ¿Qué ocurre al cancelar?
9. ¿Qué disponibilidad ofrece?
10. ¿Cómo se recupera?
11. ¿Qué soporte está incluido?
12. ¿Quién será propietario de las cuentas?
13. ¿Durante cuánto tiempo tendrá soporte?
14. ¿Qué referencias comparables existen?
15. ¿Puede probarse con un caso real?
16. ¿Qué trabajo debe aportar la empresa?
17. ¿Qué subcontratistas o terceros intervienen?
18. ¿Cómo se notifican cambios e incidentes?

Ejemplo aplicado a una pequeña empresa

Una empresa de diez personas quiere comprar un nuevo sistema de gestión porque prepara informes manualmente.

Situación

• 20 horas mensuales de consolidación;
• tres hojas con datos duplicados;
• dos errores mensuales;
• una única persona conoce el proceso.

Alternativas

1. mejorar la hoja existente;
2. desarrollar una automatización;
3. comprar una aplicación especializada;
4. implantar un ERP completo.

Resultado requerido

Reducir a cinco horas mensuales, mantener trazabilidad y permitir que dos personas ejecuten el proceso.

Decisión

El ERP ofrece más funciones, pero introduce mayor coste, migración y formación. La aplicación especializada cumple el objetivo y permite exportar. Se aprueba un piloto con dos meses de datos.

La dirección no ha elegido la opción con más funciones, sino la que resuelve el problema con un compromiso proporcionado.

Ejemplo aplicado a una empresa de formación online

Una empresa quiere cambiar de LMS para vender más cursos y mejorar la experiencia.

Información necesaria

• número de alumnos actuales y previstos;
• usuarios simultáneos;
• tipos de contenido;
• volumen de vídeo;
• métodos de pago;
• facturación;
• certificados;
• soporte;
• exportación de alumnos y progreso;
• integración con correo;
• protección de datos;
• copias;
• entorno de pruebas;
• coste por alumno;
• salida futura.

Riesgo de plataforma única

Si el LMS concentra web, pago, alumnos, contenido y comunicación, una incidencia afecta a toda la empresa.

Contenido maestro

Los materiales fuente deben conservarse fuera del LMS para poder migrar.

Piloto

Un curso real permite probar matrícula, pago, acceso, progreso, correo, soporte y exportación.

Decisión

La plataforma debe evaluarse como infraestructura de entrega y no únicamente por su interfaz visual.

Errores frecuentes de dirección

Comprar por moda

La tendencia no demuestra necesidad.

Elegir por precio inicial

Ignora implantación, soporte y salida.

Delegar toda la decisión al proveedor

El proveedor conoce su producto, no todas las prioridades de la empresa.

Exigir muchas funciones

Puede aumentar coste y complejidad sin aportar valor.

No consultar a usuarios

Genera rechazo y requisitos omitidos.

No asignar responsable

La compra se queda sin implantación real.

Confiar en la demostración

No prueba datos, carga ni integración propias.

No comparar con no comprar

Una mejora de proceso puede ser suficiente.

No planificar salida

La dependencia se descubre demasiado tarde.

Comprar antes de ordenar datos

La nueva plataforma recibe el desorden existente.

No medir el resultado

La empresa no sabe si la inversión funcionó.

Proceso de decisión en diez pasos

1. Definir el problema.
2. Medir la situación actual.
3. Establecer resultados y requisitos.
4. Identificar usuarios, datos y dependencias.
5. Considerar alternativas, incluida no comprar.
6. Calcular coste total y riesgo.
7. Comparar opciones con la misma matriz.
8. Realizar piloto cuando proceda.
9. Aprobar implantación, responsable y salida.
10. Medir después de la puesta en marcha.

Cuando la compra afecta a infraestructura crítica, conviene partir de una auditoría de la infraestructura informática existente.

Lista de comprobación

• ¿El problema está definido sin mencionar una marca?
• ¿Se conoce el coste actual?
• ¿Se ha calculado el coste de no actuar?
• ¿El resultado es medible?
• ¿Los usuarios están identificados?
• ¿Los requisitos obligatorios están separados?
• ¿Se ha comprobado compatibilidad?
• ¿Se conocen dependencias nuevas?
• ¿Los datos y su ubicación están identificados?
• ¿Existe exportación útil?
• ¿Se conoce la retención al cancelar?
• ¿Las cuentas quedarán bajo control empresarial?
• ¿Se han revisado seguridad y permisos?
• ¿Existe copia y recuperación?
• ¿Se conoce el impacto de una caída?
• ¿Se ha analizado dependencia del proveedor?
• ¿El coste total utiliza un periodo común?
• ¿Se incluyen horas internas?
• ¿La implantación tiene responsable?
• ¿Existe plan de migración?
• ¿Existe vuelta atrás?
• ¿La adopción tiene formación y soporte?
• ¿Se ha proyectado capacidad?
• ¿Se conoce el fin de soporte?
• ¿Existe plan de salida?
• ¿Las alternativas se comparan con los mismos criterios?
• ¿Se ha realizado piloto si el riesgo lo requiere?
• ¿Existe criterio de éxito?
• ¿Se ha definido cuándo revisar la decisión?

Preguntas frecuentes

Conclusión

Antes de comprar tecnología, un director debe conocer mucho más que el precio y la lista de funciones.

La decisión empieza al definir el problema, medir la situación actual y establecer un resultado observable. Después deben analizarse usuarios, requisitos, compatibilidad, datos, seguridad, continuidad, proveedor, coste total, implantación, adopción y salida.

La mejor compra no es la herramienta más potente ni la más conocida, sino la solución que aporta la capacidad necesaria con un coste, una complejidad y una dependencia asumibles.

Dirección no tiene que elegir configuraciones técnicas, pero sí exigir que las alternativas se comparen de forma equivalente y con evidencias. Las afirmaciones comerciales no sustituyen una prueba, un contrato ni una estimación completa.

El plan de salida es una de las mejores pruebas de calidad de la decisión. Si la empresa no puede explicar cómo recuperará datos, sustituirá integraciones y abandonará el servicio, está aceptando una dependencia que todavía no comprende.

La compra también necesita un responsable, un calendario, formación y criterios de éxito. Sin implantación y adopción, la tecnología se convierte en otra suscripción o equipo infrautilizado.

Para una pequeña empresa, este proceso puede resumirse en una ficha de una página. No necesita burocracia, pero sí preguntas incómodas antes de firmar y medición después de poner en marcha.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para profundizar en infraestructura, sistemas, datos, seguridad, automatización y toma de decisiones tecnológicas.