ConTodo
Product Manager

ConTodo ERP — Product Management: Visión, Roadmap, MoSCoW, Epics y MVP

ConTodo ERP — Documento de Product Management

Propósito de este documento. Define la estrategia de producto de ConTodo, un ERP SaaS cloud-native multi-tenant para PYMEs y medianas empresas de Perú y LATAM. Cubre la Product Vision, el Roadmap de alto nivel, la priorización MoSCoW de los 18 módulos, la descomposición en Epics → Features → User Stories con criterios de aceptación, la definición precisa del MVP y el Definition of Done transversal. Este artefacto es la fuente de verdad para Arquitectura, Backend, Frontend, QA y Go-to-Market.


1. Product Vision

1.1 Vision Statement

Para PYMEs y medianas empresas textiles, importadoras, comercializadoras, distribuidoras y de manufactura ligera en Perú y LATAM, que sufren con software contable fragmentado, on-premise, caro de mantener y desconectado de SUNAT, ConTodo es un ERP SaaS cloud-native multi-tenant que unifica operación, contabilidad y cumplimiento tributario en una sola plataforma, con cumplimiento SUNAT nativo (CPE, PLE, SIRE), multimoneda y multiempresa de fábrica. A diferencia de Defontana, StarSoft, CONCAR, SISCONT, Ofisis (legacy, on-premise o desktop) y de Odoo/SAP B1/NetSuite (genéricos, sin cumplimiento peruano nativo y de implementación costosa), nuestro producto entrega time-to-value en días, no meses, a un TCO 40–60% menor, con la profundidad fiscal de un producto local.

1.2 Pilares estratégicos del producto

PilarDescripciónMétrica de éxito (North Star alineada)
Cumplimiento como ventajaSUNAT nativo: CPE (factura/boleta/NC/ND/GRE), PLE 5.x, SIRE (RVIE/RCE), detracciones, percepciones, retenciones, PDT/PLAME.% de documentos aceptados por SUNAT en 1er intento ≥ 99.5%
Time-to-valueOnboarding guiado, plantillas por vertical (textil, importadora, distribuidora), data import asistido.Mediana de días hasta 1ra factura emitida ≤ 5
Cloud-native realMulti-tenant, elástico, alta disponibilidad, sin instalaciones.Uptime ≥ 99.9% mensual
Operación + Finanzas integradasKardex valorizado, costeo, asientos automáticos desde operación.% de asientos generados automáticamente ≥ 85%
IA prácticaConciliación, categorización, forecasting, asistente conversacional.Horas/mes ahorradas por usuario contable ≥ 8

North Star Metric: Documentos electrónicos válidos procesados por mes por tenant activo — captura adopción, valor operativo y dependencia del producto.

1.3 Personas objetivo

PersonaRolDolor principalQué espera de ConTodo
GloriaContadora / Jefa de ContabilidadCierre mensual manual, exportar PLE/SIRE en herramientas separadasAsientos automáticos, PLE/SIRE en 1 clic, EEFF en tiempo real
MarcoGerente General / Dueño PYMENo ve márgenes reales ni caja proyectadaDashboard de caja, márgenes por línea, alertas
LucíaJefa de Almacén / LogísticaDescuadres de stock, no sabe valorizaciónKardex multi-almacén valorizado en línea
AnaJefa de Compras / ImportacionesCosteo de importación en Excel, DUAs sueltasCosteo de importación automático prorrateado
DiegoVendedor / CRMCotiza fuera del sistema, sin seguimientoCotización → pedido → factura en un flujo

2. Product Roadmap (alto nivel)

Roadmap por horizontes de 18 meses post-kickoff, orientado a outcomes (no a fechas rígidas). Cada fase libera valor utilizable y vendible.

FaseOutcome de negocioMódulos liberadosHito comercial
F0 — FundacionesPlataforma segura, lista para clientes pilotoSeguridad, Usuarios, EmpresasEntorno listo para 3 pilotos
F1 — MVPEmpresa puede facturar y controlar stock cumpliendo SUNATInventario/Kardex, Compras, Ventas, Tesorería (básica)Primeros clientes de pago
F2 — Profundidad financieraCierre contable y EEFF en plataformaContabilidad, Estados Financieros, Importaciones, LogísticaReemplazo de CONCAR/SISCONT
F3 — VerticalizaciónManufactura textil y comercial completaProducción, CRM, Multimoneda completaPenetración vertical textil
F4 — Talento + IASuite ERP completa con analíticaRRHH, Planillas, BI, IAUpsell, expansión LATAM

3. Priorización MoSCoW de los 18 módulos

Criterio de priorización ponderado (1–5): Valor de negocio (BV), Urgencia regulatoria (RG), Dependencia técnica/habilitador (DEP), Esfuerzo inverso (ESF, mayor = más barato). Score = BV*0.35 + RG*0.30 + DEP*0.20 + ESF*0.15.

#MóduloBVRGDEPESFScoreMoSCoWFase
1Seguridad54534.40MustF0
2Usuarios53544.25MustF0
3Empresas (multiempresa/sucursal)54534.40MustF0/F1
4Inventario (multialmacén)52533.80MustF1
5Kardex (valorizado)54434.20MustF1
6Compras54434.20MustF1
7Ventas (CPE)55434.50MustF1
8Tesorería43333.35ShouldF1/F2
9Contabilidad (PCGE, PLE, SIRE)55424.35MustF2
10Estados Financieros44333.65ShouldF2
11Importaciones (costeo, DUA)42322.90ShouldF2
12Logística32332.70ShouldF2
13Producción (manuf. textil)41222.55CouldF3
14CRM31242.35CouldF3
15Multimoneda (full FX/ajuste)43333.35ShouldF3
16RRHH32232.50CouldF4
17Planillas (PLAME/AFPnet)45213.45ShouldF4
18BI + IA41122.35Won't (this release) / CouldF4

Notas de priorización. Multiidioma y Multimoneda básica (registro) se tratan como capacidades transversales habilitadas desde F0 a nivel de plataforma (i18n, columna de moneda + tipo de cambio SUNAT), pero la conversión/ajuste por diferencia de cambio contable se prioriza como Should en F3. La IA se marca Won't en el release inicial y se reclasifica a Could cuando exista masa de datos suficiente; introducirla antes sería overclaiming sin valor verificable.


4. Epics, Features y User Stories

Estructura jerárquica: Epic (objetivo de negocio) → Feature (capacidad) → User Story (incremento entregable con criterios de aceptación en formato Gherkin Given/When/Then).

Epic 1 — Plataforma Multi-Tenant Segura (Must, F0)

Feature 1.1 — IAM, autenticación y RBAC multirol

  • US-1.1.1 — Como administrador de empresa quiero crear roles con permisos granulares por módulo y acción para garantizar segregación de funciones (SoD).
    • Criterios de aceptación:
      • Dado un admin con rol "Owner", cuando crea un rol "Cajero" con permiso tesoreria:read y tesoreria:cobrar, entonces ese rol no puede acceder a contabilidad:*.
      • El sistema impide guardar un rol sin al menos un permiso.
      • Toda asignación/revocación de permiso queda en audit log con usuario, IP y timestamp (UTC-5).
  • US-1.1.2 — Como usuario quiero autenticarme con email+contraseña y MFA opcional (TOTP) para proteger mi cuenta.
    • Criterios: Bloqueo tras 5 intentos fallidos en 10 min; sesión expira a los 30 min de inactividad; MFA obligatorio para roles con acceso a contabilidad o tesoreria.

Feature 1.2 — Aislamiento y contexto multi-tenant / multiempresa / multisucursal

  • US-1.2.1 — Como usuario de un grupo empresarial quiero cambiar de empresa y sucursal activa sin re-login para operar varias razones sociales con una sola cuenta.
    • Criterios: El cambio de empresa filtra todos los datos por tenant_id+company_id; ningún query devuelve filas de otra empresa (test de aislamiento automatizado); la sucursal activa determina el almacén y serie de comprobante por defecto.

Epic 2 — Facturación Electrónica SUNAT (Must, F1)

Feature 2.1 — Emisión de Comprobantes de Pago Electrónicos (CPE)

  • US-2.1.1 — Como vendedor quiero emitir una factura electrónica desde un pedido para cumplir con SUNAT y cobrar al cliente.
    • Criterios:
      • Dado un pedido confirmado con RUC válido (validación módulo 11), cuando emito factura, entonces se genera UBL 2.1 firmado, se envía al OSE/SUNAT y se obtiene CDR de aceptación.
      • Si SUNAT rechaza, el motivo se muestra legible y el comprobante queda en estado rechazado (no consume correlativo si la regla aplica).
      • Soporta factura, boleta, nota de crédito, nota de débito y guía de remisión electrónica (GRE).
      • Cálculo correcto de IGV 18%, detracción (cuando bien/servicio afecto), percepción y retención.

Feature 2.2 — SIRE (RVIE/RCE) y PLE 5.x

  • US-2.2.1 — Como contadora quiero generar y exportar el SIRE (Registro de Ventas e Ingresos y de Compras) para cumplir la obligación mensual sin doble digitación.
    • Criterios: Genera propuesta RVIE/RCE en formato vigente; permite conciliar contra registros internos marcando diferencias; exporta TXT/archivo compatible con SUNAT; PLE 5.x para libros electrónicos restantes.

Epic 3 — Control de Inventario Valorizado (Must, F1)

Feature 3.1 — Kardex multi-almacén valorizado

  • US-3.1.1 — Como jefa de almacén quiero ver el stock y la valorización en tiempo real por almacén para evitar quiebres y descuadres.
    • Criterios: Toda entrada/salida/transferencia actualiza saldo y costo según método configurado (PEPS o Promedio Ponderado); el Kardex cuadra con el saldo del módulo de inventario al céntimo; soporta unidades de medida y conversiones.

Epic 4 — Ciclo Compra-Venta (Must, F1)

Feature 4.1 — Cotización → Pedido → Factura

  • US-4.1.1 — Como vendedor quiero convertir una cotización aprobada en pedido y luego en factura para no re-digitar datos y evitar errores.
    • Criterios: Trazabilidad documental (cotización↔pedido↔factura↔guía); control de precios/descuentos por política; bloqueo si excede línea de crédito del cliente.

El backlog completo contempla Epics adicionales para Contabilidad (asientos automáticos, PCGE), Importaciones (costeo prorrateado por DUA), Producción (BOM y órdenes de fabricación textil), Planillas (PLAME/AFPnet) y BI/IA, detallados en F2–F4.


5. Definición del MVP

5.1 Alcance Mínimo Viable (In Scope)

El MVP debe permitir a una comercializadora/importadora pequeña operar de punta a punta cumpliendo SUNAT:

Capacidad MVPIncluyeExcluye (post-MVP)
Seguridad + Usuarios + RBACLogin, MFA, roles, audit logSSO SAML/OAuth corporativo
Multiempresa / multisucursal / multialmacénContexto y aislamientoConsolidación multi-empresa contable
Inventario + KardexStock por almacén, valorización PromedioPEPS avanzado, lotes/series, vencimientos
ComprasOC, recepción, registro de compraCotización a proveedores, aprobaciones multinivel
Ventas + CPECotización→pedido→factura/boleta/NC/ND/GRE, IGV, detracciónPercepción/retención avanzada, e-commerce
Tesorería básicaRegistro de cobros/pagos, caja, bancosConciliación bancaria automática
Reportes operativosVentas, compras, stock, libro cajaEEFF completos (van en F2)
SIRE / PLE básicoRVIE/RCE exportPLE 100% libros

5.2 Out of Scope explícito del MVP

Contabilidad completa con asientos automáticos, Estados Financieros, Importaciones con costeo, Logística avanzada, Producción, CRM, RRHH, Planillas, BI, IA, conciliación bancaria automática, multimoneda con ajuste por diferencia de cambio. (Se documenta para evitar scope creep.)

5.3 Criterios de éxito del MVP (medibles)

MétricaObjetivo MVP
Tiempo a 1ra factura emitida (onboarding)≤ 5 días
Tasa de aceptación SUNAT 1er intento≥ 99%
Pilotos activos facturando≥ 3 empresas
p95 de latencia de emisión CPE≤ 3 s
Descuadre de Kardex vs Inventario0 céntimos

6. Definition of Done (DoD) — transversal

Una historia/feature se considera Done solo si cumple todos los siguientes ítems:

  • Código revisado (≥1 reviewer) y mergeado a main sin warnings de lint.
  • Pruebas unitarias y de integración con cobertura ≥ 80% en la lógica nueva; pruebas de aislamiento multi-tenant verdes.
  • Criterios de aceptación (Gherkin) validados por QA en entorno staging.
  • Cumplimiento SUNAT validado en homologación cuando la historia toca CPE/SIRE/PLE.
  • Migraciones de DB reversibles y probadas; sin downtime requerido.
  • Observabilidad: logs estructurados, métricas y trazas; audit log donde aplique.
  • Seguridad: sin secretos en código, validación de permisos RBAC, datos PII cifrados en reposo.
  • Documentación de usuario y de API actualizada; release notes redactadas.
  • Accesibilidad (WCAG 2.1 AA) y soporte i18n (es-PE base) en componentes UI.
  • Product Owner acepta la demo.

7. Riesgos y oportunidades

7.1 Riesgos

IDRiesgoProb.ImpactoMitigación
R1Cambios normativos SUNAT (SIRE/PLE) durante desarrolloAltaAltoCapa de cumplimiento aislada y versionada; monitoreo regulatorio; OSE como buffer
R2Subestimación de Contabilidad/PCGE (módulo complejo)MediaAltoSpike técnico temprano; contadora en el equipo; no comprometer F2 sin descubrimiento
R3Scope creep por pedidos de pilotosAltaMedioMoSCoW estricto; backlog priorizado; "Won't" documentado
R4Fuga de datos entre tenantsBajaCríticoTests de aislamiento automatizados en CI; RLS/scoping obligatorio
R5Sobreventa de IA sin datos suficientesMediaMedioIA como Won't inicial; anti-overclaiming; liberar con métricas reales
R6Migración de datos legacy (CONCAR/Excel) de clientesAltaMedioImportadores asistidos y plantillas; servicio de onboarding

7.2 Oportunidades

IDOportunidadAcción de producto
O1Reemplazo de software legacy on-premise (CONCAR/SISCONT/desktop)Mensaje "migra sin perder tu historia"; importadores nativos
O2Verticalización textil (BOM, costeo de producción) como diferenciadorPlantillas y módulo Producción en F3
O3Cumplimiento como gancho de venta en LATAM (Colombia DIAN, Chile SII)Arquitectura de cumplimiento pluggable por país
O4Pago local Yape/Plin + conciliación para tesoreríaIntegración en F2/F3, alto valor PYME
O5IA práctica (conciliación, categorización, forecast de caja) sobre datos propiosLiberar en F4 con métricas de ahorro verificables

8. Decisiones y alternativas consideradas

  • MVP comercial+fiscal vs MVP contable. Se eligió priorizar el ciclo compra-venta + CPE porque genera ingreso y adopción inmediata; un MVP "contable primero" tendría mayor complejidad y menor time-to-value. Alternativa descartada: arrancar por Contabilidad/EEFF (alto esfuerzo, demo poco vendible).
  • IA diferida. Se descarta IA temprana por falta de datos y riesgo de overclaiming; alternativa de "IA como wrapper de LLM genérico" rechazada por no aportar valor verificable.
  • Multimoneda escalonada. Registro multimoneda desde F0 (barato), pero ajuste contable por diferencia de cambio en F3 (complejo) — evita pagar complejidad sin demanda inmediata.

Documento vivo — propiedad del Product Manager de ConTodo. Próxima revisión al cierre de F0.