BW para Power Users

Proyecto SAP - APDR

08 de Octubre de 2009
Captulo 1
Terico
Introduccin
En los siguientes slides se presentarn los conceptos ms importantes
requeridos para poder llevar a cabo las actividades diarias de los Power Users
de BW.

En ste primer captulo, se repasarn los conceptos tericos explicados en el
Overview BW, y se ampliarn con temas adicionales y ejemplos concretos
que darn una visin real de la teora de BW.

En los siguientes captulos se detallarn en detalle las aplicaciones de BW
requeridas en el da a da de los Power Users: BEx Analyzer y Query Designer.
Asimismo, se complementar con ejemplos reales, donde se podr realizar un
ejercicio partiendo desde una necesidad particular, hasta llegar al desarrollo de
un query.

Qu es BW?
Business Warehouse es una solucin de anlisis de informaciones, planeamiento estratgico y
financiero gerencial .

Colecta informaciones provenientes de diferentes sistemas, plataformas y aplicaciones y las
utiliza para aumentar la cualidad de la informacin de la compaa, dndole un valor agregado al
proceso de toma de decisin.

Sus datos quedan almacenados en objetos (por ejemplo: InfoCubos) donde se almacena
informacin de determinado tema con diferentes perspectivas de anlisis: Cubo de Compras,
Cubo de Finanzas, Cubo Comercial, etc.

Los reportes de BW se denominan Query y se acceden mediante una aplicacin de la suite de
SAP NetWeaver, la cual se denomina BEx Analyzer y utiliza el front-end del Excel para su
implementacin.

BW es una herramienta del SAP en el rea de BI y requiere un servidor propio (adems del ERP)
garantizando su independencia, dicha independencia determina que los datos se encuentran tanto
en el sistema del cual se abastece BW (Ejemplo SAP R/3) como en BW. Para llevar a cabo dicho
pasaje de informacin se realizan cargas configuradas a nivel de consultora.
Conocimiento
Analtico del
Negocio
Estrategia de
Negocios
Procesos del
Negocio
Transaccionales
Datos Maestros
Ciclo de Vida Operativo-Analtico
Datos Maestros
X
Arquitectura BW
Cuando Crear un Query, y Cuando un Reporte en R/3?
A la hora de la necesidad reportes, usualmente se asocia dicha tarea a BW. No obstante, dependiendo
del caso es conveniente realizar un anlisis previo.
A continuacin se enumeran una serie de requisitos para identificar si la consulta debe ser creada por
BW o SAP R/3

1. Si el reportes requiere retractar la posicin del momento (online), indica que se trata de un reporte
operacional y deber realizarse en R/3. El enfoque de BW est orientado a reportes gerenciales
donde no es necesario informacin al momento actual, como mucho informacin hasta el da
anterior.

2. El nivel de detalle de la consulta debe ser una cuestin determinante a la hora de la eleccin. BW
tiende a brindar informacin ms consolidada, resumida y en pocas lneas, mientras que en R/3 se
brindan reportes ms detallados (A nivel documento).

3. Es aconsejable considerar el volumen de datos a analizar. En caso de ser muy elevado, BW es
posible que funcione con mayor performance puesto a que tiene podr ayudar en el desempeo del
SAP ERP, pues gira en servidor separado. Adicionalmente podemos decir que ese caso, BW
aliviara al servidor de R/3 donde adems de los reportes se carga con la tarea operativa del da a
da.

4. Otro aspecto de gran consideracin es evaluar si el reportes integrar informacin de varios
mdulos en el mismo. En ese caso, si es de nivel gerencial, es conveniente desarrollarlo va BW.

5. Finalmente, conviene recomendar que en caso de Informes crticos para los procesos del negocio
es aconsejable que permanezcan en R/3; en casos de retrasos o problemas en la carga de los
datos del ERP hacia BW, no se afectar el reporte.
Ejemplo de Reporte R/3
Analizaremos en primer lugar un reporte de pedidos desarrollado en R/3.
En dicho reporte, se detalla a nivel de documento/posicin para un solicitante
(cliente) en particular y un rango de fechas a nivel diario
Ejemplo de Reporte BW
Por otra parte, ahora analizaremos un
reporte realizado en BW tambin de
pedidos, donde la informacin se
muestra claramente con una
granularidad mayor: Varios Solicitantes
(cliente), por material y Ao.

Tipos de Usuario
Power User
Son usuarios con la responsabilidad de dominar la creacin de querys, dominar el
contenido de todo el cubo, colaborar en el mantenimiento del glosario, facilidades
de navegacin en la herramienta y multiplicar el conocimiento a las personas de su
rea a travs de entrenamiento y soporte tcnico.

Estos usuarios tendrn canal abierto con sus socios en las otras empresas para
acompaamiento de las querys globales y alineamiento de nuevas necesidades de
los negocios. Ese alineamiento servir para una estandarizacin de las
informaciones en las empresas del Grupo Votorantim y la seguridad de la utilizacin
de las mejores prcticas.

El Power User tiene la funcin de garantizar las informaciones necesarias del
departamento y recibir las llamadas relacionadas a su rea de todo End User de su
empresa.
Tipos de Usuario (2)
End User

Son los usuarios finales del BW que no necesitan conocimiento profundo de la
herramienta; solamente utilizan el BW para llegar a un informe final para
anlisis y exploracin. Podemos tener usuarios que slo ejecutan una query y
otros que adems de ejecutar, realizan la exploracin de las informaciones a
travs de la navegacin en la query. Un ejemplo son los Analistas de Negocios
que necesitan hacer la exploracin de los datos para su anlisis.

El End User, va contacto directo con el Power User de su frente, puede:
1) Cuestionar los nmeros y frmulas de la query,
2) Solicitar nueva query
3) Solicitar alteracin en la query.

Para los problemas arriba mencionados no tendremos soporte de Help Desk
para End User..
Tipos de Usuario (3)
Consumidores Finales

Son los usuarios que no necesitan acceso al BW, pero necesitan sus
informaciones generadas en forma de grficos o tablas para tomada de
decisin, en formato Excel o HTML.

El acceso a estas informaciones puede ser a travs de mails automticos,
portal de Internet, directorio en la red, etc.

Cabe al Power-User viabilizar el acceso de estos usuarios a la informacin
generada por el BW.
Glosario BW
InfoProvider
Son las fuentes de informacin utilizados en las consultas (query) de BW.
Pueden clasificarse en fsicos y virtuales
Fsico (Cubo / ODS):
Almacenamiento de los datos en tablas de base de datos reales
Virtual (InfoSet / MultiProvider):
Cuando es una recopilacin de datos (como un fin) que slo recoge
datos de forma temporal para alimentar a una pregunta, pero no
almacenarlo permanentemente.
Query
Son las consultas de informacin realizadas en BW.
Un query obtiene datos de un solo InfoProvider
Poseen un nombre tcnico (identificacin unvoca) y una descripcin.
El naming convention establecido en Votorantim para los nombres tcnicos del
los querys es:
Q_VS_ZIC_C03_APDR_01
Se Indica el tipo de query.
Pueden comenzar con Q o Y.
Q Para querys oficiales. Pueden ser ejecutadas por los End Users
Y Para querys especficas que muchas veces tienen un uso temporal o
son futuras querys oficiales. Solo acceden los Power Users.

Se indica la unidad de negocio de Votorantim en dicha Sigla.
Para el caso de APDR y MPDR ser VS = Votorantim Siderurga
Existen querys globales, que a priori son de utilizables para todas las
empresas de Votorantim. Dichas querys se expresan con GLO

Se indica la estructura BW (el InfoProvider del query).
En este ejemplo, se menciona el nombre tcnico del
cubo de inventario: ZIC_C03
Se indica la empresa de la cual pertenece el query.
Para el caso Paz del Rio, ser APDR o MPDR dependiendo del caso. En caso que sea para ambas ser APDR.
NOTA: Se incluye dicha consideracin ya que los power user podrn visualizar en BW todas las querys de VS, no solo
las de Paz del Ro
Se coloca un contador numrico, que va
incrementando ada query


InfoObjeto
Es la unidad mnima de informacin. (Es como similar a la definicin de 1
campo de una tabla).
Los InfoObjetos son los componentes bsicos de los Cubos y dems
InfoProviders de BW
Al igual que el resto de las entidades en BW, los infoObjetos poseen un
nombre tcnico y una descripcin.
Los InfoObjetos provistos por SAP comienzan con 0, el resto (por lo
general comienzan con Zson definidos por los usuarios.
Tipos de InfoObjetos
Caractersticas: grupos de evaluacin como Centro de Costo, Centro
de Beneficio, Materiales. Una Caracterstica es un InfoProvider.
Tipos especiales de caractersticas:
Tiempo: perodo fiscal, da calendario
Unidad: cantidad de ventas, moneda local
Tcnicas: como Request. ID (loading request) o Change ID
(aggregate change runs)

Key figures (ratios): campos numricos que toman valor contnuamente
como cantidades y valores, por ejemplo: Ingresos, Cantidad
Facturada Precio.

Glosario BW
2da Parte


Datos Maestros:

Existe un tipo particular de caractersticas denominadas Datos Maestros.

Los mismos son comunes a todas las estructuras.
Un ejemplo clsico de dato maestro es Material (0MATERIAL).
Un ejemplo clsico de NO dato maestro es Nmero de Documento
(0DOC_NUMBER).

Los datos maestros pueden contener atributos, los cuales tambin son
caractersticas y/o datos maestros adicionalmente.
Por ejemplo el dato maestro Material (0MATERIAL) contiene como
atributo el dato maestro Grupo de Articulos (0MATL_GROUP). En
ese caso se indentifica en dentro del InfoProvider como
0MATERIAL_0MATL_GROUP indicando que es el grupo de artculos
del material.
Dicho Grupo de Artculos tambin puede ser atributo de otra
caracterstica, ejemplo: Componente (0COMPONENT)
0COMPONENT_0MATL_GROUP.

Glosario BW
2da Parte


Glosario BW
3ra Parte
Consideraciones adicionales para InfoObjetos:
Pueden ser dependiente de idioma Dependiendo del idioma en que se inicia SAP, se muestra la
descripcin.
Pueden ser dependientes de tiempo Es posible que se establezca una vigencia
Haciendo un repaso de su clasificacin:
Simples Ej: Factura
Datos Maestros Ej: Centro de Costos, Centro
Tiempo Ej: Da natural, perodo fiscal
Unidad Ej: Ton, Kg, Pesos Colombianos
Tcnicos Internos de BW
Ratios Ej: Cantidad, Valor
Es posible establecer Jerarquas de InfoObjetos
Para definir jerarquas externas y sus propiedades. Se pueden dar de alta manualmente, por archivo
plano o cargarla de R/3.
Los valores en sus hojas pueden definirse por rangos en lugar de valores individuales.
Se pueden definir mltiples jerarquas por cada InfoObjeto
Es posible que los InfoObjetos tengan la particularidad de Compounding Relacin
Esto refleja el concepto de Clave Compuesta, ej: Cost Center necesita de la Business Area para ser
identificado unvocamente.
Key Figures o Ratios requieren algunas configuraciones particulares
Deben tener determinada un tipo de unidad
Debe configurarse el tipo de agregacin: Suma, Promedio, ltimo valor, etc..
Es posible configurar modalidades de visualizacin. Ej: de a 1000, con 2 decimales.
Tambin s e puede definir un KF como attribute only, y pasara a ser un atributo de display de una
caracterstica: Ej: Capacidad de Carga de un camin.`En ese caso ser meramente de visualizacin
su utilizacin, es decir no podr ser utilizado para clculos y/o frmulas.




Las dimensiones estn compuestas por infoObjetos = Caractersticas.
En todo InfoCubo existen 3 dimensiones obligatorias adems de la Fact Table
Tiempo Le da un contexto temporal a nuestro factor de analisis. (Cuando?)
Unidades Le da un contexto cuantitativo a nuestro factor de analisis (Que?)
Tcnica Es una dimensin obligatoria que contiene datos tcnicos a nivel BW; sin utilidad para los Power Users.
A continuacin analizaremos como sera el cubo tomado a modo de ejemplo.

Luego, a su alrededor ubicaremos las diferentes dimensiones del cubo.
Ellas sern los niveles de analisis del cubo
En el centro del cubo
ubicaremos la Fact Table (o
tabla de hechos).
En ella se encontrar el factor
de analisis del Cubo, es decir
los ratios (o Key Figures)
Son los objetos centrales dentro del modelo multidimensional propuesto por BW.
Se pueden definir consultas y anlisis sobre los InfoCubos.

Son uno de los principales InfoProviders para las consultas (Querys) de BW.

A modo de ejemplo analizaremos la estructura del cubo
Resumen de Ventas.
Los cubos (o InfoCubos) al igual que los otros
InfoProviders de BW, contiene un nombre tcnico (que los
diferencia unvocamente) y una descripcin.
Los nombres tcnicos para TODOS infoProviders
siguen el siguiente naming convention:
0SD_C03

Indicador del mdulo que pertece. En
este caso es SD pero podra ser
cualquier otro (FI/CO/MM/PP/etc..)
Indicador si es Estandar o
customizado
0 Provisto por SAP
Z Customizado. Es posible
crear customizaciones de
cubos estandares o
customizaciones desde cero
La primera letra contiene un Indicador del tipo de estructura.
C InfoCubos
O ODS
MP o MC MultiProviders o MultiCubos
IS InfoSets
Los 2 siguientes caracteres numricos, indican un contador segn
mdulo y tipo de infoProvider
16
Cliente
Dest. Factura (0BILLTOPPRTY)
Dest. Mcas (0SHIP_TO)
Solicitante (0SOLD_TO)
Resp. de Pago (0PAYER)
Clasif. Clientes (0SOLD_TO_0CUST_CLASS)
Tiempo
Da (0CALDAY)
Semana (0CALWEEK)
Mes (0CALMONTH)
Ao (0CALYEAR)
Unidad
Unid. Med. Base (0BASE_UOM)
Mon. Estadstica (0STAT_CURR)
Paquete de Datos
XXX
XXX
XXX
Organizacin
Sociedad (0COMP_CODE)
Centro (0PLANT)
Grp. Vendedores (0SALES_GRP)
Repres. Ventas (0SALESEMPLY)
Puesto de Exped. (0SHIP_POINT)
Oficina de Ventas (0SALES_OFF)
Area de Ventas
Canal de Distribucin (0DIST_CHAN)
Organizacin de Ventas (0SALESORG)
Sector (0DIVISION)
Documentos
Clase de Doc. (0DOC_CLASS)
Documento (0DOC_NUMBER)
Material
Material (0MATERIAL)
Grupo de Art. (0MATERIAL_0MATL_GROUP)
Color (0MATERIAL_ZCOLOR)
Tipo de Material (0MATERIAL__0MATL_TYPE)
Ramo (0MATERIAL__0IND_SECTOR)
Componente (0COMPONENT)
Grupo de Art. (0COMPONENT_0MATL_GROUP)
Fact Table
Valor Neto en Mon. Std. (0NET_VAL_S)
Cantidad UMB (0QUANT_B)
Ctd. Documentos (0DOCUMENTS)
Ctd. Pos. Doc. (0DOC_ITEMS)
Precio Fact. Mon. Std. (0COST_VAL_S)
Observacines:
En la dimensn Material, observamos que el Dato Maestro Grupo de Artculos (0MATL_GROUP), aparece tanto como atributo del
dato maestro Material (0MATERIAL) como Componente (0COMPONENT). Mediante sus nombres tcnicos, identificamos cual
pertenece a cada uno.
IMPORTANTE:
En este ejemplo, la mayora de los infoObjetos pertencientes a las dimensiones del cubo, son Datos Maestros (a excepcin de la
caracterstica simple Documento (0DOC_NUMBER) y las pertenecientes a la dimensiones obligatorias (Tiempo/Unidad/Paquete de
Datos). Los datos maestros contienen valores y descripcin que son utilizados en todos los infoProviders de BW.

InfoCubos ( )
Se parte de una estructura multidimensional donde se organiza la informacin de acuerdo
a lneas primarias de negocio (ej. Producto, Organizacin de Ventas, Tiempo, ...) conocidas
como dimensiones.
Las dimensiones son un conjunto de caractersticas unidas las cuales tienen una relacin
jerrquica.
Luego, se realiza un anlisis de los hechos (o ratios o facts) a partir de cualquier
combinacin de Dimensiones.

$$
$$
$$
R
e
g
i
o
n

N
o
r
t
e


/




S
u
r





/



B
s
A
s

Divisin
Plasticos / Vidrios /
Cermicos
Grupo de Clientes
Grandes Tiendas
Mayoristas
Minorista
s
1) Se dispone de una estructura
multidimensional para realizar
el analisis. Se realizar un
analisis de Facturacin ($) para
distintas divisiones.
Nota: La estructura podra
tener varias mtricas posibles
para analizar. En este ejemplo
habr una sola: Facturacin
($)
$$ $$ $$
R
e
g
i
o
n

N
o
r
t
e


/




S
u
r





/



B
s
A
s

Divisin
Plasticos / Vidrios /
Cermicos
Grupo de Clientes
Grandes Tiendas
Mayoristas
Minorista
s
2) Se realiza un analisis de la
regin norte
$$ $$
$$
R
e
g
i
o
n

N
o
r
t
e


/




S
u
r





/



B
s
A
s

Divisin
Plasticos / Vidrios /
Cermicos
Grupo de Clientes
Grandes Tiendas
Mayoristas
Minorista
s
3) Se realiza un analisis de la
Regin norte para la
Divisin cermicos
$$ $$
$$
R
e
g
i
o
n

N
o
r
t
e


/




S
u
r





/



B
s
A
s

Divisin
Plasticos / Vidrios /
Cermicos
Grupo de Clientes
Grandes Tiendas
Mayoristas
Minoristas
4) Se realiza un analisis de la
Regin norte para la
Divisin cermicos y el
Grupo de Clientes
minoristas
Consultas Multidimensionales en InfoCubos
Es el nivel de Detalle que se almacenar en BW.
Es el mximo nivel de detalle que se puede lograr en el query.
Naturalmente estar vinculado al infoProvider que alimenta el Query. Cada
InfoProvider tiene su propio nivel de granularidad.
Ej: Una granularidad de da, implica que se generar un registro por
cada da y una de mes implica que habr un registro por cada mes.

Est directamente relacionado con la aditividad de las mtricas asociadas ya
que cuando se toma una granularidad mayor a la de origen de la mtrica, se
consolidarn varios registros sumando (o realizando otra operacin
dependiendo del caso) los valores para dicha mtrica.

Mayor granularidad mayor volumen de datos, menor performance.... vs...
Menor granularidad prdida de informacin

A la hora de realizar validaciones de datos, se busca una granularidad mayor;
si es posible a nivel documento. De ese modo es ms fcil comparar contra R/3
donde la mayora de los reportes son por documento.

Granularidad de Datos
Operational Data Store (ODS) ( )
El Operational Data Store ODS es utilizado como InfoProvider de consolidacin de
datos homogneos en alto nivel de detalle (nivel atmico, es decir a nivel
documento).
Como todo InfoProvider puede ser utilizado para abastecer querys de BW.
Se utilizan principalmente para guardar datos a nivel de detalle, homogeneizarlos y
subirlos con menor granularidad y consolidados a nivel InfoCubos.
La existencia de un ODS es OPCIONAL.
Su funcionamiento es similar al de una de Tabla de Base de Datos Contiene una
clave (compuesta por uno o ms InfoObjetos) y un paquete de datos que incluye el
resto de la informacin (datos maestros, ratios, caractersticas de tiempo, unidades,
etc.)


ODS Facturacin

Nro. Doc. (0DOC_NUMBER)
Pos. Doc. (0DOC_ITEM)
Material (0MATERIAL)
Da (0CALDAY)
Unid. Med. Base (0BASE_UOM)
Mon. Std. (0STAT_CURR)
Valor Net. Mon. Std. (0NET_VAL_S)
Cant. UMB (0QUANT_B)

Clave
Paquete de Datos
Sistemas
Fuentes
BW
Flujo BW
El sentido de la siguiente animacin es dar una idea del flujo de
informacin posible en BW.
Es posible que la informacin requeridad se encuentre con
diferentes grados de granularidad en varios InfoProviders.

InfoProviders Virtuales: InfoSet ( )
Teniendo en cuenta que un query puede alimentarse de un solo InfoProvider, existe la posibilidad
de crear InfoSets y/o MultiProviders dependiendo de la necesidad. Cada uno de ellos tienen
diferente comportamiento en relacin a la agrupacin de los datos de los InfoProviders que lo
conforman.

El InfoSet, es un agrupamiento de dos o ms ODSs y/o Datos Maestros; donde se realiza un join
(o left outer join) de los InfoProviders intervinientes. Naturalmente es requerida una condicin (el
mismo infoObjeto) en los InfoProviders intervinientes.

Por Ejemplo: Se tiene Un ODS de Facturacn y un ODS de Pedidos de Ventas Se
realiza un infoSet de ambos, obteniendo la facturas que surgen a partir de un pedido + los
pedidos que fueron facturados.
Otra opcin aplicando un la opcin Left Outer Join de los InfoSets sera hacer hacer un
outer de facturas con pedidos. En ese caso se obtendra las todas las facturas + todos
los pedidos que se facturaron.

InfoProviders Virtuales: MultiProviders ( )
As como los InfoSets realizaban intersecciones (joins) entre InfoProviders
(ODSs y Datos Maestros), en el caso de los MultiProviders se realiza la
sumatoria de dos o ms InfoProviders.
En el caso de los MultiProviders, tambin es posible incluir InfoCubos para
la unin.
En el ejemplo de a continuacin, se armar un MultiProvider con un cubo
de produccin, uno de stock y una ODS de Facturacin


23
Preguntas
?
?
?
?
?
El primer captulo de BW para Power Users ha finalizado. Los
siguientes captulos estn orientados directamente al
funcionamiento de las herramientas utilizadas en los Power Users
para la creacin de Querys (Query Designer) y la visualizacin de
los mismos (BEx Analyzer).