Rediseño Digital & Analítica de Producto: Banca Pública

Resumen ejecutivo del impacto directo de la reingeniería de procesos en el ciclo de publicación del portal público bancario (5 Páginas del MVP):

Modelamiento formal en norma BPMN 2.0 con flujos de secuencia entre Swimlanes, compuertas de decisión XOR, eventos de temporizador (Timer) y bucles de retorno por retrabajo perfectamente conectados:

Modelamiento formal en norma BPMN 2.0 del flujo optimizado. El Editor Comercial compone landings visualmente en minutos y el Product Owner aprueba en Staging Sandbox previo a la sincronización instantánea:

Definición formal de perfiles de acceso (Role-Based Access Control) y políticas de validación para operar el nuevo modelo de procesos sin comprometer la seguridad bancaria:

1. Matriz de Permisos RBAC en Puck Admin & Strapi 5

• Editor Comercial (Marketing / Producto): Permiso de creación y modificación visual de textos, imágenes y banners únicamente sobre los componentes precargados en las 5 páginas del MVP. Sin acceso a modificar código duro ni infraestructura.
• Product Owner / QA Certifier: Permiso exclusivo de aprobación final del Gate de Staging Sandbox y ejecución del pase a producción en 1-Click.
• Lead Developer / TI: Administración de componentes React base en Puck, definición de esquemas de datos en Strapi 5 y mantenimiento del pipeline CI/CD.

2. Reglas de Negocio del Proceso BPMN 2.0

• Rule 1 (Mandatory Quality Gate): No campaign or modification can be pushed to production without a prior preview and explicit approval in the Sandbox Staging environment.
• Rule 2 (Auto-Analytics Tagging): Every new landing page or button published via Puck CMS automatically applies DataLayer tags in GTM for conversion tracking in GA4 and heatmaps in Clarity without manual tagging.

Modelo simplificado de las tres tablas del sistema bancario interno utilizadas para medir la adopción del canal digital y el impacto del rediseño del portal:

Mide la tasa de conversión de solicitudes digitales por tipo de producto bancario (cuenta corriente vs. crédito de consumo), validando directamente el KPI de +35% de conversión declarado en el MVP Canvas Bloque 5 y en el resumen ejecutivo del proyecto. Conecta con las Personas Camila y Roberto definidas en el Canvas Bloque 2.

-- Canvas B5: Validates +35% digital application conversion rate
-- Canvas B2 Personas: Camila (checking_account) & Roberto (consumer_credit)
SELECT 
    da.product_type,
    COUNT(*) AS total_applications,
    SUM(CASE WHEN da.status = 'approved' THEN 1 ELSE 0 END) AS approved_applications,
    ROUND(
        SUM(CASE WHEN da.status = 'approved' THEN 1 ELSE 0 END)::NUMERIC 
        / COUNT(*) * 100, 2
    ) AS conversion_rate_pct,
    -- Compares post-redesign period vs previous month
    LAG(
        ROUND(SUM(CASE WHEN da.status = 'approved' THEN 1 ELSE 0 END)::NUMERIC / COUNT(*) * 100, 2)
    ) OVER (PARTITION BY da.product_type ORDER BY DATE_TRUNC('month', da.application_date)) 
    AS prev_month_rate_pct
FROM digital_applications da
JOIN web_sessions ws ON da.session_id = ws.session_id
WHERE 
    da.origin_channel = 'web'
    AND da.application_date >= DATE_TRUNC('month', CURRENT_DATE) - INTERVAL '3 months'
GROUP BY da.product_type, DATE_TRUNC('month', da.application_date)
ORDER BY da.product_type, DATE_TRUNC('month', da.application_date);

🟢 Resultado simulado (muestra):

Insight: +35% de incremento validado → cuenta corriente creció de 41.5% → 56.0% (+35%), crédito de consumo de 35.6% → 48.0% (+35%).

Traza el embudo de conversión de extremo a extremo, desde la sesión en el portal hasta la aprobación de la solicitud. Valida el evento submit_application_success definido en el Canvas Bloque 6 y los pasos 3, 4 y 5 del Journey (Canvas Bloque 3): Intención de Solicitud → Formulario → Conversión.

-- Canvas B6: Measures submit_application_success
-- Canvas B3 Journey: Steps 3 (CTA) -> 4 (Form) -> 5 (Conversion)
WITH application_funnel AS (
    SELECT 
        COUNT(DISTINCT ws.session_id) AS step1_portal_sessions,
        COUNT(DISTINCT CASE WHEN da.status IS NOT NULL 
            THEN da.session_id END) AS step2_started_applications,
        COUNT(DISTINCT CASE WHEN da.status IN ('submitted', 'approved') 
            THEN da.session_id END) AS step3_submitted_forms,
        COUNT(DISTINCT CASE WHEN da.status = 'approved' 
            THEN da.session_id END) AS step4_approved_applications
    FROM web_sessions ws
    LEFT JOIN digital_applications da ON ws.session_id = da.session_id 
        AND da.origin_channel = 'web'
    WHERE ws.session_date >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT 
    step1_portal_sessions,
    step2_started_applications,
    step3_submitted_forms,
    step4_approved_applications,
    ROUND(step2_started_applications::NUMERIC / step1_portal_sessions * 100, 1) AS start_rate_pct,
    ROUND(step3_submitted_forms::NUMERIC / step2_started_applications * 100, 1) AS submit_rate_pct,
    ROUND(step4_approved_applications::NUMERIC / step3_submitted_forms * 100, 1) AS approval_rate_pct
FROM application_funnel;

🟢 Resultado simulado (muestra):

Compara el volumen y participación del canal digital frente al canal presencial (sucursal) antes y después del rediseño del portal. Valida el KPI de "Autonomía Operativa" del Canvas Bloque 5 y el impacto del flujo TO-BE implementado en la Tab 2.

-- Canvas B5: Validates digital channel growth post-redesign
-- Cut-off date: New portal go-live
SELECT 
    origin_channel,
    CASE 
        WHEN application_date < '2025-03-01' THEN 'Before Redesign'
        ELSE 'After Redesign'
    END AS period,
    COUNT(*) AS total_applications,
    ROUND(
        COUNT(*) * 100.0 / SUM(COUNT(*)) OVER (
            PARTITION BY CASE 
                WHEN application_date < '2025-03-01' THEN 'Before Redesign'
                ELSE 'After Redesign'
            END
        ), 1
    ) AS share_pct
FROM digital_applications
WHERE application_date >= '2024-12-01'
GROUP BY origin_channel, period
ORDER BY period, origin_channel;

🟢 Resultado simulado (muestra):

Insight: El canal web superó a sucursal post-rediseño (28.7% → 50.8%), validando la Autonomía Operativa del Canvas B5.

Monitorea la tendencia semanal de errores bloqueantes en los formularios del portal, validando el KPI de "Cero defectos bloqueantes en producción" del Canvas Bloque 5 y la efectividad de la Épica 3: Pruebas & Pase a Producción del Roadmap (BIN-301 y BIN-302).

-- Canvas B5: Validates "Zero blocking defects" post-QA Staging
-- Roadmap Epic 3 BIN-301: Effectiveness of QA Testing Matrix
SELECT 
    DATE_TRUNC('week', fe.error_date) AS week_start,
    fe.error_type,
    fe.form_field,
    COUNT(*) AS total_errors,
    COUNT(DISTINCT fe.session_id) AS affected_sessions,
    ROUND(
        COUNT(DISTINCT fe.session_id)::NUMERIC 
        / (SELECT COUNT(*) FROM web_sessions 
           WHERE DATE_TRUNC('week', session_date) 
               = DATE_TRUNC('week', fe.error_date)) * 100, 2
    ) AS session_error_pct
FROM form_errors fe
WHERE 
    fe.error_type = 'blocking'
    AND fe.error_date >= CURRENT_DATE - INTERVAL '8 weeks'
GROUP BY week_start, fe.error_type, fe.form_field
ORDER BY week_start DESC, total_errors DESC;

🟢 Resultado simulado (últimas 4 semanas post-lanzamiento):

Insight: Tendencia a cero errores bloqueantes confirmada en semana 4 post-lanzamiento. KPI Canvas B5 "Cero defectos bloqueantes" validado.