Qué preguntar antes de decidir

La resistencia del equipo a un nuevo sistema suele aparecer cuando la decisión de compra se toma sin entender bien los temores y los requisitos operativos de tu empresa. En este artículo encontrarás las preguntas que debes hacer al proveedor, los pactos que deben quedar por escrito y las señales de alarma que te ayudarán a descartar opciones antes de firmar.

Las preguntas que hay que hacer

• ¿Cuál es su experiencia específica en empresas peruanas que manejan facturación electrónica y SUNAT?

  • Respuesta esperada: Detalle de proyectos similares, referencias de clientes del sector y conocimiento de los requerimientos de la SUNAT (p.ej., generación de XML, envío automático, validación de códigos).
  • Señal de alarma: Respuestas vagas o ausencia de casos locales; el proveedor no entiende la normativa peruana y eso genera retrasos y multas.

• ¿Cómo planifican la gestión del cambio y la adopción del sistema?

  • Respuesta esperada: Metodología estructurada (p.ej., diagnóstico de resistencia, workshops de co‑creación, plan de comunicación semanal).
  • Señal de alarma: Prometen “capacitación” sin mencionar acompañamiento continuo o indicadores de adopción.

• ¿Qué porcentaje del proyecto está destinado a actividades de acompañamiento y soporte durante los primeros 90 días?

  • Respuesta esperada: Entre 15 % y 20 % del esfuerzo total, con entregables claros (sesiones de acompañamiento, tickets de soporte con SLA de 24 h).
  • Señal de alarma: No asignan recursos dedicados al post‑implementación o indican que el soporte empieza solo después de la firma del contrato de mantenimiento.

• ¿Cuántas iteraciones de pruebas de usuario final (UAT) incluyen y cuánto tiempo asignan a cada una?

  • Respuesta esperada: Mínimo 2 iteraciones, cada una de 2‑3 semanas, con criterios de aceptación firmados por el responsable de operaciones.
  • Señal de alarma: Solo una ronda de pruebas o pruebas “informales” sin criterios medibles.

• ¿Qué mecanismos utilizan para medir la aceptación del equipo (encuestas, métricas de uso, tiempo de ejecución de tareas)?

  • Respuesta esperada: Indicadores como % de usuarios activos, tiempo medio de tarea, y encuestas de satisfacción con umbrales (p.ej., >80 % de satisfacción).
  • Señal de alarma: No ofrecen métricas o dejan la medición a cargo del cliente sin herramientas.

• ¿Cuál es su política de cambios de alcance una vez iniciada la fase de desarrollo?

  • Respuesta esperada: Cambio controlado mediante comité de cambios, con impacto en tiempo y coste claramente comunicado.
  • Señal de alarma: Admiten “flexibilidad total” sin control, lo que suele generar desviaciones de plazo y sobrecarga de trabajo.

• ¿Cómo gestionan la integración con sistemas legados (ERP, contabilidad, banca) que ya usa tu empresa?

  • Respuesta esperada: Análisis de APIs, pruebas de conectividad y plan de migración con hitos definidos (ej.: 4 semanas de pruebas de integración).
  • Señal de alarma: Ignoran la existencia de sistemas legados o proponen “conexiones manuales” que aumentan la carga operativa.

• ¿Qué rol tendrá tu equipo interno durante el proyecto y cuántas horas semanales se esperan de ellos?

  • Respuesta esperada: Participación clara (p.ej., 4 h/semana de un líder de proceso, 2 h/semana de un usuario clave) con calendario de entregables.
  • Señal de alarma: Expectativas de disponibilidad total sin compensación ni planificación realista.

Lo que tiene que estar por escrito

1. Alcance detallado: descripción de cada módulo, funcionalidades incluidas y exclusiones explícitas. Cada punto debe estar asociado a un número de historia de usuario o caso de uso.
2. Entregables: lista de artefactos (documentación funcional, manuales de usuario, scripts de migración, código fuente). Cada entregable debe incluir fecha de entrega y criterios de aceptación.
3. Plazos: cronograma con hitos claros (análisis – 2 semanas, diseño – 3 semanas, desarrollo – 8 semanas, UAT – 3 semanas, puesta en producción – 1 semana). Señala los buffers de riesgo (p.ej., +10 % de tiempo para integraciones con SUNAT).
4. Soporte: SLA de soporte post‑implementación (tiempo de respuesta 4 h, tiempo de resolución 24 h para incidentes críticos). Define el periodo de soporte gratuito (p.ej., 90 días) y la tarifa posterior.
5. Propiedad del código: cláusula que transfiera la titularidad del código fuente, documentación y derechos de explotación a tu empresa al momento de la aceptación final. Incluye una licencia que permita modificaciones internas sin costo adicional.
6. Penalizaciones por incumplimiento: porcentaje del valor del contrato que se descontará por cada día de retraso en los hitos críticos.
7. Confidencialidad y cumplimiento: referencia a la Ley de Protección de Datos Personales (Ley N° 29733) y a la normativa de la SUNAT para asegurar que el software cumpla con los requisitos legales.

Señales de alarma

• El proveedor evita firmar un alcance detallado. Sin un documento claro, el proyecto se vuelve vulnerable a “cambios de última hora” que aumentan la resistencia del equipo.
• Promete plazos sin buffers de riesgo. En Perú, la integración con la SUNAT suele requerir ajustes inesperados; la ausencia de margen indica falta de experiencia.
• No menciona métricas de adopción. Si no se mide la aceptación, no hay forma de actuar a tiempo para corregir la resistencia.
• El soporte queda a cargo del cliente después de la entrega. La resistencia suele aparecer en los primeros 30 días; sin soporte activo, el equipo abandonará el sistema.
• Falta de referencias locales. Cada país tiene sus particularidades; la ausencia de casos peruanos es una señal de que el proveedor no está preparado para los requisitos regulatorios.

Cómo comparar dos propuestas distintas

Cuando recibas dos ofertas que no cotizan lo mismo, sigue estos pasos:

1. Normaliza los componentes: crea una tabla con los mismos ítems (alcance, horas de acompañamiento, pruebas UAT, integración SUNAT, soporte). Si una propuesta incluye un ítem que la otra no, anótalo como “no incluido”.
2. Evalúa el valor de cada ítem: asigna un peso según la criticidad para tu empresa (por ejemplo, integración SUNAT 30 %, soporte post‑implementación 25 %, acompañamiento al cambio 20 %, etc.).
3. Calcula un puntaje ponderado: multiplica el cumplimiento de cada ítem (1 = sí, 0 = no) por su peso y suma los resultados.
4. Revisa los riesgos: identifica en cada propuesta los buffers de tiempo y las penalizaciones; una oferta con menor precio pero sin buffers es más riesgosa.
5. Haz una comparativa visual: utiliza el bloque HTML permitido para resaltar la opción que mejor equilibra alcance y riesgos.

El objetivo no es elegir la opción más barata, sino la que minimice la resistencia del equipo al garantizar entregas claras, tiempo suficiente para pruebas y un soporte sólido.

Conclusión

Al leer este artículo, ya sabes qué preguntar, qué pactar por escrito, qué señales descartar y cómo comparar dos ofertas sin perder detalle. Aplicar este checklist te permitirá seleccionar un proveedor que no solo entregue el software, sino que también reduzca la resistencia de tu equipo, garantizando una adopción rápida y alineada con la normativa peruana.