Los 3 tipos de proveedores que encontrarás en el mercado
Cuando una empresa mediana en México busca software para un proceso específico que el ERP no resuelve, encuentra en el mercado tres tipos de proveedores que se presentan de maneras diferentes pero tienen modelos de negocio fundamentalmente distintos. Entender la diferencia entre ellos antes de firmar un contrato puede determinar si el proyecto termina en 8 semanas o en 18 meses.
El primer tipo es el vendor de producto puro: una empresa que tiene un software construido con una funcionalidad específica, lo empaqueta para vendérselo a muchas empresas, y lo mejora con base en el feedback de toda su base de clientes. El segundo tipo es la casa de desarrollo pura: una empresa que construye software a la medida para cada cliente, cobrando por horas o por proyecto, sin una plataforma común entre proyectos. El tercer tipo es el modelo plataforma+factory: una empresa que tiene una plataforma tecnológica propia que usa como base para construir soluciones configuradas o parcialmente a la medida para cada cliente.
El vendor de producto puro: cuándo funciona y cuándo no
El vendor de producto puro tiene ventajas claras para procesos estándar: el software ya existe y funciona, la implementación es relativamente rápida, el costo por usuario suele ser predecible, y las actualizaciones están incluidas en la suscripción. Empresas de gestión de gastos, nómina, CRM básico, o contabilidad general encajan bien en este modelo porque los procesos son similares entre empresas y el producto puede soportarlos sin customización significativa.
El vendor de producto puro falla cuando el proceso del cliente tiene particularidades que el producto no fue diseñado para soportar, cuando la integración con el ERP específico del cliente no está en el roadmap del proveedor, o cuando el cliente necesita velocidad de adaptación mayor a la que el ciclo de releases del proveedor puede ofrecer. Muchas empresas medianas mexicanas tienen procesos suficientemente específicos como para que los productos estándar del mercado no encajen bien.
La casa de desarrollo pura: el riesgo del proyecto eterno
La casa de desarrollo pura tiene la ventaja de la flexibilidad total: puede construir exactamente lo que el cliente necesita sin restricciones de plataforma. El problema estructural es que cada proyecto comienza desde cero o casi desde cero, sin una plataforma común que acelere el desarrollo de componentes transversales como autenticación, gestión de usuarios, integraciones con ERPs, o arquitectura multi-tenant.
El segundo problema de las casas de desarrollo puras es la continuidad. Si el desarrollador principal del proyecto se va de la empresa, el conocimiento del sistema se va con él. Las casas de desarrollo pequeñas —que son las que más trabajan con empresas medianas en México— tienen una rotación alta y una documentación frecuentemente escasa. La empresa cliente termina con un sistema que nadie más que el proveedor original puede mantener, y cuando necesita cambios importantes, tiene que volver a ese mismo proveedor en una posición de negociación debilitada.
"Después de tres años trabajando con una casa de desarrollo, el único desarrollador que entendía nuestro sistema renunció. Tuvimos que contratar al proveedor de nuevo para que nos 'enseñara' el sistema que ellos mismos habían construido. Costó más que el proyecto original." — Director de TI, empresa de distribución de alimentos, Guadalajara, 480 empleados
El modelo plataforma+factory: por qué combina lo mejor de ambos
El modelo plataforma+factory parte de una arquitectura tecnológica probada que el proveedor ha construido y refinado a través de múltiples proyectos. Esta plataforma tiene componentes reutilizables —autenticación, gestión de roles y permisos, integraciones con los ERPs más comunes, arquitectura de APIs, manejo de notificaciones— que ya están construidos, probados, y en producción en otros clientes. El equipo de "factory" usa estos componentes como base para construir la solución específica de cada cliente.
Las ventajas son concretas: el tiempo de desarrollo se reduce porque los componentes transversales ya existen. La calidad es más consistente porque la plataforma ha sido probada en producción. La continuidad es mayor porque cualquier desarrollador del equipo conoce la plataforma y puede retomar el trabajo donde otro lo dejó. Y el mantenimiento es más predecible porque los componentes de la plataforma se actualizan centralmente beneficiando a todos los clientes simultáneamente.
La misma arquitectura, el mismo equipo: el valor de la continuidad
Una de las ventajas menos visibles pero más importantes del modelo plataforma+factory es la continuidad del equipo. Cuando la solución de un cliente está construida sobre la misma plataforma que las soluciones de otros clientes, cualquier desarrollador del equipo puede trabajar en ella sin necesidad de un período de inducción largo. Esto tiene implicaciones prácticas importantes: si el proyecto necesita más capacidad en una fase crítica, el proveedor puede agregar desarrolladores sin que la calidad se vea afectada. Si un desarrollador se va de la empresa, el reemplazo puede ser productivo en días, no en semanas.
Esta continuidad también beneficia la relación post-implementación. Los cambios que el cliente necesita después del go-live —ajustes de reglas de negocio, nuevas integraciones, ampliaciones de funcionalidad— se hacen sobre una base conocida por todo el equipo. El costo y el tiempo de estos cambios es más predecible que en un sistema construido ad-hoc.
¿Quieres ver nuestra plataforma en acción?
Te mostramos los componentes que aceleran cada implementación y cómo se adaptarían a tu proceso específico.
Ver demo técnico →Indicadores de un proveedor maduro con plataforma propia
Identificar si un proveedor genuinamente tiene una plataforma propia o simplemente construye desde cero con cada cliente requiere hacer las preguntas correctas durante el proceso de evaluación. Los indicadores de un proveedor maduro con plataforma propia incluyen:
- Pueden mostrar documentación técnica de su plataforma antes de que empiece el proyecto.
- Tienen conectores documentados y probados para los ERPs más comunes en el mercado mexicano.
- Pueden dar referencia de múltiples clientes con procesos similares que usan la misma plataforma base.
- El tiempo de cotización es corto porque conocen el costo de cada componente de su plataforma.
- El equipo técnico que presentan en la propuesta es el mismo equipo que va a ejecutar el proyecto.
- Pueden mostrar el roadmap de la plataforma y cómo las mejoras benefician a todos los clientes.
Banderas rojas: señales de que no tienen plataforma real
Hay comportamientos que indican que un proveedor que se presenta como "plataforma" en realidad opera como casa de desarrollo pura. Estas señales son importantes porque cambian radicalmente el perfil de riesgo del proyecto:
- El tiempo de estimación es muy largo porque tienen que "analizar el requerimiento" antes de poder cotizar.
- No pueden mostrar demos funcionales que representen su plataforma base: cada demo que hacen es específica para el cliente.
- Las referencias de clientes que dan son de proyectos muy diferentes entre sí, sin un patrón tecnológico común.
- El equipo asignado al proyecto cambia entre la propuesta y el inicio del proyecto.
- No tienen documentación técnica de sus APIs o integraciones disponible antes de firmar.
- El contrato no especifica qué componentes son de la plataforma y cuáles son de desarrollo a la medida.
El contrato ideal con un proveedor plataforma+factory
El contrato con un proveedor plataforma+factory debe especificar claramente qué componentes de la plataforma se van a usar, qué funcionalidad adicional se va a desarrollar a la medida, y cómo se gestiona la propiedad del código desarrollado específicamente para el cliente. Un contrato bien estructurado incluye también cláusulas sobre el acceso del cliente a su propia data, el proceso de transición si el cliente decide cambiar de proveedor, y los SLAs de soporte diferenciados para problemas de plataforma y para problemas de configuración específica del cliente.
La propiedad intelectual del código es un punto frecuente de conflicto. Los componentes de la plataforma del proveedor son propiedad del proveedor: el cliente no puede exigir el código fuente de la plataforma. La configuración y el desarrollo específico para el cliente, en cambio, puede negociarse. Algunos proveedores ceden la propiedad del código específico del cliente al cierre del contrato; otros mantienen la propiedad pero garantizan exportación completa de datos y documentación técnica suficiente para que el cliente pueda encargar mantenimiento a un tercero. Cualquiera de las dos opciones es más protectora que un contrato que no especifica nada.