Gestión Integrada del Rendimiento – Parte 6 Evaluando las soluciones potenciales


En esta serie de posts estamos analizando cómo funciona una aplicación integrada de gestión del rendimiento. En este post, revisaremos lo que hace que una solución sea "integral".


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

Evaluando soluciones potenciales

Definir el alcance de la evaluación

La mayoría de las demostraciones de software de los proveedores son similares a un concurso de belleza. Están presentadas por un “actor” que desarrolla varios escenarios con un guión cuidadosamente definido para mostrar el producto de la mejor manera posible. Como consecuencia de ello, es fácil imaginarse que el producto es “fácil de usar” y que está completamente integrado. Pero, ¿puede estar seguro de ello? Bajo esta cosmética se puede encontrar otra historia. Para que una evaluación proporcione valor y se encamine a una correcta selección, debe llevarse a cabo de forma lógica y con objetivos y criterios claros. 

Las soluciones en muy pocas ocasiones son solicitadas por una sola persona – tendrán un impacto en otras, así que es necesario que se asegure de que la solución satisface todas las necesidades y no afecta negativamente a otros. 

Antes de seleccionar cualquier proveedor o revisar cualquier producto, los siguientes elementos deben ser acordados: 
  • ¿Cuál es el problema(s) que estamos tratando de resolver? 
  • ¿Cuál es la causa(s) de estos problemas? 
  • ¿Qué deberíamos obtener de la primera versión? 
  • ¿Qué es esencial para el futuro? 

Una vez que se hayan entendido completamente los requisitos y recursos de la organización, será el momento de investigar a los vendedores.

Buscar proveedores adecuados 

Existen muchos proveedores ofreciendo soluciones de gestión del rendimiento. Una búsqueda rápida en internet le revelará aquellos que están dispuestos a gastar en los anuncios del motor de búsqueda, mientras que las páginas inferiores cubrirán el resto. 

Al examinar las páginas individuales podrá determinar el nivel de experiencia que tiene cada vendedor y su punto de vista sobre como la organización debería gestionar el rendimiento. Después de todo, quiere una solución y no únicamente un software. También descubrirá qué productos ofrecen. La mayoría de los grandes fabricantes tienen múltiples productos que han sido comprados a través de adquisiciones. En ocasiones está colección se ofrecen como un paquete, pero tenga cuidado, ya que esto podría significar mantener varias configuraciones que podrían sufrir problemas de integración y ser más costosas que una sola solución. Esto también podría significar que uno de los productos que ofrecen está previsto que sea sustituido por otro. 

Solicite la hoja de ruta del producto. Investigue la visión del proveedor para el producto que le propone y su vida útil prevista. Pídale que le indique el perfil de cliente que tienen y cómo se desarrolla el producto. Esta información puede ser útil cuando se trata de evaluar si el producto se ajusta a sus necesidades actuales y futuras.

Realice una evaluación detallada 

Tenga cuidado con las demostraciones “enlatadas”. Los vendedores generalmente muestran únicamente lo que ellos quieren que Ud. vea. Un mejor método será informarle al vendedor acerca de sus requerimientos básicos y solicitarle una demostración que le presente como respondería el producto a esas necesidades específicas. Un buen proveedor respetará su tiempo, llegará directamente al punto y les permitirá ahorrar tiempo a ambos. 

Algunos soluciones de proveedores pueden implicar múltiples productos que están ocultos en una ingeniosa interfaz web. Para revelar si este es el caso, en una sesión práctica realice los siguientes controles de una aplicación completa y real:

Mantenimiento 

  • Solicite que le demuestren como el administrador configura las pantallas de introducción de datos. 
  • Añadir una nueva métrica y demostrar los elementos que están involucrados dentro de una pantalla de introducción de datos existentes y en los informes. Compruébelo mediante la introducción de números y observe cómo funciona en todo el recorrido hasta los informes. 
  • Introduzca un número durante el proceso de forecast y posteriormente verifique que el mismo número pueda ser comparado con el real y los presupuestos en un informe ya existente. Si no observa el número, es posible que el sistema que está evaluando tenga varias bases de datos y no sea la solución única que Ud. necesita. 
  • Introduzca una nueva unidad y ejecute una reorganización. Verifique que los cambios se muestran en el sistema de introducción de datos, los informes y análisis. Si no es posible, entonces la aplicación o bien no está integrada o es demasiado complicada para que el vendedor lo muestre. 
  • Añada un nuevo usuario (por ejemplo, un responsable del presupuesto) y un nuevo departamento. Compruebe los aspectos relacionados para conseguir que sean capaces de acceder al sistema para introducir un presupuesto, aprobarlo y que aparezcan en el resultado consolidado. 
  • Asegúrese que el sistema permita que los usuarios creen un presupuesto, realicen el seguimiento de los datos reales y recojan los datos del forecast. Si necesita forecast dinámico, compruebe cómo el sistema se adapta a esto. 

Evalúe la flexibilidad: 

  • Compruebe que las métricas e indicadores, que se están recogiendo, sean realistas: Algunas cuentas se recogen con mayor nivel de detalle por una dimensión de negocios diferente, como productos y clientes. 
  • Compruebe como se desarrollan las reglas de negocio, las cuales pueden cambiar según la versión. Por ejemplo, la regla “Ingresos=Volumen * Precio” se configura para las versiones de presupuesto y forecast y la de “Precio=Ingreso/Volumen” para la versión real. 
  • Compruebe cómo las métricas se convierten desde una moneda local a la moneda base. ¿Qué sucede con las ganancias/pérdidas de tipo de cambio? 
  • Compruebe que los indicadores puedan ser utilizados en estructuras de causa y efecto, tal como se usan en Balanced Scorecard. 
  • Verifique que las métricas e indicadores pueden ser agrupados por tipo de recursos, carga de trabajo y resultados, y que posteriormente puedan ser asignadas a departamentos específicos. 
  • Observe como los objetivos a alto nivel están relacionados con los procesos de negocios y sus actividades. 

Gestión de Fechas: 

  • Observe cómo se introducen los datos en diferentes niveles – por ejemplo, por día, semana, mes, etc. 
  • Observe cómo los datos pueden ser agregados, por ejemplo, en estaciones, trimestres, semestres, etc. Durante la presentación, cree una nueva agrupación de tiempo y observe cómo esta puede ser utilizada en los informes de resultados. ¿La nueva agrupación mantiene la relación con las cuentas de Balance y la manera en que los ratios son calculados? 
  • Observe cómo los datos a un nivel más detallado (por ejemplo, ventas por producto/cliente) se relacionan con los datos agrupados (por ejemplo, las cuentas de ingresos totales). Modifique los valores de algunos de estos detalles y solicite que le muestren el efecto en los totales de P&L. 
  • ¿Existe un registro de auditoría sobre cómo los resultados han sido generados? Es decir, Cuándo se han modificado los datos subyacentes y quién lo ha llevado a cabo. 
  • Observe que los cambios en las estructuras tienen una fecha relacionada. ¿Es posible re-consolidar los datos anteriores utilizando las estructuras nuevas pero manteniendo los resultados antiguos en su estructura original? 

Flexibilidad de Planificación: 

  • Presupuesto basados en Drivers o Accionadores: Observe cómo los presupuestos pueden ser generados mediante la introducción de valores en algunos drivers. Posteriormente, compruebe que el sistema pueda calcular estos valores a partir de los resultados reales. 
  • Planificación de Iniciativas: Solicite que le muestren cómo el presupuesto puede ser separado en “Business as Usual” (el negocio actual) y en “Iniciativas” o proyectos. Compruebe cómo se proponen y seleccionan las iniciativas. 
  • Planificación de Escenarios: Solicite que le muestren cómo las diferentes combinaciones de iniciativas, o de resultados de la utilización de diferentes drivers, pueden ser comparadas como escenarios paralelos. 
  • Genere una nueva versión del presupuesto. Observe el trabajo que necesita para mantener las versiones anteriores y generar una nueva. Asegúrese de que este control de versiones se extienda a los usuarios. 

Workflow: 

  • Investigue las capacidades que serán proporcionadas por el workflow. ¿Permite que las partes individuales del proceso de planificación sean desencadenadas por eventos y excepciones, así como por fechas? 
  • Compruebe las facilidades proporcionadas para el seguimiento y aprobación del presupuesto y el forecast. 

Presentación de Informes: 

Cabe resaltar que algunas aplicaciones no poseen funcionalidades de presentación de informes y en su lugar ofrecerán productos de terceros o una conexión a la base de datos vía Excel. Si este es el caso, cualquier evaluación debería comprobar que los informes puedan generarse a través de estos métodos y el esfuerzo de mantenimiento necesario, ya que los sistemas cambian. Los elementos a considerar en una evaluación son los siguientes: 
  • Cómo de “inteligente” es la selección del informe. Por ejemplo, ¿es capaz el sistema de traer las medidas asignadas a cada departamento sin tener que seleccionarlas de forma individual? 
  • Cómo de flexible es el diseño del informe. Por ejemplo, ¿es posible controlar completamente las filas y columnas? 
  • ¿Qué estilos de gráficos son compatibles? 
  • ¿Es posible ordenar los datos en la matriz? 
  • ¿Cómo son las excepciones en la manipulación de los datos? 
  • ¿Es posible acceder a los datos de forma segura dentro de una hoja de cálculo? 


Definir el Coste de Propiedad 

El coste de propiedad es el coste que tiene la solución para la compañía, incluyendo la compra inicial, los costes de implementación, puesta en ejecución y cualquier otro gasto de hardware/software que sea necesario para que el sistema funcione. Por supuesto, este coste debe ser inferior a los beneficios a imputar. 

Se debe tener en cuenta: 
  • Precio inicial de adquisición del software. Con frecuencia se establece por el número de procesadores utilizados por el servidor de aplicaciones. Investigue que sucede si el servidor se actualiza ya que podría incurrir en cargos adicionales si esto sucede. También suele depender del número de usuarios y del rol que poseen. Los vendedores de software quieren que Ud. compre más de lo necesario “en caso de que los necesite posteriormente”. Investigue cuál es el coste de actualización del número de usuarios en otro momento. Esto podría ser más costoso que el precio que tendría que pagar inicialmente. 
  • Precio de mantenimiento anual del software. Esto generalmente se establece como un porcentaje del precio y que, por supuesto, puede cambiar sin previo aviso. Al igual que con la compra inicial de software, a menudo será dependiente de la configuración del servidor. 
  • Requerimientos de Software Adicionales. Por ejemplo, algunas soluciones se basan en que el cliente proporcione la tecnología de base de datos subyacente. La aplicación seleccionada podría utilizar algunas de los “bases” cubiertas por la compra de la tecnología subyacente, y entonces pueden incurrir en costes adicionales. 
  • Costes de Hardware. ¿La aplicación necesita de su propio hardware para ejecutarse correctamente? El nuevo hardware puede necesitar la adquisición de licencias de software adicionales. 
  • Costes de Acceso de Usuarios. ¿Cómo se realizará el acceso de los usuarios y qué software necesitan localmente en sus dispositivos? 
  • Coste Inicial de Implementación. ¿Cuánto va a costar conseguir que la aplicación inicial funcione y se extienda a todos los usuarios? Esto se desglosa en la formación y la consultoría de implementación. Esta última tiende a ser mencionada como una tarifa diaria, pero sin garantizar cuánto tiempo será necesario. Intente conseguir que esta parte sea "fija" para que sepa exactamente cuánto debe presupuestar. En el pasado, la 'regla de oro' generalizada era que los costes de implementación comprendían alrededor del 50% del precio de compra del software. 
  • Soporte Continuo. Generalmente, dentro del mantenimiento del software, está incluido una línea de soporte. Sin embargo, si su pregunta está relacionada con un mejor uso de la aplicación, es posible que tenga que pagar tasas de consultoría por este consejo. También debe comprobar cuándo está disponible la línea de soporte y el tiempo de respuesta que puede esperar. A veces se incurre en cargos adicionales cuando se trata de tiempos de respuesta más rápidos. 
Los costes anteriormente mencionados deben ser acumulados para la vida útil del proyecto o, por lo menos, para los próximos 5 años. Esto es porque algunos costes iniciales pueden ser bajos, pero posteriormente tendrá que pagar más en los siguientes años en la medida que el sistema se actualice o crezca el número de usuarios.

Propuesta del Vendedor 

El último punto a considerar es lo que realmente le está proponiendo el vendedor. Asegúrese de que se trata de una solución completa de trabajo según lo fijado en las especificaciones, incluyendo los puntos no cubiertos en la evaluación detallada.

Resumen 

Los sistemas de Performance Management o Gestión del Rendimiento están en la etapa que estaban los sistemas transaccionales en 1990. Entonces, se tenía que comprar por separado los sistemas de cuentas por cobrar, cuentas por pagar y de control de existencias, aunque algunos proveedores los ofrecían como una "suite integrada". Pero a medida que las necesidades de las organizaciones crecieron, con la finalidad de obtener mejor información del forecast y de la planificación de producción, aparecieron nuevos tipos de sistemas transaccionales. 

Los sistemas de Planificación de Recursos Empresariales (ERP, por sus siglas en inglés) combinaron los sistemas tradicionales de contabilidad, compras y existencias, enmarcándolos dentro de un workflow. Esto hizo dos cosas: Primero permitió que se involucrarán más personas que formaban parte de la cadena de suministro, y en segundo lugar automatizó las diferentes partes del proceso que ahora podían ser activadas por eventos y excepciones. Ya no había que esperar hasta el final del mes para revisar los forecast de ventas, pedidos de materiales y la programación de producción. Ahora se puede realizar de forma continua. 

Las aplicaciones integradas de Performance Management o Gestión del Rendimiento deberían hacer lo mismo en la gestión. Deberían permitir que las personas involucradas en la gestión del negocio trabajen conjuntamente; y que las actividades de planificación y seguimiento sean ejecutadas de forma continua. Para ello, es necesario que combinen todos los aspectos de planificación, presupuestación, forecast, análisis y presentación de informes con un workflow que automatice quién hace qué y cuándo, basado en eventos y excepciones. 

Sistemas integrados no se refieren al empaquetado de aplicaciones antiguas. Como en el caso de los ERP, se requiere una arquitectura que haya sido diseñada para este propósito. Sin embargo, pocos vendedores de software han logrado esto, aunque uno de ellos –CorPeuM- está más cerca que la mayoría. 

En CorPeuM hemos construido nuestro sistema desde el principio con una arquitectura que permite la planificación y el seguimiento continuo en un solo sistema. Tiene muchas características únicas que no encontrará en otros productos, incluyendo: 
  • Workflow dinámico que proporciona listas personalizadas de “To Do” a todos los participantes del proceso, las cuales serán desencadenadas por una combinación de fechas, eventos y excepciones. 
  • Procedimiento de escalamiento automático si los usuarios no culminan sus actividades a tiempo o si lo hacen incorrectamente. 
  • Atributos inteligentes automáticamente relacionados a métricas específicas de los procesos y departamentos de negocios, lo que los hace ideales para modelar los procesos de negocios. 
  • Modelo de datos con múltiples formatos que permita dar soporte a los diferentes niveles y tipos de detalles que pueden ser combinados automáticamente por el sistema. 
  • Dar soporte a calendarios y agrupaciones de tiempo diferentes. 
  • Definiciones centralizadas para la configuración de dimensiones de negocios, miembros y métricas o indicadores, los cuales serán utilizados en toda la aplicación. 
  • Amplias funcionalidades de modelado de datos que dan soporte completamente a la planificación de iniciativas y escenarios. 
  • Completo registro de auditoría de los cambios en las estructuras y los datos. 
  • Sistema inteligente de presentación de informes, donde se pueden combinar y presentar los datos desde cualquier proceso y en cualquier formato y diseño. 
Si usted se encuentra en una organización que está tratando que sus procesos de gestión ya existentes generen más valor, o que está en busca de nuevas formas de gestión del rendimiento, entonces nuestro enfoque podría ser lo que usted está buscando. 

Esto finaliza nuestra serie de posts sobre los Sistemas Integrados de Gestión del Rendimiento. 

Puede descargar nuestro nuevo documento que explica detalladamente la Gestión Integrada del Rendimiento.


Gestión Integrada del Rendimiento Parte 5 ¿Cómo funciona una solución "Integrada"?


En esta serie de posts estamos analizando cómo funciona una aplicación integrada de gestión del rendimiento. En este post, revisaremos como funciona una solución  "integrada".


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

Requerimiento de las Aplicaciones Integradas

Existen muchas soluciones de software que afirman estar integradas y, sin embargo, a los administradores se les hace difícil encontrar cómo relacionar los componentes y hacer que actúen como una única solución. Por ejemplo, el componente utilizado para crear un cuadro de mando o un informe, puede tener una arquitectura diferente a la utilizada para la creación de la pantalla de introducción de datos del presupuesto. Debido a esto, los datos se tienen que mover físicamente entre el presupuesto y la aplicación de presentación de informes, y más importante, cuando se requiere realizar un cambio a una estructura o a un indicador, se tiene que realizar en ambos lugares. Esto no sólo duplica la carga de trabajo, sino que puede generar “perdidas” con facilidad (o peor aún que se ejecuten incorrectamente en una de esas aplicaciones), dando lugar a problemas de integridad no detectados. 

Una aplicación realmente integrada no sufre de este nivel de 'desintegración'. Por el contrario, los 11 componentes mencionados anteriormente, están construidos sobre una arquitectura que incluye lo siguiente: 

Interfaz Única. Sin importar donde se cree el presupuesto o el informe, todas las funcionalidades se mantienen en una única interfaz. Con esto queremos decir que el “ser y parecer” deben ser iguales y no deben parecer dos productos distintos. Los beneficios de una única interfaz incluyen desde la reducción del tiempo de aprendizaje y formación de los administradores; facilidad para saber dónde revisar cuando se realizan cambios en la aplicación; hasta garantizar que la seguridad de roles y acceso sea más fácil de mantener. 

Definición centralizada de las estructuras e indicadores que son utilizados por todos los componentes. Estas definiciones estarán accesibles cuando se cree una plantilla de forecast o se defina un informe. Cualquier cambio realizado aquí automáticamente actualiza cualquier componente donde se utilizan esos indicadores y estructuras. El beneficio de tener una definición centralizada está relacionado a la consistencia sobre lo que significa un indicador o lo que representa una estructura. Como en el caso de la interfaz única, sólo hay un lugar para definir una medida o un indicador, modificar una estructura o crear nuevas versiones de datos. En efecto hay un diccionario de datos centralizado y controlando todos los aspectos de la supervisión del rendimiento. 

Almacenamiento de datos único. Todos los datos asociados a la planificación y la supervisión del rendimiento se gestionan en un único lugar. Para ello será necesario que se de soporte a múltiples formatos de datos, tales como tablas relacionales o modelos multidimensionales. La manera en que se almacenan los datos es irrelevante, sin embargo, los usuarios finales desean que la información se presente de la manera más relevante para ellos de acuerdo al análisis solicitado, por ejemplo, una lista de los 10 principales clientes, el volumen de productos comprados por cliente a lo largo del tiempo, etc. El beneficio de un punto de almacenamiento único de datos consiste en que todos los resultados estarán basados en una misma versión de los datos, sin importar cómo estén siendo presentados. 

Lista “To Do”. Para los usuarios, independientemente del proceso, debería existir un único lugar donde puedan visualizar las actividades que tienen que realizar a continuación. Los menús no realizan esta tarea, ya que tienden a ser comunes para varias personas y no toman en cuenta el orden o importancia de las tareas. Para los administradores es difícil o imposible evaluar donde se encuentran los “cuellos de botella” del proceso y cuáles son los usuarios/actividades que están retrasando a los demás. La única manera de hacerlo es a través de un workflow real que funcione a través de toda la aplicación y todos los componentes que se encuentran en uso. Esto debería generar listas “To Do” dinámicas para cada usuario, que automáticamente cambien el progreso del proceso de gestión. También les proporciona a los administradores una línea de tiempo dinámica de todas las actividades dentro de todos los procesos “vivos” de gestión. 

Sistema único de seguridad. Debe existir un único lugar donde se definan los usuarios, sus roles y requerimientos de accesos para cualquier proceso de gestión. Debería ser posible poder ver todo: 
  • Desde el punto de vista del usuario, es decir, sus roles y acceso para cada proceso 
  • Desde el punto de vista de la gestión del proceso, es decir, todas las personas involucradas en un proceso determinado, como el de presupuestación. 

Funcionalidades Comunes. Las capacidades de todos los componentes están disponibles para todos los demás componentes. Por ejemplo, habrá un modulo de carga de datos, un modulo de presentación de informes, otra funcionalidad de manipulación de datos, etc, que están relacionadas a todas las dimensiones/miembros de negocios y cuyas capacidades puedan ser utilizadas para acceder a los datos en cualquier proceso de gestión. 

En el próximo post revisaremos cómo evaluar software de gestión del rendimiento, comprobando que sea una aplicación integrada. 

Puede descargar nuestro nuevo documento que explica detalladamente la Gestión Integrada del Rendimiento.


Gestión Integrada del Rendimiento – Parte 4 Aplicaciones vs Herramientas de BI y Hojas de Cálculo


En esta serie de posts estamos analizando cómo funciona una aplicación integrada de gestión del rendimiento. En los últimos dos post hemos revisado los 11 componentes que debería tener cualquier aplicación. En este post, cubriremos las diferentes entre las aplicaciones, las herramientas de BI y las hojas de cálculo cuando son utilizadas para la planificación y seguimiento del rendimiento.

Puede descargar el Documento Integreted Performance Aplications completo que explica detalladamente la Gestión Integrada del Rendimiento.

Aplicaciones vs Herramientas de BI y Hojas de Cálculo

Habiendo esbozado los componentes de una aplicación de gestión de rendimiento, vale la pena comparar estas funcionalidades con las que generalmente están disponibles en las herramientas de Business Intelligence (BI) y las hojas de cálculo. Actualmente existen muchas herramientas de BI disponibles, así mismo muchos afirman que ofrecen todo el proceso de planificación empresarial y de presentación de informes. De hecho la mayoría de las aplicaciones de gestión del rendimiento están construidas sobre una plataforma de BI. Sin embargo, la verdadera diferencia entre las dos se encuentra en la ausencia de funcionalidades pre-construidas para hacer frente a la "inteligencia financiera", "trasformación de datos" y "control de usuarios / datos" en las herramientas de BI.

Comparación de las funcionalidades de una aplicación de Gestión del Rendimiento con una herramienta típica de BI. Los elementos no soportados de “forma predeterminada” se muestran en rojo.

La mayoría de estas funcionalidades se pueden construir utilizando las herramientas proporcionadas, pero esto significa que tendrán que ser gestionadas y mantenidas por el administrador y, además, aumentarán considerablemente la complejidad de las reglas de negocio. Por ejemplo, controlar cómo se acumulan los diferentes tipos de cuentas dentro de la dimensión de tiempo o la forma de convertirlos de una moneda local a la moneda base. 

Del mismo modo, controlar lo que un usuario puede hacer durante un proceso de gestión y cómo las solicitudes se aprueban y bloquean, requerirá una gran cantidad de "código" a medida. 

A las hojas de cálculo les va mucho peor que a las herramientas de BI, tal como puede verse en el siguiente gráfico. Faltan la mayoría de las funcionalidades necesarias para la planificación y supervisión del rendimiento.


Comparación de las funcionalidades de una aplicación de Gestión del Rendimiento con una hoja de cálculo. Los elementos no soportados de “forma predeterminada” se muestran en rojo


En una hoja de cálculo no existe una base de datos centralizada, por lo que solo puede ser utilizada por una persona a la vez. No existe un constructor del modelo, ni inteligencia de negocios, ni control de usuarios, y así sucesivamente. Aunque algunas de estas restricciones (sin el aspecto multi-usuario) pueden ser superadas utilizando fórmulas y macros, el resultado final estará muy lejos de lo que se requiere para gestionar el rendimiento. Aquellos que usan las hojas de cálculo son conscientes de que el mantenimiento de los sistemas construidos a partir de ellas puede convertirse fácilmente en una pesadilla incontrolable donde la integridad y las capacidades de planificación están muy comprometidas. 

Por las razones anteriormente mencionadas, las organizaciones que utilizan aplicaciones construidas con este propósito son menos propensas a tener problemas. Pero eso no quiere decir que ofrecen la respuesta perfecta. Un elemento clave en relación con la facilidad de uso de una aplicación de gestión del rendimiento son las funcionalidades que proporcionan los componentes mencionados en las partes 2 y 3 de esta serie de posts y, con igual importancia, el nivel de integración entre los componentes. 

En el próximo post analizaremos los requerimientos de un sistema integrado de gestión del rendimiento.

Puede descargar nuestro nuevo documento que explica detalladamente la Gestión Integrada del Rendimiento.


Gestión Integrada del Rendimiento – Parte 3 Componentes


En esta serie de post estamos analizando cómo funcionan las aplicaciones integradas de gestión del rendimiento. En el último post revisamos los primeros 5 componentes que toda aplicación debería contener – el cual podrá leer en este enlace. En este post, presentaremos los 6 componentes restantes.


Puede descargar el Documento Integreted Performance Management Aplications completo que explica detalladamente la Gestión Integrada del Rendimiento.

6.“Inteligencia” Financiera/Aplicación 

Este componente está relacionado con las funcionalidades de procesamiento de los datos específicos requeridos por la aplicación, que en general suelen ser difíciles o imposibles de codificar utilizando las reglas de negocio estándar. Esto incluye las siguientes características: