Qué preguntar antes de contratar software a medida

En la oficina de tu empresa, la presión por digitalizar procesos se vuelve diaria: los plazos se acortan, la SUNAT exige facturación electrónica y los equipos piden herramientas que realmente se ajusten a sus flujos. Antes de firmar con un desarrollador, necesitas saber qué preguntar para evitar sorpresas costosas. Aquí tienes el checklist que todo gerente o dueño debe usar.

Las preguntas que hay que hacer

• ¿Cuál es su experiencia en proyectos similares en Perú?

  • Respuesta esperada: Detalla casos concretos, menciona cumplimiento de normativas locales (SUNAT, seguridad de datos) y referencia clientes del mismo sector.
  • Señal de alerta: Respuestas vagas, ausencia de referencias peruanas o ejemplos genéricos de “clientes internacionales”.

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

  • Respuesta esperada: Explican si trabajan con Scrum, Kanban u otra metodología ágil, y describen un proceso de control de cambios con impactos claros en tiempo y costo.
  • Señal de alerta: Prometen “cambios ilimitados” sin indicar cómo afecta al cronograma.

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

  • Respuesta esperada: Lista de roles (analista, desarrollador senior, QA) con tiempo dedicado semanal y plan de sustitución en caso de ausencias.
  • Señal de alerta: Equipo “flexible” sin compromiso de horas o con alta rotación.

• ¿Cómo manejan la integración con sistemas existentes (ERP, facturación electrónica, bancos)?

  • Respuesta esperada: Describen APIs, conectores preconstruidos y pruebas de integración en entornos de pre‑producción.
  • Señal de alerta: Ignoran la complejidad de la integración o sugieren “todo se puede conectar” sin plan técnico.

• ¿Qué garantías ofrecen en cuanto a cumplimiento de la normativa peruana (protección de datos, SUNAT, normativa de firma electrónica)?

  • Respuesta esperada: Muestran conocimiento de la Ley de Protección de Datos Personales y de los requisitos de la facturación electrónica, y cómo los incorporan al diseño.
  • Señal de alerta: Desconocimiento o delegación a “el cliente debe validar”.

• ¿Cuál es el modelo de soporte post‑entrega y los tiempos de respuesta?

  • Respuesta esperada: SLA claros (por ejemplo, respuesta en 4 h para incidencias críticas, 24 h para menores) y canales de soporte definidos.
  • Señal de alerta: Soporte “a convenir” o ausencia de métricas de servicio.

• ¿Cómo se protege la propiedad intelectual del código?

  • Respuesta esperada: Contrato que otorga a tu empresa la titularidad total del código fuente y los derechos de uso.
  • Señal de alerta: Licencias de uso restringidas o cláusulas que retienen el código.

Lo que tiene que estar por escrito

1. Alcance detallado – Funcionalidades, módulos, integraciones y exclusiones. Cada ítem debe estar descrito en un documento de requerimientos firmado.
2. Entregables – Listado de artefactos: código fuente, documentación técnica, manual de usuario, scripts de despliegue y pruebas de aceptación.
3. Plazos – Cronograma con hitos claros (por ejemplo, Sprint 1 = 2 semanas de análisis, Sprint 2 = 3 semanas de desarrollo del módulo de facturación, etc.). Cada fase debe incluir fechas de revisión y aprobación.
4. Soporte – Duración del soporte post‑producción (mínimo 6 meses), niveles de servicio (crítico, alto, bajo) y costos adicionales si se extiende.
5. Propiedad del código – Cláusula que transfiera la titularidad completa a tu empresa, con permiso de uso ilimitado y sin royalties.

Señales de alarma

• El precio no se desglosa. Si solo recibes un total sin detalle de horas, licencias o infraestructura, es difícil validar la razonabilidad.
• Prometen entrega en menos de 4 semanas para un ERP completo. Un proyecto de esa magnitud necesita al menos 12 semanas de desarrollo y pruebas.
• No ofrecen pruebas de aceptación. Sin un proceso de UAT (User Acceptance Testing) la empresa queda sin garantía de que el producto cumpla los requisitos.
• Evitan firmar contrato de propiedad del código. Retener derechos de uso es una práctica que limita la autonomía futura.
• Falta de referencias locales. La normativa peruana tiene particularidades; la ausencia de casos locales indica desconocimiento.

Cómo comparar dos propuestas distintas

1. Normaliza unidades – Convierte todas las estimaciones a semanas y a horas de trabajo. Si una propuesta habla de “2 meses” y la otra de “8 semanas”, alinéalas.
2. Identifica diferencias de alcance – Usa la tabla comparativa (como la anterior) para marcar qué incluye cada oferta: integraciones, pruebas, documentación, capacitación.
3. Evalúa el impacto de los cambios – Pregunta cuánto aumentaría el plazo y el coste si añades una integración bancaria a la propuesta A.
4. Revisa los SLA – Compara tiempos de respuesta y cobertura de soporte. Un SLA de 4 h para incidencias críticas es mucho más valioso que uno de 24 h.
5. Pondera riesgos – Asigna una puntuación (por ejemplo, 1‑5) a factores críticos: experiencia local, claridad del contrato, nivel de soporte. La propuesta con mayor puntuación suele ser la más segura.

Conclusión

Al terminar este artículo, deberías contar con una lista concreta de preguntas que cualquier proveedor serio debe responder, saber exactamente qué documentos deben firmarse y reconocer las señales que indican un riesgo elevado. Con esa base, comparar dos ofertas deja de ser una cuestión de intuición y pasa a ser un análisis objetivo basado en plazos, entregables y garantías. Así, tu empresa avanza con la seguridad de que la inversión en software a medida será una herramienta que realmente impulse la operación, cumpla con la normativa peruana y quede bajo tu control total.