Diagnóstico inicial sin costo para evaluar tu proyecto

¡Consultar ahora!
Software a medida

Qué preguntar antes de contratar portales

Descubre las preguntas clave, requisitos escritos y señales de alarma para elegir el portal B2B que realmente impulse tu empresa peruana

Kovensa 4 min de lectura

Foto de Walls.io en Pexels

Los gerentes y dueños de empresas peruanas que buscan un portal de clientes y proveedores a menudo se pierden entre ofertas técnicas y promesas de velocidad. En este artículo encontrarás las preguntas que debes hacer, los elementos que deben quedar por escrito, señales de alarma y cómo comparar dos propuestas diferentes, para que tu decisión sea basada en hechos y no en marketing.

Las preguntas que hay que hacer

  • ¿Cuál es el modelo de arquitectura que propone?

    • Respuesta esperada: “Usamos arquitectura de micro‑servicios basada en contenedores Docker, con API RESTful que se integran a SUNAT y al módulo de facturación electrónica que ya usas.”
    • Qué te preocupa: Si la respuesta menciona una arquitectura monolítica sin posibilidades de escalar o sin API, el proyecto podría quedar bloqueado al crecer la empresa.
  • ¿Cómo gestionan la seguridad de datos sensibles (información tributaria, datos bancarios)?

    • Respuesta esperada: “Aplicamos cifrado AES‑256 en tránsito y en reposo, autenticación multifactor y cumplimiento con la normativa de protección de datos personales (Ley 27444).”
    • Qué te preocupa: Falta de referencia a normas locales, uso de contraseñas simples o ausencia de auditorías de seguridad.
  • ¿Qué tiempo estiman para la fase de integración con SUNAT y la facturación electrónica?

    • Respuesta esperada: “Integración completa en 4 semanas, con pruebas de certificación en el entorno de pruebas de SUNAT durante 1 semana adicional.”
    • Qué te preocupa: Plazos vagos como “unos meses” o ausencia de pruebas de certificación, lo que puede retrasar la emisión de comprobantes legales.
  • ¿Cómo manejan la migración de datos existentes (clientes, proveedores, historiales de facturación)?

    • Respuesta esperada: “Realizamos extracción, transformación y carga (ETL) en 3 semanas, con validación de 100 % de los registros y reporte de inconsistencias antes del go‑live.”
    • Qué te preocupa: No mencionar una fase de validación o depender de “importación manual” que genera errores.
  • ¿Qué nivel de personalización permite el portal sin requerir código adicional?

    • Respuesta esperada: “El motor de formularios y reglas de negocio permite crear flujos de aprobación, campos personalizados y reportes sin tocar código, mediante un panel de administración.”
    • Qué te preocupa: Si todo requiere desarrollo a medida, el coste y los tiempos se disparan.
  • ¿Cuál es el plan de mantenimiento y actualizaciones después del lanzamiento?

    • Respuesta esperada: “Incluimos 12 meses de soporte con actualizaciones de seguridad mensuales y mejoras funcionales trimestrales, todo documentado en un SLA.”
    • Qué te preocupa: Soporte limitado a “30 días” o ausencia de SLA.
  • ¿Cómo se gestionan los accesos y roles para usuarios internos y externos?

    • Respuesta esperada: “Definimos roles granulares (admin, gestor, lector) y cada partner tiene su propio dominio de acceso, con trazabilidad de acciones.”
    • Qué te preocupa: Un modelo de acceso único que no separa a clientes y proveedores, lo que compromete la confidencialidad.

Lo que tiene que estar por escrito

  1. Alcance funcional detallado: lista de módulos (catálogo de productos, órdenes de compra, facturación electrónica, seguimiento de entregas, reportes). Cada módulo debe especificar los flujos de trabajo y los criterios de aceptación.
  2. Entregables: prototipos de UI, código fuente, documentación de API, manual de usuario, plan de pruebas y reporte de certificación SUNAT.
  3. Plazos: cronograma con hitos claros (análisis – 2 semanas, diseño – 3 semanas, desarrollo – 8 semanas, pruebas – 4 semanas, certificación – 1 semana, puesta en producción – 1 semana). Cada hito debe incluir un porcentaje de avance y una fecha de entrega.
  4. Soporte: nivel de soporte (N1/N2), tiempo de respuesta (máx 4 horas para incidentes críticos), canales (ticket, teléfono), y periodo de garantía.
  5. Propiedad del código: cláusula que establezca que el cliente posee el código fuente, los derechos de uso y la posibilidad de contratar mantenimiento a terceros sin penalizaciones.
  6. Criterios de aceptación y pruebas: pruebas unitarias, de integración, de carga y de certificación SUNAT, con métricas de éxito (por ejemplo, 99,5 % de transacciones sin error).
  7. Penalizaciones por retrasos: porcentaje de descuento por cada día hábil de retraso después del go‑live acordado.

Señales de alarma

  • El proveedor no menciona integración con SUNAT. Sin esa referencia, el portal no podrá emitir comprobantes electrónicos válidos en Perú.
  • Los plazos se expresan en “meses” sin desglosar hitos. Falta de detalle indica que no hay una planificación real y que los riesgos no están controlados.
  • No se habla de propiedad del código. Si el contrato deja los derechos al desarrollador, tu empresa quedará atada a un único proveedor.
  • El presupuesto no incluye mantenimiento. Un portal sin soporte post‑lanzamiento se vuelve vulnerable a fallas y a cambios regulatorios.
  • El modelo de precios es “todo incluido” sin desglose. Oculta posibles cargos extra por usuarios adicionales, integraciones o actualizaciones.

Cómo comparar dos propuestas distintas

  1. Normaliza la información: crea una tabla con los mismos ítems (alcance, plazos, soporte, propiedad, SLA, metodología). Cada propuesta debe rellenar la tabla.
  2. Evalúa la cobertura de requisitos críticos: marca con ✔︎ si la propuesta cubre integración SUNAT, roles granulares, migración de datos completa y pruebas de certificación.
  3. Compara los plazos: si una oferta dice 12 semanas y la otra 16 semanas, verifica si la diferencia se debe a mayor detalle de pruebas o a falta de fases críticas.
  4. Analiza el modelo de costos implícitos: aunque no se indiquen precios, identifica dónde pueden aparecer cargos adicionales (por ejemplo, por usuarios extra o por soporte fuera del SLA).
  5. Revisa las garantías y penalizaciones: la propuesta que incluya cláusulas de descuento por retraso y SLA claros ofrece mayor seguridad.
  6. Utiliza una comparativa visual (una sola vez por artículo) para resaltar la opción que mejor cumple con los criterios críticos.

Propuesta A

  • Integración SUNAT sí
  • Plazo total 14 semanas
  • Soporte 12 meses, respuesta 8 h
  • Propiedad código cliente

Propuesta B

  • Integración SUNAT parcial
  • Plazo total 10 semanas
  • Soporte 6 meses, respuesta 24 h
  • Propiedad código proveedor

Conclusión

Al terminar este artículo deberías ser capaz de identificar las preguntas clave, exigir que todos los aspectos críticos estén documentados por escrito, reconocer señales de alarma que indican un riesgo elevado y comparar de forma objetiva dos propuestas que no hablan el mismo idioma. Con esa base, la decisión de invertir en un portal de clientes y proveedores será una elección informada que protege la operatividad, la seguridad y la competitividad de tu empresa en el entorno peruano.

  • #portales b2b
  • #proveedores
  • #clientes
  • #perú
  • #software a medida
Compartir:

Seguir leyendo

Otros artículos