Actualización sobre el límite de clientes

Respecto a este punto, debemos informar una novedad muy favorable que se generó durante esta semana. Tras una consulta realizada por Camila Bernat con abogados y expertos, se logró redefinir el criterio para el límite de 100 clientes al que estábamos a punto de llegar.

Nuevos Criterios de Exclusión Se concluyó legal y operativamente que, del cálculo total, se deben excluir dos grupos de la cartera:

1. Clientes a los cuales no se les ha presentado una propuesta comercial en los últimos tres meses.

2. Clientes que cumplen con la definición de "Cliente Calificado".

Impacto y mitigación del riesgo

Al aplicar estas exclusiones, nuestra cifra activa se redujo drásticamente, pasando de 96 (cercanoa los 100) a aproximadamente 20 clientes. En consecuencia, la probabilidad de tener inconvenientes o bloqueos por alcanzar este límite durante los próximos años queda descartada, lo cual elimina este tema de nuestra lista de preocupaciones inminentes.

Aclaración sobre la mención de "100 empleados/colaboradores"

Finalmente, respecto a la mención de "100 empleados o colaboradores", consideramos que debe tratarse de un error. Actualmente, no tenemos ninguna referencia, métrica ni aspecto dentro del proyecto que enlace nuestras operaciones a un límite o grupo de 100 colaboradores.

Definición y objetivo del algoritmo FIFO

En nuestro sistema, el FIFO es un algoritmo diseñado para determinar la cartera vigente de cada cliente. Su función principal es filtrar las transacciones, aislando únicamente aquellas que afectan las posiciones actuales y descartando las que ya no tienen impacto operativo. A partir de este resultado depurado, se procede a calcular las rentabilidades, tal como se menciona correctamente en el punto 7.

Impacto técnico: Picos de CPU y memoria

La documentación vincula correctamente la ejecución de la lógica FIFO a picos en el consumo de CPU. Esto se explica por la forma en que está construido a nivel de base de datos:

El cálculo se realiza utilizando cursores dentro de SQL Server a través de procedimientos almacenados (stored procedures).

Al tener que iterar y procesar un gran volumen de información histórica (aplicando el FIFO por cada activo y por cada cliente), el consumo de CPU y memoria se dispara. Cabe destacar que el impacto es variable, ya que cuando se realizan ejecuciones parciales el consumo de recursos es menor.

Ciclos de ejecución

El estrés sobre el sistema se hace especialmente evidente debido a los horarios en los que debe operar:

Proceso nocturno: Se encarga de actualizar las carteras de los clientes procesando la información de varias semanas hacia atrás.

Proceso matutino: Aproximadamente a las 6:00 a.m., inmediatamente después de la carga de precios, el algoritmo debe ejecutarse nuevamente para actualizar las posiciones del último día vigente. Es precisamente durante este bloque de la mañana cuando se registran las mayores elevaciones en el uso de la CPU.

Evolución e historia del sistema Passport

Respecto al origen y los años de implementación del sistema Passport, es importante aclarar que su desarrollo histórico se divide en dos grandes etapas:

Passport V1 (Aprox. 2007 - 2008): Corresponde a la versión original que dio inicio al sistema.

Passport V2 (2012 - Actualidad): Es la versión vigente que opera hoy en día. Durante este hito, se consolidaron múltiples sistemas anteriores y se crearon nuevos módulos para robustecer la plataforma.

Relación del Factsheet con el Datamart

La diferencia arquitectónica más importante entre ambas versiones fue la construcción de un Data Mart durante el desarrollo de la V2 en 2012. Este repositorio de datos es el encargado de alimentar la información que se visualiza actualmente en el Factsheet.

Debido a esta evolución tecnológica conjunta, hoy en día existen diferentes versiones de ambos componentes, las cuales están estrictamente vinculadas entre sí:

El Factsheet V1 corresponde y está asociado a la versión original (Passport V1).

El Factsheet 2 (el actual) corresponde y se alimenta del Datamart construido para la versión vigente (Passport V2).

Diferencias en las fuentes de información

Para comprender bien en qué consiste este punto, es fundamental distinguir entre los dos tipos de información que manejamos y sus respectivas fuentes:

Información de la CMF: Corresponde a los datos relacionados con los activos locales. Esta información se almacena en la base de datos principal LocalVisionDB y requiere una actualización diaria.

Flujos de Inversión de las AFP: Esta información se extrae de plataformas gubernamentales y se utiliza exclusivamente para la confección de un reporte mensual. Dicho documento detalla el monto actual que las AFP invierten en fondos específicos, así como su variación mes a mes. Se almacena en la base de datos FLUJOSAFP.

Independencia de los procesos

Es importante destacar que la gestión de ambas fuentes se realiza de manera totalmente independiente y convergen en bases de datos distintas. Dado que el seguimiento de los flujos de las AFP es un proceso secundario o de menor impacto, es muy probable que por esta razón no haya sido detallado en los reportes anteriores.

Aclaración sobre la base de datos "LocalVisionGlobal"

Finalmente, cabe mencionar que la base de datos local denominada "LocalVisionGlobal" no tiene un uso intensivo. Su propósito es netamente para fines de configuración del sistema, almacenar algunos datos de clientes, y no está destinada al almacenamiento de información operativa o histórica.

Estructura de fases según matriz ejecutiva

Para complementar la información, es importante considerar solamente la estructura de fases indicada en la matriz ejecutiva que fue entregada en el Data Room. A continuación, detallamos el estado actual y la justificación de cada iniciativa:

PETI 1 (En curso): Actualmente nos encontramos en la etapa de cotización del equipamiento. Este avance ha sido posible gracias a la asesoría que nos entregaron para definir cuál debería ser nuestra plataforma tecnológica óptima.

PETI 10 y PETI 11 (Fase 1): Ambas iniciativas se mantienen en la primera fase. Si bien son problemáticas que ya estamos gestionando y resolviendo en el día a día, todavía queda un trabajo significativo por completar para darles cierre.

PETI 13 (Fase 1): También conserva su prioridad inicial. Esto responde a la necesidad apremiante de simplificar los flujos de ingresos, actualizaciones y cuadraturas, ya que nuestro sistema actual ha demostrado ser ineficiente en estas áreas.

Visión a futuro

En línea con los desafíos levantados (especialmente por el PETI 13), el escenario ideal sería la implementación de un nuevo sistema integral que nos entregue las herramientas necesarias para gestionar de manera mucho más eficiente todos nuestros procesos internos.

Aclaración sobre las entregas y procesos de cuadratura

Creemos que existe una confusión respecto a la información presentada entre ambas entregas, generada principalmente al mezclar dos instancias que tienen propósitos y frecuencias distintas. Es fundamental distinguir entre el informe de estado y el proceso de ejecución:

1. Mail semanal: Estado de las cuadraturas La documentación que menciona un informe semanal automático se refiere exclusivamente a un correo de monitoreo. Este reporte semanal tiene como único objetivo mostrar el estado actual de las cuadraturas. Es una herramienta informativa que permite visualizar la situación semana a semana, pero no es el momento en el que se ejecutan las correcciones.

2. Proceso mensual: Ejecución de la cuadratura Por otro lado, el proceso de cuadratura y corrección formal es de frecuencia en el mejor de los casos mensual. Este procedimiento existe, funciona bastante bien en la actualidad y cumple con lo requerido. Se ejecuta una vez al mes, obteniendo los archivos de los bancos internacionales para cargar la información de manera semiautomatizada a través de un cargador implementado en el sistema.

Conclusión

En resumen, lo que se debe informar con claridad es que no hay que confundir el proceso operativo de cuadratura (que es mensual y semiautomatizado) con el correo semanal (que es puramente un reporte informativo sobre el estado de dichas cuadraturas).

Focos principales: PETI 10 vs. PETI 11

Es fundamental entender la diferencia y el alcance central de ambas iniciativas:

PETI 10: Se centra en el problema de la duplicidad operativa. Aborda los errores y diferencias generados al tener que ingresar la misma información dos veces (en los bancos o corredoras y, paralelamente, en nuestro sistema).

PETI 11: Se enfoca en la brecha de funcionalidades e información. Aborda las discrepancias que existen entre los sistemas y lo almacenado en nuestro sistema de carteras locales frente a lo que tenemos en el sistema de carteras internacionales.

Relación estratégica con otras iniciativas

El PETI 11 no es un elemento aislado, sino que se conecta directamente con otros puntos levantados:

Con el PETI 10: Ambos comparten el objetivo final de eliminar manualidad y mejorar la calidad de la información que se ingresa a nuestra plataforma, beneficiando directamente al sistema de carteras locales.

Con el PETI 06: Comparten una problemática idéntica, pero a nivel de propuestas. En ambos casos se evidencia que el sistema de carteras internacionales está automatizado, mientras que el de carteras locales sigue operando de forma manual.

Evolución de la prioridad y criticidad

Respecto a la diferencia entre lo indicado en la matriz ejecutiva original y el feedback posterior (donde el PETI 11 baja a prioridad media), la justificación es muy similar a la expuesta en el primer punto de esta tabla. Se recomienda mantener la criticidad en nivel crítico. Sigue siendo una necesidad apremiante nivelar nuestra tecnología para que el sistema de carteras locales alcance el mismo estándar y nivel de automatización que ya posee el sistema de carteras internacionales. Que aparezca Lakpa es solo un indicador de que es una parte de un problema mayor.

Contexto del PETI 10 y el ingreso manual de datos.

El objetivo principal del PETI 10 es eliminar el ingreso manual y la duplicidad de datos en la empresa. Aunque se menciona el Blotter por ser nuestro sistema principal para esta tarea, el problema abarca también otras vías de ingreso. La dificultad central radica en la duplicidad del trabajo: actualmente, el equipo comercial u operativo debe registrar una operación en la plataforma del banco o corredora y, posteriormente, volver a ingresarla en nuestro sistema interno.

Avances actuales (Feedback de Camila Bernat)

El feedback reciente, alineado con los comentarios de Camila Bernat, destaca que ya estamos ejecutando iniciativas concretas para solucionar este problema:

• Automatización con Lakpa: Tenemos un sistema de scraping activo que extrae datos de esta fuente y los carga en nuestro sistema de manera automática todos los días.

• Integración con bancos internacionales: Utilizamos scripts en Python para procesar archivos de instituciones como Pershing e Interactive Brokers, lo que nos permite cargar información y realizar cuadraturas. Además, estamos gestionando la implementación de una API para automatizar completamente este flujo diario.

Evolución del problema y criticidad

Las diferencias con las matrices originales se explican por el contexto de aquel momento: cuando se elaboraron, no contábamos con estas soluciones y existía una gran preocupación sobre cómo manejar las cargas de datos no estructurados. Hoy, el problema es mucho más manejable gracias a los avances mencionados.

A pesar de estas mejoras, se recomienda mantener el nivel de criticidad original, ya que sigue siendo un tema contingente. Si bien el escenario ideal sería eliminar por completo el uso del blotter y el ingreso manual, en la práctica siempre existirán situaciones excepcionales o límites que requerirán intervención nuestra.