¿Sobre qué es el artículo?

Este es un artículo generalizado sobre qué es la "automatización presupuestaria", en qué problemas consiste esta área y qué herramientas de TI se utilizan en ella.



Si desea comprender cómo BI, almacenes de datos (DWH), sistemas de automatización de presupuestos (Cognos, Anaplan, 1C: Holding Management, Bit.Finance) están interconectados y en qué se diferencian de otros sistemas de información corporativos, aquí está.



Si es un arquitecto técnico que nunca ha trabajado con el área temática de la planificación empresarial, este artículo también es para usted.





Les advierto de inmediato que traté de escribir el artículo en el lenguaje más simple posible para que sea comprensible para todos.

¿Por qué decidí escribirlo?

En la actualidad, prácticamente no existe una breve descripción sistemática de esta área, que daría respuestas claras a las preguntas:

1. ? ?
2. (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, ., 1: ) ?
3. BI – ?

La diferencia arquitectónica entre contabilidad y planificación es que los datos contables fluyen de abajo hacia arriba. Para obtener informes de calidad, debe organizar el registro de hechos lo más detallados posible. Entonces, cualquier información resumida (importante para los gerentes) se puede obtener mediante una simple agregación.



Por lo tanto, en contabilidad, el esquema Documento -> Tabla (Registro) -> Informe funciona de manera óptima (que se usó mucho antes de la automatización, en la contabilidad medieval).





Figura: 1. Esquema contable "Documento -> Registro -> Informe"





Los planos se ampliaron inicialmente. Por tanto, conviene introducirlos exactamente "desde arriba" (es decir, en las mismas formas en que se generan los informes).



Por lo tanto, al intentar construir una automatización presupuestaria por analogía con la contabilidad convencional (Fig. 3), las empresas se enfrentan inmediatamente a tres problemas clave.





Figura: 3



Problema 1: Administrar reglas . Es muy inconveniente y laborioso administrar las reglas para la transformación de datos (desde los niveles más bajos de contabilidad hasta el formato de presupuestación), escritas en el código de informe.



Problema 2: Velocidad de "recopilación de datos" . Los planes se muestran en informes muy rápidamente (dado que ya están almacenados en forma ampliada) y los datos reales se calculan muy lentamente.



Problema 3: formularios de ingreso al plan... La forma más conveniente para ingresar planes es un informe de hechos del plan. Pero los informes en los sistemas de información generalmente no permiten la entrada de datos.



Los dos primeros temas no solo están relacionados con la elaboración de presupuestos y, en general, representan la base de toda el área temática del almacenamiento de datos, la integración de datos y ETL.



El tercer problema es un problema de planificación específico. Lo cual, de hecho, es uno de los problemas importantes de los sistemas ERP como herramientas en tiempo real (destinadas no solo a la contabilidad "póstuma" de los eventos que han ocurrido, sino a la planificación y control operativo del negocio).

Problema 1: administrar reglas de transformación

En la Fig. 1-3, todas las reglas para transformar los datos reales (desde el nivel de contabilidad más bajo hasta los niveles de informes superiores) están escritas directamente en el código de informe.



Esto es malo:

• Las reglas no se pueden administrar sin cambiar el código;
• Solo se pueden utilizar en este informe.
  lo que significa:

  – , , ,
  
  – - ,
  
  

Complejidad de las reglas de transformación

Es muy importante considerar aquí que las reglas de transformación pueden ser bastante complejas. La transformación no siempre es una simple agregación de datos (de día a mes; de departamento a organización; de almacén a región; de línea de producto a artículo, etc.). Esto es especialmente evidente en el CIS, donde la contabilidad de gestión a menudo se basa en la contabilidad. Luego, a partir de una variedad de combinaciones de diferentes detalles contables, se pueden determinar diferentes valores para la contabilidad de gestión.





Puede imaginarse el problema que supone mantener dicho código para los programadores, si hay varios cientos de artículos de este tipo, se utilizan en una docena de informes diferentes y las reglas para determinarlos en la contabilidad de gestión se pueden ajustar cada 3-4 meses.

Solución al problema 1: mapeo

Para resolver este problema, el mapeo (correspondencia entre campos de diferentes niveles y / o tipos de contabilidad e informes) se puede eliminar de los informes, crear como un objeto separado, configurar y almacenar por separado, y luego consultarlos si es necesario.





Figura: 4



Esto tiene dos ventajas a la vez:

• Las reglas son más fáciles de administrar. Pueden hacerse interactivos y configurarse sin código, lo que significa que incluso los usuarios normales pueden hacerlo a menudo;
• Una regla se puede utilizar en diferentes informes y / u otros algoritmos

Este enfoque no tiene desventajas significativas.



Pero desarrollar una herramienta para el mapeo conveniente de grandes volúmenes de directorios no es fácil.

Problema 2: Velocidad de transformación de datos reales

Solución al problema 2: almacenamiento de datos transformados

Para no calcular los datos del informe "sobre la marcha", ya se pueden almacenar de forma ampliada y transformada.



Para hacer esto, además de las tablas de origen (que aún serán necesarias en la empresa), debe crear tablas para almacenar los datos reales agregados. Pueden ser tablas separadas y una tabla general tanto para el "plan" como para el "hecho" agregado.



Por supuesto, estas tablas primero deben completarse de alguna manera: para esto, realizaremos el mismo procedimiento de transformación que se realizó anteriormente al generar el informe, pero ahora lo trasladaremos a un proceso de fondo separado.





Figura: cinco

DWH

Relacionado con este problema está el dominio Data Warehouse (DWH).



En términos generales, DWH es un lugar (una tabla o, en la práctica, un conjunto de tablas relacionadas) para almacenar datos intermedios calculados (agregados o transformados de alguna manera).



Cuáles son las ventajas:

• Velocidad de lectura de datos. Si los informes "leen" datos ya transformados de la tabla, lo hacen muy rápidamente.
• Verificabilidad. Cuando los datos se almacenan previamente en el almacén, es más fácil verificarlos.

Desventajas:

• Exactitud. De hecho, este inconveniente es bastante teórico (la máxima precisión se garantiza precisamente cuando tomamos datos de la fuente principal de información).
  En la práctica

  , ; , . , , , .
• Cargando memoria. En consecuencia, para almacenar datos agregados, desperdiciamos espacio adicional en los discos duros. También, de hecho, más bien una desventaja teórica.
• Descifrado. Si conectamos informes a tablas agregadas (en las que los datos no se detallan según los documentos fuente), surgen problemas con las posibilidades de su descifrado (drill-down).

Procesos ETL

ETL puede denominarse cualquier proceso en el que se toman datos de algún lugar, se modifican y luego se cargan en algún lugar. Ésta es una abreviatura común de Extraer, Transformar, Cargar.



Pero generalmente este término se usa precisamente en los casos en que los datos después de la transformación se escriben en algún lugar para su almacenamiento.



Este enfoque tiene ventajas:

• Distribución de la carga en el sistema. El proceso de transformación se alarga en el tiempo. Podemos llenar la tabla agregada gradualmente (a medida que cambiamos / agregamos datos en los sistemas contables originales) o en un horario. Por ejemplo, los cálculos complejos se pueden posponer durante la noche o en otro horario no comercial cuando el servidor es "gratuito". Esto le permite administrar la carga en el sistema.
• Transformación de una sola vez. Una vez que escribimos la información de resumen en una tabla agregada, podemos acceder a ella desde muchos informes diferentes. Por lo tanto, no es necesario realizar las mismas transformaciones muchas veces.

Solo hay una desventaja:

• La complejidad de controlar la integridad de los datos cargados. Construya un proceso ETL que no pierda datos, que sea lo suficientemente transparente y controlable; es posible, pero esto requiere un equipo altamente calificado, participación del usuario y costos laborales notables.

Problema 3: Formulario de ingreso de presupuesto

El hecho es que en la forma clásica, los informes en los productos de software son un medio de salida de datos. Pero no puede ingresar datos en ellos.





Pero para presupuestar el esquema clásico "Formulario de entrada" (documento) -> tablas internas -> Formulario de salida (informe) "no es adecuado.



Por ejemplo, en algún momento desarrollamos un informe de adquisiciones mensual (como en la Fig. 2), pero ahora estamos comenzando a planificar y el director financiero quiere ingresar el presupuesto de adquisiciones de la misma forma.



¿Que más queda por hacer? Puede crear un formulario de entrada de plan que se vea muy, muy similar a este informe (como se muestra en la Figura 3).

Solución al problema 3: formularios de E / S interactivos

La solución también es obvia: en lugar de los habituales "documentos" e informes ", debe crear un objeto que simultáneamente y leer e ingresar datos.



Es incluso mejor si en este objeto también será posible realizar cálculos entre los datos ingresados ​​y / o leídos, es decir, trabajar como Excel le permite trabajar.



En este caso, los planes, después de ingresar, se pueden "agregar" al mismo almacén de datos donde se encuentran los datos reales (ver figura).





Figura: 6



Pero estos formularios son mucho más difíciles de implementar que los informes o documentos ordinarios en los sistemas contables.



El grado de interactividad puede ser diferente: es más fácil implementar formularios preconfigurados, más difícil - dinámico (donde el número de columnas / filas no se conoce de antemano, pero sus tipos están predefinidos). Es incluso más difícil permitir que el usuario "rote" datos, cree nuevos formularios y establezca fórmulas de cálculo arbitrarias, cambiando la estructura de los informes.

Solución al problema 4: cubos

Existe otra herramienta que resuelve un problema no indicado anteriormente.

El caso es que con grandes cantidades de datos, con alta interactividad y con fórmulas complejas, las tablas SQL relacionales ordinarias, en las que se acostumbra almacenar datos de sistemas ERP, no brindan la máxima velocidad de procesamiento de datos en tiempo real.



Para resolver este problema, puede utilizar el almacenamiento de datos no en forma de tablas, sino inmediatamente en forma de cubos.





Es cierto que si para las tareas presupuestarias organizar el almacenamiento de forma inmediata en forma de cubo es una opción buena y adecuada, entonces, para otras tareas comerciales, un modelo de almacenamiento multidimensional puede no ser adecuado y el almacenamiento se organiza con una tecnología diferente. En este caso, el cubo se puede agregar al almacenamiento "principal" como otro enlace en la arquitectura.

TIPOS DE PRODUCTOS DE SOFTWARE EN PRESUPUESTO

Ahora consideremos los tipos de tecnologías de la información que resuelven problemas que son importantes en la automatización de presupuestos:

• Sistemas de datos iniciales (sistemas contables, sistemas ERP)
• Herramientas ETL
• Almacenes de datos (cubos regulares y OLAP)
• Sistemas de BI
• Sistemas EPM
• Excel por supuesto

Cada tipo de sistema tiene una función teóricamente básica (ver tabla):







pero en realidad, los límites son un poco borrosos y, a menudo, los productos "saben cómo" hacer cosas relacionadas. La superposición de funciones tiene un aspecto muy aproximado:







Importante: debe tenerse en cuenta que la superposición de funciones no suele ser del 100%.



Es decir, normalmente una herramienta que ofrece funciones adicionales no las realiza tan bien como una herramienta especializada independiente.

Mapa de tipos de software en presupuestación

En general, la cobertura visual de diferentes tareas para la automatización de presupuestos por diferentes tipos de sistemas de información se puede mostrar aproximadamente así:





Fig. 7



Ahora veamos qué tipo de arquitectura presupuestaria ofrecen algunos productos de software populares.

PRESUPUESTO EN SISTEMAS ERP

El concepto de ERP cambia con el tiempo y se están incorporando nuevas capacidades a los sistemas ERP.



En mi opinión, la funcionalidad ERP "clásica" incluye un sistema de contabilidad; diseñadores de informes; funciones de control operativo de los planes y, por supuesto, las capacidades básicas de su input.



Excluye: capacidad para recopilar datos de múltiples fuentes; construcción de cubos y analítica interactiva



Hay motivos para creer que EPM (como BI) se concibió como algo que iba más allá de ERP. Pero ahora las fronteras se están difuminando y las funciones de EPM o incluso productos completos se pueden incluir como módulos en los sistemas ERP.

1C: SCP

La UPP implementa el siguiente esquema, pero dentro de una base.





Figura: 8. Arquitectura de la presupuestación en 1C: UPP



Ventajas de la presupuestación en UPP:

• El SCP es muy transparente y fácil de modificar. Es fácil verificar los datos que contiene y es bastante económico desarrollar nuevas funciones.

Mapeo - en el SCP a un nivel medio. Esto no es una ventaja ni una desventaja. Establecimiento de la intensidad laboral media.



Desventajas de presupuestar en SCP:

• Falta de formas interactivas de input-output. La creación de cualquier dato se realiza a través de documentos (ingreso de planos; obtención de datos reales agregados; realización de cálculos), donde no hay y no puede haber interactividad y la capacidad de ver el panorama general.
• Falta de interfaz ETL. Existe un mapeo, pero los datos reales se cargan directamente desde el formulario del documento, lo cual es inconveniente.
• Plataforma antigua. No puede utilizar la tecnología 1C Managed Forms, que brinda al usuario posibilidades modernas para el filtrado / clasificación universal de listas e informes. Esto degrada las capacidades analíticas del usuario.

En general, en el SCP, la automatización de la presupuestación se implementa más claramente de acuerdo con el principio de contabilidad ordinaria: el usuario no trabaja desde la imagen general, sino desde los documentos primarios (ingresar un plan; cargar un hecho; estimaciones), y la imagen general solo se puede ver en informes en los que no se puede ingresar nada.

1C: ERP

Por lo que recuerdo, inicialmente ERP solo proporcionaba un modelo de informes "en línea". Y hoy, en muchas empresas, el escenario principal es exactamente este. Sin embargo, ahora el programa permite el almacenamiento intermedio de los valores calculados.





Figura: 9. Arquitectura de la presupuestación en 1C: ERP



Ventajas de la presupuestación en 1C: ERP:

• Formas de insumo-producto suficientemente funcionales

Desventajas de presupuestar en 1C: ERP:

• La rigidez del modelo. En principio, como en la mayoría de los sistemas ERP, el modelo presupuestario no tolera cambios frecuentes y es bastante exigente con la configuración previa.
• Mapeo débil. Por alguna razón, la funcionalidad de mapeo es peor que en la UPP
• Dureza del producto. A diferencia de SCP, es extremadamente difícil y costoso reelaborar el marco metodológico aquí. Debe estudiar bien el existente y construir el presupuesto en 1C: ERP, si realmente se adapta a la empresa
• Actuación. Los formularios interactivos son bastante funcionales, pero el dispositivo técnico los hace extremadamente lentos en grandes cantidades de datos

También en 1C: ERP no hay una funcionalidad seria en términos de configurar el proceso de presupuestación organizacional (flujo de trabajo) y el trabajo multiusuario. Por ejemplo, los procesos de aprobación se incluyen en un producto separado 1C: Flujo de trabajo, que generalmente se implementa sobre ERP.

1C: CA

Integrated Automation es una versión simplificada de 1C: ERP, por lo que su desarrollo sigue el mismo camino, y aquí no existe una metodología de presupuesto propia.

MS Axapta / MS Dynamics AX

Solo existe un modelo "en línea" para ver los datos presupuestarios reales: se leen directamente de sus propios módulos de contabilidad, mientras que no se brindan las posibilidades de una transformación seria.





Figura: 10. Arquitectura de la presupuestación en MS Dynamics



Tanto el positivo como el negativo del sistema es su "afilado" en sus propios módulos contables de Dynamics y su estructura prefabricada.



Pros:

• Integración con módulos contables. Configurar la obtención de datos reales de varios módulos del sistema ERP es bastante simple.
• Integración. Hay muchas oportunidades para cargar planes ya hechos desde sistemas externos. Por lo tanto, Microsoft sigue claramente la lógica de separación de EPM de ERP, como resultado de lo cual los sistemas EPM están muy bien "colgados" en Dynamics.
• Flujo de trabajo. Modelo organizativo personalizable suficientemente funcional y transparente del proceso presupuestario

Desventajas:

• ETL. En general, el producto no proporciona capacidades significativas de transformación de datos.
• Dureza del producto. Aquí se establece una metodología lista para usar, pero bastante limitada. Y (como en el caso de 1C: ERP) no solo es difícil reciclarlo, sino que también es prácticamente inútil.

SAP S4 HANA

El principal producto de SAP que reemplazó al sistema ERP SAP R / 3.



Para la presupuestación, ahora se usa un producto EPM separado, que en la versión de escritorio (SAP BPC) aún podría considerarse un sistema EPM separado "en la parte superior" del ERP, pero en la versión en la nube (SAP Analytics Cloud) ya está finalmente integrado en el sistema ERP (en SAP S4 HANA Cloud). Más detalles sobre SAP BPC estarán a continuación.



Es importante decir algo más sobre S / 4 HANA en sí: SAP transfiere todo el trabajo de un sistema ERP de una base de datos relacional a una combinada (una mezcla de relacional, columnar y multidimensional). Dicha base de datos combinada es su propia tecnología SAP HANA (que no debe confundirse con S / 4 HANA), que, dependiendo de las acciones del usuario, funciona como un sistema transaccional (sistema de contabilidad) o como un sistema analítico (cubo).



Por lo tanto, SAP se está moviendo hacia una arquitectura que es lo opuesto a lo que ahora se conoce en la práctica "normal". En él, la base de datos analítica no se construye "encima" del almacenamiento (SAP BW), sino que se implementa "bajo" el sistema ERP. En este caso, el almacén de datos (SAP BW), cuando el usuario trabaja con sus datos del sistema de EPM, las transferencias de datos para los cálculos de la parte posterior de esta base de datos combinada originales.



De hecho, SAP logra el mismo efecto para el que se concibió IN-Memory OLAP de manera opuesta: maximizando los cálculos de RAM.

ERP en la nube de Oracle

Oracle también tomó el camino de incorporar un sistema EPM dentro de un ERP.



La compañía está moviendo activamente sus productos a la versión en la nube (quizás incluso más activamente que lo que está haciendo SAP). Por lo tanto, para su principal solución EPM, Oracle Hyperion (de la que también hablaremos a continuación), la compañía está promoviendo una alternativa en forma de Oracle EPM Cloud basado en la nube, que se incluye en el ERP Oracle Cloud basado en la nube.

BI-SISTEMAS

Los sistemas BI (Business Intellegence) en su forma "pura" son un medio de salida de datos. Es decir, BI son diseñadores de informes y cuadros de mando, que suelen contener también funciones básicas para reestructurar y analizar datos (por ejemplo, permiten unir tablas, encontrar tendencias medias, etc.).



Sistemas de BI populares:

• Power BI
• Cuadro
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

Normalmente, BI se conecta a almacenes de datos (tanto relacionales como multidimensionales) o tablas SQL sin procesar. Por lo tanto, puede consultar datos de origen suficientemente detallados (para agregarlos ya en BI). Sin embargo, las transformaciones condicionales complejas (con condiciones "si") no se refieren a la funcionalidad de BI "clásica". Si se enfrenta a la tarea de crear un sistema de visualización de paneles, es mejor crear una transformación antes de implementar BI.

SISTEMAS EPM

EPM son las siglas de Enterprise Performance Management. Además, se encuentran los términos Gestión del rendimiento corporativo (CPM) y, con menos frecuencia, Gestión del rendimiento empresarial (BPM).



Un término bastante amplio que puede implicar funciones relacionadas, pero la mayoría de las veces estos sistemas se pueden considerar como constructores de formas interactivas "Plan-hecho". El concepto de EPM aún no se ha vuelto muy conocido, pero soluciones como IBM Planning Analytics, Oracle Hyperion, Anaplan, que a veces se consideran en el contexto de Business Intellegence, se denominan más correctamente sistemas EPM.



A veces, los sistemas EPM se crean para fines más amplios (por ejemplo, SAP EPM o 1C: Holding Management), pero los consideraremos precisamente en términos de sistemas para la automatización de presupuestos. Por lo tanto, lo llamaremos SAP Business Planning & Consolidation (SAP BPC), un sistema EPM, aunque el propio SAP lo llama el producto SAP EPM más grande, que incluye SAP BPC.



Como dijimos, BI no permite la entrada de datos. Los EPM generalmente incluyen funciones de BI estándar y, además, brindan la capacidad de ingresar y registrar datos.



Sistemas EPM notables:

• Oracle Hyperion
• IBM Planning Analytics
• Anaplan
• SAP BPC
• Bit.Finanzas
• 1C: Gestión de holding

Empecemos por los más pequeños.

Bit.Finanzas

Bit. Finance se basa en la metodología de presupuestación UPP, sin embargo, a diferencia de ella, en primer lugar, está respaldada y desarrollada, y en segundo lugar, se implementa como un sistema EPM sobre ERP (por lo tanto, le permite consolidar datos fácticos de varias fuentes externas).





Figura: 11. La arquitectura de la presupuestación en Bit.Finance



Ventajas de la automatización de la presupuestación en Bit.Finance:

• Constructores de formularios para ingresar o leer datos. A diferencia de la UPP, las formas de los documentos contables no se fijan aquí, se pueden personalizar, llevándolas a una forma bastante conveniente.
• Interfaz para gestionar estimaciones de costes. Puede volver a calcular los modelos presupuestarios aquí de forma centralizada, en lugar de crear manualmente un documento de cálculo de costes.

El mapeo está más desarrollado que en SCP.



La obtención de datos reales funciona de tres formas:

• A través de un documento de adquisición de pruebas (como en el SCP),
• Contabilidad paralela. En esta opción, los documentos contables, a medida que se mantienen, crean asientos simultáneos tanto en los registros contables como en los registros presupuestarios.
• Método de transmisión. En esta opción, los asientos del libro mayor de contabilidad se traducen al libro mayor de presupuestos.

Desventajas de la automatización de presupuestos en Bit.Finance:

• Trabaja con los formularios de los documentos. A pesar de que las formas de los documentos se han flexibilizado (ver el primer plus), y en general, en este aspecto, se ha avanzado mucho en comparación con SCP, el producto aún no se ha desviado del modelo de trabajo basado en documentos tanto como quisiéramos. Lo cual, como dijimos, es inconveniente para presupuestar.
• Falta de formas interactivas de input-output. A diferencia de 1C: ERP, aquí no hay ninguno.

Anaplan

Un producto estrella que recientemente ha ganado gran popularidad en el mercado global. Solo se ofrece en la versión en la nube.



A diferencia de otras soluciones populares (incluidas Hyperion y Planning Analytics), tiene una especialización ligeramente específica: funciona mejor como un servicio de costeo que le permite recalcular rápida y automáticamente modelos presupuestarios volumétricos con una gran cantidad de dependencias.





Figura: 12. Arquitectura de presupuestos de Anaplan (escenario de automatización popular)



Ventajas:

• Costeo. El producto se centra en los cálculos y almacena todos los datos en OLAP en memoria, lo que permite volver a calcular todos los modelos en línea.
• Trabajo en equipo (dentro de la preparación de datos de planificación)
• UX y modelado de formas libres.
• ETL. Herramienta ETL propia y bastante conveniente
• Requiere soporte de TI mínimo. Especialmente cuando se trata de modelar.
• Costo. Un poco caro para el mercado ruso, pero en comparación con los líderes internacionales (el mismo Oracle Hyperion), el coste total de propiedad es menor
• Velocidad de implementación. En comparación con Hyperion y Planning Analytics, el producto es más fácil de usar y más fácil de implementar.

Desventajas:

• Formateo
• Trabajo en equipo (en términos de trabajar con eventos: notificaciones, mailings, etc.)
• Sintaxis de fórmulas personalizadas. En general, usar su propio código siempre es una desventaja desde el punto de vista de los usuarios finales.
• Jerarquías. Solía ​​haber problemas con el uso de una jerarquía de directorios diferente para diferentes modelos de presupuesto. El problema no es importante para muchas empresas, pero es fundamental para algunas. Quizás (espero que sí) Anaplan ya haya resuelto este problema.
• Ad-hoc . , : Anaplan , .

El más y el menos de Anaplan es su especialización relativamente clara y el hecho de que no invade el ecosistema de TI de la empresa. La ventaja es que el producto ha definido claramente su propósito funcional y las direcciones de su desarrollo son bastante predecibles. Es un servicio para realizar análisis Y si ..., calcular y aprobar planes (presupuestos), y es necesario planificar la arquitectura del cliente en base a esto. La desventaja es que el producto no puede reemplazar un almacén de datos corporativo completo, no puede reemplazar todas las capacidades de BI, no se construye una infraestructura ETL corporativa compleja sobre él y, de hecho, todo el sistema informático corporativo. Todo esto no sería un problema si el producto no se ofreciera solo en la versión en la nube.



A diferencia de Oracle y SAP (que afirman ser ecosistemas), Anaplan no enfatiza la capacidad de "transportar" datos y herramientas fácilmente entre la nube y los servidores de la empresa. Así, en su caso, las desventajas del producto en la nube (teniendo en cuenta la arancelización en función de la cantidad de datos utilizados en el servidor) son más notorias.



Dado que no reemplaza un almacenamiento corporativo universal, en ciertos casos se puede utilizar como un servicio de cálculo que "agrega" datos del plan al DWH propio de la empresa, desde donde los datos se transfieren a un sistema de BI separado para crear informes rápidos y cuadros de mando.





Figura: 13. Arquitectura presupuestaria de Anaplan (escenario alternativo de automatización)



En general, el uso de sistemas EPM y BI es una práctica normal.

Oracle Hyperion

Viene en al menos dos versiones: Oracle Hyperion Planning y Oracle Hyperion Financial Management.

Ahora está siendo reemplazado activamente por el nuevo producto Oracle EPM Cloud.



Debido al ecosistema, las arquitecturas pueden adoptar una variedad de tipos, pero la típica se parece a esto.





Figura: 14. Arquitectura presupuestaria en Hyperion (opción posible)



En la figura, di un sistema de BI como ejemplo, ya que la base de datos analítica Oracle Essbase es una excelente base de datos para el análisis de big data en herramientas de BI.



Oracle Data Integrator se ofrece como una solución ETL, que actúa como un mecanismo de integración de datos universal en el ecosistema de Oracle.



Ventajas de la automatización de presupuestos en Oracle Hyperion:

• Ecosistema. En el caso de Oracle, lo señalaré como una ventaja, ya que Oracle es uno de los proveedores de bases de datos más grandes, y la integración para las empresas que trabajan en Oracle DBMS (y hay muchas empresas de este tipo) realmente ofrece ventajas. En particular, es más conveniente distribuir la funcionalidad entre la nube y el servidor. Además, los colegas hablan de ventajas bastante serias en términos de seguridad en la arquitectura de Oracle (no soy un experto en esto, si hay alguna aquí, corrija).
• Ad-hoc ("informes a pedido").

Desventajas de la automatización de presupuestos en Oracle Hyperion:

• Ecosistema. También señalaré como un signo menos, ya que, según la información disponible, Hyperion es elegido principalmente por empresas que trabajan en la pila de tecnología de Oracle, y de su uso en un entorno que no es de Oracle a largo plazo, es posible un efecto menor.
• . , Anaplan.
• . , UX ( ).

IBM Planning Analytics

Destinado principalmente a grandes empresas, no es muy fácil de implementar y administrar, pero es un sistema EPM muy funcional. Actualmente, la analítica de IBM Planning se basa en tecnologías TM1 (que son el núcleo de Cognos).



Para los procesos ETL, IBM sugiere utilizar un producto separado, IBM DataStage (anteriormente utilizado por Cognos DataManager), Turbo Integrator, Cognos Integration Server o una herramienta ETL externa.



La arquitectura típica es muy similar a Hyperion.





Figura: 15. Arquitectura presupuestaria en Planning Analytics (opcional)



Fortalezas de IBM Planning Analytics:

• Pronóstico.
• Trabajando con eventos.
• Flexibilidad. El producto no puede considerarse no exigente en términos de preconfiguración, pero intenta ser adaptable a los modelos cambiantes.
• No ecosistema. Lo sorprendente de trabajar con IBM es que un gran volumen de material didáctico producido por la empresa tiene como objetivo describir las mejores prácticas para la interacción de los productos IBM con otras soluciones (incluidas Oracle y SAP) y en una variedad de temas. En mi opinión subjetiva, es bueno que a largo plazo la empresa mantenga la tendencia a desarrollar la integración con sistemas de terceros (lo que permite soportar una variedad de arquitecturas que se han desarrollado en las empresas), y no reducirla.
• Soporte de producto.

Desventajas

• Complejidad. Al igual que con Hyperion: requiere una formación significativa del usuario, no la infraestructura más ligera.

SAP BPC

En general, las características distintivas de SAP son el ecosistema, la complejidad de la arquitectura y la infraestructura de las soluciones.



Como dije, SAP ha admitido y admite diferentes opciones de arquitectura en diferentes momentos; Según la información más reciente, la versión insignia de la arquitectura recomendada por el proveedor hoy se ve así:





Fig. 15. Arquitectura de presupuestación en SAP Business Planning & Consoldation (ejemplo)



Ventajas de la presupuestación basada en SAP BPC:

• Integración de datos. Aunque complejo, es funcional y rápido, lo que es fundamental para las grandes empresas.
• Visualización.
• Flujo de trabajo.

Desventajas de la presupuestación basada en SAP BPC:

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• Precio. En términos de costo total de propiedad, en realidad resulta ser uno de los sistemas EPM más caros del mundo, que está influenciado por cambios en la arquitectura.

HERRAMIENTAS ETL

Se utilizan herramientas ETL bien conocidas para construir procesos ETL, entre los cuales hay muchos productos de los mismos proveedores que producen soluciones BI / EPM:

• IBM DataStage
• Informatica PowerCenter
• Talend
• Apatar
• Servicios de datos de SAP
• Integrador de datos de Oracle
• Fábrica de datos de Microsoft Azure
• y muchos otros Dr.

Está previsto que el artículo se actualice gradualmente, posiblemente con la adición de información sobre nuevos productos y principios de desarrollo de productos de software para presupuestar "desde cero".