Posts Tagged proyectos
lunes, 15 diciembre 2008 a 16:37 · Archivado en Business Intelligence, Informática, proyectos ·Etiquetado Business Intelligence, inteligencia empresarial, linkedin, proyectos
No basta con crear los informes ideales, hay que distribuirlos a las personas apropiadas y sólo a ellas, a tiempo, protegidos para que nadie más pueda verlos, ejecutarlos sin interferir en la operativa de la empresa. Además convendría que los usuarios finales pudieran generar sus propios informes sin que tuvieran que investigar en modelos complejos; que se pudiera administrar desde un lugar central en las empresas con múltiples sedes; que …
Las necesidades son variadas y es necesario encontrar soluciones que satisfagan todas ellas. En este caso se optó por BusinessObjects Enterprise XI, una solución proporcionada por SAP, tras la adquisición de la empresa Business Objects.
Cliente: una empresa inmobiliaria
Necesidad: crear un entorno de inteligencia empresarial que mantuviera la confidencialidad de la información en una empresa con varias sedes y departamentos.
Situación previa: se utilizaban muchos informes desarrollados con herramientas distintas que cada departamento administraba y guardaba.
Desarrollo del sistema: Se instaló la administración de BusinessObjects Enterprise XI en un servidor dedicado. Se rehicieron y optimizaron los informes y se creó una política de seguridad para toda la empresa. Se crearon «universos» para los departamentos que necesitaban generar consultas a medida.
Resultados: Los gerentes tuvieron por primera vez la sensación de controlar la información que circulaba por su empresa y los empleados tuvieron un mejor acceso a la información que necesitaban.
Coste del proyecto: 200 días + licencias
Enlace permanente
lunes, 30 junio 2008 a 17:30 · Archivado en BBDD, Informática, proyectos, sistemas ·Etiquetado administración BBDD, BBDD, Informática, linkedin, Oracle, proyectos, sistemas
Los entornos de certificación son fundamentales sobre todo en los sistemas que dependen de otros para funcionar. El desarrollo a menudo olvida algunas de las relaciones que existen con otros y muchas puestas en producción fracasan por no haber previsto las consecuencias que acarrearían. Suponen pérdidas importantes o por los gastos asociados por volver al sistema anterior o simplemente por la disfuncionalidad que implica en el negocio.
Cliente: una empresa de desarrollo de un grupo de telecomunicaciones
Necesidad: crear un sistema de certificación de varios servidores Unix interdependientes con varias BBDD Oracle distribuidas para poder llevar a cabo las tareas de certificación de la empresa.
Situación previa: se disponía de un sistema de certificación pero no se estaba seguro de que fuera exactamente igual que el entorno de producción y no funcionaba correctamente, entre otras cosas el sistema de réplicas entre las BBDD. Por lo que se decidió volver a crear el entorno desde cero.
Integrantes del proyecto: yo como administrador de BBDD y otro técnico de sistemas para la configuración de los servidores.
Descripción del sistema: Clusters de HP con BBDD distribuidas Oracle.
Implementación: A partir de los backups de las máquinas de producción se reprodujeron los servidores mientras que las BBDD hubo que crearlas de manera especial porque sino las replicas no funcionaban. Apuntaban a las tablas de producción en vez de las de certificación. La solución consistía en crear la BBDD, los distintos usuarios con sus esquemas y finalmente las tablas replicadas una por una apuntando a las de certificación.
Coste del proyecto: 40 días x 2 técnicos
Enlace permanente
lunes, 30 junio 2008 a 11:57 · Archivado en BBDD, Business Intelligence, Informática, proyectos ·Etiquetado BBDD, Business Intelligence, Informática, linkedin, Modelo de datos, proyectos
A lo largo de un año se crearon unas cuantas Web para diferentes empresas del grupo.
Cliente: grupo de comunicación
Necesidad: crear los modelos de datos para desarrollar sobre ellos las aplicaciones web.
Descripción del sistema: BBDD Oracle.
Implementación: .Mediante entrevistas con el cliente y la empresa desarrolladora de las páginas web, determinaba las necesidades de almacenamiento y generaba el modelo de datos pertinente.
Coste del proyecto: 200 días
Enlace permanente
lunes, 30 junio 2008 a 11:36 · Archivado en BBDD, Business Intelligence, Informática, proyectos ·Etiquetado BBDD, Business Intelligence, Informática, proyectos
Los periódicos necesitan organizar su información (texto y documentos multimedia) y dar facilidades a los lectores para encontrarla fácilmente.
Cliente: un grupo editorial
Necesidad: crear la versión digital del periódico.
Situación previa: sólo existía la versión impresa.
Descripción del sistema: BBDD Oracle para los datos con la opción Text option.
Implementación: Lo primero que tuve que hacer es adaptar la opción “Text option” para indexar documentos en español. Oracle no proporcionaba ninguna ayuda, venía preparado para indexar en inglés y se ve que tenía pocos clientes en español. Lo más importante era determinar las palabras por las cuáles no se quería indexar. Un internauta desconsiderado podría llegar a hacer caer la BBDD si se lo proponía. Una vez parametrizada correctamente esta opción, creé el modelo de datos a partir de las necesidades expuestas en las entrevistas con el cliente y los desarrolladores que iban a desarrollar el periódico digital.
Coste del proyecto: 40 días+Oracle Text option
Enlace permanente
lunes, 30 junio 2008 a 11:28 · Archivado en BBDD, Informática, Jefe de proyecto, proyectos, sistemas ·Etiquetado administración BBDD, BBDD, Informática, Jefe de proyecto, Oracle, proyectos, sistemas, Sun, UNIX
Los bancos tienen características especiales que diferencian sus sistemas informáticos de los demás. La seguridad y la fiabilidad son fundamentales. Sin olvidar la velocidad de respuesta.
Cliente: un banco
Necesidad: mantener el sistema informático recién creado mientras se formaban a los técnicos del banco en las nuevas tecnologías introducidas.
Situación previa: el soporte del sistema antiguo lo llevaban los técnicos del banco pero al introducir un nuevo sistema que dependía menos del mainframe del banco del que eran filial, las tareas de mantenimiento se ampliaron y se determinó que por un tiempo transitorio haría falta nuevo personal.
Integrantes del proyecto: yo como jefe del proyecto y cuatro técnicos de sistemas más, uno de los cuáles seguiría en el banco cuando el proyecto finalizase.
Descripción del sistema: Principalmente un cluster HA de dos máquinas Sun, con un servidor de aplicaciones Tuxedo, un SGBD Oracle y un gestor de colas MQSERIES. Además Veritas Netbackup con un robot para backups y el planificador de procesos controlM de BMC.
Implementación: El sistema todavía estaba desarrollándose cuando llegamos. Hubo que ponerlo en producción, diseñar la planificación de tareas y definir la política de backups. La administración de las BBDD, la parametrización, la optimización de las consultas, las migraciones de versiones, el control de usuarios, la llevaba yo tanto la de producción como la de desarrollo. Aparte del mantenimiento diario de los procesos, había que introducir cambios frecuentes en el sistema para incluir los nuevos módulos que se iban desarrollando. Llevábamos un soporte 24h. con un sistema rotatorio de guardias. Durante nuestro proyecto hubo que migrar el sistema a otra ubicación, al centro de datos del banco matriz y redimensionarlo tras una fusión del banco con otro.
Coste del proyecto: 300 días x 5 técnicos
Enlace permanente
domingo, 29 junio 2008 a 16:17 · Archivado en Informática, Jefe de proyecto, proyectos, sistemas ·Etiquetado HP, Informática, Oracle, proyectos, sistemas, soporte, UNIX
En el cambiante mundo de la informática, cada técnico ha recibido una formación distinta y va pasando por experiencias diferentes que le van especializando progresivamente. Pero el soporte de sistemas complejos necesita de personas polivalentes que tengan conocimientos en un amplio abanico de temas aunque no necesariamente muy profundos. La cuestión de las guardias complica el desempeño de su labor. Ante la imposibilidad de tener de guardia a todo el equipo es necesario que cada uno de ellos tenga los conocimientos mínimos para resolver el mayor número de incidencias posibles.
Cliente: una empresa de servicios
Necesidad: crear un equipo de soporte con personal joven sin experiencia o con poca, que pudiera mantener un sistema de atención de averías y proporcionar soporte de 24h.
Situación previa: el soporte estaba repartido entre la empresa que había diseñado el sistema y la empresa que lo mantenía. Se quería dejar de depender en cuestiones de mantenimiento de la empresa desarrolladora.
Descripción del sistema: el núcleo del sistema estaba formado por un cluster de HP con Service Guard. Con un SGBD Oracle distribuido, aplicaciones cliente en Windows y servidores web basados en servlets Java.
Implementación: A cada uno de los técnicos se le responsabilizó de unas tareas en función de su formación y experiencia. Desde el principio fui organizando unos talleres en los que expliqué cómo funcionaba desde el punto de vista del mantenimiento el sistema: los clusters, la BBDD Oracle, las tablas replicadas, las consultas distribuidas, los servidores Unix, etc. Al mismo tiempo fui documentando todos los problemas que iban surgiendo y les acostumbré a que lo consultaran y lo mantuvieran. Desarrollé una serie de consultas a la BBDD. y de scripts en Unix que comprobaban que todo iba bien. Les puse como tarea que todas las mañanas comprobaran el resultado, para asegurarme que todos lo comprendían. Cada uno de ellos tenía que conocer lo que hacían los demás por lo que se iban rotando para intercambiarse las tareas. Para facilitar las guardias nocturnas diseñe con BMC Performance Manager (Patrol) un sistema de consultas automático basado en las consultas anteriormente citadas que incansablemente exploraba el sistema y enviaba mensajes al móvil de guardia en cuanto se detectaba algo anormal. Quizás el principal problema fue el estrés inicial de los técnicos de llevar solos por la noche la responsabilidad de todo el soporte del sistema, pero el hecho de haber pasado durante el día por todas las posibles tareas les fue confiriendo progresivamente la suficiente confianza para reducirlo.
Coste del proyecto: 400 días x 14 técnicos
Enlace permanente
viernes, 27 junio 2008 a 19:46 · Archivado en Informática, proyectos, sistemas ·Etiquetado Informática, proyectos, sistemas
Las fusiones de empresas conllevan muchos cambios y aparte de que puedan sobrar personas hay que redimensionar los sistemas y eliminar todo lo innecesario.
Cliente: un banco, antes dos
Necesidad: Comprobar si el sistema informático de uno de los bancos tendría capacidad suficiente para atender a los clientes de los dos.
Situación previa: uno de los bancos acababa de invertir mucho dinero en un sistema informático moderno y se quería ver si había que ampliarlo para alojar el negocio de los dos.
Condicionantes del proyecto: Se tenía mucha prisa para llegar a una conclusión.
Descripción del sistema: un cluster unix de Sun, funcionando con el gestor de transacciones Tuxedo sobre una BBDD de Oracle. Además se utilizaba MQseries para comunicación con el Mainframe del banco matriz.
Implementación: se llevaron en paralelo dos métodos de evaluación. Uno de ellos consistía en evaluar con la ayuda de un programa cuanto aumentaría la carga de los diversos parámetros del sistema cuando se tuvieran a todos los clientes que se estimaba (cuatro veces más). El otro consistía en hacer una simulación real de la nueva carga. Para ello creé una BBDD con cuatro veces más datos en clientes y en las tablas relacionadas. Sobre ella se inyectaron las transacciones que se estimaba que se producirían una vez fusionados y se midieron los tiempos de respuesta. El primer método, el de la estimación, determinó que había que aumentar el sistema. El segundo que había que aumentarlo aún más pero comprobé que la carga la producían un par de peticiones al sistema y tras optimizar las consultas Oracle que incluían, el resultado fue que había menos carga sobre el sistema que en la situación de partida con cuatro veces menos clientes. Con lo cual se llegó a la conclusión de que no hacia falta ninguna ampliación, pero como estaba aprobado el presupuesto de todas maneras se amplió por si acaso, aunque no en la medida que se había previsto.
Coste del proyecto: 15 días x 3 técnicos+consultoría de dos empresas
Enlace permanente
viernes, 27 junio 2008 a 13:26 · Archivado en Informática, proyectos, sistemas ·Etiquetado BMC, Informática, Oracle, proyectos, sistemas, soporte, UNIX
El soporte de 24 horas es fundamental para algunas empresas y no es factible en muchos casos tener a alguien comprobando periódicamente si todo va bien. Es mucho mejor tener un proceso automático que compruebe con la frecuencia necesaria aquello que nosotros consideremos apropiado.
Cliente: una empresa de telecomunicación
Necesidad: Llevar el soporte 24h. de un sistema crítico del que dependen miles de trabajadores y cientos de miles de clientes.
Situación previa: los tiempos de respuesta eran pésimos. Podían pasar horas hasta que alguien daba el aviso de que algo marchaba mal o por el contrario se avisaba por cuestiones puntuales que no requerían intervención.
Condicionantes del proyecto: el sistema era muy complejo. Y durante las guardias sólo una persona debía llevar el soporte de todo.
Descripción del sistema: Se utilizaban ordenadores personales (cientos), servidores UNIX en cluster, redes complicadas, bases de datos Oracle distribuidas.
Solución elegida: Patrol de BMC, ahora Performance Manager.
Implementación: Se analizaron los problemas más comunes y se vio la mejor manera de detectarlos. Se diseñaron consultas a la BBDD, tanto al diccionario de datos como a las tablas de las aplicaciones para ver si se trabajaba correctamente. Por otra parte se crearon scripts en UNIX que exploraban los ficheros de mensajes de errores de las aplicaciones más importantes y comprobaban si ejecutaban las tareas necesarias. También se analizaban los tiempos de respuesta de determinadas tareas. El resultado de todo esto era gestionado por Patrol que mandaba alertas en forma de SMS y correos cuando se sobrepasaban los umbrales definidos. Por otra parte los resultados se podían consultar posteriormente para evaluar el rendimiento del sistema. Ahora el soporte no era el último en enterarse sino que en muchas ocasiones solucionaba los problemas antes de que se produjeran o era el primero y nadie se daba cuenta de que realmente hubiera llegado a producirse una incidencia. Por otra parte, la tarea de soporte se simplificaba porque se sabía donde fallaba el sistema, o al menos donde no fallaba, aparte de las opiniones contradictorias de los usuarios.
Coste del proyecto: 100 días x hombre + licencia de BMC Patrol.
Enlace permanente
jueves, 26 junio 2008 a 18:36 · Archivado en BBDD, Business Intelligence, Informática, proyectos ·Etiquetado BBDD, Informática, informes, proyectos
Los sistemas de gestión integral de empresas del tipo de Oracle Financials son muy flexibles, valen para todo tipo de empresa siempre que se personalice para las necesidades particulares de la misma. Pero esta flexibilidad conlleva también una gran complejidad del modelo de datos y, por tanto, una gran dependencia de los productos proporcionados por Oracle y sus socios, que no siempre aportan una solución a las necesidades particulares del cliente. La otra solución es dedicar un trabajo adicional a buscar los datos perdidos.
Cliente: una empresa de fabricación
Necesidad: Generar informes específicos sobre rentabilidad .
Situación previa: se desconocían muchos detalles de la marcha del negocio. Sólo se disponía de los informes tipo que suministra Oracle Financials, los resultados de unas cuantas consultas que se ejecutaban sobre la BBDD y los datos que se suponían más fiables de los distintos departamentos involucrados.
Condicionantes del proyecto: los datos que mostraba Oracle Financials no coincidían con los datos de los distintos departamentos por utilizar criterios diferentes. La generación de los informes no debería interferir en la operabilidad del sistema.
Estructura de los datos: modelo de datos orientado a la flexibilidad sin nombres reconocibles de campos ni tablas.
Solución elegida: Se eligió acceder directamente a las tablas con Crystal Reports, para tener un control fino de los datos que se utilizarían en los informes.
Implementación: sobre el mismo entorno de producción por no disponer de entorno de desarrollo. Se consiguió hacer coincidir los informes con los datos de los departamentos. Se estudió en que se diferenciaban con los proporcionados por Oracle Financials y se detectaron algunas inconsistencias que se corrigieron.
Coste del proyecto: 150 días x hombre + licencia de Crystal Reports.
Enlace permanente
martes, 10 junio 2008 a 08:52 · Archivado en BBDD, Business Intelligence, Informática, proyectos ·Etiquetado almacén de datos, BBDD, datawarehouse, Informática, proyectos
Muchas veces los informes llegan tarde. Hay que saber en todo momento la marcha de una empresa para dirigirla con eficacia.
Cliente: una empresa de telecomunicación
Necesidad: Control en tiempo real de la calidad del servicio de soporte al cliente de la empresa
Situación previa: se lanzaban periódicamente consultas sobre la base de datos operacional de atención al cliente que medían unos cuantos parámetros de calidad. Era un proceso muy pesado para la base de datos por lo que se procuraban lanzar a horas de poca carga. Los resultados sólo los sabían interpretar unas pocas personas porque no eran claros y había que transformarlos mucho a mano para generar los informes.
Condicionantes del proyecto: la BBDD operacional tenía que tener una disponibilidad de 24h y no debía verse degradado su funcionamiento por la gran importancia que se le concedía al servicio al cliente.
Estructura de los datos: los datos de partida se encontraban en la BBDD operacional de seguimiento de incidencias, en la BBDD maestra de clientes y proveedores de la empresa y en otra BBDD con los datos de tráfico de red.
Solución elegida: La BBDD de Oracle porque todas las demás lo eran, la empresa tenía un buen contrato de mantenimiento y personal especializado en este entorno.
Implementación: en un entorno de desarrollo se creó el modelo de datos que satisfacía los requisitos especificados, se adaptaron los datos y cargaron en el modelo y finalmente se crearon los informes solicitados. El sistema resultante tenía un desfase máximo de una hora con respecto a los datos operacionales, pero algunos indicadores se elaboraban con los datos originales (sin desfase) y existía la posibilidad, si así se estimaba, de consultar otros.
Coste del proyecto: 200 días x hombre + licencias.
Enlace permanente
martes, 3 junio 2008 a 12:05 · Archivado en Informática, proyectos, sistemas ·Etiquetado Informática, proyectos
Los datos no se pueden perder. Es necesario tener un sistema fiable de copias de seguridad. Y esto no quiere decir que basta con elegir un buen programa, hay que llevar la política correcta de copias para cada empresa y comprobar que se recuperan los datos en el tiempo que se estime como adecuado para cada uno de los escenarios posibles de pérdidas de datos.
Cliente: un banco
Necesidad: Diseñar y operar un sistema de copias de seguridad para el cluster que iba a llevar la operativa del banco.
Situación previa: el sistema anterior dependía de un mainframe de IBM en el centro de datos del banco matriz, que llevaba su propio sistema de copias.
Condicionantes del proyecto: debería interferir lo menos posible con el funcionamiento normal del banco.
Descripción del sistema: un cluster de Sun con una base de datos Oracle en modo Archivelog.
Solución elegida: Veritas Netbackup, ahora de Symantec, con un robot de cintas y un agente para Oracle.
Implementación: Diseñé la política de copias en colaboración con los encargados del banco para definir la frecuencia de copias, el período de retención y los requisitos de recuperación. Así se estableció una copia completa los fines de semana y copias incrementales todas las noches por duplicado, una de las cuáles se enviaba a las instalaciones del banco central todos los días. Se hicieron pruebas de recuperación de datos con medición de tiempos y del sistema entero. Durante el proyecto hubo que migrar el cluster a otra ubicación y se puso a prueba una vez más el sistema de recuperación. Durante todo el proyecto trabajé en colaboración con un informático del banco para que pudiera continuar operando el sistema una vez que terminara.
Coste del proyecto: 100 días x hombre + licencia de Netbackup con agente de Oracle+robot de cintas.
Enlace permanente
lunes, 26 May 2008 a 18:28 · Archivado en Business Intelligence, Informática, proyectos ·Etiquetado Business Intelligence, Informática, Jedox, MOLAP, OLAP, PALO, proyectos
Las herramientas informáticas de gestión habituales no son lo suficientemente flexibles como para cubrir todas las necesidades de las empresas. Una de las carencias habituales son los informes muy especializados que utilizan los directores y que permiten ver la marcha de un negocio para poder adoptar decisiones estratégicas sobre el mismo.
Cliente: una empresa inmobiliaria
Necesidad: generar una serie de informes de periodicidad mensual para seguir la evolución del negocio de alquileres de diversos propietarios.
Situación previa: estos informes se generaban a mano para unos pocos propietarios en hojas Excel y se guardaban para consultas posteriores y presentar los resúmenes anuales. Era un proceso muy lento, poco flexible, proclive a introducir errores y difícil de mantener.
Condicionantes del proyecto: muchos de los datos necesarios estaban dispersos por la organización en hojas Excel y no se querían modificar ni las aplicaciones ni la BBDD de la empresa. Por lo tanto, la solución debería almacenar los datos necesarios para generar los informes (Data Mart) e incluir un sistema de introducción y revisión de los mismos, ser flexible de manera que los propios empleados pudieran modificar los informes y, sobre todo, muy económico de desarrollar y mantener.
Estructura de los datos: en su mayor parte, los datos estaban organizados por inmuebles y meses y se querían conseguir los valores agregados de portales, edificios, propietarios y tipos de propietarios por años y acumulados en el año para cada uno de los meses. Este tipo de informes es lo que mejor maneja las BBDD multidimensionales o cubos OLAP.
Solución elegida: de las distintas opciones que existen en el mercado se eligió PALO de Jedox por llevar incorporada su propia BBDD de nulo mantenimiento y perfectamente integrada con el motor de generación de informes y por tener un conector con Excel que permite que los propios usuarios generen informes sencillos y puedan modificar los diseñados a medida fácilmente, lo que permite un costo de mantenimiento muy bajo. Cualquier usuario con conocimientos medios de Excel puede entender la estructura de los informes y modificarlos. Una ventaja adicional es que el costo por licencia es cero de manera que independientemente del número de usuarios que utilicen el producto su costo será nulo.
Implementación: realicé una copia de la BBDD Oracle de la empresa y generé las consultas para recuperar los datos necesarios. A continuación diseñé la BBDD multidimensional. Luego, las pantallas de los datos que se debían introducir a mano y finalmente los informes que se me solicitaban.
Coste del proyecto: 80 días x hombre + 0 euros por licencias.
Enlace permanente
Eduardo Casais Padilla 