En lugar de “métodos para solucionar problemas” aplicaciones bien probadas y sin errores

A través de una entrada en los blogs de SAP SCN encontramos un método para solucionar problemas en SAP Visual Intelligence, puede ser útil tener en cuenta estas sugerencias para detectar el problema sobre todo cuando el tiempo apremia y el “error inexplicable” paraliza el avance de un proyecto, pero mejor que estas “metodologías” sería más útiles no utilizarlas porque las aplicaciones son estables y no presentan “extraños errores”.


A través de una entrada en los blogs de SAP SCN encontramos un método para solucionar problemas en SAP Visual Intelligence, puede ser útil tener en cuenta estas sugerencias para detectar el problema sobre todo cuando el tiempo apremia y el “error inexplicable” paraliza el avance de un proyecto, pero mejor que estas “metodologías” sería más útiles no utilizarlas porque las aplicaciones son estables y no presentan “extraños errores”.

En SAP, para que un producto pase a la categoría de “disponibilidad general” y por consiguiente todos los usuarios puedan utilizarlo, antes pasa por una fase denominada ramm-up, en la que se prueba en determinadas empresas (clientes) y para que finalice esta fase deberán pasar a producción por lo menos, por norma general, 10 proyectos.  Hemos tenido la suerte de colaborar en proyecto con SAP BusinessObjects XI 3.1, SAP BusinessObjects BI 4.0 y SAP Business Planning and Consolidation en todas sus versiones (SAP BPC 5.0, 7.0, 7.5 y 10.0) y por más suerte aún, casi siempre ha coincidido con la finalización del ramp-up del producto y en todos los casos los “errores inexplicables” han surgido y mucho.

Cada uno, por su experiencia, descubrirá su metodología para encontrar la solución a un “error inexplicable”, pero antes de reproducir el error y tratar de descubrir la solución, antes deberíamos buscar si el error ha sido reportado y si hay alguna explicación, sugerencia o solución.  Las búsqueda debería comenzar por la página de soporte de SAP Marketplace (buscando las notas que coincidan con los códigos o mensajes de error y ordenándolas descendentemente), luego en los foros de SAP SCN (en la búsqueda de la página de soporte del Marketplace también se incluye algunos resultados de este foro) y finalmente utilizando las opciones de búsqueda avanzada de Google.  SAP responde inmediatamente cuando se le escribe una nota desde la página de soporte, pero tener la solución puede resultar más inmediato si la buscamos.

Al final, la experiencia enseña que una nueva versión de un producto tiene una etapa de maduración de alrededor de un año, luego de su liberación, un “ramp-up extra” se pone en marcha con los primeros usuarios que deciden implementarlo.  Con SAP BusinessObjects BI 4.0 fue así, casi exactamente un año después de su liberación, SAP presentó el SP04, una versión mucho más estable de la que inicialmente presentó, durante ese primer año se dieron alrededor de 15 patches (actualizaciones para sólo corregir errores) que solucionaron más de 600 incidencias.

Para SAP BPC estimamos una situación similar, han transcurrido casi 7 meses de su liberación, y en te tiempo se han publicado varias actualizaciones (8 SP para el servidor y más de 35 para el cliente, denominado EPM Add-in, actualmente en SP 12 Patch 07) que solucionan errores que resulta sorprendente que no se detectaran en la fase de puesta en producción de los 10 proyectos de la fase de ramp-up.  De cualquier modo, conociendo sus características y posibilidades de esta plataforma para la automatización de procesos financieros – contables, luego de las actualizaciones previstas para diciembre (Servidor 10.0 NW SP09 y EPM Add-in 10.0 SP14) creemos  que cualquier nueva implementación tendrá muchos menos contratiempos por errores en el producto.

Una gráfica de miedo

De acuerdo con la fecha de este post compartimos este enlace a una gráfica o visualización diseñada con SAP BusinessObjects Dashboard (Xcelsius), una muestra más de las posibilidades que brinda esta herramienta. En el enlace de referencia podrás ver la muestra en ejecución (en formato Flash) y el fichero original (.XLF) por si deseas conocer como se ha diseñado.


De acuerdo con la fecha de este post compartimos este enlace a una gráfica o visualización diseñada con SAP BusinessObjects Dashboard (Xcelsius), una muestra más de las posibilidades que brinda esta herramienta.  En el enlace de referencia podrás ver la muestra en ejecución (en formato Flash) y el fichero original (.XLF) por si deseas conocer como se ha diseñado.

Referencia: SAP SDN

SAP NW BW powered by SAP HANA, obliga a rediseñar el modelo de datos

Al utilizar cualquier tecnología, en su implementación, podemos vernos obligados a realizar ciertas “soluciones” que si estuvieras utilizando otro producto no serían necesarias. Esta situación también se produce con SAP NetWeaver Business Warehouse (SAP NW BW), que para agilizar los tiempos de respuesta se diseña un modelo de datos, algunas veces muy complejo. Pero si pensamos en SAP NW BW sobre SAP HANA (SAP NW BW powered by SAP HANA) debemos considerar las siguientes situaciones:


Al utilizar cualquier tecnología, en su implementación, podemos vernos obligados a realizar ciertas “soluciones” que si estuvieras utilizando otro producto no serían necesarias.  Esta situación también se produce con SAP NetWeaver Business Warehouse (SAP NW BW), que para agilizar los tiempos de respuesta se diseña un modelo de datos, algunas veces muy complejo.  Pero si pensamos en SAP NW BW sobre SAP HANA (SAP NW BW powered by SAP HANA) debemos considerar las siguientes situaciones:

  • Se requiere que la presentación de informes sea más rápida. Como ya muchas veces se ha comentado, SAP HANA brinda tiempos muy reducidos con relación a una plataforma estándar de SAP NW BW.  Tener SAP NW BW sobre SAP HANA  requiere la versión 7.3 de SAP NW BW, lo que puede incrementar los costos si se tiene una versión anterior.
  • Se desea simplificar el modelo de datos de su plataforma SAP NW BW. Con SAP NW BW powered by SAP HANA ya no es necesario la redundancia de datos o agregados para agilizar los procesos y flujos de datos, esto puede conllevar a un trabajo inicial de rediseño de la arquitectura de datos, pero que en el futuro facilitará la administración de los datos, la escalabilidad o adaptabilidad a nuevas necesidades y desarrollos.
  • Se necesita cargas de datos más rápidas.  SAP HANA brindará cargas de datos más rápidas porque tendrá menos tablas e índices por actualizar, pero un impacto significativo se logrará si se diseña un modelo más eficiente, con menos capas y eliminando redundancias de datos, innecesarias en SAP NW BW powered by SAP HANA.

Considerando estos aspectos, podríamos señalar que llevar SAP NW BW a SAP HANA no pasa sólo por una migración de un producto, para obtener una mejora considerable estaríamos hablando de dos fases:

  • Migración técnica (según el RDS correspondiente demandaría alrededor de 3 meses).
  • Rediseño del modelo de datos para eliminar capas y estructuras innecesarias, que dependiendo de su complejidad, podría ser necesario dividir esta fase en proyectos o etapas.

La consultoría informática necesita su libro de historia

Dicen que “la historia se repite” o que “es necesario conocer el pasado para comprender el presente”, frases de uso frecuente que bien se podrían aplicar a la consultoría informática, que si se recopilara anécdotas e historias bien podrían tomar forma de más de un libro. Algunas anécdotas o historias no tan agradables como pueden ser las demandas de un cliente porque no está muy contento con el resultado de un proyecto de implementación, por causas como los que señala el artículo de referencia:


Dicen que “la historia se repite” o que “es necesario conocer el pasado para comprender el presente”, frases de uso frecuente que bien se podrían aplicar a la consultoría informática, que  si se recopilara anécdotas e historias bien podrían tomar forma de más de un libro.  Algunas anécdotas o historias no tan agradables como pueden ser las demandas de un cliente porque no está muy contento con el resultado de un proyecto de implementación, por causas como los que señala el artículo de referencia:

  • Problemas o diferencias políticas.
  • Incremento desproporcionado de los costes de los proyectos.
  • No se logran cubrir los objetivos esperados, insatisfacción de los usuarios.
  • Considerable incumplimiento de los plazos de entrega (“dijeron que podían hacerlo en siete semanas. Les dimos siete meses, y tenemos cero…”).
  • Presentación de un “demo” amañado en la preventa
  • Asignar consultores sin experiencia al proyecto.
  • Errores informáticos que generan incorrectamente pagos millonarios (Diagnóstico de auditoría: “el sistema se puso en marcha antes de superar ciertos hitos de prueba”).

Conocer un poco más sobre estos casos serían verdaderas lecciones para clientes y consultores.  Por ejemplo, interesante resulta el argumento de defensa de Oracle ante una demanda: “… Cuando los problemas surgieron durante el transcurso del proyecto, se hizo evidente que el cliente no comprendió adecuadamente la tecnología, como tampoco sabía los pasos que debía seguir para completar el proyecto…”

Referencias: aquí y aquí