Software de gestión empresarial: ahora hay que justificar por qué comprarlo

Cuando una empresa se plantea un sistema de gestión, la pregunta por defecto es cuál comprar. Construir aparece al final, como la opción exótica, y a quien la propone se le pide que la justifique.

Ese reparto de la carga de la prueba viene de un mundo que ya no existe.

Se consolidó cuando escribir software era lento y caro, y respondía correctamente a esa realidad. Un ERP propio significaba años de equipo y un resultado peor que lo que se compraba por una suscripción. Con esos costes, comprar era la decisión razonable en la mayoría de los casos.

Los números que sostenían ese razonamiento han cambiado, y la conclusión debería cambiar con ellos.

Qué ha cambiado, en concreto

No es una intuición de mercado, es una partida del presupuesto.

En cualquier desarrollo, la mayoría de las horas se iban en lo repetitivo: las pantallas, los formularios, las validaciones, los conectores, las pruebas. Ninguna de esas tareas era técnicamente difícil, pero todas eran lentas, y la lentitud es lo que encarecía el proyecto.

Esa parte cuesta hoy una fracción de lo que costaba. Un equipo que trabaja con generación asistida entrega en semanas lo que antes llevaba trimestres, y la diferencia no es marginal.

Lo que no ha cambiado es donde reside ahora el coste: entender vuestro negocio, decidir qué queréis exactamente, limpiar los datos que vais a meter dentro y acordar quién manda sobre las reglas. Eso sigue costando reuniones y sigue siendo lo que hunde los proyectos.

La consecuencia práctica es que el umbral se ha movido hacia abajo mucho más de lo que el mercado ha asimilado. Organizaciones que hace cinco años no se lo habrían planteado por presupuesto pueden sostener hoy un sistema propio, y el tamaño a partir del cual la cuenta sale ha bajado de forma considerable.

Si esa evaluación se hizo hace unos años y el resultado fue negativo, conviene rehacerla, porque los supuestos de partida han dejado de ser ciertos.

Las cuatro razones que todavía justifican comprar

Invertir la carga de la prueba no equivale a construirlo todo. Equivale a exigir un motivo para comprar, y existen cuatro que lo son.

1. Que la especificación sea ajena y se mueva. La normativa fiscal, las nóminas, los formatos de facturación verificable, los ficheros bancarios. No se compran porque sean complejos, se compran porque alguien de fuera los cambia cada año y no queréis estar persiguiendo esos cambios para siempre. Es la razón más sólida de las cuatro y la que abarca menos superficie de lo que suele suponerse.

2. Que lo que compráis sea acceso a una red, no software. Una pasarela de pago, un operador de firma, un comparador que agrega oferta de terceros. En esos casos el producto es la red, y una red no se construye.

3. Que lo que compráis sean los datos. Cartografía, bases de solvencia, catálogos sectoriales. El software que los explota es secundario.

4. Que alguien asuma una responsabilidad que vosotros no queréis. Certificaciones, custodia con valor probatorio, cumplimiento con auditoría detrás. Se adquiere el respaldo, no el programa.

Si lo que estáis a punto de contratar no encaja en ninguna de las cuatro, la pregunta pertinente deja de ser por qué construirlo y pasa a ser por qué no hacerlo.

Los tres argumentos de siempre, revisados

Al cambiar de lado la carga de la prueba, los tres motivos que se dan por válidos merecen revisión.

«El producto ya está probado por miles de empresas». Es cierto y es una ventaja real en lo que es igual para todas. Deja de serlo en cuanto el proceso es vuestro, porque entonces esas miles de empresas no han probado lo que vosotros necesitáis, han probado otra cosa. El argumento vale exactamente donde valen las cuatro razones de arriba.

«Si lo construimos, quedamos atados a quien lo haga». La comparación suele establecerse contra un escenario ideal en lugar de contra la alternativa real. Con un producto estáis atados también, solo que al fabricante, y con una diferencia importante: del desarrollo propio os podéis llevar el código y los datos, y del producto no. El riesgo existe, pero es menor que el que ya tenéis, y además se acota por escrito.

«El mantenimiento nos va a consumir». Todo sistema que sostiene una operación hay que mantenerlo, incluido el comprado. Lo que pasa es que ahí el mantenimiento va dentro de la suscripción y nadie lo contabiliza. Al construir se vuelve una partida visible, y por eso parece un coste nuevo cuando lo que es, en realidad, es el mismo coste dejando de estar escondido. Y si modificar código es hoy mucho más barato, modificar lo vuestro también lo es.

De los tres argumentos, solo el primero resiste íntegro, y únicamente dentro de su ámbito.

Lo que cuesta comprar y no sale en el presupuesto

La comparación habitual pone el precio de la suscripción contra el coste de un desarrollo y da por cerrada la discusión. Faltan tres partidas, y las tres crecen con el tiempo.

Vuestra operativa se estandariza. Es la partida más costosa y la que no se percibe el primer año. Un producto admite lo que admite, así que las particularidades que os diferenciaban se van limando porque no caben. A los dos años no trabajáis como decidisteis trabajar, sino como permite el fabricante, igual que el resto de sus clientes. Buena parte de lo que hace defendible a una empresa está justamente ahí.

El coste de salir crece todos los meses. La exportación devuelve tablas. No devuelve las automatizaciones, los campos calculados, los informes que alguien construyó ni el histórico con su contexto. Y no devuelve lo más caro: que vuestra gente ya trabaja de la manera que impone esa herramienta.

No tenéis palanca sobre el precio ni sobre el rumbo. La suscripción sube cuando el fabricante decide, la funcionalidad que necesitáis entra en su hoja de ruta o no entra, y una línea de producto se descontinúa sin pediros opinión. El riesgo de construir se discute con frecuencia. Este, que es el que ya estáis asumiendo, apenas se menciona.

Lo aplicamos en nuestra propia operación

Partimos de dos CRM, uno orientado a marketing y otro a ventas, con el mismo cliente registrado por duplicado y con criterios distintos. Unificamos en una sola herramienta y el resultado fue aceptable en todo y bueno en nada. Probamos después una alternativa de código abierto, que resolvía el coste recurrente pero imponía su propio modelo de datos. El sistema que utilizamos hoy es propio y está unido al backoffice de la compañía.

La diferencia entre defender esta tesis y haberla aplicado sobre la propia operación no es menor. El recorrido completo está en software de gestión de clientes.

Cómo decidir ahora

No se trata de elegir entre comprarlo todo o construirlo todo, sino de alterar el orden en que se plantea la decisión.

1. Listad los procesos que el sistema tiene que sostener. Los que se ejecutan realmente, no los que figuran en el organigrama.
2. Pasad cada uno por las cuatro razones. ¿Tiene una especificación ajena que se mueve? ¿Es acceso a una red? ¿Son los datos? ¿Hay una responsabilidad que no queréis asumir?
3. Lo que supere el filtro, se contrata. Habitualmente son contabilidad, nóminas, la pasarela de pago y poco más.
4. Lo que no lo supere es candidato a desarrollarse internamente. Habitualmente es más de lo previsto.
5. Acordad el mantenimiento antes de empezar, con un equipo interno, con un proveedor o con los dos. Es la única condición que de verdad hace falta.

Lo que esto no significa

La tesis tiene tres límites, y conviene enunciarlos con la misma precisión.

No significa empezar por el sistema entero. Un ERP que cubra todos los departamentos a la vez es un proyecto grande en cualquier época. Se empieza por el proceso que más duele y se crece desde ahí.

No sustituye a la decisión de negocio. Si nadie en la empresa quiere determinar cómo debe funcionar un proceso, el desarrollo no lo determinará en su lugar, y el resultado será un producto de catálogo peor construido.

No lo convierte en gratuito. Es considerablemente más barato que antes, lo cual no es lo mismo que barato. Siguen siendo necesarios la limpieza de datos, el acuerdo sobre las reglas y el mantenimiento de lo construido.

Lo que sí establece es que el argumento de que construir resulta caro y arriesgado ha dejado de sostenerse por sí mismo, y que quien lo emplee debería justificarlo en lugar de darlo por supuesto.

Si lo que os falla hoy es que los sistemas que ya tenéis no se hablan entre sí, eso está en integración de ERP con el resto de sistemas. Y si lo que entra son facturas, en cómo automatizar facturas con IA.