Consideraciones sobre el diseño de dimensiones

Diseñe dimensiones para crear la estructura de la aplicación

Agregue cuentas, entidades y otras dimensiones como soporte del proceso de negocio.

Las dimensiones categorizan los valores de datos. Planning incluye las siguientes dimensiones: Cuenta, Entidad, Escenario, Versión, Periodo y Años. Si planifica en varias monedas, la aplicación también tendrá una dimensión Moneda.

Puede utilizar una dimensión personalizada para definir sus propios valores, como Producto, Cliente o Mercado. Puede tener un total de hasta 32 dimensiones. Sin embargo, la práctica recomendada es incluir menos de 12. Puede agregar dimensiones mediante un archivo de carga, o bien puede crearlas en Oracle Smart View para Office.

Vídeos

Siga este proceso para identificar las dimensiones

Siga este proceso para identificar qué dimensión debe incluir en la aplicación.

1. Identifique procesos de planificación únicos según los requisitos.

   Ejemplo: planificación de marketing, planificación de ventas, planificación de gastos generales, planificación de capital, planificación de flujo de efectivo, planificación de mano de obra

2. Identifique las dimensiones para cada proceso de planificación.

   Ejemplo: Product, Market, Channel, Product Segment, Customer Segment

3. Defina cómo se relacionan entre sí las dimensiones.

   Ejemplo: Product tiene una relación varios a varios con Market. Product Segment y Product tienen una relación uno a varios. Labor Resources y Material Resources no tienen ninguna relación.

4. Separe las dimensiones en cubos para la planificación y creación de informes.

   Ejemplo: Product, Market y Channel son dimensiones de planificación, mientras que Product Segment y Customer Segment son dimensiones de informes.

5. Asigne procesos de planificación a Planning Modules.

   Ejemplo: configure la planificación de marketing con Projects o Financials, y configure la planificación de gastos generales y de flujo de efectivo con Financials y cubos personalizados.

Tenga en cuenta los casos de uso comunes para las dimensiones

Revise los siguientes casos de uso comunes para las dimensiones y tenga en cuenta las directrices para gestionarlos.

• Dimensiones estándar (obligatorias)

  La mayoría de los casos de uso de nivel superior y comunes de Financial Planning se pueden gestionar con dimensiones estándar, cuyos nombres también se pueden cambiar.

• Dimensiones personalizadas u opcionales

  Dimensionalidad ampliada con dimensiones personalizadas u opcionales que se pueden agregar (activar) o cambiar de nombre según sus necesidades.

• Varias jerarquías en una dimensión

  Combine una o varias dimensiones que no estén relacionadas en una única dimensión para evitar la irrelevancia interdimensional.

• Jerarquías alternativas para planificación o creación de informes

  Utilice jerarquías alternativas cuando los mismos miembros se puedan agrupar en diferentes padres con fines de asignación descendente o de informes.

• Dimensiones de atributo para creación de informes

  Las dimensiones de atributo son útiles para satisfacer los requisitos de informes si están relacionadas con una dimensión y la relación entre las dos dimensiones no cambia con el tiempo.

• Listas inteligentes y dimensiones ASO para la creación de informes

  El uso de listas inteligentes y dimensiones ASO para crear informes resulta útil si la relación entre la dimensión de informe y otras dimensiones cambia con el tiempo.

• Listas inteligentes y dimensiones BSO de varios cubos para la planificación

  Esta estrategia resulta útil si la dimensión de planificación no es una dimensión principal de un proceso de planificación y es necesario dividirlo en subprocesos.

En esta hoja de trabajo de ejemplo se muestra un ejemplo de cómo planificar dimensiones, junto con la identificación de las dimensiones y la lista de casos de uso.

Revise las estrategias de diseño de ejemplo

Revise estos ejemplos para descubrir más estrategias de diseño de dimensiones.

Uso de dimensiones de atributo para la creación de informes

El uso de dimensiones de atributo para crear informes puede resultar útil para satisfacer los requisitos de informes. El atributo está relacionado con una dimensión, y la relación entre las dos dimensiones no cambia con el tiempo.

Ejemplo:

• Defina un atributo denominado Program en la dimensión Project.
• Puede crear una jerarquía de miembros en la dimensión Program. Los miembros de nivel superior de la dimensión Program se agregarán automáticamente.
• Asocie cada miembro de Project a un miembro de nivel de hoja en la dimensión Program en una regla de Groovy Agregar proyecto.
• Esto le permite filtrar proyectos por programa.
• Los formularios de informes pueden mostrar el nivel de programa de gastos e ingresos.

Uso de listas inteligentes y dimensiones ASO para la creación de informes

Esta estrategia resulta útil si la relación entre la dimensión de informe y otras dimensiones cambia con el tiempo.

Ejemplo:

• Agregue una dimensión Skillset en ASO y asigne la lista inteligente de conjunto de habilidades a la dimensión Skillset.
• Cree una asignación de datos para mover datos de un cubo BSO a un cubo ASO.
• La asignación de datos se puede ejecutar como proceso por lotes, o bien puede implementar el envío inteligente en formularios o reglas de Groovy.
• Puede utilizar formularios de informes en el cubo ASO para mostrar el requisito de mano de obra por conjunto de habilidades en los distintos proyectos.

Uso de listas inteligentes y diseño de BSO de varios cubos

Esta estrategia resulta útil si la dimensión de planificación no es una dimensión principal de un proceso de planificación y es necesario dividirlo en subprocesos.

Ejemplo:

• Employee y Job son dimensiones de mano de obra y listas inteligentes de Project Planning.
• Project Planning utiliza apuntes para planificar los gastos de mano de obra en el nivel de Job y Employee.

Varias jerarquías en una dimensión

Puede utilizar varias jerarquías en una dimensión. Combine una o varias dimensiones que no estén relacionadas en una única dimensión para evitar la irrelevancia interdimensional.

Ejemplo:

• Jobs, Equipment y Material no están relacionadas en Projects, por lo que se combinan en una única dimensión Resource Class.
• Profit Centers y Cost Centers no están relacionadas en Financials, por lo que se pueden combinar en una única dimensión Entity.

Jerarquías alternativas para planificación y creación de informes

Utilice jerarquías alternativas cuando los mismos miembros se puedan agrupar en diferentes padres con fines de asignación descendente o de informes.

Ejemplo: cree acumulaciones alternativas en la dimensión Product para la planificación y creación de informes por las categorías de marca y producto.

Conozca las diez mejores prácticas principales para las dimensiones

Siga estas mejores prácticas importantes a la hora de diseñar dimensiones.

1. El orden de las dimensiones debe seguir un formato de reloj de arena modificado.

   Con este formato, las dimensiones más densas están en primer lugar, seguidas de dimensiones menos densas. A continuación, deben aparecer las dimensiones ligeras, colocando las dimensiones ligeras de agregación antes que las de no agregación. De las dimensiones ligeras, debe colocar las dimensiones ligeras más densas antes que las que son menos densas.

   Con BSO híbrido, el orden es el mismo, con la excepción de que debe colocar las dimensiones ligeras no dinámicas antes que las que son dinámicas.

   Obtenga más información sobre las dimensiones densas y ligeras en este tutorial: Gestión de dimensiones en Cloud EPM.

2. Un tamaño de bloque grande tiene un impacto mayor en el rendimiento.

   El tamaño de bloque viene determinado por el número de dimensiones densas y los miembros incluidos en esas dimensiones. Un tamaño de bloque óptimo está entre 8 KB y 500 KB. Reduzca el número de dimensiones densas a un máximo de 3. El nivel 1 y los niveles superiores deben ser de solo etiqueta o cálculo dinámico para las dimensiones densas.

3. Las cuentas de tipo texto, lista inteligente, fecha y porcentaje almacenado se deben establecer en Nunca para la propiedad de consolidación.

   Al agregar estos valores, a menos que las cuentas se excluyan explícitamente en un script de agregación, se crearán datos inservibles.

4. Todos los miembros de generación dos se deben establecer en Ignorar.

   No puede incluir estos miembros raíz en sus formularios porque no puede definir la seguridad para dichos miembros. Por tanto, no tiene sentido agregar los miembros de generación dos a la raíz. Esto también aumentará el número de bloqueos en la aplicación.

5. Las dimensiones largas o planas causarán un problema con el rendimiento de la agregación.

   Si hay más de 200 miembros bajo un miembro padre, agregue padres intermedios.

6. La activación de miembros de dimensión para varios cubos creará referencias cruzadas dinámicas y causará problemas de rendimiento.

   Utilice el atributo definido por el usuario HSP_NOLINK para evitar la creación de referencias cruzadas dinámicas. Utilice asignaciones de datos o el envío inteligente para mover datos de un cubo a otro.

7. Para los cálculos simples, utilice las matemáticas del esquema en lugar de escribir las fórmulas de miembro.

   Un ejemplo de cálculo simple es Cuenta C = Cuenta A – Cuenta B.

8. En la medida de lo posible, evite el uso de miembros padre con un solo hijo.

   Los miembros padre con un solo hijo implican comparticiones implícitas o la duplicación de bloques y datos en el disco si el miembro padre es de tipo Nunca compartir.

9. Si es posible, agregue las dimensiones de gran tamaño en ASO en lugar de BSO.

   Esto mejora el rendimiento, por ejemplo, durante el refrescamiento del cubo y el tiempo de mantenimiento.

10. Almacene los datos históricos de más de dos años en ASO en lugar de BSO.

    Si tiene 5 o 10 años de datos históricos, no todos los datos hacen falta para los cálculos. Si es necesario, puede utilizar un par de años de datos históricos para los cálculos en el cubo BSO y puede mover otros datos históricos al cubo ASO. Para un rendimiento óptimo, como mejor práctica puede mantener ligero el cubo BSO y asegurarse de que se centra en los cálculos de la entrada de datos.

Planifique la dimensión Entity

La dimensión Entidad representa la estructura organizativa, como centros de costes, departamentos, unidades de negocio, divisiones, etc.

Puede agrupar los centros de costes creando miembros de acumulación, denominados padres, para reflejar cómo se visualiza la organización. Por ejemplo, las acumulaciones se pueden realizar por unidad de negocio, división u otra estructura funcional. Por ejemplo, podría crear centros de costes que se acumularan en unidades de negocio que, a su vez, se acumularan en divisiones.

También puede crear varias estructuras de generación de informes. Por ejemplo, podría crear una estructura alternativa como soporte de los informes regionales. Si planifica en varias monedas, establezca la moneda base de cada entidad.

La dimensión Entidad es una de las principales dimensiones utilizadas en el proceso de elaboración de presupuestos. Junto con las dimensiones Scenario y Version, la dimensión Entity se utiliza para definir una unidad de aprobación, un componente discreto que se puede promocionar o descender para su aprobación o revisión por colegas del usuario.

Los miembros de todas las dimensiones fuera de la unidad de aprobación se promocionan y descienden junto con la propia unidad de aprobación. Por ejemplo, los doce meses se promocionan juntos cuando se promociona una unidad de aprobación. Los meses individuales no se pueden promocionar de forma independiente.

Después de cargar o actualizar cada dimensión, la práctica recomendada es refrescar la aplicación.

Planifique la dimensión Account

La dimensión Cuenta es el sitio del plan de cuentas. Debe incluir los miembros para los que realiza el plan o la previsión. No incluye necesariamente todas las cuentas del plan.

Por ejemplo, la dimensión Cuenta podría incluir cuentas para cuenta de resultados, balance general y flujo de efectivo. O bien, podría incluir cuentas para KPI y relaciones. En algunos casos, las cuentas pueden tener subcuentas, aunque esto no es lo normal.

La dimensión Cuenta incluye inteligencia financiera. Están soportados los tipos de cuenta siguientes:

• Gastos: coste de los negocios

• Ingresos: fuente de ingresos

• Activo: recursos de la compañía

• Pasivo y patrimonio: interés residual u obligación con los acreedores

• Suposición guardada: suposiciones de planificación centralizadas que garantizan la coherencia en la aplicación

La configuración del tipo de cuenta se utiliza para notificar los valores trimestrales y anuales totales y para el análisis de varianza.

Planning utiliza una estructura jerárquica para crear subtotales y totales de agrupación de cuentas. A cada grupo de cuentas se le asigna un operador de consolidación que determina cómo se acumula en su padre.

Ejemplo:

Ingresos netos = Ingresos totales - Gastos totales

En este ejemplo, el operador de consolidación para los ingresos totales es la suma y el operador de consolidación para los gastos totales es la resta.

La dimensión Cuenta se puede rellenar cargando datos o mediante Smart View. Para cargar datos de un archivo, el formato de archivo debe cumplir requisitos específicos.

Después de cargar o actualizar cada dimensión, la práctica recomendada es refrescar la aplicación.

Prácticas recomendadas:

• Los miembros de nivel superior se deben definir en cálculo dinámico.

• Para las fórmulas de miembros utilizadas para calcular relaciones y otros tipos de KPI o porcentajes, establézcalas como cálculo dinámico en dos pasadas. El ajuste de dos pasadas calcula correctamente porcentajes en niveles superiores.

Planifique la dimensión Version

Puede utilizar versiones para conservar diferentes iteraciones del proceso de planificación. Las versiones también son útiles para controlar el acceso de lectura o escritura a los datos.

Están disponibles estos dos tipos de versiones:

• Descendente estándar: los datos de entrada se pueden introducir en niveles superiores.

• Ascendente estándar: los datos de entrada solo se pueden introducir en el nivel 0.

La funcionalidad de aprobaciones y flujo de trabajo solo se puede activar para versiones ascendentes.

Como práctica recomendada, se recomiendan las versiones siguientes:

• Activo: donde los usuarios realizan sus tareas, lo que incluye el examen de resultados reales y el desarrollo del plan y la previsión.

• Primera pasada: si desea contar con varias iteraciones del plan, puede conservar una pasada del mismo en esta versión. Puede crear otros miembros si necesita más de una iteración guardada. También puede usar la funcionalidad de copia de datos para mover datos a esta versión. La copia de datos copia datos y la entrada de texto.

• Simulación: proporciona un marcador de posición donde los usuarios pueden cambiar las suposiciones y analizar los resultados.

Después de cargar o actualizar cada dimensión en el proceso de creación, la práctica recomendada es refrescar la aplicación.

Planifique la dimensión Currency

Si ha activado varias monedas para la aplicación, puede agregar las monedas que utilizará para el plan y los informes.

A continuación, puede definir tipos de cambio por escenario y año para utilizarlos en las conversiones. Se crea un script de cálculo que permita realizar conversiones de moneda. Para introducir tipos de cambio, siga el proceso en Especificación de tipos de cambio en Administración de Planning.

Prácticas recomendadas:

• Limite el número de monedas de informes. Normalmente, los clientes solo tienen una.

• Introduzca los tipos de cambio para cada combinación válida de escenario y año.

• A partir de este momento, la conversión de moneda se puede calcular mediante la ejecución de la regla de negocio Calcular monedas que está asociada de forma predeterminada a cada formulario.

• Se modifica la clase de tipo de cambio de la cuenta, como desde Final hasta Promedio.

Ejecute el script de cálculo de conversión de moneda antes de:

• Revisar los datos locales actualizados en las monedas de informes

• Ejecutar determinados cálculos que pueden depender de los datos de la moneda de informes

Planifique los tipos de cambio

Cada aplicación tiene una moneda predeterminada que se especifica al crear la aplicación. Al configurar las tablas de tipos de cambio, introduzca los tipos de cambio de todas las monedas de origen a la predeterminada. Se utiliza la triangulación para convertir a todas las demás monedas de informes.

Los tipos de cambio se establecen por escenario y año para Tasas promedio y Tasas de finalización.

Planifique la dimensión Period

Utilice la dimensión Periodo para establecer el rango del calendario en un determinado año, por ejemplo, por mes.

Prácticas recomendadas:

• Utilice variables de sustitución para esta dimensión como soporte de informes y cálculos. Las posibles variables de sustitución son: CurrMo, CurrQtr y PriorMo. Estas variables se deben actualizar mensualmente.

• Para utilizar cálculos de periodo de tiempo como Acumulado anual y Acumulado trimestral, seleccione el icono de serie de tiempo dinámica en la dimensión Periodo. A continuación, podrá seleccionar los cálculos de periodo de tiempo que necesite como soporte del proceso.

• Los periodos de tiempo de resumen, como los totales trimestrales y el total anual, se deben establecer como cálculos dinámicos para reducir el tiempo de cálculo.

• Después de cargar o actualizar cada dimensión, refresque la aplicación.

Planifique los años y las variables de sustitución

Los años están incorporados en varios lugares de la aplicación, como formularios, cálculos, informes y Smart View. Puesto que utilizará la aplicación durante muchos años en el futuro, la práctica recomendada para hacer referencia a esta dimensión es utilizar una variable de sustitución.

Las variables de sustitución funcionan como marcadores de posición globales para información que cambia con regularidad. La variable y el valor corresponden al año, y el valor se puede cambiar en cualquier momento.

El valor de la variable de sustitución se muestra en formularios e informes como un marcador de posición. Esto reduce el mantenimiento de la aplicación.

Como práctica recomendada, cree variables de sustitución para cada año incluido en el proceso. Por ejemplo:

• CurrY, Año actual

• NextYr, Año de presupuesto (plan)

• PriorYr, Año anterior

Diseñe dimensiones personalizadas

Puede utilizar una dimensión personalizada para clasificar aún más los datos. Por ejemplo, las dimensiones personalizadas pueden incluir Producto o Mercados.

Tenga en cuenta que no se pueden otorgar permisos de acceso en el nivel de dimensión, también denominado generación uno. Por ejemplo, no se pueden asignar directamente permisos de acceso al miembro Producto para todos los descendientes. Si activa la seguridad para la dimensión personalizada, se recomienda que diseñe la generación dos para todas las dimensiones personalizadas a las que se aplicará seguridad, considerando las asignaciones de acceso de seguridad.

Después de cargar o actualizar cada dimensión, la práctica recomendada es refrescar la aplicación.

Mejores prácticas adicionales

Complete estas tareas después de agregar o actualizar dimensiones.

• Refresque la aplicación.

  Debe refrescar la aplicación siempre que cambie la estructura de la aplicación.

  Los cambios realizados en la aplicación no se reflejan para los usuarios que realizan la entrada de datos y tareas de aprobaciones hasta que se refresca la aplicación.

  Por ejemplo, si modifica las propiedades de un miembro de Entidad, agrega un escenario o cambia los permisos de acceso, estos cambios se reflejan en los usuarios después de que refresque la aplicación.

• Cargue los datos históricos.

  Después de cargar todas las estructuras, como cuentas y entidades, puede cargar datos históricos. Esto puede incluir datos de resultados reales del año anterior y el plan y el presupuesto del año actual.

  La carga de datos históricos ofrece a los usuarios una forma de analizar resultados, revisar tendencias y realizar comparaciones significativas.

  Esto también ayuda a verificar las estructuras que ha creado en la aplicación. Por ejemplo, puede verificar que los datos se enlazan a informes creados previamente. Si los datos no se concilian, debe verificar si esto se debe a un problema de datos o si hay un problema con las estructuras.

  Cree una regla de agregación para ver los datos consolidados en la aplicación.

• Planifique las intersecciones válidas.

  Las intersecciones válidas permiten a los administradores del servicio definir reglas, denominadas reglas de intersección válida, que filtran las intersecciones dimensionales para los usuarios cuando introducen datos o seleccionan peticiones de datos en tiempo de ejecución. Por ejemplo, puede especificar que determinados programas sean válidos solo para departamentos específicos. Utilice las intersecciones válidas para controlar que las entradas de datos solo se realicen en intersecciones válidas.

  A la hora de diseñar formularios, tenga en cuenta lo siguiente para las intersecciones válidas.

  • Si las dimensiones con intersecciones válidas están en la página, al usuario solo se le mostrarán combinaciones válidas en el selector de miembros.
  • Si las dimensiones con intersecciones válidas están en la columna o fila, el diseñador del formulario puede suprimir por completo las intersecciones no válidas. Si no se selecciona la opción de supresión, las intersecciones no válidas se establecen en modo de solo lectura.