1. Introducción
En estos últimos años, SAP ha realizado una gran inversión en I+D, dando como resultado el lanzamiento o actualización de muchos productos. SAP HANA por ejemplo ha abierto nuevas posibilidades, algunas disruptivas, en cuanto a SAP BW y analytics se refiere.
Los consultores nos hemos visto obligados a realizar un esfuerzo en cuanto a la actualización de nuestros conocimientos y replantearnos ciertas cuestiones técnicas que dábamos como ciertas.
Esto, a mi modo de ver, ha provocado que durante la ejecución den un proyecto de SAP BW, prioricemos y dediquemos más esfuerzo a cuestiones técnicas y nos olvidamos un poco del objetivo final, que es la realización de un proyecto que resuelva las necesidades del usuario. Este documento pretende recordarnos como debemos ejecutar un proyecto de SAP BW de modo que cumplamos dicho objetivo.
El contenido mostrado a continuación sigue la metodología SAP (de hecho está obtenido principalmente de material didáctico de SAP) para proyectos SAP BW (aunque con algunos retoques podría servir también para proyectos de Business Intelligence en otras tecnologías)
Salvo algunas pinceladas, obviaré los aspectos más puramente de gestión (control de alcance, tiempo), y aquellos habituales en cualquier tipo de proyecto (identificación de stakeholders, identificación de key-users, plan de riesgos…)
2. Escenario
Queremos abordar un proyecto de SAP BW de tamaño medio en un entorno y estrategia de SAP BW pre-existente.
3. Fases del proyecto
Los proyectos de SAP tienen 5 fases:
- Preparación del proyecto
Se realiza el planning inicial, alcance, organización de la infraestructrura, disponibilidad de recursos, revisión del presupuesto y verificación de que disponemos de los perfiles adecuados.
En muchos casos, la mayoría de tareas ya las habremos realizado en la fase de oferta del proyecto, aunque resulta conveniente revisarlas pues es posible que desde la fase de oferta hayamos recibido nuevos inputs que obliguen a realizar algunos cambios
- Business blueprint
En esta fase tendremos que aterrizar como se van a desarrollar en entorno SAP los procesos empresariales. El resultado será una documentación detallada “del como”. Este documento se centrará sobretodo en ésta fase.
- Realización
Implementación de los requerimientos y procesos identificados en la fase anterior. En nuestro caso, será la creación de los objetos de SAP BW (datos maestros, datos transaccionales), transformaciones y informes.
- Preparación final
LA frontera entre la fase de realización y preparación final no siempre está clara. A mi modo de ver, sería la fase donde se realizaría la formación a usuarios, finalización de toda la documentación, obtención del ok por parte del cliente/usuario, preparación de órdenes de transporte definititvas y planificación de talladas de la puesta en producción (y de cutover si fuera el caso)
- Puesta en productivo y soporte
Como su nombre indica, en esta fase se realiza la puesta en producción y el soporte pactado anteriormente en el alcance del proyecto.
Ésta podría ser una planificación de un proyecto BW:
(Vista detallada:)
3.1 Preparación del proyecto
No me centraré mucho en esta fase, ya que no es distinta a la de cualquier otro proyecto (ya sea en SAP o en cualquier otra metodología). Para noveles en la gestión de proyectos, recomiendo encarecidamente familiarizarse con la metodología PMP, por ejemplo.
Algunas de las actividades serían:
- Definición del alcance (áreas de negocio, procesos a incluir, tecnologías a emplear…)
- Identificación de los recursos (presupuesto, hardware, lugar de trabajo, conectividades, etc)
- Responsables (el “quien es quien” en el proyecto)
- Metodología del proyecto
- Guía de desarrollo
- Repositorio de información
3.2 Business Blueprint
La realización del Business Blueprint (en adelante BBP), puede ser una de las tareas más complejas del proyecto. La definición correcta del BBP puede marcar el éxito o no del proyecto de BI.
Mi experiencia personal es que los problemas que puedan surgir durante la etapa de realización del proyecto, pueden solucionarse si se detectan a tiempo, pero es difícil terminar con éxito un proyecto si la etapa de BBP no se ha realizado de forma satisfactoria.
La confección de un BBP trae consigo la realización de una serie de tareas que he intentado hacer coincidir en un índice de lo que podría ser un BBP. Existe cierto debate sobre si un BBP debería contener aspectos técnicos o nomenclatura de BW o no. Bajo mi punto de vista, un BBP SI debe contemplar aspectos técnicos. No obstante, como el usuario no tiene por qué tener conocimientos técnicos de BW, lo que suelo hacer es hacer un índice donde los primeros puntos estén dirigidos a “todo el mundo”, y luego puntos específicos más técnicos, destinados por ejemplo a los responsables de IT o a los desarrolladores.
La inclusión de aspectos técnicos nos puede ayudar a detectar GAPS y a acotar alcance por ejemplo, así como evitar malentendidos con el departamento de IT.
Este podría ser un ejemplo de índice de BBP:
1. Introducción 2. Requerimientos 3. Atributos e indicadores 4. Matriz de indicadores 5. Matriz de requerimientos vs proceso y GAP análisis 6. Resumen del modelo arquitectónico 7. Seguridad 8. Informes 9. Modelo lógico 10. Modelo de SAP BW 10.1 Modelo 10.2. Procesos y transformaciones 11. Consideraciones de Alcance |
De este modo, los apartados 1 al 8 podrán ser leídos por el usuario final, y deberán ser redactados evitando la nomenglatura de SAP BW
3.2.1 Requerimientos
Durante una serie de actividades, levantaremos los requerimientos expresados por diferentes interlocutores (key-users, IT, spónsor).
Los requerimientos que finalmente haremos constar en este punto, serán los que implementaremos y no tienen que ser necesariamente todos los que hayamos recopilado. Los que por algún u otro motivo se descarten, los podremos hacer constan en el apartado de GAP análisis o en el de consideraciones de alcance.
Actividades para obtener los requerimientos:
- Revisión del alcance del proyecto
- Workshops con los usuarios implicados
- Obtención de los requerimientos de los informes (requerimientos de navegabilidad, auto-consumo, acceso...)
Las siguientes preguntas pueden ser útiles para la obtención de los requerimientos:
- ¿Qué atributos e indicadores son necesarios?
- ¿Qué filtros, drill-down y jerarquías son necesarias?
- ¿Qué latencia de carga de datos es aceptable? ¿se necesita real-time?
- ¿qué profundidad histórica es necesaria?
- ¿Qué niveles de autorización son necesarios?
- ¿Qué nivel de granularidad es necesaria?
- ¿Cuántos usuarios utilizarán los informes? ¿todos tienen en mismo nivel de responsabilidad?
- ¿los informes deben ser multiidioma?
- ¿hay que agrupar informes en función de la tipología de usuario?
- ¿Qué informes se quieren?
3.2.2 Atributos e indicadores
En este apartado censaremos todos los atributos e indicadores que se van a considerar, así como su definición.
3.2.3 Matriz de indicadores
Realizaremos una matriz donde definiremos para cada indicador, que dimensiones de análisis va a tener. Es importante realizar esta matriz de forma que sea entendible por el usuario.
En las filas colocaremos el indicador, y en las columnas las diferentes dimensiones, así como información adicional referente al indicador (por ejemplo el TIME visualizado en la figura de a continuación nos indica la mínima granularidad deseada)
Si realizamos la matriz correctamente, es bastante probable que los indicadores con el mismo conjunto de dimensiones, formen parte del mismo infoprovider.
Al cuadro superior, también se puede agregar (aunque no soy especialmente partidario), información como el tipo de dato (unidad, sistema fuente, si es calculado o no, si existe en el content, etc)
En ocasiones, una vez implantado el proyecto, este cuadro me ha resultado de mucha utilidad para explicar al usuario por ejemplo por qué aparece el “#” cuando coloca ciertas dimensiones en un indicador.
3.2.4 Matriz de requerimientos vs proceso y GAP análisis
Realizaremos una matriz con los requerimientos y el proceso que lo cubrirá.
Este punto en ciertas ocasiones puede resultar algo pesado de realizar y poco operativo. Bien sea mediante ésta matriz o por otros métodos, debemos ser capaces de demostrar que todos los requerimientos están cubiertos.
Si alguno de los requerimientos no pueden cumplirse mediante la solución adoptada, deberá ser explicada en este punto.
3.2.5 Resumen del modelo arquitectónico
En este modelo intentaremos plasmar un resumen de los objetos que van a ser necesarios crear para acometer los requerimientos de reporting.
Paso 1: Identificar los datamarts y fuentes de datos
Para ello, tenemos 3 posibles estrategias:
- Crear el modelo a partir de los indicadores (Top-Down)
Lo que hacemos es un “top-down”sobre el “¿que quieres?” obtenido a partir del listado de indicadores.
Probablemente desde un punto de vista conceptual, este método es el mejor, pero la experiencia me indica que éste método es especialmente recomendable en proyectos enfocados a cuadro de mandos, donde todo gira entorno a los KPi, pero no lo es en aquellos proyectos más enfocados a informes operativos y/o tácticos (que por otro lado son los más habituales en entornos SAP).
- Crear el modelo a partir de las fuentes de datos (Bottom-UP)
En este método, hacemos el foco en los procesos de negocio del sistema origen y en las fuentes de datos (incluyendo el business content como otra fuente de datos)
Este método es especialmente útil en proyectos donde los informes son muy operativos o cercanos al sistema SAP ERP.
También en proyectos donde los requerimientos de reporting no están demasiado claros, situación típica por ejemplo en proyectos donde la implantación del BI va en paralelo a la implantación del ERP
Cuando revisemos el BI-Content, hay que tener en cuenta que éste está pensado con una estrategia "bottom-up", es por esto que la situación mas usual con la que nos encontremos con el BI content, es que lo utilicemos para las capas de extracción y staging y quizás para la primera capa de consolidación, pero lo obviemos para las capas superiores (especialmente si utilizamos estrategia Top-down)
- Crear el modelo basado en estrategia mixta
Personalmente es el método que utilizo con mayor frecuencia. Se trata de cubrir los requerimientos de KPI mediante el Top-Down, y “completarlo” con el Bottom-Up”
Paso 2 y 3 : Identifcar las fuentes de datos y transformaciones
Para cada fuente de datos, identificamos las transformaciones (las describiremos en detalle más adelante)
Paso 4: Identificar las capas
Identificamos las capas de nuestro proyecto (LSA o LSA++ en el caso de HANA)
Una vez realizados los 4 pasos anteriores, obtendremos un resumen del modelo arquitectónico.
3.2.6 Seguridad
Detallaremos que requerimientos de seguridad se han requerido, identificando los diferentes posibles roles de usuarios, características relevantes de autorización y posibles accesos a informes en función del rol de usuario
3.2.7 Informes
Identificaremos que informes se van a realizar, con que atributos e indicadores por defecto, cuales opcionales, y que filtros se van a incluir (y tipo de variable asociada al filtro)
3.2.8 Modelo lógico
Se trata de identificar las relaciones entre las características y los indicadores. Ayuda a identificar que son características de lo que son atributos de características.
Hay que identificar qué características dependen de otras y que propiedades deben tener.
Básicamente se trata de analizar los datos del sistema fuente y encontrar qué características o combinaciones son las características clave más básicas y cuales son características de alto nivel.
Las características de alto nivel cuyos valores están determinados por características de bajo nivel, serán atributos en nuestro modelo.
Puede ocurrir, especialmente si el proyecto de SAP BW va en paralelo al proyecto del sistema fuente, que tengamos que realizar suposiciones. En este caso será importante documentarlas en este punto.
Aunque SAP recomienda realizar siempre un modelo lógico, personalmente no siempre lo he realizado. Solo en aquellos casos donde el sistema fuente no es estándar o se trata de módulos SAP desconocidos para los implicados en el proyecto.
Alternativamente al modelo de entidad-relación, puede hacerse un diagrama de burbuja. En mi caso personal, no me siento confortable con este tipo de diagramas pues pienso que no expresa las relaciones de forma tan concreta como el diagrama de entidad-relación
3.2.9 Modelo de datos BW
3.2.9.1 Modelo de datos
Finalmente realizaremos el modelo de datos. Bajo mi punto de vista, el modelo de datos de BW tiene que ser el máximo detallado posible, y como comentaba en el inicio de cómo realizar BBP y su índice, no tiene que ser necesariamente entendible por el usuario final (para ello ya hemos realizado anteriormente un modelo de datos resumido).
Aquí decidiremos que tipo de objetos utilizaremos (que tipo de ADSO, que composite-providers, si utilizaremos dominios para el master data, si utilizaremos infoobjetos o definiremos campos en los ADSO, Open ODS…)
Algunos puntos a considerar:
- Si se requieren “fotos” de los datos
- Si es necesario almacenar los cambios en los datos maestros
- Que tipos de ADSO vamos a utilizar
- Si los ratios serán agregados o de sobreescritura
- Claves de los ADSO y granularidad de los mismos
- Atributos dependientes del tiempo
- Atributos de navegación
3.2.9.2 Transformaciones
En este apartado indicaremos las transformaciones con relevancia funcional
3.2.10 Consideraciones de alcance
Este apartado puede ser especialmente relevante en ciertos proyectos. Deberemos especificar que requerimientos NO se van a abordar o que asunciones se han considerado para elaborar el BBP.
Será importante que verifiquemos que todos los involucrados en el proyecto hayan leído y consensuado éste punto.
3.3 Realización del proyecto
En esta fase se realizan las siguientes actividades:
- Activación del content, Creación de los infoobjetos maestros, creación de los infoproviders, reglas de transformación…
- Generación de los informes
- Documentación técnica (recomiendo realizarla en paralelo al desarrollo)
- Creación de las cadenas de carga
- Pruebas unitarias
- Pruebas usuario: la metodología SAP incluye las pruebas de usuario en la fase final. A mi modo de ver, puede depender del proyecto. En proyectos complejos por ejemplo puede ser conveniente realizar unas primeras pruebas de usuario con los responsables de IT (si existen) para obtener una primera ceritificación, y dejar las pruebas de usuario final en la fase de preparación final
La planificación habitual en esta fase suele ir en orden de las diferentes capas LSA o LSA++ que hayamos identificado. Probablemente empezaremos por los extractores, desarrollaremos los ADSO de la primera capa, los de la segunda, y así sucesivamente y dejaremos para el final la capa de reporting.
No obstante, en algunos proyectos puede resultar muy interesante presentar un prototipo al usuario o bien realizar una prueba de concepto cuando por ejemplo tenemos dudas sobre algunas funcionalidades en la integración de la capa de reporting con el modelado BW. En estos casos podemos realizar diversas iteraciones sobre el orden comentado anteriormente.
3.4 Preparación final
En esta fase se realizan las siguientes actividades:
- Planificación de cadenas
- Verificación de performance y revisión de espacio consumido
- Pruebas de usuario (UAT)
- Formación usuario
3.5 Go-Live y soporte
Las tareas a realizar en esta fase dependerán mucho del tipo de proyecto y del alcance acordado en la fase inicial. En la mayoría de casos esta fase consistirá únicamente en la resolución de incidencias post go-live y en algunos casos en el soporte al usuario ante dudas durante las primeras semanas. No obstante, el alcance de esta fase podría ser mas amplia, debiéndose contemplar las siguientes tareas:
- Otimización del sistema (por ejemplo en HANA la determinación de “datos fríos” y “datos calientes” (aplica solo en HANA)
- Creación del centro de competencia BI
- Gestión de archivados
- Proporcionar soporte a notas SAP
- Monitorización del sistema
4. Bibliografía
- SAP BW powered by SAP HANA: Data Warehouse Modeling ( BW330H_EN_Col15_R1.3)
- SAP Managed Tags:
