Inteligencia de Negocios, ETL y Modelamiento

Luego de mis primeros pasos en este tema en Sony Chile, la verdad es que me quedó la sensación de que había algo mas que podía ser muy interesante de explotar. Además de mantener y agregar cierta funcionalidad a lo ya existente, me tocó desarrollar algunas cosas con Hyperion y Essbase en conjunto con las áreas de contabilidad de la empresa. Al tener este espectro de alternativas el tema comenzó a interesarme cada vez mas pero dada las labores diarias como Subgerente de TI no pude involucrarme demasiado hasta que a principios del nuevo siglo, ya con otros rumbos, se dio nuevamente la oportunidad. Fue así como en Infonet Chile / E-Money decidimos utilizar las grandes capacidades de manipulación de datos que tenía la combinación “Builder” y “Diver” de CrossTarget para realizar incluso tareas administrativos como por ejemplo la facturación de los consumos por acceso a Internet a través de cuentas discadas. Lo interesante fue que en la demo de la nueva versión, que ya no se llamaba CrossTarget, sino DI-Atlantis, apareció un nuevo componente, el Integrator, que resultó ser un ETL extraordinariamente simple y poderoso.

Fueron tan buenos los resultados, que incluso Infonet Chile llegó a distribuir el producto aunque sin mucho éxito. Durante esta etapa de distribución fue necesario preparar muchas “demos” donde el plato fuerte era el que con la utilización de estas herramientas nosotros podíamos realizar modelos simples en tan solo horas, sin mas información que la que podíamos arrebatar a los usuarios en esas horas. Esto me llevó a desarrollar una serie de herramientas, todas basadas en los mismos productos, que me permiten hasta el día de hoy obtener información acerca de los datos existentes mediante el modelamiento de los mismos datos. La técnica empleada es de por si bastante simple y consiste en tener una batería de scripts de ETL “pre hechos” que permiten extraer de las bases de datos las estructuras de las tablas (columnas, claves, etc.,), relaciones entre ellas, de las descripciones de los archivos planos (leídas de los mismos programas fuentes) los contenidos de los mismos etc., etc. Por supuesto que la batería de scripts no fueron desarrollados en un abrir y cerrar de ojos, pero al cabo de varias “demos” en clientes el número de estos aumentó bastante. Esto me permite hoy día en tan solo algunas horas (contando por supuesto con los privilegios y rutas de acceso a la data) el obtener un tipo de “metadata” que me permite, de cara al cliente, preguntar que es lo que efectivamente se desea crear. En otras palabras, el requisito de entender “al dedillo” el negocio del cliente para esbozar modelos no es absolutamente necesario. El conocimiento previo que se tiene al obtener esta “metadata” abre un camino “express” al conocimiento del negocio facilitando la fase de modelamiento. En la práctica esto se puede realizar con casi cualquier herramienta de ETL, pero el hecho de dominar una en particular hace que la preferencia sea siempre el utilizar la conocida, en mi caso, la suite DI-Solution de Dimensional Insight.

De todo lo expuesto antes hay varios ejemplos de uso práctico, sin embargo hay uno que, a mi juicio, se destaca sobre los demás. Marzo de 2009 recibí una llamada de un distribuidor de DI-Solution de Brasil solicitando ayuda para un cliente muy importante cuya venta podía caerse. La estrategia que se debía seguir era demostrar en la práctica que una persona con conocimientos de modelamiento y dominio de DI-Solution podía implementar una solución sin realmente conocer a cabalidad el negocio, situación en la que yo encajaba a la perfección. Fui invitado a Rio de Janeiro (que mala suerte la mia…) por mi buen amigo Edison Fernandes a participar de una capacitación en terreno con la que pretendía atar todos los cabos sueltos y no dejar escapar al cliente. Los planes originales era hacer varios cursos “hands on” durante 5 días, lo que a mi juicio era demasiado ya que el cliente podía pensar que se trataba de herramientas complejas que requerían mucha dedicación, etc., etc. Con este argumento, bajamos la capacitación a 3 días y ofrecimos un primer modelo funcional al final del tercer día. El cliente, Unimed RJ, era algo así como alguna de nuestras Isapres pero por supuesto, como todo en Brasil, era muchísimo “mais grande”. Para una persona del área de TI como yo la verdad es que tratar con datos relacionados al área de la salud no puede estar mas alejado, lo que hacía que el desafío de tener un modelo funcional al cabo del tercer día fuera algo súper interesante. Se nos dio acceso a sus bases de datos (que eran varias y de volúmenes “a lo Brasil”) y aprovechamos la batería de scripts “pre hechos” para realizar una capacitación “hands on” del ETL Integrator sobre la marcha. Esto era un perfecto 2 x 1 con lo que ganábamos muchas horas. Cuento corto: Al cabo de no mas de “3 a 4” horas de trabajo nuestro conocimiento del modelo de datos nos permitió rápidamente el realizar varios prototipos con los que junto al cliente nos permitió ir esbozando lo que serían nuestros modelos de BI para el fin del tercer día. No se en que está Unimed RJ en estos días en relación a DI-Solution, solo se que Edison me comentó el año pasado que les había vendido algunas licencias mas y horas de soporte con lo que lo que gastó en la invitación pasó a ser una inversión muy rentable. Hasta el día de hoy de cuando en cuando realizó soporte a distancia en este tema, claro que utilizando principalmente herramientas de Dimensional Insight, para clientes de Brasil, EEUU e incluso Alemania.

Primer acercamiento a la Inteligencia de Negocios

Corría el año 1992 y me tocó participar en un proceso de implementación de todo un sistema administrativo para el control de Inventarios y Ventas de Sony Chile desarrollado con GeneXus para ser explotado en un flamante nuevo AS/400 F35.

Sony Chile hasta esa época tenía sus sistemas basados en un Servidor Netware 3.11 de Novell. Los usuarios accedían a los distintos sistemas desde “flamantes” IBM PS2 modelo 25 que de PS2 no tenían nada ya que no tenían arquitectura MCA (de Microcanal) sino que se trataba de PCs bajo la marca de IBM. Al corto andar pasó lo que era obvio que pasaría: Netware no claudicaba y la contabilidad y otros sistemas permanecían en el mundo DOS mientras que toda la gestión de ventas y clientes se manejaban en sistemas en el AS/400. Por supuesto que este escenario era aun mas complejo ya que adicionalmente había varios usuarios que dominaban a la perfección las planillas Borland Quattro Pro y mantenían verdaderos sistemas de información 100% aislados del resto del mundo. Ante esta situación, que hasta el día de hoy es bastante común, la “alta gerencia” se encontró con dificultades serias a la hora de tomar decisiones ya que consolidar la información era un verdadero caos. La orden no tardó: Construir lo que sea para tener información consolidada. Durante un tiempo, y con la ayuda de un estudiante en práctica nos dedicamos a construir extractores específicos para cada plataforma haciendo uso de toda herramienta posible y llevando todo lo extraído a algún formato común en un ambiente común. Al corto andar teníamos todo tipo de reportes pero no era mas que eso reportes por lo que dimos un segundo giro de tuerca para buscar como hacer “presentable” los reportes. La solución que encontramos al dilema era “leer” estos reportes con herramientas gráficas disponibles en esos tiempos en plataforma Apple Macintosh (GQL y otras).

El problema es que los costos de estas bellezas eran muy superiores a la de los PCs pero la verdad es que ya la misma estética hacía una diferencia. Gracias a que el modelo de estación de trabajo seleccionado venía con monitor “Sony Trinitron” (bajo la marca Apple eso si) no fue tan difícil lograr su compra, aun cuando la decisión fue larga y tediosa. Finalmente a 3 gerentes se les instaló un Mac con Ethertalk en vez de un PS2 o PC y los resultados fueron de dulce y agraz. La verdad era que las aplicaciones eran muy fáciles de utilizar pero requería algún grado de interacción con los usuarios ya que los “Queries” eran dinámicos. Se suponía que cada usuario confeccionaría los suyos pero en la práctica ocurría que había que dedicar tiempo a cada usuario para crearle las consultas lo que no era nada agradable ya que se perdía el concepto de autoservicio. Esta situación no mejoró hasta que Apple nos facilitó una caja cuyo contenido era un producto llamado CrossTarget de Dimensional Insight que se suponía simplificaría el concepto de autoservicio. Dado que se trataba de un producto NO comercializado ni representado por Apple, fue un verdadero “Do it yourself kit”. El producto resultó ser una verdadera joya y se basaba en un concepto muy simple y fácil de comprender sobre todo para aquellos que ya se hubieran enfrentado al mundo de obtener datos de miles de fuentes diversas. Por una parte había un componente que corría en DOS llamado “Builder” y por otro lado un componente “cliente” llamado “Diver” (buzo) que tenía la particularidad de correr tanto en DOS como Mac. Esta fue realmente la solución buscada, ya que “Builder” construía “Modelos” con miles de cálculos “prehechos” y a través de Diver, los usuarios realmente se podían “zambullir” en un cúmulo de datos a velocidades increíbles y transformarlos en información valiosa. Fue tal el éxito de esta combinación que se nos solicitó llevar esto un paso mas adelante y confeccionar un “tablero” que permitiera mostrar en un monitor algunos indicadores de gestión (típicos hoy día pero no a principio de los 90) a todos quienes pasaran frente a dicho monitor. No se cuantos años existió este “Dashboard” pero no fueron 2 ni 3 sino varios mas.

De la aplicación de mejoras y parches al desarrollo Off Shore

Luego de un paso de varios años de bastante éxito desempeñándome en diversas posiciones, todas en el ámbito de TI, en el Banco de A. Edwards, tuve la oportunidad de trabajar como Ingeniero de Sistemas en el Banco Español Chile – Organización Banco Santander. Esto fue a fines de los 80, donde las TI aun eran dominadas principalmente por los grandes Mainframes y los PCs recién estaban tomando vuelo. Mi misión: Formar parte del selecto grupo que tenía por tarea la migración de equipos con Sistema Operativo VSE a nuevos “monstruos” con MVS/XA.

Creo que no participé nunca de alguna actividad relacionada con la migración, ya que al corto andar se me asignó una tarea muy interesante: Hacer que la aplicación “Teleconsulta” dejara de ser un dolor de cabeza. ¿Qué era esta aplicación? En palabras simples, era un equipo tipo PC que permitía a los clientes del banco obtener sus saldos, cartolas y otra información en un kiosko autoservicio. La aplicación en sí, que yo NO construí, funcionaba relativamente bien siempre y cuando no ocurriera ningún problema exógeno, como falta de papel, corte de sumnistro eléctrico, polvo en las disketeras y un número casi infinito de posibles problemas, siendo quizá la falla de diskette la causa número uno de problemas y a su vez, el mas molesto ya que requería el reemplazo físico de los mismos. Esto en Santiago no era gran cosa, pero que pasaba en Punta Arenas, Valparaíso y en general en cualquier sucursal de provincia? La logística funcionaba bien pero aun así, la confianza en la Teleconsulta estaba por los suelos. A los pocos días de estuadiar la aplicación, le realicé un cambio muy simple pero a su vez extremadamente práctico que resolvía de una el problema de la falta de papel, ofreciendo al usuarios la posibilidad de desplegar la información por pantalla para que por lo menos viera algo mas que el mensaje de “No hay papel”. Esto era trivial, pero implicó crear 40 y muchos diskettes y había que repartirlos a todos lados y además asegurarse de que se realizara el cambio, lo que se lograba al solicitar devuelta los diskettes reemplazados. Cuando a la semana del envío de la nueva versión recibí desde una sucursal una carta con el diskette antiguo CORCHETEADO a la misma, cai en cuenta de que “había que hacer algo”. Teleconsulta se basaba por una parte, la de “cliente” en un programa Quick Basic y por otra, la de “servidor”, en transacciones Cobol/CICS por lo que SI había espacio para mejoras.

Me encerré durante unas 2 semanas en una especie de “garage” al que en el banco amablemente le decían laboratorio para solucionar “de una” el tema de la distribución de diskettes. Fue así como nació una nueva generación de la Teleconsulta que, basada en la característica “Merge” del lenguaje Basic, era 100% gobernada desde CICS donde los equipos remotos se “reportaban”, recibían actualizaciones y una serie de otras mejoras. Por supuesto que una vez mas hubo que distribuir diskettes por todo Chile, pero el cambio fue simplemente espectacular. A mi entender, este fue quizá uno de los primeros esbozos de lo que hoy nos parece algo estándar: Recibir parches y/o actualizaciones desde un lugar remoto. Esta experiencia volvería muy pronto a serme extremadamente útil. En fin, pasada la Teleconsulta, donde mi experiencia con CICS quedó de manifiesto, el banco me encargó el desarrollo de la conectividad con la naciente Redbanc, la red de ATMs de los principales bancos de Chile.

Esta nueva tarea permitió darme a conocer en el naciente mercado de los ATM y recibí la tentadora oferta de hacerme cargo de la parte tecnológica de la naciente Banlider, red de ATM de los “otros” bancos. Banlider fue simplemente espectacular hasta que lamenteblemente fue absorbida por Redbanc.

Poco antes de ese evento, migré a una empresa totalmente desconocida para mi y que resultó ser una verdadera y agradable sorpresa: EMERgency 24. ¿Qué es exactamente EMERgency 24? Originalmente y desde 1967, era una empresa dedicada al monitoreo de alarmas. Fue fundada por un chileno, Dante Monteverde y su oficina principal se ubica en Chicago Illinois.

Lo especial de esta compañía es que TODO el software se desarrolla en Chile en su “división de software” de la cual me hice cargo de su “gerencia de desarrollo”. EMERgency 24 sin duda debiera estar en los libros de historia por ser una de las primeras empresas en el uso del desarrollo “Off Shore” y cuyo primer sistema fue desarrollado por chilenos, Dante, su hermano Duilio y Carlos Silva, un trio para sacarse el sombrero. El software se desarrollaba en Chile sobre una plataforma “PLUTO” de Southwest Data Systems que lograba hacer que un PC se pareciera a un “Mai Basic Four” al cual se le conectaba terminales. Una vez mas, el “Merge” del Basic era el puntal del desarrollo, toda vez que a USA solo se enviaba, vía Modem, los trozos de código nuevo y no todo un conjunto de programas. Basada en esa misma lógica, EMERgency 24 fue aun mas allá y desarrolló un sistema que permitía “distribuir” la parte tediosa del monitoreo de alarmas, que es la mantención de contratos, detalles de la ubicación de sensores en las casas monitoreadas etc., hacia “dealers” que utilizaban un PC con el sistema “Chicago Connection”, sistema que transmitía novedades a la casa matríz y además se mantenía actualizado al recibir nuevas versiones y/o mejoras al sistema, una vez mas, vía Modem. En aquellos tiempos la prestigiosa empresa Sonda se arrogaba la exclusividad de desarrollo Of Shore lo que siempre nos causó algo de gracia, toda vez que EMERgency 24 nació en 1967 y desde sus origenes el desarrollo era realizado por chilenos y el software se enviaba hasta por correo normal. En fin, hasta el día de hoy sigo sosteniendo que a Chile lo único que le hace falta es reconocer sus propios logros, porque ejemplos como los aquí mencionados, hay en todos los ámbitos.

Primeros pasos: Un sistema para una industria Química

A finales de 1981, año en el cual el 12 de Agosto nacía el “IBM PC”, un amigo de la familia, socio de una empresa Química de Viña del Mar al saber que yo estudiaba algo relacionado con “Computadores”, se me acerca a preguntar acerca de “computación”. Sus conocimientos del tema no eran superiores a los de cualquier mortal de los que nacieron antes de la TV, por lo que una explicación no iba a ser tarea fácil…Antes de siquiera responder algo, pregunté cuál era el objetivo real de su curiosidad y la respuesta fue por decir lo menos, inesperada. En la práctica no le interesaba gran cosa sino que saber precios ya que quería “sistematizar” las operaciones de la empresa porque intuía que mas temprano que tarde, las empresas abrazarían la tecnología y ellos NO podían quedar atrás. En palabras simples, nuestro amigo no sabía que había que hacer pero quería hacer algo. Esto era una oportunidad de oro para un estudiante en sus últimos años por lo que NO dudé en aceptar el desafío. Antes e seguir con los detalles, cabe hacer un paréntesis para situarse en la época y de que se disponía. Las grandes empresas tenían sus grandes equipos ya sea IBM, Burroughs, Texas Instruments, Honeywell, NCR, DEC, y otros monstruos de valores estratosféricos. Por otro lado, existían los primeros microcomputadores basados en el famoso Z80, Atari 400, 800, etc., Commodore, Tandy TRS-80, algunos Apple 2, etc.. Nada de esto era realmente orientado a las empresas sino a algunos locos o fanáticos de la tecnología y punto.

Ahora bien, volviendo a nuestro amigo, el visualizaba la computación como teclados conectados a un televisor y por ende los costos debían ser “razonables”. Antes de pensar en un sistema tuve que confesarle que lo mas probable es que los costos fueran “altos” al punto que, descontando mis propios honorarios, quizá podría cambiar mas de algún auto… Lo mas increíble que a pesar de todo no se amilanó y con sus socios decidieron dar el gran salto: Pasar de un procesamiento 100% manual a controlar lo básico como Cuentas Corrientes de Clientes, Inventario y Facturación en una modalidad sistematizada.

El desafío: Hacer un sistema “simple” para usuarios que jamás habían tenido interacción alguna con la computación. Compré un computador VECTOR CPM 5800 con 2 disketteras externas de 5 ¼ “ “Hard Sectored” cuya capacidad era increíble para la época: 798 KB. (IBM PC salió al mercado con unidades de 360Kb mientras que la mayoría de los diskettes de 5 ¼” solo almacenaban 140Kb) En fin, con ese Hardware, y sin un lenguaje mas que el “Monitor” de la máquina y una versión muy precaria de Basic (sin archivos indexados por lo que todas las “claves” se confeccionaron con técnicas de “hashing”), en un plazo menor a 1 mes y con la sola ayuda de un compañero de universidad, nuestro amigo contó con un sistema operando y en tan buenas condiciones que PAGÓ mas de lo que le cobré. Lo interesante de todo esto es que operaron con ese computador por varios años, y cuando definitivamente ya no daba mas (amén de que comenzaron a desaparecer los diskettes Hard sectored), me volvieron a llamar para hacer todo de nuevo, y luego otra vez y otra vez. Fui testigo de las mayores mutaciones que un mismo sistema puede tener ya que de Basic pasamos a Pascal a Cobol y finalmente a un AS/400 con servicio en todas las oficinas y pantallas para muchos funcionarios. Lo mas rescatable de este desafío para mi sin duda fue el hecho de que nuestro amigo me entregó la confianza para que lo resolviera absolutamente todo, tarea que creo haber cumplido a cabalidad.

Tecnología: Una pura casualidad

Haciendo un alto en la vida casi al completar medio siglo de existencia, me puse a divagar acerca de porqué estoy en lo que estoy y si las cosas pudieron haber sido diferentes. Con asombro me di cuenta que llegué prácticamente por una suma de casualidades a desempeñarme casi sin respiro en el campo de las tecnologías de la información pudiendo probablemente haber sido un destacado agricultor, médico, profesor, piloto u otros oficios de no haber sido, valga la redundancia, por casualidades. Lo que si me parece tener absoluta claridad es que las artes, las letras y el deporte competitivo no son ni serán mi especialidad no porque no me atraigan sino por el simple hecho de haber nacido con dos manos y brazos izquierdos…En fin, hagamos un poco de historia.

Tuve la “mala” suerte de nacer en el seno de una familia profesional del ámbito académico donde ambos progenitores trabajaban en la “Universidad”. Por un lado un padre dedicado a la Química Orgánica y por otro una madre apasionada por los “Cromosomas” y la Genética en general. Hoy me pregunto: ¿Que habría sido de mí de haber nacido en una familia ligada al comercio u otra ligada al ámbito empresarial? La verdad no tengo ni la menor idea pero capaz que el resultado final fuera el mismo, quien sabe.

Por supuesto que el seno familiar es una gran marca, toda vez que no veo en mis recuerdos haber tenido mas claridad que mi paso natural al salir del colegio era la universidad. Si tal vez tuve una sola duda fue que en algún momento estuve indeciso entre la academia o el de ser un “Piloto de Guerra” ya que hasta el día de hoy el tema de la aeronáutica me atrae muchísimo. Sinó me incliné por ingresar a la FACH, que era prácticamente la única opción para llegar a piloto de máquinas espectaculares, respondió a factores puramente ambientales y a una real falta de ganas de pasar por el tedio, para mí en esos entonces, de una formación militar con todo lo que eso acarreaba. Bueno, mi entrada a la “Universidad”, la USM, al área de ingeniería fue básicamente por no haber dado la prueba de biología, ya que sabía que sería un estrepitoso fracaso dada mi formación tremendamente orientada al área técnica ya que mis últimos años de colegio los realicé en una escuela experimental, donde las tuercas y los números valían 10 mientras las artes y las plantas valían 2 por no decir casi nada.

Durante el primer semestre universitario todos los 600 alumnos que ingresamos estudiábamos lo mismo, es decir nada práctico sino solo números y payasadas que se englobaban en lo que se llamaba “Plan Común”, plan que incluía cátedras de matemáticas, física, química, algún taller electivo y como no, educación física. De “Ingeniería” ni las luces, por lo que al cabo de 4 meses de clases uno había aprendido solo “las bases” para seguir aprendiendo. Antes de comenzar el segundo semestre había que elegir una especialidad, donde lo único que tenía claro es que la química no iba conmigo dado que en el último certamen con suerte me pusieron una nota, ya que en la práctica había contestado solo algo mas que mi nombre. Con todas las especialidades a mi alcance, tenía que elegir una, y aunque parezca increíble, elegí “Sistemas de Información” simplemente porque me atrajeron las máquinas perfo-verificadoras y el imponente IBM 370-125 con sus periféricos estrambóticos. Como pueden apreciar, una decisión sumamente informada y científica. De ahí en adelante casi toda mi carrera ha tenido momentos similares, donde grandes decisiones se basaban en hechos de una subjetividad sin par que me llevaron del mundo de construcción de aplicaciones en ambientes transaccionales, pasando por la administración de bases de datos a manejo de infraestructura, redes de cajeros automáticos, desarrollo de aplicaciones de alta complejidad como interfaces entre dispositivos, monitoreos de alarmas, aplicaciones distribuidas con soporte remoto de las mismas, inteligencia de negocios, etc., etc., donde la única “pieza” común entre cada una de ellas es el involucramiento personal a nivel de detalle que me permite decir hoy, con un grado de confianza bastante alto, que tengo vasta experiencia en un sinnúmero de subespecialidades del mundo de las TI. En la actualidad, de todo lo anterior rescato que al parecer mi elección, aunque basada en un hecho muy subjetivo, fue mas que correcta, toda vez que hasta la fecha me apasiona hacer lo que hago y sobre todo aun siento que soy un excelente aporte a cualquier proyecto tecnológico aun cuando sea un tema esencialmente nuevo.