Qué preguntar antes de migrar de Excel
Descubre las preguntas clave, los documentos imprescindibles y las señales de alerta para decidir si contratar un desarrollo a medida en Perú
Foto de cottonbro studio en Pexels
Migrar de una hoja de cálculo a una solución propia es una decisión que afecta a la operatividad, el cumplimiento normativo y la competitividad de tu empresa. En este artículo encontrarás las preguntas que debes formular a los proveedores, los documentos que deben quedar por escrito, las señales de alarma que te ayudarán a descartar opciones y una guía práctica para comparar propuestas distintas.
Las preguntas que hay que hacer
-
¿Cuál es el proceso de descubrimiento y análisis de requisitos?
- Respuesta esperada: El proveedor describe una fase de workshops de 2‑3 semanas con usuarios clave, levantamiento de procesos, mapeo de datos y definición de casos de uso.
- Qué observar: Si la respuesta es vaga o propone iniciar el desarrollo sin validar requisitos, el riesgo de entregas fuera de alcance es alto.
-
¿Cómo se gestionan los cambios de alcance durante el proyecto?
- Respuesta esperada: Se establece un procedimiento de control de cambios con un impacto estimado en tiempo y esfuerzo, aprobado por ambas partes antes de cualquier ajuste.
- Qué observar: Si el proveedor dice que los cambios se “incorporan sin problema” o que el precio es fijo sin posibilidad de ajustes, puede ocultar sobrecargas futuras.
-
¿Qué metodologías de desarrollo y pruebas utilizan?
- Respuesta esperada: Metodología ágil (Scrum o Kanban) con sprints de 2‑3 semanas, entregas incrementales y pruebas unitarias, de integración y de usuario al final de cada sprint.
- Qué observar: Ausencia de pruebas automatizadas o de un plan de pruebas de usuario indica falta de calidad.
-
¿Cómo garantizan la seguridad y el cumplimiento con SUNAT y la facturación electrónica?
- Respuesta esperada: Implementación de protocolos TLS, encriptación de datos sensibles y generación de XML conforme a los catálogos de SUNAT, con pruebas de validación en el entorno de pruebas de la entidad.
- Qué observar: Si el proveedor no menciona normativa local o delega la responsabilidad al cliente, el proyecto puede quedar expuesto a sanciones.
-
¿Qué experiencia tienen en proyectos similares en Perú?
- Respuesta esperada: Casos de estudio de al menos dos clientes del sector (p.ej., logística, retail) con referencia a cumplimiento de plazos y entregas de módulos de gestión de inventario o facturación.
- Qué observar: Falta de referencias locales o solo proyectos internacionales; la adaptación a la realidad peruana (normas, conectividad) puede ser insuficiente.
-
¿Cuál es el modelo de soporte post‑implementación?
- Respuesta esperada: Soporte técnico 24/7 durante los primeros 3 meses, SLA de respuesta ≤ 8 horas, y opción de mantenimiento evolutivo con tarifas transparentes.
- Qué observar: Promesas de “soporte ilimitado” sin definir niveles de servicio o costos posteriores.
-
¿Cómo gestionan la migración de datos desde Excel?
- Respuesta esperada: Herramienta de importación personalizada, validación de integridad, pruebas de carga con volúmenes reales y plan de rollback en caso de error.
- Qué observar: Si la respuesta se limita a “exportar CSV y cargarlo”, el proceso puede fallar ante datos complejos o relaciones entre tablas.
Lo que tiene que estar por escrito
- Alcance funcional detallado: lista de módulos, funcionalidades, integraciones (p.ej., API con SUNAT, ERP existente) y criterios de aceptación.
- Entregables: prototipos, código fuente, documentación técnica, manual de usuario y plan de capacitación.
- Cronograma con hitos: fechas de inicio, fin de cada fase (análisis, diseño, desarrollo, pruebas, puesta en producción) expresadas en semanas. Por ejemplo, 2 semanas de análisis, 4 semanas de diseño, 12 semanas de desarrollo, 4 semanas de pruebas, 2 semanas de despliegue.
- Soporte y garantía: período de garantía de corrección de bugs (mínimo 90 días), niveles de soporte (L1, L2) y tiempos de respuesta.
- Propiedad del código: cláusula que transfiera la titularidad del código fuente al cliente, con licencia abierta o cerrada según se acuerde, y derechos de uso ilimitado.
- Condiciones de pago: hitos de pago vinculados a entregables aprobados, evitando pagos adelantados sin resultados tangibles.
- Confidencialidad y protección de datos: cumplimiento con la Ley de Protección de Datos Personales (Ley 29733) y acuerdos de no divulgación.
Señales de alarma
- Plazos irreales. Prometen entregar un sistema completo en menos de 6 semanas sin detallar fases.
- Falta de documentación escrita. Solo ofrecen un “presupuesto” verbal o en PDF sin contrato formal.
- Negación de propiedad del código. Insisten en mantener la licencia exclusiva para ellos.
- Ausencia de pruebas de seguridad. No mencionan auditorías ni pruebas de penetración.
- Soporte vago. Dicen “estaremos disponibles cuando nos necesiten” sin SLA.
Cómo comparar dos propuestas distintas
- Normaliza la unidad de medida: convierte todas las estimaciones a semanas y a porcentaje de tiempo dedicado a cada fase. Si una propuesta indica 8 semanas totales y otra 12 semanas, revisa qué incluye cada una (p.ej., pruebas de usuario, capacitación).
- Desglosa el costo implícito: aunque no se publiquen precios, identifica los factores que influyen en el coste (número de desarrolladores, nivel de experiencia, uso de tecnologías propias vs. licencias). Una propuesta con menos recursos pero mayor tiempo puede ser más cara a largo plazo.
- Evalúa la cobertura de riesgos: compara las cláusulas de garantía, soporte y propiedad del código. La propuesta que ofrezca garantía de 90 días y SLA de 8 horas tiene menos riesgo que una sin estas garantías.
- Mira la alineación con requisitos críticos: crea una tabla de requisitos obligatorios (cumplimiento SUNAT, migración de datos, soporte post‑lanzamiento) y marca con ✔/✖ cada propuesta.
- Utiliza una comparativa visual:
Propuesta A
- Plazo total 14 semanas
- Garantía 60 días
- Soporte 24 h respuesta
Propuesta B
- Plazo total 16 semanas
- Garantía 90 días
- Soporte 8 h respuesta
En la tabla, la columna destacada indica la opción que mejor cubre los criterios de riesgo y cumplimiento.
Conclusión
Al leer este artículo, ya sabes exactamente qué preguntar, qué exigir por escrito, qué señales descartar y cómo comparar dos ofertas de desarrollo a medida. Aplicar este checklist evita sorpresas, protege la inversión y garantiza que la solución cumpla con la normativa peruana y con los objetivos de tu empresa. Con una decisión informada, la migración de Excel a un sistema propio pasa de ser un riesgo a convertirse en una oportunidad de crecimiento sostenible.
