Quel est le sujet de cet article?

Il s'agit d'un article généralisé sur ce qu'est «l'automatisation de la budgétisation», les problèmes qui se posent dans ce domaine et les outils informatiques qui y sont utilisés.



Si vous voulez comprendre comment la BI, les entrepôts de données (DWH), les systèmes d'automatisation budgétaire (Cognos, Anaplan, 1C: Holding Management, Bit.Finance) sont interconnectés et en quoi ils diffèrent des autres systèmes d'information d'entreprise - vous êtes ici.



Si vous êtes un architecte technique qui n'a jamais travaillé avec le domaine de la planification d'entreprise, cet article est également pour vous.





Je vous préviens tout de suite que j'ai essayé d'écrire l'article dans le langage le plus simple possible pour qu'il soit compréhensible pour tout le monde.

Pourquoi ai-je décidé de l'écrire?

De nos jours, il n'y a pratiquement pas de brève description systématique de ce domaine, qui donnerait des réponses claires aux questions:

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

La différence architecturale entre la comptabilité et la planification est que les données comptables circulent de bas en haut. Pour obtenir des rapports de qualité, vous devez organiser l'enregistrement des faits aussi détaillés que possible. Ensuite, toute information récapitulative (importante pour les managers) peut être obtenue par simple agrégation.



Par conséquent, en comptabilité, le schéma Document -> Table (Registre) -> Rapport fonctionne de manière optimale (qui était utilisé bien avant l'automatisation, de retour dans la comptabilité médiévale).





Figure: 1. Schéma comptable "Document -> Registre -> Rapport"





Les plans ont été initialement agrandis. Par conséquent, il est pratique de les saisir exactement "par le haut" (c'est-à-dire sous les mêmes formes que celles dans lesquelles les rapports sont générés).



Par conséquent, en essayant de construire une automatisation de la budgétisation par analogie avec la comptabilité conventionnelle (Fig. 3), les entreprises sont immédiatement confrontées à trois problèmes clés.





Figure: 3



Problème 1: Administration des règles . Il est très peu pratique et laborieux d'administrer les règles de transformation des données (des niveaux les plus bas de la comptabilité au format de budgétisation), écrites dans le code du rapport.



Problème 2: Vitesse de "collecte des faits" . Les plans sont affichés très rapidement dans les rapports (puisqu'ils sont déjà stockés sous une forme agrandie), et les données réelles sont calculées très lentement.



Problème 3: planifier les formulaires de saisie... Le formulaire le plus pratique pour saisir des plans est un rapport de faits de plan. Mais les rapports dans les systèmes d'information ne permettent généralement pas la saisie de données.



Les deux premières questions ne sont pas seulement liées à la budgétisation, et représentent en général la base de tout le domaine de l’entreposage de données, de l’intégration des données et de l’ETL.



Le troisième problème est le problème de planification spécifique. Ce qui, en fait, est l'un des problèmes importants des systèmes ERP en tant qu'outils temps réel (destinés non seulement à la comptabilisation «posthume» des événements survenus, mais à la planification et au contrôle opérationnel de l'entreprise).

Problème 1: administration des règles de transformation

En figue. 1-3, toutes les règles de transformation des données réelles (du niveau de comptabilité le plus bas aux niveaux de reporting supérieurs) sont énoncées directement dans le code de l'état.



C'est mauvais:

• Les règles ne peuvent pas être administrées sans changer le code;
• Ils ne peuvent être utilisés que dans ce rapport.
  ce qui signifie:

  – , , ,
  
  – - ,
  
  

Complexité des règles de transformation

Il est très important de considérer ici que les règles de transformation peuvent en effet être assez complexes. La transformation n'est pas toujours une simple agrégation de données (au jour le jour; d'un service à une organisation; d'un entrepôt à une région; d'une ligne de produits à un article, etc.). Cela est particulièrement évident dans la CEI, où la comptabilité de gestion est souvent basée sur la comptabilité. Ensuite, à partir d'une variété de combinaisons de différents détails comptables, différentes valeurs pour la comptabilité de gestion peuvent être déterminées.





Vous pouvez imaginer à quel point un problème de maintenance d'un tel code est important pour les programmeurs, s'il existe plusieurs centaines d'articles de ce type, ils sont utilisés dans une douzaine de rapports différents, et les règles pour les déterminer dans la comptabilité de gestion peuvent être ajustées tous les 3-4 mois.

Solution au problème 1: cartographie

Pour résoudre ce problème, le mappage - correspondance entre les champs de différents niveaux et / ou types de comptabilité et de reporting - peut être supprimé des rapports, créé en tant qu'objet distinct, configuré et stocké séparément, puis s'y référer si nécessaire.





Figure: 4



Cela présente deux avantages à la fois:

• Les règles sont plus faciles à administrer. Ils peuvent être rendus interactifs et personnalisables sans code, ce qui signifie que même les utilisateurs ordinaires peuvent souvent le faire;
• Une règle peut être utilisée dans différents rapports et / ou autres algorithmes

Cette approche n'a pas d'inconvénients significatifs.



Mais développer un outil de cartographie pratique de grands volumes de répertoires n'est pas facile.

Problème 2: Vitesse de transformation des données réelles

Solution au problème 2: stockage des données transformées

Afin de ne pas calculer les données du rapport "à la volée", elles peuvent déjà être stockées sous une forme agrandie et transformée.



Pour ce faire, en plus des tables source (qui seront toujours nécessaires dans l'entreprise), vous devez créer des tables pour stocker les données réelles agrégées. Il peut s'agir de tableaux séparés et d'un tableau général pour le «plan» et le «fait» agrégé.



Bien sûr, ces tableaux doivent d'abord être remplis d'une manière ou d'une autre: pour cela, nous effectuerons la même procédure de transformation que celle effectuée précédemment lors de la génération du rapport, mais nous allons maintenant le déplacer vers un processus d'arrière-plan distinct.





Figure: cinq

DWH

Le domaine DWH (Data Warehouse) est lié à ce problème.



En gros, DWH est un endroit (une table ou, en pratique, un ensemble de tables liées) pour stocker des données intermédiaires calculées (agrégées ou transformées).



Quels sont les avantages:

• Vitesse de lecture des données. Si les rapports «lisent» des données déjà transformées de la table, ils le font très rapidement.
• Vérifiabilité. Lorsque les données sont pré-stockées dans l'entrepôt, il est plus facile de les vérifier.

Moins:

• Précision. En fait, ce moins est plutôt théorique (une précision maximale est assurée précisément lorsque nous prenons les données de la source d'information la plus primaire).
  Sur la pratique

  , ; , . , , , .
• Chargement de la mémoire. En conséquence, afin de stocker des données agrégées, nous gaspillons de l'espace supplémentaire sur les disques durs. Aussi, en fait, plutôt un inconvénient théorique.
• Décryptage. Si nous connectons des rapports à des tableaux agrégés (dans lesquels les données ne sont pas détaillées selon les documents sources), des problèmes se posent avec les possibilités de leur décryptage (drill-down).

Processus ETL

ETL peut être appelé n'importe quel processus dans lequel les données sont prises quelque part, modifiées puis chargées quelque part. C'est une abréviation courante pour Extraire, Transformer, Charger.



Mais généralement, ce terme est utilisé précisément dans les cas où les données après transformation sont écrites quelque part pour le stockage.



Cette approche présente des avantages:

• Répartition de la charge sur le système. Le processus de transformation s'étire dans le temps. Nous pouvons remplir le tableau agrégé progressivement (à mesure que nous modifions / ajoutons des données dans les systèmes comptables d'origine) ou selon un calendrier. Par exemple, des calculs complexes peuvent être reportés pendant la nuit ou pendant d'autres heures non ouvrées lorsque le serveur est «libre». Cela vous permet de gérer la charge sur le système.
• Transformation unique. Une fois que nous écrivons les informations récapitulatives dans un tableau agrégé, nous pouvons y accéder à partir de nombreux rapports différents. Par conséquent, les mêmes transformations ne doivent pas être effectuées plusieurs fois.

Il n'y a qu'un seul moins:

• La complexité du contrôle de l'intégrité des données chargées. Construire un processus ETL qui ne perdra pas de données, qui est suffisamment transparent et contrôlable - c'est possible, mais cela nécessite une équipe hautement qualifiée, l'implication des utilisateurs et des coûts de main-d'œuvre notables.

Problème 3: Formulaire de saisie des budgets

Le fait est que sous leur forme classique, les rapports dans les produits logiciels sont un moyen de sortie de données. Mais vous ne pouvez pas y entrer de données.





Mais pour la budgétisation, le schéma classique "Formulaire d'entrée" (document) -> tableaux internes -> Formulaire de sortie (rapport) "ne convient pas.



Par exemple, à un moment donné, nous avons élaboré un rapport d'approvisionnement mensuel (comme dans la figure 2), et maintenant nous commençons à planifier, et le directeur financier veut saisir le budget d'approvisionnement sous la même forme.



Que reste-t-il à faire? Vous pouvez créer un formulaire d'entrée de plan qui ressemble très, très similaire à ce rapport (comme illustré à la figure 3).

Solution au problème 3: formulaires d'E / S interactifs

La solution est également évidente: au lieu des "documents" et rapports "habituels, vous devez créer un objet qui sera simultanément et pour lire et saisir des données.



C'est encore mieux si dans cet objet il sera également possible d'effectuer des calculs entre les données saisies et / ou lues - c'est-à-dire de travailler comme Excel vous permet de travailler.



Dans ce cas, les plans, après avoir été saisis, peuvent être «ajoutés» au même entrepôt de données où se trouvent les données réelles (voir figure).





Figure: 6



Mais ces formes sont beaucoup plus compliquées à mettre en œuvre que les rapports ou documents ordinaires dans les systèmes de comptabilité.



Le degré d'interactivité peut être différent: il est plus facile d'implémenter des formulaires préconfigurés, plus difficile - dynamique (où le nombre de colonnes / lignes n'est pas connu à l'avance, mais leurs types sont prédéfinis). Il est encore plus difficile de permettre à l'utilisateur de «faire pivoter» les données, de créer de nouveaux formulaires et de définir des formules de calcul arbitraires, en modifiant la structure des rapports.

Solution au problème 4: les cubes

Il existe un autre outil qui résout un problème non indiqué ci-dessus.

Le fait est qu'avec de grandes quantités de données, une interactivité élevée et des formules complexes, les tables SQL relationnelles ordinaires, dans lesquelles il est habituel de stocker des données à partir de systèmes ERP, ne fournissent pas la vitesse maximale de traitement des données en temps réel.



Pour résoudre ce problème, vous pouvez utiliser le stockage de données non pas sous forme de tables, mais immédiatement sous forme de cubes.





Certes, si pour la budgétisation des tâches, organiser immédiatement le stockage sous la forme d'un cube est une bonne option, alors pour d'autres tâches commerciales, un modèle de stockage multidimensionnel peut ne pas convenir et le stockage est organisé à l'aide d'une technologie différente. Dans ce cas, le cube peut être ajouté au stockage "principal" comme un autre lien dans l'architecture.

TYPES DE PRODUITS LOGICIELS DANS LA BUDGÉTISATION

Examinons maintenant les types de technologies de l'information qui résolvent des problèmes importants dans l'automatisation de la budgétisation:

• Systèmes de données initiaux (systèmes comptables, systèmes ERP)
• Outils ETL
• Entrepôts de données (cubes standard et OLAP)
• Systèmes BI
• Systèmes EPM
• Excel bien sûr

Chaque type de système a une fonction théoriquement basique (voir tableau):







mais en réalité, les frontières sont légèrement floues, et souvent les produits «savent» faire des choses liées. Le chevauchement des fonctions ressemble très approximativement à ceci:







Important: Il convient de noter que le chevauchement des fonctions n'est généralement pas de 100%.



Autrement dit, généralement un outil qui offre des fonctions supplémentaires ne les exécute pas aussi bien qu'un outil spécialisé séparé!

Carte des types de logiciels dans la budgétisation

En général, visuellement, la couverture des différentes tâches d'automatisation de la budgétisation par différents types de systèmes d'information peut être représentée approximativement comme suit:





Fig. 7



Voyons maintenant quel type d'architecture de budgétisation proposent certains produits logiciels populaires.

BUDGÉTISATION DANS LES SYSTÈMES ERP

Le concept d'ERP a évolué au fil du temps et de nouvelles fonctionnalités sont intégrées aux systèmes ERP.



À mon avis, la fonctionnalité ERP «classique» comprend un système comptable; concepteurs de rapports; fonctions de contrôle opérationnel des plans et, bien entendu, les capacités de base de leur contribution.



Exclut: la capacité de collecter des données à partir de sources multiples; création de cubes et analyse interactive



Il y a des raisons de croire que l'EPM (comme la BI) a été conçu comme quelque chose qui allait au-delà de l'ERP. Mais maintenant, les frontières s'estompent et des fonctions EPM ou même des produits entiers peuvent être inclus en tant que modules dans les systèmes ERP.

1C: SCP

L'UPP implémente le schéma suivant, mais dans une seule base.





Figure: 8. Architecture de la budgétisation en 1C: UPP



Avantages de la budgétisation en UPP:

• Le SCP est très transparent et facile à modifier. Il est facile de vérifier les données qu'il contient et le développement de nouvelles fonctionnalités est assez peu coûteux.

Cartographie - dans le SCP à un niveau moyen. Ce n'est pas un avantage ou un inconvénient. Définition de l'intensité moyenne du travail.



Inconvénients de la budgétisation dans SCP:

• Manque de formes interactives d'entrées-sorties. La création de toutes les données se fait à travers des documents (saisie de plans; obtention de données réelles agrégées; réalisation de calculs), où il n'y a pas et ne peut pas y avoir d'interactivité et la capacité de voir la vue d'ensemble.
• Manque d'interface ETL. Il existe un mappage, mais les données réelles sont chargées directement à partir du formulaire de document, ce qui est peu pratique.
• Ancienne plateforme. Vous ne pouvez pas utiliser la technologie 1C Managed Forms, qui offre à l'utilisateur des possibilités modernes de filtrage / tri universel des listes et des rapports. Cela dégrade les capacités analytiques de l'utilisateur.

En général, dans le SCP, l'automatisation de la budgétisation est le plus clairement mise en œuvre selon le principe de la comptabilité ordinaire: l'utilisateur ne travaille pas à partir de l'image générale, mais à partir de documents primaires (saisie d'un plan; chargement d'un fait; estimations), et l'image générale ne peut être vue que dans des rapports dans lesquels rien ne peut être saisi.

1C: ERP

Autant que je me souvienne, au départ, l'ERP ne fournissait qu'un modèle de reporting "en ligne". Et aujourd'hui, dans de nombreuses entreprises, le scénario de travail principal est exactement celui-ci. Néanmoins, le programme permet désormais le stockage intermédiaire des valeurs calculées.





Figure: 9. Architecture de la budgétisation en 1C: ERP



Avantages de la budgétisation en 1C: ERP:

• Formes d'entrées-sorties suffisamment fonctionnelles

Inconvénients de la budgétisation dans 1C: ERP:

• La rigidité du modèle. En principe, comme dans la plupart des systèmes ERP, le modèle budgétaire ne tolère pas les changements fréquents et est plutôt pointilleux en matière de pré-paramétrage
• Cartographie faible. Pour une raison quelconque, la fonctionnalité de mappage est pire que dans l'UPP
• Dureté du produit. Contrairement à SCP, il est extrêmement difficile et coûteux de retravailler le cadre méthodologique ici. Vous devez bien étudier l'existant et construire votre budget sur 1C: ERP, si cela convient vraiment à l'entreprise
• Performance. Les formulaires interactifs sont assez fonctionnels, mais le dispositif technique les rend extrêmement lents sur de grandes quantités de données

Toujours dans 1C: ERP, il n'y a pas de fonctionnalité sérieuse en termes de mise en place du processus de budgétisation organisationnelle (workflow) et de travail multi-utilisateurs. Par exemple, les processus d'approbation sont inclus dans un produit distinct 1C: Workflow, qui est généralement implémenté en plus de l'ERP.

1C: CA

Integrated Automation est une version simplifiée de 1C: ERP, son développement suit donc le même chemin et il n'y a pas de méthodologie de budgétisation propre.

MS Axapta / MS Dynamics AX

Il ne fournit qu'un modèle «en ligne» pour visualiser les données réelles des budgets - elles sont lues directement à partir de leurs propres modules comptables, alors que les possibilités de transformation sérieuse ne sont pas fournies.





Figure: 10. Architecture de la budgétisation dans MS Dynamics



Le plus et le moins du système est son "affûtage" pour ses propres modules comptables de Dynamics et leur structure prête à l'emploi.



Avantages:

• Intégration avec les modules comptables. La configuration de l'obtention de données réelles à partir de divers modules du système ERP est assez simple.
• L'intégration. Il existe de nombreuses possibilités pour charger des plans prêts à l'emploi à partir de systèmes externes. Ainsi, Microsoft suit clairement la logique de séparation entre EPM et ERP, ce qui fait que les systèmes EPM sont très bien «accrochés» à Dynamics
• Flux de travail. Modèle d'organisation personnalisable suffisamment fonctionnel et transparent du processus budgétaire

Moins:

• ETL. En général, le produit ne fournit pas de capacités de transformation de données significatives
• Dureté du produit. Une méthodologie toute faite, mais plutôt limitée, est définie ici. Et (comme dans le cas de 1C: ERP), il est non seulement difficile de le recycler, mais aussi pratiquement inutile.

SAP S4 HANA

Le produit SAP principal qui a remplacé le système ERP SAP R / 3.



Pour la budgétisation, un produit EPM distinct est maintenant utilisé, qui dans la version de bureau (SAP BPC) pourrait encore être considéré comme un système EPM distinct "au-dessus" de l'ERP, mais dans la version cloud (SAP Analytics Cloud), il est déjà enfin intégré au système ERP (dans SAP S4 Cloud HANA). Vous trouverez ci-dessous plus de détails sur SAP BPC.



Il est important de dire autre chose à propos de S / 4 HANA lui-même: SAP transfère tout le travail d'un système ERP d'une base de données relationnelle à une base de données combinée (un mélange de relationnel, de colonne et multidimensionnel). Une telle base de données combinée est la technologie propriétaire SAP HANA (à ne pas confondre avec S / 4 HANA), qui, en fonction des actions de l'utilisateur, fonctionne soit comme un système transactionnel (système comptable), soit comme un système analytique (cube).



Ainsi, SAP évolue vers une architecture à l'opposé de ce qui est désormais bien connu dans la pratique «normale». Dans celui-ci, la base de données analytique n'est pas construite «au-dessus» du stockage (SAP BW), mais est implémentée «sous» le système ERP. Dans ce cas, l'entrepôt de données (SAP BW), lorsque l'utilisateur travaille avec ses données du système EPM, transfère les données pour les calculs arrière à cette base de données combinée d' origine.



En fait, SAP réalise le même effet pour lequel IN-Memory OLAP a été conçu de manière inverse: en maximisant les calculs à partir de la RAM.

Oracle Cloud ERP

Oracle a également pris le chemin de l'intégration d'un système EPM dans un ERP.



La société déplace activement ses produits vers la version cloud (peut-être même plus activement que ne le fait SAP). Par conséquent, pour sa principale solution EPM, Oracle Hyperion (dont nous parlerons également ci-dessous), la société promeut une alternative sous la forme d'Oracle EPM Cloud basé sur le cloud, qui est inclus dans l'ERP Oracle Cloud basé sur le cloud.

BI-SYSTÈMES

Les systèmes BI (Business Intellegence) dans leur forme «pure» sont un moyen de sortie de données. Autrement dit, les BI sont des concepteurs de rapports et de tableaux de bord, qui contiennent généralement également des fonctions de base pour la restructuration et l'analyse des données (par exemple, ils vous permettent de joindre des tables, de trouver des tendances moyennes, etc.).



Systèmes BI populaires:

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

En règle générale, BI se connecte à des magasins de données (à la fois relationnels et multidimensionnels) ou à des tables SQL brutes. Ainsi, vous pouvez vous référer à des données sources suffisamment détaillées (pour les agréger déjà dans BI). Cependant, les transformations conditionnelles complexes (avec des conditions «si») ne concernent pas la fonctionnalité BI «classique». Si vous êtes confronté à la tâche de créer un système de visualisation de tableau de bord, il est préférable de construire une transformation avant d'implémenter la BI.

SYSTÈMES EPM

EPM signifie Enterprise Performance Management. En outre, les termes Corporate Performance Management (CPM) et, moins fréquemment, Business Performance Management (BPM) sont rencontrés.



Un terme assez large qui peut impliquer des fonctions apparentées, mais le plus souvent de tels systèmes peuvent être considérés comme des constructeurs de formes interactives «plan-fact». Le concept d'EPM n'est pas encore largement connu, mais des solutions telles que IBM Planning analytics, Oracle Hyperion, Anaplan, parfois considérées dans le contexte de Business Intellegence, sont plus correctement appelées systèmes EPM.



Parfois, les systèmes EPM sont créés à des fins plus larges (par exemple, SAP EPM ou 1C: Holding Management), mais nous les considérerons précisément en termes de systèmes d'automatisation de la budgétisation. Par conséquent, nous appellerons SAP Business Planning & Consolidation (SAP BPC) - un système EPM, bien que SAP lui-même l'appelle le plus grand produit SAP EPM, qui inclut SAP BPC.



Comme nous l'avons dit, la BI ne permet pas la saisie de données. Les EPM incluent généralement des fonctions BI standard et offrent en outre la possibilité de saisir et d'écrire des données.



Systèmes EPM notables:

• Oracle Hyperion
• IBM Planning Analytics
• Anaplan
• SAP BPC
• Bit.Finance
• 1C: Gestion de la détention

Commençons par les plus petits.

Bit.Finance

Bit. Finance est basé sur la méthodologie de budgétisation UPP, mais contrairement à elle, d'une part, il est pris en charge et développé, et d'autre part, il est mis en œuvre comme un système EPM au-dessus de l'ERP (ainsi, il vous permet de consolider des données factuelles provenant de diverses sources externes).





Figure: 11. L'architecture de la budgétisation dans Bit.Finance



Avantages de l'automatisation de la budgétisation dans Bit.Finance:

• Constructeurs de formulaires pour saisir ou lire des données. Contrairement à l'UPP, les formes des documents comptables ne sont pas figées ici, elles peuvent être personnalisées, les mettant sous une forme assez pratique.
• Interface de gestion des devis. Vous pouvez recalculer ici les modèles de budget de manière centralisée, plutôt que de créer manuellement un document de valorisation.

La cartographie est plus développée que dans SCP.



L'obtention de données réelles fonctionne de trois manières:

• Grâce à un document d'acquisition de preuves (comme dans SCP),
• Comptabilité parallèle. Dans cette option, les documents comptables, au fur et à mesure de leur conservation, créent des entrées simultanées dans les registres comptables et les registres budgétaires.
• Méthode de diffusion. Dans cette option, les écritures du grand livre comptable sont converties dans le grand livre de budgétisation.

Inconvénients de l'automatisation de la budgétisation dans Bit.Finance:

• Travaillez à travers les formes de documents. Malgré le fait que les formes des documents soient devenues flexibles (voir le premier plus), et en général, dans cet aspect, beaucoup de progrès ont été réalisés par rapport à SCP, le produit ne s'est toujours pas écarté du modèle de travail orienté document autant que nous le souhaiterions. Ce qui, comme nous l'avons dit, n'est pas pratique pour la budgétisation.
• Manque de formes interactives d'entrées-sorties. Contrairement à 1C: ERP, il n'y en a pas ici.

Anaplan

Un produit phare qui a récemment acquis une grande popularité sur le marché mondial. Offert uniquement dans la version cloud.



Contrairement à d'autres solutions populaires (y compris Hyperion et Planning Analytics), elle a une spécialisation légèrement spécifique: elle fonctionne mieux en tant que service de coût qui vous permet de recalculer rapidement et automatiquement des modèles de budget volumétrique avec un grand nombre de dépendances.





Figure: 12. Architecture de budgétisation Anaplan (scénario d'automatisation populaire)



Avantages:

• Coût. Le produit se concentre sur les calculs et stocke toutes les données dans In-Memory OLAP, ce qui permet à tous les modèles d'être recalculés en ligne
• Travail d'équipe (dans le cadre de la préparation des données de planification)
• Modélisation UX et forme libre.
• ETL. Outil ETL propre et très pratique
• Nécessite un support informatique minimal. Surtout quand il s'agit de modélisation
• Coût. Un peu cher pour le marché russe, mais en comparaison avec les leaders internationaux (le même Oracle Hyperion), le coût total de possession est moindre
• Vitesse de mise en œuvre. Comparé à Hyperion et Planning Analytics, le produit est plus simple à utiliser et à mettre en œuvre

Moins:

• Mise en page
• Travail d'équipe (en termes de travail avec les événements: notifications, mailings, etc.)
• Syntaxe de formule personnalisée. En général, utiliser votre propre code est toujours un inconvénient du point de vue des utilisateurs finaux.
• Hiérarchies. Il y avait des problèmes avec l'utilisation d'une hiérarchie d'annuaires différente pour différents modèles de budget. Le problème n'est pas important pour de nombreuses entreprises, mais critique pour certaines. Peut-être (je l'espère) Anaplan a déjà résolu ce problème maintenant.
• Ad-hoc . , : Anaplan , .

Le plus et le moins d'Anaplan est sa spécialisation relativement claire et le fait qu'elle n'empiète pas sur l'écosystème informatique de l'entreprise. Le plus est que le produit a clairement défini son objectif fonctionnel, et les directions de son développement sont tout à fait prévisibles. C'est un service pour effectuer des analyses hypothétiques, calculer et approuver des plans (budgets), et vous devez planifier l'architecture du client en fonction de cela. L'inconvénient est que le produit ne peut pas remplacer un entrepôt de données d'entreprise à part entière, ne peut pas remplacer toutes les capacités de BI, une infrastructure ETL d'entreprise complexe et l'ensemble du système informatique d'entreprise ne sont pas construits dessus. Tout cela ne poserait pas de problème si le produit n'était pas proposé uniquement dans la version cloud.



Contrairement à Oracle et SAP (qui prétendent tous deux être un écosystème), Anaplan ne met pas l'accent sur la capacité à «déplacer» facilement les données et les outils entre le cloud et les serveurs de l'entreprise. Ainsi, dans son cas, les inconvénients du produit cloud (prise en compte de la tarification en fonction de la quantité de données utilisées sur le serveur) sont les plus visibles.



Comme il ne remplace pas un stockage d'entreprise universel, il peut dans certains cas être utilisé comme un service de calcul qui «ajoute» des données de planification au DWH de l'entreprise, à partir duquel les données sont transférées vers un système BI séparé pour créer des rapports et des tableaux de bord rapides.





Figure: 13. Architecture de budgétisation Anaplan (scénario d'automatisation alternatif)



En général, l'utilisation des systèmes EPM et BI est une pratique normale.

Oracle Hyperion

Il existe au moins en deux versions: Oracle Hyperion Planning et Oracle Hyperion Financial Management.

Désormais activement remplacé par le nouveau produit Oracle EPM Cloud.



En raison de l'écosystème, les architectures peuvent prendre une variété de types, mais la typique ressemble à quelque chose comme ça.





Figure: 14. Architecture de budgétisation dans Hyperion (option possible)



Dans la figure, j'ai donné un système de BI à titre d'exemple, car la base de données analytique Oracle Essbase est une excellente base pour l'analyse du big data dans les outils de BI.



Oracle Data Integrator est proposé en tant que solution ETL, qui agit comme un mécanisme d'intégration de données universel dans l'écosystème Oracle.



Avantages de l'automatisation de la budgétisation dans Oracle Hyperion:

• Écosystème. Dans le cas d'Oracle, je le noterai comme un plus, car Oracle est l'un des plus grands fournisseurs de bases de données, et l'intégration pour les entreprises qui travaillent sur Oracle SGBD (et il y en a beaucoup) présente vraiment des avantages. En particulier, il est plus pratique de répartir les fonctionnalités entre le cloud et le serveur. De plus, des collègues parlent d'avantages assez sérieux en termes de sécurité dans l'architecture d'Oracle (je ne suis pas un expert en la matière, s'il y en a ici, veuillez corriger).
• Ad-hoc ("reporting on demand").

Inconvénients de l'automatisation de la budgétisation dans Oracle Hyperion:

• Écosystème. Je noterai également comme un inconvénient, puisque, selon les informations disponibles, Hyperion est choisi principalement par les entreprises travaillant sur la pile technologique Oracle, et de son utilisation dans un environnement non Oracle sur le long terme, un effet moindre est possible.
• . , Anaplan.
• . , UX ( ).

IBM Planning Analytics

Principalement destiné aux grandes entreprises, pas très facile à déployer et à administrer, mais un système EPM très fonctionnel. Actuellement, IBM Planning Analytics repose sur les technologies TM1 (sous-jacentes à Cognos).



Pour les processus ETL, IBM suggère d'utiliser un produit distinct, IBM DataStage (précédemment utilisé par Cognos DataManager), Turbo Integrator, Cognos Integration Server ou un outil ETL externe.



L'architecture typique est très similaire à Hyperion.





Figure: 15. Architecture de budgétisation dans Planning Analytics (facultatif)



Forces d'IBM Planning Analytics:

• Prévision.
• Travailler avec des événements.
• Souplesse. Le produit ne peut pas être qualifié de non exigeant en termes de pré-configuration, mais il essaie de s'adapter à l'évolution des modèles.
• Pas un écosystème. Ce qui est surprenant dans le fait de travailler avec IBM, c'est qu'un grand volume de matériel didactique produit par l'entreprise vise à décrire les meilleures pratiques d'interaction des produits IBM avec d'autres solutions (y compris Oracle et SAP), et dans une variété de problèmes. À mon avis subjectif, il est bon qu'à long terme, l'entreprise garde la tendance à développer l'intégration avec des systèmes tiers (ce qui permet de prendre en charge une variété d'architectures qui se sont développées dans les entreprises), et non à la réduire.
• Support produit.

Moins

• Complexité. Comme avec Hyperion: nécessite une formation importante des utilisateurs, pas l'infrastructure la plus légère.

SAP BPC

En général, les caractéristiques distinctives de SAP sont l'écosystème, la complexité de l'architecture et l'infrastructure des solutions.



Comme je l'ai dit, SAP a pris en charge et prend en charge différentes options d'architecture à des moments différents; selon les informations les plus récentes, la version phare de l'architecture préconisée par l'éditeur aujourd'hui ressemble à ceci:





Fig. 15. Architecture de budgétisation dans SAP Business Planning & Consoldation (exemple)



Avantages de la budgétisation basée sur SAP BPC:

• Intégration de données. Bien que complexe, il est fonctionnel et rapide, ce qui est essentiel pour les grandes entreprises.
• Visualisation.
• Flux de travail.

Inconvénients de la budgétisation basée sur SAP BPC:

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• Prix. En termes de coût total de possession, il s'avère en fait être l'un des systèmes EPM les plus chers au monde, qui est influencé par les changements d'architecture.

OUTILS ETL

Des outils ETL bien connus sont utilisés pour créer des processus ETL, parmi lesquels il existe de nombreux produits des mêmes fournisseurs qui produisent des solutions BI / EPM:

• IBM DataStage
• Informatica PowerCenter
• Talend
• Apatar
• Services de données SAP
• Intégrateur de données Oracle
• Usine de données Microsoft Azure
• et plein d'autres dr.

Il est prévu que l'article sera progressivement mis à jour, éventuellement avec l'ajout d'informations sur les nouveaux produits et les principes de développement de logiciels pour la budgétisation à partir de zéro.