¿Comprar, integrar o desarrollar software? Marco de decisión a 5 años para una pyme de Houston

Una pyme de Houston casi nunca se enfrenta a una elección limpia entre comprar software o desarrollarlo desde cero. En la práctica, las opciones suelen ser tres: comprar un producto, comprarlo e integrarlo con otros sistemas, o crear una solución limitada alrededor de las herramientas que la empresa ya utiliza. La respuesta correcta depende menos del tamaño de la compañía que de dónde obtiene su margen, qué tan particular es su forma de trabajar y quién se hará cargo del sistema después del lanzamiento.

Esta guía propone una forma de comparar esas opciones a cinco años. Está pensada para dueños y responsables de operaciones que necesitan reemplazar hojas de cálculo, abrir un portal para clientes o personal de campo, conectar un ERP con un CRM, o convertir un proceso interno en software. No parte de la idea de que el desarrollo a la medida siempre gana. En muchos casos, un producto maduro con una capa pequeña de integración cuesta menos y presenta menos riesgo.

Empiece por la limitación del negocio, no por la categoría de software

Antes de revisar proveedores o pedir estimaciones de desarrollo, describa la limitación en términos operativos. “Necesitamos un CRM” es demasiado amplio. “Los vendedores no pueden consultar el inventario actual ni los precios acordados con cada cliente mientras preparan una cotización” sí sirve. La segunda frase se puede comprobar, cotizar y relacionar con un resultado del negocio.

Una descripción breve del problema debe cubrir:

• las personas afectadas y el trabajo que intentan completar;
• la demora, el error, la captura duplicada o la falla de control actuales;
• los sistemas y datos involucrados;
• el resultado que justificaría la inversión;
• las restricciones que no se pueden negociar, como un ERP existente, un contrato con un cliente, un requisito de auditoría o una fecha de lanzamiento.

Este primer paso evita dos errores frecuentes. El primero es comprar una plataforma amplia porque la demostración se ve bien y descubrir después que el trabajo difícil sigue haciéndose por correo electrónico. El segundo es encargar software a la medida para un proceso que un producto estándar ya resuelve de manera adecuada.

La orientación federal también resulta útil para una empresa privada. Digital.gov describe una secuencia de investigación, solicitud y evaluación, y recomienda explorar las soluciones existentes antes de decidir qué adquirir.^[1] Una pyme puede aplicar la misma lógica sin adoptar un proceso de contratación gubernamental: investigar el mercado, definir el problema y los criterios de aceptación, y después evaluar pruebas en lugar de presentaciones comerciales.

Las tres opciones que realmente está comparando

“Integrar” merece su propia columna. Tratarlo como una variante menor de la compra oculta costos reales: límites de API, suscripciones de middleware, administración de identidades, manejo de errores, monitoreo, cambios de proveedores y soporte cuando dos empresas se atribuyen mutuamente la falla. Aun así, puede ser la mejor respuesta. Solo hay que estimarla como un sistema completo, no como un par de conectores.

Use una matriz ponderada antes de hablar de precio

Una matriz ponderada deja las suposiciones a la vista. No tomará la decisión por usted, pero evita que una demostración convincente o una estimación atractiva dominen la conversación.

Elija criterios que correspondan a la decisión concreta. Asigne ponderaciones que sumen 100. Califique cada opción del 1 al 5, donde 1 es deficiente y 5 es sólido. Después calcule:

Puntuación ponderada = suma de (ponderación del criterio × calificación de la opción) ÷ 100

El ejemplo siguiente describe a un distribuidor ficticio de Houston cuyo proceso de cotización requiere inventario en tiempo real, precios por cliente, reglas de aprobación e historial del CRM. Las calificaciones son ilustrativas. No son evaluaciones generales de comprar, integrar o desarrollar.

En este ejemplo, la integración gana por un margen pequeño. Eso no equivale a un veredicto. Una diferencia estrecha indica que el equipo debe comprobar las suposiciones capaces de cambiar el orden. Si el proveedor del ERP no admite las consultas de precios necesarias, la calificación de integración puede bajar. Si un producto comercial de cotización cubre las reglas de aprobación mejor de lo previsto, la compra puede pasar al primer lugar.

Califique con franqueza la “capacidad interna”. El software a la medida necesita una persona del negocio que pueda resolver dudas sobre políticas, revisar entregas y decidir qué no se va a construir. Si la empresa no puede dar autoridad y tiempo recurrente a una persona, debe reducir la calificación de la opción de desarrollo, por bueno que se vea el prototipo.

Calcule el TCO a cinco años, no solo la factura del primer año

El precio de compra y el costo de desarrollo son apenas las partidas visibles. Un modelo útil de costo total de propiedad, o TCO, a cinco años incluye implementación, trabajo interno, cuotas recurrentes, mantenimiento, cambios previstos, soporte operativo, riesgo y costo de salida.

Use esta estructura:

TCO a 5 años = adquisición o entrega inicial + implementación e integración + (costo mensual recurrente × 60) + (costo operativo interno anual × 5) + mantenimiento posterior a la garantía + presupuesto de cambios previstos + costo esperado del riesgo + costo de salida o migración − valor residual

El costo esperado del riesgo se puede estimar por evento:

Costo esperado del riesgo = probabilidad del evento × impacto financiero

No esconda la incertidumbre dentro de una cifra aparentemente exacta. Prepare un caso base y un rango razonable. La Guía de estimación y evaluación de costos de la Oficina de Responsabilidad Gubernamental de Estados Unidos presenta un proceso de 12 pasos y considera el análisis de riesgo e incertidumbre como parte de una estimación creíble.^[2] Una pyme de Houston no necesita un modelo federal de costos, pero sí debe documentar sus suposiciones, identificar qué impulsa el gasto y comprobar qué ocurre cuando esas suposiciones cambian.

Ejemplo de comparación del TCO a cinco años

Las cifras siguientes son hipótesis para un proyecto ficticio. No son referencias de mercado, cotizaciones ni precios típicos de Houston. Su función es mostrar las partidas que suelen quedar fuera del cálculo.

Las suposiciones detrás de esos totales importan más que los totales. El caso de compra supone una suscripción mensual de $1,800 y 0.15 del tiempo de un empleado de tiempo completo para administración. El caso de integración supone $1,500 al mes en productos, $600 al mes en middleware, cuatro años de mantenimiento a $18,000 y 0.2 del tiempo de un empleado. El caso de desarrollo supone $1,200 al mes en servicios de nube, cuatro años de mantenimiento equivalentes al 18% del costo inicial de desarrollo y una cuarta parte del tiempo de un responsable de producto. Cambie cualquiera de esos datos si no corresponde a la empresa.

Haga por lo menos estas pruebas de sensibilidad:

• el precio de la suscripción sube o el proveedor cambia sus paquetes;
• la implementación tarda más porque los datos o las reglas del negocio están incompletos;
• el volumen de transacciones, usuarios, ubicaciones o integraciones crece más rápido de lo previsto;
• una API del proveedor queda restringida, se reemplaza o se cobra por separado;
• la empresa necesita un segundo flujo de trabajo importante en el tercer año.

El desarrollo a la medida puede resultar más barato cuando las licencias recurrentes crecen con rapidez, el proceso cambia con frecuencia o el software sustituye varios productos. La compra puede seguir costando menos, incluso con un ajuste imperfecto, si el trabajo que falta aporta poco valor. El costo debe relacionarse con el proceso. Comparar solamente una licencia con una estimación de desarrollo produce una decisión incompleta.

Compruebe las afirmaciones de seguridad antes de comprometerse

La seguridad pertenece a la decisión de compra, no a un cuestionario que se envía cuando el contrato casi está cerrado. La guía Secure by Demand de CISA recomienda preguntar a los fabricantes de software por sus prácticas y solicitar pruebas verificables antes de comprar.^[3] La frase “seguridad de nivel empresarial” no constituye una prueba.

Para un producto comercial, pida detalles que correspondan al riesgo: controles de identidad y funciones, registros de auditoría, copias de seguridad y recuperación, aviso de incidentes, manejo de vulnerabilidades, exportación y eliminación de datos, subcontratistas e informes de evaluaciones independientes cuando proceda. Confirme qué controles están incluidos en el nivel cotizado. Algunos productos reservan los registros útiles, el inicio de sesión único o la configuración de retención para planes más costosos.

Para software a la medida, exija un método de desarrollo y operación en lugar de una promesa de “seguir las mejores prácticas”. El Marco de Desarrollo Seguro de Software de NIST organiza las prácticas en Preparar, Proteger, Producir y Responder.^[4] Esos grupos sirven para ordenar preguntas sobre la preparación del equipo, la protección del código y los entornos, la producción segura y la respuesta ante vulnerabilidades.

El Estándar de Verificación de Seguridad de Aplicaciones de OWASP ofrece requisitos verificables para los controles técnicos de una aplicación.^[5] Un proyecto puede seleccionar los requisitos adecuados para su riesgo e incluirlos en las pruebas de aceptación. Eso resulta más útil que escribir “seguro” en un contrato sin definir cómo se comprobará.

Si el sistema incluye una aplicación móvil, conviene separar los requisitos de seguridad de las preferencias de diseño. La guía de requisitos de seguridad para una app móvil de pequeña empresa ayuda a documentar controles y evidencias antes de firmar el alcance.

Tres situaciones comunes en Houston

1. Una empresa de servicio en campo que reemplaza hojas de despacho

Pensemos en una empresa de HVAC o mantenimiento comercial con 25 técnicos. Los despachadores programan el trabajo en una hoja compartida, los técnicos envían fotos por mensaje de texto y el personal de oficina vuelve a capturar los datos del servicio para facturar. El proceso causa problemas, pero no es raro.

Un producto de gestión de servicio en campo probablemente sea la primera opción que debe probarse. Tal vez ya incluya programación, órdenes de trabajo móviles, presupuestos, firmas, pagos y avisos para técnicos. Una integración pequeña con contabilidad o nómina puede resolver lo que falta. Desarrollar toda la plataforma obligaría a reproducir funciones maduras antes de mejorar la parte propia de la empresa.

La decisión puede cambiar si la compañía maneja historiales de activos poco comunes, formularios de cumplimiento específicos por cliente o reglas de rutas que los productos estándar no admiten. Incluso en ese caso, una pantalla personalizada para técnicos conectada a un sistema comprado puede ser más razonable que un reemplazo completo.

Si el proyecto gira alrededor del CRM, consulte la lista de verificación para implementar un CRM, disponible en inglés. Sirve para revisar responsabilidades, limpieza de datos, adopción, informes y preparación para el lanzamiento. Un sistema técnicamente correcto también falla cuando los registros de clientes y los hábitos diarios siguen siendo inconsistentes.

2. Un distribuidor industrial con cotizaciones complejas

Un distribuidor industrial de Houston puede vender inventario estándar y, al mismo tiempo, manejar precios por contrato, sustituciones, disponibilidad entre sucursales, reglas de flete y aprobaciones de gerencia. El CRM administra las oportunidades. El ERP sigue siendo la fuente de inventario y precios. Ninguno de los dos sistemas produce por sí solo una cotización utilizable.

Este caso es un candidato claro para integración. Una interfaz de cotización puede obtener datos controlados del ERP, registrar la actividad en el CRM y aplicar las reglas de aprobación. La empresa conserva sistemas maduros para contabilidad y gestión de clientes, mientras desarrolla únicamente la capa vinculada con su proceso de ventas.

La integración necesita una persona responsable, monitoreo, reglas de reintento y una ruta de soporte. Sin eso, se convierte en un conjunto de scripts que funciona hasta que cambia una API, el nombre de un campo o una regla de precios. El modelo a cinco años debe incluir mantenimiento y dependencia de proveedores, no solo la primera conexión. La guía de requisitos de integración para una app móvil de pequeña empresa ofrece preguntas útiles sobre datos, API, sincronización y fallas, incluso si la interfaz final no es exclusivamente móvil.

3. Una empresa de logística especializada con un proceso propio para clientes

Ahora considere una firma de logística especializada que coordina solicitudes de clientes, documentos regulados, entregas entre socios, aprobaciones de excepciones y actualizaciones de estado. Su servicio depende de cómo se conectan esos pasos. Los clientes perciben el proceso y la empresa lo modifica conforme cambian los contratos y las condiciones operativas.

El software comercial de transporte puede atender la contabilidad, el rastreo o las funciones de flota, pero el flujo del cliente y de las excepciones todavía podría ser una ventaja operativa de la empresa. Una aplicación a la medida puede tener sentido si la investigación demuestra que los productos disponibles obligan al personal a volver al correo electrónico, no pueden representar la lógica de aprobación o generan duplicación de datos inaceptable.

Eso no justifica una primera versión grande. Desarrolle el flujo completo más pequeño que permita comprobar adopción y beneficio operativo. Mantenga en los productos existentes las funciones comunes, como contabilidad y mensajería estándar, cuando sea práctico. Si los clientes usarán una aplicación móvil, defina desde el principio el acceso al código fuente, las cuentas de las tiendas, los derechos sobre los datos, la entrega y las responsabilidades de mantenimiento. El documento de requisitos para una app móvil de pequeña empresa ayuda a dejar esos términos por escrito.

Una ruta de validación de 90 días

La meta de los primeros 90 días no es terminar el sistema. Es sustituir suposiciones por pruebas antes de asumir el compromiso costoso.

Si el resultado apunta a contratar desarrollo externo, prepare una solicitud que dé a los proveedores suficiente contexto para proponer con responsabilidad. La guía para preparar un RFP de desarrollo de software, disponible en inglés, explica cómo describir el problema, las restricciones, el método de evaluación y el formato de respuesta sin fingir que todas las funciones ya están definidas.

Una vez elegido el método de entrega, incluya en el acuerdo el trabajo, las responsabilidades, los supuestos, el proceso para gestionar cambios y el método de aceptación. La guía de SOW para desarrollo de software, disponible en inglés, cubre ese paso. Antes del lanzamiento, adapte la lista de verificación de pruebas de aceptación de usuario, o UAT, también disponible en inglés, para que los usuarios del negocio comprueben el flujo real, los permisos, los informes y los casos de falla.

Qué puede invalidar la decisión

Un modelo solo es confiable en la medida en que lo sean sus suposiciones. Vuelva a abrir la decisión si cambia cualquiera de estas condiciones:

• un proveedor no puede demostrar un flujo obligatorio con datos representativos;
• falta una API, una exportación, un registro de auditoría o una función de identidad, o solo se vende en otro nivel;
• el negocio no puede asignar a una persona con autoridad para resolver dudas sobre el proceso;
• la cantidad prevista de usuarios o el volumen de transacciones cambia lo suficiente para alterar el precio;
• la implementación depende de datos incompletos, duplicados o no disponibles legalmente para el uso planeado;
• los requisitos personalizados siguen creciendo antes de que se haya probado el flujo central;
• el proveedor o desarrollador no puede explicar cómo recuperará la empresa sus datos ni cómo seguirá operando al terminar la relación.

No diluya un requisito no negociable dentro de un promedio. Si un producto obtiene una buena calificación general, pero no cumple una regla contractual sobre la ubicación de datos o un control de aprobación obligatorio, su resultado ponderado deja de importar. Marque las restricciones estrictas como aprobado o rechazado antes de comparar los totales.

Cómo tomar la decisión final

Compre cuando el proceso sea común, el producto pueda demostrar que encaja y adaptar la operación no perjudique el servicio ni el margen. Integre cuando los sistemas estándar cubran las funciones principales, pero la empresa necesite mover datos de forma confiable o colocar una interfaz específica entre ellos. Desarrolle cuando el flujo tenga importancia comercial, sea materialmente distinto, probablemente cambie y cuente con una persona interna capaz de seguir tomando decisiones de producto.

También existe una cuarta respuesta válida: esperar. Si el equipo no puede definir el problema, producir datos utilizables o asignar responsabilidades, comprometerse con cualquiera de las opciones puede convertir la incertidumbre en una implementación cara. Corregir primero un proceso o limpiar los datos puede ser la inversión adecuada.

Para revisar factores locales de planeación y entrega, consulte nuestra guía de desarrollo de software a la medida en Houston. La guía general de software a la medida explica el ciclo de vida, las funciones del equipo y los asuntos de propiedad que se aplican más allá de una sola ciudad.

Preguntas frecuentes

Fuentes oficiales

1. Digital.gov, “Navigating Digital Acquisitions”
2. U.S. GAO, “Cost Estimating and Assessment Guide”
3. CISA, “Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem”
4. NIST, Secure Software Development Framework
5. OWASP Application Security Verification Standard