Software a medida frente a producto de catálogo: cómo decidir de verdad

Construimos software a medida, así que tome lo que sigue con el escepticismo que merece. Aun así es cierto que la mayoría de las empresas que nos hacen esta pregunta deberían comprar en vez de construir, y que quienes deberían construir suelen saber por qué antes de llamar: solo quieren que alguien les confirme que eso que no encuentran no existe.

La decisión suele plantearse como una cuestión de coste. Ese planteamiento es erróneo, porque los costes de las dos opciones tienen formas distintas. El software de catálogo tiene un coste bajo, cierto y recurrente, y un encaje incierto. Un desarrollo a medida tiene un coste alto, incierto y único, y un encaje que usted especifica. Comparar la primera cifra con la primera cifra no dice casi nada.

Las cuatro preguntas que lo deciden

Hágalas en este orden. La primera que dé una respuesta clara suele terminar la discusión.

1. ¿Es el proceso una ventaja competitiva o solo algo necesario?Las nóminas son necesarias. Nadie gana clientes por hacer las nóminas excepcionalmente bien, así que cómprelas. Cómo calcula el coste de un trabajo, cómo asigna un lote a un comprador o cómo planifica sus máquinas quizá sea realmente aquello con lo que compite, y meterlo en el flujo de trabajo de otro es la manera de dejar de competir con ello.
2. ¿Puede un producto de catálogo expresar su modelo de datos?No sus pantallas, sino su modelo. Si su stock tiene dos unidades que deben mantenerse ciertas a la vez, si la mercancía puede ser suya estando físicamente en otro sitio, si a un trabajador se le paga de tres formas distintas en el mismo mes, entonces un sistema con un solo campo de cantidad y una sola estructura salarial estará equivocado de una manera a la que la configuración no llega.
3. ¿Cuántos productos harían falta?Un buen producto de catálogo supera a un desarrollo a medida la mayoría de las veces. Cuatro productos más las hojas de cálculo que los unen, casi nunca: ha comprado cuatro problemas de encaje y ha construido un proyecto de integración sin llamarlo así.
4. ¿Quién será su dueño dentro de tres años?Un desarrollo a medida necesita a alguien que responda por él, ya sea un desarrollador interno, un contrato de mantenimiento u otro estudio. Si la respuesta honesta es «nadie», compre algo con contrato de soporte. El software a medida sin mantenimiento se convierte en un lastre más rápido que cualquier otra cosa sin mantenimiento.

Los costes que se pasan por alto en cada lado

Del lado del catálogo, la licencia recurrente es el coste visible y rara vez el mayor. Los costes ocultos son el precio por usuario que crece con la plantilla, los módulos que resultan ser productos aparte, el socio implantador, la subida anual, y el trabajo que hace su equipo para salvar la distancia entre lo que el software hace y lo que usted necesita, que es un coste de personal permanente que nunca aparece en la comparación.

El mayor coste del producto de catálogo suele ser el que nadie calcula: los procesos que usted cambia para encajar en el software. A veces es una ventaja, porque el proceso del producto es mejor que el suyo. A veces significa que sus mejores personas pasan la semana haciendo una introducción de datos que existe solo para tener contento al sistema.

Del lado del desarrollo a medida, la construcción es el coste visible y normalmente se estima con honestidad. Lo que se infravalora es la migración de datos, el funcionamiento en paralelo y los cambios del segundo año. La migración es casi siempre peor de lo que parece, porque los datos antiguos contienen una década de excepciones que nadie documentó. Un funcionamiento en paralelo no es opcional ni es gratis: alguien hace el trabajo dos veces durante un mes. Y el software que no puede cambiar es software que acabará sustituyendo, así que presupueste el cambio en lugar de tratarlo como un fracaso.

El híbrido que nadie propone

En la práctica el planteamiento rara vez es todo o nada, y la mejor respuesta suele ser comprar lo estándar y construir lo que diferencia. Conserve la contabilidad de catálogo como libro legal. Construya el sistema operativo que conoce su oficio, y haga que contabilice automáticamente.

Esto funciona porque pone la frontera en el sitio correcto. Las reglas contables son iguales para todos y cambian por ley; las reglas operativas son suyas y cambian cuando usted decide. Intentar que un solo sistema haga ambas cosas es lo que produce la peor versión de cada una.

Cuándo recomendamos comprar

Una necesidad estándar con un mercado maduro. Contabilidad para una empresa de una sola entidad, correo electrónico, nóminas de personal fijo, almacenamiento documental, un CRM general para un equipo pequeño que vende un producto sencillo. Esas categorías tienen productos pulidos durante décadas frente a miles de clientes. No podemos superarlos en doce semanas, y nadie más tampoco.

Un problema mal definido. Si el requisito no sobrevive a una conversación con quienes van a usarlo, un desarrollo producirá una versión cara de la confusión. Comprar algo barato y convivir con ello seis meses es una forma legítima de descubrir qué necesita realmente, y mucho más barata.

Sin responsable y sin presupuesto para el segundo año. Un desarrollo que nadie mantiene se degrada exactamente hasta el sistema heredado que el proyecto debía sustituir, solo que ahora es uno que únicamente tiene usted.

Cuándo construir es claramente lo correcto

Ha probado productos de catálogo y cada uno falló en el mismo punto. Ese punto suele ser su modelo de datos, y seguirá siendo el punto de fallo, porque es lo único que la configuración no puede cambiar.

El software es el producto, o es lo que el cliente experimenta. Nadie se diferencia con una plataforma a la que sus competidores también pueden suscribirse.

El trabajo de integración superaría al desarrollo. Cuando cuatro sistemas deben ponerse de acuerdo y la unión la hacen personas y hojas de cálculo, ya está pagando un sistema a medida, solo que en salarios en lugar de en software, y sin llegar a tener el software.

El cumplimiento normativo o la ubicación de los datos hacen realmente imposible la opción de catálogo. Esto es menos frecuente de lo que se afirma, así que compruebe si es una restricción real o una preferencia; pero cuando es real, es decisiva.

Cómo poner a prueba la decisión antes de comprometerse

• Escriba las tres cosas que hace su proceso actual y que cree que ningún producto de catálogo cubre. Luego dedique un día a intentar de verdad que un producto las haga. La mayoría de las objeciones no sobreviven a esto, y las que sobreviven son sus requisitos reales.
• Pida a cualquier proveedor una referencia de su sector concreto, y pregunte a esa referencia qué tuvo que cambiar en su forma de trabajar. La respuesta es la brecha de encaje, dicha por alguien sin incentivo para minimizarla.
• Calcule el producto de catálogo a tres años incluyendo la implantación, la subida anual y el tiempo del personal dedicado a salvar las carencias, no con el coste de licencia del primer año.
• Para un desarrollo, exija un plan por fases en el que haya algo real en producción antes de tres meses. Si la primera entrega es en el mes nueve, el riesgo se está aplazando, no gestionando.

La versión corta

Compre lo estándar. Construya aquello con lo que compite, si tiene a alguien que se haga cargo. Desconfíe de cualquiera —nosotros incluidos— que responda a esta pregunta antes de entender su modelo de datos, porque ahí es donde vive realmente la respuesta.