jueves, 29 de noviembre de 2007

Data Warehouse en profundidad


Empieza el primer tema hablando de los Data Warehouses, los almacenes de datos.
Los sistemas tradicionales empezaron a tener problemas para satisfacer las necesidades de los usuarios y de esta problematica, surgen los Data Warehouse como sistemas de apoyo a la toma de decisiones, en que los datos de una organización se transforman en información estratégica. Ayudan a su vez a disponer de un acceso sencillo e inmediato a determinada información de negocio estructurada y de calidad.

Acceder a los datos directamente en sistemas operacionales (del dia a dia, no DWH) suponía algunos problemas:
  • Conocer lenguajes como SQL
  • Rendimiento
  • Los datos no están preparados para las consultas necesarias.
  • No suelen tener un horizonte histórico como para detectar tendencias o realizar seguimientos.

Data Warehousing versus Data Warehouse
Data Warehousing es el proceso de crear y mantener un almacén central de datos, es decir un Data Warehouse.

Características de un DWH
  • Orientado a temas: en contra de la orientación a procesos de los sistemas operacionales, facilitando su acceso y entendimiento.
  • Integrado: Los datos de un DWH son íntegros en unidades de medida, nombres, codificación, etc...
  • Variante en el tiempo: Se guardan datos históricos (del orden de años) que facilitan la evaluación e identificación de tendencias.
  • No volátil: Los valores permanecen en el DWH sin modificación.

Diferencias entre un DWH y una BD Operacional
La principal diferencia entre un Data Warehouse y una BD operacional es su objetivo, el primero esta orientado a las operaciones del día a día y el segundo al análisis y la toma de decisiones. Por tanto podemos preveer que uno recibe multitud de transacciones repetitivas y conocidas y el DWH consultas masivas, puntuales y no conocidas. También como diferencia encontramos el rendimiento, la volatilidad, los usuarios (más expertos), estructura (relacional versus multidimensional), alcance histórico, detalle de los datos y por último el volumen, mucho mayor en un DWH.

Arquitectura de un DWH

Cuando hablamos de la arquitectura, nos referimos a la manera de representar la estructura global de los datos, los procesos y las interfaces de usuario. Las bases de esta arquitectura son:
  • Mezclar los datos de la BD operacional con otras fuentes de datos, incluidas las externas.
  • Información fácil y transparente
  • Proveer al usuario de un acceso universal a los datos (apoyado en lenguaje SQL)
  • Metadatos: De donde proviene un dato, que formato tenía, significado, como se ha calculado, etc...
  • Construir y mantener el directorio de datos.
  • Gestión de copia y de replicación: todos los procesos necesarios para asegurar la calidad de los datos.

Estructura del DWH
¿Qué nivel de detalle tienen los datos? Normalmente difiere de los sistemas de producción por contener agregaciones y por guardar al detalle los datos de otros años.
Dentro del DWH también encontramos los famosos Metadatos, que los podríamos definir como un directorio para ayudar a ubicar los contenidos, una guía de donde provienen los datos y una descripción de los algoritmos utilizados para calcular las agregaciones pertinentes.

Data Mart
Un Data Mart cumple los mismos principios que un Data Warehouse, pero difiere principalmente en el alcance del mismo, que seria de un departamento o grupo de personas y no de toda la organización. De Data Marts podemos encontrar de dos tipos: dependientes e independientes según si los datos son extraidos del DWH o directamente de los sistemas operacionales (a la larga un desastre).

Explotar un Data Warehouse
El reto es sacar datos y convertirlo en información, que se dice pronto... y encima querer crear una ventaja empresarial. Este reto va des de la edición de informes hasta una minería de datos avanzada, con análisis multidimensional. Por tanto, un DWH es un medio, no un fin en si mismo. Ningún proyecto debería tener como finalidad construir un DWH, sino obtener información... si bien, cabe decir que el construirlo debe suponer una gran meta.
Para la explotación encontramos tres técnicas principalmente: Query and reporting, OLAP (análisis multidimensional) y Minería de datos . La primera consiste en realizar informes y generar consultas flexibles, con una interfaz gráfica, permitiendo también escribir total o parcialmente la consula en SQL (o similar). La segunda (OLAP) consiste en realizar análisis desde un conjunto de perspectivas o dimensiones. Muy adecuada para grandes volúmenes de datos.
La tercera consiste en el descubrimiento de conocimiento no accesible de manera directa... si no que se encuentra oculto, por ejemplo, buscar patrones de información en los datos.

lunes, 19 de noviembre de 2007

El valor del cliente


El Business Intelligence puede ayudarnos en saber que clientes son los más rentables. Una buena política de clientes establecería 4 categorías:
  • Categoría A: Clientes muy rentables.
  • Categoría B. Clientes rentables
  • Categoría C: Clientes poco rentables
  • Categoría D: Clientes con un valor nulo o negativo para la compañía.

En cada grupo se establecen políticas diferentes, siempre teniendo en cuenta un factor: el valor que estos podían tener en el futuro.
Categoría A: Política para mantener la satisfacción del cliente. Tener un contacto con todos ellos: carta, email, teléfono, solo para preguntar si están contentos, si tienen alguna sugerencia para el servicios, etc.. (Aproximadamente un 15% de nuestros clientes)

Categoría B: Política para aumentar la rentabilidad. Los clientes con alto valor futuro en esta categoría hemos de tenerlos entre algodones, ya que son buena parte del futuro de nuestra compañía. Un análisis de los servicios que tienen y por similitud, los que les podrían interesar, es una buena manera de seguir con esta plácida relación. Otra buena política es ampliar la oferta de productos, quizas no son mejores clientes porque no les ofrecemos lo que necesitan. (Aproximadamente un 25% de nuestros clientes)

Categoría C: Tener una política más agresiva de ventas, estos clientes tienen que decantarse por el grupo B o en el D... Los cliente con buenas perspectivas de futuro en esta categoría, podríamos mantenerlos esperando una mejor oportunidad a medio plazo. En este grupo encontraremos un 50% de nuestros clientes, pero que representa solo el 10% de nuestra facturación. No hay que tener miedo.

Categoría D:Suponen un 10% de nuestros clientes. Aquí el desafío es intentar cambiar la situación. mejorando sus productos. Si esto no fuera posible, la mejor opción es no contar con estos clientes. Como siempre, es mejor tener pocos y buenos, que muchos y malos.

domingo, 4 de noviembre de 2007

Shopping 2.0

Los clientes no somos tontos, pero a veces se nos vende humo, quizás una manera de tapar la poca información que tenemos de ellos... un poco de inversión en BI no vendría nada mal para acercar más los anuncios al target de cliente que van dirigidos.
Por ejemplo, se escucha un anuncio por la radio sobre un centro comercial, en donde dicen, se practica shopping 2.0. Supongo que nada más lejos de la realidad... un comercio 2.0 debería tener una participación activa del usuario, cosa que en las tiendas no pasa... somos seres pasivos, nos gusta lo que hay o fuera, a otra tienda.

Una tienda física 2.0 debería tener:
  • Junto a cada articulo, un lugar donde poder apuntar comentarios del producto, así como preguntas o dudas al respecto.
  • Los productos tendrían que poderse buscar o conseguir ordenados por el voto de los usuarios. En el escaparate se encontrarían los más valorados.
  • Los clientes tendrían que poder apuntar sus productos favoritos, así otro día que vuelvan los pueden volver a comprar sin olvidarse ninguno.
  • Evidentemente buscadores repartidos por la tienda... con TAGS como fashion, novedad, sin azúcar, niños, etc...
  • Ranking de productos más vendidos, comentados, valorados, etc...
  • Diferentes entradas a la tienda: una normal y otra muy simple, en donde encontrar solo las últimas novedades.
Realmente una tienda con todo eso, si que seria shopping 2.0 de verdad...

jueves, 1 de noviembre de 2007

¿Qué debe "almacenar" un DataWarehouse?


Me ha parecido super interesante el debate del blog Sistemas Decisionales sobre que debe almacenar un DW.
La verdad... nunca me había planteado tan a fondo como una gran duda... de entrada y sin leer los comentarios pensé "Datos, of course". Después de leer todos los comentarios, me decidí por datos estructurados por eso de que estos se guardan en una cierta estructura.
Creo que se le puede dar una vuelta más. Conocimiento o Información yo creo que un DW lo contiene, pero depende de la persona a la que va dirigido simplemente. El DW solo contiene el dato (o dato estructurado), pero para alguien que sepa interpretarlo el DW tien conocimiento e información, pero al final depende de la persona que lo usa, no del DW en si, por tanto, entiendo que este en si mismo no contiene ni información, ni conocimiento.

Destacaría dos puntos interesantes de la conversación:
  • Los usuarios de la empresa, están de paso. Debemos tener cuidado de adaptar el DW a ellos.
  • ¿Podría la capa semántica estar contenida en el propio DW? es decir el modelo de negocio podría ser creado a partir de una reglas incluidas en el DW y "en el aire" crearse el modelo, así, este permitiría poderse cambiar sin problemas, a partir de modificar las reglas. Quizás es parte del futuro...