Desarrollar o comprar: cómo decidirlo con honestidad

La pregunta se plantea como una comparación de presupuestos y por eso se decide mal. Coste de licencia frente a coste de desarrollo omite casi todo lo que importa.

Compre cuando el proceso es corriente

Contabilidad, nóminas, correo, gestión de clientes, tickets de soporte. Miles de empresas hacen esto de forma casi idéntica. Un producto empaquetado ha absorbido años de casos límite en los que usted no ha pensado, y viene con contrato de soporte, hoja de ruta de cumplimiento y los informes de error de otros.

Construir su propia versión de un problema resuelto es pagar por redescubrirlo.

Desarrolle cuando el proceso es el diferencial

Si su manera de hacer algo es por lo que le eligen los clientes, el software empaquetado le hará mediocre en eso. Señales de que está en ese terreno:

• Su equipo mantiene hojas de cálculo elaboradas para sortear el producto que compró
• Paga once módulos y usa dos
• Sus competidores no pueden copiar fácilmente esa parte de su operación
• El flujo de trabajo sencillamente no existe en ningún producto, porque lo inventó usted

Los costes que oculta cada opción

Comprar oculta: precios por usuario que escalan mal, integración entre productos, subidas anuales, coste de migración cuando se le quede pequeño y la restricción de una hoja de ruta que no controla.

Desarrollar oculta: mantenimiento para siempre, el riesgo de depender de un solo desarrollador, parcheado de seguridad, el segundo sistema que nadie presupuestó y el hecho de que la versión uno es aproximadamente el cuarenta por ciento del coste total de vida.

La respuesta que necesitan casi todas

Compre las partes corrientes. Desarrolle la capa fina que es genuinamente suya. Intégrelas bien.

Eso suele significar un sistema contable empaquetado, un CRM empaquetado y una aplicación a medida para el flujo específico de su negocio, conectados mediante integraciones y no mediante personas copiando datos.

Antes de encargar nada

Escriba qué hace hoy el proceso, con todas sus excepciones. Si ese documento es corto y anodino, compre algo. Si es largo, lleno de criterios y describe algo que ningún fabricante vende, desarróllelo, y presupueste su mantenimiento.

Trabajamos esto en los proyectos de desarrollo de software.