1. Introducción al Análisis
El presente documento presenta el análisis exhaustivo del sistema RutaCC, abordando el dominio del negocio, los actores involucrados, los procesos críticos y las consideraciones técnicas que sustentan la solución propuesta.
El análisis se realiza considerando el contexto de las empresas de transporte y logística en Chile, que enfrentan desafíos como:
- Gestión manual de flotas con herramientas dispersas (Excel, papel)
- Falta de control sobre costos operativos
- Dificultad para cumplir con normativas de documentación vehicular
- Ausencia de indicadores de gestión confiables
- Procesos de despacho ineficientes y poco trazables
2. Análisis del Dominio
2.1 Contexto del Negocio
El dominio corresponde a la gestión logística de empresas de transporte y distribución. Las empresas del sector necesitan coordinar múltiples recursos (vehículos, conductores, bodegas) para entregar pedidos a clientes en distintas ubicaciones geográficas.
2.2 Problema Central
Problema identificado: Las empresas de transporte gestionan sus operaciones con herramientas manuales o sistemas básicos que no permiten:
• Optimizar rutas de despacho
• Controlar costos en tiempo real
• Mantener documentación al día
• Tener visibilidad completa de las operaciones
2.3 Oportunidad
Un sistema SaaS centralizado puede resolver estos problemas ofreciendo:
- Centralización: Toda la información en una sola plataforma
- Automatización: Alertas, cálculos y reportes automáticos
- Optimización: Planificación inteligente de rutas
- Trazabilidad: Seguimiento completo de cada despacho
- Escalabilidad: Modelo multi-tenant para múltiples empresas
2.4 Términos del Dominio
| Término | Definición | Ejemplo |
|---|
| Despacho | Operación de entrega que agrupa pedidos, vehículo y conductor | Despacho OD.N° 1254 con 4 pedidos |
| Bodega | Punto de origen físico desde donde salen los despachos | Bodega Central, Bodega Sur |
| Pedido | Solicitud de entrega con dirección y cliente | Pedido a "Katrina Rojas" en Ñuñoa |
| Mantención | Servicio preventivo o correctivo al vehículo | Cambio de aceite a los 90.000 km |
| Fallo | Avería o problema mecánico del vehículo | Reventón de neumáticos |
| SOAP | Seguro obligatorio de accidentes personales | Vence el 2027-05-15 |
| Revisión Técnica | Certificación de condiciones mecánicas | Cada 6 meses o 1 año |
3. Identificación de Actores
3.1 Actores Primarios
| Actor | Descripción | Objetivos |
|---|
| Administrador |
Dueño o gerente de la empresa de transporte |
• Tener control total de la operación
• Ver reportes financieros
• Gestionar usuarios y permisos
• Tomar decisiones estratégicas |
| Despachador |
Encargado de planificar y ejecutar despachos |
• Crear despachos eficientes
• Asignar pedidos a vehículos
• Planificar rutas óptimas
• Hacer seguimiento en tiempo real |
| Conductor |
Persona que opera el vehículo |
• Conocer su ruta de entrega
• Registrar novedades
• Confirmar entregas |
3.2 Actores Secundarios
| Actor | Descripción |
|---|
| Mantenedor | Responsable de gestionar mantenimientos y fallos |
| Contador/Finanzas | Revisa costos, cobros y reportes financieros |
| Visitante / Prospecto | Persona sin cuenta que evalúa contratar RutaCC desde las páginas públicas; interactúa con el chatbot comercial |
Nota: el alta de nuevas empresas (tenants) y la asignación de sus módulos habilitados es una
operación interna del equipo de Intelliti para administrar la plataforma SaaS — no es un actor ni un caso de uso
del producto que ve el cliente, por lo que queda fuera del análisis de actores.
4. Casos de Uso Principales
4.1 Caso de Uso: Crear Despacho
Actor: Despachador
Precondición: Existen vehículos disponibles, conductores disponibles y pedidos pendientes
Flujo principal:
1. Despachador selecciona bodega de origen
2. Selecciona vehículo y conductor
3. Sistema calcula distancia, combustible y costo estimado
4. Despachador confirma la creación del despacho
5. Sistema genera número de orden único
6. Estado cambia a "creada"
Postcondición: Despacho creado con estado "creada"
4.2 Caso de Uso: Planificar Ruta
Actor: Despachador
Precondición: Existe un despacho con pedidos asignados
Flujo principal:
1. Despachador ingresa al planificador de ruta
2. Sistema muestra pedidos asignados en el mapa
3. Despachador ordena los pedidos (drag & drop)
4. Sistema calcula hora estimada de llegada por pedido
5. Despachador guarda el orden
6. Sistema actualiza el campo "orden" de cada pedido
Postcondición: Ruta planificada con orden de entrega definido
4.3 Caso de Uso: Iniciar Despacho
Actor: Despachador / Conductor
Precondición: Despacho en estado "planificada"
Flujo principal:
1. Se ingresa kilometraje de salida del vehículo
2. Se registra hora real de salida
3. Sistema actualiza estado a "en_ruta"
4. Sistema actualiza estado del vehículo a "en_ruta"
5. Sistema actualiza estado del conductor a "en_ruta"
Postcondición: Despacho en ejecución
4.4 Caso de Uso: Finalizar Despacho
Actor: Conductor / Despachador
Precondición: Despacho en estado "en_ruta" o "en_entrega"
Flujo principal:
1. Se ingresa kilometraje de llegada
2. Se registran observaciones finales
3. Sistema calcula distancia real, duración y velocidad media
4. Sistema actualiza estado a "finalizada"
5. Sistema libera vehículo y conductor
Postcondición: Despacho finalizado con datos reales
4.5 Caso de Uso: Registrar Mantención
Actor: Administrador / Mantenedor
Flujo principal:
1. Selecciona vehículo
2. Ingresa tipo (preventiva/correctiva), motivo, fechas, costo, taller
3. Ingresa kilometraje actual y próxima mantención
4. Sistema cambia estado del vehículo a "mantencion"
Postcondición: Mantención registrada
4.6 Caso de Uso: Ver Posición en Vivo de la Flota
Actor: Despachador / Administrador
Precondición: Al menos un conductor tiene la app OwnTracks o GPSLogger configurada y transmitiendo
Flujo principal:
1. Usuario abre el módulo de Tracking en vivo
2. Sistema muestra un mapa con la última posición conocida de cada vehículo
3. Usuario revisa la hora de la última actualización de cada posición
4. Usuario puede abrir el historial de ruta de un despacho pasado
Postcondición: Usuario tiene visibilidad del estado y ubicación actual de la flota
4.7 Caso de Uso: Consultar al Asistente Virtual
Actor: Usuario autenticado (ayuda) / Visitante público (venta)
Precondición: El widget de chat está disponible en la página (siempre en el sistema autenticado; en páginas públicas seleccionadas para el chat comercial)
Flujo principal:
1. Usuario abre la burbuja de chat
2. Usuario escribe una pregunta
3. Sistema envía el mensaje y el historial reciente a chat.php o chatv.php
4. El backend arma un system prompt con la base de conocimiento correspondiente y llama a la API de Gemini
5. Sistema muestra la respuesta en el widget
Postcondición: Usuario recibe una respuesta fundamentada en el conocimiento real del producto, no inventada
Flujo alternativo: si se supera el límite de mensajes por sesión o la API de Gemini no responde, el sistema muestra un mensaje de error controlado en vez de fallar silenciosamente.
5. Modelo de Entidades
5.1 Diagrama Entidad-Relación Principal
TENANTS
1 ────── ∞
USUARIOS
TENANTS
1 ────── ∞
VEHICULOS
VEHICULOS
1 ────── ∞
DOCUMENTOS_VEHICULO
TENANTS
1 ────── ∞
CONDUCTORES
CONDUCTORES
1 ────── ∞
DOCUMENTOS_CONDUCTOR
DESPACHOS
──── conductor_id ────
CONDUCTORES
DESPACHOS
──── vehiculo_id ────
VEHICULOS
DESPACHOS
──── bodega_id ────
BODEGAS
DESPACHOS
1 ────── ∞
PEDIDOS
VEHICULOS
1 ────── ∞
COMBUSTIBLES
VEHICULOS
1 ────── ∞
MANTENCIONES
VEHICULOS
1 ────── ∞
FALLOS
VEHICULOS
1 ────── ∞
OTROS_COBROS
TENANTS
1 ────── ∞
USUARIOS
TENANTS
∞ ────── ∞
MODULOS (vía TENANT_MODULOS)
VEHICULOS
1 ────── ∞
ULTIMA_POSICION_VEHICULO
CONDUCTORES
1 ────── ∞
DISPOSITIVOS_MOVILES
5.2 Entidades Principales
| Entidad | Atributos Clave | Relaciones |
|---|
| tenants |
id, nombre, rut, email, plan, estado |
1:N con todas las entidades operativas |
| vehiculos |
id, patente (única), marca, modelo, año, km_motor, estado |
N:1 con tenants, 1:N con documentos, mantenciones, fallos, combustibles |
| conductores |
id, rut (único), nombre, teléfono, email, estado |
N:1 con tenants, 1:N con documentos |
| despachos |
id, numero_orden, estado, fechas, km, costos |
N:1 con conductor, vehículo, bodega, tenant. 1:N con pedidos |
| pedidos |
id, cliente, direccion, lat, lng, estado, orden |
N:1 con despacho y tenant |
| bodegas |
id, nombre, direccion, lat, lng, estado |
N:1 con tenant, 1:N con despachos |
6. Flujos de Procesos
6.1 Flujo Completo de un Despacho
Inicio → Fin del ciclo de vida de un despacho:
1. CREADA: Se registra el despacho con vehículo, conductor y bodega
↓
2. PLANIFICADA: Se asignan pedidos y se planifica la ruta
↓
3. EN_RUTA: Se inicia el despacho (km y hora de salida)
↓
4. EN_ENTREGA: Se marca el inicio de entregas
↓
5. FINALIZADA: Se completa con km y hora de llegada
Ruta alternativa:
Cualquier estado → CANCELADA (si se anula)
6.2 Flujo de Estados de Vehículos
Ciclo de vida de un vehículo:
DISPONIBLE → (se asigna a despacho) → ASIGNADO
ASIGNADO → (inicia despacho) → EN_RUTA
EN_RUTA → (finaliza despacho) → DISPONIBLE
CUALQUIER ESTADO → (reporta fallo) → EN_FALLO
CUALQUIER ESTADO → (entra a taller) → MANTENCION
CUALQUIER ESTADO → (se desactiva) → INACTIVO
6.3 Flujo de Cobros
REGISTRADO → (se paga) → PAGADO
REGISTRADO → (se anula) → ANULADO
REGISTRADO → (vence sin pagar) → Alerta automática
7. Análisis de Riesgos
7.1 Riesgos Técnicos
| Riesgo | Probabilidad | Impacto | Mitigación |
|---|
| Pérdida de datos |
Media |
Crítico |
PostgreSQL con integridad referencial estricta; pendiente implementar backups automáticos (hoy no existen — ver Diseño del Sistema §9.3) |
| Caída del servidor |
Media |
Alto |
Monitoreo 24/7, plan de contingencia |
| Ataque de seguridad |
Media |
Crítico |
OWASP Top 10, auditorías periódicas |
| Mezcla de datos entre tenants |
Baja |
Crítico |
Validación de tenant_id en todas las consultas |
7.2 Riesgos del Negocio
| Riesgo | Probabilidad | Impacto | Mitigación |
|---|
| Baja adopción por usuarios |
Media |
Alto |
Capacitación, interfaz intuitiva, soporte |
| Incumplimiento legal (Ley 21.710) |
Baja |
Crítico |
Cumplimiento de estándares ISO 27001 |
| Competencia de soluciones establecidas |
Alta |
Medio |
Enfoque en PYMEs chilenas, precio competitivo |
8. Estudio de Factibilidad
8.1 Factibilidad Técnica
✅ ALTAMENTE FACTIBLE
• Tecnologías maduras (PHP, PostgreSQL, HTML5)
• Infraestructura estándar (hosting compartido o VPS)
• Sin requerimientos de hardware especializado
• Conocimientos disponibles en el mercado
8.2 Factibilidad Económica
✅ FACTIBLE
• Costo de desarrollo ya absorbido
• Costos operativos bajos (hosting ~$20-50 USD/mes)
• Modelo de ingresos recurrente (suscripción SaaS)
• ROI estimado: 6-12 meses
8.3 Factibilidad Operativa
✅ FACTIBLE
• Interfaz intuitiva que no requiere capacitación extensa
• Soporte técnico centralizado
• Actualizaciones transparentes para el usuario
• Escalable a múltiples empresas
8.4 Factibilidad Legal
✅ FACTIBLE
• Apunta a cumplir la Ley 21.710 de Protección de Datos
• Diseño siguiendo los principios de OWASP Top 10 e ISO/IEC 27001:2022 (no son certificaciones formales de terceros)
• Términos y condiciones claros para SaaS — pendientes de redactar
9. Conclusiones del Análisis
9.1 Hallazgos Principales
- El sistema resuelve un problema real: Las PYMEs de transporte en Chile necesitan una solución accesible y completa.
- El modelo SaaS es viable: Permite escalar el negocio con costos operativos bajos.
- La arquitectura multi-tenant es robusta: Aislamiento de datos garantizado por diseño.
- Los procesos están bien definidos: Los flujos de despacho, mantención y cobros son claros.
- La seguridad es prioritaria: Cumple con estándares internacionales y ley chilena.
9.2 Recomendaciones
- Implementar el sistema en un entorno de producción con SSL/HTTPS
- Establecer un plan de backups automatizados
- Documentar los términos de servicio y políticas de privacidad
- Crear un plan de onboarding para nuevos clientes
- Considerar futuras integraciones (ERP, GPS, pagos)
✅ Conclusión Final:
El análisis confirma que el sistema RutaCC es técnica, económica y operacionalmente factible. Resuelve necesidades reales del mercado chileno de transporte y logística, con una arquitectura sólida y segura que permite su comercialización como servicio.