¿Qué preguntar antes de elegir un sistema

Migrar de Excel a un sistema propio es una decisión que implica tiempo, recursos y riesgo. Si ya sabes que la hoja de cálculo ya no basta, el siguiente paso es asegurarte de que el proveedor que elijas entienda tus necesidades y pueda entregarte lo que realmente necesitas. En este artículo encontrarás las preguntas que debes hacer, qué debe quedar por escrito, señales de alarma y cómo comparar dos propuestas distintas.

Las preguntas que hay que hacer

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

  • Respuesta esperada: Detalle de al menos dos casos de migración de Excel a un sistema web a medida, con referencias a clientes peruanos y cumplimiento de requisitos de SUNAT.
  • Qué te preocupa: Si el proveedor menciona solo proyectos genéricos o fuera del país, puede desconocer regulaciones locales como la facturación electrónica.

• ¿Cómo estructuran el análisis de requerimientos?

  • Respuesta esperada: Un taller de descubrimiento de 2‑3 semanas donde se mapearán procesos, se identificarán datos críticos y se definirá el alcance funcional.
  • Qué te preocupa: Si la respuesta es “solo una reunión” o “un cuestionario rápido”, el proyecto podría quedar con lagunas importantes.

• ¿Qué arquitectura propone y por qué?

  • Respuesta esperada: Explicación de una arquitectura basada en servicios REST, base de datos relacional y front‑end responsive, con justificación de escalabilidad y seguridad.
  • Qué te preocupa: Propuestas “todo en una sola página” o sin separación clara de capas pueden generar problemas de mantenimiento.

• ¿Cómo gestionan la integración con Excel durante la transición?

  • Respuesta esperada: Herramientas de importación masiva, sincronización bidireccional y una fase piloto donde ambos sistemas conviven.
  • Qué te preocupa: Si solo hablan de “cargar datos una vez”, podrías quedar atrapado con datos desactualizados.

• ¿Qué metodologías de pruebas utilizan?

  • Respuesta esperada: Pruebas unitarias, de integración y de usuario (UAT) con criterios de aceptación claros y un plan de pruebas de al menos 2 semanas.
  • Qué te preocupa: Ausencia de pruebas estructuradas o pruebas realizadas sólo por el equipo de desarrollo.

• ¿Cuál es el modelo de soporte post‑entrega?

  • Respuesta esperada: Soporte nivel 1 y 2 durante 6 meses, con SLA de respuesta ≤ 24 h y corrección de bugs críticos en ≤ 48 h.
  • Qué te preocupa: Soporte “a convenir” o sin tiempos definidos.

• ¿Quién será el responsable técnico del proyecto?

  • Respuesta esperada: Un arquitecto de soluciones asignado de forma exclusiva, con contacto directo y disponibilidad para decisiones rápidas.
  • Qué te preocupa: Si el proyecto se delega a un equipo rotativo sin lider claro.

Lo que tiene que estar por escrito

1. Alcance detallado – Lista de módulos, funcionalidades y flujos que se entregarán, incluyendo los requisitos de integración con SUNAT y la normativa de protección de datos.
2. Entregables – Mockups, prototipos, código fuente, documentación técnica y manual de usuario. Cada entregable debe tener una fecha estimada.
3. Plazos – Cronograma con hitos claros: análisis (2‑3 semanas), diseño (2 semanas), desarrollo (8‑12 semanas), pruebas (2‑3 semanas) y puesta en producción (1 semana).
4. Propiedad del código – Cláusula que transfiera al cliente la titularidad total del código fuente y de los derechos de uso, sin licencias restrictivas.
5. Soporte y mantenimiento – Detalle de horas incluidas, niveles de servicio, costos adicionales y periodo de garantía.
6. Penalizaciones – Multas por incumplimiento de plazos críticos (por ejemplo, retraso > 10 días en la fase de pruebas).

Señales de alarma

• El proveedor evita describir su proceso de análisis. Sin un taller estructurado, el proyecto puede quedar con requerimientos implícitos y cambios costosos.
• Promete entregas “en tiempo récord” sin detallar etapas. La velocidad suele esconder un alcance limitado o una calidad pobre.
• No menciona propiedad del código. Podrías quedar atado a un software que no puedes modificar ni portar.
• Carece de SLA para soporte. En caso de fallas críticas, la empresa quedará sin garantía de respuesta.
• Solo habla de “software enlatado”. Si el discurso se centra en soluciones pre‑configuradas, el proyecto no será a medida.

Cómo comparar dos propuestas distintas

1. Verifica la correspondencia con tus preguntas – Cada propuesta debe responder claramente a las preguntas listadas arriba. Las respuestas vagas son una señal de riesgo.
2. Desglosa el cronograma – Compara los hitos y la duración de cada fase. Si una oferta reduce drásticamente el tiempo de desarrollo, indaga cómo se logra.
3. Revisa los entregables – Asegúrate de que ambas incluyan los mismos artefactos (código, documentación, pruebas). La falta de alguno indica un alcance menor.
4. Evalúa la propiedad del código – La propuesta que transfiera la totalidad del código es la que protege tu inversión a largo plazo.
5. Compara el modelo de soporte – Analiza SLA, duración del soporte incluido y costos adicionales. Un soporte limitado puede generar gastos inesperados.
6. Utiliza una tabla comparativa

Al comparar, pon peso a los criterios que más impactan tu operación: propiedad del código, plazo de entrega y nivel de soporte. Una oferta más barata pero sin transferencia de código puede costar mucho más a futuro.

Conclusión

Quien ha llegado hasta aquí ya dispone de una lista práctica de preguntas, de los elementos contractuales que deben quedar por escrito y de las señales que indican un proveedor poco fiable. Además, cuenta con una guía para evaluar objetivamente dos propuestas distintas, enfocándose en plazos, entregables, soporte y propiedad del código. Con esta información, la decisión de migrar de Excel a un sistema hecho a medida o software enlatado pasa de ser una intuición a una elección basada en datos concretos y alineada con la realidad peruana.