Estudio de caso práctico: los retos de una implementación de business intelligence

Antecedentes de la empresa

Cada año se inscriben más de 70,000 estudiantes a la Universidad de Illinois, que ofrece más de 150 campos de estudio en 30 colegios, escuelas independientes e institutos repartidos en 3 campus: Chicago, Springfield y Urbana-Campaign. La universidad, que es una de las primeras escuelas que recibieron en cesión el terreno donde se encuentran, abrió sus puertas en 1867, y desde entonces ha otorgado más de 500,000 títulos universitarios.

El campus Urbana-Campaign es la sede de la biblioteca pública de ingeniería más grande y la tercera biblioteca académica más importante de los Estados Unidos, después de Harvard y Yale. La universidad tiene reconocimiento mundial por ser un centro de investigación médica, informática, de ingeniería y agrícola de primera calidad. Por ejemplo, sus profesores y alumnos construyeron la primera computadora propiedad de una universidad, desarrollaron un sistema de aprendizaje informático y crearon Mosaic, el primer navegador popular para computadora. Su Centro médico, que se encuentra en Chicago, es famoso por sus trasplantes de órganos y su investigación sobre la diabetes. Cerca de 20 profesores y alumnos han recibido premios Nobel y 16 han recibido premios Pulitzer. Asimismo, algunos de sus alumnos han creado empresas como Oracle Corp., Netscape Communications y Siebel Systems. Su presupuesto operativo anual es de más de $3,600 millones USD y sus investigaciones patrocinadas sobrepasan los $600 millones USD.

El problema

Al expandir una iniciativa que se creó en el 2001 en toda la universidad para reemplazar los sistemas de los cursos, surgió el problema de cómo acceder a los datos y crear reportes sobre ellos usando el nuevo sistema de planificación de los recursos de la empresa (ERP). La universidad planeaba implementar el sistema ERP en etapas para poder desarrollar un sistema de forma gradual y diseñar, en etapas también, la información saliente requerida para cubrir las necesidades de los usuarios. De acuerdo al alcance de los sistemas centrales de la universidad, el desarrollo gradual de un sistema centralizado permitiría evaluar y satisfacer las necesidades de los departamentos y las unidades del negocio.

El problema relacionado con la implementación nueva era decidir si se usaría el sistema ERP para generar reportes o se aprovecharían las características y las funciones de un sistema creado a la medida que ofreciera estas funciones. Con la ayuda de Linda Bair, directora ejecutiva de la Universidad de Illinois, se creó un grupo de soporte a la toma de decisiones. Bair había realizado la investigación necesaria para definir qué tipo de software cubriría las necesidades de creación de reportes y análisis de la universidad. La decisión de crear una arquitectura de almacenamiento de datos al que se agregara una capa de business intelligence (BI) parecía ser la solución que mejor respondía a los requisitos del negocio de la organización. Así, el grupo de soporte a la toma de decisiones se convirtió en el responsable de desarrollar un ambiente de almacenamiento de datos y creación de reportes que diera a los usuarios acceso a la información que necesitaban para la creación de reportes y el análisis.

El grupo de almacenamiento de datos estaba alineado directamente con el desarrollo del sistema ERP. Conforme se iban creando los módulos, el grupo de soporte a la toma de decisiones identificaba las necesidades de creación de reportes de los departamentos asociados. El grupo desarrolló la estructura de almacenamiento de datos, creación de reportes y BI como una capa de aplicación que se agrega al sistema ERP para identificar los datos requeridos en el sistema. Al identificar las necesidades de creación de reportes y análisis de forma paralela con el sistema ERP, el grupo de soporte a la toma de decisiones pudo identificar los requisitos que posteriormente serían transferidos para ayudar a la selección del proveedor. Si bien se estaba creando el almacén de datos al mismo tiempo, el desarrollo de la capa de aplicación exigía el uso de herramientas de un tercero. Una vez que se estableció esta estructura, la selección de un proveedor de BI se convirtió en un factor clave.

La solución

La Universidad de Illinois decidió enfocarse en los usuarios para identificar la herramienta de BI correcta. Se definieron paneles para entrevistar a más de 200 personas pertenecientes a diferentes comunidades de usuarios e identificar los requisitos. La evaluación de las necesidades tenía dos propósitos. En primer lugar, identificaría los requisitos de reportes estáticos y, en segundo, evaluaría la funcionalidad de creación de reportes ad hoc que permitieran que los usuarios crearan sus propios reportes. Una de las necesidades clave de la creación de reportes habilitados por los usuarios era contar con un ambiente fácil de usar. Debido a la implementación del ERP nuevo, los paneles de usuarios se concentrarían en el nuevo sistema de la empresa y no en el acceso a los datos para la creación de reportes. Además, el grupo de soporte a la toma de decisiones identificó varios reportes estáticos, como presupuestos normalizados y listas de estudiantes. De acuerdo a los resultados que produjeron los paneles, se seleccionó un grupo de usuarios centrales que ayudarían con el proceso de selección de software. Esta selección iba más allá de las simples características y funciones que ofrecían los proveedores, y tomaba en cuenta los criterios reunidos, así como la capacidad de graduación, el crecimiento, los costos, el soporte y la experiencia técnica del proveedor.

Una vez que se capturaron los resultados, el grupo de soporte a la toma de decisiones creó una lista de cinco vendedores y les pidió que realizaran presentaciones usando un subconjunto de los datos de la universidad. Después de las demostraciones, la universidad decidió seleccionar a Business Objects por dos razones. La primera fue su capacidad de graduación con respecto a la forma en que sus servidores se adaptan a grandes volúmenes de datos y aprovechan la información proveniente de todas las fuentes de datos requeridas. La segunda fue su facilidad de uso desde el punto de vista del usuario, que se debe a su ambiente habilitado para la red.

El grupo de soporte a la toma de decisiones quería mantener el enfoque en los usuarios, mantener el proyecto enfocado en el negocio y no en la tecnología de la información (TI). El problema de esta estrategia era determinar si el personal de TI sería capaz de aprovechar su experiencia tecnológica y anticiparse a los requisitos basándose en su conocimiento del sistema ERP sin hacer sombra a las necesidades de los usuarios. Además, las distintas unidades del negocio se sentirían propietarias del proceso y el sistema implementado, y esto afectaría la aceptación entre los usuarios.

En los tres campus, hay mas de 4,500 usuarios de reportes normalizados que obtienen dichos reportes del almacén de datos o directamente del sistema ERP. Asimismo, 2,000 de esos usuarios de reportes son gente que usa la funcionalidad de creación de reportes ad hoc. Además, más de 1,000 usuarios (esta es la cifra más reciente) están clasificados como usuarios activos, es decir que realizan una consulta al menos una vez al mes para tener acceso a los datos y realizar análisis. Aunque Business Objects es el software que se mantiene, los usuarios pueden utilizar cualquier otro programa para acceder al almacén de datos y realizar consultas.

Los retos

La Universidad de Illinois tuvo que enfrentarse a varios retos durante la implementación de Business Objects, como la capacitación de los usuarios, el enfoque de la creación de reportes, el uso de herramientas de BI y la aceptación entre los usuarios. Además, la capacidad de graduación del ambiente del servidor y la cantidad de datos procesados generaron problemas graves. Aunque en cada una de estas áreas se obtuvieron resultados positivos, el grupo de soporte a la toma de decisiones y Business Objects tuvieron que trabajar muy duro para superar los obstáculos que surgieron durante la implementación.

Los dos retos principales de la capacitación tuvieron que ver con el tiempo y la venta del sistema nuevo. En la implementación real, la capacitación se llevó a cabo demasiado pronto. El grupo de soporte a la toma de decisiones había capacitado a los usuarios (ellos mismos “súper usuarios” capacitados por Business Objects) tres meses antes de que el sistema empezara a funcionar en vivo. Es decir que los usuarios no pudieron aplicar el conocimiento que acababan de adquirir, y esto redujo las ventajas de la capacitación. Cuando se instaló la herramienta nueva, el grupo de soporte a la toma de decisiones realizó un seguimiento para ver cómo se sentían los usuarios con el sistema nuevo. Posteriormente se instaló una herramienta para identificar la correlación entre los usuarios capacitados y las consultas en el servicio de ayuda. Se establecieron laboratorios para ayudar a que la gente creara los reportes departamentales necesarios. Asimismo, la universidad creó un centro de soporte técnico para responder a las preguntas que pudieran surgir y resolver los problemas pendientes.

El segundo problema relacionado con la capacitación de los usuarios tuvo que ver con la venta del nuevo sistema. La implementación del sistema ERP hizo que los usuarios se preocupan más con cómo introducir un estudiante nuevo al sistema y cómo usar el sistema de forma general para realizar sus tareas (y no con cómo crear reportes o analizar la información financiera). El grupo de soporte a la toma de decisiones creó una campaña interna de mercadotecnia que se orientaba a la satisfacción de las necesidades de los usuarios. Se enfocaba en las personas clave de los distintos departamentos y en los usuarios prácticos. Contemplaba un enfoque en el hecho de que una vez que los usuarios saben cómo operar el sistema, se interesan en la información saliente necesaria -en concreto, los reportes- y el análisis de la información requerida. Este problema subrayó el debate entre la teoría de crear algo para que lo usen los usuarios o crear un sistema nuevo una vez que la comunidad de usuarios ha definido sus necesidades. En este caso, y debido al nivel tan alto de uso, el primer enfoque funcionó, únicamente por la diligencia del grupo de soporte a la toma de decisiones y su compromiso por crear un ambiente de BI satisfactorio para la universidad.

El grupo de soporte a la toma de decisiones identificó una desventaja: el uso de Business Objects como aplicación de creación de reportes generales. La fortaleza de Business Objects es la creación y la implementación de reportes ad hoc y el análisis de las tendencias. La herramienta no se diseñó para usarse como una aplicación de creación de reportes generales. Por ejemplo, la Universidad de Illinois genera un reporte diario que identifica a cada estudiante y toda su información disponible. El reporte más pequeño de este tipo es de más de 10,000 páginas. Por consiguiente, la herramienta de creación de reportes debía funcionar durante 45 minutos para empezar a generar las visualizaciones de las páginas. Hasta ahora, el reporte sigue funcionando con Business Objects, pero se crea un archivo PDF para que los usuarios puedan visualizarlo. Así, los usuarios no tienen que esperar a que se genere el reporte y pueden verlo inmediatamente después de realizar la consulta.

Además de que los usuarios estuvieron muy involucrados en el proceso de selección, la universidad se apegó a las políticas de encargos del estado de Illinois. Desde el principio, los directores comprendieron el razonamiento detrás de la selección de software. Las políticas de encargo dan a los directores la comprensión que necesitan para ver el valor inmediato de la decisión. Además de enviar la solicitud de propuesta, se apegaron a los procesos técnico y político, y debido a que la iniciativa estaba relacionada directamente con la implementación general de ERP, ya se había asignado un presupuesto general al proyecto. En cuanto a los usuarios, obtener su aceptación fue más difícil. Por un lado, su implicación en el proyecto fue masiva. Aunque fuera a través de los paneles, el proceso de creación de solicitudes de propuesta y demostraciones o las iniciativas de capacitación, los usuarios estaban conscientes del proceso y tenían voz y voto en él. La información que proporcionaron iba desde la evaluación de las necesidades, hasta la selección de la evaluación del software y la facilidad de uso. Pero por otro lado, el interés era poco. Si hubiese habido un interés por parte de la comunidad de usuarios (o si se hubiese desarrollado al momento de la renovación de los sistemas de los estudiantes), el interés y la aceptación generales habrían llegado con mayor rapidez.

Otro reto importante fue el diseño técnico del ambiente del servidor. Inicialmente, la universidad determinó que un servidor podría manejar las cargas de datos y la creación de reportes de todo el sistema. La base de esta suposición fueron cinco usuarios que usaron el sistema inicialmente y que sólo sirvió para subestimar el alcance del uso de la herramienta y el acceso a la información. El uso real abarcó más de 400 usuarios regulares. En realidad, esta suposición dio lugar a un proceso de 17 meses de desarrollo de una plataforma del servidor que soportara el ambiente. Además de la cantidad de tráfico, al actualizar el sistema a la versión 5.1.7 del servidor Business Objects los servidores dejaron de funcionar y se reportaron muchos errores. Lo usuarios no podían acceder al sistema, culpaban al almacén de datos y posteriormente salían del ambiente (en otras palabras, dejaron de usar las herramientas de creación de reportes que se les proporcionó y volvieron al sistema anterior). Algunos de los errores reportados fueron la aparición repetida de pantallas de registro, el cierre del sistema durante el registro de los usuarios y la creación de registros que sobrecargaban el sistema. En cuanto al servicio, Business Objects trabajó de cerca con la universidad para crear un ambiente estable con la actualización a la versión 6.5.1.

Recomendaciones y lecciones aprendidas

La creación de un ambiente de servidor que no sólo promueva el uso de la herramienta de BI, sino que lo haga de acuerdo a sus fortalezas, son los retos que hay que tomar en cuenta al implementar una solución de BI. Para poder desarrollar un ambiente estable, las organizaciones deben sobrestimar el uso del sistema. En esta evaluación debe incluirse la necesidad que tienen las organizaciones de asignar un más presupuesto a la solución seleccionada. El impacto que tiene el no hacerlo se hace evidente en la forma en que la universidad subestimó la frecuencia de generación de reportes y los volúmenes de datos requeridos -una situación común en las implementaciones de almacenamiento de datos.

Asimismo, al evaluar software, las organizaciones deben comprender las limitaciones, los retos y las debilidades de la herramienta. Para ilustrar esto está la forma en que Business Objects generaba reportes estáticos grandes, en donde el sistema tardaba 45 minutos en empezar a generar las visualizaciones. Aunque esta herramienta es fuerte en cuanto a generación de reportes ad hoc y analítica, la extensión de esa generación de reportes basada en la aplicación no hace más que subrayar las debilidades relacionadas con la transferencia de una herramienta de BI a una aplicación de generación de reportes.

Otros factores importantes son la capacitación de los usuarios y el desarrollo de experiencia interna. Business Objects es un ejemplo de un proveedor que transmite sus conocimientos a sus usuarios y les permite convertirse en expertos en el área. Con ello, da a las organizaciones usuarias la confianza y las habilidades necesarias para desarrollar y mantener sus propios ambientes de BI. En este sentido, y en el caso de la Universidad de Illinois, el grupo de soporte a la toma de decisiones pudo desarrollar capacitación personalizada y ofrecerla a sus usuarios con el conocimiento adicional del negocio que sólo se encuentra en el ambiente propio de la organización. Además, aunque un ambiente de servicio de ayuda resulta esencial para tratar con los problemas que vayan surgiendo, es posible minimizar los problemas relacionados con capacitación si se ofrece una capacitación sobre el sistema lo más cercana a la fecha de implementación del mismo como sea posible, con el fin de dar a los usuarios los elementos para que practiquen las habilidades adquiridas y aprovechen al máximo el ambiente nuevo.