Preguntas para contratar control de inventario

En la práctica diaria de una empresa peruana, la falta de visibilidad y precisión en el inventario se traduce en pérdidas, retrasos y sanciones de SUNAT. Si ya sabes qué es el control de inventario y almacenes, lo que realmente necesitas ahora son los criterios de evaluación que te permitan escoger al socio tecnológico correcto. En este artículo encontrarás las preguntas que deben guiar tu decisión, los documentos que deben quedar por escrito, señales de alarma y una guía práctica para comparar propuestas distintas.

Las preguntas que hay que hacer

• ¿Cuál es la arquitectura del sistema y cómo se integra con nuestros actuales ERP y con SUNAT?

  • Respuesta esperada: El proveedor detalla si la solución es modular, basada en API REST, y muestra diagramas de integración con los módulos de compras, ventas y la API de SUNAT para emisión de comprobantes electrónicos.
  • Señal de alerta: Respuestas vagas o “todo es compatible” sin ejemplos concretos.

• ¿Qué nivel de automatización de procesos de almacén ofrece (recepción, ubicación, picking, despacho) y cómo se configuran los flujos?

  • Respuesta esperada: Descripción de flujos configurables, posibilidad de usar códigos de barra o RFID, y ejemplos de reglas de negocio (por ejemplo, reorden automático cuando el stock cae al 20%).
  • Señal de alerta: Solo menciona “automatización básica” sin detallar cómo se adapta a diferentes tipos de productos.

• ¿Cómo se gestionan los usuarios y roles, y qué auditorías de cambios quedan registradas?

  • Respuesta esperada: Matriz de roles (operario, supervisor, jefe de almacén, auditor) y registro de trazabilidad con sello de tiempo, indispensable para cumplir con la normativa de la SUNAT y auditorías internas.
  • Señal de alerta: Falta de control de acceso granular o ausencia de logs de auditoría.

• ¿Qué métricas e indicadores (KPIs) se entregan por defecto y cómo se pueden personalizar?

  • Respuesta esperada: KPIs como rotación de inventario, nivel de servicio, tiempo de ciclo de picking, y la posibilidad de crear dashboards a medida con Power BI o herramientas propias.
  • Señal de alerta: Sólo informes estáticos en PDF sin opción de visualización en tiempo real.

• ¿Cuál es el modelo de licenciamiento y qué costos están asociados a actualizaciones, soporte y capacitación?

  • Respuesta esperada: Desglose claro: licencia perpetua o suscripción anual, porcentaje de tiempo dedicado a actualizaciones (por ejemplo, 10 % del proyecto) y número de horas de capacitación incluidas.
  • Señal de alerta: Ocultamiento de costos recurrentes o promesas de “actualizaciones gratuitas para siempre”.

• ¿Cómo se manejan los datos históricos y la migración desde nuestro sistema actual?

  • Respuesta esperada: Plan de migración con pruebas piloto, garantía de integridad de datos y tiempo estimado (por ejemplo, 4 semanas para 200 mil registros).
  • Señal de alerta: Falta de plan de pruebas o promesas de “importación automática” sin validar la calidad de los datos.

• ¿Qué garantías de disponibilidad y tiempo de respuesta ofrece el hosting (si es cloud) o el entorno on‑premise?

  • Respuesta esperada: SLA de 99,5 % de disponibilidad, tiempo máximo de respuesta de 2 segundos en consultas críticas y plan de contingencia con backups diarios.
  • Señal de alerta: Ausencia de SLA escrito o tiempos de respuesta no medidos.

• El sistema se vuelve lento al registrar una recepción. Indica mala arquitectura o falta de escalabilidad.
• Los usuarios no pueden acceder a módulos críticos fuera de horario. Señala problemas de permisos o de disponibilidad del servidor.
• Los reportes no coinciden con los conteos físicos. Refleja fallas en la lógica de inventario o en la integración.

Lo que tiene que estar por escrito

1. Alcance del proyecto – Definición exacta de módulos (recepción, ubicación, picking, despacho, reporting) y de los procesos que quedarán automatizados.
2. Entregables – Listado de artefactos: diagramas de arquitectura, manuales de usuario, scripts de migración, pruebas de aceptación (UAT) y documentación de API.
3. Plazos – Cronograma detallado en semanas: análisis (2 sem), diseño (3 sem), desarrollo (6 sem), pruebas (3 sem), capacitación (1 sem) y puesta en producción (1 sem). Cada fase debe incluir criterios de salida claros.
4. Soporte – Niveles de soporte (L1, L2, L3), tiempos de respuesta (ej.: 4 h para incidentes críticos) y canales (ticket, teléfono, videollamada). El contrato debe especificar la duración del soporte post‑implementación (mínimo 12 meses).
5. Propiedad del código – Acuerdo que indique que el código fuente es propiedad de tu empresa, con derechos de uso, modificación y mantenimiento sin cargos adicionales.

Señales de alarma

• El proveedor evita firmar un SLA. Sin un acuerdo de nivel de servicio, cualquier interrupción queda a su discreción.
• La propuesta incluye “personalización ilimitada” sin estimar esfuerzo. Cada cambio implica tiempo de desarrollo; la ausencia de estimaciones oculta costes futuros.
• Solo ofrecen capacitación “online” sin sesiones presenciales. En el contexto peruano, la adopción suele requerir talleres prácticos para operarios.
• El contrato menciona “software como servicio” pero no indica dónde se alojan los datos. La legislación peruana exige que los datos críticos de la empresa estén bajo control del responsable.

Cómo comparar dos propuestas distintas

1. Normaliza la unidad de medida – Convierte todas las ofertas a un coste total de propiedad (TCO) en semanas‑hombre y porcentaje de esfuerzo de configuración. Por ejemplo, si la Propuesta A indica 8 semanas de desarrollo y 2 semanas de pruebas, y la Propuesta B solo menciona “implementación rápida”, solicita desglosar los mismos ítems.
2. Matriz de criterios – Usa una tabla con columnas: Funcionalidad cubierta, Nivel de integración SUNAT, Tiempo de entrega, Soporte incluido, Propiedad del código y Riesgos identificados. Asigna una puntuación (1‑5) a cada criterio y suma.
3. Evalúa la alineación con tus procesos – Marca en la tabla los procesos críticos de tu empresa (por ejemplo, “reorden automático al 15 % del stock”). La propuesta que cubra más procesos sin necesidad de personalizaciones extra gana.
4. Revisa la flexibilidad – Pregunta cómo se manejarían cambios futuros (nuevas ubicaciones, nuevos canales de venta). La respuesta debe incluir estimación de tiempo (ej.: “cambio de regla de reorden: 2 días de desarrollo”).
5. Haz una prueba piloto – Si ambas opciones pasan la tabla, solicita una prueba de 2 semanas con datos reales. Evalúa velocidad, precisión y facilidad de uso antes de decidir.

Conclusión

Al terminar la lectura, tendrás una lista concreta de preguntas que cualquier proveedor serio debe responder, un checklist de documentos que deben quedar firmados y un método estructurado para comparar ofertas sin caer en sorpresas de coste o funcionalidad. Con esa base, tu empresa podrá seleccionar la solución de control de inventario que realmente se ajuste a sus procesos, a la normativa peruana y a sus planes de crecimiento, minimizando riesgos y asegurando un retorno de inversión medible.