En 1996, el Instituto politécnico comunitario de Nueva Escocia (NSCC, por Nova Scotia Community College) se convirtió en una institución de administración independiente y regida por un consejo. El NSCC es el primer instituto politécnico comunitario de toda la provincia y representa trece campus principales y seis centros de enseñanza comunitarios. Las escuelas que lo conforman abarcan cinco sectores académicos principales, que son administración, acceso, artes aplicadas y medios nuevos, servicios sanitarios y humanitarios y comercio y tecnología. El instituto ofrece una gran variedad de programas académicos, así como la mayoría de los programas de capacitación técnicos y de aprendizaje de Nueva Escocia (Canadá). Cuenta con una matriculación anual de 25,000 estudiantes y con 1,400 empleados y maestros.
El problema
Para llevar a cabo la gestión de las actividades del NSCC, era necesario generar y distribuir, al final de cada mes, reportes financieros a los diferentes encargados de la toma de decisiones de toda la provincia, repartidos en trece ubicaciones físicas. Esta era una tarea realmente difícil; el NSCC dependía de sistemas financieros legados para operar todas sus aplicaciones financieras y sus procesos de fin de mes, y para generar los reportes financieros. El instituto tardaba hasta dos semanas en realizar este proceso, y una semana adicional para imprimir y distribuir los reportes a las personas adecuadas de los diferentes campus y centros comunitarios que forman parte del NSCC. Cuando finalmente los reportes llegaban a manos de las personas correctas, los datos eran demasiado viejos y no tenían valor alguno para el proceso de toma de decisiones. Los usuarios finales no sólo no veían valor agregado alguno, sino que no usaban los reportes por que tardaban demasiado en recibirlos. Este proceso de distribución tan largo se convirtió en la excusa para tener un bajo rendimiento, porque los usuarios alegaban que no contaban con la información adecuada a tiempo. Asimismo, no era fácil desarrollar reportes nuevos o hacer modificaciones a los existentes, y esto hacia que el proceso general fuera aún más difícil de manejar.
En la organización hay diferentes encargados de la toma de decisiones que deben analizar los datos de formas distintas. Al no poder personalizar y cambiar los reportes existentes, o desarrollar reportes nuevos, los usuarios no podían aprovechar todas las ventajas. Tenían acceso únicamente a reportes impresos, por lo tanto, sólo podían visualizarlos sin acceder a los datos fuente y sin manipular su estructura.
Además, los usuarios estaban descontentos con el retraso que había entre los procesos de fin de mes y la recepción de los reportes, entonces no proporcionaban a la oficina del vicepresidente de servicios administrativos la información de planeación financiera de todos los campus. El vicepresidente no estaba recibiendo retroalimentación sobre las actividades de planeación de los diferentes departamentos, sino excusas que buscaban justificar la poca información que recibían los encargados de la toma de decisiones. Sin la información correcta, estos últimos suponían que no podían tomar las decisiones correctas.
La selección de esta solución había sido directa, ya que un colega de David Dewey, un controlador del NSCC, le había recomendado Seagate Info 7.0. Después de una visita de tres días de Business Objects, el sistema estaba en funcionamiento. Al cabo de semana y media de trabajo intenso, los reportes se estaban publicando en la web; los usuarios podían cargarlos y acceder a ellos de forma directa para obtener la información en tiempo real. Dos semanas más tarde, se había finalizado el proceso del cambio. Esta nueva funcionalidad de generación de reportes se acopló con la implementación de ERP, de manera que la mayoría de los usuarios pensaba que estos reportes nuevos formaban parte de PeopleSoft, lo que provocó una aceptación natural. También se colocó el logotipo de PeopleSoft en los reportes para dar la ilusión de que se estaba usando un solo sistema. Gracias a esta táctica fue posible tener una integración uniforme, ya que la comunidad de usuarios no se vio afectada.
Uno de los temas principales de la implementación era si también se usaría PeopleSoft como herramienta de generación de reportes. La mayoría de los usuarios de los reportes se concentraban en los departamentos financieros de los distintos campus, lo que hacía que la capacitación relacionada con la adopción del sistema fuera tardada y costosa. La alternativa era implementar un sistema de generación de reportes que se pudiera integrar con el sistema ERP, de forma uniforme y fácil para los usuarios, para simplificar la transición. Se tomó la decisión de implementar la herramienta de generación de reportes de un tercero para aprovechar las capacidades avanzadas que ofrecía. Una vez que se creó el esquema de trabajo para la generación de reportes, se creó un proyecto piloto donde se capacitó a quince usuarios de los distintos campus del NSCC como súper usuarios. Desde la implementación original de Crystal Reports, el uso de Business Objects en la organización ha crecido por encima de los 200 usuarios.
Además, fue fácil obtener la aceptación de la dirección, porque los costos relacionados con la implementación fueron 75 por ciento más bajos con la versión de prueba que con una implementación de Crystal Reports desde un principio. Esto significaba que el riesgo de la implementación era mínimo o nulo. El riesgo se evaluó con base en criterios simples, donde los factores principales eran una implementación relativamente gratuita gracias a la versión de prueba (además de que la dirección creía que las cosas no podían ser peores). La preocupación principal era la necesidad de fomentar un cambio en un proceso que resultaba frustrante para los encargados de la toma de decisiones financieras de todos los niveles. Por ello, no vieron mucho riesgo en implementar un sistema nuevo de generación de reportes por sólo $2,000 a $3,000 dólares (USD); lo veían como un costo muy bajo que se sumaba a las ventajas de probar algo nuevo.
Cuando los usuarios finales pasaron de distribuir los reportes físicamente a poder acceder a ellos (a través de Internet o mediante su distribución por correo electrónico), adquirieron la libertad para usar y manipular los datos. Los datos se generaban justo al terminar el mes, por lo tanto, los usuarios podían acceder a los reportes que deseaban al cerrar el periodo financiero. Con este acceso nuevo a los reportes se generó una serie de solicitudes por parte de los usuarios finales para hacer cambios a los estados de resultados. Se efectuaron dichos cambios, que implicaban actualizar las visualizaciones de los reportes y hacer que el número de variaciones de los mismos creciera exponencialmente. Ahora los encargados de la toma de decisiones podían acceder a los datos correctos en el momento correcto.
El uso de los reportes aumentó y surgió la necesidad de contar con un ambiente del servidor más estable que pudiera cubrir las necesidades de los usuarios adicionales, que ya eran más de 200. Asimismo, se tomó la decisión de comprar licencias adicionales e implementar Crystal Enterprise, haciendo las actualizaciones posteriores conforme se iban publicando las nuevas versiones. Ahora, se crea una versión del estado de resultados como un reporte que se abre por medio de una pregunta al usuario, para permitir que cada usuario visualice el reporte en la forma que lo necesite. Desde el punto de vista del usuario, sólo hay un reporte; sin embargo, este reporte que se abre con una pregunta reemplaza más de treinta variaciones del estado de resultados.
El ambiente de generación de reportes de Crystal ha progresado y ahora incluye la simplificación de recursos humanos y la gestión de la administración estudiantil. El NSCC cuenta con más de 1,200 empleados y 25,000 estudiantes, por lo tanto, la generación de reportes empresariales se ha convertido en la norma. El departamento de finanzas sigue siendo quien tiene mejor conocimiento y experiencia con Crystal Reports, y esto se traduce en una mayor adopción y una aceptación más general.
El problema del servidor magnifica el reto de crear un sistema que pueda crecer con el tiempo. Es de vital importancia identificar los requisitos técnicos y funcionales y explicar el crecimiento anticipado, especialmente cuando se desarrolla una plataforma de BI. Hay que identificar las especificaciones, ya sea que se extraigan datos de un almacén de datos o se usen reportes u otras funciones de BI encima de un sistema existente. Del mismo modo, no hay que ignorar la importancia que tiene contar con un ambiente de desarrollo y pruebas para garantizar el desarrollo continuo de las funciones que pueden satisfacer las necesidades cambiantes de los usuarios. Dicho ambiente de pruebas también puede facilitar la transición a versiones más nuevas de BI y a las herramientas de generación de reportes. Asimismo, las pruebas pueden ayudar a las organizaciones a identificar los problemas relacionados con la transición, y solucionarlos antes de que afecten a los usuarios. Por lo tanto, puede esperarse tener una aceptación en toda la organización, siempre y cuando los usuarios no se vean afectados innecesariamente con cada implementación de actualizaciones al software.
Una experiencia interna también ayuda a la aceptación por parte de los usuarios finales, ya que con ella no tienen que recurrir a soporte externo en caso de tener un problema. Si bien siempre es necesario mantener el contacto con el proveedor de BI cuando hay problemas, los usuarios vivirán una experiencia que parecerá libre de problemas cuando puedan hablar con un colega de los problemas, las preocupaciones o las solicitudes de cambios. Es importante trabajar con un proveedor, como Business Objects, que capacitará a los usuarios de tal forma que los haga independientes y les dé la capacidad para desarrollar y mantener sus propios ambientes de BI. Asimismo, es esencial crear un ambiente donde los usuarios no se den cuenta de la transición entre una versión y otra o de los cambios, y no tengan dificultades técnicas. En otras palabras, ya sea que la solución se opere en paralelo o se pruebe detalladamente antes de iniciar la operación, es importante dar a la comunidad de usuarios un ambiente de implementación uniforme.