El software casi nunca es el problema
Llevamos años entrando en proyectos que otros dejaron a medias. Y hay un patrón: cuando se pregunta qué falló, la respuesta suele ser técnica. La herramienta era mala, el proveedor no cumplió, la tecnología se quedó corta.
Casi nunca es cierto. En la mayoría de casos el software funcionaba. Lo que falló fue una decisión de negocio tomada antes de escribir una línea de código, o una decisión organizativa tomada después de entregarlo.
Estos son los siete errores que más caros salen, ordenados por lo que hemos visto costar.
1. Digitalizar el proceso malo
El más caro de todos, con diferencia.
Una empresa tiene un proceso que se ha ido complicando durante quince años: un presupuesto que pasa por cuatro manos, tres aprobaciones, dos hojas de cálculo y un correo. Y encarga un sistema que replique exactamente eso.
El resultado es un proceso igual de malo, ahora más rígido y más caro de cambiar. Antes, si alguien quería saltarse un paso, lo hacía. Ahora no puede.
Cómo evitarlo: antes de definir el sistema, preguntar por cada paso "¿por qué existe?". Un porcentaje sorprendente de pasos existe porque alguien que ya no trabaja aquí tuvo un problema en 2014. Simplificar el proceso primero, y luego automatizarlo, cuesta menos y da mejor resultado.
2. No decidir quién manda
Un proyecto de software genera decenas de decisiones pequeñas: qué campos son obligatorios, quién ve qué, qué pasa cuando falta un dato.
Si no hay una persona con autoridad para decidir, cada una de esas preguntas se convierte en una reunión. El proyecto se alarga por indecisión, no por complejidad técnica.
Cómo evitarlo: designar un responsable con capacidad real de decidir, aunque después consulte. Un proyecto con un interlocutor claro va al doble de velocidad que uno con un comité.
Andie recomienda
Si en tu empresa la persona que decide sobre el proyecto no es la que lo va a usar, junta a las dos en las mismas reuniones desde el principio. La combinación de un directivo que decide sin usarlo y un usuario que lo sufre sin decidir es la receta más fiable para un sistema que nadie quiere.
3. Pensar que la formación es opcional
Se invierte en construir la herramienta y se despacha la formación con un correo y un manual PDF.
Después el equipo sigue usando Excel "porque es más rápido", y a los seis meses alguien concluye que el sistema no funcionaba. Funcionaba: nadie aprendió a usarlo.
Cómo evitarlo: presupuestar la formación como parte del proyecto, hacerla con datos reales de la empresa y no con ejemplos genéricos, y repetirla a las dos o tres semanas, cuando ya han aparecido las dudas de verdad.
4. No poner fecha de corte
Relacionado con el anterior y suficientemente grave como para ir aparte.
Cuando el sistema nuevo convive indefinidamente con el método antiguo, gana el antiguo. Siempre. Porque es lo conocido y porque en un día de trabajo con prisa nadie experimenta.
Cómo evitarlo: fecha de corte clara, comunicada con antelación y sostenida. A partir de tal día, los datos nuevos van solo al sistema. Con un periodo en paralelo corto, dos o tres semanas, no seis meses.
5. Comprar por funcionalidades en lugar de por problema
Las comparativas de software se hacen con listas de características. Gana el que tiene más casillas marcadas.
El problema es que el 80% de esas funcionalidades no las vas a usar nunca, y las que de verdad necesitas suelen ser específicas de tu forma de trabajar, que es justo lo que no aparece en ninguna lista.
Cómo evitarlo: definir tres o cuatro situaciones reales de tu negocio y pedir que te las enseñen resueltas. No una demo genérica: tu caso, con tus datos. Es asombroso cuántas herramientas impecables sobre el papel se caen en ese ejercicio.
6. Ignorar quién va a mantenerlo
Un sistema entregado no es un sistema terminado. Necesita actualizaciones de seguridad, cambios cuando cambia la normativa y alguien que responda cuando algo se rompe.
Cuando eso no se piensa de antemano, pasa lo previsible: el sistema se queda sin actualizar, acumula deuda técnica y a los tres años hay que rehacerlo entero. El coste de no mantener siempre acaba siendo mayor que el de mantener.
Cómo evitarlo: tratar el mantenimiento como una partida del presupuesto anual desde el primer día, y tener claro qué incluye. Las preguntas concretas están en el artículo sobre qué preguntar antes de contratar software a medida.
7. No medir nada antes de empezar
Si no sabes cuánto tardabas antes, no vas a poder demostrar que ahora tardas menos. Y sin esa prueba, el proyecto se percibe como un gasto y no como una inversión, lo que condiciona todo lo que quieras hacer después.
Cómo evitarlo: medir dos o tres cosas antes de tocar nada. Cuánto se tarda en emitir un presupuesto, cuántos errores de facturación hay al mes, cuánto tiempo se dedica a copiar datos. Son datos que se recogen en una semana y valen oro cuando llega el momento de justificar la siguiente fase.
Andie recomienda
Guarda la medición inicial por escrito y con fecha, aunque sea una nota de cuatro líneas. La memoria es tramposa: seis meses después todo el mundo recordará que "antes tampoco tardábamos tanto". Con el número anotado, la conversación es distinta.
El patrón común
Si miras los siete, ninguno es técnico. Todos tienen que ver con decisiones, personas y disciplina.
Esa es también la buena noticia: son errores que puedes evitar tú, antes de contratar a nadie y sin conocimientos técnicos. Un proyecto con el proceso simplificado, un responsable claro, formación presupuestada, fecha de corte, criterio de compra por problema, mantenimiento previsto y una medición inicial tiene una probabilidad de éxito muy alta, casi con independencia del proveedor.
Y al revés: sin eso, el mejor equipo de desarrollo del mundo te entregará algo que nadie usará.
Cómo trabajamos nosotros esto
En AndorraDev, la primera conversación de un proyecto no va de tecnología. Va de qué proceso duele, quién decide, cómo sabremos que ha funcionado y quién lo va a mantener después. Es menos vistoso que enseñar pantallas, y es lo que determina si el proyecto sirve.
Si estás pensando en digitalizar algo y quieres empezar por las preguntas correctas, escríbenos.
