Recientemente, tuve una conversación con alguien de Oracle que contó el caso de un posible cliente de CRM que se les escapó. Oracle había superado a Salesforce, Microsoft, etc., y estaba a punto de cerrar la venta. Sin embargo, el cliente decidió no comprar, sino seguir desarrollando su propio sistema de CRM.

Este cliente se enfrentó a la pregunta de construir o comprar y decidió construir. Siempre es una pregunta difícil de responder, ya que es demasiado fácil tomar la decisión equivocada. Hay dos respuestas a esta pregunta:

1. Tomar una decisión emocional que “se siente bien”.
2. Tomar una decisión racional basada en datos.

La mayoría de las decisiones son una mezcla de los dos extremos, pero muchas empresas se inclinan demasiado hacia la dirección emocional. ¡Cuando hay datos duros disponibles, tomar una decisión emocional no es una buena práctica empresarial!

La mayoría de las organizaciones tienen un nivel relativamente bajo en la Escala de Madurez de Selección de Software. Por lo general, comienzan con hojas de cálculo, pero a medida que avanza el análisis, se hacen evidentes las limitaciones de las hojas de cálculo. También se dan cuenta de la cantidad de trabajo involucrado y carecen de una idea clara de cómo proceder. Al final, pueden hacer un análisis muy general, pero en el fondo es una decisión emocional basada en lo que “se siente mejor”. La decisión final a menudo la toma un comité, y eso tiene sus propios problemas.

Una decisión racional de construir o comprar comienza con requisitos bien definidos. Luego, se evalúan los productos potenciales para medir qué tan bien cumplen con esos requisitos. Si estás considerando reemplazar un producto hecho a medida, inclúyelo en la evaluación. Por lo general, vale la pena comenzar un nuevo proyecto de software empresarial con una evaluación, incluso si el resultado final es un proyecto de desarrollo.

Entonces, ¿cómo se puede responder a la pregunta de construir o comprar de manera racional sin verse abrumado por todo el trabajo?

Requisitos

El atractivo de construir software es que se pueden satisfacer todos los requisitos, pero eso es una ilusión. Las limitaciones de recursos significan que la codificación debe priorizarse y algunos requisitos nunca se cumplirán. Además, es posible que el equipo no comprenda completamente el dominio del problema y no descubra requisitos desconocidos.

Comienza con una herramienta diseñada para la evaluación y selección de software, como la aplicación gratuita Wayferry. Para descubrir todos los requisitos, incluso los desconocidos, utiliza la técnica de ingeniería inversa de características en requisitos. Comienza con el código hecho a medida para desarrollar una línea de base y luego realiza ingeniería inversa de los productos de reemplazo potenciales. Esto construye una lista completa de requisitos que incluye los desconocidos. Ten en cuenta que vale la pena el esfuerzo de cargar los requisitos al principio porque esto reduce los riesgos generales del proyecto.

Una vez que la lista de requisitos esté completa, esos requisitos deben clasificarse por importancia. Esto tiene el beneficio adicional de generar el apoyo de las partes interesadas. El resultado de este ejercicio es un perfil de requisitos completo que captura adecuadamente las necesidades de la organización. Utiliza el perfil de requisitos completo para crear las RFIs (o RFPs) que se enviarán a los proveedores. Diseña la RFI para maximizar la respuesta de los proveedores. No quieres perder la mejor opción de software porque ese proveedor no respondió. Califica las respuestas de los proveedores en la aplicación, que automáticamente realiza el análisis de brechas y calcula las puntuaciones de ajuste.

La decisión de construir o comprar

Una vez que tengas las puntuaciones de ajuste para el producto hecho a medida y los posibles reemplazos, puedes responder de manera racional a la pregunta de construir o comprar. Suponiendo puntuaciones de ajuste normalizadas donde el 100% significa que se cumplen todos los requisitos, si varios productos en la nube o listos para usar tienen una puntuación de ajuste del 80% o más, entonces comprar es la mejor opción. Si todos los productos comerciales tienen una puntuación inferior al 60%, hay otras tres posibilidades:

1. Reducir el alcance del proyecto eliminando ciertas funcionalidades.
2. Combinar un producto con un pequeño módulo de código personalizado.
3. Combinar dos o más productos comerciales.

Cada una de las opciones anteriores aumenta la puntuación de ajuste. Si ninguna de estas opciones funciona lo suficientemente bien, entonces construir la aplicación puede ser la mejor opción.

Conclusión

Si una organización tiene un equipo de desarrollo interno, siempre existe la presión de construir porque supuestamente pueden satisfacer todas las necesidades. Sin embargo, por mi experiencia y observación, generalmente es mucho más barato y rápido comprar que construir. Después de todo, si un problema se ha resuelto adecuadamente en un producto comercial, ¿por qué resolverlo nuevamente? ¿Por qué no centrarse en un problema nuevo y más interesante?

En este artículo, resumimos un proceso para tomar una decisión racional de construir o comprar. Si bien requiere un trabajo significativo para ejecutarse correctamente, los costos de tomar la decisión equivocada se sentirán durante años. Por otro lado, las consecuencias de la decisión correcta pueden resonar en la línea de fondo durante décadas o más.