Qué preguntar antes de automatizar datos

En tu empresa los procesos de captura y transferencia de información se vuelven cada vez más críticos: errores en la carga de datos generan retrasos, multas de SUNAT y pérdida de confianza interna. Antes de decidirte por un proyecto de automatizar carga de datos entre sistemas, necesitas saber exactamente qué preguntar para que el proveedor entregue lo que realmente necesitas.

Las preguntas que hay que hacer

• ¿Cuál es el flujo exacto que propones automatizar?

  • Respuesta esperada: Un diagrama paso a paso que incluye origen, transformación y destino, con referencias a los formatos de facturación electrónica de SUNAT y a los sistemas internos (ERP, CRM, etc.).
  • Señal de alarma: Respuestas vagas o “dependiendo de la necesidad”. Si no pueden describir el flujo, el riesgo de sobre‑carga o de datos perdidos aumenta.

• ¿Qué tecnologías usarás y por qué?

  • Respuesta esperada: Detalle de APIs, conectores o RPA, y justificación basada en la disponibilidad de los endpoints de cada sistema. Si se menciona IA, debe explicar el rol concreto (p. ej. reconocimiento de patrones en facturas).
  • Señal de alarma: Prometer “cualquier tecnología” sin especificar, lo que suele esconder soluciones ad‑hoc difíciles de mantener.

• ¿Cómo manejas la seguridad y el cumplimiento con la normativa peruana?

  • Respuesta esperada: Encriptación TLS, gestión de tokens, registro de auditoría y alineación con la Ley de Protección de Datos Personales y los requisitos de SUNAT para la transmisión de información fiscal.
  • Señal de alarma: Ignorar la necesidad de certificaciones o de registros de actividad.

• ¿Cuál es el tiempo estimado de desarrollo y de pruebas?

  • Respuesta esperada: Un cronograma claro, por ejemplo, 4 semanas de levantamiento de requisitos, 6 semanas de desarrollo, 2 semanas de pruebas unitarias y 2 semanas de pruebas de integración con usuarios clave.
  • Señal de alarma: Prometer entregas en menos de 3 semanas sin fase de pruebas.

• ¿Qué nivel de soporte ofreces después de la puesta en marcha?

  • Respuesta esperada: Soporte técnico 8 x5 durante los primeros 90 días, con SLA de respuesta < 4 horas y corrección de errores críticos en < 24 horas.
  • Señal de alarma: No definir tiempos de respuesta o limitar el soporte a “consultas por correo”.

• ¿Cómo se gestionan los cambios de alcance?

  • Respuesta esperada: Un proceso de control de cambios que incluye estimación de esfuerzo adicional (por ejemplo, + 10 % de tiempo por cada nuevo endpoint) y aprobación formal.
  • Señal de alarma: Ausencia de un proceso formal, lo que suele derivar en sobrecostos ocultos.

Lo que tiene que estar por escrito

• Alcance detallado: lista de sistemas involucrados, tipos de documentos (facturas, órdenes de compra, tickets de WhatsApp) y los campos específicos que se sincronizarán.
• Entregables: diagramas de arquitectura, código fuente, scripts de despliegue, documentación de API y manual de usuario.
• Plazos: fechas de inicio, hitos de revisión (demo de integración, pruebas de usuario) y fecha de entrega final.
• Soporte y mantenimiento: nivel de soporte (nivel 1, 2, 3), canales (ticket, videollamada), horarios y duración del contrato post‑implementación.
• Propiedad del código: cláusula que establezca que el cliente posee los derechos de autor y puede mantener o migrar la solución sin penalizaciones.

Una propuesta clara evita malentendidos y protege la inversión de tu empresa.

Señales de alarma

• El proveedor no muestra ejemplos de proyectos similares. Sin referencias concretas, es difícil validar su capacidad para manejar la complejidad de la normativa peruana.
• Promete “integración sin código”. En la práctica siempre hay al menos un nivel de personalización; la ausencia de código suele significar uso de plataformas genéricas que pueden no cumplir con los requisitos de SUNAT.
• Falta de un plan de pruebas. Sin pruebas de carga, de seguridad y de regresión, el riesgo de interrupciones operativas es alto.
• Negan la entrega del código fuente. Retener el código impide futuras mejoras o migraciones a otro proveedor.

Cómo comparar dos propuestas distintas

1. Normaliza los criterios: crea una tabla con columnas como “Alcance”, “Plazos”, “Soporte”, “Propiedad del código” y “Metodología de pruebas”.
2. Evalúa la claridad: la propuesta que detalle cada ítem con números (semanas, horas) gana puntos.
3. Revisa los supuestos: identifica si alguna propuesta incluye servicios no cotizados (por ejemplo, licencias de software) y anótalo como gasto extra.
4. Aplica una ponderación: para una empresa que depende de la facturación electrónica, asigna mayor peso a cumplimiento normativo y seguridad.
5. Usa una comparativa visual:

En este ejemplo, aunque la Propuesta B sea más rápida, la Propuesta A cubre todos los sistemas críticos y ofrece un soporte más amplio, lo que la hace más adecuada para una operación que depende de la integración completa.

Conclusión

Al decidir automatizar carga de datos entre sistemas, la clave está en preguntar con precisión, exigir documentación escrita y estar atento a señales de alarma que indiquen falta de experiencia o compromiso. Comparar propuestas con criterios normalizados te permite elegir al socio que garantice cumplimiento normativo, plazos realistas y soporte sólido, evitando sorpresas costosas y asegurando que la inversión impulse realmente la eficiencia de tu empresa.