Mayo 2008
Newsletter de Business Intelligence
N°4

En este Newsletter...

Temas abordados en esta edición:

- Basilea II

- Business Intelligence Estratégico, Táctico y Operacional

Basilea II - Breve Guía para Comprender su Impacto

Avances del Acuerdo de Basilea II

El Comité de Basilea, que forma parte del Banco Internacional de Pagos, emite recomendaciones que tienen influencia y reconocimiento a nivel mundial. Prueba de ello es que el llamado Acuerdo de Basilea I ha sido adoptado en más de cien países.

En 1998 el Comité inició una profunda revisión del primer Acuerdo, dando lugar a un largo y complejo proceso que culminará con la implementación del Acuerdo de Basilea II.

El Nuevo Acuerdo representa un intento más ambicioso en la búsqueda de mejorar la seguridad y solvencia del sistema financiero. Es el reflejo de la evolución de la actividad bancaria en los principales países del mundo y recoge las reacciones de la industria al anterior Acuerdo. Se sustenta en tres pilares básicos.

El Pilar 1 pretende ser una norma de adecuación de capital más sensible y ajustada al riesgo de las operaciones bancarias. A los conceptos de riesgo de crédito y de mercado incorpora la noción de riesgo operacional, al cual define, en términos generales, como el riesgo de pérdida causada por una insuficiencia o fallo de los procesos, personas o sistemas. Es decir que, mientras la fuente de los riesgos de crédito y de mercado es externa, la fuente principal del riesgo operacional está dentro de la propia entidad y tiene que ver con la fortaleza de su sistema de control interno y prevención de fraudes.

El Pilar 1 establece un espectro de enfoques para el cálculo del capital ajustado por riesgo de crédito y por riesgo operacional, así como los requisitos que hay que cumplir para poder acogerse a cada uno de ellos, dando libertad a los bancos para que adopten los que mejor se adapten a su nivel de sofisticación y perfil de riesgo. Al mismo tiempo, ofrece incentivos a las entidades para desplazarse hacia las metodologías más avanzadas.

Lo interesante del Acuerdo de Basilea II es que, a diferencia del anterior acuerdo, las opciones avanzadas permitirán a las entidades utilizar sus propias estimaciones de las variables críticas que componen los modelos de cálculo, incrementando así la precisión y sensibilidad a su efectiva exposición al riesgo. En otras palabras, el Nuevo Acuerdo deposita confianza en que las entidades puedan estimar sus propios parámetros de riesgo, en lugar de aplicar una fórmula estándar, siempre y cuando demuestren que se ajustan a las condiciones establecidas.

El Pilar 2 establece el papel del banco central o supervisor para valorar los modelos de gestión de riesgos y su potestad para intervenir cuando considere que el capital mantenido no se ajusta al riesgo contraído.

Por último, el Pilar 3, conocido como Disciplina de Mercado, establece la información que las entidades deberán hacer pública. Esta información incluirá tanto los datos de nivel y composición de capital como así también, la descripción de los modelos empleados para su cálculo.

Los tres pilares del Nuevo Acuerdo representan un avance significativo en el campo de la medición y gestión de los riesgos de la actividad bancaria.

Importancia del Acuerdo de Basilea II

El Acuerdo de Basilea II constituye, al menos en una primera etapa, una oportunidad de diferenciación competitiva para los bancos.

Aquellos que cuenten con sistemas y modelos más sofisticados de medición de riesgos estarán en mejores condiciones para evitar los excedentes injustificados de capital mínimo y sus consecuentes costos de oportunidad. En términos simples, si un banco comprueba que tiene un buen control su exigencia de capital podrá ser menor a la de otro banco que no tiene la misma capacidad. Las estimaciones realizadas en algunos países arrojan que, en ciertos casos, la adopción de las opciones avanzadas puede llevar a una liberación de capital mínimo del orden del 20%.

Por otro lado, la imposibilidad de implementar los modelos avanzados podrá ocasionar el downgrade en el rating de la entidad, lo que encarecerá sus costos de fondeo e impactará negativamente en el valor de su acción.

Desafíos del Acuerdo de Basilea II

El Nuevo Acuerdo afecta a distintas áreas y funciones de los bancos.

Para la alta dirección implica revisar su estrategia de posicionamiento frente al riesgo; es decir qué riesgos tomar y cuáles no, dado que ello tendrá un impacto más directo sobre sus requerimientos de capital. También implica seleccionar las opciones del Acuerdo a las que se desea llegar, haciendo un análisis profundo de sus costos y beneficios, y poner en marcha un plan de acción para alcanzarlas en el tiempo disponible, que no es mucho.

En lo relativo a la estructura organizacional, el Nuevo Acuerdo requiere la formación de unidades específicas dedicadas a Basilea II, así como también la clara definición de las responsabilidades de los diferentes niveles y áreas del banco en relación con el modelo de gestión de riesgos.

Desde el punto de vista de los procesos de negocio, implica la revisión del funcionamiento operativo del banco para identificar y corregir las debilidades de control interno que pudieran existir. Al mismo tiempo, para el órgano de supervisión bancaria representa la necesidad de evolucionar hacia una forma de inspección más proactiva y de mayor calidad.

Brown cheap hair extensions is a favorite choice for many people. real hair extensions is because it is safe enough to be close to black, hair extensions and charming.

En lo que se refiere al personal, los bancos deben divulgar la importancia de adoptar el nuevo Acuerdo y reforzar las competencias de quienes están involucrados en las actividades de gestión de riesgos, a través de un plan de entrenamiento.

Por último, el Nuevo Acuerdo implica fuertes requerimientos tecnológicos para aquellos bancos que deseen posicionarse en los modelos avanzados. Estos deben implementar aplicaciones específicas para el cálculo del capital mínimo y la divulgación de la información pública. Además, deben construir las bases de datos necesarias para almacenar las series históricas que permitan estimar internamente las variables de los modelos de cálculo, como por ejemplo, la probabilidad de default.

Considerando todos estos impactos, el proceso de adecuación de los bancos para cumplir con el nuevo Acuerdo se estima en más de dos años. De hecho, algunos especialistas opinan que los requerimientos de Basilea II son superiores a los que representó la llegada del Año 2000.

¿Qué se debe hacer inmediatamente?

Una acción inmediata es realizar un estudio general del impacto de Basilea II, que consiste en identificar las diferencias entre la situación actual y la deseada, cubriendo todos los frentes de análisis: modelos y metodologías, estructura y procesos, tecnología y datos, etc. El producto terminado permitirá llevar a cabo una evaluación de los costos del proyecto de adecuación, comparándolos con sus beneficios potenciales. Consecuentemente se estará en condiciones de seleccionar la opción estratégica a seguir en forma estructurada y fundamentada.

Otra acción inmediata debería ser el lanzamiento de un programa de divulgación de los conceptos de Basilea II para todos los ejecutivos del banco, con el propósito de que comprendan su importancia estratégica y su amplio impacto organizacional.

Una tercera iniciativa es la creación de una Oficina de Gestión de Proyecto que consolide todas las iniciativas dispersas y se haga responsable de la ejecución del plan de acción general de Basilea II.

Por último, resulta crítico comenzar a trabajar en la identificación y almacenamiento de las series históricas de datos necesarios para los modelos de cálculo puesto que los enfoques avanzados basados en ratings internos requieren contar con información correspondiente a un período de cinco a siete años.

Referencias:

Business Intelligence Operacional

El área de Business Intelligence (BI) continúa evolucionando. Surgida inicialmente como una tarea de interés estratégico, luego derivó a cuestiones tácticas y ahora, finalmente, comienza a aplicarse en el área operacional. Esto plantea una necesidad de readecuación de procesos e instrumentos, aunque su objetivo sigue siendo el mismo, una mejor toma de decisiones mediante el análisis de variables, la predicción de tendencias, la integración de resultados y la producción de reportes.

El BI estratégico ayuda a ejecutivos y gerentes a tomar decisiones estratégicas como la introducción de una nueva línea de productos, expandir una fuerza de ventas, cambiar un modelo de pricing, etc. El BI táctico ayuda a gerentes departamentales a tomar decisiones de menor amplitud (mensuales o semanales) como la asignación de recursos, el diseño de una nueva promoción de marketing para optimizar las ventas o un análisis del impacto de un nuevo proyecto. El BI operacional ayuda a una base mayor de personas, desde empleados técnicos hasta ejecutivos, a tomar muchísmas decisiones operativas cada día, desde cómo tratar con un cliente insatisfecho hasta reemplazar una parte defectuosa en una maquinaria.

El BI operacional debe entregar información tan pronto como sucede un suceso significativo para que puedan tomarse acciones correctivas y no supone la intervención de operadores humanos necesariamente. El uso de técnicas predictivas en ambientes on line de tiempo real puede ayudar a hacer más eficientes distintos procesos y automatizarlos. Ejemplos de esto son las compañías de e-commerce que generan recomendaciones personalizadas para sus clientes o las compañías de servicios financieros que pueden aprobar automáticamente solicitudes de préstamos o servicios.

Los requerimientos de las tareas del BI operacional significan un apartamiento importante de la operación acostumbrada en el BI estratégico. Los tiempos más o menos dilatados de procesos batch en un ambiente de data warehousing (DW) deben dejar lugar a procesos de muy corto tiempo de latencia en ambientes que estén dentro o fuera de un data warehouse. Los tiempos de latencia, según las aplicaciones, pueden ir desde tiempo real (o sea reacción inmediata) hasta algunas horas, aunque lo frecuente es entre 15 minutos y una hora. En muchos casos, lo más importante es recibir la información apropiada en el momento apropiado para tomar una decisión oportuna, razón por la cual se suele llamar a estos sistemas de “right time” o “just in time”.

Otra característica habitual de los sistemas de BI operacional es la necesidad de actualizar una porción significativa (se calcula en un 15%) de los datos en un DW en intervalos menores de 24 horas (en algunos casos cada algunos pocos minutos o en otros cada algunos segundos). Esto implica también la utilización de herramientas de captación de la nueva información que sean capaces de suministrarla en plazos acordes.

El sistema de reporting también debe modificarse. Predominan los reportes estáticos debido a que los procesos operacionales no cambian frecuentemente y a que muchos de los datos entregados se encuentran en el nivel más bajo de granularidad, de modo que operaciones como drill down no tienen sentido. También son frecuentes los reportes parametrizados y los tableros de control. Las principales acciones invocadas por un sistema de BI operacional son alertas y mensajes de e-mail, lo que es indicio de que aún no predominan las reacciones automatizadas, y que la mayoría de estos sistemas requieren de la intervención humana. Sin embargo, es probable que esto se modifique progresivamente.

La implementación de sistemas de BI operacional plantea desafíos de negocio y desafíos técnicos importantes.

Desafíos de negocio

  • Definición de requerimientos: Si bien la propuesta de un BI operacional es atractiva, muchas implementaciones se realizan sin objetivos de negocio claros o previamente definidos. Las necesidades o requerimientos detrás de la implementación de estos sistemas son en muchos casos nebulosos.
  • Identificación de costos: Los costos de los sistemas de BI operacional aumentan en forma inversamente proporcional al tiempo de latencia deseado. Tiempos pequeños de latencia exigen la compra de nuevas herramientas para capturar las transacciones u otros sucesos en tiempo real, transportarlos y cargarlos, usualmente, en un data warehouse. Se utilizan productos de replicación de datos, captura de datos modificados, backbones de colas de mensajes, buses de servicios, software especializado de ETL y paralelización de procesos de ETL y DBMS. Según las estimaciones del TDWI, el costo promedio de un sistema de BI operacional es de 1.1 millones de dólares, incluyendo hardware, software, servicios y staff.
  • Reingeniería de procesos: Muy frecuentemente las empresas deben hacer reingeniería de sus procesos para estar en condiciones de utilizar datos “just in time”. No tiene sentido tener una disponibilidad casi en tiempo real de los datos si los procesos sólo reaccionan una vez por semana o por mes. El impacto de esta reingeniería puede ser mayor o menor según la empresa y el área de negocios. A veces las modificaciones son radicales.
  • Control de expectativas: En proyectos de este tipo no es infrecuente la sobreventa de posibilidades y la generación de expectativas desmedidas e irreales. Naturalmente esto no trae más que problemas.
  • Entrenamiento de los usuarios: Este aspecto tiene múltiples aristas, por lo que sólo consideraremos algunos aspectos. A medida que pasamos del BI estratégico al BI táctico y de éste al BI operacional, algo seguro es que la base de usuarios se ensancha considerablemente. En una empresa mediana o grande, los usuarios de BI estratégico pueden ser unas pocas decenas de roles directivos superiores, los de BI táctico pueden ser unas cuantas decenas más en roles gerenciales superiores o intermedios, pero los del BI operacional se cuentan por centenas en los más diversos niveles. Esto plantea una heterogeneidad muy grande de usuarios, mucho de los cuales poseen escaso entrenamiento para tareas de BI. En muchos casos no tienen tampoco el tiempo para dicho entrenamiento o la motivación para hacerlo. La reingeniería de procesos obliga a un reentrenamiento en las tareas básicas de muchos empleados. Finalmente, la necesidad de manejar datos “just in time” obliga a muchos departamentos de IT a prescindir de servicios de verificación de integridad referencial, agregación y data cleansing. Esto lleva a datos con un nivel de confiabilidad reducido y a la necesidad de entrenar a los usuarios en la detección y manejo de estos problemas en sus tareas individuales.

Desafíos técnicos

  • Uso de datawarehousing: La cuestión técnica más importante es si es apropiado o conveniente usar una arquitectura de warehousing para entregar datos “just-in-time” o esto se debiera evitar. No existe una opinión uniforme. Unos cuantos vendors de software de BI son optimistas al respecto. Algunos como Business Objects, Hyperion, SAS o Intersoft confían en que sus herramientas pueden proporcionar un modo sencillo y de costo razonable de capturar datos en tiempo real y entregarlos a los usuarios en función de sus necesidades con una calidad apropiada. Otros vendors, principalmente los de BI anidada, analytics en memoria y otros creen que un data warehouse es crítico para aplicar un contexto histórico a los datos de tiempo real, pero no necesariamente son apropiados para manejar los propios datos de tiempo real. Muchos expertos en BI tienen dudas al respecto y creen que el uso de data warehousing perjudica la calidad de los datos y dificulta el BI operacional. Al menos la mitad de las empresas no parecen entusiasmadas en abandonar una técnica de IT bien establecida como la de DW, en la que invirtieron considerables recursos, por lo que intentan adaptar sus recursos de DW a los procesos operacionales. Pero los desafíos técnicos son importantes, como se menciona en lo que sigue.
  • Selección de la tecnología correcta: Un arquitecto de BI debe elegir entre una multitud de tecnologías que pueden agruparse en tres categorías: adquisición de datos (herramientas de ETL, de replicación, de captura de datos modificados, backbones de mensajería, motores de streams dirigidos por sucesos, etc.), almacenamiento de datos (herramientas de DW, bases de datos de latencia reducida, motores analíticos dirigidos por eventos, etc.) y delivery de datos (herramientas de reporting de BI, portales, tableros de comando, etc.)
  • Aumento de escalabilidad: Al incrementar la base de los datos disponibles y la base de usuarios potenciales se plantean problemas de escalabilidad de los recursos que debe resolverse mediante upgrades de redes y hardware, paralelización de procesos de extracción y transformación.
  • Aumento de disponibilidad y recuperabilidad: En un ambiente “just in time” hay poco tiempo (o ninguno) para recuperarse de errores y corregir problemas. Una buena manera de tratar de evitar estos problemas es construir sistemas de alta disponibilidad mediante paralelización, ambientes en clustering, procesos de failover y backup, mirrors, conexiones duplicadas, servers de staging, “microbatches”, etc.
  • Performance adecuada: El problema principal para los arquitectos de BI operacional es asegurar tiempos de respuesta apropiados para las consultas al mismo tiempo que se realizan diversas tareas de carga, actualización y performance, como monitoreo de sucesos, disparo de eventos, realización de backups, scoring, etc. La ejecución simultanea de todos estos procesos tiende a degradar la performance del sistema, a lo que se agrega la expectativa por parte de los usuarios de tiempos de respuesta casi instantáneos. Existen diversas soluciones de compromiso para mantener un balance entre las cargas de trabajo y los SLA existentes.
  • Bloqueos: Cuando los procesos de ETL y las consultas de los usuarios impactan sobre las mismas tablas existe un serio riesgo de que un proceso bloquee al otro, con la consiguiente degradación de performance. Una forma de evitar esto es mantener almacenamientos separados para datos históricos y “just in time”. Otras formas (con ventajas y desventajas) de minimizar este problema son permitir lectura y escritura simultanea, crear particiones duplicadas de tablas lácticas, cargar los datos en caches “in memory” fuera del DW.
  • Sincronización de agregados: Un problema asociado al del bloqueo es el de la consulta de tablas agregadas que no se recalculan dinámicamente con los datos en tiempo real. Esto suele ocurrir cuando las tablas son grandes, por lo cual para evitar la sobrecarga de la actualización se la realiza típicamente al final del día. Pero esto requiere que los usuarios sean conscientes de estas cuestiones para evitar consultas no validas.

Recomendaciones

En base a lo anterior, pueden hacerse algunas recomendaciones para el desarrollo de sistemas de BI operacional:

  • No mantener divisiones rígidas entre los procesos y tecnologías analíticas y operacionales
  • Colocar los datos “just in time” en un contexto histórico
  • Buscar arquitecturas simples, no complicarla innecesariamente
  • Comprender la estructura de costos del BI operacional
  • Simplificar el proceso de delivery de datos
  • Aplicar modelizacion predictiva a los procesos operacionales para mejorar su eficiencia
  • Automatizar con cuidado, evitando los problemas típicos de procesos fuera de control, usuarios que reciben gran cantidad de datos no queridos, triggers o alertas inapropiadamente definidos, etc.

Referencias

Si no quiere seguir recibiendo este Newsletter por favor enviar un mail de respuesta colocando "EXCLUIR" en su título.
Copyright © 2008 MAySA Consultores. Todos los derechos reservados.