Preguntas antes de comprar software

En la fase de selección de un software para empresas constructoras la presión es alta: los plazos de obra, la normativa peruana y la necesidad de integrar procesos hacen que cualquier decisión equivocada cueste tiempo y dinero. En este artículo encontrarás las preguntas que debes hacer, los aspectos que deben quedar por escrito, señales de alarma y una guía práctica para comparar dos propuestas diferentes.

Las preguntas que hay que hacer

• ¿Cuál es su experiencia en el sector de la construcción en Perú?

  • Respuesta esperada: El proveedor debe citar proyectos similares, mencionar cumplimiento de requisitos de SUNAT y facturación electrónica, y describir cómo adaptó funcionalidades a obras civiles.
  • Qué observar: Si solo habla de proyectos genéricos o de otros sectores, la curva de aprendizaje será mayor y el riesgo de incompatibilidades regulatorias aumenta.

• ¿Qué metodología de desarrollo utilizan y cómo gestionan los cambios?

  • Respuesta esperada: Metodología ágil (Scrum o Kanban) con sprints de 2 semana, reuniones de revisión y un proceso formal de control de cambios que no altere el cronograma sin aprobación.
  • Qué observar: Promesas de “cambio ilimitado” o ausencia de un proceso de gestión de cambios indican posibles sobrecostos.

• ¿Cuál es el equipo asignado y cuál es su disponibilidad?

  • Respuesta esperada: Un equipo dedicado de 1 analista, 2 desarrolladores y 1 QA, con disponibilidad mínima del 80 % durante el proyecto.
  • Qué observar: Proveedores que asignan recursos compartidos pueden retrasar entregas críticas.

• ¿Cómo garantizan la seguridad y confidencialidad de los datos?

  • Respuesta esperada: Encriptación de datos en tránsito y reposo, cumplimiento de la Ley de Protección de Datos Personales (LPDP) y auditorías de seguridad trimestrales.
  • Qué observar: Falta de certificaciones o pruebas de penetración.

• ¿Qué soporte ofrecen después de la puesta en producción?

  • Respuesta esperada: Soporte nivel 2 durante 12 meses, con SLA de respuesta en 4 horas y resolución en 24 horas para incidencias críticas.
  • Qué observar: Soporte solo “post‑venta” sin SLA definido.

Lo que tiene que estar por escrito

1. Alcance del proyecto: descripción detallada de módulos (presupuesto, control de obra, facturación electrónica, integración con SUNAT), funcionalidades y exclusiones.
2. Entregables: especificaciones técnicas, manuales de usuario, código fuente, diagramas de arquitectura y plan de pruebas.
3. Plazos: cronograma con hitos claros – por ejemplo, análisis de requisitos (2 semanas), prototipo UI (3 semanas), desarrollo iterativo (12 semanas), pruebas de aceptación (3 semanas) y puesta en producción (1 semana).
4. Propiedad del código: cláusula que transfiera la titularidad del código fuente a tu empresa al momento del pago final, con licencia de uso perpetua.
5. Condiciones de pago: porcentajes vinculados a entregables – 20 % al iniciar, 30 % al prototipo aprobado, 30 % al cierre de pruebas y 20 % al go‑live.
6. Mantenimiento y actualizaciones: detalle de lo que incluye el soporte (bugs, parches de seguridad) y el costo de evoluciones posteriores.

Señales de alarma

• Falta de documentación escrita. El proveedor solo ofrece acuerdos verbales o PDFs genéricos; sin un contrato detallado el proyecto queda expuesto a cambios inesperados.
• Plazos muy agresivos. Prometer entregas en menos de 4 semanas para un ERP de obra es irreal y suele ocultar una reducción de calidad.
• Precios “todo incluido”. Sin desglose de horas o recursos, el precio puede esconder cargos ocultos en soporte o personalización.
• Ausencia de referencias locales. Si no pueden citar clientes peruanos que hayan superado la integración con la SUNAT, la adaptación normativa será un riesgo.

Cómo comparar dos propuestas distintas

1. Normaliza la unidad de medida: convierte cada propuesta a horas estimadas por fase (análisis, desarrollo, pruebas, implementación). Si una propuesta indica “30 semanas” y otra “800 horas”, traduce a la misma escala.
2. Evalúa la cobertura de requisitos: crea una tabla con los módulos críticos (presupuesto, cronograma, control de calidad, facturación electrónica) y marca si cada propuesta los incluye, los excluye o los ofrece como opcionales.
3. Compara los SLA: tiempo de respuesta, tiempo de resolución y disponibilidad del equipo de soporte.
4. Revisa la cláusula de propiedad del código: la propuesta que transfiera la titularidad sin costos adicionales es la más segura.
5. Analiza el riesgo de cambios: la oferta con un proceso de gestión de cambios claro y costos predefinidos reduce sorpresas.

Paso práctico

1. Asigna un peso a cada criterio (alcance 40 %, plazo 20 %, SLA 20 %, propiedad 10 %, gestión de cambios 10 %).
2. Califica cada propuesta del 1 al 5 en cada criterio.
3. Multiplica la calificación por el peso y suma los resultados. La propuesta con mayor puntuación suele ser la más equilibrada.

Conclusión

Quien ha leído hasta aquí dispone de una lista concreta de preguntas que deben responder los proveedores, conoce los documentos esenciales que deben firmarse, reconoce señales de alarma que indican un riesgo alto y cuenta con un método práctico para comparar dos ofertas sin dejarse llevar solo por el precio. Con esta guía, tu empresa constructora podrá tomar una decisión informada, alineada a la normativa peruana y a los objetivos de eficiencia operativa, minimizando sorpresas y asegurando que la inversión en software a medida genere el retorno esperado.