LOGYX
Infraestructura digital colaborativa para la logística de PYMEs del corredor Lima – Arequipa – Juliaca – Puno – Cusco.
Toda la documentación, en un solo lugar
El detalle completo de los tres entregables (Software, Gestión de TI e Infraestructura) vive en un sitio MkDocs versionado en GitHub, con respaldo en PDF/DOCX por área y el prototipo navegable en Figma.
Sitio MkDocs
Documentación técnica navegable por entregable y sub-competencia, con tabla de contenidos y búsqueda.
Abrir sitio →Repositorio GitHub
Fuente versionada de todo el contenido, historial de cambios y el pipeline de despliegue automático.
Ver repositorio →Prototipo Figma
Prototipo navegable de las tres apps del ecosistema: LOGYX Business, Driver y Operator.
Ver prototipo →La logística fragmentada le cuesta más caro al pequeño
Las PYMEs del corredor Lima–Sierra Sur coordinan su transporte de manera informal —WhatsApp, llamadas, Excel— sin poder de negociación frente a intermediarios y "hombres-camión" que atomizan la oferta.
La tesis del proyecto: la colaboración entre PYMEs fragmentadas puede replicar el poder de negociación logístico de una gran corporación.
21.1%
de las ventas se va en costos logísticos para microempresas (ComexPerú, 2022)
3.0/5
Logistics Performance Index del Perú (Banco Mundial, 2023)
2.3M+
MIPYMEs formales en el Perú (PRODUCE, 2025)
15.3%
margen típico de un broker logístico tradicional
Un marketplace B2B con reglas claras
Marketplace + Subasta Inversa
PYMEs publican solicitudes de carga; transportistas verificados compiten por precio y calidad en una ventana de tiempo controlada.
Motor de Costos
Precio de referencia con distancias reales antes de publicar.
Tracking Multi-Parada
Estados en tiempo real con evidencia fotográfica y firma.
Smart Load Planner
Consolidación de cargas y aprovechamiento de retornos.
Reputación
Trust Score compuesto por cumplimiento, puntualidad y calidad.
Comisión escalonada por lealtad
2%–8%
TAM
2.3M+
SAM
~50k
SOM
200
Ingresos por transacción, no por suscripción
LOGYX cobra una comisión escalonada de 2% a 8% sobre cada transacción completada — muy por debajo del margen de un broker tradicional (15.3%). El mercado objetivo son las PYMEs y transportistas del corredor Lima–Arequipa–Juliaca–Puno–Cusco, con una meta de 200 empresas activas y punto de equilibrio hacia la semana 24 del MVP.
Área de Gestión de TI
Competencia CE01 — Gestión e Innovación de TI. Diagnostica brechas, prioriza iniciativas, justifica inversiones y orienta la tecnología hacia resultados organizacionales, bajo el modelo CDIO y estándares PMBOK / Gobierno de TI / Gestión de Procesos.
E1 · Diagnóstico
Alineamiento estratégico y organizacional
E2 · Business Case
Viabilidad económica del proyecto
E3 · Plan de Gestión
PMBOK + Ágil, WBS, riesgos
E4 · Procesos
Modelado AS-IS / TO-BE
Diagnóstico bajo doble lente
El análisis interno evalúa a LOGYX como organización (equipo, finanzas, tecnología); el análisis externo evalúa el ecosistema logístico PYME–transportista representado mediante una PYME arquetipo.
Se cierra con un análisis de Gobierno de TI bajo COBIT 2019, que identifica las obligaciones normativas (Ley N° 29733, PCI-DSS) que la solución técnica debe satisfacer desde su diseño.
AMOFHIT
Análisis interno por áreas funcionales
EFI / EFE
Matrices de factores internos y externos
Porter
Cinco fuerzas del microentorno
PESTEL
Macroentorno político, social, tecnológico
FODA / CAME
Cruce estratégico y plan de acción
COBIT 2019
Gobierno de TI y riesgo normativo
Un ecosistema con ocho tipos de actores
PYMEs del corredor
Poder bajo · Interés alto
Empresas transportistas
Poder medio · Interés alto
Transportistas independientes
Poder bajo · Interés alto
Brokers informales
Interés contrario · a monitorear
Asociaciones (Juliaca, Puno)
Poder alto · gestionar de cerca
Cámaras de comercio
Poder alto · mantener satisfechos
MTC / SUNAT
Reguladores · poder alto
Clientes finales
Poder bajo · interés medio
Ishikawa: seis espinas, una causa raíz
Cuatro de las seis espinas del diagrama causa–efecto corresponden a problemas de coordinación e información, no a limitaciones físicas del transporte.
Método
Sin proceso definido; búsqueda por 5–10 contactos personales
Información
Sin referencia de precios ni historial de desempeño de transportistas
Tecnología
Herramientas genéricas; cero trazabilidad (sin GPS ni evidencia digital)
Personas
Función logística dispersa; dependencia de la memoria del gerente
Mercado
Oferta atomizada sin agregación; intermediarios sin tecnología
Entorno
Infraestructura vial vulnerable; informalidad y débil fiscalización
Causa raíz sistémica: ausencia de una capa de información compartida entre los actores del corredor.
El diagnóstico interno y externo coinciden
Posición interna balanceada: fortalezas técnicas y de producto sólidas, contrarrestadas por debilidades típicas de una startup en validación de mercado y capital.
El ecosistema responde débilmente a sus propias oportunidades y amenazas — no existen aún mecanismos para capitalizarlas sin una intervención activa como LOGYX.
Cruce estratégico CAME (ejemplos)
El EPE es la primera parada, no el destino
Tres horizontes tecnológicos: el MVP evaluado en este EPE corresponde íntegramente a H1.
Digitalizar la transacción
Reemplazar la coordinación informal.
Marketplace · subasta · negociación registrada · tracking · evidencia · verificación legal
Optimizar la red
Capturar la eficiencia estructural.
Consolidación inteligente · retornos · pricing dinámico · reputación · escrow
Inteligencia y servicios
Convertir datos en valor predictivo.
Predicción de demanda · ML · cooperativas · factoring logístico
Por qué construir LOGYX, y para qué exactamente
Puntaje ponderado de alternativas
Ventaja decisiva en cobertura de FCE y escalabilidad, sobre statu quo, broker tradicional y SaaS genérico.
Objetivos SMART (OP1–OP6)
- OP1MVP operativo en 16 semanas
- OP220 transportistas verificados a la semana 4
- OP380 PYMEs activas y NPS ≥ 45 a la semana 12
- OP4200 empresas y punto de equilibrio a la semana 24
- OP5≥ 60% de solicitudes con oferta en 24h desde el mes 2
- OP6Contratación de flete: de días a < 60 minutos
Business Case: viabilidad financiera clara
Inversión inicial acotada frente a un modelo de ingresos de bajo capital intensivo ("asset-light"), típico de startups de software.
Inversión inicial
S/ 20,966
TCO a 24 meses
S/ 68,966
Payback
Mes 11–12
VAN (18% anual)
S/ 370,829
Incluso en el escenario conservador (50% del volumen proyectado) el proyecto recupera su inversión dentro del horizonte de 24 meses: VAN de S/ 156,532 y payback en el mes 15–16.
PMBOK para el gobierno, Scrum para la ejecución
El plan adopta un enfoque híbrido: Project Charter, EDT/WBS y línea base de costos bajo buenas prácticas PMBOK, mientras el desarrollo se ejecuta en 8 sprints de dos semanas con métricas de velocidad — con evidencia real de configuración en Azure DevOps.
Hitos de alto nivel
- H1Arquitectura y módulos base
- H2Marketplace y subastas operativas
- H3Tracking y app del conductor
- H4MVP integrado en staging
- H5MVP en producción y demo final
El plan no es solo un documento
Project Charter
- Sponsor: Docente responsable EPE — GTI
- Director: Fabrizio Sánchez Saravia
- Éxito: MVP desplegado y demostrable, flujo E2E funcionando
- Supuesto: 15h/semana por integrante
WBS · 4 cuentas de control
- 1. Gestión del proyecto
- 2. Plataforma — núcleo transaccional
- 3. Plataforma — operación y confianza
- 4. Infraestructura y despliegue
Evidencia en Azure DevOps
Proyecto real configurado (organización fabriziosanchezs): 8 sprints con fechas exactas, backlog de épicas e historias de usuario cargado, y distribución visible en Sprint Backlog y Taskboard.
El gobierno de TI baja a requerimientos reales
El análisis COBIT 2019 de Gestión TI (E1 1.7 / E3 3.7) no se quedó en el diagnóstico: generó requerimientos no funcionales concretos ya incorporados en el SRS de Software.
| Obligación (Ley N° 29733 / PCI-DSS) | Requerimiento en Software |
|---|---|
| Política de privacidad pública (Art. 18) | RNF17 |
| Consentimiento informado en onboarding (Art. 13) | RNF18 + columna consent_accepted_at |
| Registro de tratamiento y notificación de brechas ≤72h | RNF19 |
| No almacenar datos de tarjeta (PCI-DSS) | RNF20 — tokenización delegada |
De la informalidad al proceso trazable
Coordinación informal
WhatsApp, llamadas y Excel; sin trazabilidad ni verificación del transportista, con visibilidad nula del estado del envío.
- • Recorridos en vacío: 40–45%
- • Costo logístico/ventas PYME: 21.1%
- • Contactos necesarios por envío: 5–10
- • Envíos con evidencia formal: 0%
Plataforma digital LOGYX
Marketplace con verificación legal, tracking en tiempo real y trazabilidad completa del proceso logístico.
- • Publicación → primera oferta: < 60 min
- • Solicitudes con oferta en 24h: ≥ 60%
- • Evidencia de entrega en plataforma: 100%
- • Desviación vs. precio de referencia: monitoreada
Toolkit completo de Lean Six Sigma aplicado al caso LOGYX (sección 4.6).
Cada tarea manual, un mecanismo digital
Precio de referencia
Reemplaza la negociación a ciegas: motor de costos con distancia real + histórico del corredor
Matching automático
Reemplaza 5–10 llamadas manuales: notificación a transportistas verificados compatibles
Cierre de subasta
Reemplaza la presión telefónica: cierre automático por tiempo u ofertas, reglas iguales
Negociación moderada
Reemplaza acuerdos verbales: chat con registro íntegro y bloqueo de contacto externo
Trazabilidad y evidencia
Reemplaza "llamar al chofer": estados por parada + foto y firma, funciona offline
Cargas de retorno
Reemplaza el retorno en vacío: búsqueda automática de cargas cercanas al destino
Riesgo identificado, no riesgo ignorado
Riesgos estratégicos (matriz E1)
- Resistencia cultural al cambio (statu quo WhatsApp) 20 · Crítico
- Arranque en frío del marketplace 20 · Crítico
- Desintermediación fuera de plataforma 12 · Alto
- Dependencia de infraestructura vial vulnerable 12 · Alto
Riesgos de proyecto (matriz E3)
- Disponibilidad del equipo menor a la planificada 16 · Alto
- Subestimación de complejidad (consolidación/retornos) 12 · Medio
- Bloqueos por dependencias externas (APIs) 9 · Medio
- Pérdida de un integrante (salud, retiro del curso) 8 · Medio
De los requerimientos al sistema desplegado
Backend en Quarkus, frontend web en Angular y tres apps móviles en Flutter, sobre PostgreSQL.
E1 · Sistema
SRS, prototipos, C4, UML
E2 · Base de Datos
Modelo, SQL, seguridad
E3 · Sistema
Implementación y despliegue
E4 · Validado
Pruebas, CI/CD, auditoría
E5 · Sustentación
Video pitch y defensa
Backlog · 16 épicas del producto
67 requerimientos, 5 decisiones que los sostienen
El SRS documenta 67 requerimientos funcionales (RF01–RF67) trazables a la arquitectura. Cinco ADRs (Architecture Decision Records) justifican las decisiones clave:
Monolito modular
Punto de partida, migrable a microservicios
Quarkus
Reactive, bajo footprint, nativo con GraalVM
3 apps Flutter
Business, Driver y Operator separadas
PostgreSQL único
Integridad referencial fuerte
OpenRouteService
Cálculo de rutas para el motor de costos
Del diseño a la operación confiable
Dos semestres: diseño primero, implementación y control después.
Semestre 1 · Diseño
- C1.1 — Diseño de red (VLAN, DMZ, redundancia)
- C2.1 — Planificación de seguridad (ISO 27005 / NIST)
- C3.1 — Diseño de centro de datos (Tier I–IV)
Semestre 2 · Implementación
- C1.2/C1.3 — Configuración y testing de red
- C2.2–C2.4 — Controles, monitoreo y ética ACM
- C3.2/C3.3 — Servidores, almacenamiento y SLA
Estándares aplicados
Roles claros, red segmentada
La planificación de seguridad define una matriz RACI que asigna responsable, aprobador, consultado e informado para cada control — evitando ambigüedad operativa en un equipo pequeño.
El diseño de red traduce los estándares tradicionales (VLAN, DMZ) a una VPC de AWS multi-AZ, con subnets públicas y privadas segmentadas por función.
VPC LOGYX — 10.0.0.0/16 (sa-east-1)
├─ AZ-A (sa-east-1a)
│ ├─ pública-A · 10.0.1.0/24 · ALB + NAT
│ ├─ app-A · 10.0.10.0/24 · Quarkus / ECS
│ └─ datos-A · 10.0.20.0/24 · RDS primary
└─ AZ-B (sa-east-1b)
├─ pública-B · 10.0.2.0/24 · ALB failover
├─ app-B · 10.0.11.0/24 · Quarkus / ECS
└─ datos-B · 10.0.21.0/24 · RDS standby
Fabrizio Sánchez · Alex Coila · Jorge Gutiérrez
Universidad Peruana Unión — Facultad de Ingeniería y Arquitectura, Escuela de Ingeniería de Sistemas · Juliaca, Perú