Guía

7 errores que cometen las pymes al comprar software a medida

El software a medida puede ser el dinero más inteligente que gasta una pequeña empresa, o el más doloroso. La diferencia casi nunca está en el código. Está en siete errores evitables que la gente comete antes de escribir una sola línea.

Have a nice dayHave a nice day13 min de lectura
7 errores que cometen las pymes al comprar software a medida

La mayoría de las pequeñas empresas que salen escaldadas de un proyecto de software a medida no lo hacen por culpa de malos programadores. Salen escaldadas semanas antes de que empiece la programación: en una reunión de arranque, en un hilo de correo, en un apretón de manos, por una decisión que entonces parecía menor. Cuando llega el código, el error ya está cocinado dentro. La buena noticia es que estos errores se repiten de forma aburridamente predecible, lo que significa que son evitables si sabe reconocerlos.

He visto muchos de estos proyectos desde dentro, a ambos lados de la mesa. Algunos se convirtieron en herramientas sin las que una empresa no se imaginaba trabajar. Otros acabaron en una pantalla de acceso a medio terminar, una tensa disputa por una factura y un fundador jurando que nunca volverá a apostar por lo personalizado. Lo frustrante es lo poco que separaba a unos de otros. La tecnología rara vez era el problema. Las decisiones en torno a la tecnología casi siempre lo eran.

Así que estos son los siete errores que veo una y otra vez cuando una pequeña empresa encarga software a medida. Ninguno requiere formación técnica para evitarlo. Solo hace falta saber que existen antes de firmar nada.

Error 1: comprar una solución antes de entender el problema

El error más caro ocurre primero, y suena inofensivo: «Necesitamos una aplicación que haga X». Cuando alguien lo dice en voz alta, casi siempre ya ha decidido la forma de la solución (un panel, un portal, una app móvil) sin que nadie haya escrito el problema real en lenguaje llano. El desarrollo entrega entonces fielmente lo equivocado, y con buen acabado.

El buen software parte de un enunciado del problema, no de una lista de funciones. «Nuestro equipo de oficina vuelve a teclear cada pedido del correo en el sistema de contabilidad, y eso ocupa a dos personas media jornada» es un problema. «Necesitamos un CRM a medida» es una suposición sobre una solución a un problema que nadie se molestó en nombrar. Lo primero puede resolverse de forma barata y medirse. Lo segundo es una invitación abierta a gastar dinero.

La dueña de una pequeña empresa y un desarrollador de pie frente a una pizarra, la dueña señalando un mapa dibujado a mano de un flujo de trabajo real y caótico en lugar de un boceto de pantalla, luz cálida de oficina
La hora más barata que invertirá en software a medida es la que dedique a mapear el problema real, antes de que nadie diseñe una pantalla.

Error 2: intentar construirlo todo a la vez

El software a medida parece una compra de una vez por década, así que la gente intenta meter una década de deseos en la versión uno. Cada departamento añade una petición. A cada «ya que estamos» se le dice que sí. El alcance se infla, el plazo se triplica y el proyecto se hunde bajo su propia ambición mucho antes de que nadie llegue a usarlo.

Las empresas que tienen éxito hacen lo contrario. Eligen la porción más dolorosa del problema y construyen eso primero: una cosa real, en funcionamiento y en producción en un par de meses. Luego dejan que el uso real les diga qué viene después. Esto no solo es más barato; es más seguro. Aprende si la idea funciona mientras la apuesta sigue siendo pequeña, en vez de descubrir, tras seis meses y una factura abultada, que diseñó lo equivocado.

Una cosa pequeña que está terminada y se usa a diario vale más que una cosa grande que está al 80 % y muere en silencio en un servidor de pruebas.
lo que le digo a cada cliente que me entrega una lista de deseos de 40 puntos

Debajo de esto hay una verdad incómoda: usted todavía no sabe qué necesita. Nadie lo sabe al principio. Su comprensión del problema cambiará en el momento en que personas reales toquen una herramienta real. Construirlo todo de antemano fija sus conjeturas más tempranas y peor informadas. Construir por porciones lo mantiene flexible, y mantiene el presupuesto bajo control mientras sigue aprendiendo.

Error 3: elegir solo por el precio

Pide tres presupuestos. Uno es muchísimo más barato que los demás. Alivio: se queda con ese. Esta es una de las formas más fiables de convertir un proyecto pequeño en uno caro, porque el presupuesto barato casi nunca significa que el trabajo sea más barato. Suele significar que las dos partes entendieron el encargo de forma distinta.

Una cifra baja a menudo indica una de varias cosas: el proveedor calculó por debajo porque no preguntó lo suficiente, planea sacar su margen más tarde con peticiones de cambio, o es inexperto y aún no sabe lo que no sabe. Ninguna acaba bien para usted. El precio de portada es la cifra menos útil de la propuesta. Lo que importa es si el proveedor entiende con claridad su problema, hace preguntas incómodas y es honesto sobre lo que no está incluido.

Error 4: olvidar que el software no es una compra única

El software a medida se vende, y se compra, a menudo como un mueble: paga una vez, lo tienes para siempre. No es así. El software vive en un mundo en movimiento: los sistemas operativos se actualizan, los navegadores cambian, llegan parches de seguridad, su negocio evoluciona, las herramientas con las que se conecta cambian sus reglas. Una herramienta que nadie mantiene deja poco a poco de funcionar, y luego se rompe en el peor momento posible.

Esto golpea con dureza a las pequeñas empresas porque el coste de mantenimiento es invisible al firmar. Compara dos presupuestos por el precio de construcción y nunca hace la pregunta que más importa: ¿cuánto cuesta mantener esto vivo y sano cada año? Alojamiento, actualizaciones, pequeñas correcciones, algún cambio ocasional a medida que su negocio evoluciona: planifíquelo como una partida normal y continua, igual que hace con el seguro o la contabilidad. Suele ser modesto, pero solo si lo prevé.

Coste¿Evidente al firmar?Planifíquelo
Construcción inicialObviamente
Alojamiento e infraestructuraA vecesMensual, continuo
Actualizaciones de seguridad y arreglosRara vezPresupuestar cada año
Cambios a medida que creceRara vezCuente con ellos
Incorporación y formaciónCasi nuncaInclúyalo desde el día uno
Propiedad del código y los datosCasi nuncaAcuérdelo antes de empezar
Los costes que la gente recuerda frente a los que olvida.

Error 5: dejar los requisitos vagos y sin responsable

«Ustedes son los expertos, construyan algo bueno» suena generoso. En realidad, así es como los proyectos se desvían. Las personas que mejor entienden su negocio son usted y su equipo, no los desarrolladores. Si entrega un encargo difuso y desaparece, el proveedor rellena los huecos con sus mejores conjeturas, y descubrirá esas conjeturas en el peor momento: en la entrega, cuando cambiarlas es más caro.

Hay que cubrir dos roles de su lado, y las pequeñas empresas no suelen cubrir ninguno. El primero es un único responsable de decidir: una persona que puede decir que sí, zanjar desacuerdos entre departamentos y que no está demasiado ocupada para responder preguntas durante semanas. El segundo es la disposición a ser concreto en lo que importa: los casos límite, la excepción rara que su negocio siempre ha resuelto a mano, la regla que todos conocen pero nadie escribió. Eso es justo lo que el software tiene que acertar.

Una ilustración dividida: a un lado un camino recto y claro con un único responsable etiquetado, al otro un camino enredado y serpenteante con muchas personas tirando en direcciones distintas, estilo plano editorial limpio
Un responsable de decidir con autoridad mantiene el proyecto en marcha. Un comité sin dueño es donde los plazos van a morir.

Error 6: no preguntar de quién son el código y los datos

Este es el silencioso, y es el que más duele años después. Paga por software a medida y da por hecho que es suyo. Luego la relación con el proveedor se agria, o sube precios, o simplemente desaparece, y descubre que no puede moverse. No tiene el código fuente. Los datos viven en un sistema al que solo él accede. Toda su operación depende ahora de una empresa en la que ya no confía, y no tiene ninguna palanca.

Nada de esto requiere un abogado para evitarlo. Requiere tres preguntas sencillas hechas antes de empezar, mientras aún tiene todo el poder de negociación: ¿De quién es el código fuente cuando esto esté terminado? ¿Puedo exportar todos mis datos, en un formato usable, cuando quiera? Y si nos separamos, ¿con qué me quedo exactamente? Un socio serio responde a esto sin pestañear. Titubear aquí es la mayor señal de alarma de todo el proceso.

  • Consiga por escrito que el código fuente es suyo, o que tiene una licencia clara y justa sobre él.
  • Confirme que puede exportar sus propios datos en un formato estándar, cuando quiera, sin pedir permiso.
  • Asegúrese de que el trabajo está documentado lo suficiente como para que otro desarrollador pudiera retomarlo.
  • Evite la dependencia de tecnología propietaria cuando una tecnología sencilla y conocida haría el mismo trabajo.
  • Acuerde de antemano qué pasa con el alojamiento y las cuentas si algún día cambia de proveedor.

Error 7: tratar el lanzamiento como la meta

El software se entrega, funciona, todos respiran. Se declara terminado el proyecto. Seis meses después, la mitad del equipo ha vuelto en silencio a la vieja hoja de cálculo, y la cara herramienta nueva la usan dos personas para una sola cosa. La construcción tuvo éxito. La adopción fracasó, y son dos problemas completamente distintos.

La gente no se resiste a las herramientas nuevas por tonta o testaruda. Se resiste porque lo nuevo es desconocido y lo viejo todavía funciona, más o menos. Vencer eso exige un esfuerzo deliberado que nadie presupuestó: algo de formación, una razón clara de por qué el cambio les ayuda a ellos en concreto, alguien que responda las preguntas tontas sin juzgar durante las primeras semanas, y una decisión firme de retirar lo viejo para que no haya un refugio al que volver.

  1. 1
    Lance primero a un grupo pequeño
    Despliegue la herramienta entre unas pocas personas dispuestas antes que al equipo entero. Encontrarán las asperezas y se convertirán en sus defensores internos.
  2. 2
    Muestre la ganancia personal, no la de la empresa
    «Esto le ahorra dinero al negocio» no motiva a nadie. «Esto significa que dejas de teclear direcciones dos veces» suma a la gente.
  3. 3
    Designe a una persona de referencia para dudas
    Durante el primer mes, alguien se encarga de las preguntas tontas. La fricción de la primera semana es lo que mata la adopción para siempre.
  4. 4
    Apague de verdad lo viejo
    Mientras exista la vieja hoja de cálculo, la gente seguirá usándola. Cuando lo nuevo funcione, retire el refugio: con suavidad, pero con claridad.
Un pequeño equipo reunido alrededor de una pantalla durante una sesión de formación amistosa y práctica, una persona guiando a las demás, ambiente relajado y positivo, luz natural suave
El software se construye una vez. La adopción se gana en las primeras semanas: con formación, paciencia y una buena razón para cambiar.

Uniéndolo todo: la mentalidad del comprador

Relea esos siete y verá un hilo común recorriéndolos. Casi ninguno es técnico. Van de claridad, propiedad y mesura: conocer su problema antes de comprar, construir en pequeños pasos, juzgar a los proveedores por su comprensión más que por el precio, planificar para la vida de la herramienta y no solo para su nacimiento, mantenerse implicado, proteger su salida y tratar el lanzamiento como el comienzo del trabajo de verdad.

El software a medida es de verdad una de las mejores inversiones que puede hacer una pequeña empresa una vez que ha superado las herramientas estándar que todos comparten. Un sistema moldeado exactamente en torno a cómo trabaja usted, en lugar de forzar a su negocio a retorcerse alrededor del producto de otro, es una ventaja real y duradera. Las empresas que llegan ahí no son las de mayores presupuestos. Son las que evitaron los siete errores de arriba, y eso es cuestión de criterio, no de dinero.

¿Pensando en software a medida?

La conversación más valiosa suele ocurrir antes de construir nada, cuando averiguamos si de verdad necesita software a medida y, si es así, la versión más pequeña con la que merece la pena empezar. Sin presión y sin jerga.

Vea cómo desarrollamos software a medida

Preguntas frecuentes

¿Cuánto cuesta el software a medida para una pequeña empresa?
Varía enormemente, porque «software a medida» describe desde una pequeña herramienta interna hasta una plataforma completa. La pregunta más útil es cuánto cuesta la primera porción útil, y a menudo resulta sorprendentemente modesta si resiste la tentación de construirlo todo a la vez. Desconfíe de cualquier cifra que le den antes de que el proveedor haya entendido bien su problema, y recuerde incluir el alojamiento y el mantenimiento continuos, no solo la construcción.
¿Es mejor el software a medida que las herramientas estándar?
No automáticamente. El software estándar es más barato y más rápido cuando un producto estándar encaja con su forma de trabajar. Lo personalizado solo gana cuando su proceso es genuinamente específico, ha superado las herramientas compartidas, o coser varios productos se ha vuelto más doloroso que construir una sola cosa que encaje. Empiece por ser honesto sobre en qué situación está.
¿Cómo sé si un proveedor de software es bueno?
Observe cómo se comporta antes de que haya pagado nada. Un buen proveedor hace muchas preguntas, contradice peticiones caras o poco sensatas, es concreto sobre lo que no está incluido y responde sin titubear a las preguntas de propiedad sobre el código y los datos. Tenga cautela con quien está de acuerdo con todo y da una cifra segura en la primera reunión.
¿De quién es el código en un proyecto de software a medida?
De lo que acuerde al principio, que es justo por lo que debe acordarlo al principio. Si ha pagado por el trabajo, debería ser dueño del código fuente (o tener una licencia clara sobre él) y poder exportar todos sus datos cuando quiera. Resuélvalo antes de que cambie de manos el dinero, mientras todavía tiene el poder de negociación. Un socio serio lo pondrá por escrito.
¿Por qué fracasan tantos proyectos de software a medida?
Rara vez por el código. Fracasan porque el problema nunca se definió con claridad, el alcance intentó hacerlo todo a la vez, nadie del lado del cliente se responsabilizó de las decisiones, o la herramienta se lanzó sin plan para conseguir que la gente la usara de verdad. Son errores evitables de proceso y de criterio, no de tecnología, y esa es la parte alentadora.
Have a nice day
Have a nice day
Redacción

Have a nice day es un estudio de software que ayuda a las pequeñas y medianas empresas a digitalizarse — automatización, IA y software a medida que funciona en el día a día, no solo en las diapositivas.

Servicios relacionados