archivo

Archivos Mensuales: marzo 2009

Independientemente de que la solución óptima para el tipo de información que se requiere y el perfil del usuario sean cuadros de mando, reporting, análisis dinámico de la información o una combinación de ellas, el desarrollo de un sistema de estas características debe ser iterativo y es necesario hacer el esfuerzo que haya que hacer para que el resultado cumpla al máximo las espectativas del usuario, por lo que si las iteraciones deben seguir una vez que la solución esté en producción es necesario hacerlo. Hay que evitar que el producto no quede del todo fino por no haber recorrido esa milla extra que puede convertir en sobresaliente un producto que sin ella se quede en un aprobado raspado.

Un buen sistema de soporte a la decisión (se entiende un buen sistema aquel que verifique las expectativas del usuario) que se base en 1 o más sistemas operacionales de base, garantizará el uso cada vez más extendido y con mayor calidad de dichos sistemas operacionales, ya que quienes saquen provecho del sistema de soporte a la decisión se preocuparán porque los sistemas de base estén lo mejor alimentados de información posible.

La colaboración del usuario para el desarrollo de un sistema de estas características resulta esencial. Sin una colaboración activa del usuario será complicado encontrar una solución que le satisfaga completamente, ya que quien conoce qué necesidades en materia de información o conocimiento requiere es el usuario final. En el proceso de análisis y en la presentación de prototipos iterativos, es conveniente siempre hacerle ver al usuario sobre qué aspectos puede obtener información y conocimiento y sobre cuáles no, ya que el usuario o usuarios que definen el sistema de soporte a la decisión no tienen por qué saber con detalle las características de la información que se graban en los operaciones y la calidad de la misma. Por tanto, hay que saber indicar los límites que existen para evitar falsas expectativas.

El desarrollo de sistemas de soporte a la decisión supone el fin último de la informatización de procesos de una organización que no es otro que extraer información y/o conocimiento a partir de la información que se genera en los procesos de gestión u operacionales.

El desarrollo de este tipo de sistemas no es complejo, pero para conseguir soluciones válidas es conveniente seguir una serie de recomendaciones:

1) Es necesario identificar cuáles son las necesidades de información que existen. Es decir, no es lo mismo que se necesite información de detallada (solución de reporting o de análisis de datos), cuadros de mando o la verificación o extracción de hipótesis de negocio (minería de datos).

La solución óptima a aplicar para cada caso es diferente por lo que antes que empezar hay que tener muy claro qué necesidades existen y qué quiere el usuario.

2) Otra característica que hay que identificar es el tipo de usuario que necesita la información y su cualificación técnica para utilizar soluciones más complejas o avanzadas.

Es decir, no es lo mismo que el usuario sea la alta dirección, un analista de información o un administrativo de la organización.

3) Es necesario hacer un estudio previo de la calidad del dato de los sistemas de información implicados. Aunque el análisis de datos permite sin duda detectar la calidad de los mismos, es mejor hacer un estudio a priori sobre los mismos, porque lo mismo interesa retrasar la implantación de sistemas de soporte a la decisión hasta que los datos ganen en calidad y dirigir los esfuerzos a esa tarea.

4) Si la organización no tiene implantada ninguna solución de Business Intelligence, es conveniente hacer una estimación a corto y medio plazo de lo especificado en 1) y en 2) y del volumen de información que se va a tratar en el desarrollo del sistema de soporte a la decisión. De ello va a depender mucho la solución de Business Intelligence a utilizar. Mi recomendación es que se opte por soluciones de bajo coste que permitan obtener resultados a muy corto plazo, nada de buscar soluciones monstruosas desde el primer momento, siempre hay tiempo de evolucionar hacia soluciones más complejas.

Independientemente de que en tu empresa tengas claro los objetivos que quieres conseguir y cómo hacerlo, no hay que olvidar que no estás solo en el mercado y que tu competencia evoluciona en tecnología, en estrategia de negocio, en política de empresa, de personal, etc… Es por eso que hay que estar siempre con un ojo abierto observando los movimientos de los competidores.

En un mercado tan competitivo y voraz como es el de las TICs, dormirse es lo peor que puede pasar, ya que tu ventaja competitiva, sea cual sea, puede desaparecer de la noche a la mañana.

No hay competidor pequeño, no hay competidor tecnológicamente desfasado, porque en el mundo de las TICs lo que un día es negro, al otro día es blanco.

Como he comentado en algunas entradas, el éxito de una empresa TIC depende de muchísimos factores, no todos controlables, no obstante, todo lo que sea controlable y susceptible de mejorar, se debe intentar que cada día sea mejor. Y no siempre es suficiente con ir mejorando, ya que si tus competidores mejoran más rápido que tú, estás perdido.

Tu empresa debe llevar un ritmo continuo de crecimiento y mejora, con una velocidad para hacer los mismos que se debe ajustar al mercado y a los competidores, por eso no hay que menospreciar a ninguno.

En mi departamento seguimos dando pasos pequeños, pero firmes para tener una infraestructura de desarrollo de software en condiciones.

– El uso de Subversion ya es generalizado, por lo que tenemos un control absoluto sobre los fuentes de las aplicaciones.
– El uso de Artifactory también es generalizado, por lo que también tenemos un control absoluto sobre las librerías que se utilizan y las tenemos en un espacio distinto a los fuentes.
– El uso de maven para las entregas e implantación también es generalizado y se está generalizando la implantación mediante Hudson.
– Tenemos un libro blanco de desarrollo que de un tiempo a esta parte ha orientado los desarrollos a una arquitectura y una tecnología común, lo que facilita la reutilización y el mantenimiento. En la actualidad se está retocando dicho libro para actualizarlo tecnológicamente, acotar un poco más el abanico de posibilidades y soluciones a utilizar y modificar drásticamente la forma de documentar los proyectos, basándonos en una herramienta CASE (independientemente de que haya documentación extra-CASE).
– La metodología de peticiones de entregas y de comunicación de incidencias en las pruebas con las empresas desarrolladoras también se está generalizando.
– La documentación de los proyectos está centralizada en un ECM (en nuestro caso Alfresco), con una estructura de carpetas por proyectos. Esta forma de organizar la documentación va a variar con la nueva versión del libro blanco que como he comentado se va a basar en el uso de una herramienta CASE.
– Se ha terminado de implantar una herramienta para gestionar los proyectos de manera que no tengamos la gestión en diversas herramientas y soluciones. A partir de ahora vamos a tratar de que la gestión de todos los proyectos esté centralizada en Redmine. Probablemente más adelante “truquemos” Redmine para comunicarlo con Alfresco, para añadirle alguna característica como la gestión de incurridos, etc…

Todavía nos queda mucho camino por recorrer, pero creo que la dirección que hemos tomado es adecuada. Mi único mérito en todo este asunto ha sido escuchar y dejarme aconsejar por gente que sabe mucho, muchísimo de lo que es el proceso de desarrollo de software. También hay que destacar la acogida que ha tenido esta infraestructura entre mis compañeros porque sin su colaboración nada hubiera sido posible.

Dicen que hay trenes que pasan una sola vez en la vida.

En mi trayectoria laboral ese tren ha pasado cuatro veces y en ninguna de ellas me he podido subir. En todos los casos el motivo ha sido no disponer de un requisito necesario para acceder al puesto, requisito del que creo que soy merecedor con creces, pero que de momento no cumplo.

Hoy ha sido la cuarta vez que el tren ha pasado delante mía y ha sido el tren más importante en el que nunca me habían ofrecido montarme. Un tren que no sé si alguna vez más volverá a pasar.

Me siento un privilegiado y muy orgulloso por el ofrecimiento que me han hecho. También fustrado por no poder ocupar el puesto, ya que pese a ser un reto enorme y ser un puesto de una gran responsabilidad, me siento capacitado y con muchas ganas.

Solo me queda seguir trabajando con la misma intensidad de siempre, con el deseo de aprender todos los días no solo de tecnología, sino también de todas las personas que me rodean y seguir con la intención de mejorar en mi trabajo y como persona.

Tal vez no vuelva a pasar más un tren así, pero cada día a las 7.00h de la mañana me montaré en el coche camino de la estación.

La semana pasada asistí a una reunión de captación de requisitos en la que detecté una necesidad en el grupo de usuarios usuario en un proyecto, que se traducía en un requisito funcional no previsto en el alcance inicial del proyecto.

Como es lógico, yo era consciente de que ese requisito funcional no estaba previsto y así se lo hice ver al proveedor una vez finalizada la reunión. El proveedor a lo largo de la reunión no comentó nada sobre este nuevo requisito, pese a que era consciente como yo que se escapaba del alcance inicial del proyecto.

Tras la reunión el proveedor me comentó que lo que más le interesaba era el éxito del proyecto y que el cliente y usuarios estuvieran satisfechos y que ya habría tiempo más adelante si fuera de necesario de hablar de costes extra.

Sabia decisión.

Como se ha podido ver en esta serie de posts sobre los planes de sistemas de información, la realización de los mismos es un proceso complejo, por lo que debe ser tratado como tal.

Dado los objetivos tan estratégicos que se persiguen con la realización de los mismos, el presupuesto del proyecto debe ser lo suficientemente holgado para asegurar que el equipo de personas que lo realicen sean en nivel y en número las que exige un trabajo de estas características.

Resulta fundamental el apoyo e impulso de la dirección de la organización, antes, durante y después de su ejecución. Sin ese apoyo e impulso no merece la pena ni siquiera pensar en abordar un proyecto de estas características.

Hay que ser ambicioso pero no olvidar ni la realidad de la organización ni su capacidad de gasto. Lo mejor es abordar un enfoque iterativo de manera que en cada plan de sistemas se consiga estar más cerca de esa situación ideal a la que se debe pretender aproximarse cada vez más.