Gestión Integrada del Rendimiento - Parte 2 - Componentes

En nuestro último post hemos revisado los motivos por los que las aplicaciones de gestión del rendimiento sufren de una falta de integración. Para definir correctamente lo que es una aplicación integrada, primero tenemos que analizar lo que los componentes que debe contener.

Puede descargar el documento completo que explica detalladamente la Gestión Integrada del Rendimiento.

Componentes de una Aplicación Integrada de Gestión del Rendimiento

En nuestra experiencia, las aplicaciones de gestión del rendimiento únicamente pueden ser evaluadas por los componentes que contienen y cómo estos funcionan en conjunto para dar soporte a los objetivos. Sin importar lo que la aplicación dará soporte –presupuesto, forecasting, presentación de informes de gestión- todo estará conformado (o debería estar conformado) por los siguientes 11 componentes integrados. A continuación presentamos los primeros 5.

1. Base de Datos Multiusuario

En el centro de cada aplicación se encuentra la base de datos, que generalmente se utiliza para gestionar tanto los detalles de configuración (por ejemplo, estructuras de negocios, medidas, cómo serán calculados los resultados) como los propios datos. Los datos deben ser accesibles para varias personas y permitir que la información sea fácilmente trasformada y reportada. 

Para dar cabida a esto, existen tres tipos de base de datos que se pueden utilizar: 

• Relacionales – los datos serán almacenados en tablas de información, similares a lo que se esperaría ver en una base de datos de Access. 
• Multidimensionales – los datos serán almacenados en formatos que facilitan el análisis. La apariencia es similar al concepto de tablas dinámicas en Excel (aunque en Excel los datos puede ser almacenados tanto en formato relacional como multidimensional). 
• No Estructurado – en este caso los datos no encajan en ninguna de las categorías anteriores o incluyen datos no textuales, tales como imágenes o videos. Esta categoría se vuelve cada vez más popular cuando se trata de analizar tendencias en redes sociales, tales como twitter y facebook. 

Las aplicaciones pueden utilizar uno o varios de los formatos anteriores. En nuestro documento sobre sistemas de ejecución de la estrategia, explicábamos un caso donde se daba cabida a todos ellos. La forma en que el proveedor de software logra utilizar todos estos formatos dependerá de la manera en que esté diseñado su producto.

2. Seguridad

La seguridad dentro de una base de datos multiusuario puede estar dividida en las siguientes áreas: 

• Acceso a los Datos. Esto determina los datos que pueden ser vistos o modificados y quienes podrán hacerlo. Por lo general, los datos que no formen parte de las responsabilidades de una persona serán ocultados, mientras que los informes generales podrán estar accesibles a todos, pero sin el detalle subyacente. 
• Roles. El rol de una persona debería determinar lo qué esta puede hacer. Por ejemplo, a un administrador se le permite realizar cambios a la aplicación (o a partes de ella), mientras que a un gerente se le permite introducir y aprobar los datos del presupuesto y del forecast, así como analizar (pero no cambiar) los resultados. Estos roles pueden cambiar en función del proceso al que se le da soporte. 
• Dependencia Proceso / Tiempo. Esta área reconoce que los datos y perfiles de seguridad de los roles es dependiente del tiempo. Por ejemplo, un responsable del presupuesto podrá solicitar aprobación del mismo, pero una vez que ha culminado esta actividad, la aplicación se bloquea para evitar cambios, salvo previa autorización para ello. Del mismo modo, los resultados de final de año pueden ser “invisibles” para todos excepto para las personas clave del equipo financiero, hasta que se anuncie el punto en el que se restablece el acceso “normal”. 

Algunos sistemas van más allá e incluyen rutas de escalamiento, es decir, las personas que tomarán la responsabilidad del rol cuando el encargado original no cumple con los requerimientos. Por ejemplo, si el responsable del presupuesto no ejecuta su tarea de presentación del presupuesto a tiempo, entonces su jefe podrá ser automáticamente informado y heredar las responsabilidades que pertenecían inicialmente al encargado del presupuesto.

3. Constructor del Modelo

Todas las aplicaciones tendrán estructuras de negocios que permiten que la organización sea modelada. Algunas de estas estructuras estarán basadas en jerarquías, por ejemplo Departamento, Producto, Canal y así sucesivamente, mientras que otras tendrán estructuras “planas” o sin jerarquía, como Versión. Estas estructuras determinan los datos que pueden ser gestionados y cómo serán consolidados. Con frecuencia estas estructuras ya existirán en otros sistemas, como los ERP, por lo que tener una manera de importarlos es útil para reducir los potenciales errores de “copiado”. También permite que sea fácil mantener las estructuras actuales al día y sincronizadas con todos los sistemas operativos. 

Estas estructuras cambiarán con el paso del tiempo o cuando sea necesario evaluar las estrategias alternativas de negocio. El sistema tendrá que hacer frente a esta situación, mediante una interfaz gráfica sencilla que permita que los administradores reorganicen el modelo, pero manteniendo las estructuras históricas con fines analíticos. Por este motivo, los datos no deben estar unidos a la estructura y deben permitir que, tanto los datos del forecast como los históricos, sean visualizados o reportados por múltiples versiones de la estructura.

4. Reglas de Negocio

Además de tener rutas de consolidación tal como se define en el constructor del modelo, también será necesario especificar "reglas" más complejas que determinen cómo se procesan los datos. A diferencia de una hoja de cálculo, estas reglas deben: 

• Tener un nombre que las identifique. Es decir, no utilizan referencias de celdas, sino que utilizan el nombre de negocio asignado. Por ejemplo: Ingresos = Volumen x Precio. 
• Contener funciones para calcular ratios, porcentajes y sumas. 
• Ser capaces de acceder a los datos en cualquier dimensión de negocios. La mayoría de las reglas que afectan a las métricas se aplican generalmente a todas las dimensiones. En el ejemplo anterior para calcular los ingresos, la regla será aplicada a todos los departamentos, productos, versiones – o en cualquiera de las dimensiones existentes. Sin embargo, algunos cálculos, como los que distribuyen los costes del departamento financiero a todos los demás departamentos, tendrán la posibilidad de colocar los valores específicos en las diferentes dimensiones del modelo. 
• Controlar cómo funcionan las formulas de cálculo en cada uno de los niveles de la estructura. Una vez más, en el ejemplo anterior, las fórmulas se utilizan desde el nivel más bajo de la estructura (también conocida como “nodos”) y el resultado será acumulado a través de la estructura de la organización o de producto. Sin embargo, la regla de cálculo del precio medio (=ingresos/volumen) se utiliza en todos los niveles dentro de la estructura, es decir, no se puede sumar los precios medios individuales, ya que esto originaría una respuesta incorrecta. 

Algunos sistemas se basan en que el administrador utiliza las reglas proporcionadas por la base de datos que se usa, por ejemplo MDX. Estos “lenguajes” pueden ser difíciles de aprender y pueden dar lugar a errores ocasionados por equivocaciones en la sintaxis. 

5. Captura de Datos

Este componente se utilizan para importar (o exportar) datos que existen en el sistema operativo. Con frecuencia, se le denomina ETL (acrónimo del inglés Extract, Transform and Load), y debe tener las siguientes características: 

• Elección del formato de los datos de origen. Los datos se encuentran en sistemas y formatos diferentes, por lo que lo ideal es que el componente sea capaz de leer directamente estas fuentes de datos. Sin embargo, esto no siempre es práctico por lo que, como mínimo, el sistema debe ser capaz de "leer" un archivo CSV (archivos separados por comas) que la mayoría de los sistemas son capaces de producir. 
• Transformar. Esto está relacionado a la capacidad de escoger la ubicación de los datos dentro de la fuente de datos. Por ejemplo, si el tiempo y otros miembros de la dimensión se almacenan como registros o columnas. 
• Resumir. Con frecuencia los datos almacenados en un sistema transaccional se encuentran a un nivel con mucho más de detalle del que necesita la aplicación de planificación. En este caso los datos se pueden agrupar por componente de captura de datos y, a continuación, sólo carga los totales. 
• Coincidir. Cuando los datos son capturados desde múltiples sistemas, generalmente los códigos que se utilizan para almacenar los datos internamente son diferentes. Esto es particularmente cierto cuando se trata de la recolección de datos de múltiples libros de contabilidad que mantienen diferentes planes de cuentas. Para poder importar los datos correctamente es necesario que exista un mapa del código interno desde el sistema origen hasta los miembros de la dimensión correspondiente. Con frecuencia se necesitarán varias series de "mapas" para cargar los datos, ya que cada sistema de origen puede utilizar diferentes códigos. 
• Carga. Una vez que el punto anterior se ha establecido, los datos pueden ser cargados. El sistema debe informar cuando los datos no coinciden o si el formato es diferente al esperado. En estos casos se debe presentar la opción de rechazar la carga completa o cargar aquellos datos que se pueden leer. Además, también debe presentar opciones para la carga de datos, que incluyen reemplazar los datos que pueden estar presentes en el sistema de planificación o acumularlos.

Además de la carga electrónica de datos, cualquier aplicación de gestión del rendimiento requiere dos funcionalidades adicionales: 

• Entrada Manual de Datos. Los usuarios tendrán acceso a pantallas de captura de datos, donde podrán introducir los mismos. Esta funcionalidad debería dar soporte tanto a periodos individuales como múltiples, como por ejemplo introducir datos de 12 meses cuando se crea el presupuesto o los próximos 6 meses cuando se trata del forecast. Algunos sistemas también ofrecen 'atajos' para la introducción de datos, tales como las fases y la distribución de una cantidad total entre las filas/columnas seleccionadas. 
• Registros de Auditoría. Cuando los datos son importados, ya sea electrónica o manualmente, debe existir un completo registro de auditoría que mantenga el detalle de lo que se ha cargado junto con el archivo de origen, los mapas utilizados, información del usuario que realizo la carga, la fecha y la hora. Esta funcionalidad garantiza que cada uno de los números importados al sistema puedan ser rastreados hasta su origen y autor. 

En nuestro próximo post analizaremos los otros 6 componentes de un sistema integrado de gestión del rendimiento.

Puede descargar Documento Integreted performance Management Aplicatios que explica detalladamente la Gestión Integrada del Rendimiento.